Ubuntu mit Software-RAID 1 installieren

Ich habe kürzlich zwei neue Festplatten für meinen Heimserver besorgt, um ein RAID 1 System einzurichten. Bei einem RAID 1 werden die beiden (oder auch mehr) Festplatten zu einer zusammengefasst. Die Daten werden dann redundant auf beiden Festplatten gespeichert (Mirroring / Spiegelung). Sollte eine Festplatte ausfallen, so bedeutet dies nicht den Verlust der darauf gespeicherten Daten, denn diese befinden sich ja ebenfalls auf der anderen Festplatte.

An dieser Stelle sei aber erwähnt, dass ein RAID 1 System kein Backup ersetzen kann. Wenn auf irgendeiner unachtsamen Art und Weise Daten gelöscht werden oder verloren gehen, sind sie natürlich auch auf beiden Festplatten nicht mehr vorhanden. Da ich aber beruflich (genauer: nebenberuflich zum Studium) oft auf kaputte Festplatten (defekte Sektoren, kaputte Elektronik, Motorschaden, Headcrash etc.) treffe, habe ich eine gewisse Paranoia entwickelt.

Die folgende Anleitung ist auch auf RAID 0 (Verdopplung der Kapazität und Geschwindigkeit, Ausfall einer Festplatte bedeutet kompletten Datenverlust) oder andere RAID Systeme anwendbar, aber ich schreibe einfach darüber, was ich bei mir gemacht habe.

Ein Software-RAID habe ich aus 2 Gründen gewählt:

  1. Mein Mainboard besitzt keinen echten RAID-Controller
  2. Ein Software-RAID ist unabhängig vom Mainboard bzw. RAID-Controller einsetzbar

Einrichtung des RAID Systems:

Ich beschreibe hier die Einrichtung eines RAID Systems bei einer Neuinstallation von Ubuntu. Diese Anleitung kann ab Ubuntu 9.10 verwendet werden. Ältere Ubuntu Versionen verwenden noch kein GRUB 2, weshalb eine andere Partitionierung notwendig ist.

Das RAID lässt sich zwar auch später einrichten, aber es gleich bei der Installation einzurichten finde ich einfacher. Außerdem ist nichts gegen ein frisches Ubuntu einzuwenden.
Für die Installation wird eine Ubuntu Server CD oder eine Ubuntu Alternate CD benötigt, die man für 10.04.1 hier herunterladen kann. Anschließend wird der Rechner von der CD gestartet und nach der Auswahl der Sprache der Menüpunkt “Ubuntu Installieren” ausgewählt (durch drücken der Eingabetaste).

Nach einigen Angaben über Land, Tastatur, Gebiet und Rechnername landet man bei dem Punkt “Festplatten partitionieren”. Dort wählt man dann “Manuell” aus.

Als nächstes kann man die Festplatten partitionieren.

Hier sieht man die beiden Festplatten (sda und sdb), in diesem Fall befindet sich noch keine Partitionstabelle auf den Festplatten. Um bei einem Festplattenausfall sda und sdb unterscheiden zu können, sollte man sich die Festplatten markieren. SCSI3 ist der erste (oder dritte?) und SCSI4 der zweite (oder vierte, entscheidend ist die Reihenfolge) SATA Anschluss.

Befinden sich bereits Partitionen oder gar Daten auf der Festplatte, müssen die Daten natürlich vorher gesichert werden, da diese verloren gehen werden. Hat man bereits die Festplatten (gleicherweise) partitioniert und möchte diese Partitionen nicht neu erstellen, bitte einfach weiter lesen.

Nun wählt man die erste Festplatte aus. Die Frage, “Neue, leere Partitionstabelle erstellen?” bestätigt man mit ja.

Nachdem die neue Partitionstabelle erstellt wurde, wählt man den freien Speicher aus.

Im nächsten Schritt wählt man dann “Eine neue Partition erstellen” aus, anschließend gibt man die Größe der ersten Partition an. Ich habe lediglich eine root (/) Partition und eine Swap Partition erstellt. Für die erste Partition wähle ich eine “Primäre Partiton”, die am “Anfang” erstellt werden soll.

