I found this howto for installing Nagios on Linode and thought I'd share it after using it to successfully install and configure Nagios.

Author: Amanda Folson
Published: May 26, 2010

Nagios is a flexible monitoring system framework that makes it possible to maintain consistent monitoring of a broad range of infrastructural components. Many users use Nagios to monitor a broad range of network services over protocols that include SMTP and POP3 (email), HTTP (web), ICMP (ping), and SSH. In addition to simple uptime monitoring, Nagios also contains features for advanced notification and graphing as well as an extensible plugin architecture that allows users to develop simple plugins for accessing unique monitoring information and providing customized reports.
Before beginning this document, we assume that you have followed our getting started guide and LAMP Guide to achieve a fully functional LAMP stack on your Linode. If you're new to Linux system administration, you may also want to consider the administration basics article in our using linux series.
These instructions work with the Linode platform. If you don't have a Linode yet, sign up for a Linux VPS and get started today.

Prepare for Nagios Installation

Ensure that your system's package repository and installed packages are up to date by issuing the following commands:
apt-get update
apt-get upgrade
Install Dependencies
Before we can begin installing Nagios, we must first install several prerequisites. Issue the following command:
apt-get install build-essential php5-gd wget libgd2-xpm libgd2-xpm-dev
Create Users and Groups
Create a new system user account to run Nagios under. Issue the following commands:
adduser --system --no-create-home --disabled-login --group nagios
groupadd nagcmd
usermod -G nagcmd nagios
usermod -a -G nagcmd www-data
Now we're ready to continue with the installation of Nagios itself.
Install Nagios
Download Nagios Software
Begin by downloading the latest version of the Nagios Core. At the time of writing the latest version of Nagios is 3.2.1, but be sure that you are downloading the latest version by checking the Nagios download page. Issue the following command:
cd /opt/
wget http://prdownloads.sourceforge.net/sourceforge/nagios/nagios-3.2.1.tar.gz
Next, download the official plugin package for Nagios. At the time of writing this is version 1.4.14, but check the Nagios plugin download page to ensure that this remains the latest version. Issue the following commands:
cd /opt/
wget http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins...
Build and Install Nagios Core
Issue the following command to extract, compile and install the Nagios Core software:
tar -xzvf /opt/nagios-3.2.1.tar.gz
cd /opt/nagios-3.2.1
./configure --with-command-group=nagcmd

make all
make install
make install-init
make install-config
make install-commandmode
Configure Nagios Core
Begin by editing the /usr/local/nagios/etc/objects/contacts.cfg file's email field, according to the example below:
File excerpt: /usr/local/nagios/etc/objects/contacts.cfg
define contact{
contact_name nagiosadmin ; Short name of user
use generic-contact ; Inherit default values from generic-contact template (defined above)
alias John Doe ; Full name of user

email nagiosuser@ducklington.org ; <<***** CHANGE THIS TO YOUR EMAIL ADDRESS ******
}
Issue the following commands to configure the web interface for Nagios:
cd /opt/nagios-3.2.1
make install-webconf
Now issue the following command to create a password for the nagiosadmin user. To learn more about HTTP Authentication consider our documentation. You will use this password to log into the Nagios administration panel when it is configured.
htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin
Now reload the configuration of the web server by issuing the following command:
/etc/init.d/apache2 reload
Before we continue with the web configuration of Nagios we need to install the default plugins for Nagios.
Build and install Nagios Plugins
To install and configure the Nagios plugins, issue the following commands to extract, build, and install them:
cd /opt/
tar xzf /opt/nagios-plugins-1.4.14.tar.gz
cd /opt/nagios-plugins-1.4.14

