The xmlsysd daemon is designed to provide statistics and system information to hosts or monitor programs over the network via a simple, easily parsable API.
In forking daemon mode ([-d port]) it listens upon the suggested port (which must be unoccupied) and, upon a connection request, accepts it and forks a copy of itself to handle the connection. The connection is not authenticated in any way, but should be safe and efficient on a protected cluster like a beowulf or firewall-protected LAN.
The maximum number of permitted forked daemons/connections can be set. ([-n nconnect], default 10). For xinetd-based operation, this must be set in /etc/xinetd.d/xmlsysd, as xinetd controls the number of permitted connections directly.
The daemon can be invoked from a command line in verbose mode ([-v 1]) to obtain debugging information. Obviously this "breaks" the xml and hence the daemon! The easiest way to debug is to invoke the daemon in inetd mode and verbose set so you can just interact with it on the command line. Note that verbosity can be set to certain values to "focus" on particular subroutines or operations and can be (re)set at the command line via the "verbose" command.
Note that the port numbers used in the [-i port] or [-d port] arguments MUST match the port numbers used by the client applications. In the case of at least the accompanying wulfstat application, the ports should default to 7887 in xinetd-based daemon and wulfstat and can be overridden in the latter in the hostfile.
Security methodology and requirements vary from site to site, so it is not possible to "preconfigure" security for xmlsysd except in the context of a known distribution and environment. xmlsysd has no intrinsic security -- it will happily service connections from any host. Although it was written with some care to avoid buffer overwrite attacks, it is impossible to guarantee that this care was totally successful.
It is therefore strongly suggested that xmlsysd be secured unless it is run in a protected/firewalled environment. In daemon mode, tcp wrappers together with /etc/hosts.[allow,deny] provide a reasonable layer of security. In xinetd-based operation (the installation default in the rpm) one will likely need to use (e.g.) ipchains or iptables, which adds kernel overhead but allows access to be carefully controlled. For the truly paranoid, although it hasn't been personally tested by me, there is no reason that one should not be able to use ssl (stunnel) or ssh (port forwarding) to bidirectionally encrypt daemon traffic over even a WAN and simultaneously provide strong host identification.
In addition, unless one is either debugging or running a private forking daemon wrapped by e.g. ssh port forwarding, the daemon should generally be run as a non-privileged user such as "guest", and installs itself that way by default.
NO WARRANTY is provided for the intrinsic security of this daemon, and it is best to assume that it contains an as-yet-undiscovered exploit in configuring your system to secure it. Use it at your own risk and take whatever measures you deem necessary to make that level of risk acceptable in your own environment.
Once a connection is established the daemon accepts many commands:
Initialize all structures. REQUIRED to be the first command.
send Send the currently enabled node/clients statistics.
sendall Send ALL available (not PID-based) node/client statistics.
on flag1 flag2 flag3... (or) all off flag1 flag2 flag3... (or) all Set control flags that mask what information is sent by the send command. The flags currently supported include:
compress, whitespace, identity, time, users, cpuinfo, loadavg, meminfo, net, stat, sysvipc, uptime, version, pids, running, root.
quit Terminates the connection -- the daemon instantiation dies.
The data returned by the daemon in any non-verbose mode should be an http 1.1 header fragment followed by a well-formed xml message containing the encapsulated statistics. This message can be parsed with standard tools to extract the field contents for display or processing or recording. Each bottom level statistic should be tagged uniquely with at least an "id" identifier differentiating multiple interfaces or values with otherwise identical tags.
When writing an interface, remember that the interface may well know (or need to know) only of a subset of the fields the daemon provides. It should not "break" if it encounters unknown fields or if the field it expects is missing. The xmlsysd is thus continue to be both scalable and extensible independent of the tools that use it.
Additional suggestions, especially those accompanied by code or patches, are greatfully welcomed. Feel free to include patch authorship in comments within the patches -- they will be left in the source to immortalize your contributions. They'll also entitle you to tap into the "beverage" clause of the modified GPL but the other way... I'll buy you a beer.
The only reliable way to see if a statistic is supported is to crank it up and see what it finds. You can easily do this in userspace -- just enter e.g. xmlsysd -i 7882 and the daemon will start up. Enter "init". You should see the all the non-pid fields. Enter "on pids" and then "send". You should see all the supported statistics AND at least the status information a few "running" processes (repeat some more sends sends if necessary until you surprise something running). Nothin' to it.
Please send bug reports, patches, suggestions, etc. to firstname.lastname@example.org. If the suggestions are sufficiently general, they may be worth discussing on the Beowulf or Extreme Linux lists, see
for information on what these projects are and instructions for joining in.
The author of xmlsysd is Robert G. Brown. xmlsysd is provided under a slightly modified GPL version 2"b" (for beverage), see the README.GPL in the source. The current source is freely available from the author upon request at:
What's the GPL "b" modification? He's glad you asked. If you use the software and happen to meet the author (say, at a Linux Expo or the like) you are morally and ethically obligated to at least offer to buy him a beverage, if time and circumstances permit. If you are a software distributer/reseller and actually make money from the software, you might consider going a bit further and sending the author a bottle of nice, dry red wine from time to time as a "royalty". Thank you very much indeed.