Dann landet man bei dem Schritt, den Typ und die Verwendung der Partition anzugeben. Bei “Benutzen als” wählt man nicht ext4 oder Ähnliches aus, sondern “physikalisches Volume für RAID”. Dann wird noch mit dem Betätigen der Eingabetaste das “Boot-Flag” gesetzt. Damit wäre die erste Partition für den RAID Verbund fertig, nun kann man das “Anlegen der Partition beenden”.

Dann landet man wieder bei der Übersicht der Partitionen, wo man nun wieder den freien Speicher auswählt.

Nun können nach der gleichen Vorgehensweise weitere Partitionen erstellen werden. Ich habe allerdings nur noch eine Swap Partition eingerichtet. Die Swap Partition werde ich aber nicht zum RAID hinzufügen, da dies meistens eher unwichtig ist. Trotzdem werde ich zwei Swap Partitionen anlegen, die dann automatisch beide von Ubuntu genutzt werden. Die Gesamtgröße des Swaps ergibt sich aus der Summe der Swap Partitionen, die Schreibgeschwindigkeit in den Swap sollte sich damit ebenfalls erhöhen.

Also, zum Erstellen der Swap Partition wählt man wieder den freien Speicher aus und erstellt eine neue Partition. Da nun die Swap Partition die letzte Partition ist, ist es wichtig, dass am Ende der Festplatte ein wenig (128 KB sollten reichen) freier Speicher übrig bleibt, da am Ende der Festplatte Informationen über den RAID Verbund gespeichert werden. Deswegen gibt man bei der Frage nach der Größe der Partition ein bisschen weniger an.

Für weitere Partitionen bzw. diese Swap Partition wählt man eine “logische Partition”, die ebenfalls am “Anfang” des freien Speichers erstellt wird.

Für eine Swap Partition wählt man als Verwendung logischerweise “Auslagerungsspeicher (Swap)”.

Anschließend kann das Anlegen der Partition beendet werden. Damit wäre die erste Festplatte fertig partitioniert. Die zweite Festplatte benötigt nun exakt die gleiche Partitionierung, damit das RAID funktionieren kann. Dazu wählt man nun die zweite Festplatte aus und wiederholt exakt die gleichen Schritte wie bei der ersten Festplatte.

Anschließend sollte die Partitionierung der Festplatten so aussehen:

Wenn die Partitionierung beider Festplatten auf gleiche Weise geschehen ist, kann man das “Software-RAID konfigurieren”. Die Frage, ob die Änderungen auf das Speichergerät geschrieben werden sollen, bestätigt man mit ja, dann gelangt man zu diesem Bildschirm:


Hier kann man nun für jede Partition, die man dem RAID Verbund hinzufügen möchte, ein “MD-Gerät erstellen” (Multiple Devices). Für unser Vorhaben wählen wir anschließend RAID1 aus, die Anzahl der am RAID Verbund beteiligten Geräte (bzw. Partitionen, für dieses Beispiel also 2) und die Anzahl der Reserve-Geräte (hier 0).

Der nächste Schritt ist der interessanteste, hier wählt man die Partitionen aus, die für diesen RAID Verbund genutzt werden sollen:


Mit der Leertaste lassen sich die Partitionen auswählen. Wer bisher noch nicht viel mit Linux Partitionen gearbeitet hat, mag vielleicht ein wenig verwirrt sein. Aber gerade bei nur 2 Partitionen pro Festplatte ist es gar nicht so schwierig zu erkennen, dass sda die erste und sdb die zweite Festplatte ist. Wir möchten jeweils die “raid” Partition einer Festplatte dem RAID Verbund hinzufügen, also wählen wir /dev/sda1 und /dev/sdb1 aus und bestätigen mit “Weiter”.

Wenn man mehrere Partitionen für den RAID Verbund angelegt hat, wiederholt man einfach die letzten Schritte, für dieses Beispiel können wir die Software-RAID Konfiguration mit “Fertigstellen” abschließen.

Wenn bisher alles richtig ausgeführt wurde, sollte das Resultat so aussehen:

Jetzt sind wir auch fast fertig. Der RAID1 Verbund wurde richtig erstellt, aber Ubuntu wüsste noch nichts damit anzufangen, weil wir ihm noch kein Dateisystem zugeteilt haben. Also wählen wir die RAID Partition aus und stellen die Benutzung auf “Ext4 journaling file system” und den Einhängepunkt auf “/”.

