Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #15804 > unrolled thread

Monitoring/inventory client-server app

Back to article view | Back to comp.lang.python

Contents

  Monitoring/inventory client-server app snorble <snorble@hotmail.com> - 2011-11-16 20:17 -0800
    Re: Monitoring/inventory client-server app Irmen de Jong <irmen@-NOSPAM-razorvine.net> - 2011-11-17 23:31 +0100
      Re: Monitoring/inventory client-server app snorble <snorble@hotmail.com> - 2011-11-17 20:49 -0800
        Re: Monitoring/inventory client-server app Alec Taylor <alec.taylor6@gmail.com> - 2011-11-18 15:53 +1100

#15804 — Monitoring/inventory client-server app

I'm writing a tool for monitoring the workstations and servers in our
office. I plan to have a server and a client service that runs on each
workstation and reports back to the server (heartbeat, disk free
space, etc).

So far I am considering XMLRPC, or a client service that just
downloads a Python file and runs it.

With XMLRPC I don't know how to easily add features without having to
update every client. Also while playing with XMLRPC I learned that
when you run a registered function, it runs it on the server. I was
hoping it would run on the client, so that when I get the machine's
computer name (or disk space, etc) it will return the client's info.
It seems with XMLRPC I would have to hard code the functionality into
the client (i.e. client gets it's computer name, then calls the XMLRPC
function to pass it to the server)? I was hoping it would work more
like, "pass some code to the client to be run on the client, and
report it to the server". Almost XMLRPC in the reverse direction.

With the download-and-run approach, it seems trivially easy to add new
functionality to the clients. Just save the updated Python file to the
server, and clients download it and run it.

Are there any standard approaches to problems like this that can be
recommended? Thank you.

[toc] | [next] | [standalone]

#15838

On 17-11-2011 5:17, snorble wrote:
> I'm writing a tool for monitoring the workstations and servers in our
> office. I plan to have a server and a client service that runs on each
> workstation and reports back to the server (heartbeat, disk free
> space, etc).
>
> So far I am considering XMLRPC, or a client service that just
> downloads a Python file and runs it.
>
> With XMLRPC I don't know how to easily add features without having to
> update every client. Also while playing with XMLRPC I learned that
> when you run a registered function, it runs it on the server. I was
> hoping it would run on the client, so that when I get the machine's
> computer name (or disk space, etc) it will return the client's info.
> It seems with XMLRPC I would have to hard code the functionality into
> the client (i.e. client gets it's computer name, then calls the XMLRPC
> function to pass it to the server)? I was hoping it would work more
> like, "pass some code to the client to be run on the client, and
> report it to the server". Almost XMLRPC in the reverse direction.
>
> With the download-and-run approach, it seems trivially easy to add new
> functionality to the clients. Just save the updated Python file to the
> server, and clients download it and run it.
>
> Are there any standard approaches to problems like this that can be
> recommended? Thank you.


The security implications are HUGE when you are thinking about 
transferring and executing arbitrary code over the network. Avoid this 
if at all possible. But if you can be 100% sure it's only trusted stuff, 
things are not so grim.

Have a look at Pyro, or even Pyro Flame:

http://packages.python.org/Pyro4/
http://packages.python.org/Pyro4/flame.html

Flame allows for very easy remote module execution and a limited way of 
transferring code to the 'other side'.

Also what is wrong with running an XMLrpc server, or Pyro daemon, on 
your client machines? This way your central computer can call registered 
methods (or remote objects in case of Pyro) on the client and execute 
code there (that reports all sorts of stuff you want to know). Or have 
each client call into a central server, where it reports that stuff 
itself. Many ways to skin a cat.

Regards,
Irmen de Jong

[toc] | [prev] | [next] | [standalone]

#15862