./configure --with-nagios-user=nagios --with-nagios-group=nagios
make
make install
We're now ready to run Nagios for the first time and continue with the configuration process!
Running Nagios
Issue the following command to ensure that Nagios will be restarted following a system boot.
chmod +x /etc/init.d/nagios
/usr/sbin/update-rc.d -f nagios defaults
Run the following command to check your Nagios configuration file for errors:
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg
Any errors will be shown in red. If everything is okay, you may issue the following command to start Nagios for the first time:
/etc/init.d/nagios start
Now you can access the web based administration and reporting tools by visiting http://ducklington.org/nagios/, where ducklington.org refers to your Linode's default virtual host. You may also access this interface by visiting http://12.34.56.78/nagios/ where 12.34.56.78 is the IP address of your Linode. You will need to authenticate with the nagiosadmin user you created earlier.
Configure Nagios Alerts
A great deal of the power of Nagios is its ability to send notifications and alerts of the status of the components of your network on a very granular level. While most of this fine grained configuration is beyond the scope of this document, we have outlined some basic notification systems below.
Installing Prerequsites to send Mail Alerts
Before Nagios can send Alerts by way of email, basic mail services need to be installed. Issue the following command:
apt-get install mailutils postfix
When the installation process prompts you to define the type of mail setup you're running, select "Internet Site." You will also want to specify the machine specific hostname for this server during the installation process. Next, we'll need to update the path to the mail binary in the Nagios command file. Change both references from /bin/mail to /usr/bin/mail. The relevant section of this file should look like this:
File: /usr/local/nagios/etc/objects/commands.cfg
define command{
command_name notify-host-by-email
command_line /usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\nHost: $HOSTNAME$\nState: $HOSTSTATE$\nAddress: $HOSTADDRESS$\nInfo: $HOSTOUTPUT$\n\nDate/Time: $LONGDATETIME$\n" | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Host Alert: $HOSTNAME$ is $HOSTSTATE$ **" $CONTACTEMAIL$
}

# 'notify-service-by-email' command definition
define command{
command_name notify-service-by-email
command_line /usr/bin/printf "%b" "***** Nagios *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$" | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$
}
Issue the following command to restart Nagios and put the changes into effect:
/etc/init.d/nagios restart
You will now be able to successfully configure and send email alerts using Nagios.
Configuring Basic IRC Notifications
You can also configure Nagios to send notifications to an IRC channel. Issue the following commands to download, extract, and build the IRC bot:
cd /opt/
wget http://www.vanheusden.com/nagircbot/nagircbot-0.0.29b.tgz
tar -zxvf /opt/nagircbot-0.0.29b.tgz
cd /opt/nagircbot-0.0.29b
make
make install
You are now ready to run the bot, however you will need to specify some parameters such as the IRC network and channel. For a list of parameters, issue the following command:
nagircbot -h
Now to start the Nagios IRC bot issue the nagircbot command. See the following example as a starting point. Replace irc.ducklington.net with the domain of your IRC network, and #bucknell with the name of the IRC channel to which you would like to send notifications. Replace nagircbot with the desired nickname for your bot, and ident and realname with the ident and real name strings for the IRC bot.
nagircbot -f /usr/local/nagios/var/status.dat -s irc.duckligton.net:6667 -c \#bucknell -C -n nagircbot -u ident -U realname -I 900
In the above example, "-f /usr/local/nagios/var/status.dat" tells the bot where to get status updates. The "-C" flag will allow the bot to send colored messages to the channel depending on the status of the service. When services are down, red status messages are displayed, and these messages turn green when the service has recovered. Warnings are displayed in yellow, but do not typically represent a critical status. The "-I 900" parameter tells the bot to send a status message to the channel every 900 seconds (or 15 minutes). For example, the bot may send something like "Critical: 0, warning: 1, ok: 6, up: 2, down: 0, unreachable: 0, pending: 0", which indicates that there are no critical messages and 1 warning.
These two examples only scratch the surface of the kinds of monitoring and notifications that are possible with Nagios. Explore the resources listed below and the administrative interface for more information regarding the setup and configuration of Nagios. Congratulations on your new Nagios monitoring and notification system!

This guide is licensed under a Creative Commons Attribution-No Derivative Works 3.0 United States License. Please feel free to redistribute unmodified copies of it as long as attribution is provided, preferably via a link to this page.

So, I have someone on Identi.ca (@flameeyees@identi.ca) discussing with me me about my views on FatELF. No biggie, but trying to continue the argument (pointless as it is) there is just too much work: the character limit does not permit real discussion on such a complex issue. So, permit me to address each of the issues raised as I understand them and rebut. Then conversation can continue, if at all desired (though seriously, I don’t know that *I* desire to do so).

