Alle Beiträge von Kamil Günay

iCloud einfach erklärt

Dieser Beitrag erschien zunächst als E-Mail in der TuKSuB Mailingliste und wurde von Heiko Warnken verfasst. Ich habe ihn lediglich für das Blog etwas formatiert.


Bereits am 17.07.2013 habe ich diesen Text bis zum Punkt 7 veröffentlicht. Da aber mit IOS 8 Einiges hinzugekommen ist, habe ich mich dazu entschlossen, die Punkte 8 bis 12 hinzuzufügen und die Punkte 1 bis 7 zu überarbeiten.

1. iCloud, was bist Du?

Apple bietet Jeden, der ein Produkt aus der i-Reihe, also iPot, iPhone, iPad oder iMac, besitzt, die Möglichkeit, seine Daten wie Apps, Kontakte, Termine, Notizen, Aufgaben usw. zentral an einem Ort zu speichern, der von überall aus erreichbar ist. Dafür steht Jedem zunächst einmal ein Platz von 5 GB zur Verfügung. Der große Vorteil der iCloud ist seine ununterbrochene Verfügbarkeit, egal, wo Du Dich gerade befindest.

Weiterhin hat sich die iCloud mit Einführung von IOS 8 und OSX 10.10 zu einer richtigen kleinen Datenzentrale entwickelt, die sehr leistungsfähig geworden ist. Sie birgt aber auch die eine oder andere kleine Tücke in sich.

2. iCloud, wie funktionierst Du?

Die iCloud ist vom Prinzip her nichts anderes als eine Festplatte. Allerdings ist sie in ihrer Funktionsweise gegenüber einer herkömmlichen Festplatte eingeschränkt. In der iCloud können nur Daten gespeichert werden, die Apple dem User freischaltet. Zur Zeit sind dies Daten wie die gekauften Apps, Kalender, Termine, Notizen und Deine eMails. Mit den entsprechenden Apps wie z. B. der App Kontakte können Deine privaten Kontaktdaten von Dir selbst oder die Kontaktdaten Deiner Freunde usw. auf diese Festplatte, der iCloud gespeichert und jederzeit wieder abgerufen werden.

3. Organisatorisches in der iCloud

Um dies vernünftig organisiert zu bekommen, stellt die iCloud eine fest definierte Ordnerstruktur zur Verfügung. So befinden sich in der iCloud Ordner für

  • Deine Adress-Kontaktdaten (contacts)
  • Deine Termine (calendars)
  • Deine eMails (mail)
  • Deine Datensicherungen (backups)
  • sowie für Deine Notizen (notices)

Da Du mehrere Kalender anlegen kannst, befinden sich im Ordner für die Kalender (calendars) weitere Ordner für die verschiedenen Kalender. Hier hat Apple uns bereits einige Arbeit abgenommen und stellt 3 Kalender bereits zur Verfügung. Dies sind die Kalender

  • privat (calendars/home)
  • Arbeit (calendars/work) und
  • Geburtstage (calendars/birthday)

Außerdem kannst Du von Deinen verschiedenen Geräten mehrere Backups erstellen. Hierfür legt die iCloud im Ordner Backups ebenfalls weitere Ordner an. Diese Unterordner tragen den Namen Deines Mobilgerätes.

Hast Du Dein iPhone z. B. den Namen “iPhone von Silvio” gegeben, befindet sich im Ordner Backups genau dieser Ordner mit dem Namen “iPhone von Silvio”. Und in diesem Ordner “iPhone von Silvio” befinden sich die Backups bzw. Datensicherungen des besagten Mobilgerätes. In meinem persönlichen Fall befinden sich diese Ordner für Backups in der iCloud:

  • mein iPhone (backups/iPhone von Heiko)
  • mein iPad (backups/iPad von Heiko)

Außerdem können einige Apps, die auf dem Mobilgerät installiert sind, selbständig weitere Ordner anlegen und darin ihre Daten ablegen. So kann Navigon z. B. seine Favoriten in der iCloud ablegen, damit sie auf allen angeschlossenen Geräten identisch sind.

4. iCloud mit iPhone, iPad und Mac

Die iCloud unterstützt bis zu 5 unterschiedliche Geräte. Dies können 5 iPhones sein, aber auch 5 Geräte unterschiedlicher Bauart. Bei mir sind es zzt. 4 Geräte:

  1. mein iPhone 5S
  2. mein iPad 2
  3. mein MacBook pro und
  4. mein Windowsrechner (iTunes)

Ich könnte also noch ein weiteres Gerät mit meiner persönlichen iCloud verknüpfen. Benötige ich mehr als 5 Geräte, gibt es 2 Möglichkeiten:

  1. Du löscht aus der Liste  der verknüpften Geräte ein Gerät oder
  2. Du kaufst Dir weitere 5 GB iCloudspeicher, zu dem Du bis zu 5 weitere Geräte an Deine iCloud hängen kannst.

Letztere Möglichkeit solltest Du aber nur dann verwenden, wenn es beim besten Willen nicht anders geht, da die Zusammenarbeit der mit der iCloud verknüpften Geräte mit steigender Anzahl zunehmend langsamer wird.

5. Daten auf allen Geräten gleich halten (synchronisieren)

Die Möglichkeit, all Deine Daten auf allen Geräten zu synchronisieren, ist die Hauptaufgabe der iCloud. Hierzu muss nur jedes Gerät mit deiner Apple-ID und Deinem Kennwort in der iCloud angemeldet werden. Ist die Anmeldung erfolgreich, dauert es nur wenige Sekunden, bis die Daten der iCloud auf dem angemeldeten Gerät zu sehen ist. Bei Apps kann dies aufgrund der größeren Datenmenge etwas länger dauern. Besitzt Du schon länger ein iPhone und möchtest Dir jetzt Dein iPad einrichten, genügt es, auf dem iPad Deine Apple-ID und das passende Kennwort einzugeben, damit die Daten wie Termine, Kontakte, Apps usw. direkt auf Dein iPad kopiert werden. Bei den Apps gibt es eine kleine Einschränkung. Es werden nämlich nur Apps kopiert, die auch für das iPad geeignet sind. Apps, die ausschließlich für das iPhone entwickelt wurden, wirst Du auf Deinem iPad nicht finden. Ebenso verhält es sich mit Apps, die speziell für das iPad entwickelt wurden. Diese wirst Du auf keinem iPhone finden. So können schon mal gerade bei den Apps Unterschiede in Erscheinung treten.

Jetzt stellt sich aber die Frage, warum die iCloud nicht so schnell voll ist, wie man erwarten müsste. Schließlich habe ich doch rund 30 Apps mit einer Gesamtkapazität von 11 GB Speicherplatzbedarf. Die iCloud müsste also sehr schnell voll sein. Normalerweise ist das richtig. Allerdings werden für die Apps nicht die Apps selbst gespeichert, sondern lediglich der Speicherort im Appstore, und das sind dann nur noch wenige Bytes (Zeichen). Das hat aber einen kleinen Nachteil. Solltest Du nämlich Apps gesichert haben, die es beim Zurückspielen Deines Backups nicht mehr im AppStore gibt, werden diese Apps natürlich auch nicht mehr auf Deinem Geräte gespeichert.

