SFTP only access to server

I recently installed a NAS server in my home and wanted to give my family and relatives access to it so that they could use it as a remote backup server for photos and stuff. To keep it as secure as possible I only wanted to give them SFTP access.

(All commands below are executed as root.)

First I created a group to group them together and then added the users to that group. I choose to disable their password as I only allow logins using SSH keys.

As for the upload directory I wanted them to upload their data to my raid1 volume mounted under /data/pool1. Since OpenSSH has some requirements for the permission on the directories used as chroot I created the following directory layout.

The home symlink is there to make the initial SFTP directory /ausername and the sftp directory is created with 751 to disallow directory listing in the top directory.

Then, as “all components of the pathname must be root-owned directories that are not writable by any other user or group” and /data/pool1 is not root owned I created a bind mount by adding the following to /etc/fstab.

Before the initial mount, the directory must be created.

Then, the final part was to configure OpenSSH by adding the following lines at the end of /etc/ssh/sshd_config.

Remember to restart the server afterwards.

Faster resume with (k)ubuntu Natty

After upgrading to Kubuntu Natty beta 1 the time for resuming (from RAM) my HP ProBook 6450b has improved significant. Previously I had to wait up to a minute until the wireless card was up and running and I had Internet access. Now it’s only a matter of seconds. My Linux laptop is now fully on par with my old Apple iBook when it comes to suspend/resume (the only area where it was previously lagging).

I can’t say for sure why it’s better now, but I like to think that it’s due to Broadcom’s full-source release of their wireless drivers. Thank you Broadcom!

Getting Licq to build with pbuilder

I wanted to test that I had specified the correct Build-Depends in my Debian package of Licq 1.5.0-rc2. It seemed like the simplest way to do this was to create a personal builder installation and build the package in that chroot.

So I did:

Building should then be as simple as executing:

Or it should have been that simple. Unfortunately the build failed with:

After some googling and testing; the fix was to add two random devices to the chroot:

(The change of permission for /dev/null was needed to avoid getting errors later in the build process.)

Git is not always better than subversion

Yesterday I wished I had used svn instead of git as VCS for Licq’s debian package, when I accidentally deleted my local git clone with lots of commits that I hadn’t pushed…

Luckily I had all the changes in a different format so I didn’t have to redo all the work, but I had to spend time trying to commit the changes in a somewhat logical way.

debian/licq.git mirror on Gitorious

To get better speed and a backup I’ve set up a mirror of debian/licq.git on Gitorious.org.

I don’t really know the best way to do this, but I did it by adding the following line to hooks/post-update:

This way the mirror will always be updated when I push to the “real” repository.

Get it by running

or clone it on Gitorious and send me merge requests 🙂

Compiler bug

To see if Licq would build without warnings with gcc 4.5 I tried to build Licq trunk with the latest gcc-snapshot in Debian today. Three warnings were quickly fixed but a bigger problem was that the unit test hung; something which doesn’t happen with earlier gcc.

After some digging it turned out to be a problem with locking. A mutex was never unlocked when returning in the exception handler. This was very strange as the unlocking should be done by the MutexLocker destructor.

I was able to reproduce the problem with a simple test program so I concluded that it was indeed a compiler bug and reported it: Destructor not called when returning in exception handler.

Not every day you get to find a compiler bug…