Schlagwort-Archive: rsync

aeroFS

aerofs

Klingt ja auf den ersten Blick gut: aeroFS synct nicht gegenüber einem Server beim Dienstleister, sondern nur zwischen den Rechnern, auf denen es installiert ist. Es liegen also keine Dateien in der Cloud rum – meint man.

Denn: Wer das Passwort hat (und dazu gehört im Prinzip auch der Dienstleister selbst), kann einen weiteren SyncClient einrichten und sich dann von dort alle Daten von den Clients holen. Ob dieser Fremdclient dann in jedem Fall im Frontend angezeigt wird … bleibt ein Geheimnis des Dienstleisters. Ich glaube da nicht dran: Da wird schon nicht der Client „Sheriff“ auftauchen, wenn der Sheriff von Hicktown meint, er müsse in meine Dateien blicken. Dass derartiges Cloud-Geschnüffele nicht nur bei US Unternehmen passiert, sondern auch bei uns, steht unter anderem hier.

Ergo: Komfortabler Dienst – aber am Ende fast genauso unsicher wie Dropbox, SkyDrive und wie sie alle heißen. OwnCloud – gepaart mit TrueCrypt – auf dem eigenen Server bleibt die sauberste Lösung.

F15 raus, Oneiric Beta rein

Mein Dell Vostro 1510 wollte einfach nicht unter Fedora 15 rsync-en: Trotz neuem Kernel (2.6.40 in F15 Sprache, eigentlich wohl ein Linux 3 Kernel) riss rsync regelmäßig das gesamte System in den Abgrund: Meine Daten auf meinem Dell waren so nicht aktuell zu halten.

Also probierte ich die Synchronisation so eben unter Ubuntu Oneiric Beta 1 und siehe da: hier funktioniert es ohne Abstürze.

Oneiric macht auch an anderen Stellen schon jetzt keine schlechte Figur: Die Installation des WLan Treibers für die in diesem Gerät verbaute Broadcom Corporation BCM4312 802.11b/g LP-PHY (rev 01) lief glatt, wurde sogar im Rahmen der Systeminstallation angeboten. Der proprietäre NVidia Treiber läuft auch.

Dafür fliegen mir jetzt dauernd irgendwelche Gnome Komponenten um die Ohren und ich komm vor lauter Bugreports einreichen nicht mehr zum Arbeiten 😉

Lovelock and deadlock

Mein Dell Vostro 1510 läuft unter Fedora 15. Wenn ich auf diesen die Daten vom heimischen Server mit Hilfe von rsync ziehe, dann friert mir regelmäßig der Desktop ein. Das Einzige, was dann noch hilft, ist ein lang anhaltender Druck auf die Ausschalten-Taste.

Ich hab schon probiert mit Hilfe der rsync Option –bwlimit=1000 oder –bwlimit=500 einen erfolgreichen Sync zu bekommen, weil ich dies als Tipp in mehreren Foren fand. Umsonst.

Was leider ebenfalls nicht funktioniert, ist, mit sudo telinit 3 F15 in den Mehrbenutzerbetrieb ohne Gnome zu versetzen und dann das Sync-Script laufen zu lassen.

Update

Inzwischen vermute ich, dass hier ein Bug im Treiber der Netzwerkkarte oder der Festplatte vorliegt. NFS könnte ebenfalls ein Kandidat für Probleme sein – aber wie rausfinden, wenn ein

sudo tail -f /var/log/messages

nix bringt, weil Gnome in den Abgrund geht, ohne jegliche Meldung?

Update

Ein dmesg liefert evtl. einen Hinweis mit der folgenden Meldung:

[  118.705871] [drm:drm_debugfs_create_files] *ERROR* Cannot create /sys/kernel/debug/dri/

Ja – die komischen Zeichen gehören zur Fehlermeldung mit dazu und nach allem, was ich bisher gefunden habe, liegt es wohl an einem Kernel Bug. Im Moment nutze ich 2.6.38.8-35.fc15.i686 und hoffe nun auf den bald erscheinenden kernel-2.6.40-4.fc15.

Nachtrag 28.08.2011

Die „komischen Zeichen“ führen leider dazu, dass der Feed über die Wupper geht. Der Feed Validator machte mich hierauf aufmerksam. Mist. Screenshot wäre besser gewesen.

Truecrypt Zeitstempel

Veränderungen in einem TrueCrypt Container gehen in den Grundeinstellungen von TrueCrypt nahtlos an der mtime der Datei vorbei. Dies führt dazu, dass die Container nicht von Programmen wie BackinTime oder anderen auf rsync basierenden Backuplösungen gesichert werden. Mit den folgenden Einstellungen klappt es dann doch:

In den Einstellungen den Haken bei „Preserver modification timestamp of file containers“ entfernen und

einen Haken bei „Do not use kernel cryptographic services“ setzen, damit die vorher getroffene Einstellung wirksam werden kann.

Moodle frisst Server

Eigentlich dumpe ich jede Nacht alle Datenbanken auf dem Server und verpacke diese zusammen mit den Webserververzeichnissen in Archive – bzw. backup2l macht das für mich. Diese Archivdateien rsynce ich am frühen Morgen auf meine lokale Platte bzw. auf meinen Backupserver in der Schule.

Jahrelang ging das glatt. Moodle 1.x.y legte brav nur die Dateien in die Unterverzeichnisse von /moodledata, die von den Nutzern hochgeladen wurden. Moodle 2 benimmt sich komplett anders – wie, genau, weiß ich noch nicht. Da komm ich gerade erst dahinter. Auf jeden Fall fressen die frisch installierten Moodle 2 langsam den Plattenplatz auf dem Server und auf den Backupservern auf, weil sich jede Nacht gleich pfundweise Dateien und Verzeichnisse innerhalb von /moodledata verändern und so die Archive aufblähen.

