TimeMachine-Server-Gebastel auf Linux

01/03/2010 - 02:02 von Gerald Eíscher | Report spam
Nach ersten Versuchen <4B3A38A1.5040206@ID-37099.user.uni-berlin.de>
habe ich meinen TimeMachine-Versuchs-Server nun soweit, dass:
- die TimeMachine-Systemeinstellung das entsprechend AFP-Share findet,
ohne dass es vorher gemountet wurde
- bei Wiederherstellung von gebooteter Installations-DVD das AFP-Share
automagisch gemountet wird

Das Versuchsopfer ist ein EeePC mit Ubuntu 9.10 und angeschlossener
USB-Platte (FAT32 formatiert). Netatalk ist in Version 2.0.5 mit
SSL-Unterstützung nötig; für Ubuntu 9.10 habe ich ein Paket gebastelt:
http://members.kabsi.at/eischer/g/d...l_i386.deb

Mein Eintrag in der /etc/netatalk/AppleVolumes.default:

/media/TimeMachine/ "TimeMachine" options:tm,usedots,upriv
allow:gerald

/etc/netatalk/afpd.conf:


In der /etc/default/netatalk empfielt sich:

ATALKD_RUN=no
PAPD_RUN=no
CNID_METAD_RUN=no
AFPD_RUN=yes
TIMELORD_RUN=no
A2BOOT_RUN=no

Es sei denn, man braucht das AppleTalk-Zeugs wirklich, andernfalls
verbràt das ziemlich Zeit beim Starten des Netatalk-Dàmons.

Im Root-Verzeichnes des TM-Volumes muss eine (leere) Datei
.com.apple.timemachine.supported existieren.
"TMShowUnsupportedNetworkVolumes"-Fummelei in irgendeiner .plist ist
nicht nötig.


Schwieriger war die richtige Announcierung per Avahi (Bonjour).
Ausgehend von Dominiks Posting
<news:1j9350e%2E1ld6b0sl2zt8N%schlu-do@gmx.net> habe ich in diversen
Webforen rumgewühlt und eine /etc/avahi/services/timemachine.service
angelegt:

<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">TimeMachine auf %h</name>
<service>
<type>_afpovertcp._tcp</type>
<port>548</port>
</service>
<service>
<type>_adisk._tcp</type>
<port>9</port>
<txt-record>sys=waMA=0,adVF=0x100</txt-record>
<txt-record>dk0=adVF=0x81,adVN=TimeMachine</txt-record>
</service>
<service>
<type>_device-info._tcp</type>
<port>0</port>
<txt-record>model=Macmini</txt-record>
</service>
</service-group>


Unter adVN= (AirDiskVolumeName) muss der gleiche Name stehen, wie in der
AppleVolumes.default (hier: "TimeMachine"), etwas das mir erst sehr spàt
klar wurde. Andernfalls scheitertn die TM-Systemeinstellung beim Mounten
des Volumes.
Unter waMA= schreiben manche die MAC-Adresse vom Server rein, dürfte nach
<http://developer.apple.com/mac/libr...00-SW1>
nicht nötig sein. Dito das von mir nicht verwendete adVU= mit
irgendeiner UUID. Siehe
http://marc.info/?l=netatalk-devel&m1076211716326&w=2
UUID wovon?

Der <service>-Eintrag mit _device-info._tcp ist nicht nötig, ergibt aber
ein hypsches Icon eines MacMini im Finder ;-)


Falls bei einer Wiederherstellung von gebooteter Installations-DVD
netzwerktechnisch alle Stricke reißen sollten, làsst sich die Platte mit
dem TM-Backup per USB (oder Firewire) direkt am Mac anhàngen und
wiederherstellen. Das sparse bundle mit dem Backup wird ohne Umschweife
gefunden.
Deswegen auch die Formatierung mit dem kranken FAT32, da es meines
Wissens das einzige Dateisystem ist, das Linux und Schneeleo verstehen.


Gerald
 

Lesen sie die antworten

#1 Thomas Kaiser
01/03/2010 - 11:10 | Warnen spam
Gerald Eíscher schrieb in <news:
Nach ersten Versuchen
habe ich meinen TimeMachine-Versuchs-Server nun soweit, dass:
- die TimeMachine-Systemeinstellung das entsprechend AFP-Share findet,
ohne dass es vorher gemountet wurde
- bei Wiederherstellung von gebooteter Installations-DVD das AFP-Share
automagisch gemountet wird

Das Versuchsopfer ist ein EeePC mit Ubuntu 9.10 und angeschlossener
USB-Platte (FAT32 formatiert). Netatalk ist in Version 2.0.5 mit
SSL-Unterstützung nötig; für Ubuntu 9.10 habe ich ein Paket gebastelt:
http://members.kabsi.at/eischer/g/d...l_i386.deb