First point: FatELF would be useless because “you can do that already, write a cc frontend that compiles the same file multiple times, it’s _not_ hard, I’ve done it before“. Okay, so the proposed solution here is to write a compiler driver that will interpret arguments and, from a single Makefile, build for multiple platforms. There might even be something out there for that, but simply put, if GCC supported this feature intrinsically, then everyone would have it and it would be done in a standard way. Free software works better when everyone can agree on a single standard way of doing things, and not just a single standard template for how it might be done. Using addons to perform this function still yields multiple binaries that have to be shipped anyway, which is decidedly not the aim.

Second point: “how is shipping one (fat) binary ‘better’ than shipping one auto-extracting auto-deciding archive?” Making the assumption that the toolchain and kernel all support the feature as a standard thing here, the difference is simple: the kernel ELF loader would be able to decide which sections of the ELF file should actually be loaded in memory, read only those sections, and go on about its business normally—the rest of the process would not need to change in any way. No temporary copies need to be made, no images need to be extracted, nothing like that has to be done. However, the inverse is quite a different story. Let’s make the assumption that you’re using a POSIX shell script, with the archive of all of the possible binaries appended to the POSIX shell script. First, the script has to be prepended to EVERY such archive (meaning that different versions of the script could exist, and as any programmer knows, DRY), and the script is not going to be trivial: it would have to have code to detect and support every single individual platform. Furthermore, it would require that the user have permission to extract the payload, make it executable, and run it. This is the same deficiency that makes gzexe impractical for everyday use; I know that at least on all the servers that I manage, /tmp is mounted read-write but with execution of scripts and binaries disabled. Finally, it would fail to properly work in the event that something needed to be setuid—that information would have to be in the payload itself, which is absolutely not portable from one system to another. It just cannot be made to work in a generic enough fashion to be reliable on all different types of platforms with different administrative decisions made in the management of those platforms, and in many cases would require an increased attack surface just to be made workable.

However, if FatELF (or, honestly, anything that is truly equivalent) were used, an administrator could copy the binary from one system (say, an x86) to another system (say, a PowerPC) that has all of the other dependencies filled for it, drop it on the filesystem, chown/chmod it once, and it would Just Work. setuid, if needed, would be honored by the kernel, and no extraction has to take place. No additional temporary disk space would be required, nor would it be necessary to incorporate any logic into the ad-hoc “loader” (if it could even be called that) to try to find a filesystem that is read-write with execution permitted for the current user, and therefore no special privileges from the user would be necessary.

In fact, the only way to solve the problem reliably at present would be to have something like /var/cache/adhoc-fat-binaries, and have all ad-hoc “fat binaries” be setuid 0 (or setuid to some user that has all necessary privileges to make something setuid 0 if necessary, probably only UID 0 has that privilege on most systems) so that it could (a) write to /var/cache/adhoc-fat-binaries and (b) set the setuid or setgid bits if necessary for the program to fulfill its function. And it deserves to be restated: we all know that having a single specific standard and adhering to it—even when the standard is less than ideal (and in some cases, like X11, falls quite short of ideal)—is far better than having 100 different and incompatible ways to do the same thing. It’s one of the things that we people in free software know pretty damn well.

See, I don’t see something like FatELF being used for distribution binaries, or anything that would be distributed in an operating system distribution package, except perhaps in special situations where something like biarch is natively supported on the hardware and it would be feasible to permit that sort of flexibility. Instead, I see something like my current situation: I administer several machines for small businesses, and not all of them are the same hardware platform.  They are all the same operating system and many of them have the same libraries installed.  Some of them are 64-bit and some are 32-bit.  Some are x86, some x86-64, and some are neither. But I would very much like to write a single program, say “make” and copy the file to every machine so that it just works. For the moment, if I want something like that, I have to just use something like Java, C#, or a script. Or, if I need something setuid, I do it in C and compile it for every system, shipping the source code file to the systems instead. But it would be more efficient to not have to do that. That is why I would see FatELF being a “good thing”.

I know that I am in the minority.

