[Note: parts of this message were removed to make it a legal post.]

Team,

Let me begin by stating that I am still a Ruby novice, although I've written
some simple appls (sudoku, TCP and UDP servers and other mundane appls) with
the input of the team.

I worked with AIX and I support more than a hundred servers in a complex and
secured??? environment.
Although some vendors have packages to perform "distributed" remote support,
it is not allowed in my environment.
At first tried to design my own poor-man distributed package using what is
allowed, ssh (port 22).
But this did not provide the flexibility to manage all the servers from one
centralized location.

So, I went ahead and designed in Ruby a TCP Client/Server that works as
follows:

On every server I have a server listening on a predefined port.
The server gets started from the cron and every 10 minutes the cron checks
to ensure that the server is running.

Lets say the client wants to execute a remote command like creating a userid
on all servers or just checking paging or memory consumption, etc.
It sends a request to the server and the server executes the command and
returns the output to the client.

So the client can:

shc -s hostname cmd
shc -p full_path_of_a_file_with_list_of_servers
hsc -a cmd (This version uses a file /etc/servers with the list of all
servers)

I also have another client named shp with the same flags as above and which
uses the same TCP server and which is listening on the same port.
The shp program is used to push files to one or multiple or all servers.

All the UNIX admin actually love the application. BTW, the shc shp are only
executable by root.

However, although we are behind multiple firewalls (at least 6) a scanning
tool detected the listener (TCP Server) and marked it as a security risk on
a particular server.
I was asked and of course I complied, to shutdown the server on that host.
I was also asked to redesign the tool adding a bit more security and they
would allow it. They suggested "handshaking" between client and server, the
initial comm or perhaps all comm should be encrypted. I was asked if Ruby
has encryption
So here is where I am looking for some recommendations.

Reading a new book I just acquired I came across a package called GServer. I
was wondering if this will be suitable for what I need.
Also, what type of encryption should I use?

They were talking something like:

Client sends connection request
Server replies with client's hostname and time
Client sends back the time received from server together with the command
which the client wants to execute at the remote server.
Server executes command if it is "happy" with the reply from the client.

Of course all communication must be ciphered.

Any suggestions will be greatly appreciated.

Thank you

Victor

On 2008-05-23 22:02:00 -0600, Victor Reyes <victor.reyes@gmail.com> said:

> [Note: parts of this message were removed to make it a legal post.]
>
> Team,
>
> <snip>.
>
> Any suggestions will be greatly appreciated.
>
> Thank you
>
> Victor

Hi Victor.

I know it's not what you are asking.. but did you check out Capistrano?

I've found it very useful for doing exactly what you are describing,
without the need to run extra service on remote machines.

http://capify.org/




--
dedward

[Note: parts of this message were removed to make it a legal post.]

No but I will check it right now.

Thank you for the info!

Victor

On Mon, May 26, 2008 at 8:49 PM, dedward <dedward@ruby-lang.org> wrote:

> On 2008-05-23 22:02:00 -0600, Victor Reyes <victor.reyes@gmail.com> said:
>
> [Note: parts of this message were removed to make it a legal post.]
>>
>> Team,
>>
>> <snip>.
>>
>> Any suggestions will be greatly appreciated.
>>
>> Thank you
>>
>> Victor
>>
>
> Hi Victor.
>
> I know it's not what you are asking.. but did you check out Capistrano?
>
> I've found it very useful for doing exactly what you are describing,
> without the need to run extra service on remote machines.
>
> http://capify.org/
>
>
>
>
> --
> dedward
>
>
>

How about dsh (distributed shell), seems to be available for with AIX:

http://publib.boulder.ibm.com/infoce...am7cm_dsh.html

RF