Gibst Du nun auf dem iPhone z. B. einen neuen Termin ein, wird dieser in der iCloud gespeichert und erscheint nur wenige Sekunden später auch auf allen anderen Geräten, die in der iCloud Deiner Apple-ID zugeordnet sind. Dies betrifft auch das Löschen oder Ändern eines Termines, eines Kontaktes oder all anderer Daten in Deiner iCloud.

Wenn diese Synchronisation von Gerät zu Gerät nicht funktioniert, solltest Du Dir die Einstellungen des Gerätes ansehen, auf dem die Synchronisation nicht funktioniert. Gehe hierzu in die App Einstellungen und doppeltippe hier auf iCloud. Hier aktiviere alle Daten, die Du synchronisiert haben möchtest. Danach schließt Du das Einstellungsfenster. Nach maximal 1 Minute sollten Deine Daten auf diesem Gerät ebenfalls zu finden sein. Tipp: Die Synchronisation erfolgt sofort, nachdem das Gerät in einem WLAN eingeloggt und ans Netzkabel angeschlossen ist.

6. Datensicherungen in der iCloud

Die Datensicherung, also das Speichern sämtlicher Einstellungen des iPhones, iPad oder iPot, ist eine sehr nützliche Sache. Doch ich warne davor, die Datensicherung ausschließlich in der iCloud zu erledigen. Ich rate Jedem, wenigstens einmal nach der vollständigen Einrichtung des Mobilgerätes, eine Datensicherung auf der Festplatte Deines Rechners mit Hilfe von iTunes durchzuführen. Warum? Frage: Wie kommst Du an Deine Datensicherung, wenn Du das Kennwort zu Deiner Apple-ID vergessen hast oder noch schlimmer, Du hast Deine Apple-ID vergessen? Richtig. Gar nicht. Deshalb ist es sinnvoll, eine Datensicherung auf der eigenen häuslichen Festplatte zu haben, damit Du sie im Notfall auf Dein iPhone zurückspielen kannst. Und schon hast Du Deine Apple-ID wieder. Wenn Du Dein Kennwort vergessen hast, kannst Du Dir auf apple.com jederzeit ein neues Kennwort zuschicken lassen oder selbst festlegen.

Die Datensicherung in der iCloud erfolgt normalerweise automatisch, wenn das iPhone in ein Wlan eingeloggt und an Netzstrom angeschlossen ist. Davon bekommt man normalerweise gar nichts mit, da Du Dein iPhone ganz normal weiternutzen kannst. Solltest Du das iPhone während eines Backups vom Netzstecker ziehen, wird der Backupvorgang davon nur dann berührt, wenn Dein Handyakku unter 20 % liegt, denn in diesem Fall erhälst Du nicht nur eine Meldung, dass der Akku schwach ist, sondern danach auch die Frage, ob das laufende Backup gestoppt werden soll. Dann einfach Netzkabel wieder einstecken und auf “nein” tippen und einfach mal warten, bis der Akku wieder voll ist.

7. Neueinrichtung eines IOS-Gerätes mit der iCloud

Wenn Du ein neues Gerät einrichtest, wird während der Ersteinrichtung nach Deiner Apple-ID und dem dazu passenden Kennwort gefragt. Konnte sich das neue Gerät in der iCloud erfolgreich anmelden, bietet es Dir die Möglichkeit an, ein Backup aus der iCloud auf das neue Gerät zu spielen. An dieser Stelle möchte nicht nur Apple, sondern auch ich, dringend davor warnen, ein iPhone4 Backup auf z. B. einem iPad Mini zu spielen. Die Chance, dass das neue Gerät nicht wie gewünscht oder wie erwartet funktioniert, liegt immerhin bei 50 zu 50. Darum bitte ein jungfräuliches Neugerät prinzipiell komplett durchkonfigurieren und danach eine Datensicherung machen. Wenn Du aber Dein iPhone auf Werkseinstellungen zurücksetzen musstest, dann ist das Rückspielen des Backups aus der iCloud möglicherweise sogar sehr sinnvoll. Dann achte aber darauf, dass Du ein Backup zurückspielst, in dem evtl. vorhandene Probleme nicht existierten.

Mit IOS 8.0 hat Apple die funktionalität der iCloud erweitert. In den nachfolgenden Kapiteln 8 bis 12 gehe ich näher auf diese Änderungen ein.

8. Das iDrive

Das iDrive ist eine kleine externe Festplatte. Auf Ihr können alle möglichen Daten gespeichert werden, auf die du mit Deinem iPhone, iPot, iPad oder iMac Zugriff hast. So kannst Du z. B. in Pages einen Text schreiben und diesen in der iCloud speichern. Die Speicherung erfolgt bei Bedarf auch auf dem iDrive. Alle Geräte, die Deiner APPLE-ID zugeordnet sind und Zugriff auf das iDrive haben, können nun auf die Daten auf dem iDrive zugreifen. Dies betrifft sämtliche Geräte aus der i-Serie von Apple. Ich habe es nicht geschafft, mit meinem Windows-Rechner einen Zugriff auf das iDrive zu erhalten. Ob die im April 2015 erhältliche AppleWatch auf das iDrive zugreifen kann, bleibt abzuwarten. Du kannst auf dem iDrive beliebig Ordner und Dateien erstellen, kopieren, umbenennen oder löschen. Eben genauso, wie auf der Festplatte Deines Rechners zu Hause.

Leider ist das iDrive mit 2 oder 5 GB etwas klein geraten, so dass es sich kaum lohnen dürfte, das iDrive ausgiebig zu nutzen.

9. Familienfreigabe

Die Familienfreigabe ist eine sehr schöne und meiner Meinung nach nützliche Erweiterung der iCloud. Du kannst jedes beliebige Familienmitglied, einen Freund oder eine fremde Person in Deine Familie aufnehmen. Du musst nur die Apple-ID des aufzunehmenden Mitgliedes kennen. Da Du in Deine Familie jedes Dir bekannte oder unbekannte Mitglied aufnehmen kannst, ist der Begriff “Familie” eigentlich etwas falsch gewählt. Meiner Meinung nach wäre die Bezeichnung “Gruppe” statt “Familie” sinnvoller gewählt.

Voraussetzung zur Einrichtung einer Familie ist, dass das “Familienoberhaupt” eine Kreditkarte besitzt. Alle Familienmitglieder können dann Einkäufe von dieser Kreditkarte tätigen. Hat ein hinzugefügtes Familienmitglied noch ein iTunes-Guthaben, so wird das zuerst verbraucht, bevor die Kreditkarte belastet wird. Das Familienoberhaupt kann festlegen, ob ein Kauf von ihm noch genehmigt werden muss, oder eben nicht.

Eine App, ein Musiktitel oder ein Video, welches von einem Mitglied der Familie gekauft wurde, kann von allen anderen Familienmitgliedern ebenfalls genutzt werden. Einzige Voraussetzung hierfür ist nur, dass der Entwickler der App die Familienfreigabe für seine App aktiviert hat.

Wenn von einem Mitglied ein Kauf getätigt wurde, erhält zunächst das betreffende Mitglied einen Kaufbeleg. Das Familienoberhaupt erhält den selben Kaufbeleg etwas zeitverzögert. So kann es vorkommen, dass das Familienoberhaupt, also der User mit der Kreditkarte, diesen Kaufbeleg evtl. erst 1 oder 2 Tage später erhält.