On Nov 17, 4:31 pm, Irmen de Jong <ir...@-NOSPAM-razorvine.net> wrote:
> On 17-11-2011 5:17, snorble wrote:
>
>
>
>
>
>
>
>
>
> > I'm writing a tool for monitoring the workstations and servers in our
> > office. I plan to have a server and a client service that runs on each
> > workstation and reports back to the server (heartbeat, disk free
> > space, etc).
>
> > So far I am considering XMLRPC, or a client service that just
> > downloads a Python file and runs it.
>
> > With XMLRPC I don't know how to easily add features without having to
> > update every client. Also while playing with XMLRPC I learned that
> > when you run a registered function, it runs it on the server. I was
> > hoping it would run on the client, so that when I get the machine's
> > computer name (or disk space, etc) it will return the client's info.
> > It seems with XMLRPC I would have to hard code the functionality into
> > the client (i.e. client gets it's computer name, then calls the XMLRPC
> > function to pass it to the server)? I was hoping it would work more
> > like, "pass some code to the client to be run on the client, and
> > report it to the server". Almost XMLRPC in the reverse direction.
>
> > With the download-and-run approach, it seems trivially easy to add new
> > functionality to the clients. Just save the updated Python file to the
> > server, and clients download it and run it.
>
> > Are there any standard approaches to problems like this that can be
> > recommended? Thank you.
>
> The security implications are HUGE when you are thinking about
> transferring and executing arbitrary code over the network. Avoid this
> if at all possible. But if you can be 100% sure it's only trusted stuff,
> things are not so grim.
>
> Have a look at Pyro, or even Pyro Flame:
>
> http://packages.python.org/Pyro4/http://packages.python.org/Pyro4/flame.html
>
> Flame allows for very easy remote module execution and a limited way of
> transferring code to the 'other side'.
>
> Also what is wrong with running an XMLrpc server, or Pyro daemon, on
> your client machines? This way your central computer can call registered
> methods (or remote objects in case of Pyro) on the client and execute
> code there (that reports all sorts of stuff you want to know). Or have
> each client call into a central server, where it reports that stuff
> itself. Many ways to skin a cat.
>
> Regards,
> Irmen de Jong

I'm thinking maybe the client service will have a small number of
generic features, such as reading WMI and SNMP values. That way the
server still dictates the work to be done (i.e. XMLRPC returns which
WMI/SNMP values to query), and the client remains relatively focused
and straightforward.

[toc] | [prev] | [next] | [standalone]

#15863

Maybe take a look outside python:

- Puppet

On Fri, Nov 18, 2011 at 3:49 PM, snorble <snorble@hotmail.com> wrote:
> On Nov 17, 4:31 pm, Irmen de Jong <ir...@-NOSPAM-razorvine.net> wrote:
>> On 17-11-2011 5:17, snorble wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> > I'm writing a tool for monitoring the workstations and servers in our
>> > office. I plan to have a server and a client service that runs on each
>> > workstation and reports back to the server (heartbeat, disk free
>> > space, etc).
>>
>> > So far I am considering XMLRPC, or a client service that just
>> > downloads a Python file and runs it.
>>
>> > With XMLRPC I don't know how to easily add features without having to
>> > update every client. Also while playing with XMLRPC I learned that
>> > when you run a registered function, it runs it on the server. I was
>> > hoping it would run on the client, so that when I get the machine's
>> > computer name (or disk space, etc) it will return the client's info.
>> > It seems with XMLRPC I would have to hard code the functionality into
>> > the client (i.e. client gets it's computer name, then calls the XMLRPC
>> > function to pass it to the server)? I was hoping it would work more
>> > like, "pass some code to the client to be run on the client, and
>> > report it to the server". Almost XMLRPC in the reverse direction.
>>
>> > With the download-and-run approach, it seems trivially easy to add new
>> > functionality to the clients. Just save the updated Python file to the
>> > server, and clients download it and run it.
>>
>> > Are there any standard approaches to problems like this that can be
>> > recommended? Thank you.
>>
>> The security implications are HUGE when you are thinking about
>> transferring and executing arbitrary code over the network. Avoid this
>> if at all possible. But if you can be 100% sure it's only trusted stuff,
>> things are not so grim.
>>
>> Have a look at Pyro, or even Pyro Flame:
>>
>> http://packages.python.org/Pyro4/http://packages.python.org/Pyro4/flame.html
>>
>> Flame allows for very easy remote module execution and a limited way of
>> transferring code to the 'other side'.
>>
>> Also what is wrong with running an XMLrpc server, or Pyro daemon, on
>> your client machines? This way your central computer can call registered
>> methods (or remote objects in case of Pyro) on the client and execute
>> code there (that reports all sorts of stuff you want to know). Or have
>> each client call into a central server, where it reports that stuff
>> itself. Many ways to skin a cat.
>>
>> Regards,
>> Irmen de Jong
>
> I'm thinking maybe the client service will have a small number of
> generic features, such as reading WMI and SNMP values. That way the
> server still dictates the work to be done (i.e. XMLRPC returns which
> WMI/SNMP values to query), and the client remains relatively focused
> and straightforward.
> --
> http://mail.python.org/mailman/listinfo/python-list
>

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web