Search This Blog

Friday, March 23, 2012

Ubuntu Quickstart - Installing Nagios

Ubuntu Quickstart:

This guide is intended to provide you with simple instructions on how to install Nagios from source (code) on Ubuntu and have it monitoring your local machine inside of 20 minutes. No advanced installation options are discussed here - just the basics that will work for 95% of users who want to get started.
These instructions were written based on an Ubuntu 6.10 (desktop) installation. They should work for an Ubuntu 7.10 install as well.
What You'll End Up With
If you follow these instructions, here's what you'll end up with:
  • Nagios and the plugins will be installed underneath /usr/local/nagios
  • Nagios will be configured to monitor a few aspects of your local system (CPU load, disk usage, etc.)
  • The Nagios web interface will be accessible at http://localhost/nagios/
Required Packages
Make sure you've installed the following packages on your Ubuntu installation before continuing.
  • Apache 2
  • PHP
  • GCC compiler and development libraries
  • GD development libraries
You can use apt-get to install these packages by running the following commands:
sudo apt-get install apache2

sudo apt-get install libapache2-mod-php5

sudo apt-get install build-essential

With Ubuntu 6.10, install the gd2 library with this command:
sudo apt-get install libgd2-dev

With Ubuntu 7.10, the gd2 library name has changed, so you'll need to use the following:
sudo apt-get install libgd2-xpm-dev

1) Create Account Information
Become the root user.
sudo -s

Create a new nagios user account and give it a password.
/usr/sbin/useradd -m -s /bin/bash nagios

passwd nagios

On older Ubuntu server editions (6.01 and earlier), you will need to also add a nagios group (it's not created by default). You should be able to skip this step on desktop, or newer server editions of Ubuntu.
/usr/sbin/groupadd nagios

/usr/sbin/usermod -G nagios nagios

Create a new nagcmd group for allowing external commands to be submitted through the web interface. Add both the nagios user and the apache user to the group.
/usr/sbin/groupadd nagcmd

/usr/sbin/usermod -a -G nagcmd nagios

/usr/sbin/usermod -a -G nagcmd www-data

2) Download Nagios and the Plugins
Create a directory for storing the downloads.
mkdir ~/downloads

cd ~/downloads

Download the source code tarballs of both Nagios and the Nagios plugins (visit for links to the latest versions). These directions were tested with Nagios 3.1.1 and Nagios Plugins 1.4.11.


3) Compile and Install Nagios
Extract the Nagios source code tarball.
cd ~/downloads

tar xzf nagios-3.2.3.tar.gz

cd nagios-3.2.3

Run the Nagios configure script, passing the name of the group you created earlier like so:
./configure --with-command-group=nagcmd

Compile the Nagios source code.
make all

Install binaries, init script, sample config files and set permissions on the external command directory.
make install

make install-init

make install-config

make install-commandmode

