Alle Beiträge von Kamil Günay

Homeserver 23: Webserver absichern

Der Webserver ist zwar zur Zeit nur von meinem internen Netz erreichbar, das soll sich aber später noch ändern. Aber so, wie er jetzt ist, wäre es fahrlässig, ihn für das Internet zu öffnen. Jeder könnte meine Server-Logs sehen, jeder könnte die Daten für PHP und MySQL finden, die auf meinem Server laufen. Für einen Angreifer sind das wichtige Daten. Also muss ich, bevor ich Zugriff von außen erlaube, den Webserver absichern.

Passwortschutz einrichten

Meine Server-Startseite hat Links zu allen wichtigen Punkten meines Servers. Jeder, der auf die Startseite kommt, kann sich meine Hardware, Systemdetails und Logs angucken. Also muss ich dafür sorgen, dass man dafür einen Benutzernamen und Passwort braucht. Und das ist gar nicht so schwer.

Zunächst müssen wir am Webserver was umkonfigurieren.

sudo nano /etc/apache2/sites-enabled/000-default

Ihr erinnert euch? Das ist die gleiche Datei, in der wir das DocumentRoot, also das Verzeichnis festgelegt haben, wo Apache nach den Website-Daten suchen soll. Hier müssen wir eine kleine Kleinigkeit ändern. Der Abschnitt sieht ursprünglich so aus:

    <Directory /raid1/web/HTML/>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride None
        Order allow,deny
        allow from all
    </Directory>

In der Zeile, wo “AllowOverride None” steht, müssen wir das “None” durch “all” ersetzen. Dann sieht die Zeile so aus: “AllowOverride all”.

Dann noch die Datei speichern, und den Webserver neu starten:

sudo service apache2 restart

Nun müssen im Verzeichnis “HTML” in der Web-Freigabe zwei Dateien erstellt werden. Die erste Datei erstellen wir mit einem Texteditor. Um es einfach zu machen, mache ich das wieder von der SSH-Kommandozeile:

nano /raid1/web/HTML/.htaccess

Das sudo ist hier nicht nötig, weil wir die Datei mit den Rechten des angemeldeten Benutzers, also kamil, anlegen. Und in das leere Editorfenster schreibe ich folgendes rein:

AuthType Basic
AuthName "Passwort eingeben"
AuthUserFile /raid1/web/HTML/.htpasswd
require valid-user
  • AuthType Basic: Das sorgt für die Abfrage von Nutzerdaten.
  • AuthName “Passwort eingeben”: Dieser Text erscheint im Dialogfeld, wenn jemand die Seite aufruft. Hier könnte alles mögliche stehen.
  • AuthUserFile /raid1/web/HTML/.htpasswd: Das ist der Pfad zur Passwort-Datei, dazu komme ich gleich noch.
  • require valid-user: Jeder in der Passwort-Datei eingetragene Nutzer kann sich an der Seite anmelden.

OK, soweit so gut, aber die Passwort-Datei muss noch angelegt werden. Dies machen wir nicht mit einem Editor, weil das Passwort ja verschlüsselt abgelegt werden soll. Wäre ja witzlos, wenn das Passwort im Klartext auf der Platte liegen würde. Also nehmen wir ein Programm dazu, dass der Apache gleich mitgebracht hat:

sudo htpasswd -c /raid1/web/HTML/.htpasswd kamil

Falls noch keine Passwort-Datei existiert, muss sie angelegt werden, das macht der Parameter -c. Falls die Datei bereits existiert, braucht ihr den Parameter später nicht mehr. Dann kommt der Pfad zur Passwort-Datei, und am Ende der Benutzername.

Nun werde ich nach dem Passwort für kamil gefragt, dieses gebe ich zwei mal ein. Fertig, die Datei wurde erstellt und der Nutzer eingetragen.

Wenn ich jetzt entweder mit der IP-Adresse, oder auch mit http://server01 auf die Seite gehen will, öffnet sich ein Dialogfenster, welches mich nach Benutzername und Passwort fragt. Erst dann bin ich auf meiner Startseite und kann die Links anklicken und mir z. B. die Logs angucken.

Zugriff mit SSL erzwingen

Das ist erst mal die halbe Miete, die andere Hälfte ist die Absicherung mit einem SSL-Zertifikat. Wenn ihr in einem unverschlüsselten WLAN seit, dürft ihr auf gar keinen Fall auf den Server zugreifen, wenn die Verbindung nicht mit SSL abgesichert ist. Jeder, der wollte, könnte mitlesen. Wenn aber der Zugriff über SSL erfolgt, sind eure Daten sicher. Daher richte ich jetzt den Server so ein, dass er alles nur noch über SSL macht.

SSL-Zertifikate sind teuer, wenn man sie sich von einer offiziellen CA-Stelle ausstellen lässt. Die Browser kennen die CAs, (Certificate Authorities), und vertrauen den SSL-Zertifikaten. Ich hingegen will für meinen Homeserver jetzt nicht so viel Geld ausgeben, daher erstelle ich selbst ein Zertifikat und beglaubige es auch selbst. Nachteil, die Browser kennen das Zertifikat nicht und wollen, dass man es selbst bestätigt. Auch muss dieses Zertifikat dann manuell in die liste vertrauenswürdiger Zertifikate aufgenommen werden. Aber für einen Privatserver ist das OK. Wenn ich bei meinem Mailanbieter oder bei der Bank auf solch ein Zertifikat stoßen würde, würden bei mir alle Alarmglocken Sturm läuten.

Zunächst müssen wir am Apache-Webserver die SSL-Unterstützung einschalten. Dazu müssen Module geladen werden.

sudo a2enmod ssl
sudo a2ensite default-ssl

So, nun noch selbstsignierte SSL-Zertifikate erstellen:

sudo make-ssl-cert generate-default-snakeoil --force-overwrite

Damit nun alle Zugriffe auf den Webserver verschlüsselt passieren, müssen alle HTTP-Anfragen in HTTPS-Anfragen umgeleitet werden. Dies kann Apache, aber dazu muss erst wieder ein Modul aktiviert werden:

sudo a2enmod rewrite

Nun muss noch die Regel erstellt werden, die dafür sorgt, dass die Anfragen jeweils umgeleitet werden. Dies ändert man wieder in der 000-default-Datei:

sudo nano /etc/apache2/sites-enabled/000-default

Unter die Zeile, die mit “ServerAdmin” beginnt, füge ich folgende Zeilen hinzu:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

Diese Datei speichern wir noch und müssen noch eine Datei editieren. Die default-ssl-Datei zeigt noch auf die falschen Verzeichnisse.

sudo nano /etc/apache2/sites-enabled/default-ssl

Hier müssen wieder genau die gleichen Zeilen angepasst werden, damit Apache die Webseite findet und auch die Passwortabfrage funktioniert.

Die Zeile “DocumentRoot” muss geändert werden, damit da wieder /raid1/web/HTML steht.

Die Zeile <directory /var/www></directory> muss in <directory /raid1/web/HTML></directory> geändert werden.

Die Zeile “AllowOverride None” muss zu “AllowOverride all” geändert werden.

Die Datei noch speichern, und nachdem wir all diese Änderungen gemacht haben, den Webserver noch mal neu starten:

sudo service apache2 restart

Wenn ich an meinem Windows-Rechner mit Firefox nun auf die Seite http://server01 gehe, passiert folgendes: Es erscheint eine Meldung, dass dieser Verbindung nicht vertraut wird. Diese Meldung ignoriere ich, und wähle ganz unten den Schalter “Ich kenne das Risiko”. Hierauf erscheint noch mehr Text, welcher einen warnt, und normalerweise würde ich diese Warnungen auch sehr ernst nehmen. Ich weiß aber, dass es mein Server und mein Zertifikat ist, daher gehe ich ganz unten auf die Schaltfläche “Ausnahmen hinzufügen”. In dem nun folgenden Dialog aktiviere ich die Checkbox, “Diese Ausnahme dauerhaft speichern” und klicke auf die Schaltfläche “Sicherheits-Ausnahmeregel bestätigen”.

Fertig!

Von nun an kann ich, ob nun innerhalb meines Heimnetzes oder von außen, auf meinen Server per SSL-Verbindung zugreifen. Falls ich also mal im Zug, im Hotel oder in einem anderen öffentlichen WLAN auf meinen Server will, kann jedenfalls so ohne weiteres keiner mitlesen.

Homeserver 22: Linux Handbuchseiten im Browser ansehen

Eine Kleinigkeit habe ich im vorigen Teil total vergessen, obwohl ich dies für absolut wichtig halte. Nämlich das Lesen von Manpages im Browser.

Manpages sind Handbuchseiten, Manual Pages, die die Optionen und Anwendung von Programmen beschreiben. Im Terminal ruft man die Hilfe zu ls, also dem Tool zum Verzeichnisse anzeigen, so auf:

man ls

Am Terminal liest sich das aber, ehrlich gesagt, nicht so bequem. Und ich will es mir so bequem wie möglich machen. :-)

Installation

Damit Manpages im Browser angezeigt werden können, muss ein Paket nachinstalliert werden:

sudo apt-get install man2html

Das war es schon, das Programm funktioniert schon.

Manpages im Browser ansehen

Nun kann man die Manpages bequem im Browser lesen. Ich habe für meine Server-Startseite bereits einen Link gemacht, so dass ich die Adresse hier nicht immer in die Zeile per Hand eingeben muss. Um sich die Manpages also im Browser anzugucken gibt man folgende Adresse ein: http://server01/cgi-bin/man/man2html. An Stelle von server01 kann auch ein anderer Rechnername stehen, je nach dem, wie ihr euren Server genannt habt, oder eben auch eine IP-Adresse.

Hier kann man nun in einem Suchfeld den Befehl eingeben, zu dem man Hilfe sucht, oder man kann durch die Liste der Sektionen browsen.

Das macht es doch schon viel einfacher, oder? Zumindest muss man sich nicht mehr per SSH anmelden, um mal was nachzugucken. :-)

Homeserver 21: Serverinformationen und Logs im Browser ansehen

In diesem Teil will ich mal ein Paar Anwendungen installieren, mit denen ich über den Webserver einiges an Informationen abfragen oder Datenbanken erstellen kann.

phpMyAdmin

Damit wir jetzt aber mit Datenbanken arbeiten, welche erstellen oder Sicherungen davon machen können, brauchen wir eine bequeme Anwendung. Zwar können wir das auch über die Kommandozeile machen, aber warum kompliziert, wenn es auch einfach geht? phpMyAdmin ist solch eine bequeme Form.

Installation

Wie alles in Linux, wird auch diese Anwendung auf die gleiche Weise installiert:

sudo apt-get install phpmyadmin

