Man Linux: Main Page and Category List

NAME

       xmlsysd  - provide anonymous information to enable the efficient remote
       monitoring of a network workstations, especially in the  context  of  a
       beowulf or a LAN subnet.

SYNOPSIS

       xmlsysd [-v] [-d port] [-i port] [-n nconnect]

DESCRIPTION

       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

       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.

OPERATION AND API

       Once a connection is established the daemon accepts many commands:

       init

       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.

SUPPORTED STATISTICS

       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.

BUG REPORTS

       Please   send   bug   reports,   patches,    suggestions,    etc.    to
       rgb@phy.duke.edu.   If  the  suggestions are sufficiently general, they
       may be worth discussing on the Beowulf or Extreme Linux lists, see

         http://www.beowulf.org
         http://www.extremelinux.org

       for information on what these projects are and instructions for joining
       in.

AUTHOR AND LICENSE INFO

       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:

       http://www.phy.duke.edu/brahma

       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.