wulfware
by
Robert G. Brown
Duke University Physics Department
Durham, NC 27708-0305
Copyright Robert G. Brown, 2025
Abstract
Wulfware: A LAN/Cluster/Beowulf Monitoring Suite
Version 2.6.0
Robert G. Brown (rgb)
This is the official website for the Wulfware suite of LAN or
cluster monitoring tools. These tools all build from a single source
rpm, or alternatively one can build them from the source tarball.
This project has a mailing list here.
This is a (currently) very low traffic list devoted to bug reports,
development announcements, feature requests and little else.
View
this
page in Romanian courtesy of azoft
- xmlsysd -- a daemon that runs on the client to be monitored that
provides client statistics on demand via an xinetd or forking daemon
socket. The information is wrapped in XML tags that can be parsed or
presented on the client side in a variety of ways.
- libwulf -- a library of functions that support configuring a
cluster or LAN for monitoring (using an XML-based cluster description
file), managing connections to the cluster nodes or LAN clients
automatically, configuring the connections to return minimal information
for the quantities being monitored or displayed, and then polling the
hosts and extracting their information into a struct for further
processing by a user interface (UI) program linked to the library.
- wulflogger -- a very simple raw-tty (stdout) UI that is suitable
for extracting cluster/lan statistics from any of several useful
clusters of data. This data can be piped into a file or other
applications for post-processing, removing the burden from a programmer
of writing an automated UI for managing the connections themselves.
Alternatively, it can be used as a template for further UIs.
- wulfstat -- an ncurses-based (cooked tty) UI that presents LAN or
cluster stats in a scrollable display within e.g. an xterm window.
- wulf2html -- a perl filter that runs behind wulflogger and transforms
wulflogger output into a formatted html page that can then be viewed
from any browser. wulf2html can be started from chkconfig as a service
on a webserver or host that mounts webspace after editing
/etc/warewulf/wulf2html.sh and /etc/warewulf/wulfhosts to reflect the
cluster or LAN to be monitored. This is still a bit experimental.
- wulfware-doc -- a future latex/pdf documentation set for all
of the above, which alas doesn't exist yet. The man pages do exist, and
are installed for each package within the package.
- gwulfstat -- a future or planned piece of vaporware that
will someday come to fruition -- a nice, fully featured GUI based on
Gtk/Gnome for monitoring a cluster or LAN. Since it doesn't exist I can
be lavish with features such as a "panel of lights" display that lets
you see the state of a huge cluster at a glance on a high-res display,
settable alarms and an alarm messaging system, a remote shell interface
that lets you select blocks of nodes or clients by means of a mouse or
hostname glob and then run shell commands on all the selected clients at
one time, an integrated batch job scheduler with the ability to
implement SIMPLE policy schemes, and eating your meatloaf for you. With
catsup. Seriously, all of that and more is possible, it just needs the
work.
- wulfwebd -- a future or planned aggregator daemon. This is
a daemon that is basically a stripped wulflogger on one side -- goes and
connects to an entire cluster and manages all connections for you. It
polls the connected clients, collects their raw xmlsysd results, and
spits them out on a SINGLE port offered on the daemon side. This daemon
(will) exists only to make it possible to drill a hole through a
firewall to a single host and retrieve all the information on a cluster
or LAN inside. Or, alternatively, within multiple VPNs across IP domain
boundaries and so on if you want to do this securely. So you can sit in
Boston and monitor your departmental LAN and your research cluster all
at the same time right through firewalls in between from a single e.g.
wulfstat or gwulfstat session. This will require changes to the libwulf
API to support an aggregated connection, probably to a different default
port number or connection type via an extension of the cluster defining
xml.
Submit bug reports, etc. to
rgb at phy dot duke dot edu
|
Contents
|