Während der Installation werden paar Fragen gestellt.

  • Welcher Webserver soll automatisch konfiguriert werden, damit phpMyAdmin damit funktioniert? Hier gibt es zwei zur Auswahl, ich habe Apache gewählt.
  • Datenbank mit config-db erstellen? Man kann das hinterher auch manuell machen, aber wie das geht, weiß ich nicht. Müsste ich erst lesen. Daher habe ich hier zugestimmt, damit das automatisch gemacht wird. phpMyAdmin funktioniert sonst nicht.
  • Das Datenbank-Administrator-Passwort.
  • Ein phpMyAdmin-Passwort.

Wenn man diese Angaben gemacht hat, ist phpMyAdmin bereits einsatzbereit. Man kann es sehen, wenn man den Browser öffnet, http://<ip des Servers>/phpmyadmin eingibt und die Webseite betrachtet. :-)

Übrigens, offenbar kann man in der Adresszeile des Browsers auch den Rechnernamen eingeben. mit http://server01/phpmyadmin kam ich auch auf die phpMyAdmin-Seite.

Für die Anmeldung muss man als Benutzername “root” und als Passwort das Datenbank-Administrator-Passwort eingeben, welches man bei der MySQL-Installation gewählt hat.

Wie man damit jetzt aber Datenbanken anlegt oder sichert, dazu komme ich, wenn es soweit ist.

phpSysInfo

Diese kleine Anwendung zeigt allerhand nützliche Informationen über den Server an. Hier kann man sehen, wie die Temperatur der Festplatten oder des Prozessors ist, wie der RAID-Status ist oder auch, welche Prozesse gerade laufen. Die Art der Anzeigen ist hier fast frei konfigurierbar.

Installation

Zunächst einmal lädt man sich die Anwendung von der phpSysInfo-Webseite herunter. Die geladene ZIP-Datei muss entpackt, und das darin befindliche Verzeichnis umbenannt werden. Zunächst hat es den Namen “phpsysinfo-<version>“, wobei man das Verzeichnis dann in “phpsysinfo” umbenennt. Das habe ich auf meinem Windows-Rechner gemacht.

Auf dem Server gibt es ja die Freigabe Web, die ich als Netzwerklaufwerk verbunden habe. Dort existiert ein Verzeichnis “HTML”. Hier sucht ja der Webserver nach Dateien. Dort hinein kopiere ich das Verzeichnis “phpsysinfo”. Das war es schon, mehr muss nicht installiert werden.

Konfiguration

Im Verzeichnis “phpsysinfo” liegt nun eine Datei die sich “phpsysinfo.ini.new” nennt. Diese muss umbenannt werden, so dass sie “phpsysinfo.ini” heißt.

Ich habe die INI-Datei aus Bequemlichkeit an meinem Windows-Rechner bearbeitet, aber das ist letztlich euch überlassen. In dieser Datei finden sich alle möglichen Einstellungen, die ihr dem Programm phpSysInfo übergeben könnt. Dies beinhaltet z. B. die Sprache, das Design und viele weitere Parameter. Jede Einstellung hier zu erwähnen würde den Rahmen bei weitem sprengen. Die einzelnen Einstellmöglichkeiten sind in der Datei in Englisch aber ausführlich beschrieben.

Besonders solltet ihr auf die Einstellungen für die Plugins achten. Hier könnt ihr festlegen, ob ihr Prozesse sehen wollt, RAID-Status oder S.M.A.R.T.-Informationen. Aber die meisten anderen Einstellungen können auf Standardwerten bleiben.

Aufruf

Geht mit eurem Browser einfach auf die IP-Adresse eures Servers, z. B. http://192.168.178.10/phpsysinfo. Die Seite baut sich auf, und ihr könnt die Informationen ablesen. Alternativ geht auch http://server01/phpsysinfo.

Log-Dateien im Browser betrachten

So ziemlich alles, was wir dafür brauchen, ist schon installiert. Der Webserver und PHP laufen, MySQL geht auch. Der Dienst rsyslog, den wir dafür brauchen, ist schon vorinstalliert.

Konfiguration der Datenbank

Dieser Punkt hat mich fast den ganzen Tag beschäftigt. Da gibt es so viele veraltete Informationen im Netz, aber egal. Letztlich habe ich es dann doch noch geschafft.

Damit rsyslog in eine Datenbank schreiben kann, muss ein weiteres Modul installiert werden.

sudo apt-get install rsyslog-mysql

Während der Installation werdet ihr gefragt, ob ihr die Datenbanken automatisch erstellen lassen wollt. Das beantwortet ihr mit ja. Dann wird das Datenbank-Administrator-Passwort abgefragt. Anschließend will rsyslog für sich noch ein Passwort erstellt haben. Wenn ihr diese Fragen beantwortet habt, ist rsyslog schon dabei, Logs in die Datenbank zu schreiben.

LogAnalyzer

Dies ist das Programm, mit dem ich mir die Logs angucken will. Dieses bekomme ich auf der Website des Herstellers. Die heruntergeladene Datei wird ausgepackt, und in dem jeweiligen Unterverzeichnis befindet sich ein Verzeichnis “src”. Dieses benenne ich um in “log” und kopiere es in das HTML-Verzeichnis auf der Web-Freigabe.

Nun gehe ich mit dem Browser auf die Seite http://server01/log und folge den Anweisungen.

Eigentlich sind die Felder selbsterklärend. Als Log-Typ wähle ich “MySQL native”, Benutzername ist “root” und Passwort ist das Datenbank-Administrator-Passwort. Als Host wird “localhost” eingegeben.

Hier gibt es zwei Fallen, auf die ihr achten müsst. Der Datenbankname ist vorgegeben, den löscht ihr und tragt “Syslog” ein. Die Tabelle ist ebenfalls vorgegeben, da steht “systemevents”. Da müsst ihr “SystemEvents” eintragen, sonst funktioniert es nicht.

Auf die Frage, ob ich die Benutzerverwaltung installieren will, wähle ich ja, worauf wieder Eingabefelder für Datenbank und Tabellen aufgehen. Hier ändere ich nur den vorgegebenen Datenbanknamen in “Syslog” und trage ansonsten alles so ein, wie vorher. Den Tabellenpräfix lasse ich aber so, wie es vorgegeben war. Anschließend noch schnell den ersten Admin-Benutzer einrichten, fertig.

Die Benutzerverwaltung ist wichtig, weil wir nur so an das Admin-Center rankommen, wo wir Einstellungen machen können. Sonst müssten wir mühsam irgendwelche PHP-Dateien editieren.

Wenn alles geklappt hat, werdet ihr auf die Seite geleitet, wo das Log angezeigt wird. Hier gibt es Suchfelder, viele Möglichkeiten, zu filtern, und eben, wenn alles geklappt hat, eine Menge Logeinträge.

Fazit

Leider stehen die früheren Logs hier nicht zur Verfügung. Die muss man sich evtl. mühsam an der Kommandozeile von Linux angucken. Aber ab jetzt wird jedes Syslog-Ereignis in die Datenbank geschrieben und kann hier über die Webseite ´http://server01/log` angeguckt, oder nach speziellen Einträgen gesucht werden.

Das war’s

Zumindest mal für den Augenblick. Aber damit ihr euch nicht alle URLs zu den unterschiedlichen Diensten merken müsst, könntet ihr euch ja eine Startseite auf http://server01/index.php mit den Links erstellen. Ich habe eine gebastelt, die zum einen die Links zu den Seiten hat, darunter auch die PHP-Info mit vielen nützlichen Infos anzeigt. Ihr könnt das ja als Beispielvorlage nehmen.

Kopiert den folgenden Text und fügt ihn in eine leere Textdatei ein. Speichert diese dann als index.php und kopiert sie in das HTML-Verzeichnis der Web-Freigabe.

<html>
<body>
<h1>System Startseite</h1>
<p>Hier sind die Links, um auf die wichtigsten Systembereiche zu kommen:</p>
<p><a href="/phpsysinfo">Systeminformationen mit PHPSysInfo</a></p>
<p><a href="/phpmyadmin">PHPMyAdmin</a></p>
<p><a href="/log">Log Analyzer</a></p>
<h1>PHP-Informationen</h1>
<?php
phpinfo();
?>
</body>
</html>

Damit müsst ihr euch jedenfalls nicht alle URLS merken und habt auch noch alle PHP-Funktionen und Einstellungen auf dem Bildschirm.

Homeserver 20: Webserver und Komponenten installieren

Als nächstes möchte ich auf dem Server einen Webserver installieren. Ich möchte jetzt nicht irgendwelche Webseiten im Internet anbieten, dafür wäre mein Server vielleicht zu schwach, oder zumindest mal die Anbindung ans Internet wäre dünn. Aber mit einem installierten Webserver kann man eine Menge interessanter Sachen machen. Zum Beispiel habe ich Tools gefunden, mit denen ich den Rechnerstatus abfragen kann, wie Temperatur, Lüfter und andere Parameter. Und das bequem im Browser, ohne dass ich mit SSH verbinden muss und Befehle eingeben muss. Dann habe ich Tools gefunden, mit denen ich die Server-Logdateien anzeigen und bequem durchsuchen kann. Auch das bequem im Browser. Das Management von Datenbanken geht auch super mit phpMyAdmin, also auch prima im Browser. Später soll vielleicht eine Cloud-Lösung installiert werden, ob es nun Owncloud wird, oder ein anderes Produkt welches mir CalDAV und CardDAV anbietet, weiß ich noch nicht. Aber auch hier, ein laufender Webserver sollte schon da sein.

Ich habe so was noch nie gemacht, das wird spannend. Vor allem die Konfiguration, denn besonders viele Informationen habe ich jetzt auf die Schnelle nicht gefunden. Aber, ich weiß ja ungefähr, wo die Konfigurationsdateien des Webservers abgelegt werden, versuche ich mich mal durchzuwühlen. Bei konkreten Fragestellungen kann ich ja immer noch im Netz suchen.

Es soll also Apache, der Webserver, PHP und MySQL als Datenbank installiert werden. Ob dann noch andere Tools installiert werden müssen, sehe ich dann, wenn es soweit ist.

Installation des Webservers

Das ist, denke ich, mit der einfachste Schritt. Man installiert einfach das Apache-Metapaket, und gut. Metapakete sind übrigens leer, sie fassen eine Gruppe von Paketen je nach Zweck zusammen. Das Apache-Metapaket installiert 4 oder 5 Pakete, die zum Betrieb des Webservers nötig sind. So muss man nicht alle Pakete einzeln installieren. Auch MySQL hat solche Metapakete, die die Installation vereinfachen.

Die Installation ist daher denkbar einfach. Das haben wir ja schon dutzende Male gemacht:

sudo apt-get install apache2