Nachdem in den Foren auf moodle.org zu dem geschilderten Problem keine Reaktion kam, trug ich einen bug report ein. Jetzt kommt Bewegung in die Sache … aber eine saubere Lösung steht wohl noch für einige Zeit aus.

Im Moment packt backup2l nur noch die WordPresse und DokuWikis sowie die Moodle 1.9.x Installation – nicht aber Verzeichnisse, die ein Moodle 2 enthalten – ein. Moodle 2 Backups gibt es nur noch ein paar mal im Monat – und da dann lediglich von den von Moodle 2 selbst angelegten Kursraumbackups.

Was für ein Gewürge.

keybindings II

Für den manuellen Weg und für eine allgemeine Beschreibung siehe diesen Beitrag.

Im Alltag taugt für eine Synchronisation von Tastenkombinationen mal wieder rsync. Um die Tastenkombinationen vom Homeserver auf den Laptop zu bekommen, das Serververzeichnis (z.B. mit Hilfe von NFS oder Samba) am Laptop einhängen und dann auf dem Laptop das folgende, selbstverständlich an die eigene Umgebung angepasste, Skript laufen lassen:

#!/bin/bash
# Standardkeybindings
rsync -r -t -v –progress –delete /home/user/eingehaengtesserververzeichnis/.gconf/desktop/gnome/keybindings/ /home/user/.gconf/desktop/gnome/keybindings/ ;
# Zusatzkeybindings
rsync -r -t -v –progress –delete /home/user/eingehaengtesserverzeichnis/.gconf/apps/gnome_settings_daemon/keybindings/ /home/user/.gconf/apps/gnome_settings_daemon/keybindings/ ;

Ausloggen – Einloggen. Die Tastenkombinationen des Laptops entsprechen nun denen vom Homeserver.

rsync über ssh mit Hop

Einer meiner Laptops steht in der Schule – also hinter einer Firewall und nur über seine schulinterne IP erreichbar. Angenehm ist, wenn der Datenbestand auf dieser Maschine dem Datenbestand auf meinem heimischen Arbeitsplatzrechner entspricht. Bisher trug ich den Schullaptop deswegen immer in den Ferien mit nach Hause, synchronisierte diesen im heimischen Netz und nahm diesen dann am ersten Schultag wieder mit zum Arbeitsplatz. Der Datenbestand hinkte demnach etwas hinterher.

Für eine Erstsynchronisation ist dieses Vorgehen immer noch ratsam. Aber jetzt aktualisiere ich öfter – mit Hilfe von rsync über ssh und einem Hop über einen anderen Rechner im Schulnetz, der – so zu sagen – „in der Mitte“ steht, von Außen erreichbar ist und immer am Netz hängt. Ich nenne diese Maschine hier „rechnermitte“.

Die Maschine rechnermitte ist nicht über den Standard SSH Port 22, sondern (sagen wir mal) über Port 2244 zu erreichen. Der SSH Server auf dem Schullaptop jedoch hört auf Port 22.

Hinweis: Damit keiner Blödsinn mit meinem Schullaptop macht, ist der Login über SSH nur für einen bestimmten User (hier: schullaptopnutzer) erlaubt und außerdem hab ich auf diesem als zusätzliche Hürde fail2ban installiert.

Zuerst wird ein SSH-Tunnel zum Schullaptop geöffnet, und zwar so, dass dessen Port 22 über rechnermitte an den Port 2223 am Heimarbeitsplatz (localhost) gebunden wird:

ssh -L 2223:interne_ip_schullaptop:22 user_mitte@rechnermitte.schuldomain.de -p 2244

Der Aufruf verlangt nach dem Passwort für user_mitte auf rechnermitte.

Steht diese Verbindung, kann ich meinen Schullaptop vom heimischen Rechner aus schon wie folgt über SSH erreichen:

ssh schullaptopnutzer@localhost -p 2223

Es folgt der Aufruf von rsync auf dem heimischen Rechner, mit dem Ziel, die zu Hause geänderten Daten auf den Schulrechner zu übertragen (umgekehrt geht das auch – aber das ist nicht Teil dieser Beschreibung):

rsync -r -t -p -x -v –progress –delete -z /home/heimrechnernutzer/Dokumente/Schule/ –rsh=’ssh -p2223′ schullaptopnutzer@localhost:/home/schullaptopnutzer/Dokumente/schule

Selbstverständlich dauert eine derartige Synchronisation über das Internet wesentlich länger – ich hab hier nur „Bauern-DSL“ und entsprechend niedrige Upload-Raten. Aber es klappt trotz aller Einschränkungen erstaunlich flott – die Zeit für das Abendessen reicht fast immer.

Nach einer erfolgreichen Synchronisation kann ich den Schullaptop dann von zu Hause aus herunterfahren.

Vereinfachend für mich ist, dass ich auf dem Schullaptop nur selten viele Dateien überarbeite: Die Maschine dient im Wesentlichen als Präsentationsrechner. Wenn doch umfangreichere Änderungen vorgenommen werden, dann schick ich mir diese meist per Mail oder werf sie nach Dropbox, so dass ich extrem selten einen rsync vom Laptop in Richtung Heimrechner benötige. Sollte dies sich ändern, dann käme evtl. noch unison ins Spiel und würde weitere Vereinfachungen ermöglichen: http://wiki.ubuntuusers.de/Unison

Eine gute Sammlung verschiedener Methoden für rsync über ssh liefert die folgenden Website inklusive Sicherheitshinweise: http://samba.anu.edu.au/rsync/firewall.html