That brings me to point three: “because in 99% of all usage, the kernel won’t _need_ it. And its cost in effort and overhead would be higher.” For this next part of my post here, I am going to be looking at the Linux kernel, version 2.6.34, which I have just downloaded from kernel.org, which is 64 MB compressed (using bzip2!) and takes up 442 MB when uncompressed, before touching any file in the tree. Now, I am looking at this for x86-64 because that is the system I am running on and typed “make menuconfig”.

Who needs any of the following options? I am willing to bet that the following options are not needed in 99% of all (desktop, server, and embedded, combined) usage:

1. Processor type and features/Support for extended (non-PC) x86 platforms
2. Processor type and features/Maximum number of CPUs
3. Processor type and features/Memory model
4. Processor type and features/Build a relocatable kernel
5. Executable file formats / Emulations/Kernel support for ELF binaries
6. Executable file formats / Emulations/Kernel support for MISC binaries
7. Executable file formats / Emulations/IA32 Emulation
8. Executable file formats / Emulations/IA32 Emulation/IA32 a.out support
9. Networking support/Plan 9 Resource Sharing Support (9P2000) (Experimental)
10. File systems/Second extended fs support
11. File systems/Reiserfs support
12. File systems/JFS filesystem support
13. File systems/XFS filesystem support
14. File systems/GFS2 file system support
15. File systems/OCFS2 file system support
16. File systems/Dnotify support
17. File systems/Kernel automounter support
18. File systems/Kernel automounter version 4 support (also supports v3)
19. File systems/FUSE (Filesystem in Userspace) support
20. File systems/FUSE (Filesystem in Userspace) support/Character device in Userpace support

I can’t even go on. Twenty is enough; I think I have made my point. In 99%+ of all situations, these options are either always on or always off. They are rarely modified. And the kernel still supports a.out from IA32’s really old days‽ Seriously?

What does this tell me? It tells me that FatELF—or anything else that came along and did something like what FatELF would do—has room in the kernel. And if it were for whatever reason incompatible with current ELF (as it would very likely be) then the kernel could still support “old” ELF, without any of the extra fields or sections.

And actually, there is a great deal of possibility around something entirely different altogether. FatELF isn’t the most technically elegant thing I can think of to solve the problems that it solves, but I have yet to see something else seriously proposed. I can think of something even better, actually. We are all taught that operating systems are here to abstract us from hardware, so that we can write applications and not have to worry about communicating with the hardware directly because the OS handles those details for us. Well, if that is the case, then why don’t operating systems also abstract the system’s processor? Why don’t we have operating system kernels that provide a virtual instruction set? Yes, I am talking about essentially moving the application VM into an operating system kernel, though ideally with some supporting utilities in userspace to do things like hold persistent JIT caches and so forth. However, that’s for another post, another time.

I’ve recently gotten a lot of flack from a couple of people for an innocent comment I made about logging into a machine as root.
I’d like to think of myself as pretty savvy when it comes to security, and as far as I’m concerned, the reasons for not logging in as root are:-

• Password could theoretically be sniffed
• Unsecure connection could theoretically be hijacked
• You don’t get an audit trail like you would with su or sudo
• Password could be brute forced
• You could easily run a command unintentionally which causes damage to your system

Ok, so we have the reasons not to – and they’re good reasons. This is why, generally, I don’t login to my boxes as root. However, the box in concern mitigates the above in the following ways

• We only ever connect via SSH
• Access to root is only allowable through SSH keys
• Due to the nature of the server (local file storage) we don’t need an audit trail
• Password login is only ever allowed from a secure TTY (aka the box itself)
• The only reason we ever need to login to this machine is to perform maintenance which requires root access

Is there any good reason that I shouldn’t be logging in as root in the above circumstances?

1) If you are running a 64 bit version of OpenVZ on the Hardware Node, don't expect your 64 bit guests to work on a 32 bit host.

2) If you get an error saying asm/bitsperlong.h missing, then run make sure /usr/src/linux/include/asm/bitsperlong.h -> /lib/modules/2.6.31-gentoo-r10/build/include/asm-generic/bitsperlong.h is linked.

3) Do not be afraid.