All posts by Phil

Tips for Configuring Nagios3 Efficiently – part 1

Back when I started using Nagios (I think ~1.2 or earlier) I don’t remember many options for being all that efficient in terms of “lines of config written” – certainly, any options for being efficient that there may have been ended up being overlooked in the rush to get it up and running, and I’ve been largely been using the same configuration files (and style) ever since – though I did start using host and service templates as soon as I became aware of them some time back in the 2.x branch days.

In the spirit of self-improvement, I’ve been revisiting the Nagios configuration syntax as part of rolling out a fresh monitoring host based on Nagios3, and have significantly reduced the number of lines of config my Nagios installation depends on as a result.

Continue reading Tips for Configuring Nagios3 Efficiently – part 1

The LCHost Debian package mirror

As part of giving back to the community LCHost runs a Debian package mirror (including backports) (for i386 and amd64) which was recently added to the official mirrors list.

I spent a little time making it automatically detect changes at our source mirror within a couple of minutes and pull down, so at most it’ll never be more than 5 minutes behind the top-level mirrors.

To use our debian mirror, simply replace your regular mirror definition in /etc/apt/sources.list with:

deb stable main contrib
deb-src stable main contrib

(You may choose to use the release name in place of “stable” to ensure you never accidentally go between major releases – so for wheezy, simply replace the word stable with wheezy)

If you use backports, you can get those packages from us too, using something like:

deb wheezy-backports main

Installing Nagios3 on Debian Wheezy

It’s pretty straightforward to install Nagios on a Debian system but if you want to be able to use the web interface to control the nagios process a little more work is required.

Starting with a blank slate (apt/dpkg will ensure any required prerequisites will be installed):

# apt-get install nagios3 apache2-suexec

You’ll be asked to set a password for the nagiosadmin user for the web interface.

Enable check_external_commands in Nagios to enable the ability to mute alarms, make comments, restart the nagios process etc from the web interface (pretty much invaluable, but be aware of the inherent risks in enabling the ability to influence the process from “outside”)

# sed -i -e 's/check_external_commands=0/check_external_commands=1/' /etc/nagios3/nagios.cfg
# /etc/init.d/nagios3 restart

Edit the nagios3 apache2 config include to make the web interface scripts run as the nagios user so that the web interface can write to the nagios command pipe; inserting the following at the top of /etc/nagios3/apache2.conf:

User nagios
Group nagios

Restart apache..

# /etc/init.d/apache2 restart

And you’re pretty much done! You can go to http://YOUR_HOST_NAME/nagios3/ and log in with your nagiosadmin password you set up when prompted at the start of this process.

Now, you can get started with creating host and service configuration files in /etc/nagios3/conf.d/ to monitor your servers/network/etc


So, I used to post this stuff onto a tumblr blog at but decided that – frankly – I’m not exactly short of server resource, so I’ve moved what little content there was in-house.

Lately I have found that poor documentation – or simply vast documentation – has been irking me more and more and I’ll likely start documenting things I figure out for both my own sanity and that of others who follow in my footsteps.

Reset virtualhost / domain file permissions plesk 9.x (and possibly 10.x?) linux

Having just completed a rescue job on a customer’s Plesk 9 server, all of the files in /var/www/vhosts had incorrect permissions on them resulting in visitors to any of the domains receiving a 403 Permission Denied error. The Plesk disaster recoveryKB article (KB 112699) has a section on fixing ownership of transferred files (step 9) but nothing on fixing vhost permissions.

The Parallels knowledgebase has this article (KB 6572) on restoring permissions on ONE domain, but that’s not all that helpful when you need to restore permissions on EVERY domain on the server. Plesk Windows users get the ability to batch “Check Permissions” in the control panel interface, but Linux users get no such love.

Instead, you can execute the following (as root!) to reset the permissions for every virtual host on the server:

# mysql -uadmin -p`cat /etc/psa/.psa.shadow` -Dpsa -Ns -e”select, sys_users.login as username from domains left join hosting on left join sys_users on left join accounts on where htype=’vrt_hst’;” | awk ‘{print “/usr/local/psa/admin/sbin/vhostmng —install-vhost —vhost-name=” $1 ” —user-name=” $2 ” —set-content-permissions”}’ | sh -x

