FreeBSD, Time Machine, Lion und ein schweigender Netatalk

Nachdem durch geänderte Protokollnutzung in Mac OS X Lion zwischenzeitlich FreeBSD/FreeNAS nicht mehr als Time Machine-Sicherungsmedium zu benutzen war, gibt es nun seit einer Weile upgedatete Ports, die es wieder ermöglichen, seine Lion-Macs auf einen FreeBSD/FreeNAS-Server zu sichern.

Es war eine kleine Odyssee, alles wirklich ans Laufen zu bringen. Vor allem permanente Crashs des Netatalk-Daemons afpd haben mir Kopfzerbrechen bereitet. Die Lösung ist jedoch banal: damit der afpd nicht crasht, ist es wichtig, dass der netatalk-Port mit deaktivierten Zeroconf (Bonjour)-Support gebaut wird.

FreeBSD: Server als Time Machine-Backupmedium für Mac OS X konfigurieren

Ich habe meinen FreeBSD-Server so konfiguriert, dass er als Backup-Medium für die Time Machine von Mac OS X-Clients dienen kann. Im Wesentlichen habe ich mich an dieser Anleitung orientiert.

Auf meinem Server läuft die Version 8.0-STABLE, über Sixxs gibt es einen IPv6-Tunnel in’s Internet.

Vorbereitung des Servers

Der erste Schritt war, die Ports net/netatalk  und net/howl  zu installieren. Netatalk stellt die Appletalk-Protokolle zur Verfügung, und Howl implementiert den Zeroconf-Standard.

Damit die Dienste beim Booten automatisch gestartet werden, muss die /etc/rc.conf entsprechend angepasst werden:

netatalk_enable="YES"
cnid_metad_enable="YES"
afpd_enable="YES"
mdnsresponder_enable="YES"
mdnsresponder_flags="-f /usr/local/etc/mDNSResponder.conf"

Die  Datei /usr/local/etc/mDNSResponder.conf sieht bei mir so aus:

"TMBackup"      _afpovertcp._tcp        local.  548

Die Zeichenkette am Anfang ist der Name, unter dem die Freigabe im Mac OS X Finder erscheint. Dieser Name ist frei wählbar und kann vom DNS-Namen und SMB-Namen des Servers abweichen. Ich hatte in der Tat Probleme, als ich hier den gleichen Namen verwendet habe und veränderte ihn daher absichtlich.

Nach der Installation der Ports und dem Anpassen der Konfigurationsdateien kann man einen ersten Test machen und den mDNSResponder starten:

/usr/local/etc/rc.d/mdnsresponder startStarting mdnsresponder

Die neue Freigabe (hier: TMBackup) sollte dann nach kurzer Zeit im Finder unter Freigaben erscheinen.

Wenn das funktioniert, kann man Netatalk konfigurieren (die Datei /usr/local/etc/afpd.conf):

"TMBackup" -tcp -noddp -uamlist uams_dhx2.so -ipaddr 192.168.2.100

Hier wird ebenfalls wieder der für den mDNSResponder vergebene Freigabename verwendet. Die IP-Adresse kann man eventuell weglassen, was aber unter gewissen Umständen zu Problemen führen soll. Ich habe sie daher mit inkludiert.

Auf dem Server habe ich nun eine eigene Kennung tm für das Login der Time Machine-Clients angelegt sowie ein Verzeichnis für die Sicherungen (/usr/home/backup/TimeMachine). Für das Sicherungsverzeichnis sollten dann die Eigentumsrechte entsprechend gesetzt werden:

chmod tm:tm /usr/home/backup/TimeMachine

Jetzt muss noch das Sicherungsvolume für Netatalk entsprechend konfiguriert werden (Datei /usr/local/etc/AppleVolumes.default):

/usr/home/backup/TimeMachine "TimeMachine" volsizelimit:250000 options:tm

Der erste Eintrag ist der lokale Pfad auf dem Server zum Backup-Verzeichnis, dann folgt der Name, unter dem das Server-Verzeichnis als Netatalk-Freigabe im Finder zu sehen ist, eine Quota-Angabe für die Speicherkapazität in kB, also hier 250GB, und die Aktivierung dieses Shares für die Time-Machine (options:tm). Die Reihenfolge der Parameter volsizelimit und options scheint relevant zu sein, denn wenn ich options:tm nicht am Ende stehen habe, lässt sich das Share nicht für Time Machine-Backups verwenden, sehr wohl aber als “normales” Share.

Nachdem nun alle serverseitigen Konfigurationsarbeiten abgeschlossen sind, kann der Netatalk-Daemon auf dem Server gestartet werden:

/usr/local/etc/rc.d/netatalk start

Einrichtung auf den Mac OS X-Clients