Ein Familienmitglied kann von einem IOS-Gerät oder an einem Mac der Familie hinzugefügt oder entfernt werden. Auf einem IOS-Gerät öffnest Du dazu die Einstellungen und öffnest dann den Punkt “iCloud”. Hier findest Du die Einstellungen für die Familienmitglieder und kannst jemanden hinzufügen oder löschen.

10. HandsOff

Ein Dokument an einem Gerät beginnen und nahtlos an einem anderen Gerät fortsetzen? Mit HandsOff ist das gar kein Problem. Voraussetzung ist hier, dass auf allen Geräten, die HandsOff nutzen sollen, die entsprechende Einstellung aktiviert ist. Stell Dir vor, Du sitzt im Zug und bist gerade dabei, dich zu langweilen. Dann fällt Dir ein, Du könntest Doch an Deinem Text, den Du gestern zu Hause an Deinem MacBook begonnen hast, weiterarbeiten. Gar kein Problem. Einfach Dein iPhone aus der Tasche holen, das iDrive öffnen und direkt weiterschreiben. So, wenn sich nun Dein iPhone und MacBook im selben WLAN befinden, kannst Du jede Änderung Deines Dokumentes, die Du an Deinem iPhone machst, direkt an Deinem Mac verfolgen. Umgekehrt funktioniert das übrigens auch. Voraussetzung für HandsOff ist, dass sich alle Geräte, die HandsOff nutzen, im selben WLAN befinden. Für alle anderen Fälle stellt das iDrive den erforderlichen Speicherplatz zur Verfügung.

11. Hilfe! Mein Mac klingelt

Mit Einführung von IOS 8 und OSX 10.10 hat Apple eine weitere Neuerung eingeführt: das Weiterleiten des Klingelns bei einem eingehenden Anruf.

Du hast Dein iPhone an der Garderobe in der Jackentasche und es klingelt? Entweder rennst Du jetzt ganz schnell zu Deinem Telefon oder Du nimmst das Gespräch einfach an Deinem Mac an, an dem Du sowieso gerade sitzt und arbeitest. Schön bequem, was? Voraussetzung: Alle Geräte müssen mit der selben Apple-ID an der iCloud angemeldet sein.

Wenn Du nun einen Anruf auf Deinem iPhone bekommst, beginnt nach dem 2. Klingelzeichen auch, Dein Mac zu klingeln. Auf dem Mac wird Facetime gestartet und lässt das Klingelzeichen ertönen. Du kannst das eingehende Gespräch nun am Mac mit Facetime annehmen oder ablehnen. Eine sehr schöne Sache. Aber diese Funktion hat einen kleinen Haken:

Es kommt leider immer wieder vor, dass die Geräte, an denen Du das Gespräch nicht angenommen hast, noch sehr lange klingeln, obwohl Du das Gespräch z. B. am Mac angenommen hast. Ein weiterer kleiner unschöner Punkt ist, dass alle Geräte von Apple gleichzeitig klingeln. Bei mir wären das zzt. 3 Geräte, iPhone, iPad und MacBook. Das fällt weiter nicht auf, wenn alle Geräte in unterschiedlichen Räumen liegen. Aber es kann ganz schön nervig sein, wenn Du am Mac bereits telefonierst und iPhone und iPad klingeln noch 3 Minuten munter vor sich hin. Es ist bei mir auch schon vorgekommen, dass die IOS-Geräte solange geklingelt haben, bis ich das Gespräch am Mac beendet habe. Wirklich lästig. Aber ich denke, da wird sich Apple noch etwas einfallen lassen. Eigentlich sollte es so sein, dass alle Geräte aufhören, zu klingeln, sobald das Gespräch an einem Gerät angenommen wurde.

Diese Funktion hat nur am Rande mit der iCloud zu tun, denn die iCloud wird dafür eigentlich gar nicht benötigt. Nur die Apple-ID ist vonnöten. Ruft Dich jemand auf dem iPhone an, erkennt das das iPhone und leitet das Gespräch automatisch an seine Apple-ID weiter. Dies wiederum erkennen alle Geräte mit der selben Apple-ID und beginnen, zu klingeln.

Facetime

Ruft mich jemand via Facetime an und gibt dabei als Empfänger meine Apple-ID an, klingeln natürlich auch mal iPad und iPhone. Aber sobald ich das Gespräch am Mac angenommen habe, klingeln iPad und iPhone noch 2 mal und verstummen dann.

Möchtest Du nicht, dass alle Deine Geräte wie in einem Konzert klingeln, rattern und brüllen, wenn Du angerufen wirst, musst Du das in Facetime auf allen Geräten abschalten.

Anmerkung von mir

Mich hat dieses Feature wirklich genervt, weil eben mein Mac munter weiterdudelte, obwohl ich am iPhone schon am Telefonieren war. Daher hier mal der Weg, wie Ihr das abschalten könnt:

Geht am iPhone in die Einstellungen und dort in Facetime. Hier könnt Ihr weiter unten einstellen, von welchen E-Mail-Adressen aus Ihr für Facetime erreichbar sein möchtet. Wichtig ist hier der Punkt “iPhone Mobilanrufe”. Diesen Punkt müsst Ihr abschalten.

Geht nun in die Facetime-App am Mac, diese befindet sich im Programme-Ordner. Hier kommt Ihr leicht mit Befehl+Umschalt+A hin. Öffnet mit Befehl+, die Einstellungen und deaktiviert auch hier “Iphone Mobilanrufe”.

Wenn Ihr beide Einstellungen gemacht habt, werden nur beide Geräte zusammen klingeln, wenn Ihr über Facetime angerufen werdet. Bei normalen Telefonanrufen wird jetzt nur noch das iPhone klingeln.

