Homebrew und crlf

Git ist ein verteiltes Versionskontrollsystem. Soweit so gut. Genauer werde ich in diesem Artikel nicht darauf eingehen, schreibe aber seit einiger Zeit an einer Kurzeinführung.

Nun will es der Zufall, dass ich Git für einige Webprojekte einsetze. Auf diversen Seiten, so auch auf Github gab es den Hinweis, in der Config folgendes Einzutragen:

autocrlf = true

Dies verhindert mögliche Probleme mit Windowsusern, wenn deren Editor mit LF Zeilenenden (Standard unter Unix und Linux Systemen, und eben auch unter Mac OS X) nicht zurecht kommt. Da viele Editoren unter Windows LF automatisch in CRLF (Windows Zeilenendsteuerzeichen) umwandeln, würde dies Änderungen in jeder Zeile einer geänderten Datei ergeben.

Daher solle man doch lieber gleich mit CRLF arbeiten, wenn ggf. Windowsuser mit ins Repository pushen.

So weit so gut. Bis vor einiger Zeit funktionierte das auch alles wunderbar, und funktioniert auch immer noch.

Allerdings macht das mit Homebrew Probleme. Homebrew ist ein Packetmanager für Mac OS X, ähnlich wie MacPorts oder Fink. Homebrew ist wesentlich schlanker als oben genannte Alternativen und setzt wenn möglich auf Versionen von Programmen, die bereits standardmäßig auf OS X vorhanden sind.

Auf jeden Fall hat der Aufruf von ‘brew’ mir folgende Fehlermeldung eingebracht:

-bash: /usr/local/bin/brew: /usr/bin/ruby^M: bad interpreter: No such file or directory

Ich konnte mir erst keinen Reim darauf machen. Was ist passiert? brew hat beim Updaten sich selbst überschrieben und die Zeilenendsteuerzeichen von LF auf CRLF geändert und sich damit selbst ins Nirvana geschossen, da es Ruby nicht mehr aufrufen konnte.

Ich habe /usr/local/brew in Textmate geöffnet und neu unter gleichem Namen, jedoch mit LF statt CRLF gespeichert. In der Datei /usr/local/.git/config habe ich noch folgende Zeile eingetragen:

autocrlf = false

Das überschreibt den Wert aus ~/.gitconfig und verhindert das Umwandeln.
Vielleicht ist es auch einfach Sinnvoll Auto-CRLF nur zu setzen, wenn man es wirklich braucht. Keine Ahnung.

Jedenfalls wollte ich an dem Problem, bzw. dessen Lösung teilhaben lassen, da ich irgendwie keine sinnvollen Ergebnisse ergooglen konnte.

22 Feb 2010 Noch keine Meinung Tweet this



Backup von Websites leicht gemacht

Viele Webseiten oder Blogbetreiber machen sich wenig Gedanken über Backups. Was ist, wenn der Webhoster ausversehen die Platte schreddert, oder jemand mit zu viel destruktiver Energie über eine Sicherheitslücke Zugriff auf den Server bekommt und einfach mal eure Website löscht? Was, wenn ein Update z.B. von Wordpress mal nicht sauber durch läuft, oder ihr ausversehen etwas löscht, was ihr gar nicht löschen wolltet? Diese Dinge sind in meinem Umfeld schon das ein oder andere mal geschehen, weshalb ich regelmäßig ein lokales Backup von Datenbanken und Dateien meiner Websites mache.

Ich will euch nun zeigen, wie ihr recht einfach mit UNIX-Bordmitteln entsprechende Backups ziehen könnt, ohne Shell-Zugriff auf den Webserver haben zu müssen. (Ein Backup mit Hilfe von rsync oder ähnlichem, per SSH ist dieser Methode definitiv vorzuziehen. Vorsicht, diese Methode sendet eure Logindaten unverschlüsselt übers Internet!)

Vorbereitung

Für dieses Tutorial braucht ihr das UNIX-Tool wget. Unter Mac OS X ist dies nicht standardmässig installiert, weshalb ihr es z.B. mit MacPorts, Fink oder Homebrew nachinstallieren solltet. Ich persönlich nutze Homebrew und habe darüber nicht nur wget, sondern auch andere nützliche Helferlein wie nmap, htop und einige andere installiert. Für Windows gibt es das Projekt Cygwin.

Anleitungen zur Installation dieser Paket-Manager findet ihr auf den entsprechenden Seiten. Bitte lest erst weiter wenn Ihr wget nachgerüstet habt.

Es empfiehlt sich nun, an passender Stelle eine Ordnerstruktur für eure Backups anzulegen. In meinem falle ist dies /Users/julius/Daten/websites/backups/. Wget legt dort für jede Website einen Unterordner an, um die einzelnen Backups auseinander zu halten.

Nun müssen wir ein bisschen schwarze Magie auf der Komandozeile ausführen. Aber keine Angst unter OS X gibt es Möglichkeiten, das Ganze später mit einem Mausklick oder per Cron-Job auszuführen.

wget -c --mirror --preserve-permissions  --ftp-user=user --ftp-password=pass ftp://ftp.domain.com

Mit dieser einfachen Zeile im Terminal ladet ihr euch rekursiv den kompletten Inhalt des FTP-Servers in einen neuen bzw. bestehenden Ordner herunter.
Für viele ist hier schon Schluss, da es für einfache HTML-Webseiten ausreicht.

Bitte denkt daran, dass reines FTP die Daten unverschlüsselt durchs Internet sendet. Führt dieses Script niemals in einer unsicheren Umgebung, wie z.B. einem Internetcafe oder einem nicht gesicherten WLAN aus. Wget kennt leider keine Möglichkeit per FTPs oder SFTP auf einen Rechner zu verbinden. Weiterhin liegen die Passwörter komplett unverschlüsselt auf eurer Festplatte. Dies gilt auch für Passwörter für MySQL-Datenbanken o.ä. in den heruntergeladenen Dateien. Es empfiehlt sich, die Backups und auch das Shell-Script in einem verschlüsselten Container aufzubewahren.

Wenn man möchte kann man nun diversen Voodo mit seiner Sicherheitskopie anstellen. Man kann ein rotierendes Backup erstellen, kann die Dateien mit Git Versionieren (das ist das, was ich momentan mache), sie komprimieren und auf dem Netzlaufwerk archivieren etc. Der Fantasie sind hier keine Grenzen gesetzt.

Sobald ich meinen Workflow so habe wie ich es mag, werde ich das noch mal etwas ausführlicher beschreiben.

Wie immer: Solltet ihr Fragen, Wünsche, Feedback haben, immer her damit!

09 Feb 2010 Noch keine Meinung Tweet this



Ältere Beiträge »
Ältere Beiträge »