Fertig! Im Grunde läuft der Server schon. Man kann das sofort prüfen, in dem man im Browser mal die IP-Adresse des Servers eingibt. Aber das ist ja noch nicht alles. Ich habe ja auf dem RAID ein Verzeichnis web eingerichtet. Also muss Apache so konfiguriert werden, dass es die Webseiten-Daten dort sucht.

Konfiguration des Webservers

Der Webserver sucht seine Webseiten standardmäßig im Ordner /var/www. Das möchte ich aber nicht. Ich habe auf dem RAID einen Ordner web eingerichtet, damit ich die Website-Daten dort ablegen kann. Ich muss also dafür sorgen, dass Apache dort nach den Website-Dateien sucht.

Damit ich später kontrollieren kann, ob es geklappt hat, verschiebe ich erst mal die Test-Index-Datei, die im /var/www-Verzeichnis liegt, auf das RAID.

sudo mv /var/www/index.html -t /raid1/web/HTML

Im Verzeichnis web habe ich das Verzeichnis HTML erstellt, wo die ganzen Website-Daten reinkommen.

Nun teile ich Apache mit, dass der DocumentRoot, das ist das Verzeichnis mit den Website-Daten, auf dem RAID liegt.

sudo nano /etc/apache2/sites-enabled/000-default

In dieser Datei sind einige Werte eingestellt, aber die lassen wir erst mal in Ruhe. Zunächst müssen wir zwei Zeilen ändern.

    DocumentRoot /var/www

Diese Zeile müssen wir so ändern, dass sie auf das HTML-Verzeichnis auf dem RAID zeigt.

    DocumentRoot /raid1/web/HTML

Damit sucht der Server die Dateien nun in diesem Ordner. Es gibt aber noch eine Zeile, die die Rechte innerhalb des Verzeichnisses regelt. Hier muss auch noch etwas geändert werden.

    <Directory /var/www/>

Diese Zeile muss hinterher so aussehen:

    <Directory /raid1/web/HTML/>

Den Rest der Datei können wir in Ruhe lassen. Einfach speichern und dann noch den Webserver neu starten.

sudo service apache2 restart

Und wenn der Server wieder gestartet ist, öffnet mal euren Browser und gebt mal die IP-Adresse eures Servers ein. Ich habe meinem Server ja eine feste IP gegeben, daher weiß ich diese. Wenn alles geklappt hat, erscheint eine Webseite mit ungefähr diesem Text:

It works!

This is the default web page for this server.

The web server software is running but no content has been added, yet.

OK, läuft! Am Webserver müssen wir so jetzt nichts mehr machen.

PHP installieren

Damit gewisse in PHP programmierte Webseiten laufen können, muss PHP auf diesem Server installiert werden.

sudo apt-get install php5

Auch dies hat nun geklappt. Während der Installation wurde der Apache-Server neu gestartet. Damit ist auch die PHP-Installation erledigt.

MySQL installieren

Damit Datenbank-Anwendungen laufen können, muss ein MySQL Server und ein MySQL Client installiert werden. Und damit PHP-Anwendungen auf MySQL zugreifen können, muss PHP5-MySQL installiert werden.

sudo apt-get install mysql-server mysql-client php5-mysql

Während der Installation von MySQL werde ich nach einem Root-Passwort für den Datenbank-Administrator gefragt. Zwar ist das nicht unbedingt erforderlich, es wäre dennoch zu empfehlen, hier eines einzugeben. Es sollte sinnvollerweise nicht das gleiche Passwort sein, welches ihr am Server nutzt. Dann noch das Passwort erneut eingeben, fertig!

Fazit

Die Installation der Komponenten ist wirklich nicht so das Problem. Aber im nächsten Teil möchte ich ein paar Programme für den Webserver installieren, zum Beispiel phpsysinfo, mit dem man allerhand Statusinformationen zum Server bekommt. phpMyAdmin brauchen wir noch, um die Datenbanken managen zu können, und eine Anwendung, um die Logdateien zu durchsuchen wäre auch schön. Diese Dinge kommen in den nächsten Teilen nach und nach dran.

Homeserver 19: Nachtrag zu öffentlichen Ordnern mit Samba

Während des Betriebes ist mir aufgefallen, dass der öffentliche Ordner, den ich mit Samba eingerichtet hatte, nicht öffentlich zugänglich war. Irgendetwas war da falschgelaufen. Also habe ich mir den Vorgang noch einmal angesehen, mich noch weiter eingelesen und korrigiert. Und so funktioniert es dann auch wirklich, mehrmals ausprobiert! :-)

Anlegen des freizugebenden Ordners

Ich wechsele also in das Hauptverzeichnis meines RAIDs:

cd /raid1

Hier erstelle ich einen Ordner namens public:

sudo mkdir public

Anschließend übernehme ich den Ordner in meinen Besitz:

sudo chown -c -R kamil:kamil public

Und nun gebe ich jedem, der auf den Ordner zugreifen will, alle Rechte. Das beinhaltet lesen, schreiben und auch Programme ausführen. Das ist ein Punkt, den hatte ich vorher nicht gemacht:

sudo chmod 777 public

Kleine Anpassung der Samba-Konfiguration

Hier müssen wir zwei Dinge ändern. Zum Einen muss der Gast-Benutzer festgelegt werden, zum Anderen muss die Gast-Freigabe angepasst werden. Zunächst mal muss die Samba-Konfigurationsdatei geöffnet werden:

sudo nano /etc/samba/smb.conf

Nun könnt ihr im Editor Nano den Suchbefehl nutzen, um einen bestimmten Begriff zu finden. Der Befehl wird mit STRG+W aufgerufen. In das Eingabefeld gebt ihr “guest account”, natürlich ohne die Anführungsstriche, ein.

Hier steht in der Zeile:

   guest account = nobody

Den Wert “nobody” habe ich durch meinen Benutzernamen, also kamil, ersetzt.

Freigabe ändern

Die Freigabe, wie sie im früheren Teil beschrieben wurde, solltet ihr löschen. Ich habe die Freigabe nun angepasst, diese sieht jetzt so aus:

[Public]
path = /raid1/public
comment = Öffentlicher Ordner
public = yes
guest only = yes
writable = yes
browseable = yes
directory mask = 0777
vfs object = recycle
recycle:repository = /raid1/public/@recycle
recycle:keeptree = Yes
recycle:touch = Yes
recycle:versions = Yes
recycle:maxsize = 0
recycle:directory_mode = 0777
recycle:exclude_dir = @recycle

Nun noch die smb.conf speichern und mit

sudo service samba restart

den Samba-Service neu starten. Jetzt sollte die öffentliche Freigabe auch für Gäste mit Lese- und Schreibzugriff funktionieren.

Fazit

Fehler können leider immer mal passieren. Sobald mir welche auffallen, werde ich sie jedoch zu korrigieren versuchen. Ich hoffe aber, das war der bisher einzige Fehler. Der Rest scheint bisher super zu funktionieren. Das automatische Leeren der Netzwerk-Mülleimer klappt, das RAID arbeitet schnell und auch sonst ist mir noch nichts aufgefallen.

Aber bevor ich weitermache, dem Server mehr und mehr Arbeit aufzuhalsen, kümmere ich mich als nächstes lieber mal darum, wie man die Server-Logdateien auswerten kann. Schließlich will man ja wissen, was der Server so tut, und ob er es so tut, wie man es erwartet.

Homeserver 18: Das RAID erweitern

Mein RAID läuft ja als RAID 5. Ich habe das RAID mit der Mindestanzahl von drei Festplatten erstellt. Somit war ich in der Lage, den Server bereits zu nutzen, da ich ja schon Daten auf ihm lagern kann. Mein Time Machine Backup läuft darauf, Daten werden Stück für Stück kopiert und später kommen noch Webserver-Daten dazu.

Der Server war aber von Anfang an für ein wesentlich größeres RAID ausgelegt. Denn nicht nur für mich, sondern auch für den Rest meiner Familie, dient der Server als Datenablage. Und da kommt bei HD-Camcordern und hochauflösenden Digitalkameras so einiges an Daten zusammen. Das RAID wird jetzt also, je nach Bedarf, erweitert.

Vorher

Schauen wir uns doch mal an, wie viel Speicherplatz wir auf dem RAID gerade haben. Dazu benutze ich den Befehl “df”, kann man sich gut mit “Disk Free” als Eselsbrücke merken. :-)

df -h /raid1

Das vorangestellte sudo ist hier nicht nötig. Der Parameter -h sorgt dafür, dass die Ausgabe für Menschen lesbar wird. Sonst bekommen wir monströse Zahlen, die nur die Dateisystemblöcke angeben. Rechnen dürfen wir dann selber… Und zum Schluss das Verzeichnis /raid1, an dem ja unser RAID angedockt ist. Die Ausgabe sieht dann so aus:

Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        7.3T  4.4T  2.9T  62% /raid1

Sagt doch eigentlich alles, oder? Um die 62 % sind schon belegt, weil ich schon mit dem Kopieren der Daten angefangen habe. Ich werde aber nicht fertig, weil mir der Speicherplatz nicht ausreichen wird, das weiß ich jetzt schon. Die Zahl, die für uns jetzt interessant ist, ist die Zahl unter Size, also 7,3T (Terrabyte). Nur, damit wir später den Unterschied sehen.

RAID Erweitern

Jetzt werde ich dem RAID also zwei Festplatten hinzufügen. Wieso gerade zwei? Nun, eine, damit ich alle Daten von meinem QNAP NAS kopieren kann. Danach wird das QNAP NAS nicht mehr benötigt. Dort steckt aber schon eine ST4000VN000 drin, weil ich ursprünglich dessen RAID neu anlegen wollte. Später habe ich mich dann aber für den Bau dieses Servers entschieden. Diese Festplatte nehme ich dann natürlich aus dem NAS raus und baue sie in meinen Server ein. Hier wird nix verschwendet… :-)

Festplatten vorbereiten

Genau so, wie ich im Teil 12 beschrieben habe, müssen nun die neuen Festplatten partitioniert werden. Das sind dann die Laufwerke /dev/sde und /dev/sdf. Insbesondere bei der Festplatte, die ich aus dem QNAP NAS rausgenommen habe muss ich darauf achten, dessen Partitionstabelle mit O zu löschen und mit einer leeren zu überschreiben. Danach läuft alles wie bisher ab, Partition erstellen, Typ auf FD00 stellen und Daten mit W auf die Platten schreiben.

Festplatten in den RAID-Verbund aufnehmen

Dies passiert in mehreren Schritten. Laut einer Webseite im Internet ist es möglich, den Prozess auch mit mehreren Festplatten gleichzeitig durchzuführen. Das ist mir auch lieber, weil ich sonst für jede Festplatte erst warten müsste, bis der Synchronisationsvorgang abgeschlossen ist. Das kann Tage dauern. Die Wartezeit halbiert sich quasi, wenn man das nur ein mal tun muss… Ich Probiere es mal, falls es nicht klappt, dann halt einzeln.