Diese Einstellung hat aber einen kleinen, meiner Ansicht nach aber vernachlässigbaren, Nachteil. Wenn auf beiden Geräten “iPhone Mobilanrufe” aktiviert sind, so könnt Ihr auch vom Mac aus über Euer iPhone telefonieren. Hierbei baut der Mac die Verbindung über das Mobilfunknetz auf, indem es über Euer iPhone den Anruf tätigt. Telefonieren werdet Ihr weiterhin am Mac, aber das iPhone muss dazu eingeschaltet und geladen sein. Wenn Ihr diese Funktion nutzen möchtet, werdet Ihr mit dem gemeinsamen Dudeln beider Geräte leben müssen… :-(

12. Endlich SMS und iMessage am Mac schreiben

Seit OSX 10.10 hast Du die Möglichkeit, eine iMessage oder eine SMS am Mac zu schreiben und über Dein iPhone zu versenden. Auf dem iPhone muss dafür IOS 8 installiert sein und beide Geräte müssen sich im selben WLAN befinden. Es ist mit OSX 10.10 in Verbindung mit IOS 8 auch möglich, eine empfangene SMS oder iMessage am MAC zu lesen und zu beantworten, die auf Deinem iPhone angekommen ist. Ist auf einem Gerät nicht die erwähnte Betriebssystemversion installiert, funktioniert das leider nicht mehr. Also schön darauf achten, dass IOS8 auf iPhone oder iPad und OSX 10.10 auf dem Mac installiert ist.

So, ich hoffe, ich konnte Euch das Verständnis zur iCloud etwas Näher bringen. Wie ich eingangs schrieb, habe ich versucht, es mit einfachen Worten und so verständlich wie möglich zu erklären. Ich gebe zu, dass diese Darstellung einen vereinfachten Einblick in die iCloud gibt. Dennoch bin ich sicher, dass das Prinzip der iCloud verstanden wurde.

Wer zur iCloud noch Fragen oder Anmerkungen zu meinen Ausführungen hat, darf dies gern in dieser Liste tun.


Diskutiert werden kann natürlich nicht nur in der Mailingliste, sondern auch im Forum oder hier in den Kommentaren. Entweder wird diese Text dann aktualisiert, oder einzelne Fragen und Antworten kommen dann in die FAQ-Sektion.

Homeserver 27: Mailversand über Postfix einrichten

Entscheidungen, die zum Zeitpunkt ihres Entstehens wie eine gute Idee aussehen, können sich im Nachhinein als echt blöde Idee entpuppen! So geschehen mit SSMTP. Erinnert ihr euch? Damit mein Server Mails verschicken kann, um mich über diverse Ereignisse zu informieren, musste ja ein SMTP-Dienst installiert werden. Dies habe ich ja in Teil 9 gemacht. Stellt sich raus, SSMTP mag schnell und einfach zu installieren sein, hat aber mitunter gravierende Nachteile.

Ich habe mit dem Kommando “mail” etwas experimentiert, wie man von der Kommandozeile eine Mail verschicken kann, damit ich es später vielleicht gezielt in Scripts einbauen kann. Und bei dieser Gelegenheit bin ich über eine Unzulänglichkeit des Tools gestoßen, es benötigt dringend eine bestehende Internetverbindung. Ist die Verbindung kurz weg, oder antwortet der Mailserver vom Mailanbieter nicht rechtzeitig, quittiert das Programm “mail” einfach den Dienst mit einem Fehlercode. Die zu sendende Mail hingegen entfleucht für immer im Datennirvana. Das ist, mit Verlaub, eine echt blöde Idee! Was, wenn mein Server mich über einen RAID-Ausfall informieren will, aber der Mailprovider für 5 Minuten mal nicht erreichbar ist? Genau, ich würde von dem Fehler niemals erfahren! Denn SSMTP hat keine Warteschlange, es drückt die Mail sofort zum SMTP-Server des Mailanbieters, und ist der nicht vorhanden, spielt er beleidigte Leberwurst und wirft die Mail weg!

Das kann ich unter gar keinen Umständen so lassen! Es braucht ja nur mal für ein paar Minuten der Router weg sein, weil er neu startet, die Internetverbindung ist getrennt, der Mailanbieter ist nicht erreichbar, und eine wirklich wichtige Systemmeldung bleibt ungesehen. Daher muss SSMTP weg, und doch Postfix installiert werden. Postfix hat, habe ich schon ausprobiert, eine Warteschlange. Kann eine Mail nicht versendet werden, probiert Postfix es immer wieder in gewissen Abständen. Ich kann die Warteschlange auch anzeigen und den Versand per Befehl gleich auslösen, wenn ich weiß, dass die Internetverbindung wieder in Ordnung ist.

SSMTP deinstallieren

Zunächst mal muss SSMTP vom System runter.

sudo apt-get purge ssmtp

Dies deinstalliert SSMTP und seine Komponenten, löscht aber auch seine Konfigurationsdateien. Möchte man, warum auch immer, die Konfigurationsdateien aber behalten, kann man statt purge auch remove nutzen.

Anschließend sind noch ein paar Pakete übrig, die noch entfernt werden müssen. Diese wurden von SSMTP installiert, werden nicht mehr benötigt aber wurden beim Deinstallieren nicht automatisch entfernt. Dies muss noch manuell nachgeholt werden.

sudo apt-get autoremove

Nun ist SSMTP vom Server runter und Postfix kann installiert werden.

Postfix installieren

Meine Installationsanleitung für Postfix habe ich vom Wiki Ubuntuusers.de. Falls ihr also genauere Infos sucht, könntet ihr dort zu Lesen anfangen.

Zunächst muss Postfix und ein weiteres Paket installiert werden:

sudo apt-get install postfix bsd-mailx

Das Paket bsd-mailx wurde von SSMTP installiert, aber weil wir SSMTP ja deinstalliert haben, hat sich dieses Paket auch von dannen gemacht. Es ist aber notwendig, weil viele Programme und Dienste über dieses Paket mit dem Befehl “mail” die Mails verschicken. Fehlt dieses Paket, keine Mails vom System, ist gleich ziemlich blöd. :-)

Laut der Anleitung aus dem UbuntuUsers-Wiki soll man auch libsasl2-modules installieren, brauchen wir aber nicht. Ich bin mir nicht mehr sicher, weil das echt schnell ging, ob dieses Paket von Postfix gleich mitinstalliert wurde, oder ob es schon auf dem System war. Wie auch immer, bei mir war es bereits da.

Konfiguration von Postfix

Nachdem der Befehl zur Installation von Postfix ausgeführt wird, erscheint ein Dialogfeld, in dem man einige kleine Konfigurationsfragen beantworten muss.

Die erste Frage ist, als was Postfix konfiguriert werden soll. Wird das mal ein voller Mailserver, oder nur zum Senden, oder vielleicht nur intern? Ich möchte keinen vollständigen Mailserver betreiben, Postfix soll Mails entgegennehmen und an einen SMTP-Server eines Mailproviders weiterleiten. Also wähle ich hier “Satellite System” aus.

Als nächstes wird nach einem “Mail Name” gefragt. Hier ist der Rechnername, in meinem Fall “server01″ bereits vorgegeben. Das akzeptiere ich so.

SMTP Relay Host? Hier kommt der SMTP-Server eines Mailproviders hinein. Da ich eine GMX-Adresse nutze, kommt hier “mail.gmx.net” rein.

Ich bin mir gar nicht mehr so sicher, was für Fragen da noch kamen, aber die kann man alle mit Enter beantworten. Sollte man einen Fehler gemacht haben, oder aus irgendwelchen Gründen die Konfiguration noch einmal machen wollen, gibt man folgenden Befehl ein:

sudo dpkg-reconfigure postfix

Aber Achtung, hier kommen mehr Fragen. Alle Fragen, die ich hier nicht behandelt habe, könnt ihr so lassen, wie sie vorgegeben sind.

Mailversand einrichten

Damit Postfix jetzt aber Mails versenden kann, muss die Konfiguration noch angepasst werden. Ich werde hier meine Mailadresse für GMX konfigurieren, weil mein Server darüber seine Mails verschicken soll. Weitere Beispiele findet ihr auch im UbuntuUsers Wiki Artikel zu Postfix.

Ich editiere also die Konfigurationsdatei von Postfix:

sudo nano /etc/postfix/main.cf

Folgende Zeilen füge ich am Ende ein:

smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_password
sender_canonical_maps = hash:/etc/postfix/sender_canonical
smtp_tls_security_level = encrypt