Jetzt können wir endlich die “Partitionierung beenden und Änderungen übernehmen”.

Damit ist die Erstellung des RAID 1 Arrays beendet und die Installation fast geschafft. Im nächsten Schritt wird allerdings noch eine wichtige Frage gestellt: “Do you want to boot your system if your RAID becomes degraded?” Hier wird gefragt, ob das System gebootet werden soll, wenn das RAID Array nicht mehr richtig arbeitet, also z.B. eine Festplatte ausfällt. Ich empfehle hier “Nein”, denn wenn das System nur noch mit einer Festplatte problemlos bootet, merkt man schwieriger, dass eine Festplatte ausgetauscht werden muss.

Man kann dies aber auch nachträglich in der Datei /etc/initramfs-tools/conf.d/mdadm ändern. Dazu setzt man den Wert “BOOT_DEGRADED” auf “true” (bootet bei defektem RAID) oder auf “false” (bootet nicht bei defektem RAID).

Anschließend bestätigt man noch einmal, dass die Änderungen auf die Festplatten geschrieben werden sollen und der Rest ist normale Ubuntu Installation.

Überprüfung des RAID Arrays

Nach der Installation sollte man gleich testen, ob das RAID Array auch vernünftig funktioniert. Dies geschieht am besten mit dem Befehl

1
cat /proc/mdstat

dessen Ausgabe etwa so aussehen sollte:

1
2
3
4
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sda1[0] sdb1[1]
7811008 blocks [2/2] [UU]
unused devices: <none>

Hier sieht man, dass md0 ein RAID1 Device ist, dass aus den Partitionen sda1 und sdb1 besteht. Wenn dieses zu sehen ist, dann funktioniert der RAID Verbund.

Wenn eine der Festplatten nun ausfällt, dann sieht man das entweder an der Ausgabe von “cat /proc/mdstat” oder beim nächsten Booten. Die Zeile

1
md0 : active raid1 sda1[0] sdb1[1]

wird z.B. so aussehen:

1
md0 : inactive raid1 sda1[0]

Wie man sieht, fehlt die Partition sdb1 und damit wäre der Übeltäter schnell erkannt.

Austausch einer defekten Festplatte

Nachdem man die defekte Festplatte ausgetauscht hat, müssen noch einige Schritte vorgenommen werden, um die neue Festplatte in das RAID Array aufzunehmen. Zunächst entfernt man die als defekt erkannte Festplatte aus dem RAID Array.

1
mdadm /dev/md0 --remove /dev/sdb1

Nachdem man nun die Festplatte ausgetauscht hat, muss diese noch exakt wie die andere Festplatte partitioniert werden. Am einfachsten erledigt man es mit diesem Befehl:

1
sfdisk -d /dev/sda | sfdisk /dev/sdb

Jetzt kann man die Partition wieder dem RAID Array hinzufügen:

1
mdadm /dev/md0 --add /dev/sdb1

Seitdem ich ein RAID1 einsetze, kann ich zwar ruhiger schlafen, aber wenn man Vorkehrungen getroffen hat, geht so eine Festplatte ja eh nie kaputt ;-)

sfdisk -d /dev/hdf | sfdisk /dev/hde
  • Share/Bookmark

, , , , , ,

Keine Kommentare

Lang ist’s her

Nun ja, mal wieder ist seit meinem letzten Eintrag einige Zeit vergangen. Dies mag zum einen persönliche Gründe haben, unter anderem liegt es wohl an meiner Blog-Blockade und außerdem habe ich über die inhaltliche Entwicklung meines Blogs nachgedacht.

Meine letzten Beiträge hatten meist überwiegend in irgendeiner Art und Weise mit Linux zu tun. So wollte ich aber nicht weitermachen, ich möchte mehr eigene Inhalte. Über meine Pflanzen und Tiere gibt es leider nichts interessantes zu erzählen, hoffentlich komme ich bald mal zu der Geschlechtsbestimmung meiner Vogelspinne, das wäre eventuell noch interessant. Private Dinge habe ich eigentlich noch nie in meinem Blog erwähnt, da habe ich auch gar keine Lust zu und wahrscheinlich interessiert es keinen.

