Archive for the ‘Uncategorized’ Category
Wednesday, July 7th, 2010
It is quite possible to run Nagios3’s web interface directly from Nginx and a FastCGI server, rather than having to involve a web application server like Apache. This is useful if you want to preserve memory on your machine, for example.
First of all, we ask Nginx to serve the static files for the Nagios web interface. In Debian/Ubuntu, these live in /usr/share/nagios3/htdocs and /usr/share/nagios3/stylesheets, which is a little awkward, but just the sort of thing that the rewrite command is for …
location / {
root /usr/share/nagios3/htdocs;
index index.html;
rewrite ^/nagios3/stylesheets/(.*)$ /../stylesheets/$1 break;
rewrite ^/nagios3/(.*)$ /$1 break;
}
Next, we tell Nginx to send requests for CGI pages down to a FastCGI server :-
location ~ \.cgi$ {
root /usr/lib/cgi-bin/nagios3;
include /etc/nginx/fastcgi_params;
rewrite ^/cgi-bin/nagios3/(.*)$ /$1;
auth_basic "Nagios";
auth_basic_user_file /etc/nagios3/htpasswd.users;
fastcgi_pass 127.0.1.1:8998;
fastcgi_param SCRIPT_FILENAME /usr/lib/cgi-bin/nagios3$fastcgi_script_name;
fastcgi_param AUTH_USER $remote_user;
fastcgi_param REMOTE_USER $remote_user;
}
We need to make sure that these requests are under authentication, and that we pass the authenticated username to the CGI script properly, hence the auth_basic and fastcgi_param AUTH_USER lines.
That’s Nginx taken care of, but we also need to make sure there’s a generic FastCGI server running on the specified address/port. No configuration is necessary, as we’re passing everything we need, including the script name. fcgiwrap comes recommended on the Nginx wiki.
/usr/bin/spawn-fcgi -a 127.0.1.1 -p 8998 \
-u www-data -g www-data \
-f /usr/local/bin/fcgiwrap -P /var/run/fcgiwrap.pid
And that’s all you need!
Posted in Uncategorized | 1 Comment »
Tuesday, February 23rd, 2010
I was using s3sync to copy masses of files to Amazon S3 from a customer machine, and after the first run was complete, I just re-ran the same command to check elapsed time. It failed with 403 Forbidden errors …
Looking at the detailed error, it turned out that the machine’s clock was set about 20 minutes into the future (come back Max Headroom …), and this was breaking things. Quite reasonable.
So, I installed openntpd, and set the correct time from the date command. Well, I tried to set the date … it was being ignored. Very odd.
A bit more digging later, and I realised that this machine was a Xen guest, and had been set to follow the Xen host time — in this case, you can try to set the time until you’re blue in the face, and you will be ignored (without any errors being emitted, I note. Well, that’s under Debian 4, anyway).
The long-term answer is to get the Xen host fixed — having incorrect time is terribly inexcusable. Looking at a handy Xen FAQ, the short-term fix is to decouple the guest clock using /proc/sys/xen/independent_wallclock …
# cat /proc/sys/xen/independent_wallclock
0
# echo 1 > /proc/sys/xen/independent_wallclock
# date -u --set 03:09:45
Tue Feb 23 03:09:45 UTC 2010
# date
Tue Feb 23 03:09:47 GMT 2010
Now I can continue to sync files into S3 …
Posted in Technology, Uncategorized | No Comments »
Sunday, January 10th, 2010
Why have I chosen Wordpress as the CMS for http://inode.co.nz/?
Normally, I wouldn’t choose to rely on anything written in PHP … but more than that, I wanted something that was supported from the Debian repository. And while the significantly more interesting Plone is in there as well, the development environment they prefer doesn’t like being wedged into The Debian Way — I couldn’t install simple themes, and the recommendation was “ignore the packaged version, install from source”. Sorry, that violates the Inode philosophy of system administration.
So, Wordpress is enough of a CMS to be used as a manager for a simple website, which this is. It’s provided in a workable form from the Debian repository, so it will be security tracked and updated. And addons (such as themes) work the way they are supposed to, easily.
Posted in Uncategorized | No Comments »