If you get following error while executing make install command 
make[1]: *** [install] Error 1
make[1]: Leaving directory `/media/europa/callisto/nagios___/nagios-3.3.1/nagios/html'
make: *** [install] Error 2

then execute following commands
./configure --with-command-group=nagcmd
sed -i 's:for file in includes/rss/\*;:for file in includes/rss/\*.\*;:g' ./html/Makefile
sed -i 's:for file in includes/rss/extlib/\*;:for file in includes/rss/extlib/\*.\*;:g' ./html/Makefile make fullinstall

courtesy by grunge

Don't start Nagios yet - there's still more that needs to be done...
4) Customize Configuration
Sample configuration files have now been installed in the /usr/local/nagios/etc directory. These sample files should work fine for getting started with Nagios. You'll need to make just one change before you proceed...
Edit the /usr/local/nagios/etc/objects/contacts.cfg config file with your favorite editor and change the email address associated with the nagiosadmin contact definition to the address you'd like to use for receiving alerts.
vi /usr/local/nagios/etc/objects/contacts.cfg

5) Configure the Web Interface
Install the Nagios web config file in the Apache conf.d directory.
make install-webconf

Create a nagiosadmin account for logging into the Nagios web interface. Remember the password you assign to this account - you'll need it later.
htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

Restart Apache to make the new settings take effect.
/etc/init.d/apache2 reload

Note Note: Consider implementing the ehanced CGI security measures described here to ensure that your web authentication credentials are not compromised.
6) Compile and Install the Nagios Plugins
Extract the Nagios plugins source code tarball.
cd ~/downloads

tar xzf nagios-plugins-1.4.11.tar.gz

cd nagios-plugins-1.4.11

Compile and install the plugins.
./configure --with-nagios-user=nagios --with-nagios-group=nagios


make install

7) Start Nagios
Configure Nagios to automatically start when the system boots.
ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios

Verify the sample Nagios configuration files.
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

If there are no errors, start Nagios.
/etc/init.d/nagios start

8) Login to the Web Interface
You should now be able to access the Nagios web interface at the URL below. You'll be prompted for the username (nagiosadmin) and password you specified earlier.

Click on the "Service Detail" navbar link to see details of what's being monitored on your local machine. It will take a few minutes for Nagios to check all the services associated with your machine, as the checks are spread out over time.
9) Other Modifications
If you want to receive email notifications for Nagios alerts, you need to install the mailx (Postfix) package.
sudo apt-get install mailx

sudo apt-get install postfix

You'll have to edit the Nagios email notification commands found in /usr/local/nagios/etc/objects/commands.cfg and change any '/bin/mail' references to '/usr/bin/mail'. Once you do that you'll need to restart Nagios to make the configuration changes live.
sudo /etc/init.d/nagios restart

Configuring email notifications is outside the scope of this documentation. Refer to your system documentation, search the web, or look to the Nagios Support Portal or Nagios Community Wiki for specific instructions on configuring your Ubuntu system to send email messages to external addresses.

Thursday, March 22, 2012

NGINX: Slicehost Articles: How to serve multiple domains

Slicehost Articles: How to serve multiple domains: "^/(.*) http://"


I am often asked by people how to use their Slice to serve multiple domains.
The question often surprises me as they may have setup their Slice, installed a web server (Apache, Nginx, etc) and even created a virtual host to serve their main domain.
Don't get me wrong, the question itself is good (I like questions as it makes me feel useful!), but the answer is always so simple:
Create another vhost.


There may not be a great deal I can add to the answer but let me outline the process of setting up a Slice and creating a virtual host (I won't go into any details of the installation and creation process - please see the relevant articles for detailed help).
When your Slice is first created it is a minimal Linux install (it doesn't matter what OS you choose).
You SSH into the Slice and update and secure it.
Then you install your preferred web server (Apache, Nginx, Litespeed, etc).
Then the detailed stuff begins. It doesn't matter if your site is PHP based or Rails based or something else entirely. You install the language and framework basics (say Ruby and rubygems or mod_php and so on).
Once that is all done, you come to the part that allows you to server your site: creating virtual hosts.


Greatly simplified the procedure for serving a website is as follows:
A browser send a request to your Slice IP asking for the contents of '' (your domain name).
Your web server jumps into action and says 'yes! I have something for you'. The web server does its 'thing' and serves up an http representation of your site which is sent to the browser.
The browser then translates the http and parses it to a human form of the web site (something like this one).
All jolly good but how does your web server know what to send?

Virtual Hosts

This is where name based virtual hosts come in.
One of the first lines in any virtual host contains the domain name that is related to the vhost.
Something like this for Apache:
<VirtualHost *:80>

and something like this for Nginx:
server {

  rewrite ^/(.*)$1 permanent;
Each one starts slightly differently but the same principle applies - that particular virtual host will respond to queries for '' and ''.

Multiple domains

So, to serve different content for different domains is as simple as adding another virtual host.
Let's say you have a subdomain called '' serving a blog (I know, shocking originality!).
The basic creation process would be to create a folder in your public_html folder with the relevant files (let's say a Wordpress install).
A virtual host would be created with the server_name or ServerName as '' which would be configured to point to the blog files and folders in your public_html folder.

Language and frameworks

It doesn't matter what language or framework your domain uses.
To serve multiple Rails applications for example requires the same setup for each application.
Of course, there would be some differences such as port numbers for the mongrel or thin instances. Virtual hosts can't share ports.
For example, you may create a mongrel cluster to run from port 8000 - 8002 for one domain and another running from 8010 - 8012 for your blog and so on.


Once the Slice has been setup and the web server has been installed, serving multiple domains is very easy:
Simply create more vhosts...

apache bench max concurrency

apache bench max concurrency:

echo "10240" > /proc/sys/net/core/somaxconn

or set (to make permanent) 

net.core.somaxconn = 10240 (or any number over what you are using as max connections)



then run 

/sbin/sysctl -p /etc/sysctl.conf

Also set your local ulimit to 

ulimit -n 65535 

just to have some overhead in case you want to increase the concurrent connections in ab. Let me know if that helps. If you want my thoughts on why I think this fixes things (assuming it helps you) let me know 

Also if you move to Worker MPM (you will have to redo php to be threadsafe if you use php) it might lower you CPU usage for a higher RAM usage depending on what your running off your server.

Vi: Search and Replace

Vi: Search and Replace:

Vi: Search and Replace

Change to normal mode with <ESC>.
Search (Wraped around at end of file):
  Search STRING forward :   / STRING.
  Search STRING backward:   ? STRING.

  Repeat search:   n
  Repeat search in opposite direction:  N  (SHIFT-n)

Replace: Same as with sed, Replace OLD with NEW:
 First occurrence on current line:      :s/OLD/NEW
 Globally (all) on current line:        :s/OLD/NEW/g 

 Between two lines #,#:                 :#,#s/OLD/NEW/g
 Every occurrence in file:              :%s/OLD/NEW/g 

Wednesday, March 21, 2012

How to Change the Timezone in Linux: 8 steps - wikiHow

How to Change the Timezone in Linux: 8 steps - wikiHow:

  1. 2
    Logged in as root, check which timezone your machine is currently using by executing `date`. You'll see something like Mon 17 Jan 2005 12:15:08 PM PST, PST in this case is the current timezone.
  2. 3
    Change to the directory /usr/share/zoneinfo here you will find a list of time zone regions. Choose the most appropriate region, if you live in Canada or the US this directory is the "America" directory.
  3. 4
    If you wish, backup the previous timezone configuration by copying it to a different location. Such as
    mv /etc/localtime  /etc/localtime-old
  4. 5
    Create a symbolic link to the appropriate timezone from /etc/localtime. Example:
    ln -sf /usr/share/zoneinfo/Europe/Amsterdam /etc/localtime 

Tuesday, March 20, 2012

Brian Huisman - Apache mod_rewrite & mod_alias tricks you should know

Brian Huisman - Apache mod_rewrite & mod_alias tricks you should know:

I don't usually like writing articles, because inevitably someone you know is going to stumble upon your work and realise that you don't know as much they thought you did lol With regards to mod_rewrite andmod_alias, however, I am regularily underwhelmed by the available examples floating out there whenever I go looking.

Sure the official docs at are okay, but they really only go through all the available options and don't give very many real world examples. I hope to offer some simple tips and tricks which will solve many common problems.

.htaccess And You
If your website is hosted via Apache, you can edit your .htaccess file(s) and the server is set up to read them, I have one big piece of advice for you: USE YOUR .HTACCESS FILE! Your .htaccess file provides you with quick access to make extremely valuable site-wide context changes to the way your webserver behaves. It can provide for HTTP redirects (3xx), mark documents as gone (HTTP 410), pre-set PHP environment variables, add custom MIME-types, block IPs, adjust headers, set which pages to display on a server error, and much, much, much more!

If you aren't using it yet because you fear it's too complicated, just start with something simple and also very useful: setting a 404 error document. Create a page to display to users if they request a page that doesn't exist in your website. I've called mine "notfound.html".

ErrorDocument  404  /notfound.html

Place the saved .htaccess file in the root public HTML folder. Now instead of the plain "File Not Found" page, your users will be given a much nicer page to look at, ideally which contains navigation links back to the rest of your site.

The Tricks 
Okay, now that we've gotten the beginner stuff out of the way, let's move on to the tricks. There is so much you can do with mod_rewrite and mod_alias that it would be impossible to detail all of the sneaky things they can do. Basically I'm going to describe a few tricks which I've picked up over the years, tricks that have gotten me out of some tough situations.

Let's start with the basics. If the functionality of each of these modules were mapped out in area, it would look something like this red and blue image. Yesh, that's right. For all practical purposes mod_rewrite can do everything that mod_alias can do, plus a great deal more. So why use mod_alias at all?

Well, mostly because it's "cleaner". mod_rewrite can get pretty complicated sometimes, and if an action can be performed using mod_alias, it can usually be done in a lot fewer bytes, CPU cycles and headaches. Essentially, if you're doing a "rewrite" which doesn't have any complex conditions attached to it, youshould be using mod_alias. Conversely, if you want to redirect requests to files and query strings which you don't want displayed in the browser's address bar, you should be using mod_rewrite. In my own crazy world, I consider mod_alias the brightly dressed traffic cop which you can't miss, while mod_rewrite is the shady character you often miss because he does most of his work behind the scenes.

Moving forward, I'll assume that you know which directives are members of each module. See the links at the top of this post to go to the Apache documentation.

Order of Execution
mod_rewrite rules get executed before mod_alias rules. This is important to note because this is the case regardless of the order in which you place the directives in your .htaccess file. It may not seem like a big deal at first, but it means you may end up performing simple redirects using mod_rewrite simply because you want it to happen before a mod_rewrite directive which happens later.

For example, say you have a PHP file which deals with products that uses the following simple mod_rewrite directive:

RewriteCond  %{DOCUMENT_ROOT}/products/$1  !-f
RewriteRule  ^products/(.+)$               /products/index.php?$1  [L,QSA]

The rules above will check to see if a file doesn't exist (!-f) at the requested URI within the /products directory, and if the file doesn't exist, it will send the request as a query string to the index.php file. This makes URIs like into a "real" request for which the client never sees.

However, you also want to redirect an obsolete product to a non-product page. So you add the following:

Redirect      301  /products/Widget

However, this doesn't work because the "products/Widget" REQUEST_URI gets caught by the mod_rewrite rule before it ever gets to the Redirect directive. This happens even if the Redirect directive comesbefore the RewriteRule directive in the .htaccess file! There are a number of ways you can overcome this, but the simplest is to move the Redirect above the RewriteRule by moving it from mod_alias to mod_rewrite:

RewriteRule  ^products/Widget              /new-widgets            [R=301,L]

RewriteCond  %{DOCUMENT_ROOT}/products/$1  !-f
RewriteRule  ^products/(.+)$               /products/index.php?$1  [L,QSA]

Now /products/Widget will be correctly redirected with a 301 Moved Permanently HTTP status code.

Other Quirks
Both mod_rewrite and mod_alias have a few quirks which keeps them from being completely compatible. For instance, mod_alias patterns will match against a REQUEST_URI which begins with the first forward slash (/), while mod_rewrite patterns exclude this slash. This is because mod_alias always works from the root public HTML directory, even if the .htaccess file is placed in child directories. Thus, if the .htaccess file is in the root public HTML directory, the following two rules are equivalent:

RewriteRule  ^directory/(.*)$  /target/$1  [R=301,L]
RedirectMatch  301  ^/directory/(.*)$  /target/$1

Another quirk to keep in mind is that a plain Redirect directive requires that you give a complete URI as the redirect target, while using RedirectMatch allows you to specify a relative URI as the target (as above). The mod_alias docs say a relative URI is acceptable for the Redirect directive, but it doesn't work on any server that I've tried; it throws an Internal Server Error instead.

RedirectMatch  301  ^/directory/(.*)$  /target/$1                      # Valid
Redirect       301  /directory/        /target/                        # Not Valid
Redirect       301  /directory/  # Valid

Domain Name Consolidation
If you own a domain name, chances are that both the www. and non-www. version both lead to your website. In order to prevent links of both types from getting spread around in search engines and the rest of the internet, you should decide upon the one you'd like to be the default. It doesn't really matter which one you choose, but once you choose, you shouldn't switch.

The mod_rewrite code below will redirect all requests for to

RewriteCond  %{HTTP_HOST}      ^example\.com$
RewriteRule  ^(.*)   $1      [R=301,L]

Redirects - Not Just 3xx
Just because it's called a "Redirect" directive, doesn't mean getting sent to a new URI is obligatory. You can also do 4xx level responses with this directive which allows you to leave out the target URI entirely.

Here are a couple URIs which are Gone:

Redirect      410  /old/index.html
Redirect      410  /not-here.html

Or we can block some pesky bots with an obscure response and keep them from generating 404s. HTTP 412 is Precondition Failed.

RedirectMatch 412  ^/_vti_bin/

Normal subdomains activated through most hosts act as entirely separate domains. Files are stored in different public HTML folders and so any content shared by both sites needs to be duplicated, or the HTML files of one need to refer to files on the other using full URIs. Usually the benefits of such a system outweigh the hassles, but perhaps you want a tighter subdomain setup.

If your DNS is set up to direct undefined hostnames to the basic www host, then mod_rewrite can help you mimic as many subdomains as you wish, with one amazing benefit: File fallback. Consider the following set of mod_rewrite directives:

RewriteCond  %{HTTP_HOST}                   !^subdomain\.
RewriteRule  ^.*$                           -                     [S=2]

RewriteCond  %{DOCUMENT_ROOT}/subdomain/$1  -f
RewriteRule  ^(.*)$                         /subdomain/$1         [L]

RewriteRule  ^$                             /subdomain/index.php  [L]

Using this setup, whenever a client accesses your website using the domain name, the server will first check to see if the file being requested exists in the /subdomain directory. Now here is the cool bit: If the file doesn't exist there, it will fall back to the one in the regular directory!

This sort of setup is great for offering, say, multiple translations or versions of your website. To create the second website, you would just fill the /subdomain directory using the same directory structure as the main site. And if a certain file hasn't yet been translated, it will silently default to the file from the main website. In the example above, "index.php" is the filename of your directory index.

Regexp Magic
The mod_rewrite documentation at does a pretty good job at giving a basic outline of regular expressions. However, there are some things it skips over.

The documentation mentions subpattern matches which can be referenced in the replacement string in the format $N, where N is the number of the subpattern match. eg. $1, $2, etc. But did you know that you can also refer to subpattern matches within the pattern itself? While it's a documented feature of Perl Compatible Regular Expressions (PCRE), it isn't mentioned in the mod_rewrite documentation.

For example, perhaps because of some other complex redirection rules, some broken browsers or faulty robots are doubling up on directories, making requests to URIs like /docs/docs/file.doc and /products/products/Widget which are filling up your logs with 404s. You can catch all of these doubled directories with a single Redirect:

RedirectMatch  301  ^/([^/]+)/\1/(.*)$  /$1/$2

The \1 means: whatever got matched by the first parenthesized subpattern. You can see here that the pattern will thus match a directory, followed by the same directory name, followed by the rest of the path. Voila! No more doubled directories!

No examination of mod_rewrite and mod_alias pattern-making is complete without a review of regular expressions direct from Check it out!

Preferring Files Over Directories
One of the most complex problems I've encountered while developing sounded deceptively simple: In it's default setup, Apache will look for a directory match first, and then look for a file match for an incoming REQUEST_URI. However, what if you wanted Apache to prefer the file over the directory?

Generally, this only applies if you have some form of extensionless system active. So you could have a file named image.html and also a directory named /image within the same directory; where then would a request like end up? As explained above, by default you will get a directory listing for the /image directory, rather than the contents of the image.html file.

So how to prefer files over directories? The answer is complicated because it requires overriding not just one, but several default Apache behaviours. The first thing you will need to disable is the mod_dir DirectorySlash directive:

DirectorySlash  Off

When DirectorySlash is On, REQUEST_URIs which are determined to match directories automatically get a slash added to the end. We definitely don't want this; we want to stay as it is and give us the image.html file.

Now for the mod_rewrite directives. Hold on to your butts . . .

RewriteCond  %{DOCUMENT_ROOT}/$1.html  -f
RewriteRule  ^(.*?)(\.html)?/$         /$1       [R=301,L]

RewriteCond  %{DOCUMENT_ROOT}/$1       -d
RewriteCond  %{DOCUMENT_ROOT}/$1.html  !-f
RewriteRule  ^(.*?[^/])$               /$1/      [R=301,L]

RewriteCond  %{DOCUMENT_ROOT}/$1.html  -f
RewriteRule  ^(.*)$                    /$1.html  [L,NC]

Jeepers! What the heck is all that? Well, using the rules above we are bypassing the normal MultiViewsmethod to instead implement a strictly mod_rewrite solution. The above code assumes that your HTML files have the .html extension. If your content files all end in .php or .xhtml, just change the extensions in the code.

The first two lines redirect URIs ending with a slash, but matching a file with an .html extention, to the extensionless version. So it would take a URI like and forward you to That's step #1! An unfortunate consequence of this is that it overrides the directory index of a directory if a sibling file exists with the same name as the directory. So even if exists, you cannot type get to it. Rather, the URI is required to load this file. All other files in the /hello directory are unaffected.

The next three lines take URIs which do NOT end in a slash, check whether it matches a directory (-d) and at the same time does NOT match a file of the same name with an .html extension (!-f). If all these tests pass, the rule forwards you to a URI with a slash at the end. This is pretty much a "smarter" replacement for the DirectorySlash directive which we disabled earlier. That's step #2.

The final two lines actually hook up URIs with the correct file. It checks whether the currently requested file, with an .html extension tacked onto the end, matches an actual file, and if so, we are silentlyforwarded to the contents. Silently, meaning that it is not a real HTTP redirect so the client's address bar will still display the clean URI:

Of course, there are other ways to accomplish an extensionless system which prefers files over directories, this just happens to be the one I use. There's always more than one way to do it, and I welcome suggestions which would make the code above better coffee 

The End?
Well, that's all I could think of for now. If you found any errors in the examples above, please let me know. Hopefully you learned a few things, and if not, you are pretty smart!