Ob und wie sich mein Blog zukünftig entwickeln wird, weiß ich nicht. Ich habe zwar viele Ideen, aber über halbe Sachen schreibe ich nicht gerne. Wahrscheinlich werde ich mich weiterhin mehr auf Ubuntu und alles drumherum konzentrieren. Irgendeine Umgestaltung schwirrt mir im Kopf herum, aber mal abwarten, ist ja eh nur mein Blog und nichts weltbewegendes ;-)

  • Share/Bookmark

, , ,

Keine Kommentare

vServer kostenlos

In der heutigen Zeit gibt es ja nicht mehr viel umsonst, und wenn doch, dann hat die Sache meistens eine Haken. Darum habe ich vorhin nicht schlecht gestaunt, als ich das hier gelesen hatte: Ingate verschenkt 55 vServer

Natürlich sind das keine hoch-performante vServer, aber mit 5GB Speicherplatz und 200 MB RAM (+200 MB SWAP) lässt sich schon eine Menge anfangen. Wunderbar!

Ich bin gespannt auf meinen neuen vServer und habe auch schon ein paar Ideen, die von Ingate gewünschte Resonanz sollte also kein Problem darstellen ;-)

mfg
Finn

  • Share/Bookmark

, ,

Keine Kommentare

SSH Tunnel mit SOCKS durch Proxy-Server

Öffentliche Internetzugänge in Cafés, in Hotels oder an Hochschulen sind natürlich eine wunderbare Sache, allerdings ist dieser Datenverkehr meistens für alle anderen im Netzwerk mit Leichtigkeit abhörbar. Davon betroffen ist der Großteil der Daten, nämlich der, der nicht z.B. SSL verschlüsselt ist.
An vielen (Fach)Hochschulen ist es außerdem üblich, dass der Internetzugang nur über einen Proxy-Server möglich ist, der gleichzeitig alle übrigen, nicht für das “normale” Surfen (HTTP) gedachten, Ports sperrt. Somit ist es nicht möglich, FTP Verbindungen aufzubauen, E-Mails mit einem Mailprogramm zu verwalten (POP3/IMAP und SMTP) oder sonstige andere Dienste zu nutzen.

Hat man einen SSH Server zur Verfügung, lassen sich nun diese zwei Fliegen mit einer Klatsche schlagen. Ein SSH Tunnel leitet den gesamten Datenverkehr durch die verschlüsselte SSH Verbindung, gleichzeitig lassen sich so die Port-Sperren des Proxy-Servers umgehen.

Ich nutze auf meinem Server und meinem Notebook Ubuntu, also sollte diese Anleitung kompatibel mit Debian Systemen sein und prinzipiell auch auf andere Distributionen anwendbar sein.

Einrichtung des SSH Servers:

Falls noch nicht geschehen, installiert man zuerst den SSH Server:

1
sudo apt-get install openssh-server

Um den Server später von überall erreichen zu können, lässt man ihn zusätzlich auf Port 80 laufen. Dazu öffnet man man die Datei sshd_config…

1
sudo nano /etc/ssh/sshd_config

…und fügt folgende Zeile ein:

1
Port 80

Alternativ bietet sich auch Port 443 (SSL) an, dieser ist bei vielen Proxy-Servern ebenfalls offen, allerdings hatte ich da so meine Probleme. Entscheidet man sich für den Port 80, muss man bei einem eventuell vorhandenen Webserver dessen Port umstellen.

Es ist nicht notwendig, aber recht praktisch, sich anstatt per Passwort mit dem Public Key einzuloggen. Dazu erstellt man auf dem Client ein Schlüsselpaar…

1
ssh-keygen -t rsa

…und kopiert dann den Public Key auf den Server:

1
ssh-copy-id -i ~/.ssh/id_rsa.pub user@server

Das wäre serverseitig dann auch schon alles.

Einrichtung des Clients:

Wird in dem öffentlichen Netzwerk ein Proxyserver benutzt, muss man dem SSH Client dazu bringen, auch über diesen zu verbinden. Dafür wird corkscrew benötigt:

1
sudo apt-get install corkscrew

Dann fügt man der SSH Konfiguration noch einen Eintrag für den SSH Tunnel über den Proxy hinzu:

1
nano ~/.ssh/config

Der Eintrag sieht in etwa so aus:

1
2
3
Host tunnelserver
Hostname server.xyz
ProxyCommand corkscrew proxy.abcdef.xyz 80 %h %p ~/proxy.auth