Ist da "nur" die DHX2 UAM drin oder auch DHX?

Mein Eintrag in der /etc/netatalk/AppleVolumes.default:

/media/TimeMachine/ "TimeMachine" options:tm,usedots,upriv
allow:gerald



Hmm... "upriv" und dann nur "allow:gerald" ;-)

Man kann TimeMachine übers Netz auf AFP-Volumes mit und ohne Unix
Privileges betreiben. Der spezielle Charme, dem Volume "upriv"
mitzugeben, bestünde darin, daß im Netzwerkbetrieb User nicht auf die
Sparse Bundles der anderen User zugreifen können, sofern jeder User
eigene Logon Credentials hat und die auch fürs Mounten der Share genutzt
werden.

In Deinem Fall mit der FAT32-Platte dürfte das aber doch alles nix
bringen oder wie bildet Linux Permissions/Ownerships auf FAT32 ab? Ich
kann mich dran erinnern, daß es so 'ne Mountoption für DOS-Kram mal gab,
bei dem der Kram irgendwie in einer Container-Datei auf dem FAT-Laufwerk
verwaltet wurde. Aber keine Ahnung, ob das noch mit fvat/fat32 geht.

/etc/netatalk/afpd.conf:


In der /etc/default/netatalk empfielt sich:

ATALKD_RUN=no
PAPD_RUN=no
CNID_METAD_RUN=no
AFPD_RUN=yes
TIMELORD_RUN=no
A2BOOT_RUN=no

Es sei denn, man braucht das AppleTalk-Zeugs wirklich, andernfalls
verbràt das ziemlich Zeit beim Starten des Netatalk-Dàmons.



Außer Du setzt auch die Option ATALK_BGROUND, dann erfolgt der Start des
atalkd im Hintergrund (das ist nötig, weil die Selbstkonfigurations-
konzepte von AppleTalk Höflichkeit vorsehen. Jeder, der neu im Netz ist,
fragt erstmal höflich, ob es gestattet ist, sich diese DDP-Adresse oder
jenen NBP-Namen zu reservieren... und wartet halbe Ewigkeiten auf
Antworten, die ja auch aus einem WAN, d.h. durch dünne Leitungen kommen
könnten. Der Hauptteil der Zeit geht aber für ZIP/RTMP drauf, d.h. das
Abchecken, ob evtl. AppleTalk-Router im Netz am Start sind, mit denen
friedlich koexistiert werden muß)

Im Root-Verzeichnes des TM-Volumes muss eine (leere) Datei
.com.apple.timemachine.supported existieren.
"TMShowUnsupportedNetworkVolumes"-Fummelei in irgendeiner .plist ist
nicht nötig.

Schwieriger war die richtige Announcierung per Avahi (Bonjour).
Ausgehend von Dominiks Posting
<news:1j9350e%2E1ld6b0sl2zt8N% habe ich in diversen
Webforen rumgewühlt und eine /etc/avahi/services/timemachine.service
angelegt:

<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">TimeMachine auf %h</name>
<service>
<type>_afpovertcp._tcp</type>
<port>548</port>
</service>
<service>
<type>_adisk._tcp</type>
<port>9</port>
<txt-record>sys=waMA=0,adVF=0x100</txt-record>
<txt-record>dk0=adVF=0x81,adVN=TimeMachine</txt-record>
</service>
<service>
<type>_device-info._tcp</type>
<port>0</port>
<txt-record>model=Macmini</txt-record>
</service>
</service-group>


Unter adVN= (AirDiskVolumeName) muss der gleiche Name stehen, wie in
der AppleVolumes.default (hier: "TimeMachine"), etwas das mir erst
sehr spàt klar wurde. Andernfalls scheitertn die TM-Systemeinstellung
beim Mounten des Volumes.



Und wenn ich Dominik richtig verstanden habe, ist die Reihenfolge, in
der die Volumes seitens Netatalk annonciert werden (FetchVolumeList) und
die, die in Avahi vorgenommen wird (dk0, dk1, dk2, ..., dkn) auch nicht
uninteressant. Ich hab mir das mal in Helios' Inkarnation (die können
TimeMachine mit automatischer Bonjour-Annoncierung auch seit Kurzem)
eben angeschaut:

macbookpro-tk:~ tk$ dns-sd -L macbookpro-tk _adisk._tcp
Lookup macbookpro-tk._adisk._tcp.local
10:48:51.981 macbookpro-tk._adisk._tcp.local. can be reached at macbookpro-tk.local.:1088 Flags: 1
dk0=adVN=HELIOS\ Applications,adVF=0x80
dk1=adVN=ICC-Profiles,adVF=0x80
dk2=adVN=Settings,adVF=0x80
dk3=adVN=HELIOS\ Demo,adVF=0x81
dk4=adVN=Hotfolder,adVF=0x80
dk5=adVN=ParadorExport,adVF=0x80
dk6=adVN=FS01,adVF=0x80
dk7=adVN=Distill,adVF=0x80

