Tuesday 17 November 2009

CentOS, Nagios and SELinux

I've just finished installing Nagios on our CentOS box. I kept on running into errors when trying to get Nagios to start. The errors weren't very specific, merely stating

Starting nagios:CONFIG ERROR! Start aborted. Check your Nagios configuration.

This confused the crap out of me, mostly because of the lack of information in the error messages. So after a few hours of googling, I found that the problem was with SELinux. This is the fourth or fifth time that this piece of software has gotten in the way of installs. It's no wonder then that the first piece of advice when telling someone on a forum/mailing list is to give the advice to set 'SELINUX=disabled'.

This ofcourse ends up voiding any security advantage that SELinux may have had, but apparently everyone seems to think that Linux is secure enough.

Friday 6 November 2009

Linux and Remote Desktop

Recently we've installed a remote server in North America. In order to set up some Windows boxes, we figured it would be easier to download the DVD images from the servers themselves. This posed a problem however, for several reasons:

1. XenServer requires that any Linux installs be specially compiled for Xen. This is due to the way that the Xen guys wrote the code for the HyperVisor. From my understanding (and without going through the lkml) the code was not very 'clean' and/or did not conform to the kernel coding guidelines. This resulted in the Xen code not being available in the standard kernel that comes with most distributions.

2. Figuring out how to add an ISO repository and actually have its contents come up when installing a new VM is harder than it probably should be on Xen. When trying to figure this out, I found plenty of examples of how to add a new iSCSI/CIFS repository to the XenServer, but nothing on how to set up an ISO repository on the local storage.

3. Apparently there's also a way of uploading a Windows XP VM, but this was more complicated to get going than adding the local ISO repository.

Due to these problems it was decided to take one of the existing distributions (Debian Lenny) and install a desktop environment and enable Remote Desktop functionality through the use of one of the below listed technologies. After pissing about for two/three days with these protocols I can honestly say that the NX protocol and the binaries available off the NoMachine site are the easiest to configure and the best working solutions. This is kind of disappointing for me, since I would have loved to see a FLOSS solution out do a propriatary one, but as a programmer you have to give credit where credit is due.

When it comes to Remote Desktop functionality for Linux, there are a few options regarding protocols:

* XDMCP - Basically the original X idea of remote displays hooked up to a mainframe. Couldn't get it to work for the life of me. Also, found a known, unfixed bug whereby enabling remote login makes the gdm listen only to IPv6 addresses
* VNC - Hard to set up and slow
* RDP - See VNC
* NX (FreeNX) - Awesome. Although FreeNX is a real bastard to set up

UPDATE: Found out that Google released their own NX Server called Neatx.

Monday 2 November 2009

Zend CE Server on CentOS

I just finished installing Zend Server Community Edition on CentOS. One of the problems encountered along the way was that starting Apache would give an error saying that it did not have the necessary permissions to access '/usr/local/zend/lib/apache2/libphp5.so'. This is due to SELinux not allowing the httpd process access to this file. After searching around for a solution, I found that most of the forum posts gave the advice to either switch SELinux to permissive mode or to disable it altogether. To me, this was a bit like throwing the baby out with the bathwater, so after reading up a bit on SELinux, I figured an easier (and more secure) solution was to just add this file to the 'httpd_modules' context. So, here your are:

chcon -t httpd_modules_t /usr/local/zend/lib/apache2/libphp5.so

This command adds the Zend php binary to the 'httpd_modules' context, allowing Apache to load it and start up normally.