Die Pfadangabe zu einer Datei wie z.B. proxy.auth ist nur nötig, wenn der Proxy-Server einen Benutzernamen und Passwort verlangt. Der Inhalt einer solchen Datei sieht z.B. so aus:

1
username:password

Dann stellt man die Verbindung zum SSH Server her, als Host verwendet man nicht die normalen Host, sondern den in der SSH Konfiguration angegebenen (hier: tunnelserver). Der Parameter “-D 1080″ bewirkt eine dynamische Portweiterleitung, SSH fungiert hier als SOCKS Server, der auf dem Port 1080 lauscht.

1
ssh -D 1080 tunnelserver -p 80

Als nächstes wird eine Verbindung zu dem lokalen SOCKS Server hergestellt, dies kann entweder mit dem Programm tsocks oder proxychains geschehen. Mit tsocks hatte ich aber Probleme, denn die CPU Auslastung der über tsocks gestarteten Programme lag bei 100% und waren somit auch nicht benutzbar. Wen es interessiert, hier der entsprechende Bugreport.

Wer tsocks benutzen möchte, installiert es…

1
sudo apt-get install tsocks

und konfiguriert es…

1
sudo nano /etc/tsocks.conf

Dazu wird das path Beispiel auskommentiert und die Server Einstellungen am Ende entsprechend angepasst:

1
2
3
server = 127.0.0.1
server_type = 5
server_port = 1080

Möchte man z.B. nun seine E-Mails mit Mozilla Thunderbird abfragen, startet man es folgendermaßen:

1
tsocks thunderbird

Wer proxychains benutzen möchte, installiert es…

1
sudo apt-get install proxychains

…und konfiguriert es

1
sudo nano /etc/proxychains.conf

Man kommentiert stric_chain und proxy_dns aus und und der lokale SOCKS wird unter [ProxyList] hinzugefügt:

1
socks5  127.0.0.1 1080

Möchte man z.B. nun seine E-Mails mit Mozilla Thunderbird abfragen, startet man es folgendermaßen:

1
proxychains thunderbird

Das war auch schon alles. Wer es etwas komfortabler machen möchte, kann die Befehle als Starter ins Menü packen.
So kann man dann mit nur einem Klick die SSH Verbindung herstellen und anschließend mit einem weiteren Klick Thunderbird über diesen Tunnel starten.

mfg
Finn

  • Share/Bookmark

, , , , ,

Keine Kommentare

Compiz auf dem Notebook automatisch steuern

Nachdem Compiz bei mir auf dem Notebook endlich vernünftig läuft, habe ich mir Gedanken um meinen sowieso nicht mehr sehr fitten Akku gemacht. Natürlich könnte man Compiz manuell deaktivieren, wenn man per Akku unterwegs ist, aber das ist keine Lösung für faule Geeks.

Lieber setzt man sich hin, grübelt ein wenig und heraus kommt ein Bash Script. Zugegebenermaßen ist es mein erstes Bash Script, deshalb nicht böse sein, falls es nicht funktioniert. Konstruktive Kritik nehme ich gerne an :-)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#!/bin/bash
while (true)
do
#Akku- oder Netzteilbetrieb ermitteln
AKKU=$(cat /proc/acpi/ac_adapter/AC0/state)
if [ "${AKKU}" = "state:                   on-line" ]; then
# Netzteilbetrieb, laeuft Metacity noch?
PS_METACITY=$(ps -C metacity| grep metacity)
if [ "${PS_METACITY}" ];    then
# Wenn Metacity noch lauft, durch Compiz ersetzten
compiz --replace &
fi
else
# Akkubetrieb, laeuft Compiz noch?
PS_COMPIZ=$(ps -C compiz| grep compiz)
if [ "${PS_COMPIZ}" ]; then
# Wenn Compiz noch laeuft, durch Metacity ersetzen
metacity --replace &
fi
fi
sleep 10s
done

(Hilfe, wieso wollen die TAB Einrückungen nicht?)

Oder das Script zum Download: auto-compiz.sh

Das Script muss natürlich noch ausführbar gemacht werden, das habe ich früher immer vergessen und mich jedes mal wieder geärgert ;-)

1
chmod a+x auto-compiz.sh

Anschließend kann man das Script in den Autostart (System – Einstellungen – Startprogramme) eingetragen werden, z.B. so:

