How to mount your backups with Obnam using FUSE

With the latest version 1.5 Obnam introduced a pretty cool new feature: You now can mount your backup as if it would be a "virtual hard drive". That is, you don't need to extract / restore your backup using Obnam's command line anymore if you only are interested in certain files or directories to restore.

Since this feature is pretty new I had to bring myself up-to-date on how to exactly use the mount option. Since this is FUSE (Filesystem in Userspace) you don't need to be root to mount the actual backup. Still, it took my a while until I figured out the right parameters to make it all work.


This is how to make it happen (tested on Ubuntu / Mint / Debian):

First, you have to create a new directory in your home directory where to actually let Obnam mount the backup into. I chose

/home/<your-user-name>/tmp/obnam

for that.

Second, your user needs to be part of the group "fuse". This already should be the case, and if not: 

 sudo usermod -a -G fuse <your-user-name>

Now comes the fun part: Mounting your backup! For me, my backups are located on my NAS, which in turn are mounted (read-only, for saftey!) into

/media/ds212/backup/<your-hostname>/backup_YYMM

To mount the this backup repository, do a

obnam mount --repository /media/ds212/backup/<your-hostname>/backup_1310/ --client-name <your-hostname> --viewmode=multiple / --to=/home/<your-user-name>/tmp/obnam

Note: Execute the command above as your regular user, not as root! The backup will be mounted as ready-only -- makes sense with a backup, does it?

Now you should be able to access your backup within

/home/<your-user-name>/tmp/obnam

The cool thing is: With the option --viewmode=multiple just supplied above you can access all backup generations so far created at once. The latest folder contains a link to the, well, latest backup made.

To unmount the backup you need to be root however: sudo umount obnam

Have fun with this cool feature!

Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010

Whoa, what an article! If you consider IT security your thing you have to read the following blog post over at:

http://op-co.de/blog/posts/android_ssl_downgrade/

The author essentially found out that since Android 2.3.4 Google has changed the default cipher suite list to favor the (unsecure) RC4-MD5 first instead of RSA-SHA256.

How to debug SSH path problems on Synology NASes

Recently I wanted to add just another backup job to my beloved DS212+ Synology NAS box. This job essentially does a bit of shell stuff via SSH on that box, also requiring to have some of the optware binaries in $PATH.

Well, first it didn't work out because apparently the optware binaries (more precisely /opt/bin and /opt/sbin) weren't in SSH's $PATH. However, I was pretty sure (and of course double checked!) that $PATH was tweaked correctly in the .ssh/environment file and that sshd was restarted after that.

To debug the issue further I just started another SSH instance on the Synology, using a different port + in foreground debug mode: 

/usr/syno/sbin/sshd -d -D -p 2222

On my client I then did this:

ssh -v root@<IP-to-my-NAS> echo \$PATH

Ah ha! The "Environment:" on the client side now told me that it indeed was picking up the wrong $PATH. But wait: Where did this come from?

Quick answer: Synology's start/stop script located at

/usr/syno/etc/rc.d/S95sshd.sh

kind of messes it up. For the sake of speed I believe it doesn't really terminate the old sshd instance and instead just drops existing connections. This is why changes to .ssh/environment do not get applied correctly after restarting the service.

Solution to all this now sounds pretty simple: Log in to DSM (DiskStation Manager) via web interface, go to system settings / terminal and (again) activate "SSH". This will (re-)start sshd the right way with the new environment settings picked up. Crappy, but works!