Im Finder muss nun die Freigabe TMBackup verbunden werden. Bei der Passwortabfrage verwendet man die dafür eingerichtete Kennung (tm mit dem zugehörigen Passwort). Diese Informationen sollte man im Schlüsselbund hinterlegen, damit der Mac das Time Machine-Share immer automatisch einbinden kann und die Backups nicht deshalb unterbleiben, weil versäumt wurde, die Freigabe manuell zu verbinden (Jidōka in der Lean-Philosophie) . Nachdem die Freigabe erfolgreich gemountet wurde, sollte der Ordner TimeMachine im Finder angezeigt werden und sich öffnen lassen. Es empfiehlt sich, testhalber einen Unterordner innerhalb von TimeMachine anzulegen, um sicher zu gehen, dass dieser vom Mac aus beschreibbar ist. Wenn das erfolgreich war, kann man den Testordner wieder löschen.

Bei gemounteter Freigabe wechselt man nun in die Systemeinstellungen und klickt dort Time Machine an. Über den Button Volume auswählen wählt man dann das Volume TimeMachine aus und bestätigt (Für Backup verwenden). Die Anmeldedaten für das Volume sollten, wenn hier eine entsprechende Rückfrage kommt, wieder im Schlüsselbund gespeichert werden, siehe oben. Für eine automatisierte Sicherung sollte nun der Time Machine-Schalter noch auf “Ein” gesetzt werden. Ich habe auch die Option Time Machine-Status in der Menüleiste anzeigen aktiviert, so dass ich dort sehen kann, ob die Time Machine gerade sichert und auch über die Menüleiste bei Bedarf eine Sicherung manuell auslösen kann. Bei Bedarf kann über den Button Optionen noch festgelegt werden, welche Verzeichnisse nicht gesichert werden sollen, z. B. temporäre Download-Verzeichnisse.

Die Konfiguration des Mac OS X-Clients ist nun abgeschlossen, und die Datensicherung kann bei Bedarf über das Time Machine-Icon in der Menüleiste manuell gestartet werden (Backup jetzt erstellen).

Installation von Tracks unter FreeBSD 8

Nachdem ich in der Vergangenheit schon mal wegen irgendwelcher Ruby-Gem-Probleme gescheitert bin, habe ich gestern erfolgreich die GTD-Webanwendung Tracks auf meinem FreeBSD-Server installieren können, mit einer Sqlite3-Datenbank als Backend.

Folgende Pakete habe ich aus den Ports installiert:

• sqlite3
• ruby+oniguruma
• ruby18-aspectr
• ruby18-bdb
• ruby18-dbd_sqlite3
• ruby18-dbi
• ruby18-fcgi
• ruby18-gems
• ruby18-iconv
• ruby18-mysql
• rubygem-actionmailer
• rubygem-actionpack
• rubygem-activerecord
• rubygem-activeresource
• rubygem-activesupport
• rubygem-addressable
• rubygem-data_objects
• rubygem-deprecated
• rubygem-do_mysql
• rubygem-do_sqlite3
• rubygem-extlib
• rubygem-rack
• rubygem-rails
• rubygem-rake
• rubygem-redcloth
• rubygem-sqlite3

Einige davon, z. B. die MysSQL-Pakete, sind vermutlich unnötig.

Ich habe das Tracks-Archiv heruntergeladen und nach /usr/local entpackt. Um die Datenbank zu “bevölkern”, habe ich vom Tracks-Basisverzeichnis aus folgendes Kommando abgesetzt:

 rake db:migrate RAILS_ENV=production

Tracks konnte ich danach (ebenfalls vom Tracks-Basisverzeichnis aus) starten mit

 script/server -e production

 