Es gibt auch andere Wege, das Script automatisch zu starten, z.B. über die /etc/rc.local, aber ich habe mich eben hierfür entschieden. Ich hoffe es läuft bei euch, bei mir tut es das jedenfalls.

mfg
Finn

  • Share/Bookmark

, , , ,

2 Kommentare

Bugfix: Fenster wiederherstellen mit Compiz und ATI langsam

Vielen läuft sicherlich ein kalter Schauer über den Rücken, wenn sie die Worte “ATI” und “Compiz” in einem Satz hören. Die Unterstützung für ATI Grafikkarten unter Linux hat sich in den letzten Jahren aber wesentlich verbessert. Sowohl mit den freien als auch mit dem proprietären Treibern habe ich schon lange keine Probleme gehabt.

Allerdings habe ich bisher nie Compiz benutzt, erstens weil es überwiegend nur eine Spielerei ist und zweitens weil das Wiederherstellen minimierter Fenster sehr langsam war. Allgemein schien mir alles etwas langsamer zu sein. Kürzlich habe ich dann den entsprechenden Bug-Report bei Launchpad herausgesucht.

Tja, und das ist es, was ich an Open Source Software so liebe: Bevor man das Problem genauer untersuchen kann, stellt sich heraus, dass andere schon an der Lösung des Problems arbeiten. In diesem Fall ist das Problem schon lange bekannt und inzwischen gibt es einen Bugfix (für Xorg X-Server 1.7.6) in Form eines PPA.

Die Installation gelingt damit sogar jemandem wie mir :-)
(Achtung! Fremdquellen können das System gefährden! Nervig, aber na ja, ihr wisst schon…

1
2
3
sudo add-apt-repository ppa:info-g-com/xserver-xorg-1.7.6-gc
sudo apt-get update
sudo apt-get upgrade

Bei mir (Lucid Lynx) läuft Compiz jetzt (augenscheinlich) genauso flüssig wie Metacity, sehr schön! Ich bin mal gespannt, wie lange es dauert, bis dies in ein normales Ubuntu Update einfließt. Ich muss zugeben, dass ich momentan noch kein aktiver Teil der Open Source Gemeinde bin, deshalb habe ich schlicht keine Ahnung, wie lange so etwas dauert und welche Schritte genau da hinter stecken.

Also nochmal Danke an alle, die mir ein flüssiges Compiz ermöglicht haben und überhaupt geile Open Source Software programmieren!

mfg
Finn

ppa:info-g-com/xserver-xorg-1.7.6-gcppa:info-g-com/xserver-xorg-1.7.6-gcppa:info-g-com/xserver-xorg-1.7.6-gc
  • Share/Bookmark

, , , ,

2 Kommentare

Platzsparende Backups mit rsnapshot

Ich weiß nicht, wie viele Beiträge ich schon zum Thema Backups und Datensicherung geschrieben habe, aber ich habe schon jede Menge Programme ausprobiert. Jetzt habe ich auf meinem Server rsnapshot im Einsatz, dass sich per SSH und rsync die Daten von meinem Notebook holt. Dank Gigabit kann ich das Backup sehr großzugig gestalten, aber auch per WLAN geht das ziemlich zügig, denn das Besondere an rsnapshot ist, dass es in jedem Backup nur veränderte Daten speichert. Zu unveränderten Dateien wird ein Hardlink erstellt, so dass man ohne allzu großen Platzbedarf mehrere Backups eines Systems speichern kann.

Bei der Installation habe ich mich an diesem Artikel im Ubuntuusers Wiki orientiert, er enthält eigentlich alles nötige was man über die Konfiguration wissen muss. Auf bereits dort genanntes werde ich auch nicht näher eingehen. Allerdings hatte ich anfangs Probleme rsnapshot zum Laufen zu kriegen, da ich das Backup meines Notebook schließlich per Netzwerk auf meinem Server speichern möchte. Das Backup auf eine gemountete Samba Freigabe zu speichern ist jedenfalls nicht zu empfehlen, da cifs anscheinend Probleme mit Dateirechten hat:

1
/bin/cp: Erhalten der Zugriffsrechte für „/media/Backup/daily.1/finn-laptop/sbin“: Permission denied

Also wollte den Dateitransfer per SSH erledigen. Leider unterstützt rsnapshot nur das Speichern auf lokalen Datenträgern, also habe ich den Spieß umgedreht und rsnapshot auf dem Server installiert und einen SSH Server auf meinem Notebook installiert.

Weil ich aber mehr als nur mein /home Verzeichnis sichern möchte, muss ich auf meinem Notebook den Root Account aktivieren. Unter Ubuntu ist der Root Account standardmäßig deaktiviert, schließlich kann man damit auch schnell sein System kaputt machen, wenn man nicht aufpasst, was man tut. Möchte man ein Programm als Root Ausführen, gibt es dafür den sudo Befehl. Um den Root Account zu aktivieren, verpasst man ihm einfach ein Passwort:

1
sudo passwd root

Die entsprechende Backup-Zeile in der Konfigurationsdatei /etc/rsnapshot.conf sieht dann z.B. so aus:

1
backup    root@finn-laptop.local:/    finn-laptop/

An dieser Stelle ist zu erkennen, dass ich eine Sicherung des kompletten Dateisystems vornehmen möchte. Diese wird dann im snapshot_root im Ordner finn-laptop auf dem Server gespeichert. Damit rsnapshot auch SSH benutzen kann, muss der Pfad dazu in der rsnapshot.conf eingetragen werden:

1
cmd_ssh        /usr/bin/ssh

Außerdem wird im oben genannten Wiki Artikel erwähnt, wie man rsnapshot mit anacron automatisiert. Aber damit Backups per SSH ohne Eingabe des Root Passworts auch automatisch laufen können, muss man ein Schlüsselpaar für den SSH Server (in meinem Fall ist das mein Notebook) erstellen:

1
2
3
4
5
6
7
8
9
10
11
finn@finn-laptop:~$ sudo ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase): [---leer lassen---]
Enter same passphrase again: [---leer lassen---]
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
...
The key's randomart image is.....