Um die nun partitionierten Festplatten in den RAID-Verbund aufzunehmen, nutze ich diesen Befehl:

sudo mdadm --add /dev/md0 /dev/sde1 /dev/sdf1

Mit dem Parameter --add wird MDADM mitgeteilt, dass nun neue Festplatten hinzugefügt werden, nämlich dem RAID-Verbund /dev/md0. Und die Platten sind /dev/sde1 und /dev/sdf1.

Wir können uns auch gleich angucken, ob das zumindest schon mal geklappt hat, indem wir uns mal die mdstat angucken. Die sieht nach dieser Aktion nämlich so aus:

Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdf1[6](S) sde1[5](S) sdb1[0] sdd1[3] sdc1[4]
      7813772544 blocks super 1.2 level 5, 128k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Wie ihr jetzt sehen könnt, sind die Platten sde1 und sdf1 als Spares, also als Ersatzplatten hinzugefügt worden. Daher steht neben diesen Platten ein S in Klammern. Würde jetzt eine der ursprünglichen aktiven Platten ausfallen, würde MDADM sofort eine der Ersatzplatten nehmen, um das RAID wiederherzustellen. Das will ich ja nicht, also muss ich jetzt das RAID auf die beiden zusätzlichen platten erweitern.

RAID vergrößern

Der Grow-Modus von MDADM kann ziemlich viel. Man kann viele Parameter des RAIDs ändern. Wenn man z. B. merkt, die Chunk-Size von 128K ist zu klein, könnte man sie auf 512K erweitern oder sogar auf 64K verkleinern. Auch ein Wechsel des RAID-Level wäre möglich. Das will ich jetzt gar nicht machen, ich will die Anzahl der an dem RAID beteiligten Platten erhöhen.

sudo mdadm --grow /dev/md0 --raid-devices=5

Zuvor waren es ja 3, nun habe ich es auf 5 Platten erweitert. Die Platten sind bereits im Verbund, also erweitert MDADM das RAID auf die Spares, die schon hinzugefügt wurden.

MDADM fängt sofort damit an, das RAID auf die zusätzlichen Platten auszuweiten. Das kann man an der mdstat-Datei gut sehen, die jetzt so aussieht:

Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdf1[6] sde1[5] sdb1[0] sdd1[3] sdc1[4]
      7813772544 blocks super 1.2 level 5, 128k chunk, algorithm 2 [5/5] [UUUUU]
      [>....................]  reshape =  0.0% (927744/3906886272) finish=2565.2min speed=25377K/sec

unused devices: <none>

Das kann jetzt eine gehörige Zeit dauern. MDADM verteilt die Daten und ihre Wiederherstellungsinformationen jetzt auf die 5 Platten. Hierbei müssen eine ganze Menge Daten bewegt werden.

Die ersten paar Sekunden sind kritisch. Fällt jetzt der Strom aus, oder sonst irgendwas passiert, ist das RAID futsch. Das sind, wie gesagt, nur die ersten paar Sekunden, so um die 5 bis 10. Danach ist das RAID wieder ausfallsicher. Man könnte jetzt den Rechner sogar herunterfahren, und MDADM würde nach dem Einschalten dort weitermachen. Ich lasse ihn aber mal durchlaufen, der Prozess dauert so schon lange genug.

Auch auf die Daten kann man zugreifen. Aber auch hier, jeder Zugriff verlangsamt die Rekonstruktion des RAIDs. Und fertig sind wir ja noch nicht, es müssen noch ein paar Dinge erledigt werden. Dies können wir aber erst machen, wenn das RAID fertig ist mit Daten Umverteilen.

Man kann sich den Fortschritt des Reshape auch ganz bequem anschauen, ohne dass man ständig die mdstat-Datei aufrufen muss. Hierfür gibt es den Watch-Befehl. Der Aufruf sähe so aus:

watch cat /proc/mdstat

Das Terminal-Fenster wird jetzt komplett geleert und die mdstat-Datei angezeigt. Alle zwei Sekunden wird die Anzeige aktualisiert. Die Anzeige der Datei unterbricht man mit STRG+C, somit steht man wieder im Terminal-Fenster und kann weitere Befehle eingeben.

Natürlich macht es keinen Sinn, sich den Fortschritt die ganze Zeit anzugucken, aber wenn man mal über eine Minute sich anschauen will, was da passiert, ist das eine bequemere Lösung, als die Datei ständig immer wieder aufzurufen.

Dateisystem anpassen

Na, das hat ja mal richtig lange gedauert! Anfänglich sah es so aus, als bräuchte er ganze 2 Tage, aber so ab 50 % hat er mal so richtig Gas gegeben und war schon in 1,5 Tagen fertig.

Wir sind aber noch lange nicht fertig damit, das RAID zu erweitern. Bis eben noch sah die 3. Zeile von mdstat so aus:

      7813772544 blocks super 1.2 level 5, 128k chunk, algorithm 2 [5/5] [UUUUU]

Erst, seit der Prozess ganz fertig ist, steht die volle Größe zur Verfügung. Jetzt sieht die Zeile so aus:

      15627545088 blocks super 1.2 level 5, 128k chunk, algorithm 2 [5/5] [UUUUU]

Noch steht uns die volle Kapazität aber nicht zur Verfügung, da müssen wir noch einiges tun.

Dateisystem erweitern

Zwar hat das RAID jetzt eine höhere Kapazität, das Dateisystem ist weiterhin auf 7,3T. Wir haben quasi das bestehende Dateisystem von 3 auf 5 Platten verteilt. Also muss es auf die volle Kapazität erweitert werden.

Um die folgenden Schritte gefahrlos für Daten ausführen zu können, werde ich das Dateisystem aushängen. Dies geht mit folgendem Befehl:

sudo umount /dev/md0

Es könnte sein, dass umount den Dienst verweigert, weil das Dateisystem angeblich noch in Benutzung ist. Dies passiert vor allem dann, wenn man mit seinem Windows-Rechner verbunden war. Um das Problem zu lösen, kann man einfach vorübergehend den Samba-Service stoppen:

sudo service samba stop

Dann sollte auch das Aushängen klappen.

Um Problemen vorzubeugen, werde ich zunächst das Dateisystem auf Fehler prüfen. Klar, es ist noch neu und viel passiert ist ja darauf nicht, aber sicher ist sicher. Also starte ich die Prüfung mit folgendem Befehl:

sudo e2fsck -f -C 0 /dev/md0

Dieser Befehl erzwingt die Fehlerprüfung, auch wenn das Dateisystem als sauber markiert ist, zeigt einen Prozentbalken an und führt die Prüfung auf dem RAID /dev/md0 aus. Mit dem Prozentbalken sehe ich wenigstens, ob das Programm noch arbeitet, oder ob etwas hängt.

Die Dateisystemprüfung war jetzt bei mir problemlos durchgelaufen und keine Fehler gefunden. Also kann ich jetzt das Dateisystem erweitern. Hierzu nehme ich den Befehl:

sudo resize2fs -p /dev/md0

Der Parameter -p zeigt mir wieder einen Fortschritt an, so dass ich sehe, ob das Programm noch was tut. Die Änderung soll auf /dev/md0 ausgeführt werden. Ich habe hier jetzt hinter /dev/md0 keine Größe angegeben. Dann wird das Dateisystem auf die maximal mögliche Größe erweitert. Ich könnte aber natürlich auch eine feste Größe hier eingeben. Das möchte ich aber nicht, sondern ich will die ganze Kapazität für mich alleine! :-) Dieser Vorgang kann eine ganze Weile dauern.

Zur Sicherheit mache ich noch mal eine Dateisystemprüfung, vielleicht ist beim Vergrößern ja was schiefgelaufen? Dafür nehme ich wieder den gleichen Befehl wie oben.

Stride und Stripe-Width

Ihr erinnert euch? Der Stride-Wert ist die Chunk-Größe dividiert durch Dateisystem-Blockgröße. Diese Werte haben sich nicht geändert, also ist es immer noch 128 / 4 = 32. Aber der Stripe-Width-Wert ist der Stride-Wert mal Nutzplatten. Zuerst waren es 2 Nutzplatten, jetzt sind es 4, also 5 Platten minus eine Paritätsplatte, gleich 4. Also hat sich der Stripe-Width-Wert geändert, 32 * 4 = 128. Dies müssen wir dem Dateisystem natürlich auch klar machen.

Diese Werte lassen sich ganz einfach nachträglich anpassen. Hierzu nimmt man das Programm tune2fs. Der Befehl würde hier also so lauten:

sudo tune2fs -E stride=32,stripe-width=128 /dev/md0

Dateisystem mounten

Nun muss das Dateisystem nur noch wieder in den Verzeichnisbaum eingehängt werden. Da das RAID bereits in der fstab-Datei eingetragen ist, ist die Prozedur ziemlich einfach. Der Befehl lautet:

sudo mount /raid1

Und das war es auch schon. Schauen wir doch mal, wie viel Platz wir jetzt haben. Vorher waren es ja 7.3T. Zwischenzeitlich habe ich weiter Daten auf das RAID kopiert, aber mich interessiert ja nur der Wert unter Size. Ich verwende wieder den gleichen df-Befehl wie oben. Jetzt ist der Wert unter Size bei 15T. Ja, das sollte für die nächste Zeit reichen. :-)

Fazit

Wenn man Platz im Server hat, könnte man das RAID noch um wer weiß wie viele Platten erweitern. Ich weiß ehrlich gesagt gar nicht, wo da die Grenze ist. Aber für den Hausgebrauch reicht es alle mal.

Und jetzt noch ganz schnell die Daten vom QNAP kopieren! Weil ich eine der Platten, nämlich die 4-TB-Platte, aus dem RAID-Verbund gepflückt habe, läuft dieses jetzt im degraded mode, also im herabgesetzten Modus. Ich kann drauf schreiben, ich kann davon lesen, aber die Ausfallsicherheit ist dahin! Gut, die platten sind noch nicht alt und ein Ausfall daher nicht zu erwarten, aber sicher ist sicher, je eher ich damit fertig bin, desto besser.

Super, das hat auch geklappt. Nun ist mein Server vollständig einsatzbereit. Das war’s! Nein, natürlich nicht für das Projekt Homeserver im Eigenbau. Aber der erste große Meilenstein, das QNAP NAS zu ersetzen, ist erreicht. Alles, was jetzt kommt, ist Bonus!