Victor Reyes wrote:
> [Note: parts of this message were removed to make it a legal post.]
>
> Team,
>
> Let me begin by stating that I am still a Ruby novice, although I've written
> some simple appls (sudoku, TCP and UDP servers and other mundane appls) with
> the input of the team.
>
> I worked with AIX and I support more than a hundred servers in a complex and
> secured??? environment.
> Although some vendors have packages to perform "distributed" remote support,
> it is not allowed in my environment.
> At first tried to design my own poor-man distributed package using what is
> allowed, ssh (port 22).
> But this did not provide the flexibility to manage all the servers from one
> centralized location.
>
> So, I went ahead and designed in Ruby a TCP Client/Server that works as
> follows:
>
> On every server I have a server listening on a predefined port.
> The server gets started from the cron and every 10 minutes the cron checks
> to ensure that the server is running.
>
> Lets say the client wants to execute a remote command like creating a userid
> on all servers or just checking paging or memory consumption, etc.
> It sends a request to the server and the server executes the command and
> returns the output to the client.
>
> So the client can:
>
> shc -s hostname cmd
> shc -p full_path_of_a_file_with_list_of_servers
> hsc -a cmd (This version uses a file /etc/servers with the list of all
> servers)
>
> I also have another client named shp with the same flags as above and which
> uses the same TCP server and which is listening on the same port.
> The shp program is used to push files to one or multiple or all servers.
>
> All the UNIX admin actually love the application. BTW, the shc shp are only
> executable by root.
>
> However, although we are behind multiple firewalls (at least 6) a scanning
> tool detected the listener (TCP Server) and marked it as a security risk on
> a particular server.
> I was asked and of course I complied, to shutdown the server on that host.
> I was also asked to redesign the tool adding a bit more security and they
> would allow it. They suggested "handshaking" between client and server, the
> initial comm or perhaps all comm should be encrypted. I was asked if Ruby
> has encryption
> So here is where I am looking for some recommendations.
>
> Reading a new book I just acquired I came across a package called GServer. I
> was wondering if this will be suitable for what I need.
> Also, what type of encryption should I use?
>
> They were talking something like:
>
> Client sends connection request
> Server replies with client's hostname and time
> Client sends back the time received from server together with the command
> which the client wants to execute at the remote server.
> Server executes command if it is "happy" with the reply from the client.
>
> Of course all communication must be ciphered.
>
> Any suggestions will be greatly appreciated.
>
> Thank you
>
> Victor
>

[Note: parts of this message were removed to make it a legal post.]

*dsh* is not allowed as it is part of the infamous "r" commands.

On Tue, May 27, 2008 at 7:39 AM, Ron Fox <fox@nscl.msu.edu> wrote:

> How about dsh (distributed shell), seems to be available for with AIX:
>
>
> http://publib.boulder.ibm.com/infoce...am7cm_dsh.html
>
> RF
>
> Victor Reyes wrote:
>
>> [Note: parts of this message were removed to make it a legal post.]
>>
>> Team,
>>
>> Let me begin by stating that I am still a Ruby novice, although I've
>> written
>> some simple appls (sudoku, TCP and UDP servers and other mundane appls)
>> with
>> the input of the team.
>>
>> I worked with AIX and I support more than a hundred servers in a complex
>> and
>> secured??? environment.
>> Although some vendors have packages to perform "distributed" remote
>> support,
>> it is not allowed in my environment.
>> At first tried to design my own poor-man distributed package using what is
>> allowed, ssh (port 22).
>> But this did not provide the flexibility to manage all the servers from
>> one
>> centralized location.
>>
>> So, I went ahead and designed in Ruby a TCP Client/Server that works as
>> follows:
>>
>> On every server I have a server listening on a predefined port.
>> The server gets started from the cron and every 10 minutes the cron checks
>> to ensure that the server is running.
>>
>> Lets say the client wants to execute a remote command like creating a
>> userid
>> on all servers or just checking paging or memory consumption, etc.
>> It sends a request to the server and the server executes the command and
>> returns the output to the client.
>>
>> So the client can:
>>
>> shc -s hostname cmd
>> shc -p full_path_of_a_file_with_list_of_servers
>> hsc -a cmd (This version uses a file /etc/servers with the list of all
>> servers)
>>
>> I also have another client named shp with the same flags as above and
>> which
>> uses the same TCP server and which is listening on the same port.
>> The shp program is used to push files to one or multiple or all servers.
>>
>> All the UNIX admin actually love the application. BTW, the shc shp are
>> only
>> executable by root.
>>
>> However, although we are behind multiple firewalls (at least 6) a scanning
>> tool detected the listener (TCP Server) and marked it as a security risk
>> on
>> a particular server.
>> I was asked and of course I complied, to shutdown the server on that host.
>> I was also asked to redesign the tool adding a bit more security and they
>> would allow it. They suggested "handshaking" between client and server,
>> the
>> initial comm or perhaps all comm should be encrypted. I was asked if Ruby
>> has encryption
>> So here is where I am looking for some recommendations.
>>
>> Reading a new book I just acquired I came across a package called GServer.
>> I
>> was wondering if this will be suitable for what I need.
>> Also, what type of encryption should I use?
>>
>> They were talking something like:
>>
>> Client sends connection request
>> Server replies with client's hostname and time
>> Client sends back the time received from server together with the command
>> which the client wants to execute at the remote server.
>> Server executes command if it is "happy" with the reply from the client.
>>
>> Of course all communication must be ciphered.
>>
>> Any suggestions will be greatly appreciated.
>>
>> Thank you
>>
>> Victor
>>
>>
>