Die Reihenfolge der Volumes stimmt exakt mit der überein, die auch beim
Mounten bzw. beim "Erstkontakt" mit dem Server seitens AFP-Client
abgefragt bzw. übermittelt wird -- wird einem in /var/log/system.log
gelistet, wenn man den AFP-Client auf geschwàtzig stellt, siehe den
syslog.conf-Abschnitt in

<http://kaiser-edv.de/news/MacOS/afp...n.html>

Ab 10.4 braucht's nur noch den syslog.conf-Kram, kein Fummeln mehr per
defaults.

Allerdings sehe ich grad, daß Helios meine Homedir-Share "~tk"
unterschlàgt, d.h. die Reihenfolge der Eintràge stimmt zwar überein
zwischen AFP-Call und Bonjour-Annoncierung aber es fehlt ein neuntes
Volume mittendrin. Vielleicht also doch egal, in welcher Reihenfolge man
annonciert, wenn man mehr als ein Netatalk-Volume hat?

Falls bei einer Wiederherstellung von gebooteter Installations-DVD
netzwerktechnisch alle Stricke reißen sollten, làsst sich die Platte
mit dem TM-Backup per USB (oder Firewire) direkt am Mac anhàngen und
wiederherstellen. Das sparse bundle mit dem Backup wird ohne
Umschweife gefunden.



Das ist ein wirklicher Vorzug, stimmt.

BTW: Wenn man Backup übers Netzwerk mit mehreren Rechnern macht, dann
kann es sehr sinnvoll sein, sich vorher zu überlegen, wieviel Platz
jeder der Rechner auf dem TimeMachine-Volume bekommen darf. Und dann
entsprechend passende SparseBundles zu Fuß anlegen. Andernfalls könnten
die einzelnen Sicherungen der Rechner miteinander in Konflikt kommen.
Das Handling der SparseBundles auf HFS+ bzw. AFP ist zwar intelligent
genug, den extern zur Verfügung stehenden Platz auch ins SparseBundle
selbst durchzureichen aber es kann dann trotzdem vorkommen, daß eine der
zu sichernden Kisten anmault, es stünde nicht genügend Platz zur
Verfügung. Dem entgeht man eben "elegant", indem man die maximale Größe
der Images vorbestimmt.

Man braucht dazu:

* den Rechnernamen (nicht FQDN!):

sudo /usr/sbin/systemsetup -getcomputername | awk -F": " '{print $2}'

* die MAC-Adresse der ersten Netzwerkkarte in passender Notation:

ifconfig | grep -A1 "^en[0-9]: " | awk -F" " '/ether / {print $2}' | head -n1 | tr -d ":" | tr "[:upper:]" "[:lower:]"

* Die gewünschte maximale Größe des SparseBundles in GByte.

* Die gewünschte Größe der einzelnen SparseBundle-Streifen in KByte
(default bei TimeMachine ist 8172 KByte, was Vor- als auch Nachteile
hat)

Nennen wir die Parameter bspw. ${MachineName}, ${MACAddress} und
${BackupSize}, ${BandSize}, so muß der hdiutil-Aufruf lauten:

/usr/bin/hdiutil create -layout SPUD -size ${BackupSize}g -fs HFSX \
-type SPARSEBUNDLE -imagekey sparse-band-size=${BandSize} -volname \
"Backup of ${MachineName}" \
/path/to/tm-volume/${MachineName}_${MACAddress}.sparsebundle

(Infos zum SparseBundle gibt's per "hdiutil imageinfo", Hinweise zum
Veràndern der Größe finden sich dort dito und in der manual page --
Stichwort: "hdiutil resize", ein "hdiutil compact" macht TimeMachine
AFAIK eh autark)

Deswegen auch die Formatierung mit dem kranken FAT32, da es meines
Wissens das einzige Dateisystem ist, das Linux und Schneeleo
verstehen.



Hat FAT32 eine Limitierung hinsichtlich maximale Dateien je Ordner? Denn
mit der default Sparseband-Size von 8 MByte werden affig viele Dateien
in /path/to/tm-volume/${MachineName}_${MACAddress}.sparsebundle/bands/
erzeugt, wenn die zu sichernde Datenmenge auch nur moderat (für heutige
Verhàltnisse) ausfàllt, so daß es da ggf. irgendwann knallen könnte.

Gruss,

Thomas

Ähnliche fragen