Diese Zeilen bestimmen, dass der SMTP-Server bei GMX eine Authentifizierung benötigt, welcher Absender verwendet werden soll, wo Benutzername und Passwort stehen und dass die Verbindung über SSL bzw. TLS verschlüsselt werden soll.

Nun müssen noch zwei Dateien angelegt werden, die, in der die Zugangsdaten stehen und die, in der die Absenderadressen eingetragen werden.

Zunächst erstellen wir mal die Datei für die Zugangsdaten zum SMTP-Server:

sudo touch /etc/postfix/sasl_password

Warum ich die Datei so erstelle? Nun, im Postfix-Artikel bei UbuntuUsers steht, dass es sonst zu Problemen kommen könnte, daher mache ich das lieber so. Aber nun muss die Datei noch editiert werden.

sudo nano /etc/postfix/sasl_password

Hier kommt jetzt in einer Zeile der SMTP-Server, der Benutzername und das Passwort rein. Bei GMX müsste das also so aussehen:

mail.gmx.net mail_adresse@gmx.de:passwort

Natürlich tragt ihr dort die eigentlichen Werte ein. Und nun speichert ihr die Datei.

GMX akzeptiert nur Absender, mit denen man sich auch anmeldet. Das heißt, alle Nutzer dieses Servers schicken ihre Mails über die gleiche Adresse. Macht ja nix, hier wohnt ja nur root und ich auf dem Server. :-)

sudo nano /et/postfix/sender_canonical

Und hier kommen folgende Zeilen rein:

www-data meine_adresse@gmx.de
root meine_adresse@gmx.de
kamil meine_adresse@gmx.de

Nun kann root, der Web-Server und ich Mails verschicken. Aber zuerst sind noch zwei befehle nötig, um aus den eben erstellten Dateien für Postfix lesbare Datenbanken zu machen:

sudo postmap hash:/etc/postfix/sasl_password 
sudo postmap /etc/postfix/sender_canonical

Nun noch den Postfix neu starten:

sudo service postfix restart

Fertig! Ab jetzt kann man Mails verschicken.

Test der Konfiguration

Lasst uns mal eine Testmail verschicken, wenn die ankommt, ist alles in bester Ordnung:

echo Hallo! dies ist ein Test! | mail -s Testmail meine_adresse@gmx.de

Meine Testmail ist angekommen, also funktioniert meine Installation.

Warteschlange

In der Regel braucht ihr euch um die Warteschlange nicht zu kümmern. Sollte mal die Internetverbindung tot sein und einige Mails in der Warteschlange liegen, so versucht Postfix diese von Zeit zu Zeit erneut zu senden. In welchen Intervallen und wo man evtl. das konfigurieren kann, das habe ich leider noch nicht herausgefunden. Was ich aber weiß, weil ausprobiert, wenn die Verbindung zum Internet getrennt ist, und ihr sendet eine Mail mit dem “mail”-Kommando, so gibt es keine Fehlermeldung wie bei SSMTP, sondern die Mail landet in der Warteschlange. Ist die Verbindung zum Internet wieder da, so wird nach einer Weile die Mail verschickt.

Sollte dies aus irgendwelchen Gründen nicht passieren, könnt ihr das auch per Hand tun. Die Warteschlange zeigt ihr so an:

sudo postqueue -p

Sind hier nun also Mails drin, die Verbindung zum Internet funktioniert aber, dann könnt ihr das Senden der Mails anstoßen:

sudo postqueue -f

Das verschickt alle Mails, die gerade in der Warteschlange sind.

Fazit

Als ich SSMTP installiert hatte, wusste ich davon nichts. Und demnächst will ich auch noch eine USV, eine unterbrechungsfreie Stromversorgung, einsetzen. Wenn diese also Mails über ihren Status senden will, während der Strom für den Router gerade weg ist, würde ich die ja nicht sehen. Ist der Strom wieder da, bekomme ich Infos darüber, ob die USV angesprungen ist, ob alles geklappt hat oder ob es zu Problemen gekommen ist. Hätte ich vorher gewusst, dass SSMTP keine Warteschlange hat, ich hätte wahrscheinlich sofort Postfix installiert. Aber naja, das haben wir ja jetzt korrigiert. :-)

Homeserver 26: Prozesse unbeaufsichtigt im Hintergrund laufen lassen

Lange laufende Prozesse am Server bereiten ein kleineres Problem. Das ist mir insbesondere aufgefallen, als ich die Hashwerte mit den Daten prüfen wollte. Dieser Prozess hat länger als einen Tag gedauert, und in der Zeit muss die SSH-Verbindung offen bleiben, also auch der Rechner hier weiter laufen. Wäre mir zwischenzeitlich mein Windows-PC abgestürzt, hätte ich von vorn beginnen können.

Aber, dieses Problem kann gelöst werden, mit virtuellen Terminals. Und wie dies geht, werde ich in diesem Artikel erklären.

Screen

Screen ist ein ziemlich umfangreiches Werkzeug. Man kann fast beliebig viele virtuelle Fenster erstellen, man kann auch mit mehreren Personen an so einem Fenster arbeiten. Das macht z. B. Sinn, wenn Person A jemandem etwas zeigen will, wie z. B. eine bestimmte Software funktioniert, und Person B und einige weitere sind ebenfalls an diesem Fenster angemeldet und können die Vorgänge nachvollziehen.

Für mich ist jetzt erst einmal nur die Möglichkeit wichtig, ein Fenster zu erstellen, und dieses dann von der Sitzung zu entkoppeln, so dass ich die SSH-Sitzung schließen kann. Später kann ich über SSH das Fenster wieder aufrufen und dort weiter arbeiten.

Zunächst muss Screen aber erst mal installiert werden:

sudo apt-get install screen

Aufruf

Es gibt mehrere Möglichkeiten, Screen aufzurufen. Gibt man “screen” ohne irgendwelche Parameter auf, so wird einfach ein Fenster erzeugt, in dem man schon arbeiten könnte. Man kann auch mit screen und einem Befehl dahinter sofort eine Aufgabe an ein virtuelles Terminal übergeben. Ich habe beide Methoden probiert und hinterher etwas Schwierigkeiten gehabt, die Fenster aus dem Hintergrund wieder hervorzuholen. Denn dazu müsste ich den Namen angeben, und das ist bei automatisch erzeugten Fenstern nicht ganz trivial. Stattdessen erzeuge ich ein Fenster, welches gleich einen zur Aufgabe passenden Namen bekommt:

screen -S Hash

Nun habe ich ein leeres Terminal und kann, wie der Name des Terminals schon sagt, die Erstellung der Hashwerte einleiten. Also gebe ich an der Befehlszeile ein:

sudo hashdeep -re /raid1/daten >hashset.txt

Wie ich schon sagte, dieses Programm läuft lange, länger jedenfalls, als ein Tag. Und so lange möchte ich weder das Terminal offen lassen, noch den PC. Daher verfrachte ich das virtuelle Terminal in den Hintergrund, ich entkopple es also von der SSH-Sitzung, und kann die SSH-Sitzung dann problemlos schließen.