Ich habe noch einige Dinge mit dem Server vor. Was sich aber wie bewerkstelligen lässt, wird sich nach und nach ergeben. Daher mache ich jetzt auch erst mal keinen Ausblick darauf, was wohl als nächstes kommt. Das weiß ich selbst noch nicht so genau. Eines der Ziele, die in nächster Zeit angegangen werden, wird wohl ein Webserver sein, der auf dem Server läuft. Nicht, weil ich Webseiten im Internet damit anbieten will, sondern weil ich z. B. von außen auf meine eigenen Daten zugreifen können will, oder vielleicht auch einen CalDAV und CardDAV Dienst für die Synchronisation meiner Handydaten betreiben will. Aber wie gesagt, ob und wie, das muss ich selbst erst noch rausfinden.

Also, auch wenn es jetzt etwas länger dauert, bis wieder ein Beitrag kommt, es kommt sicher noch mehr.

Homeserver 17: Optionen der fstab optimieren

Mein Server ist gerade dabei, das RAID zu erweitern. Das kann noch eine ganze Weile dauern, daher kümmere ich mich mal um ein Thema, dass ich etwas vernachlässigt habe. Ich will die Dateisysteme des Servers etwas optimieren, genauer gesagt, die Optionen in der fstab-Datei.

Optimierungen für die SSD

Wenn man auf der SSD etwas löscht, so wird der Block nicht sofort freigegeben. Das Dateisystem markiert den Block lediglich als “Frei”. Der Controler der SSD selbst, der auch die Speicherverwaltung und die zu beschreibenden Blöcke verwaltet, erfährt davon nichts. Dieser Block, obwohl nicht mehr benötigt, wird ständig weiter mitgeführt und bei Schreiboperationen evtl. weiter mitgeschrieben. Das kann, in gewissem Maße, die Lebensdauer der SSD beeinflussen.

Dafür gibt es den TRIM-Befehl, der solch eine Löschung auch an die Hardware der SSD meldet, so dass der Block wirklich als nicht mehr genutzt markiert wird. Linux unterstützt diesen Befehl, aber nicht standardmäßig.

Für weitere Informationen könnt ihr euch ja den Wikipedia-Artikel zu TRIM durchlesen.

Um die TRIM-Funktion zu aktivieren, fügen wir der fstab die Mount-Option “discard” hinzu.

Eine weitere Optimierung ist, die letzte Zugriffszeit auf eine Datei nicht mitzuprotokollieren. Dies ist zum einen nicht unbedingt nötig, und macht die SSD auch unnötig langsamer. Um dies zu erreichen, fügen wir die Option “noatime” hinzu.

Die fstab-Datei öffnen wir so:

sudo nano /etc/fstab

Ganz unten stehen die Zeilen mit den Dateisystemen, die zum Systemstart automatisch eingehängt werden. Die Zeile für mein Root-Verzeichnis sieht also so aus:

UUID=1d7a581e-f7da-4325-9600-438f4fabb75d /               ext4    errors=remount-ro 0       1

Wenn ich jetzt die oben angegebenen Änderungen durchführe, sieht die Zeile anschließend so aus:

UUID=1d7a581e-f7da-4325-9600-438f4fabb75d /               ext4    errors=remount-ro,discard,noatime 0       1

Beide Parameter, “discard” und “noatime”, zumindest aber “discard”, sollten wir auch in die Swap-Zeile darunter einfügen.

RAID-Optimierung

Hier gibt es nicht so viel zu optimieren. Lediglich die letzte Zugriffszeit auf eine Datei möchte ich nicht automatisch protokollieren, weil dies das RAID zum Einen langsamer macht, und zum Anderen meinen Netzwerkpapierkorb stört.

Wenn ich eine Datei in den Papierkorb lege, also lösche, setzt Linux automatisch den Löschzeitpunkt als letzten Zugriffszeitpunkt. Diese Zugriffszeit nutze ich, um die automatische Leerung des Papierkorbs zu erledigen. Öffne ich die Datei, um zu gucken, ob die wirklich weg kann, aktualisiert sich die Zugriffszeit, und das Löschen dieser Datei aus dem Papierkorb verzögert sich nach hinten.

Insgesamt wird das RAID aber langsamer, weil bei jedem Dateizugriff dieser Wert angepasst wird. Das können durchaus viele Dateizugriffe sein, wenn z. B. ein Batch-Backup läuft. Also empfiehlt es sich hier auch, die Option “noatime” zu setzen. Die Zeile sieht nach der Änderung also so aus:

/dev/md0    /raid1      ext4    noatime,defaults    0   2

Dieser Parameter beeinflusst aber nicht das gewollte Setzen der Zugriffszeit als Löschzeitpunkt. Das funktioniert weiterhin.

Fazit

Nun noch die fstab speichern, fertig. Im Falle des RAID reicht es, es mit umount auszuhängen und wieder mit mount zu mounten. Aber im Falle des Root- und Swap-Dateisystems wird man um ein Reboot nicht herumkommen. Daher sollte man vielleicht gleich einen Reboot machen.

Die Optimierungen fallen vielleicht nicht auf den ersten Blick auf, langfristig wird sich das aber schon bemerkbar machen. Windows ist, zumindest bei meinem Windows 7, standardmäßig so eingestellt, dass es die letzte Zugriffszeit nicht mitschreibt.

So, dann warte ich mal, bis mein Server mit RAID Erweitern fertig ist, dann kommt der Beitrag dazu.

Homeserver 16: Den Server als Time Machine Backupziel nutzen

Der Server hat eine riesengroße Festplatte, also warum nicht auch das TimeMachine-Backup darauf machen lassen? Zur Zeit wird mein TimeMachine-Backup auf meinem QNAP NAS gemacht. In diesem Artikel möchte ich also zwei Dinge tun, zum Einen TimeMachine auf dem Server installieren, zum Anderen meinen bisherigen Backupverlauf vom QNAP auf diesen Server übertragen. Das ist durchaus möglich. Ich habe Anleitungen im Netz gefunden, wie man Backups von einer TimeCapsule zu einer Anderen transferieren kann. Und auch wenn das Backup-Ziel QNAP oder Selbstbauserver heißt, es simuliert letztlich doch nur eine TimeCapsule. Vielleicht klappt es ja…

Vorbereitungen

Zunächst einmal muss auf dem RAID ein Verzeichnis angelegt werden, in dem das TimeMachine sein Backup speichert. Ich befinde mich bereits im Hauptverzeichnis /raid1.

sudo mkdir timemachine
sudo chown -c -R kamil:kamil timemachine

Somit wurde das Verzeichnis unter /raid1/timemachine erstellt und das Eigentum an mich übertragen.

Nun muss noch das Paket installiert werden, welches das AFP-Protokoll spricht, welches der Mac benötigt.

sudo apt-get install netatalk

Damit TimeMachine funktioniert, muss es noch konfiguriert werden. Dazu muss die Datei /etc/netatalk/AppleVolumes.default editiert werden.

sudo nano /etc/netatalk/AppleVolumes.default

Nun muss ganz unten an die Datei folgende Zeile hinzugefügt werden:

/raid1/timemachine "TimeMachine" allow:kamil options:usedots,upriv,tm cnidscheme:dbd volsizelimit:500000

Alle Optionen habe ich auch nicht verstanden. Nur das Erste ist der Pfad zu dem Verzeichnis, wo das Backup angelegt werden soll. Danach, in Anführungszeichen, der Name, wie es erscheinen soll. Der Parameter Allow bestimmt einen User, für den das TimeMachine angezeigt werden soll, hier solltet ihr einen User eintragen, der auch an eurem Mac eingerichtet ist. Der letzte Wert legt die Größe des TimeMachine-Backuplaufwerks fest. Ich habe zwar nur 500 Megabyte angegeben, aber für meinen Fall reicht das dicke. Die meisten Daten habe ich sowieso auf dem NAS und dem Mac gleichzeitig, da muss es nicht auch noch im TimeMachine-Backup vorhanden sein. Daher sind meine Backups immer recht klein.

Nun starten wir mal den Service neu.

sudo service netatalk restart

Unglaublich, aber auf der Server-Seite war es das schon! :-) Von jetzt geht es am Mac weiter.

TimeMachine auf dem Mac Konfigurieren

Das Laufwerk des Servers für die TimeMachine-Backups auszuwählen läuft auch nicht anders, als jede andere TimeCapsule oder QNAP NAS als Backup-Ziel auszuwählen.

Ich habe meine Anleitung übrigens von dieser Seite, wo noch beschrieben wird, dass im Terminal was eingegeben werden muss, damit Mac OS den Server sieht. Er hat das dort mit Mavericks gemacht, ich habe bereits Yosemite installiert. Es scheint hier nicht weiter nötig zu sein, im Terminal was einzugeben, der Server wird sofort gesehen.

Ich werde jetzt im nächsten Schritt nicht nur das TimeMachine-Backup auf dem Mac konfigurieren, sondern auch den bisherigen Backupverlauf auf den neuen Server zu ziehen versuchen.

Server als TimeMachine auswählen

Damit mein MacBook sein TimeMachine-Backup auf dem Server machen kann, müssen wir das Laufwerk dafür festlegen. Hierzu gehe ich mit der Tastenkombination VO+MM in den Statusbereich und wandere mit VO+Pfeil-rechts zu TimeMachine. Mit VO+Leertaste öffne ich das Menü und gehe auf “Systemeinstellung Time Machine öffnen”.

In diesem Dialog suche ich mir die Taste “Volume wechseln” und aktiviere diese. Nun dauert es eine kleine Weile, bis die einzelnen, über das Netzwerk erreichbaren, TimeMachine-Laufwerke angezeigt werden. Ich wähle “TimeMachine auf Server01″ aus. Die Option, das Backup zu verschlüsseln, kann jeder so setzen, wie er mag. Anschließend gehe ich auf den Schalter “Volume verwenden” und aktiviere diesen.

Es öffnet sich nun ein Fenster, wo ihr nach Benutzernamen und Passwort gefragt werdet. Ich gebe hier die Daten an, die ich auch zum Anmelden auf den Server benötige.

Wenn ihr einen komplett neuen Backupsatz anfangen wollt, und keinen älteren Backupsatz von einer TimeCapsule oder NAS kopieren wollt, war es das schon. Euer Mac wird in Zukunft seine Backups auf dem neuen Server durchführen.

Backupsatz vom QNAP NAS übernehmen

Nun beginnt ein Sekundenzähler zu zählen, nachdem das erste Backup erstellt wird. Ich warte ab, bis das Backup anfängt, und tatsächlich auch Daten übertragen werden. Das ist wichtig, damit auf dem Server die entsprechenden Strukturen erstellt werden.

Der Status ist im Fenster der TimeMachine-Einstellungen direkt über der Taste “Volume wechseln” zu sehen. Zuerst steht da, “Backup Volume suchen”, anschließend “Backup vorbereiten”. Sobald der Status zu “Backup erstellen” wechselt, und tatsächlich Daten kopiert werden, gehe ich auf die Schaltfläche “Stopp” darüber und breche das Backup ab. Anschließend suche ich mir die Taste “Aus”, um die automatischen Backups abzuschalten.

