hobbitlaunch(8) [debian man page]
HOBBITLAUNCH(8) System Manager's Manual HOBBITLAUNCH(8) NAME
hobbitlaunch - Master program to launch other Xymon programs SYNOPSIS
hobbitlaunch [options] DESCRIPTION
hobbitlaunch(8) is the main program that controls the execution and scheduling of all of the components in the Xymon system. hobbitlaunch allows the administrator to add, remove or change the set of Xymon applications and extensions without restarting Xymon - hob- bitlaunch will automatically notice any changes in the set of tasks, and change the scheduling of activities accordingly. hobbitlaunch also allows the administrator to setup specific logfiles for each component of the Xymon system, instead of getting output from all components logged to a single file. OPTIONS
--env=FILENAME Loads the environment from FILENAME before starting other tools. The environment defined by FILENAME is the default, it can be overridden by the ENVFILE option in hobbitlaunch.cfg(5) --config=FILENAME This option defines the file that hobbitlaunch scans for tasks it must launch. A description of this file is in hobbitlaunch.cfg(5) The default tasklist is /etc/hobbitlaunch.cfg --log=FILENAME Defines the logfile where hobbitlaunch logs information about failures to launch tasks and other data about the operation of hobbit- launch. Logs from individual tasks are defined in the hobbitlaunch.cfg file. By default this is logged to stdout. --pidfile=FILENAME Filename which hobbitlaunch saves its own process-ID to. Commonly used by automated start/stop scripts. --verbose Logs the launch of all tasks to the logfile. Note that the logfile may become quite large if you enable this. --dump Just dump the contents of the hobbitlaunch.cfg file after parsing it. Used for debugging. --debug Enable debugging output while running. --no-daemon hobbitlaunch normally detaches from the controlling tty and runs as a background task. This option keeps it running in the fore- ground. STARTING TASKS
hobbitlaunch will read the configuration file and start all of the tasks listed there. If a task completes abnormally (i.e. terminated by a signal or with a non-zero exit status), then hobbitlaunch will attempt to restart it 5 times. If it still will not run, then the task is disabled for 10 minutes. This will be logged to the hobbitlaunch logfile. If the configuration file changes, hobbitlaunch will re-read it and notice any changes. If a running task was removed from the configura- tion, then the task is stopped. If a new task was added, it will be started. If the command used for a task changed, or it was given a new environment definition file, or the logfile was changed, then the task is stopped and restarted with the new definition. SEE ALSO
hobbitlaunch.cfg(5), xymon(7) Xymon Version 4.2.3: 4 Feb 2009 HOBBITLAUNCH(8)
Check Out this Related Man Page
HOBBITD(8) System Manager's Manual HOBBITD(8) NAME
hobbitd - Master network daemon for a Xymon server SYNOPSIS
hobbitd [options] DESCRIPTION
hobbitd is the core daemon in the Xymon Monitor. It is designed to handle monitoring of a large number of hosts, with a strong focus on being a high-speed, low-overhead implementation of a Big Brother compatible server. To achieve this, hobbitd stores all information about the state of the monitored systems in memory, instead of storing it in the host filesystem. A number of plug-ins can be enabled to enhance the basic operation; e.g. a set of plugins are provided to implement persistent storage in a way that is compatible with the Big Brother daemon. However, even with these plugins enabled, hobbitd still performs much faster than the standard bbd daemon. hobbitd is normally started and controlled by the hobbitlaunch(8) tool, and the command used to invoke hobbitd should therefore be in the hobbitlaunch.cfg file. OPTIONS
--bbhosts=FILENAME Specifies the path to the Xymon bb-hosts file. This is used to check if incoming status messages refer to known hosts; depending on the "--ghosts" option, messages for unknown hosts may be dropped. If this option is omitted, the default path used is set by the BBHOSTS environment variable. --checkpoint-file=FILENAME With regular intervals, hobbitd will dump all of its internal state to this check-point file. It is also dumped when hobbitd termi- nates, or when it receives a SIGUSR1 signal. --checkpoint-interval=N Specifies the interval (in seconds) between dumps to the check-point file. The default is 900 seconds (15 minutes). --restart=FILENAME Specifies an existing file containing a previously generated hobbitd checkpoint. When starting up, hobbitd will restore its internal state from the information in this file. You can use the same filename for "--checkpoint-file" and "--restart". --ghosts={allow|drop|log} How to handle status messages from unknown hosts. The "allow" setting accepts all status messages, regardless of whether the host is known in the bb-hosts file or not. "drop" silently ignores reports from unknown hosts. "log" works like drop, but logs the event in the hobbitd output file. The default is "allow", unless the BBGHOSTS environment variable is set. --no-purple Prevent status messages from going purple when they are no longer valid. Unlike the standard bbd daemon, purple-handling is done by hobbitd. --listen=IP[:PORT] Specifies the IP-address and port where hobbitd will listen for incoming connections. By default, hobbitd listens on IP 0.0.0.0 (i.e. all IP- adresses available on the host) and port 1984. --daemon hobbitd is normally started by hobbitlaunch(8) it will then detach from the terminal and continue running as a background task. --timeout=N Set the timeout used for incoming connections. If a status has not been received more than N seconds after the connection was accepted, then the connection is dropped and any status message is discarded. Default: 10 seconds. --env=FILENAME Loads the content of FILENAME as environment settings before starting hobbitd. This is mostly used when running as a stand-alone daemon; if hobbitd is started by hobbitlaunch, the environment settings are controlled by the hobbitlaunch hobbitlaunch.cfg file. --pidfile=FILENAME hobbitd writes the process-ID it is running with to this file. This is for use in automated startup scripts. The default file is $BBSERVERLOGS/hobbitd.pid. --log=FILENAME Redirect all output from hobbitd to FILENAME. --store-clientlogs[=[!]COLUMN] Determines which status columns can cause a client message to be broadcast to the CLICHG channel. By default, no client messages are pushed to the CLICHG channel. If this option is specified with no parameter list, all status columns that go into an alert state will trigger the client data to be sent to the CLICHG channel. If a paramater list is added to this option, only those status col- umns listed in the list will cause the client data to be sent to the CLICHG channel. Several column names can be listed, separated by commas. If all columns are given as "!COLUMNNAME", then all status columns except those listed will cause the client data to be sent. --status-senders=IP[/MASK][,IP/MASK] Controls which hosts may send "status", "combo", "config" and "query" commands to hobbitd. By default, any host can send status-updates. If this option is used, then status-updates are accepted only if they are sent by one of the IP-adresses listed here, or if they are sent from the IP-address of the host that the updates pertains to (this is to allow Xymon clients to send in their own status updates, without having to list all clients here). So typically you will need to list your BBNET servers here. The format of this option is a list of IP-adresses, optionally with a network mask in the form of the number of bits. E.g. if you want to accept status-updates from the host 172.16.10.2, you would use --status-senders=172.16.10.2 whereas if you want to accept status updates from both 172.16.10.2 and from all of the hosts on the 10.0.2.* network (a 24-bit IP network), you would use --status-senders=172.16.10.2,10.0.2.0/24 --maint-senders=IP[/MASK][,IP/MASK] Controls which hosts may send maintenance commands to hobbitd. Maintenance commands are the "enable", "disable", "ack" and "notes" commands. Format of this option is as for the --status-senders option. It is strongly recommended that you use this to restrict access to these commands, so that monitoring of a host cannot be disabled by a rogue user - e.g. to hide a system compromise from the monitoring system. Note: If messages are sent through a proxy, the IP-address restrictions are of little use, since the messages will appear to origi- nate from the proxy server address. It is therefore strongly recommended that you do NOT include the address of a server running bbproxy in the list of allowed addresses. --www-senders=IP[/MASK][,IP/MASK] Controls which hosts may send commands to retrieve the state of hobbitd. These are the "hobbitdlog", "hobbitdboard" and "hobbit- dxboard" commands, which are used by bbgen(1) and bbcombotest(1) to retrieve the state of the Xymon system so they can generate the Xymon webpages. Note: If messages are sent through a proxy, the IP-address restrictions are of little use, since the messages will appear to origi- nate from the proxy server address. It is therefore strongly recommended that you do NOT include the address of a server running bbproxy in the list of allowed addresses. --admin-senders=IP[/MASK][,IP/MASK] Controls which hosts may send administrative commands to hobbitd. These commands are the "drop" and "rename" commands. Access to these should be restricted, since they provide an un-authenticated means of completely disabling monitoring of a host, and can be used to remove all traces of e.g. a system compromise from the Xymon monitor. Note: If messages are sent through a proxy, the IP-address restrictions are of little use, since the messages will appear to origi- nate from the proxy server address. It is therefore strongly recommended that you do NOT include the address of a server running bbproxy in the list of allowed addresses. --no-download Disable the "download" and "config" commands which can be used by clients to pull files from the Xymon server. The use of these may be seen as a security risk since they allow file downloads. --debug Enable debugging output. --dbghost=HOSTNAME For troubleshooting problems with a specific host, it may be useful to track the exact communications from a single host. This option causes hobbitd to dump all traffic from a single host to the file "/tmp/hobbitd.dbg". HOW ALERTS TRIGGER
When a status arrives, hobbitd matches the old and new color against the "alert" colors (from the "ALERTCOLORS" setting) and the "OK" col- ors (from the "OKCOLORS" setting). The old and new color falls into one of three categories: OK: The color is one of the "OK" colors (e.g. "green"). ALERT: The color is one of the "alert" colors (e.g. "red"). UNDECIDED: The color is neither an "alert" color nor an "OK" color (e.g. "yellow"). If the new status shows an ALERT state, then a message to the hobbitd_alert(8) module is triggered. This may be a repeat of a previous alert, but hobbitd_alert(8) will handle that internally, and only send alert messages with the interval configured in hobbit-alerts.cfg(5). If the status goes from a not-OK state (ALERT or UNDECIDED) to OK, and there is a record of having been in a ALERT state previously, then a recovery message is triggered. The use of the OK, ALERT and UNDECIDED states make it possible to avoid being flooded with alerts when a status flip-flops between e.g yel- low and red, or green and yellow. CHANNELS
A lot of functionality in the Xymon server is delegated to "worker modules" that are fed various events from hobbitd via a "channel". Pro- grams access a channel using IPC mechanisms - specifically, shared memory and semaphores - or by using an instance of the hobbitd_chan- nel(8) intermediate program. hobbitd_channel enables access to a channel via a simple file I/O interface. A skeleton program for hooking into a hobbitd channel is provided as part of Xymon in the hobbitd_sample(8) program. The following channels are provided by hobbitd: status This channel is fed the contents of all incoming "status" and "summary" messages. stachg This channel is fed information about tests that change status, i.e. the color of the status-log changes. page This channel is fed information about tests where the color changes between an alert color and a non-alert color. It also receives information about "ack" messages. data This channel is fed information about all "data" messages. notes This channel is fed information about all "notes" messages. enadis This channel is fed information about hosts or tests that are being disabled or enabled. client This channel is fed the contents of the client messages sent by Xymon clients installed on the monitored servers. clichg This channel is fed the contents of a host client messages, whenever a status for that host goes red, yellow or purple. Information about the data stream passed on these channels is in the Xymon source-tree, see the "hobbitd/new-daemon.txt" file. SIGNALS
SIGHUP Re-read the bb-hosts configuration file. SIGUSR1 Force an immediate dump of the checkpoint file. BUGS
Timeout of incoming connections are not strictly enforced. The check for a timeout only triggers during the normal network handling loop, so a connection that should timeout after N seconds may persist until some activity happens on another (unrelated) connection. FILES
If ghost-handling is enabled via the "--ghosts" option, the bb-hosts file is read to determine the names of all known hosts. SEE ALSO
xymon(7), hobbitserver.cfg(5). Xymon Version 4.2.3: 4 Feb 2009 HOBBITD(8)