Screen lässt sich ganz einfach mit Tastenbefehlen steuern. Jeder Befehl beginnt mit einem STRG+a gefolgt von einem Buchstaben oder einer Kombination. Eine Liste der Tastenbefehle bekommt ihr, wenn ihr STRG+a ? eingebt. Ich möchte jetzt das Terminal entkoppeln, dafür drücke ich STRG+a d. Nun ist das Terminal abgekoppelt und ich kann SSH beenden und den PC abschalten, der Hash-Vorgang läuft auf dem Server aber weiter.

Wieder verbinden

Auch hier gibt es mehrere Möglichkeiten.

screen -r

Dieser Befehl ist dann sinnvoll, wenn man sowieso nur ein Fenster offen hatte. Es wird dann sofort verbunden. Hat man mehrere Fenster im Hintergrund laufen, so hilft der Befehl “screen -ls” herauszufinden, welche Fenster da sind und wie diese heißen. Wie mein Fenster heißt, weiß ich ja, ich habe es ja entsprechend gestartet.

screen -r Hash

Nun bin ich wieder mit meinem Fenster verbunden und kann sehen, ob der Hash-Vorgang noch läuft, oder ob er schon beendet ist. Läuft er noch, kann ich das Fenster ja wieder abkoppeln. Ist der Vorgang aber schon beendet, kann ich das Fenster ja beenden, also, wie es in der Linux-Welt so brutal heißt, killen! :-) Also kille ich das Fenster mit STRG+a k. Dann werde ich noch gefragt, ob ich das wirklich will, und dann ist das Terminal auch beendet. Dies kann man leicht mit “screen -ls” herausfinden.

Fazit

Man kann mit Screen noch eine Menge toller Sachen machen, wie z. B. am Terminal eines Rechners verbunden sein, der irgendwo auf der Welt steht, gemeinsam an Dokumenten Arbeiten und vieles mehr. Aber für mich ist erst mal nur von Bedeutung, dass ich lange laufende Prozesse im Hintergrund ablaufen lassen kann, ohne dass mein Windows-PC und mein SSH-Fenster offen sein müssen.

Homeserver 25: Sind wirklich keine Daten verlorengegangen?

War der Ausfall des RAIDs letztens jetzt eigentlich folgenlos? Sind meine Daten evtl. in Mitleidenschaft gezogen worden? Diese Fragen kann ich mit einem definitiven “Ich habe keine Ahnung!” beantworten. :-) Denn ein Kommentar von Stefan Jansen in meinem vorigen Artikel brachte mich zum Nachdenken. Zum Einen, ob der Ausfall wirklich folgenlos war, und zum Anderen, wie ich das denn jetzt überprüfen kann. Also habe ich den Browser meiner Wahl geöffnet, paar Stichworte in die Suchmaschine meiner Wahl eingegeben und eine ganze Weile gelesen.

Der einfachste Weg, zu prüfen, ob die Datenintegrität noch da ist, sind Hashes. Ein Hash ist eine Prüfsumme, an der man sehen kann, ob Daten verändert wurden. Wer genaueres wissen möchte, kann sich den Wikipedia-Artikel zu Prüfsummen durchlesen.

Damit ich also Prüfsummen erstellen kann, und diese auch gegenprüfen kann, muss ich diverse Tools haben. Meine Wahl fiel auf MD5Deep, weil dieses wirklich für alle relevanten Betriebssysteme vorhanden ist und identisch bedient wird. So muss ich nicht für jedes System ein neues Tool haben. Aber auch wenn es “MD5Deep” heißt, es ist eine Sammlung von Programmen, die mit allen möglichen Hash-Funktionen umgehen kann.

Hashwerte für mein Datenbackup erstellen

Dieser Schritt ist nur dieses Mal nötig, weil ja noch keine Hashes von intakten Daten existieren. Später werden die Daten direkt auf dem RAID gehashed.

Um also zu gucken, ob die Daten auf dem RAID noch in Ordnung sind, muss ich ja erst mal Hashes von Daten haben, von denen ich weiß, dass sie in Ordnung sind. Also muss erst mal ein Hashset von meinem Datenbackup erstellt werden. Dieses liegt auf mehreren externen Festplatten, die auch unter Windows lesbar sind.

Zunächst muss ich mir MD5Deep für Windows von der MD5Deep Homepage herunterladen. Die Datei packe ich aus. Hier sind viele Dateien drin, vor allem auch für die diversen Hash-Typen. Mich interessiert zunächst aber nur die Datei hashdeep64.exe, weil ich ein Windows 7 64 Bit nutze. Diese kopiere ich in ein Verzeichnis, von dem aus ich dieses Programm leicht aufrufen kann.

Nun muss ich von meinem Backup Hashes erstellen. Um dies zu tun, muss ich das für jede externe platte tun, auf der Backupdaten liegen. Da ich eine Festplatten-Dockingstation habe, ist das Wechseln von Platten denkbar einfach, einfach senkrecht reinstellen… :-)

Meine externe Platte lässt sich über den Laufwerksbuchstaben G: ansprechen. Die Backups liegen in exakt der Verzeichnisstruktur auf der Platte, wie sie auch auf dem RAID liegen.

Nun stelle ich also die erste Platte ins Dock, schalte sie ein und dann starte ich das Hash-Programm von der Kommandozeile. Der Befehl sieht so aus:

hashdeep64 -re -j1 g:\daten >>known.txt
  • hashdeep64: Das Programm.
  • -re: Diese Parameter hashen die Daten rekursiv, also alle Dateien aller Unterverzeichnisse. Und es wird die zu erwartende Dauer bei großen Dateien angezeigt.
  • -j1: Verwendet nur einen CPU-Kern. Sonst werden 4 Operationen gleichzeitig gemacht. Ich habe ja eine Quadcore-CPU in meinem Rechner, also ein Thread pro CPU-Kern. Das mag bei internen Platten oder RAIDs kein Problem sein, aber bei externen Platten, auch wenn es USB 3.0 ist, verlangsamt das den Prozess fast auf die doppelte Länge.
  • g:\daten: Da liegt mein Backup.
  • >>known.txt: Leitet die Ausgabe der Hashes in diese Datei um.

Diese Datei wird später noch wichtig, denn hier sind die bekannten Hashwerte drin, gegen die die Daten auf dem RAID geprüft werden sollen. Und warum habe ich zwei Größerzeichen verwendet? Weil dieser Befehl nach und nach mit allen Backupplatten ausgeführt werden soll. Die neuen Hashes sollen an die Datei angefügt werden. Würde da nur ein Größerzeichn stehen, würde die Datei bei jeder Ausführung überschrieben werden.

Jede Datei, auch große Videos, MP3s und Bilder, wird jetzt gehashed und dessen Hashwert in der Datei gespeichert. Da dies für alle Backupplatten gemacht werden muss, kann das eine geraume Zeit dauern.

known.txt bearbeiten

Ich fühle mich gerade wie ein HDD-DJ, ich jongliere hier mit Festplatten, wie andere mit CDs… :-) Aber egal.

Das Hashen hat nun eine geraume Zeit gedauert, und es ist dabei eine sehr große known.txt dabei entstanden. Die kann aber, so, wie sie jetzt ist, nicht verwendet werden. Zum Einen sind die Pfadangaben für Windows, zum Anderen haben wir hashdeep mehrere Male aufgerufen und die Hashes an diese Datei anhängen lassen, so dass der Datei-Header nun mehrere Male vorhanden ist. Dies muss geändert werden, bevor die Datei auf dem Server verwendet werden kann.