It should be noted that I have only tested this on a 9.x server but I think the psa database structure is similar on 10.x so you may find this works for you. The trickiest part of this was figuring out how to get a listing of virtual host domains mapped to system users out of the psa database as the schema is a bit convoluted – hat tip to for having something I could adapt.

Debian 6 (Debian Squeeze) & Debian 7 (Debian Wheezy) reboot… doesn’t.

Someone made kexec-tools handle reboot requests by default seemingly. This allows the system to skip BIOS/POST etc and just drop to a minimal runlevel and start a kernel again.

This is great if you only have debian on your system and particularly great if you spend a lot of time changing kernels – when you issue reboot, or shutdown -r now (etc) kexec-tools intercepts the command and does a warm-restart rather than resetting the machine cold – if you don’t need to, why wait through all the BIOS checks, bootroms, etc, right?

Except some of us reboot because we want to change OS. I’d argue that it should perhaps be the default behaviour to cold-reboot (and the installer could, perhaps, ask!) or that KDE should have a button for “warm restart” and one for “cold reboot” or whatever, but anyway.

If you want to make reboot actually reboot the system you’ll want to:

# dpkg-reconfigure kexec-tools

And tell it to not use kexec-tools to handle reboots. If you’re never going to want kexec-tools, you can probably uninstall it using apt, but I just disabled it. It’s useful on the odd occasion I do want to just upgrade the kernel to enable it, reboot, and disable it again, I suppose.

Some SEO, perhaps?

Debian 6 Squeeze won’t reboot
Debian 6 Squeeze reboot doesn’t go to grub
Debian 6 Squeeze reboot dualboot
Debian 7 Wheezy won’t reboot
Debian 7 Wheezy reboot doesn’t go to bios

Debian 6 (Debian Squeeze) KDE4 Override Screen Resolution

Everything you needed to know about manually overriding incorrectly probed screen resolutions but nobody thought to write down, seemingly:

$ xrandr -q
Screen 0: minimum 320 x 200, current 3600 x 1080, maximum 8192 x 8192
DVI-I-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm
   1920x1080      60.0*+
   1600x1200      60.0  
   1680x1050      60.0  
   1400x1050      60.0  
   1280x1024      75.0     60.0  
   1440x900       59.9  
   1280x960       60.0  
   1152x864       75.0  
   1024x768       75.1     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   640x480        72.8     75.0     66.7     60.0  
   720x400        70.1  
DVI-I-2 connected 1680x1050+1920+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1024x768       60.0  
   800x600        60.3     56.2  
   848x480        60.0  
   640x480        59.9  
   1680x1050      60.0*

This output shows what xrandr has detected. In my case, DVI-I-2 wasn’t showing the 1680×1050 resolution I needed. It’s there now because this output is from after I made my modifications.

$ xrandr --addmode DVI-I-2 "1680x1050"

Was all it took.

Sadly, of course, this is all lost on reboot, despite making changes in the System Settings/Display panel and saving them as default – because even though my screen alignment settings were saved in $HOME/.kde/share/config/krandrrc, the mode 1680×1050 isn’t remembered as being valid for my screen.

Because krandrrc contains a config element like this:

StartupCommands=xrandr --output "DVI-I-1" --pos 0x0 --mode 1920x1080 --refresh 60\nxrandr --output "DVI-I-2" --pos 1920x0 --mode 1680x1050 --refresh 59.9543

I simply elected to try adding:

xrandr --addmode DVI-I-2 "1680x1050"

To the front end of StartupCommands, like so:

StartupCommands=xrandr --addmode DVI-I-2 "1680x1050"\nxrandr --output "DVI-I-1" --pos 0x0 --mode 1920x1080 --refresh 60\nxrandr --output "DVI-I-2" --pos 1920x0 --mode 1680x1050 --refresh 59.9543

On reboot, my screen resolution is correctly set, and my dualhead config works as expected. Now I just need to remember never to change my screen settings again, or be prepared to make that change again.

Some SEO, hopefully:

KDE4 Manual Resolution
KDE4 Override Screen Resolution
KDE4 Incorrect Screen Resolution