Time Machine Backups to AFP volume over SSH tunnel

Since I read that time machine works better over wireless now, I wanted to give it another try.

I ran into quite a few problems...

Netatalk: AFP Daemon

Netatalk is easy to setup...
I didn't bother setting up avahi etc. for getting funky server icons on the mac  as I didn't intend to open these ports anyway...

The only files to configure are:

/etc/netatalk/afpd.conf:

   - -tcp -noddp -uamlist uams_dhx2.so -nosavepassword -nozeroconf

/etc/netatalk/netatalk.conf

   AFPD_UAMLIST="-U uams_dhx2.so"

/etc/netatalk/AppleVolumes.default

   /mnt/tmdisk/tmb tmb  allow:tmuser cnidscheme:dbd options:tm,usedots,upriv

1. I created a new user: tmuser 
2. I only wanted to support DHX2 (Lion does not use DHX) and found to my annoyance that whenever I started the netatalk server through systemd, it passed in
   

      "-U uams_dhx.so, uams_dhx2.so" 

   despite my setting the UAMs in afpd.conf!
   Inspecting the service file: /lib/systemd/system/netatalk.service revealed the culprit to be the script /usr/libexec/netatalk/netatalk.sh - some kind of kludgy script to start/stop netatalk which looks at netatalk.conf to set the UAMs!
   So, the change to netatalk.conf is listed above.
3. Make sure to use the DBD scheme which is supposed to be tolerant of network dropouts...

SSH Tunnel

AFP is quite insecure (as are other file sharing protocols such as SMB/NFS (?)) and I wanted to tunnel the connection over SSH. There are pages galore describing this one command setup in great detail ;-)!

ssh -f -N -L 12345:localhost:548 karthik@netatalkserver

I intend to create the tunnel, start the backup and tear it down when done...

Time Machine Setup

Thereafter, mounting in finder worked like a charm:

    open afp://tmuser@localhost:12345/tmb

Setting it up in time machine also worked:
sudo tmutil setdestination -p afp://tmuser@localhost:12345/tmb

You are prompted for the password (tmuser's password) and no errors are reported.

However, if you try to start a backup, it results in failure - time machine reports that backup disk could not be made available! In the Console logs, you can see the error:

com.apple.backupd: NAConnectToServerSync failed with error: 80 for url: afp://tmuser@localhost:12345/tmb

I spent half the night trying to figure this out. Wireshark showed a similar sequence of 6 messages being exchanged in both cases - finder mount and time machine mount... However, the logs on the netatalk server indicate that the password was incorrect. Encryption of the password makes it hard to figure out what is going on...

The solution: modify the keychain record storing the password (open the keychain app and filter by "time") which is tripping up time machine:

When time machine is setup, it creates a record without the port number appended to the URL. Apparently, when it is time to do the backup, it somehow does not parse this record properly and sends the wrong password!

It took me forever to find this!

After that, starting the backup is a cinch:

   sudo tmutil startbackup

Lights Out Upgrade to Fedora Core 17.

Upgrading to Fedora Core 17 on a headless unit proved difficult.

I was upgrading from FC16 - had a disk failure on the FC15 system I described in the earlier post and installed FC16 on the replacement drive.

Pre-upgrade supports VNC access to make this possible - but there were hiccups.

1. IIRC pre upgrade did not configure grub correctly and reboot just brought me back to FC16 - I had to go down to the system and choose the pre-upgrade kernel while booting (this is a known bug: here and here)
2. Once the install was started, the vnc server was started as requested during pre-upgrade. I connected to the vnc server and accidentally closed the vnc viewer and could not connect back to the vnc server! This is also known and thanks to Ambarish for the workaround:
1. I downloaded the debug symbols for the tiger vnc server in an FC17 system running in a virtual machine (as the virtual machine was a 64 bit system, I had to specify the architecture for my 32 bit system): setarch=i686 yumdownloader --enablerepo fedora-debuginfo tigervnc-debuginfo
2. Use rpm2cpio to convert to cpio archive and extract the contents
3. Copy the entire contents to the system being upgraded (e.g. at /tmp/d).
4. Fire up gdb and point it to the debug symbols: 
1. Load symbols:
   set debug-file-directory /tmp/d/usr/lib/debug
2. Set source search directory:
   directory /tmp/d/usr/src/.../tigervnc-1.0.1/
3. Attach to running Xvnc (vnc server)
4. break at rfb::VNCSConnectionST::checkIdleTimeout()
5. Try to connect with vnc viewer and when you hit the breakpoint
1. set rfb::Server::idleTimeout.value=600
2. set rfb::Server::neverShared.value = false
6. And, voila you are connected to the vnc server again!
3. But, now the upgrade is hung at upgrading the package sbcl! Again, a known bug. Kill the process from a VT console and the upgrade continues...

Interestingly, cleaning up after pre upgrade as per the instructions, I found FC14/FC15 packages - where did they come from?! I had a pristine FC16 install before the upgrade...

Fedora Core 15...CMOS battery

Ran across a curious situation... Was installing FC15 (use the net install image to get all the updates during install) on a system with a drained CMOS battery. 

The install would fail:"Unable to read package metadata"/"Cannot retrieve repository metadata (repomd.xml) for repository".

From FC15 install

Switching to a VT and using wget revealed the problem : the SSL certificate for the repository could not be validated as the date on the system was incorrect - 2006. Fixing the date (date -s 'YYYY-mm-dd HH:MM:SS-HH:MM') was all that was needed.