Portable Applications

Portable Apps at http://portableapps.com/blogs

Removing jaymyka Worm

Worm: Jaymyka
Threat Level: Low

Description:

It creates an autorun.inf file per drive with the following contents,

[autorun]
open=jay.exe
;shell\open=Open(&O)
shell\open\Command=jay.exe
shell\open\Default=1
;shell\explore=Manager(&X)
shell\explore\Command=jay.exe

The autorun.inf file is paired with jay.exe. The jay.exe file handles the annoying duplication of files and some resource-hogging tasks leading to DoS attack. If this worm is able to infect the target device successfully, it attaches a file named mveo.exe at startup. This mveo.exe is responsible for the worm’s capability of regeneration.

How To Remove:

1. Kill mveo.exe and jay.exe

TASKKILL /F /IM mveo.exe /IM jay.exe

2. Delete all files named jay.exe and mveo.exe
3. Remove mveo.exe in msconfig’s startup tab
4. Clean the registry of entries containing jay.exe, jaymyka, mveo.exe
5. Reboot

Credit is due to the author of this blog site: http://eradicus.blogsome.com/2007/11/30/removing-jaymyka-worm/

the Freeware Noob.Killer by Leerz can handle JAYMYKA.

http://images.ocxt.multiply.com/image/1/photos/upload/300×300/R61DUwoKCCgAAAQUyQY1/nooblatest.jpg?et=QpT0NaOsEWay4SSRAyjjMQ&nmid=

#Update Feb 09 2008 [Noob.Killer 3.5.215]
Added Jaymyka.wen9.com Fix

you can get Noob.Killer here:
http://leerz25.sitesled.com/
http://convergenceforums.net/e107_plugins/forum/forum_viewtopic.php?11735
http://ocxt.multiply.com/journal/item/125

Paesseler Site Inspector