Warum das alles?

Jetzt sind auf dem Server die Strukturen erstellt, damit die Freigabe “TimeMachine” tatsächlich auch als TimeMachine fungieren kann. Die automatischen Backups habe ich ausgeschaltet, da während des Kopiervorganges des alten Backups vom QNAP-NAS auf gar keinen Fall ein weiteres Backup angelegt werden darf!

Backupverlauf vom QNAP übernehmen

Als ich die Anleitung gelesen hatte, erschien mir das ziemlich kompliziert. Jetzt, wo ich vor dem Mac sitze und das ausprobiere, wirkt das gar nicht mehr so komplex. Hier mal die Schritte:

Ich öffne irgendein Finder-Fenster, zum Beispiel das Home-Verzeichnis mit Befehl+Shift+H. Nun stoppe ich die Interaktion mit der Listenansicht und gehe mit VO+Pfeil-links zur Seitenleiste. Mit dieser interagiere ich.

Relativ weit unten befindet sich eine Freigabe, die sich “QNAP – Timemachine” nennt. Je nach dem, wie ihr euer QNAP NAS benannt habt, könnte es auch etwas anders heißen. Jedenfalls navigiere ich mit VO+Pfeil-rechts dort hin, drücke VO+Leertaste und beende die Interaktion mit der Seitenleiste. Wenn ich jetzt mit VO+Pfeil-rechts wandere, komme ich auf eine Taste, die sich “Verbinden als” nennt, die drücke ich mit VO+Leertaste.

Nun öffnet sich ein Fenster, in das ich Benutzernamen und Kennwort eingeben soll. Bei QNAP ist der Benutzer für die TimeMachine “timemachine”. In das Passwort-Feld tragt ihr das Kennwort ein, welches ihr auf der QNAP-Oberfläche für die TimeMachine festgelegt habt. Anschließend drückt ihr einfach Enter. Nun sollte in der Listenansicht “TMBackup” erscheinen. Das ist ein Ordner, den wir mit Befehl+Pfeil-runter öffnen. Damit haben wir es gemounted, so dass er als Symbol auf dem Desktop zu sehen ist.

Das Gleiche müssen wir jetzt noch mit server01 machen, um uns auch mit dessen TimeMachine zu verbinden. Ich gehe also wieder in die Seitenleiste, interagiere damit, und suche “server01″. Hier drücke ich wieder VO+Leertaste, stoppe die Interaktion mit der Seitenleiste und gehe wieder zum Schalter “Verbinden als”. Das Kennwort und der Benutzername sind die gleichen Daten, mit denen ich mich auf dem Server anmelde. Hier befinden sich dann sogar zwei Ordner, wobei mich aber nur der Ordner “TimeMachine” interessiert. Auch hier gehe ich mit Befehl+Pfeil-runter rein. Auch dieses Verzeichnis ist nun mit einem Symbol auf meinem Schreibtisch vertreten.

Laut eines englischen Support-Artikels von Apple sollte es also ausreichen, wenn ich das eine Volume auf das andere kopiere, also mache ich das doch mal…

Ich gehe also auf das Volume “TMBackup Volume” und öffne es mit Befehl+O. Hierin befindet sich eine Sparsebundle-Datei, die je nach dem Namen eures MacBooks anders heißen kann. Diese copiere ich mit Befehl+C. Nun kann ich dieses Fenster mit Befehl+W wieder schließen.

Anschließend gehe ich auf das “TimeMachine Volume” und öffne es mit Befehl+O. Hier setze ich das Sparsebundle mit Befehl+V ein.

Der Kopiervorgang startet. Je nach Größe des alten Backups kann es eine sehr lange Zeit dauern, bis die Daten kopiert sind.

Wenn das Kopieren beendet ist, schließe ich die Finder-Fenster, die noch offen sind, und werfe beide Volumes, TMBackup und TimeMachine mit Befehl+e aus.

Funktionalität überprüfen

Oh man, 8 Stunden, wieso habe ich das MacBook nicht mit einem Kabel ans Netz gehängt? Naja, nu is es passiert, und das Kopieren war erst mal erfolgreich. Aber funktioniert es denn nun auch? Das werden wir jetzt überprüfen.

Wiederherstellungsumgebung

Was nutzt uns das beste Backup, wenn wir unseren Mac nach einem Totalausfall nicht von der Recovery-Umgebung aus wiederherstellen können? Um sicherzugehen, dass unser Server das Backup auch über die Recovery-Umgebung wiederherstellen kann, gehen wir mal kurz da rein. Ich werde das Backup nicht wiederherstellen, ich will nur sehen, ob ich den Server ansprechen und die Liste der Backups angezeigt bekomme.

Um dies zu tun, müssen wir den Mac im Recovery-Modus starten. Geht mit VO+M in die Menüzeile, dort auf das Apple-Menü, hier weit unten auf Neustart. Der Mac fährt jetzt runter. Wenn er neu startet, ertönt der Mac-Einschaltton. Sobald ihr den hört, drückt ihr Befehl+r für eine ganze Weile, so um die 15 Sekunden sollten ausreichen. Da man nicht wirklich hören kann, wann die Recovery-Umgebung gestartet ist, warte ich immer so um die 1 Minute, dann drücke ich Befehl+F5, um VoiceOver zu starten.

Nun stehe ich in einer Tabelle, aus der ich eine ganze Reihe von Optionen auswählen kann. Die oberste Option ist “Aus Time Machine Backup wiederherstellen”. Das will ich ja gerade sehen, ob das geht. Also gehe ich mit VO+rechts auf “Fortfahren button” und drücke VO+Leertaste. Das sich nun öffnende Informationsfenster übergehe ich, indem ich wieder auf “Fortfahren” gehe und mit VO+Leertaste aktiviere.

Nun öffnet sich ein Fenster, in dem ich das Backup-Laufwerk auswählen kann. Angeboten werden mir die TimeMachine auf meinem server01 und TMBackup auf meinem QNAP NAS. Ich wähle TimeMachine auf server01. Anschließend gehe ich mit VO+rechts auf die Schaltfläche “Verbinden” und aktiviere diese. Es öffnet sich ein Fenster, in dem ich Benutzername und Passwort meines Benutzers auf dem Server eingebe und Enter drücke.

Es kann nun in der Tat eine ganze Weile dauern, bis das Dienstprogramm den Server nach den Backups durchsucht. Bei mir hat es fast 2 Minuten gedauert, also nicht gleich ungeduldig werden. Jedenfalls hat sich dann ein Fenster geöffnet, aus dem ich das Backup auswählen soll. Bei mir ist es “Kamils MacBook Pro auf TimeMachine”. Dann gehe ich wieder auf die Schaltfläche “Fortfahren”.

Jetzt öffnet sich in der Tat eine Liste meiner Backups. Das neueste, von heute Morgen um 06:15 Uhr, steht dabei ganz oben.

Weiter werde ich hier nicht gehen. Es ist klar, dass mein Mac die Backups findet und auch wiederherstellen würde, wenn ich jetzt weiter auf “Fortfahren” ginge. Das will ich ja nicht, ich wollte nur sehen, ob die Backups gefunden werden. Also schließe ich die Wiederherstellung mit Befehl+q. Auch die Recovery-Umgebung beende ich mit Befehl+q und bestätige die Abfrage zum Neustart.

Backup-Integrität prüfen

Nun will ich noch schnell prüfen, ob das Backup auch wirklich in Ordnung ist. Dass es da ist und auch angezeigt wird, heißt ja noch nicht, dass der Kopiervorgang auch wirklich sauber durchgelaufen ist. In regelmäßigen Abständen macht Mac OS X diese Prüfung automatisch, aber ich kann sie auch manuell anstoßen.

Mit VO+MM gehe ich in den Statusbereich und bewege mich mit VO+Rechts zu “Time Machine”. Mit VO+Leertaste öffne ich das Menü und gehe mit Pfeil runter auf “Backup jetzt erstellen”. Ich will ja kein Backup erstellen, daher drücke ich auch nicht Enter. Aber wenn ich jetzt die Wahltaste drücke, ändert sich der Befehl in “Backups überprüfen”. Genau das will ich, daher drücke ich Wahl+Enter. Die Überprüfung beginnt, und ich warte ab, ob es mir Fehler meldet. Dieser Vorgang kann auch eine ganze Weile dauern. Im Statusmenü für Time Machine kann man immer sehen, wie weit er schon ist.

Fazit

Die Überprüfung war erfolgreich, somit hat Einrichtung und Kopieren geklappt. Der Server ist nun mein TimeMachine-Backupziel. Daher stelle ich die automatische Sicherung in den Systemeinstellungen für Time Machine auch wieder auf ein.

Zuvor jedoch mache ich, nur um sicher zu gehen, ein manuelles Backup. Hierbei kann es passieren, dass ein Fenster aufgeht, welches euch darüber informiert, dass sich die Identität des Backup-Volumes geändert hat. Dies ist ja auch klar, wir haben es ja von einem anderen Server hier her kopiert. Daher ignoriere ich die Warnung und gehe auf die Schaltfläche “Dieses Volume verwenden”. Anschließend dauert es eine Weile, bis das Backup beginnt, da Time Machine es erst noch neu indizieren muss.

Eine Aufgabe weniger, die mein QNAP erledigen muss. Um genau zu sein, noch habe ich auf den Server nicht alle Daten kopiert. Wenn das aber passiert ist, wird das QNAP NAS nicht mehr gebraucht. Ich weiß noch nicht, was ich dann damit mache. Wahrscheinlich benutze ich es dann nur noch, um meine Daten zu sichern, wie ich schon sagte, ein Backup haben ist dreiviertel der Miete. :-)

Homeserver 15: Netzwerkfreigaben einrichten

Update 21:30 Uhr

Folgende Bereiche wurden aktualisiert:

  • Bei den Papierkorb-Optionen wurde eine Option hinzugefügt, damit Objekte, die innerhalb des Papierkorbs gelöscht werden können. Ohne diese Funktion werden diese Optionen nur wieder in den Papierkorb gelegt.
  • Die Cron-Jobs zum automatischen Leeren der Papierkörbe wurden umgeschrieben. Ich habe mehr recherchiert und finde, dass diese Optionen passender sind. Tests stehen jedoch noch aus, am 16. Januar weiß ich, ob es so funktioniert.

Jetzt, wo das RAID läuft, möchte ich gerne per Netzwerk auf die Platte zugreifen können. Ich möchte meine Daten auf dem Server ablegen und von PC, Mac oder sonst einem Computer drauf zugreifen können.

Linux hat ja den SAMBA File Server an Board. Grundlegende Dinge haben wir mit Samba ja schon gemacht. Von daher ist das alles jetzt gar nicht allzu neues.

