XML-RPC Server
Release date = 2006-05-27
wperl.exe gus_xml-rpc_server.pl --help
perl gus_xml-rpc_server.pl --help &
An XML-RPC server useful in allowing external Perl scripts to be triggered remotely (for backup, etc).
At head of script is an area for user configuration. But in taking advantage of them, one therby documents the settings, some of which might best remain secret. Should you prefer to leave them as empty strings, a pop-up GUI will let you set them at startup.
A harmless way to test the server/client connection. Requests the server to inform of its status.
Copy the current log, if any, back to the client.
Allows a client to change the password of the server.
Allows a client to change the cipher pass pharase of the server.
A means of executing a single command on each selected server.
A means of executing external scripts line-by-line on each selected server.
Execute button, browsing to the network path of the backup script. Each selected server will run said backup script in turn, not all at once, but one after another.
Client remotely kills selected servers. As of this version the results are ungraceful. Although harmless, a killed server cannot reply to the client with an I have died packet. So the client, after a short timeout, thinks the procedure call has failed. A subsequent attempt with the server_status method will verify that said server is indeed off-line.
Client browses for and transmits a new script to selected servers. Once transmitted, those servers store a copy locally. It is then immediately available to the<C execute_script >method. This, quite obviously, is a dangerous thing to do. Hence on the client, it is accessed via a warningly entitled titled pull-down menu: At Your Hazard!
Any script thus sent is subjected to a certain degree of scrutiny by receiving servers. This scrutiny is only for known types of scripting languages, pure-ASCII content, etc. No test whatever is made for dangerous instructions embeded therein. Accordingly, use of this feature is AT YOUR OWN HAZARD! The author of this server/client pair assumes no responsibility whatever for any use to which it is put.
User enters exact script name or regular expression into client. Client then requests selected servers to delete matching files. Once transmitted, each selected server will completely delete its local copy along with info related to it. The client too forgets its existence so that you cannot ask for it again.
Client browses for, filters and then transmits a pure ASCII text file to selected servers. Once transmitted, those servers store a copy locally, in a directory path generally outside that where executable scripts are stored. The exact path will vary, depending pupon the contents of the '%elsewhere' hash as defined by the user.
%elsewhere hash are polled as filename-matching regexes. The values are directory paths. So when the server receives a filtered file sent to it from the client via the add_doc_elsewhere method, the server store it accordingly
%lines_to_skip hash with keys similar to those of the %elsewhere hash on the server, and likewise employed to match against filenames. But there each value will be an array of regular expressions for disallowed phrases. Any such lines as match a regex therein listed will be removed prior to transmission.
add_doc_elsewhere method as follows. Certain MTS servo-hydraulic testing machines which are left to run unattended on weekends had formerly required on-site visitation by operators working on overtime, and at their considerable inconvenience. Most frequently, however, such efforts were merely to determine that, no, the machines in question had not stopped and did not therefor require any service.
Now, however, an XML-RPC client oversees these machines, forwarding filtered copies of their current status logs over the Internet to an XML-RPC server. There the server matches the received, filtered logs to a directory on a co-resident Apache web server. Thus operators have only to check that URL via web browser from their home PC to know if the machine requires service or not.
The filtering so often mentioned above serves a two-fold purpose. Firstly it removes many lines from the status logs which are of no interest to the operator in determining if their machine needs tending. Secondly it removes any reference as to what sort of test the machine is running...customer proprietary information...that kind of thing (which, in a sense, is really just part of the first criterion).
User enters exact script name or regular expression into client. Client then requests selected servers to delete matching files from their designated elsewhere-paths.
Hereby the client transmits a request for the server to transfer control temporarilly to companion script gus_xml-rpc_update.pl which kills and restarts the server. Works for both Unix and Win32 being tested on NetBSD, Win2K and WinXP.
Assuming you have a database server (PostgreSQL, MySQL, etc.) on the same PC. Then this method will function very like a CGI web page so that you may relay SQL queries to it. Each method call will do as follows:
There is not much advantage in doing this way unless you need to bridge a firewall, in which case you will, of course, also require the companion Perl/CGI script for doing just that. Suitable as a stop-gap until such time as you can persuade your friendly, local, corporate IT SysAdmin to unblock the port where your DB normally listens.
So if, like me, you have an fetal DB project gestating in your home PC, then this little feature will give you access to it from work until such time as it is ready for presentation to management. And then, being thus armed with a fait accompli, you stand a much better chance of weaning your IT department off their nasty commercial addition with a taste of open source.
$cipher_key near the head of each). Or if this has been left empty, a default pass phrase (refer to $GUS::Crypt::DEFAULT_KEY near the tail of each) will serve in its stead.. The client may later propagate new pass phrases to selected servers at any time.
$GUS::Crypt::obfuscate for details) and again each time the cipher is changed.
You may not rely upon the built-in default cipher key. The server will not allow it for any method except 'change_cipher'. Thus, in order to do anything useful, you will have to supply a cipher key of your own.
Transactions also require a password. At startup, both client and server must employ identical plain text passwords (refer to $plain_pw near the head of each). The client may later propagate new passwords to selected servers at any time.
The client and server each keep their own separate logs. Verbosity is according to user-elected startup options.
$script_script ) stripping away any ascending path elements. Secondly, it checks against its own list of allowable scripts (ref $script_list). Thirdly it makes sure the script is pure ASCII. Lastly it insures against any modification since upload or server startup.
execute_script method is free from any malicious tampering prior to startup. Nor does it filter the contents of pure ASCII scripts uploaded by the client. The user alone is wholly responsible for script content.
Install these into Perl via ActiveState PPM, else into NetBSD via pkgsrc or CPAN as appropriate for your OS: Frontier::Daemon, Sys::Hostname::Long, Crypt::CBC, Crypt::Blowfish, Digest::MD5::File, Log::Logger.
Further, if you expect to relay SQL queries to a database server, then you will also require the DBI module and an associated DBD for whichever DB you are using.
My own GUS::Crypt package is already embeded in both the client and server scripts. It does not add anything truly novel but exists as a separate package for the sake of authorial convenience.
Nothing here presentes itself as a difficulty. Required external dependencies are available from the expected sources: /usr/pkgsrc for NetBSD and/or CPAN for Perl. I cannot say for Linux, since I have yet to try it. If any report a problem for Linux, I would very like to help work it out and document the solution here
No especial problems here either, except that some things are not where most folks expect to find them.
ppm> help repository
ppm> repository add ``Lincoln Stein'' http://stein.cshl.org/ppm
ppm> repository add ``Randy Kobes'' http://theoryx5.uwinnipeg.ca/ppms
Unless the companion Perl script gus_xml-rpc_client_tk.pl running on some other network-attached PC, this server will lack any client to communicate with. Refer to documentation for the client at this URL: http://starling.us/tet/gus_perl/gus_xml-rpc_pl/gus_xml-rpc_client_tk.html.
These are for use with the execute_script method. See the complete list at this URL: http://starling.us/tet/gus_perl/gus_xml-rpc_pl.
Gan Uesli Starling <gan@starling.us>
Copyright (c) 2005-2006, Gan Uesli Starling. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
Networking