Ihr könnt zwar so ziemlich jeden Editor nutzen, den ihr möchtet, da es ja nur eine einfache Textdatei ist, ich benutze den Notepad++, aus gewohnheit und weil ich meine, dass der mit großen Dateien besser klarkommt.

Die known.txt beginnt mit den folgenden Zeilen:

%%%% HASHDEEP-1.0
%%%% size,md5,sha256,filename
## Invoked from: c:\
## c:\> hashdeep64 -re g:\daten
## 

Darunter beginnen die Hashes, jede Zeile enthält einen Hashwert und die dazu passende Datei.

Diese 5 Zeilen lassen wir so auch stehen. Weiter unten tauchen diese 5 Zeilen leider aber noch mehrere Male auf. Das könnte zum Problem werden, daher müssen wir diese entfernen. Also nutze ich die Suchfunktion und suche nach den 4 aufeinanderfolgenden Prozentzeichen. Dann wird der zusätzliche Header gelöscht, bis nur noch die Headerzeilen ganz oben vorhanden sind. Diese müssen sein.

Nun zeigen auch noch die Pfade auf Windows-Pfade, weswegen das Programm auf dem Server nichts finden würde. Mit zwei einfachen Suchen und Ersetzen Schritten wandeln wir diese Pfade in Linux-Pfade um.

Gehen wir also in das Suchen und Ersetzen Dialogfeld, in fast allen Editoren ist das mit Strg+H möglich. In das Feld “Suchen nach” geben wir “g:\daten” ein. In das “Ersetzen mit” Feld geben wir “/raid1/daten” ein. Nun aktivieren wir die Schaltfläche “Alle ersetzen”. Bei der Größe der Datei kann das einige Zeit dauern.

Im zweiten Schritt gehen wir wieder in das Suchen und Ersetzen Dialogfeld, und geben bei “Suchen nach” “\” ein, und in das “Ersetzen mit” Feld einen “/”. Auch jetzt aktivieren wir wieder die Schaltfläche “Alle ersetzen”.

Jetzt ist die Datei bereit, weiterverwendet zu werden. Also schließe ich den Editor, speichere die Datei dabei ab und kopiere sie auf den Server ins Home-Verzeichnis. Hierfür hatte ich ja eine Freigabe eingerichtet, also kann ich das mit dem Explorer tun.

Hashwerte gegenprüfen auf dem Server

Um nun zu prüfen, ob die Dateien auf meinem RAID in Ordnung sind, habe ich ja die known.txt in mein Home-Verzeichnis kopiert. Also logge ich mich per SSH auf dem Server ein. Das Erste, was ich nun tue, ich installiere erst mal MD5Deep auf meinem Server:

sudo apt-get install md5deep

Nun stehen mir alle Programme wieder zur Verfügung, die ich auch unter Windows schon hatte, darunter auch hashdeep. Mit diesem Programm und der zuvor erstellten Liste der bekannten Hashes kann ich nun prüfen, ob die Dateien auf dem RAID dem entsprechen, wie sie in meinem Backup vorhanden sind.

Hinweis: Die Prüfung wird in jedem Falle fehlschlagen. In der Zwischenzeit wurden Dateien hinzugefügt, entfernt und bearbeitet. Hashdeep prüft aber, ob der Verzeichnisbaum und -inhalt identisch sind. Kleinste Abweichungen führen schon zum Fehlschlagen des Audits. Das macht aber nix, wie ich gleich zeigen werde. Ich wollte es nur gleich gesagt haben… :-)

Ich rufe Hashdeep also nun mit folgendem Befehl auf:

sudo hashdeep -vv -rak known.txt /raid1/daten >resultat.txt

Der Parameter -v regelt die Ausführlichkeit der Ausgabe. Ein einzelnes v gibt nur etwas mehr Informationen, vv führt die Diskrepanzen auf und vvv gibt den Status für jede Datei an.

Den Status jeder Datei zu sehen, wäre too much. Mich interessieren nur die Diskrepanzen. Denn so kann ich entscheiden, ob ich die Datei gelöscht, bewegt, bearbeitet oder sie durch den Crash kaputtgegangen ist.

Der Parameter -rak scant das Ziel rekursiv, aktiviert den Audit-Modus und übergibt die Hash-Datei. Der Audit-Modus untersucht nun jede Datei in der Hash-Datei, ob sie geändert ist oder überhaupt noch vorhanden ist.

Am Ende wird das Resultat in die Datei resultat.txt geschrieben, wo ich es dann in Ruhe analysieren kann. Und da die Diskrepanzen nur eine Hand voll Dateien betreffen sollten, wenn alles gutgegangen ist, dürfte das ein überschaubarer Aufwand sein.

Resultate?

Eine Handvoll Dateien, ja nee, is klar! :-) Das habe ich ja mal so was von unterschätzt!

Woran ich nicht gedacht habe, alle Dateien, die nicht im Backup vorhanden sind, werden natürlich als “No match” angegeben und in die resultat.txt geschrieben. Und es gibt einiges auf dem RAID, was nie ins Backup kommt. Diese Daten sind einfach zu unwichtig, tämporäre Dateien, Podcasts oder sonst Daten, die ich leicht aus dem Netz bekommen kann. Das macht die Analyse der Datei nicht einfach, aber da muss ich jetzt durch… Wie zu erwarten war, steht am Ende der Datei natürlich “hashdeep: Audit failed”.

Das macht aber nix, ich war tapfer und bin die ganze Datei durchgegangen. Das ist auch relativ einfach, da die Einträge ja nach Verzeichnissen sortiert waren. So konnte ich die unwichtigen Verzeichnisse einfach durchblättern.

War der Ausfall des RAIDs letztens jetzt eigentlich folgenlos? Sind meine Daten evtl. in Mitleidenschaft gezogen worden? Diese Fragen kann ich jetzt mit einem definitiven “Alles ist gut, nichts ist kaputt!” beantworten! Das beruhigt mich ja ungemein, auch wenn das jetzt echt Arbeit war, das zu prüfen.

Für die Zukunft

Jetzt, wo ich weiß, dass die Daten auf dem RAID OK sind, kann ich es mir ja bedeutend einfacher machen. Statt nach einem Desaster mühsam alle Backupplatten zu hashen, werde ich jetzt in größeren Abständen die Daten direkt auf dem RAID hashen. Hierfür werde ich folgenden Befehl nutzen:

sudo hashdeep -re /raid1/daten >hashes.txt

Die hashes.txt liegt dann in meinem Homeverzeichnis auf der SSD. Sollte ich nun mal wieder das Bedürfnis haben, die Integrität meiner Daten prüfen zu wollen, so kann ich immer auf diese Datei zugreifen:

sudo hashdeep -vv -rak hashes.txt /raid1/daten

Somit entfällt natürlich der gesamte obere Teil, die Datenbackups zu hashen und die Hash-Datei manuell zu bearbeiten. Selbstverständlich muss die Hash-Datei gelegentlich aktualisiert werden, aber das dürfte ja klar sein.

Fazit

