Monitoring/inventory client-server app

snorble snorble at hotmail.com
Thu Nov 17 23:49:16 EST 2011


On Nov 17, 4:31 pm, Irmen de Jong <ir... at -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.



More information about the Python-list mailing list