Erstellen von Verzeichnissen

Genau genommen möchte ich drei Freigaben einrichten.

  • Eine große Freigabe für all meine Daten und Backups. Hier kommen alle meine Daten hinein.
  • Eine öffentliche Freigabe. Oft ist meine Family da, oder ich habe Besuch, die müssen ja nicht in meinen Daten wühlen. Daher kommt eine öffentliche Freigabe dazu, damit die mir Fotos auf das Netz legen können, und umgekehrt, ich ihnen Daten zur Verfügung stellen kann.
  • Ein Verzeichnis für Webserver-Daten. Hier kommen Daten rein, auf die über einen Webserver zugegriffen werden soll. Webserver und dergleichen kommen aber später noch dran, die Freigabe kann ich ja aber schon mal einrichten.

Der Einfachheit halber wechsele ich ins Verzeichnis /raid1, wo sich ja das große Laufwerk befindet.

cd /raid1

Und hier lege ich die Verzeichnisse für die Freigaben an.

sudo mkdir daten
sudo mkdir public
sudo mkdir web

Mit dem Befehl ls -al kann man sich nun den Inhalt des Verzeichnisses anzeigen lassen. Und hier stellt man fest, die Verzeichnisse gehören alle noch root, weswegen es später schwierig sein könnte, drauf zuzugreifen. Daher müssen wir jetzt noch das Eigentum an diesen Verzeichnissen anmelden.

sudo chown -c -R kamil:kamil daten
sudo chown -c -R kamil:kamil web
sudo chown -c -R kamil:kamil public

Jetzt, wo die Verzeichnisse mir gehören, kann ich auch munter Dateien hineinkopieren.

Erstellen der Samba-Freigaben

Dies läuft ähnlich wie das ab, was wir schon mal mit dem Home-Verzeichnis gemacht haben. Zunächst wird die smb.conf-Datei geöffnet.

sudo nano /etc/samba/smb.conf

Nun gehen wir bis ganz unten an die Datei und fügen die Freigabe an.

[Daten]
path = /raid1/daten
comment = Server-Daten
browseable = yes
writeable = yes
create mask = 0777
directory mask = 0777
force user = kamil

Netzwerk-Papierkorb

Eine der Funktionen, die ich an meinem QNAP-NAS wirklich nützlich finde, wenn man auf der Netzwerkfreigabe was löscht, verschwindet es nicht gleich im Nirvana, wie üblich, sondern wird in einen Ordner, dem Netzwerk-Papierkorb, verschoben. So etwas möchte ich auf meinem Server auch haben, und Samba bietet mir genau das! Also muss an die Freigabe eigentlich nur noch etwas angehängt werden:

vfs object = recycle
recycle:repository = /raid1/daten/@recycle
recycle:keeptree = Yes
recycle:touch = Yes
recycle:versions = Yes
recycle:maxsize = 0
recycle:exclude_dir = @recycle

Hier mal eine kurze Erläuterung, was die Werte tun.

  • vfs object = recycle: Erstellt einen Papierkorb
  • recycle:repository = /raid1/daten/@recycle: Ort des Papierkorb-Ordners. Nennt mich nostalgisch, aber ich habe mal den Namen vom QNAP-NAS übernommen.
  • recycle:keeptree = Yes: Behält Verzeichnisstruktur bei.
  • recycle:touch = Yes: Ändert das Datum des letzten Zugriffs auf das Löschdatum. Das wird später noch interessant.
  • recycle:versions = Yes: Falls eine Datei mehrfach gelöscht wird, werden alle Versionen behalten.
  • recycle:maxsize = 0: Keine Größenbeschränkung.
  • recycle:exclude_dir = @recycle: Ignoriert diesen Ordner. Was hierin gelöscht wird, wird endgültig gelöscht.

Der Ordner des Papierkorbs wird beim ersten Löschvorgang automatisch erstellt. So kann ich für alle Freigaben, für die ich das für sinnvoll halte, einen solchen Papierkorb erstellen.

Freigabe für das Web-Verzeichnis

Die komplette Freigabe für das Web-Verzeichnis sähe dann so aus.

[Web]
path = /raid1/web
comment = Webserver Dateien
browseable = yes
writeable = yes
create mask = 0777
directory mask = 0777
force user = kamil
vfs object = recycle
recycle:repository = /raid1/web/@recycle
recycle:keeptree = Yes
recycle:touch = Yes
recycle:versions = Yes
recycle:maxsize = 0
recycle:exclude_dir = @recycle

Öffentliche Gastfreigabe

Für die beiden Freigaben oben benötigt man Benutzernamen und Kennwort, um darauf zugreifenzukönnen. Das ist auch in Ordnung so, auf diesen Freigaben hat außer mir niemand was verloren. :-)

Ich möchte aber, um auch mal mit Freunden, Familie und Co Daten austauschen zu können, einen Bereich einrichten, wo man keine Nutzerdaten braucht, um sich anzumelden. Dazu braucht es einen Bereich, der nicht von einem Passwort geschützt ist. Eine solche Gastfreigabe sieht dann so aus.

[Public]
path = /raid1/public
public = yes
guest only = yes
writable = yes
browseable = yes
force user = kamil
inherit permissions = yes
vfs object = recycle
recycle:repository = /raid1/public/@recycle
recycle:keeptree = Yes
recycle:touch = Yes
recycle:versions = Yes
recycle:maxsize = 0
recycle:exclude_dir = @recycle

Papierkörbe automatisch leeren

Die Papierkörbe der drei Freigaben werden, wenn wir nichts unternehmen, mit der Zeit größer und größer werden. Weil ich aber keine Lust habe, ständig selber nachzugucken, ob es mal wieder Zeit zum Leeren ist, soll mein Server das gefälligst selber machen. :-) Hierzu kann ich natürlich einen Cron-Job bemühen. Der soll jetzt jeden morgen um 7:30 Uhr alles aus den Papierkörben löschen, was älter als 3 Tage ist.

sudo nano /etc/crontab

In der crontab gehen wir nun ganz nach unten und fügen über dem letzten # folgende Zeilen für die Netzwerkpapierkörbe ein:

30 7    * * *   root    find /raid1/public/@recycle -type f -atime +3 -exec rm -f {} \;
30 7    * * *   root    find /raid1/daten/@recycle -type f -atime +3 -exec rm -f {} \;
30 7    * * *   root    find /raid1/web/@recycle -type f -atime +3 -exec rm -f {} \;
30 7    * * *   root    find /raid1/public/@recycle -depth -type d -mtime +3 -exec rmdir --ignore-fail-on-non-empty {} \;
30 7    * * *   root    find /raid1/daten/@recycle -depth -type d -mtime +3 -exec rmdir --ignore-fail-on-non-empty {} \;
30 7    * * *   root    find /raid1/web/@recycle -depth -type d -mtime +3 -exec rmdir --ignore-fail-on-non-empty {} \;

Der Papierkorb setzt bei jeder gelöschten Datei das letzte Zugriffsdatum auf das Löschdatum. Dieser Befehl überprüft, ob eine Datei schon länger als 3 Tage im Papierkorb liegt. Den Wert -atime +3 kann jeder nach seinem Geschmack anpassen, für mich haben sich 3 Tage immer als praktikabel erwiesen. Um sicher zu gehen, könnte man hier natürlich auch 7 oder 14 hinter dem Pluszeichen eingeben.

Cron wird jedenfalls jeden Tag um 7:30 Uhr alle 3 Papierkörbe nach Dateien durchsuchen, die da schon länger als die Anzahl Tage liegen, die im Parameter -atime festgelegt wurden. Wenn solche vorhanden sind, wird es diese löschen. Somit brauche ich mich um die Papierkörbe nicht mehr kümmern.

Ich habe jetzt in jeder der drei Freigaben eine Datei im Papierkorb liegen. Ob meine Cron-Jobs wirklich funktionieren, werde ich am 15. Januar sehen. Schließlich habe ich mir diese Zeile von einer Website kopiert und hoffe einfach mal, dass das schon richtig ist… :-)

Samba Server neu starten

Nun sollten wir den Samba Server neu starten. Dafür muss der ganze Server nicht neu gestartet werden, ein Befehl im Terminal reicht.

sudo service samba restart

Wenn wir nun an einem Windows-Rechner sind, sollte man mit folgendem Befehl auf die Daten-Freigabe kommen. Drückt mal Windowstaste+R, um das Ausführen-Dialog aufzurufen. Gebt dort folgendes, gefolgt von Enter, ein:

\\server01\daten

Bei mir öffnet sich dann ein leeres Fenster. Ist ja auch klar, hab ja noch nichts dort hineinkopiert. Aber das tue ich jetzt mal, und kopiere diese Textdatei dort hin.

Das ist jetzt natürlich schwer hier darzustellen, aber das Kopieren hat hervorragend geklappt. Und als ich die Datei gelöscht habe, wurde in der Tat mein @recycle-Papierkorb erstellt.

Fazit

Nun, da die Verzeichnisse und Freigaben funktionieren, werde ich diese Freigaben dauerhaft als Netzwerkfreigaben im Explorer einrichten. Dadurch brauche ich mich nicht immer umständlich zu verbinden und kann Laufwerksbuchstaben nutzen. Somit steht dem Kopieren von Daten auf den Server auch nichts mehr im Wege.

Homeserver 14: Festplattenausfall im RAID

Im Grunde könnten wir jetzt einfach mal mit dem RAID arbeiten und Daten kopieren. Ich denke aber, bevor wir das tun, sollten wir die Gelegenheit nutzen. Noch ist nichts drauf, was wichtig ist, also können wir auch bedenkenlos experimentieren. Denn was nutzt eine Ausfallsicherheit, wenn man nicht weiß, was passiert, wenn was passiert?

Ergänzungen zum vorherigen Artikel

Zuvor aber will ich noch mal auf ein paar Punkte eingehen, die ich im vorherigen Artikel entweder vergessen habe, oder nur viel zu oberflächlich angesprochen habe.

Superblock

Ihr erinnert euch? Wenn man die Datei mdstat anzeigt, bekommt man in der dritten Zeile die Angabe “super 1.2″. Ich bin nicht weiter darauf eingegangen, dabei ist der Superblock sehr wichtig.

Der Superblock ist ein Datensatz, der auf jede am RAID beteiligte Platte geschrieben wird. Viele Angaben stehen hier drin, wie der Typ des RAID, welcher Algorithmus verwendet wird und dergleichen. Wenn ein RAID gestartet wird, wird dieser Superblock gelesen und dessen Informationen ausgewertet. So können die einzelnen Laufwerke im RAID korrekt zusammengestellt werden.

Die Angabe “super 1.2″ sagt eigentlich nichts weiter aus, als dass die Definition der Version 1.2 des Superblocks verwendet wird.

