FTP ist out, rsync via ssh rockt
Früher habe ich, wie wohl die meisten, meine Webdaten mit einem schönen grafischen Client per FTP auf den Webserver geladen. Abgesehen davon, dass es unsicher ist ist es auch noch langsam und umständlich. Es wird besonders dann lästig, wenn man nicht alle Dateien auf den Server laden will. In meinem Fall sind das die bei Python üblichen *.pyc Dateien und Backup Dateien, die der Editor anlegt und mit einer ~ enden. Besonders die Backup Dateien haben auf dem Webserver nichts verloren, weil die von jedem ausgelesen werden können. Und mit den meisten FTP Clients ist es, wenn überhaupt, ziemlich umständlich, unerwünschte Dateien nicht automatisch zu kopieren.
Da ich vor einer Weile PHP den Rücken gekehrt habe und mit der Webentwicklung in Python begonnen habe musste ich mir auch einen anderen Provider suchen. Dieser bietet neben Python 2.6 und 3.x und den Datenbanken Postgresql und CouchDB auch einen eingeschränkten SSH Zugang. Eingeschränkt heißt in diesem Fall, dass ich (noch) keine Shell habe sondern nur diese Befehle nutzen kann.
- scp
- sftp
- rdist
- rsync
- cvn
- svnserve
Da ich mit rsync schon gearbeitet habe habe ich es mal damit versucht. Da der Port für den SSH Zugang nicht auf dem Standardwert ist muss man im Verzeichnis .ssh eine config Datei anlegen. Wie das geht findet ihr im Ubuntuusers Wiki.
Anschließend habe ich im Verzeichnis meines Webprojekts die Datei upload.sh angelegt. Diese enthält nur zwei Zeilen:
#!/bin/sh rsync -avze ssh --exclude='*.pyc' --exclude='*~' /pfad/zu/meinem/projekt hostname:~/
Ergänzend eine Variante ohne .ssh/config (danke an Alex)
rsync -avze 'ssh -p 12345' --exclude='*.pyc' --exclude='*~' /pfad/zu/meinem/projekt username@hostname:~/
Mit diesem Befehl ist das Webprojekt in einem Bruchteil der Zeit, den ein FTP Client brauchen würde, auf dem Server. Und wenn die Daten einmal oben sind werden nur noch die geänderten Dateien hochgeladen. Ganz automatisch. Und ganz wichtig, es wird auch keine Datei vergessen 
Ganz ehrlich, ich war zu Windows Zeiten ein reiner Mausschubser. Aber ich lege die Maus immer häufiger beiseite und verwende die Konsole. Man bekommt eine GUI Anwendung zwar schneller zu einem Erfolg, aber wenn man sieht, wie einfach und vor allem besser die Konsole manchmal sein kann…
Januar 16th, 2011 at 9:51 am
wenn Du GUI magst, nimm doch einfach grsync. Die Console ist nicht dass, was Dir jetzt die Arbeit vereinfacht, sondern der Protokollwechsel, würde ich meinen
Januar 16th, 2011 at 10:05 am
Bei grsync habe ich nicht rausgefunden, wie man da einen Webhost angibt und Unison hat bisher den Dienst verweigert.
Januar 16th, 2011 at 12:13 pm
Klar, Unison bräuchte meines Wissens nach auf der anderen Seite ebenfalls eine Unison-Instanz. Unison benutzt den rsync-Algorithmus, nicht das Programm.
Januar 16th, 2011 at 12:43 pm
1. Quoting!!! (Sonst doppelte Expansion der *)
2. /USR/bin/sh ???
2. rsync -e ‘ssh -p 12345′ sollte .ssh/config überflüssig machen
4. “–exclude=*.*~” trifft keine Backups von Dateien ohne Endung!
Januar 16th, 2011 at 1:41 pm
-p funktioniert bei rsync anscheinend nicht. wie ich auf /usr komme weiß ich ehrlich gesagt auch nicht.
Januar 16th, 2011 at 1:50 pm
Das mit dem Wechsel von GUI auf Konsole kann ich gut nachvollziehen… ich werde zwar immer von Komilitonen schräg angeguckt wenn ich das verwende (ist ja so geekig… Politikwissenschaftler -.-), aber es geht einfac schneller als den Dateimanager aufzumachen
Januar 16th, 2011 at 1:54 pm
Man merkt, dass ich kein Shell Experte bin. Mir sind in der einen Zeile doch gleich mehrere Fehler unterlaufen. Ich hoffe, jetzt passt es
Januar 16th, 2011 at 1:55 pm
Jetzt wo du es erwähnst… stimmt
Januar 16th, 2011 at 2:03 pm
Wenn man ohnehin bzr benutzt, dann empfiehlt sich uebrigens auch das bzr plugin “update”. Wenn ich in meinem tree bin, dann wird quasi ueber ssh ein sync mit dem staging-server gemacht wenn ich dort “bzr update” eingebe. Den vollstaendigen pfad muss ich nur 1x angeben, er wird dann gespeichert. Man kann fuer bzr aber auch aliase definieren. “bzr upload-staging” und “bzr upload-production” z.B..
Auf der anderen Seite muss uebrigens kein bzr laufen.
Januar 16th, 2011 at 2:46 pm
evtl. wäre noch der Parameter –delete für den Rsync-Aufruf hilfreich, damit gelöschte Dateien auch auf dem Server gelöscht werden.
Januar 16th, 2011 at 3:06 pm
Guter Hinweis, danke
Januar 16th, 2011 at 3:37 pm
Wer auch mit FTP etwas mehr Komfort haben möchte, der sollte sich “sitecopy” anschauen: http://www.schlittermann.de/doc/sitecopy.html
Damit ist es auch möglich, nur die geänderten Dateien auf den Webserver hochzuladen. Ich möchte das Tool nicht mehr missen!
Januar 16th, 2011 at 4:03 pm
Nettes Programm. Wenn man einen Provider hat, der kein rsync via ssh anbietet ist das zumindest eine brauchbare Alternative.
Aber wenn ssh und rsync zur Verfügung steht würde ich das in jedem Fall vorziehen, da es immer noch sicherer und schneller ist
Januar 16th, 2011 at 10:54 pm
Sitecopy habe ich auch lange benutzt, echt nich schlecht. Inzwischen arbeite ich mit lftp, echt super Tool. Damit kann ich direkt auf dem Server die Daten bearbeiten, schau es Euch mal an, echt empfehlenswert, Gruss Michael
Januar 27th, 2011 at 8:54 pm
Ich bin eigentlich ein Fan von Unison. Besonders die 2-Wege Synchronisation ist ein echtes Plus, falls man es braucht. Allerdings nervt es ziemlich, dass man nicht nur wie bei rsync auch Unison auf beiden Seiten brauch, nein es muss sogar noch die gleiche Version sein. Das ist extrem nervig, wenn man zwischen verschiedenen Linux Distributionen synchronisiert. Häufig sind da unterschiedliche Versionsstände in den Repositories.