Der Zugriff war dann per Browser möglich (http://meineserverip:3000)

Damit ich auch von außerhalb auf meine Tracks-Installation zugreifen kann, habe ich noch die Firewall meines OpenWRT-Routers so konfiguriert, dass Port 3000 auf den Server weiter geleitet wird.

Wer Tracks nicht selber installieren will, kann sich hier ein kostenloses Tracks-Account anlegen.

Problem mit Synaptics Touchpad unter FreeBSSD/Xorg 7.4

Auf meinem Thinkpad R60 hatte ich unter FreeBSD das Problem, dass nach einem Xorg-Update die linke Maustaste meistens als rechte Maustaste ausgewertet wird, üblicherweise hat sie kurz als linke Maustaste reagiert und unmittelbar danach als rechte Maustaste.

Eine Lösung für das Problem hat jemand freundlicherweise im Forum von FreeBSD.org gepostet:

In der “InputDevice”-Section für das Synaptics Touchpad muss man die Zeile

Option “ClickFinger2″ “0″

aufnehmen, und schon funktioniert das Touchpad wieder wie erwartet.

Twitter & identi.ca-Client für FreeBSD

Obwohl ich noch keinen großen praktischen Nutzen für mich darin sehe, habe ich mir jeweils ein Twitter- und ein identi.ca-Account angelegt, um das zumindest einmal auszuprobieren und ein paar Belanglosigkeiten “gezwitschert”. KDE 4.2 hat ja hierzu bereits ein Twitter-Plasma-Applet an Bord, das auch unter FreeBSD problemlos läuft. Für identi.ca kannte ich keinen entsprechenden Client und Google hat nach kurzer Suche choqoK ausgespuckt. Nach dem Herunterladen und Entpacken habe ich erfreut festgestellt, dass es sich problemlos unter FreeBSD bauen und nutzen lässt.

Jetzt habe ich zwar immer noch keinen wirklichen Anwendungszweck für das Zwitschern, doch immerhin unter FreeBSD einen Client, der beide Protokolle spricht.

Dell Studio-Notebook wieder auf FreeBSD umgestellt

Nachdem ich mein Dell-Studio-Notebook wieder auf Linux umgestellt hatte, konnte ich doch die Finger nicht von FreeBSD lassen.

Zuerst versuchte ich mich an FreeBSD-Current (das, was mal FreeBSD 8.0 wird). Dort gibt es Sound-Unterstützung für mein Notebook (snd_hda, HDA IDT 92HD73C1 PCM). Jedoch ist diese Version erwartungsgemäß instabil, da dort noch alles in Bewegung ist. Die Instabilität hat zweimal zu sehr ernsthaften Schäden am Dateisystem (ZFS) geführt, die ich nicht mit vertretbarem Aufwand beheben konnte. Also habe ich wieder FreeBSD 7.1 installiert und dann den snd_hda-Treiber aus FreeBSD-Current in meine FreeBSD-7.1-Installation implantiert. Resultat: ein stabiles FreeBSD 7.1 mit Sound-Unterstützung für mein Notebook.

Das Problem, dass mein Touchpad mit dem Xorg-Server 7.4 nicht funktioniert, habe ich dadurch umgangen, dass ich das Touchpad über den moused verwende. Als moused_flags benutze ich “-3 -m 1=4″. Nachteil: das vertikale Scrolling funktioniert nicht.

Was nach wie vor auch fehlt, ist eine Unterstützung für den LAN-NIC und für den WLAN-Chip, hier nutze ich bis auf weiteres meinen RALINK-USB-Adapter.

FreeBSD: Update auf Xorg 7.4

Xorg 7.4 ist seit ein paar Tagen in den Ports verfügbar, und Ich habe meine beiden FreeBSD-Notebooks upgedatet.

Dies ging leider nicht schmerzlos, da als Folge des Updates erst mal Tastatur und Touchpad/Maus nicht mehr erkannt worden. Auf meinem Thinkpad R60 ist das Problem inzwischen durch neuere Ports von Xorg und hald behoben, auf dem Dell-Notebook noch nicht, dort wird die Maus/das Touchpad nach wie vor noch nicht erkannt.

Upgrade auf FreeBSD 7.1, Netzwerk

Da ja inzwischen FreeBSD 7.1 veröffentlicht wurde, habe ich meine Notebooks auf diese Version aktualisiert, das ging alles ganz problemlos. Kernel und Userland habe ich auf jeder Maschine jeweils neu gebaut.

Meine Hoffnung auf ein stabileres WLAN haben sich leider nicht erfüllt, mit verschiedenen Chipsätzen habe ich nach wie vor das Problem, dass ich das Netz nicht mehr nutzen kann, üblicherweise hilft dann nur noch ein /etc/rc.d/netif restart. Das liegt auch nicht am Router, denn das Problem tritt mit verschiedenen Routern auf. Auch einen Kanalwechsel habe ich schon probiert.

Auch mein Router mit OpenWRT verliert gelegentlich (zusätzlich zur Zwangstrennung des Providers) die Verbindung ins WAN, so dass ich hier mit einem ifup wan nachhelfen muss. Darunter leidet auch der IPv6-Tunnel von Sixxs, der ebenfalls ab und zu neu neu aufgebaut werden will (meist übersteht er aber die verbindungslosen Phasen).

ZFS auf dem Dell Studio Notebook

Vor ein paar Tagen habe ich FreeBSD auf meinem Dell Studio-Notebook auf dem ZFS-Dateisystem neu installiert. Ich bin dabei dieser Anleitung gefolgt.

Die Installation war recht einfach und komplikationslos. Mal gespannt, wie sich ZFS so im Alltagsbetrieb anfühlt. Der File System Check fällt ja jedenfalls schon mal weg…

Ein paar Links zu FreeBSD und ZFS gibt es hier.

Thinkingrock unter FreeBSD

Die GTD-Anwendung ThinkingRock ist unter FreeBSD sehr wählerisch, mit welcher Java-Inkarnation sie laufen will. Mit der nativen Diablo Java-Implementierung läuft die Anwendung nicht, wohl aber mit dem Linux-Sun-JDK 16.

Wenn man die Diablo-Implementierung “für den Rest” nutzen will, kann man sich die Linux-Version von der Sun-Webseite herunterladen, in ein separates Verzeichnis installieren und muß vor dem Aufruf von ThinkingRock die Umgebungsvariable JAVA_HOME entsprechend setzen:

setenv JAVA_HOME /usr/local/jdk1.6.0 bzw.
export JAVA_HOME=/usr/local/jdk1.6.0