No it wasn’t my fault but the stupid DNS provider’s.
They had a partial outage of their service for the whole weekend (even their own website wasn’t reachable) and didn’t answer ANY of our calls or email enquiries.

As a result all of the ~20 domains that I run on this server will be migrated to our own DNS servers.
HowtoForge has a good tutorial on MyDNS which we will try and most probably use.

Sorry again for the outage and I hope with taking the matter in our own hands, such things won’t happen again in the future.

MotionI recently installed a simple video surveillance system at a facility I work.

The main goal is to know who (and when) entered our server room. Currently the setup features a tiny Philips USB cam connected to a Linux server (running Debian Sarge). At a later Stage this webcam will be replaced by a proper network camera (or even several cameras).

The software I used is called Motion – a relatively easy to set up video surveillance system that does motion detection (…and much, much more). Motion detection is ideal for my purpose because the room is normally completely dark unless somebody enters it and switches on the light.

Now every time somebody comes in, a short video is produced and saved on our server. I made a web accessible filesystem alias to the video directory, so I could check whether there was new footage available. This process was not automated enough for me, so I slapped together a short (und ugly) PHP script that takes the contents of the video directory and delivers it as a RSS feed that I can now subscribe to with my news reader.

The script is available at the Motion WIKI and can also be downloaded from there.

[Update:]
Some photos of the former chaos in our server room and it’s extinction can be viewed here.

special thanks to Herbert for having the idea 😉

WordpressGrowlWow! I really gotta have this.
The Binary Bonsay has set out a competition to code a Growl plugin that notifies you of events happening at your WordPress install. This is a great idea. I hope the guys working on it can sort out the NAT issues somehow and will deliver a working implementation.

If you wonder what Growl is:

As described on the Growl website, Growl is a global notification system for Mac OS X. Any application can send a notification to Growl, which will display an attractive message on your screen. Growl currently works with a growing number of applications.

I set up scponly to permit some of my users, for whom I host websites, to use sftp/scp to transfer files to the server but refuse them to login with a fully functional shell. After configuring scponly to chroot to the users home directory and some initial tests it worked very well with Transmit on the Mac, Filezilla on Windows and Putty/Terminal. The only thing that didn’t work was using Dreamweaver in SFTP mode to connect to the server.

After a bit of digging around me & Herbert found out that Dreamweaver will only communicate with the SSH server if you change the config from the Debian-standard, refusing “tunneled clear text passwords”, to permiting it in /etc/ssh/sshd_config.

# Change to yes to enable tunnelled clear text passwords
PasswordAuthentication yes

After a quick /etc/init.d/ssh restart Dreamweaver was able to log in as well 🙂

To set up chroot for scponly on a Debian system do the following:

  1. unzip the chroot script in /usr/share/doc/scponly/setup_chroot
  2. chmod +x setup_chroot.sh
  3. ./setup_chroot.sh
  4. type in the user you want to have scponly access
  5. accept the default for home directory
  6. type in the directory to be user writeable (in my case “www”)
  7. choose a password
  8. optional: compile the groups.c file in /usr/share/doc/scponly gcc -o groups groups.c and move it to the chroot mv groups /home/user/bin/.

…simple as that 🙂

After struggling almost one week to find the cause for my not entirely working Permalinks on this WordPress installation, I finally found the cure on the WordPress Codex. I already read this page about five times and I just can’t tell how this one paragraph could always slip away… anyway the solution is rather simple.

As I’m a decently paranoid Server Admin I once changed the way Apache reports it’s server software. This poses some troubles with WordPress which checks to see if the host is running Apache or IIS to determine wether to write a .htaccess file with some mod_rewrite rules or not. As WordPress can’t find out on it’s own on my host I just had to help it a little 😉

In wp-includes/vars.php on line 40 is the check for the hosting webserver, I changed the entire line to read

$is_apache = 1;

After this small modification Worpress happily updatet the .htaccess file with the apropriate mod_rewrite rules (given the file permissions are correct on the server).

One small sidenote: If you are using FAlbum and have “friendly urls” enabled you have to make sure that the rewrite rules made by FAlbum are above the ones from WordPress.