Ich bleibe dabei, das Linux Software-RAID ist echt robust und kann ganz schön was ab, bevor es zu Datenverlusten kommt. Aber, und das kann ich gar nicht oft genug sagen, wer kein Backup hat, hat ein größeres Problem, als nur paar Tage mit Hashen und Prüfen zu verlieren.

Homeserver 24: RAID-Ausfall, was tun?

Heute Morgen geriet ich dann doch etwas in Panik! Mein Postfach war voller Fehlermeldungen vom RAID-System und von S.M.A.R.T. Demnach waren zwei Festplatten ausgefallen. S.M.A.R.T. war der Meinung, /dev/sdb und /dev/sdc seien zwar noch da, könnten aber nicht geöffnet werden oder seien keine Laufwerke, die S.M.A.R.T.-Daten zur Verfügung stellten. Und MDADM, das RAID-System, war der Meinung, die Laufwerke hätten ein Problem und setzte mal eben das RAID herab. Da es ja jetzt aber zwei Platten sind, ging am RAID erst mal gar nichts mehr!

Eine kurze Abfrage der /proc/mdstat ergab leider auch nichts brauchbares, da SDb1 und SDC1 einfach nur als defekt markiert wurden. Nun hätte ich viele der Reparaturversuche sofort machen können, tat dies aber nicht. Ich hatte nämlich vorher, als ich mich noch in Linux eingelesen hatte, in einem Forum gesehen, dass so ein Problem, ganz wie bei Windows, bei einem Reboot wieder verschwindet. Gesagt, getan, und nicht gestartet. :-( Der Server fuhr einfach nicht mehr hoch. Und da ja nun kein Bildschirm und keine Tastatur angeschlossen ist, wusste ich auch nicht, was denn nun vor sich geht. Also habe ich den Server abgebaut und zu mir an meinen Schreibtisch geholt.

Erinnert ihr euch, dass ich relativ kurz nach der Installation BRLTTY wieder deinstalliert hatte, weil es ja nicht benötigt würde? Ganz schlechte Idee, wie sich jetzt herausstellt. :-) Aber, halb so wild, ich habe es ja wieder installieren können, für so was einfaches reichte mein Sehrest noch. Aber nur so zur Info, lieber nicht deinstallieren. :-)

Startversuch

Das System bleibt mitten im Bootvorgang stehen und meldet einen Fehler. Ich habe die Fehlermeldung nicht mehr genau im Kopf, aber in Etwa sah es so aus:

FSCK died with exit code 8

Oder so etwas ähnliches. Und dann noch ein englischer Text, dass nun eine Maintenance Shell gestartet würde, damit man das Problem beheben könne. Und wenn man dies getan hätte, könne man ja Ctrl+D drücken, um normal weiterzubooten. Gut, ich habe das ignoriert und habe gleich Ctrl+D gedrückt.

RAID analysieren

Wenn ich mir nun die /proc/mdstat angucke, steht das RAID MD0 dort als inactive, also es ist nicht gestartet. Alle Platten stehen dort als Spare, also hinter jeder Bezeichnung der Platten steht ein (S).

Manuelles Starten des RAID

Bevor man nun irgendetwas tut, muss das RAID erst mal gestoppt werden:

sudo mdadm --stop /dev/md0

Gibt man folgenden Befehl ein,

sudo mdadm --assemble /dev/md0

müsste das RAID sich selbst wieder zusammensetzen und starten. In meinem Falle ging das aber nicht. Also habe ich den Befehl noch etwas anders eingegeben:

sudo mdadm --assemble --verbose /dev/md0

Dieser Befehl gibt eine Menge Informationen aus, ob etwas klappt, und wenn nicht, warum nicht. Allerdings hatte ich diese Befehle alle angewendet, als mein Server hier am Schreibtisch Stand und keine Netzverbindung hatte. Ich habe daher die Ausgaben nicht gespeichert und gebe die Daten aus dem Kopf wieder.

Bei den Festplatten /dev/sdb1 und /dev/sdc1 bekam ich die Fehlermeldung “has no Superblock”. Der Superblock ist der Bereich, indem das RAID eine Menge an Informationen über das RAID selbst und seine beteiligten Festplatten ablegt.

Das selbständige zusammensetzen hat also nicht geklappt, dann also per Hand. Und, bevor ein Array wieder gestartet und zusammengesetzt werden kann, muss es immer erst gestoppt werden. Also setze ich das RAID so zusammen:

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

Auch kein Glück:

MDADM: Assemby of /dev/md0 from 3 drives, not enough to start the array.

Aus dem Kopf geschrieben, die Formulierung könnte geringfügig anders sein.

Reparieren des RAID

Zunächst überprüfe ich erst mal, ob die Festplatten wirklich nicht kaputt sind. Ich mache keine außerordentlich ausführliche Prüfung, sondern ich checke einfach nur mal, ob die durch S.M.A.R.T. gemeldeten Probleme noch da sind:

sudo smartctl -a /dev/sdb

Und das mache ich natürlich mit allen als defekt gemeldeten Platten. Die Ausgabe ist sehr umfangreich, zumeist reicht aber, die ersten paar Werte zu sehen, und ob sie in Ordnung sind. In meinem Fall sind beide Platten in Ordnung, weiß der Geier, warum die rumgezickt haben.

Wie auch immer, wo ja nun klar ist, dass /dev/sdb1 und /dev/sdc1 in Ordnung sind, können wir das RAID wieder reparieren. Und zwar teile ich MDADM mit, dass die Platten in Ordnung sind und er sie starten soll, auch wenn er meint, er würde Fehler finden.

sudo mdadm --assemble --force /dev/md0

Nun startet zwar das RAID, aber nur mit 4 statt 5 Platten. Aber es startet. Nun gucke ich mit cat /proc/mdstat mal rein, was das Problem ist, und /dev/sdb1 ist aus irgendwelchen Gründen nicht hinzugefügt worden. Es ist also gar nicht mehr im RAID-Verbund. OK, dann müssen wir diese Platte wieder hinzufügen:

sudo mdadm --add /dev/md0 /dev/sdb1

Die Platte wird dem RAID hinzugefügt und die Rekonstruktion des RAID beginnt. Dies kann einige Zeit dauern, in meinem Fall so um die 5 Stunden.

Fazit

Das Schöne ist, man kann den Rechner jetzt einfach abschalten, zurück in seine dunkle Ecke tragen und dort wieder in Betrieb nehmen. Der Server startet wieder normal und beginnt sofort die Rekonstruktion.

Ich habe von meinen Daten ein Backup. Schlimmstenfalls wäre mir Arbeit von 3 oder 4 Tagen verlorengegangen, damit hätte ich leben können. Ich bin aber dennoch erstaunt, wie robust das RAID-System ist. Zwar war wieder eine Menge Lesen angesagt, aber letztlich kann man sich selbst aus so einer Situation wieder retten.

Andererseits habe ich nicht die geringste Ahnung, was eigentlich passiert ist. Wieso waren die beiden Laufwerke auf einmal nicht mehr ansprechbar? Da ich die Ursache nicht kenne, und auch irgendwie nicht rausfinde, bleibt mir nur zu hoffen, dass es so schnell nicht wieder passiert. Und falls doch, immer schön das Backup aktuell halten!

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.