Site Inspector (http://www.paessler.com/tools/psi) is a Web browser that combines the two most frequently used browser engines (Internet Explorer and Mozilla/Gecko) into one program. Its advanced web page analysis features make it the perfect companion for webmasters and web developers.

With Site Inspector’s very own browser, the Analyzing Browser, users can switch between the two browser engines with just one mouse click, e.g., to compare the rendering of a page in both browsers. The sophisticated web page analysis functions – which also integrate into Internet Explorer and Firefox – make analyzing and debugging web sites easy.

Cacti ,RRDTool, and jEdit

Cacti (http://www.cacti.net/index.php) is a complete network graphing solution designed to harness the power of RRDTool’s data storage and graphing functionality. Cacti provides a fast poller, advanced graph templating, multiple data acquisition methods, and user management features out of the box. All of this is wrapped in an intuitive, easy to use interface that makes sense for LAN-sized installations up to complex networks with hundreds of devices.

RRDtool (http://oss.oetiker.ch/rrdtool/) is the OpenSource industry standard, high performance data logging and graphing system for time series data. Use it to write your custom monitoring shell scripts or create whole applications using its Perl, Python, Ruby, TCL or PHP bindings.

jEdit (http://www.jedit.org/) is a mature programmer’s text editor with hundreds (counting the time developing plugins) of person-years of development behind it.

Collection of Freeware Tools

NirSoft (http://www.nirsoft.net/) web site provides a unique collection of small and useful freeware utilities, all of them developed by Nir Sofer.

TechGuruLive – A Big Help

I encountered this website and I found it very helpful and informative. (http://techgurulive.com/2008/09/22/how-to-do-mac-address-packet-filtering-using-iptables/). The following is a sample articel:

How to do MAC address packet filtering using IPTables

Media Access Control address (MAC address) or Ethernet Hardware Address (EHA) or hardware address or adapter address is a quasi-unique identifier attached to most network adapters (NICs). It is a number that acts like a name for a particular network adapter, so, for example, the network cards (or built-in network adapters) in two different computers will have different names, or MAC addresses, as would an Ethernet adapter and a wireless adapter in the same computer, and as would multiple network cards in a router. However, it is possible to change the MAC address on most of today’s hardware.

There are situations from our local network that requires control and management of packets going IN and OUT of your proxy interfaces coming and requested usually by internal hosts. Proxy servers are usually configurable linux gateway machines serving internal or client host as their front-end host from the web.

Implementing IP-based policies and access list restrictions from linux-based firewall is one of the many approaches to resolve and filter host based from MAC address. This situation can also be resolved by implememting a MAC address filters from the router level, or from firewall appliances, first hop bandwidth monitoring appliances, VLAN switches, other proxy software packages like Squid, other linux-based firewalls like IPCop and a lot of them from opensource list.

Considering the costly fees from acquiring these not so cheap appliances and routers, we can make use of iptables out of an existing proxy server or proxy gateway to filter out host based on their MAC address. In short, do MAC address packet filtering using iptables of an existing proxy linux box.

Iptables man says:
Iptables is used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel. Several different tables may be defined. Each table contains a number of built-in chains and may also contain user-defined chains.

Linux IPtables is currently the default firewall package that comes from RedHat, CentOS and Fedora, right after ipchains dominated them long time ago. Iptables supports different types of filters. To name a few, iptables can do filters and firewall rules by usernames, by group IDs and user profiles, by source and destination ports, by source host and destination hosts, by URLs, by IP addresses, by packet ID flags, by protocols, and a lot more including filtering by MAC address.

This entry assumes that an existing proxy server is currently in place inside your network and you want to filter linux/windows client machines behind the proxy server using MAC address packet filtering by iptables.

Here’s an entry on how to filter out MAC address using Linux IPTable firewall.

IPTABLES INSTALLATION
=====================

# yum -y install iptables

IPTABLES FIREWALL PACKAGE VERIFICATION
======================================

# rpm -qa iptables

IPTABLES MAC ADDRESS FILTERING
==============================

Here’s an iptables sample lines to filter out host based on MAC address using the currently in place proxy server or linux proxy gateway. Make sure you insert them from one of your existing iptables INPUT chains like so

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# iptables -A INPUT -m mac –mac-source 00:02:A5:EC:00:8B -j DROP

Alternatively,

# -A RH-Firewall-1-INPUT -m mac –mac-source 00:02:A5:EC:00:8B -j DROP

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The command above would block a host with MAC Address 00:02:A5:EC:00:8B regardless of current IP address and packet/port source and destinations.

Extending MAC Address Filters via Iptables
==========================================

If you want to allow port 80 for a host with MAC address 00:02:A5:EC:00:8B , simply insert this line to your existing /etc/sysconfig/iptables firewall rules right after your INPUT chain

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# iptables -A INPUT -p tcp –destination-port 80 -m mac –mac-source 00:02:A5:EC:00:8B -j ACCEPT

Alternatively,

# -A RH-Firewall-1-INPUT -p tcp –destination-port 80 -m mac –mac-source 00:02:A5:EC:00:8B -j ACCEPT

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Iptables is one powerful linux packet filtering firewall specially when properly tweaked and modified to fit your needs. If you wish to know more of iptables, read the man page. Further iptables reading can be found here.

Java Tutorial

Java tutorial link: http://java.sun.com/docs/books/tutorial/getStarted/

Updating access.db of Sendmail

1. Modify (add or delete domains or ip address) “access.db” of sendmail, edit the “access” file.
2. Update by issuing the command:

root@server mail]# makemap hash /etc/mail/access.db < /etc/mail/access

That’s it.

Smoothwall Squid Configuration

This Smoothwall Squid Configuration has been fetched from http://martybugs.net/smoothwall/squid.cgi and is being posted here for my convenience. All rights is being retained by the original author.

===============================================================

Configuring Squid

[This modification has been verified to work with Smoothwall Express 2.0.]

This page describes how to filter web traffic using Squid ACLs, and also covers various other Squid configuration elements. Squid is the web proxy software used on Smoothwall.

Requirements:
You’ll need:

* A Smoothwall Express 2.0 installation (obviously…).
* A way of getting a command-line prompt on your Smoothwall box (either by logging directly onto your Smoothwall box, using a SSH client such as PuTTY or SSH Secure Shell, or via the Smoothwall web interface).

A Web Proxy?
Squid is the most popular web proxy software available, and Smoothwall comes with Squid pre-installed.

There are a number of reasons why you might want to use a web proxy:

Cache Web Page Content:
The primary purpose of a web proxy is to cache web content locally. This provides a number of benefits, including faster web browsing, and less bandwidth usage.
Whether you’re using a dialup account or a fast ADSL account, reducing the amount of data that needs to be retrieved from the source webserver will provide you with a faster web browsing experience. This is particularly true if multiple users on your green network visit the same pages, or if you frequent a web-based forum or bulletin board, as all images will be cached by the proxy server.

Restrict Web Page Access:
If PCs on your green network are configured to use the web proxy, you can restrict access to specified sites, only allow access to specified sites, restrict PCs to only have web access during specified time periods, etc.

Block Advertisements:
If all web traffic is going through the web proxy, you can block advertisements that are displayed on web pages. For more information on doing this, see my page on Ad Zapping with Squid.
Blocking webpage advertisements can also provide additional benefits on slower internet connections, as the volume of data is reduced, due to the advertisements not being loaded from the originating webserver.
Update multiple PCs from Microsoft’s Windows Update site through a web proxy also means the patches are only downloaded once, and cached locally by the web proxy.

Monitor Web Sites Being Visited:
All web pages that are accessed through the web proxy are logged to the Squid access log. You can then use this data to monitor exactly which users are visiting which sites. See my Web Proxy Log Analysis Reports for more information on generating reports from the Squid access log.

Log Timestamp Correction:
The timestamps in the Squid access log on Smoothwall Express 2.0 are in GMT format.
This is because the strict access permissions on the /var/smoothwall/ directory prevent Squid from reading the timezone information.

To correct this, and get Smoothwall’s Squid access log using the local time for all timestamps, execute the following from a command prompt on your Smoothwall:

chmod 701 /var/smoothwall/
/usr/local/bin/restartsquid

This will adjust the permissions on the /var/smoothwall/, and restart the web proxy to make the change take effect.

Using Smoothwall’s Web Proxy:
Smoothwall’s web proxy can be configured to run in transparent mode, or in non-transparent mode.

In transparent mode, all web traffic going through Smoothwall will automatically be redirected to go through the proxy, without requiring any proxy configuration in the web browsers on the PCs on your green network.
This effectively forces all web browsing from PCs on your green network to go through Smoothwall’s web proxy.

In non-transparent mode, all web browsers on your green network must be configured to use Smoothwall’s green IP address on port 800 as a web proxy.

If you want to use Smoothwall’s web proxy as a way of blocking some websites and/or some users, you should run the web proxy in transparent mode, to ensure users are not bypassing the proxy.

Any user who is blocked by any ACLs which you configure will see a Squid error page, indicating that their web access is being blocked by Smoothwall.

the default access denied page

Editing the Config File:
Smoothwall’s Squid configuration is stored in /var/smoothwall/proxy/squid.conf.
However, you should never edit this file directly, as it’s re-written each time changes are made to the web proxy configuration, or the proxy is restarted through the web interface.

Instead, you should always add your new configuration to /var/smoothwall/proxy/acl.

Applying Your Changes:
Any changes made to this file will take effect when you restart the web proxy through Smoothwall’s web interface. This will cause Smoothwall to re-write /var/smoothwall/proxy/squid.conf, and include the contents of /var/smoothwall/proxy/acl.

As with any modifications to your Smoothwall, make a backup copy of this file before making any changes to it, so you can easily revert back to a known working version.

Only Allow Specific PCs:
If you only want to allow some PCs to use Smoothwall’s web proxy, you can add one or more ACLs to limit this access.

Edit /var/smoothwall/proxy/acl, and before the line containing

http_access deny all

insert the following lines:

acl ok_users src 192.168.0.2
acl ok_users src 192.168.0.3
http_access allow ok_users

and add another acl line for each PC you want to allow.
You’ll also need to comment out the following line (it’s the second last line):

http_access allow localnet

by inserting a # character at the beginning of the line.

Restart the web proxy through Smoothwall’s web interface (by clicking the “Save” button) to make your changes take effect.

Block Specific Sites:
To block access to specific websites, edit /var/smoothwall/proxy/acl, and just before the line containing

http_access allow localnet

insert the following lines:

acl blocked_sites url_regex www.xxx.com
acl blocked_sites url_regex www.yyy.com
acl blocked_sites url_regex www.zzz.com
http_access deny blocked_sites

Restart the web proxy through Smoothwall’s web interface (by clicking the “Save” button) to make your changes take effect.

Note that if you have a longer list of sites you want to block, it may be easier to list the websites in a text file, and then just reference the text file in the Squid configuration file.

Assuming you have created a text file called /var/smoothwall/proxy/badsites.txt, containing a single URL on each line, use the following in /var/smoothwall/proxy/acl:

acl blocked_sites url_regex “/var/smoothwall/proxy/badsites.txt”
http_access deny blocked_sites

If you make any changes to the contents of /var/smoothwall/proxy/badsites.txt, you’ll need to restart the web proxy to make your changes take effect.

Time Restrictions:
You can also use Squid ACLs to restrict web browsing to specific times.

To allow a specific PC on your green network to only access the web during lunchtime on weekdays, edit /var/smoothwall/proxy/acl, and immediately before the line containing

http_access allow localnet

insert the following:

acl clients src 192.168.0.3
acl lunchtime time MTWHF 12:00-13:00
http_access allow clients lunchtime
http_access deny clients

where the following day abbreviations can be used:
S Sunday
M Monday
T Tuesday
W Wednesday
H Thrusday
F Friday
A Saturday

Note that all times need to be in GMT, as Smoothwall’s Squid is configured to only use GMT (all logs are timestamped with GMT times too).

Restart the web proxy through Smoothwall’s web interface (by clicking the “Save” button) to make your changes take effect.

Allow Another Network:
If you have another subnet behind your Smoothwall (ie, behind a router on the green network or similar), by default, this subnet will not be able to use Smoothwall’s web proxy, but will receive an error message saying the requested URL cannot be retrieved from the cache due to access control configuration.

Assuming you already have a static route in place to allow the other network to communicate with Smoothwall, edit /var/smoothwall/proxy/acl, and just before the line containing

http_access allow localnet

insert the following line:

acl localnet src 192.168.2.0/255.255.255.0

and replace the network address and subnet mask with that of your other subnet.

Smoothwall already has an acl for localnet, allowing the green network, so here we’re adding another subnet to the acl which defines the networks allowed access to the proxy.

Restart the web proxy through Smoothwall’s web interface (by clicking the “Save” button) to make your changes take effect.

Customising Error Pages:
If you’re blocking access to some websites and/or some users, you may want to customise the error messages displayed by Squid, to provide more meaningful messages to your users.

All of the Squid error pages are in /var/squid/smootherrors/, so just identify the error page you want to modify, modify it as required, and restart the web proxy through Smoothwall’s web interface to make your changes take effect.

For example, the error page displayed when attempting to access a page that has been blocked by ACLs is /var/squid/smootherrors/ERR_ACCESS_DENIED

New Error Pages:
You can also define new error pages for specific ACLs, using the deny_info option.

For example, to display a new error page for the time-restricted user, create a new error page in the following location:

/var/squid/smootherrors/ERR_TIMERESTRICT

containing the error message you want to display to the user when they are denied access.

Then edit /var/smoothwall/proxy/acl, and immediately before the line containing

http_access allow localnet

insert the following:

acl clients src 192.168.0.3
acl lunchtime time MTWHF 12:00-13:00
deny_info ERR_TIMERESTRICT clients
http_access allow clients lunchtime
http_access deny clients

This will cause your new error page to be displayed whenever the specified PC attempts to access the web outside of the allowed time period.

The deny_info option can be used in a similar way with any other ACLs.

Restart the web proxy through Smoothwall’s web interface (by clicking the “Save” button) to make your changes take effect.

Change The Cache Administrator Email:
Most of the Squid error pages report include a message mentioning the cache administrator. However, this message includes a non-existing and invalid email address of just webmaster.

It’s easy to include a valid cache administrator email address on these error pages. To do so, add a line containing the following to the end of /var/smoothwall/proxy/acl:

cache_mgr email@host.com

replacing email@host.com with a valid email address of course!

Restart the web proxy through Smoothwall’s web interface (by clicking the “Save” button) to make your changes take effect.

Gandalf! Monitor Your Machines with Hobbit

I came across with this article in Linux Magazine. It is very useful for monitoring Linux machines. Although I have not implemented this by now, I will be doing it sooner. I copied this article for my convenience. Here it goes….

---

Gandalf! Monitor Your Machines with Hobbit

Not quite a ring of power, but Hobbit can take some of the pain out of machine, network and services management.
Juliet Kemp
Thursday, June 5th, 2008

Hobbit is a tool for monitoring servers, applications, and networks, inspired by and compatible with Big Brother, but with the advantage of being open source and under active development. You install Hobbit on a central server, and a client for Hobbit on all the machines you want to monitor.

The central server collects information about the status of your computers and the applications on them, and displays it via an automatically updating Web page. You can also set up email (or text message) alerts for particular situations.

It can monitor various services (SSH, FTP, HTTP…), connectivity, disk space, CPU usage, Web sites, and a variety of other aspects of your machines and network. It’s very configurable, extendable, easy to use, and can handle large numbers of machines.

In this column, I’ll provide a quick overview of how to set it up, configure it, and use alerts.

Setup

First, identify the machine you wish to use as a central server — here I use hobbitserver.example.com. You’ll need to install a basic Apache setup (or have one already available). Hobbit is available as a Debian package for Debian or Ubuntu, or as an RPM Fedora Core 5, so should be very straightforward to install. (Or you can of course install from source if you prefer.)

All packages are available from the project’s SourceForge page, or possibly via your distribution’s repositories.

Basic configuration

For the most basic setup (monitoring only itself), you only need to edit a single file, /etc/hobbit/bb-hosts, and update the Web server.

First, check that bb-hosts includes this line:

127.0.0.1 localhost # bbd http://localhost/ conn

Secondly, you’ll find instructions on how to set up Apache in /etc/hobbit/hobbit-apache.conf. Add the configuration as directed in this file, and reload your Web server.

Now restart the server (/etc/init.d/hobbit restart). Wait for a few seconds — maybe as much as a minute — and then go to the Webpage at http://localhost/hobbit/ or http://hobbitserver.example.com/hobbit/ and you should see the single line entry for localhost. It should show the Hobbit server running OK, and will also have information about disk usage, CPU usage, and connection, among other things.

There are several possible statuses. Green means that status is OK; yellow is a warning; red means critical. Clear means that there is no data, purple that there is no report. Blue means that the monitoring aspect is disabled.

Next, try a test client. Install the Hobbit client software (see the sourceforge page for packages) on the test client. Next add your test client machine to the configuration, by editing the file /etc/hobbit/bb-hosts on the hobbit server again, and adding a similar line to the localhost one, but with the appropriate IP address and machine name.

You shouldn’t need to restart hobbit on the server, although obviously you will need to make sure that it is running on the client. Again, wait for a minute or so, then refresh the Web page, and the client will appear.

More Advanced Configuration

Using Hobbit, you can choose what services you check. For example, if your client webserver.example.com is running a Web site at http://www.example.com, you can add that to the services to check by editing the relevant line in the bb-hosts configuration file as follows:

192.0.2.25 webserver # conn http://www.example.com

You can list as many sites as you like, separated by a space. You can also monitor SSH and NFS:

192.0.2.30 nfsserver # conn ssh rpc=mount,nlockmgr,nfs

And various other services, including FTP, Telnet, SMTP, POP3, IMAP, spamd, and SSL-enabled services. You’ll find a full list on the Hobbit Web site. You can monitor any of these services by simply adding them to the relevant client line in bb-hosts on the server running Hobbit.

Specifying danger levels

You can specify the boundaries for alerts — what is defined as “warn” (yellow) or “panic” (red) — for individual machines, or change the defaults. You do this by editing /etc/hobbit/hobbit-clients.cfg. Here’s a sample:

HOST=client1
DISK /data IGNORE

DEFAULT
UP 1h
LOAD 5.0 10.0
DISK / 90 95
DISK %^/local.* 99 99.5
MEMPHYS 100 101
MEMSWAP 50 80
MEMACT 90 97
LOG %.* %WARNING %COLOR=yellow

Note that the default section must be the last one in the config file. The first section tells hobbit to ignore a particular disk — /data1 on client1. (Perhaps this data disk is known to be full and we don’t care about it.)

The next section sets various defaults:

* UP: sets “warn” status if the system has been up for less than 1 hour. If you add a second number, it will set “warn” status if the system has been up for longer than that.
* LOAD: warn if CPU usage is above 5.0, panic if it is above 10.0.
* DISK: specify a regular expression for the disk name, noting that any such regexp must begin with %. Again, panic and warn levels are set (for percentage disk use).
* The various memory options are taken from proc.
* LOG: The indicator will go yellow if a line in any log file contains WARNING.

You can alter these as you prefer. You’ll see a handful of other options, documentation of which is at the top of the hobbit-clients.cfg file.

Logfile Monitoring

To monitor logfiles, you need both the section in hobbit-clients.cfg, as above, and a section in /etc/hobbit/client-local.cfg (on the Hobbit server). The clients will pick up the configuration corresponding to their hostname or operating system from client-local.cfg when they connect to the server.

The default for Linux clients is just to check /var/log/messages, and to ignore lines beginning with MARK. You may also want to add /var/log/syslog, and to ignore cronjob lines in that (cronjobs should email you if they go wrong, and there are often a great many cron lines in syslog!). The following section of client-local.cfg should do this:

[linux]
log:/var/log/messages:10240
ignore MARK
log:/var/log/syslog:10240
ignore MARK
ignore /USR/SBIN/CRON

The number at the end of the line is a maximum number of bytes that the client will send — it also only sends the last 30 minutes’ worth of data, so this is a suitable upper bound.

Email and Other Alerts

One of the most useful things about Hobbit is that you can configure it to send you email alerts in certain circumstances. To do this, you edit the /etc/hobbit/hobbit-alerts.cfg configuration file.

There are numerous available options to configure your alerts. For example, the following setup would email you if any machine (again, the regular expression must start with %) had been unavailable for 30 minutes (DURATION), would then repeat every 24 hours (1400 minutes) thereafter, and would email you on recovery (RECOVERED):

HOST=%.* SERVICE=conn
MAIL admin@example.com DURATION>30 REPEAT=1440 RECOVERED

You can also set more than one alert. For example, you might want to email a different address (your own home address, or the on-call address), if the service went down out of hours:

HOST=%.* SERVICE=ssh
MAIL admin@example.com DURATION>30 REPEAT=1440 RECOVERED
MAIL admin@home.com DURATION>30 REPEAT=1440 RECOVERED TIME=*:1800:0800

Or for a particular host, there may be different people to mail in different situations, in which case the SERVICE can be specified in the MAIL line:

HOST=webserver.example.com
MAIL admin@example.com SERVICE=disk,ssh DURATION>30 REPEAT=1h RECOVERED
MAIL webmaster@example.com SERVICE=http DURATION>30 REPEAT=1h RECOVERED

Here the repeat would be every hour. You can also use the SCRIPT keyword instead of MAIL, to run a particular script if there is a problem. For example, if monitoring an email service, sending an email in case of problems might not make a lot of sense! Hobbit provides various environment variables which will be passed to the script — see the documentation for further information.

This file will also utilize variables. So you can set up a default alert setting, and then specify that using that variable thereafter. To do this using the first example above:

$MAILADMIN=MAIL admin@example.com REPEAT=1440 RECOVERED

HOST=%.* SERVICE=conn
$MAILADMIN

Finally, you can exclude particular machines if you want. For example if you have a Windows machine that isn’t running ssh, you can avoid being warned that this is the case:

HOST=%.* SERVICE=ssh
IGNORE HOST=windows1
$MAILADMIN

The IGNORE keyword stops processing that section altogether at the point where it appears — so it must occur before any alerts to work properly.

Conclusion

Hobbit makes monitoring your services and network much more straightforward, and is a more manageable solution than the clutch of homebrew scripts that many sysadmins employ! In particular, the configurability of the alert system is excellent and makes it much easier to react in a timely fashion when problems occur. Given how easy it is to get running, it’s well worth taking the time to experiment with it.
Juliet Kemp has been playing with Linux systems for around 6 years now, after discovering that it was an excellent way to avoid Finals revision. She is currently sysadmin for the Astrophysics group at Imperial College, in London (UK), and is responsible for wrangling a Linux+Solaris network and its users.