Für diesen Zweck ist es leider notwendig, den Schlüssel ohne ein Passwort zu erstellen.

Als nächstes kopiert man den öffentlichen Schlüssel des Root Benutzers auf den Client (also eigentlich mein Server, dort läuft rsnapshot). Vorher sind allerdings ein paar Einstellungen in der sshd_config nötig:

1
sudo nano /etc/ssh/sshd_config

Erstens muss der Root Zugriff per SSH erlaubt werden:

1
PermitRootLogin yes

Für das Übertragen muss des Schlüssels muss das Einloggen per Passwort möglich sein, nach der Übertragen deaktiviert man dies wieder:

1
PasswordAuthentication yes

Dann kann der Schlüssel kopiert werden:

1
2
3
4
5
6
7
8
9
finn@finn-server:~$ sudo ssh-copy-id -i ~/.ssh/id_rsa.pub root@finn-laptop.local
[sudo] password for finn:
root@finn-laptop.local's password:
Now try logging into the machine, with "ssh 'root@finn-laptop.local'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
### Ab hier kann PasswordAuthentication wieder auf no gesetzt werden.
finn@finn-server:~$ ssh root@finn-laptop.local
root@finn-laptop:~#

Mit anacron lässt sich das ganze auch automatisieren, allerdings weiß ich noch nicht, was passiert, wenn rsnapshot gestartet wird, aber mein Notebook ausgeschaltet ist. Falls mir jemand sagen kann, wie anacron da reagiert und ob Backups eventuell ausgelassen werden, wäre ich sehr dankbar.

Heute habe ich keine Lust mehr, mich damit zu beschäftigen ;-)

mfg
Finn

  • Share/Bookmark

, , , ,

2 Kommentare

Heimserver wieder online

Endlich! Letzten Monat habe ich das defekte Mainboard meines Heimservers eingeschickt. Diese Woche ist es endlich zurück gekommen, genauer gesagt wurde es durch ein neues ersetzt. Eigentlich ist mein Heimserver nur mein Desktop-PC, den ich eigentlich eh nicht brauche. Wenn alles nach meinen Vorstellungen läuft und Geld übrig ist, werde ich neue und noch bessere Hardware kaufen, dann kann der “Server” zurück in meinen Schrank.