Was passiert bei Neuinstallation?

Niemals wieder darf auf diesen Laufwerken der Befehl mdadm --create verwendet werden! Es gibt widersprüchliche Texte, wobei manche sagen, es würde nur der Superblock neu erstellt, manche sagen aber, die Daten gingen verloren.

Wenn ihr, aus welchen Gründen auch immer, mal euer Linux neu installieren müsst, ist das RAID erst mal nicht vorhanden. Aber ihr braucht es nicht neu zu erstellen, sondern könnt es ganz einfach wieder zusammenstellen. Hier helfen euch die Superblöcke, die auf den Laufwerken gespeichert sind und die nötigen Informationen des RAIDs beinhalten. Und so stellt ihr euer bisheriges RAID einfach wieder zusammen:

sudo mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1

Fertig! Das RAID ist wieder da und funktioniert auch. Weil aber die Superblocks auf den Festplatten gespeichert sind, würde auch folgender Befehl funktionieren:

sudo mdadm --assemble --scan

Das RAID mit all euren Daten wäre wieder da. Nun müsstet ihr nur noch das Dateisystem einhängen und die fstab editieren. Neu anlegen braucht, und dürft, ihr das Dateisystem nicht, es ist ja schon vorhanden.

Und wie im vorherigen Artikel müsst ihr das RAID nur noch in die Konfigurationsdatei mdadm.conf eintragen. Das ist alles.

Festplatte ausgefallen, was nun?

Ein RAID ersetzt niemals ein Backup! Sichert eure Daten irgendwo auf externen Platten oder auf einem anderen Server. Ein RAID kann euch helfen, beim Ausfall einer Platte weiterarbeiten zu können oder die Daten noch eben schnell sichern zu können. Aber ein RAID schützt euch nicht vor versehentlichem Löschen, Virusbefall oder einer Alien-Invasion. OK, ein Backup schützt euch vor der Alien-Invasion jetzt auch nicht wirklich … :-) Gerade ein RAID 5 schützt euch, zumindest für eine gewisse Zeit, vor dem Ausfall einer Platte. Wenn aber zwei Platten ausfallen, was zwar ziemlich unwahrscheinlich ist aber dennoch passieren kann, sind alle Daten weg. Macht also immer ein Backup!

Wenn im RAID 5 also eine Festplatte ausfällt, so kann man dennoch weiter arbeiten. Man sollte die ausgefallene Festplatte aber so schnell wie möglich auswechseln. Denn wenn nun noch eine ausfällt, sind die Daten weg. Man hat zwar ein Backup, aber das wiederherzustellen dauert seine Zeit.

Bei fertigen NAS-Systemen, wie z. B. meinem QNAP NAS, weiß ich, welche Platte defekt ist. Zum Einen sind die Platten durchnummeriert, zum Anderen leuchtet an der defekten Platte ein rotes Lämpchen. Mein Selbstbauserver hat weder feste Laufwerksnummern noch kleine rote Lämpchen, die mir dabei helfen. Wie kriege ich also heraus, welche Platte ausgefallen ist?

Festplattenausfall simulieren

Ich könnte jetzt natürlich einfach zum Server rennen und eines der Festplattenkabel rausziehen. Das ist aber witzlos, weil ich dann ja weiß, welche Platte als kaputt simuliert werden soll. Es geht ja eben gerade darum, dass man das in der Praxis ja nicht weiß. Also werde ich MDADM einfach anweisen, eine der Platten als kaputt zu markieren.

sudo mdadm -f /dev/md0 /dev/sdc1

Somit habe ich MDADM angewiesen, die Platte /dev/sdc1 als kaputt zu markieren. Und Prompt bekomme ich auch schon eine Mail vom Server!

Fail event on /dev/md0:server01
This is an automatically generated mail message from mdadm
running on server01

A Fail event had been detected on md device /dev/md0.

It could be related to component device /dev/sdc1.

Faithfully yours, etc.

P.S. The /proc/mdstat file currently contains the following:

Personalities : [raid6] [raid5] [raid4] 
md0 : active raid5 sdb1[0] sdd1[3] sdc1[1](F)
      7813772544 blocks super 1.2 level 5, 128k chunk, algorithm 2 [3/2] [U_U]

unused devices: <none>

Wie ihr sehen könnt, sagt er mir auch schon, welche Platte evtl. kaputt ist. Die Datei mdstat zeigt dies in der zweiten Zeile an:

md0 : active raid5 sdb1[0] sdd1[3] sdc1[1](F)

Neben sdc1 ist ein F in Klammern, (F). Damit ist die Platte als kaputt markiert, auch in der dritten Zeile, [U_U], wird angezeigt, dass die mittlere Platte kaputt ist.

Übrigens, in der zweiten Zeile, wo sdc1[1] (F) steht, weiß ich nicht, was die Zahl in eckigen Klammern bedeutet. Es ist jedenfalls nicht die Position im RAID. Aber das soll erst mal nicht von Bedeutung sein.

Festplatte aus dem RAID-Verbund entfernen

Bevor wir die Festplatte nun ausbauen können, müssen wir sie erst aus dem RAID-Verbund entfernen.

sudo mdadm -r /dev/md0 /dev/sdc1

Nun ist die Festplatte aus dem RAID entfernt und kann ausgebaut werden.

Finden der Festplatte

Aber welche der 3 ist es denn nun? Wir wollen ja nicht die falsche Platte ausbauen. Das würde dem RAID nicht besonders gut tun.

Das Tool lshw, welches wir früher schon installiert haben, wird uns dabei helfen, die Festplatte zu identifizieren. Sie kann uns sagen, an welchem Port sie angeschlossen ist. Ich habe ja das Layout meiner SATA-Ports beschrieben, und dass die Platte an Port 1 ganz unten, und Port 5 ganz oben im Gehäuse eingebaut ist. Also schauen wir doch mal nach, wo welche Platte angeschlossen ist.

sudo lshw -c disk

Damit werden mir nur die Festplatten angezeigt. Würde ich lshw ohne Parameter ausführen, würde mir alles über jede verbaute Hardware angezeigt werden. Das ist aber jetzt zu viel Information, daher interessiere ich mich zur Zeit nur für die Festplatten.

Auch hier, die Ausgabe ist so umfangreich, dass ich mal nur die Ausgabe der betreffenden Festplatte hier einfüge:

  *-disk:2
       description: ATA Disk
       product: ST4000VN000-1H41
       vendor: Seagate
       physical id: 2
       bus info: scsi@2:0.0.0
       logical name: /dev/sdc
       version: SC46
       serial: S300ZDWJ
       size: 3726GiB (4TB)
       capabilities: gpt-1.00 partitioned partitioned:gpt
       configuration: ansiversion=5 guid=36d24ddd-4bcb-44bf-9de2-97e057ee3e79 sectorsize=4096

Wenn ihr also eine Ausgabe mit mehreren Festplatten bekommt, sucht nach der Zeile “logical name: /dev/sdc”. Ich habe jetzt nur mal diese Festplatte hier eingefügt.

All diese Informationen sind für euch zwar interessant, aber nicht wirklich wichtig. Die einzige Zeile, die uns eigentlich interessiert ist diese hier:

bus info: scsi@2:0.0.0

Aus dieser Zeile interessiert uns auch nur die Zahl direkt hinter dem @-Zeichen, alles andere ist irrelevant. Nun weiß ich, dass die kaputte Platte an Port 2 hängt, somit weiß ich, es ist die zweite Platte von unten. Also schalte ich den Server mal aus und ziehe nun das Kabel ab. Wenn ich den Server wieder hochfahre, müsste das RAID, wenn auch im herabgesetzten Modus, weiter arbeiten.

Das tut es sogar, der Server ist gerade ohne /dev/sdc1 normal hochgefahren, und das RAID funktioniert noch. Allerdings ist jetzt die Ausfallsicherheit nicht mehr da. Fällt jetzt noch eine Platte aus, war es das.

Noch eine Besonderheit am Rande: Die Bezeichnungen /dev/sdc usw. werden dynamisch vergeben. Somit ist /dev/sdd gerade zu /dev/sdc geworden. Das könnte hinterher wichtig sein, wenn ihr eine neue Platte einbaut und partitionieren wollt.

Neue Festplatte einbauen und ins RAID integrieren

Nun baut ihr dort, wo die kaputte Platte war, eine neue, gleichgroße Festplatte ein. Diese muss selbstverständlich noch partitioniert werden. Dies tut ihr, wie ich es im Teil 12 beschrieben habe.

Ich habe jetzt die Festplatte wieder angeschlossen und den Server wieder hochgefahren. Die Laufwerksbezeichnungen haben sich wieder verschoben, /dev/sdc wurde wieder zu /dev/sdd, wie es sich gehört, und die eigentliche Festplatte /dev/sdc ist wieder da, wo sie hingehört.

Partitioniert ist die Festplatte jetzt auch. Nun muss die Platte aber wieder in den RAID-Verbund integriert werden.

sudo mdadm -add /dev/md0 /dev/sdc1

Die Wiederherstellung des RAID-Arrays beginnt sofort von selbst. Dies kann, je nach Anzahl der Platten und der Größe aber schon mal mehrere Stunden dauern. Die Datei mdstat sagt, es könne so um die 470 Minuten dauern. OK, warte ich halt… :-(

Weiterarbeiten möglich?

Natürlich. Genau wie beim Erstellen des RAIDs, ist das Arbeiten ohne Einschränkungen möglich. Nur die Ausfallsicherheit ist halt nicht gegeben, bis das Array sich wieder komplett synchronisiert hat.

Fazit

Es können eine Vielzahl von Problemen mit einem RAID entstehen. Mit den meisten Sonderfällen hat man in der Regel aber nie zu tun. Daher gehe ich jetzt da auch nicht weiter drauf ein. Der häufigste Fall, also ein Festplattenausfall, kann jeden treffen, daher habe ich diesen auch ausführlich beschrieben. Der wohl wichtigste Aspekt ist, die richtige Platte zu finden, wenn ein Array sich im herabgesetzten Modus befindet. Die falsche Platte auszubauen wäre nicht von Vorteil.

Wenn man aber damit umgehen kann, also die richtige Festplatte herausfinden kann, die ausgetauscht werden muss, und wenn man dann noch ein aktuelles Backup seiner Daten hat, kann einem eigentlich nichts wirklich schlimmes passieren. Dann habt ihr im schlimmsten Fall eine Menge Arbeit und eine Menge Zeit verloren. Aber eure Daten sind weiterhin sicher.

Ausblick

Das Grundgerüst des Servers steht ja und funktioniert auch. Nun müssen wir es noch mit Leben füllen. Als nächstes werden daher auf dem RAID Ordner angelegt und Netzwerkfreigaben erstellt. Dann können wir auch endlich Daten auf das RAID kopieren.