Wenn man das Backuptool Duplicity unter Ubuntu installiert, scheinen nicht alle Abhängigkeiten mitinstalliert zu werden. Das stellt man spätestens bei der ersten Benutzung fest:
BackendException: Could not initialize backend: No module named paramiko
Bei „paramiko“ handelt es sich um ein Python-Modul welches der Unterstützung des SSH2 Protokolls dient. Nachdem das ganze mittels:
apt-get install python-paramiko
nachinstalliert wurde, funktioniert auch Duplicity ohne weitere Probleme.
Wenn man einen Server betreibt ist ein Backup sehr praktisch. Viele Hoster bietet mittlerweile Backupspeicher an, auf welchen man seine Daten sichern kann. In diesem Artikel wird dabei davon ausgegangen das sich auf dem Server größere Imagedateien befinden, welche inkrementell gesichert werden sollen. Im ersten Schritt wird der Backupspeicher eingebunden. Viele Server lassen sich dabei mit SFTP ansprechen. Um dieses einzubinden muss das passende Paket installiert werden:
apt-get install sshfs
Danach erstellen wir einen Mountpunkt:
mkdir /mnt/backup
Anschließend kann das entfernte Dateisystem eingebunden werden:
sshfs :/ /mnt/backup
Für das Backup wird „rdiff-backup“ genutzt, welches über die Paketverwaltung installiert werden kann:
apt-get install rdiff-backup
Problematisch an „rdiff-backup“ ist die Tatsache, das dieses unter anderem mit Hardlinks arbeitet und diese bei SFTP unter Umständen nicht zur Verfügung stehen. Deshalb muss im ersten Schritt ein Image erzeugt werden und dieses eingebunden werden. Mittels:
rdiff-backup /etc/ /mnt/backup/etc/
kann dann anschließend das Backup angelegt werden. Möchte man ermitteln welche Backupversionen sich im Verzeichnis befinden, so kann dies durch
rdiff-backup -l /mnt/backup/etc/
bewerkstelligt werden. Damit man das ganze nicht immer per Hand erledigen muss (was bei Backups nicht ratsam wäre), habe ich das ganze in ein Skript gegossen welches auf GitHub zu finden ist.
Weitere Informationen gibt es unter:
http://wiki.ubuntuusers.de/FUSE/sshfs
http://www.nongnu.org/rdiff-backup/
http://www.thomas-krenn.com/de/wiki/Backup_unter_Linux_mit_rdiff-backup
Wenn man sich auf einem Ubuntu-Server einloggt, bekommt man meist folgende Zeilen zu sehen:
Welcome to Ubuntu 13.04 (GNU/Linux 3.8.0-31-generic x86_64) * Documentation: https://help.ubuntu.com/ System information as of Thu Oct 3 11:23:01 CEST 2013 System load: 0.0 Processes: 95 Usage of /: 71.0% of 969.52GB Users logged in: 0 Memory usage: 1% IP address for eth0: 192.168.1.50 Swap usage: 0% Graph this data and manage this system at https://landscape.canonical.com/ 0 packages can be updated. 0 updates are security updates. Last login: Sat Sep 28 15:26:35 2013 from localhost
Unter Umständen kann es aber auch passieren das man diese Meldung nicht sieht. Den auszugebenen Text findet man dabei in der Datei „/etc/motd“. Dort kann man das Verhalten beim Login allerdings nicht konfigurieren. Um die Meldung zu aktivieren, muss stattdessen die Datei „/etc/pam.d/login“ im Editor angepasst werden. Dort findet man die Zeilen:
# Prints the message of the day upon succesful login. # (Replaces the `MOTD_FILE' option in login.defs) # This includes a dynamically generated part from /run/motd.dynamic # and a static (admin-editable) part from /etc/motd. session optional pam_motd.so motd=/run/motd.dynamic noupdate session optional pam_motd.so
welche je nach Bedarf ein oder auskommentiert werden können. Sind diese Zeilen bereits einkommentiert, so liegt das Problem am Fehlen des Kommandos „landscape-sysinfo“. Sobald das passende Paket „landscape-common“ nachinstalliert wurde, funktioniert das Anzeigen der Systeminformationen nach einem Login wieder.
Möchte man sich auf einem Linux-Server per SSH Schlüssel anmelden, so kopiert man im ersten Schritt seinen Schlüssel auf den entfernten Server:
ssh-copy-id -i ~/.ssh/id_rsa.pub
Anschließend kann man sich mittels:
ssh
ohne Passworteingabe auf den Rechner einloggen. Sollte dies nicht der Fall sein, gibt es ein Problem. So kann es passieren das man trotz SSH-Schlüssel ein Passwort eingeben soll. Um die Ursache zu diagnostizieren hilft es „ssh“ im Verbose-Modus zu benutzen:
ssh -v
Im diesem Modus werden viele Debuginformationen ausgegeben, welche helfen können das Problem einzugrenzen. Das man Passwörter trotz eines SSH Schlüssels eingeben muss, liegt manchmal an falsch konfigurierten Dateirechten im „.ssh“ Ordner auf dem entfernten Rechner. Die einfachste Möglichkeit ist es hier den Ordner komplett zu entfernen, damit er vom System nochmal angelegt wird. Dazu muss der Schlüssel natürlich mittels „ssh-copy-id“ wieder auf dem Rechner angebracht werden. Alternativ ist es auch möglich die Rechte für diesen Ordner neu zu setzen:
chmod 700 /home/seeseekey/.ssh/ chmod 600 /home/seeseekey/.ssh/authorized_keys
Wenn der Verbose-Modus nicht die gewünschten Ergebnisse bringt, so sollte sich die Logdatei /var/log/auth.log“ angeschaut werden. Dort kann man dann z.B. solche Meldungen bewundern:
Sep 21 01:47:35 service sshd[34221]: Authentication refused: bad ownership or modes for directory /home/seeseekey
In diesem Fall lag es nicht nur am „.ssh“ Verzeichnis, sondern auch an dem Homeverzeichnis des Nutzers. Ein:
chmod 700 /home/seeseekey/
wirkt in einem solchen Fall wahre Wunder. Danach sollte auch die Authentifikation per SSH-Schlüssel wieder funktionieren.
Wenn man PuTTY nutzt, wird man sich sicherlich das ein oder andere Mal über die seltsame Zeichen gewundert haben. Ein schönes Beispiel dafür ist der Midnight Commander, der anstatt mit der gewohnten Linienoptik mit ganz anderen Zeichnen arbeitet. Das Problem ist hier allerdings nicht beim Server zu finden. Stattdessen muss bei PuTTY gesucht werden.
Die PuTTY Optionen
Um das Problem zu beheben, sollte man in den Einstellungen unter „Window“ -> „Translation“ das „Remote character set“ auf UTF-8 stellen. Danach gehören die fehlerhaften Zeichen der Vergangenheit an.