Seitdem mein Server also nun wieder läuft, habe ich erst gemerkt, wie verdammt praktisch so ein kleiner Linux Server zu hause sein kann. Das Fernsehen über MythTV ist eigentlich eher eine Spielerei, aber endlich kann ich wieder schön einfach von allen Rechnern Drucken, kann ganz einfach per einer einzigen Samba Freigabe auf meine 3 Externen Festplatten zugreifen und Backups muss ich nicht mehr per Hand machen, denn das erledigt auch mein Server für mich.

Backups sind zwar schön, aber wenn sie umständlich sind und lange dauern, macht sie keiner gerne. Genau aus diesem Grund habe ich mir jetzt endlich einen Gigabit Switch gekauft. Für meine bescheidenen Zwecke soll vorerst ein günstiger 5 Port Switch der Firma TP-Link genügen. Ich besitze ebenfalls einen 5 Port 100 Mbit/s Switch und einen WLAN Access Point dieser Firma. Anfangs war ich skeptisch, da mir TP-Link bislang unbekannt war und ich schon oft Probleme mit zu billiger Hardware hatte.
Aber ich muss sagen, alle 3 Geräte laufen bestens und selbst mit dem Gigabit Switch bin ich zufrieden:

1
2
3
4
5
6
7
8
finn@finn-laptop:~$ iperf -c finn-server.local
------------------------------------------------------------
Client connecting to finn-server.local, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.9 port 60054 connected with 192.168.1.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.07 GBytes    923 Mbits/sec

Das geht wahrscheinlich noch etwas schneller, aber ich besitze sowieso nur herkömmliche Magnetspeicher-Festplatten, also reicht das völlig aus.

Linux Server zu betreiben und zu konfigurieren macht halt Spaß, was soll ich da noch großartig zu sagen? :-)

  • Share/Bookmark

,

Keine Kommentare

Mysteriöser Fehler in Enigmail/OpenPGP

Ich hatte bereits länger vor, mich mal mit verschlüsselten E-Mails und OpenPGP zu beschäftigen. Denn sichere Kommunikation und die Möglichkeit, seine Identität eindeutig nachweisen zu können, sind in diesem vom Internet regierten Zeitalter doch eher selten.

Die für den E-Mail Client Thunderbird passende Erweiterung Enigmail hatte ich sogar schon installiert, aber bisher bin ich noch nicht dazu gekommen, einen Schlüssel zu erstellen. Das Erstellen des Schlüsselpaares verlief ohne Probleme, aber dann wollte ich auch gleich ein Widerrufszertifikat erzeugen, was allerdings fehlschlug:

1
2
Das Widerrufszertifikat konnte nicht erzeugt werden.
Ein unbekannter Fehler ist aufgetreten.

Wenn man nicht weiter weiß, fragt man einfach Google und erfährt, dass das Problem bei Umlauten auftreten kann. Allerdings benutze ich weder im Verzeichnis- noch im Dateinamen Umlaute. Und an dieser Stelle wusste Google dann auch nicht weiter, also ist man wohl gezwungen, sein eigenes Gehirn zu verwenden.

Nach einigen dieser Fehlversuche habe ich dann das Logging in den Enigmail Einstellungen aktiviert und die Fehler-Konsole geöffnet, welche am Ende folgendes präsentierte:

1
2
3
4
5
6
enigmail> /usr/bin/gpg --charset utf8  --use-agent  --no-tty
--status-fd 1 --logger-fd 1 --command-fd 0 -a -o '/home/finn/Finn
Christiansen kontakt@finnchristiansen.de (0x6F15CD57) rev.asc'

--gen-revoke 0x2258D3686F15CD57

Unknown command prompt: [GNUPG:] GET_HIDDEN passphrase.enter

Die letzte Zeile war natürlich interessant, denn obwohl die Passwortabfrage in den Einstellungen aktiviert war, kam dieses Fenster nicht. Scheinbar war dies der Fehler, warum das Erstellen des Widerrufzertifikats fehlschlug.

Ich bin mir absolut sicher, dass ich nach dem Lesen der Fehlermeldung keine weiteren Einstellungen geändert habe, denn anschließend habe ich einen erneuten Versuch gemacht und plötzlich erschien die Passphrase Eingabeaufforderung und das Zertifikat wurde erfolgreich erstellt.

Mehr kann ich da leider auch nicht zu sagen, irgendwie mysteriös, aber wenigstens hat es funktioniert…

  • Share/Bookmark

, , ,

Keine Kommentare