Alle Beiträge von Kamil Günay

Homeserver 29: Kalender und Kontakte

Jetzt, wo der Server von außen erreichbar ist, kann ich damit beginnen, ein paar der wirklich interessanten Features zu installieren. Ich habe so einiges im Hinterkopf, aber beginnen wir heute mal damit, CalDAV und CardDAV zu installieren.

Diese beiden Dienste ermöglichen es mir, meine Kontakte und Kalender auf meinem eigenen Server zu hosten. Das hat gleich mehrere Vorteile:

  • Ich bin unabhängig von externen Diensten wie iCloud, Google oder sonstigen Anbietern.
  • Die Daten liegen bei mir. Das lässt mich wegen des Datenschutzes beträchtlich ruhiger schlafen.
  • Ich bin geräteunabhängig. Bei Fremddiensten, wie iCloud, bin ich auf Apple festgelegt. Andere Systeme und Geräte sind nur mit umständlichen Kniffen zu nutzen.

Bis jetzt liegen meine Daten in der iCloud. Mit meinem iPhone und meinem MacBook ist das ja kein Problem, aber mit Thunderbird komme ich kaum an die Daten ran. Und was ist, wenn ich mich später mal für ein Android-Gerät entscheide, sei es auch nur zum Ausprobieren?

CalDAV und CardDAV sind mehr oder weniger standardisierte Systeme, die so ziemlich von jedem modernen Gerät oder Programm verstanden werden. Somit bin ich wesentlich flexibler. Zwar muss bei manchen Programmen und Geräten Software nachinstalliert werden, aber das ist in der Regel schnell gemacht.

Nachtrag zur Erreichbarkeit aus dem Netz

Im letzten Teil habe ich beschrieben, wie ich meinen Server von außen zugänglich gemacht habe. Ich muss hierzu einmal einige Kleinigkeiten konkretisieren.

Ich hätte mir bei FreeDNS eine Subdomain als CNAME-Eintrag machen können. Das wollte ich aber nicht, weil es zum Einen nur mit einem CAPTCHA ging, und ich gerade niemanden hatte, der mir helfen konnte, und zum Anderen, weil man sich eine aus einem Pool öffentlicher Domains eine aussuchen müsste. Ich wollte einfach nicht, dass mein Server z. B. unter server.chickenkiller.com oder crabdance.com erreichbar ist. :-) Andererseits, wer keine andere Möglichkeit hat, das ist kostenlos.

Ich habe ja schon Domains, also habe ich mal selbst Subdomains angelegt, die aber alle ein Problem haben: Es sind alles HTTP-Weiterleitungen. Das nutzt mir so nichts, weil ich z. B. über diese Subdomains nicht per SSH auf meinen Server zugreifen kann. Aber jetzt habe ich eine Subdomain unter einer meiner Domains mit einem CNAME-Eintrag, der dann auf die Adresse server01.xxx.myfritz.net zeigt. Und jetzt kann ich jeden Dienst mit jedem Port aus dem Internet über meine neue Subdomain erreichen.

Wenn ihr also euren Server, NAS oder sonst was von außen erreichen wollt, und über MyFritz! geht, ist eine Subdomain mit einem CNAME-Record das, was ihr wollt. :-) Manche können ihre DNS-Einträge ja selbst verwalten, falls ihr nicht zu denen gehört, fragt mal freundlich bei euren Providern nach. Da werdet ihr dann auch geholfen. :-)

Auswahl der Software

Kommen wir jetzt also mal zur Auswahl der Software für das CalDAV und CardDAV. Da gibt es ja ein paar, aber ich habe mich für den Baical-Server entschieden. Es gibt hier zwei Downloads, die Regular Version, und die Flat-Version. Dabei unterscheiden die sich nur in ihrer Installationsmethode. Regular war mir zu umständlich, zu kompliziert, keine Lust dazu! Also habe ich die Flat-Version heruntergeladen.

Installation

Wenn man sich also das Flat-Package heruntergeladen und ausgepackt hat, hat man ein Verzeichnis, in dem ein Verzeichnis “baikal” existiert. Dieses Verzeichnis lade ich nun auf meinen Server ins HTML-Verzeichnis. Ich hatte mir dafür ja eine SMB-Freigabe zugelegt, so dass ich mir den Pfad da nicht merken muss. Stattdessen habe ich mir hierfür einen Laufwerksbuchstaben zugewiesen, in dem sich jetzt das Hauptverzeichnis meines Webservers befindet. Hier kopiere ich das baikal-Verzeichnis rein.

Nun gehe ich auf meinen Server, und da ich ja lokal bin,

http://server01/baikal/admin

Dies startet den Installationsvorgang.

Juhu! Fehlermeldung! Was für eine Freude! Denn davon stand in der Installationsanleitung nix! Aber OK, mach ich doch, was da steht. Denn die Fehlermeldung sagt, die Installationsroutine sei locked, also gesichert. Ist ja auch sinnvoll, sonst könnte man vielleicht eine bestehende Installation beschädigen. Man löst das Problem dadurch, indem man einfach eine leere Datei mit dem Namen “ENABLE_INSTALL” in Großbuchstaben anlegt. Diese Datei kommt ins Verzeichnis “Specific” im Baikal-Verzeichnis. Dann klappt’s auch mit der Installation. :-)

Es werden nur ein paar Fragen gestellt, dann kann es auch schon los gehen:

  • Server Time zone: Hier wählt man die Zeitzone aus. Für mich in Deutschland natürlich “Europe/Berlin”.
  • Enable CalDAV: Natürlich hake ich das an, will ja Kalender synchronisieren.
  • Enable CardDAV: Aktiviere ich ebenfalls für Adresssynchronisation.
  • WebDAV authentication type: Hier wählt man Basic aus.
  • Admin-Passwörter: Hier wählt man das Passwort für den Admin aus.
  • Enable Web Interface: Sollte man anhaken, sonst hat man kein Webinterface mehr… :-)
  • Web interface autolock: Das lasse ich deaktiviert.

Mit der Schaltfläche “Save” Speichert man das ganze ab. Und nun geht es zur Datenbank-Konfiguration.

Datenbank anlegen

Bevor ich jetzt weitermachen kann, muss ich erst mal eine Datenbank anlegen. Irgendwohin müssen die Daten ja hingeschrieben werden. Also öffne ich in einem weiteren Tab meines Browsers die Adresse:

http://server01/phpmyadmin

Hier melde ich mich mit Benutzernamen und Passwort an und klicke auf den Link “Datenbanken”.

Die Maske für die Erstellung einer neuen Datenbank ist bereits auf dem Bildschirm, ich brauche sie nur auszufüllen. Eigentlich reicht der Datenbankname schon, dann auf den Anlegen-Schalter klicken, fertig! Den Tab mit PHPMyAdmin können wir wieder schließen und die Konfiguration von Baikal fortsetzen.

Baikal weiter konfigurieren

Bei “Use MySQL” ist ein Haken gesetzt, so dass Baikal nun eine MySQL-Datenbank nutzen kann. Die weiteren Felder werden wie folgt ausgefüllt:

  • MySQL Host: Hier kommt “localhost” rein.
  • MySQL database name: Hier kommt der Datenbankname rein, den wir gerade für die neue Datenbank gewählt haben.
  • MySQL username: Benutzername für MySqL.
  • MySQL password: Nun, sagt ja schon der Name… :-)

Um nun fortfahren zu können, klicke ich auf “Save changes”. Und das war es auch schon. Die Installation ist abgeschlossen und die Installationsroutine ist wieder “locked”.

Erste Schritte

Wenn ich jetzt meinen Browser öffne und folgende Adresse eingebe:

http://server01/baikal/admin

So komme ich auf eine Anmeldungsseite, wo ich mich erst mal mit dem Benutzernamen Admin und dem bei der Konfiguration festgelegten Passwort anmelden muss. Dann öffnet sich das Dashboard mit allerhand nützlichen und statistischen Daten. Hier kann ich auch die Einstellungen einsehen und ggf. ändern.

Bevor ich jetzt aber irgendetwas sinnvolles machen kann, muss ich mir erst mal einen Benutzer anlegen. Dafür klicke ich auf den Link “Users and resources”. Und hier klicke ich auf den Link “Add user”.

Hier müssen nicht viele Felder ausgefüllt werden:

  • Username: Hier kann man einen Benutzernamen festlegen.
  • Display name: Der Name, der angezeigt werden soll.
  • Email: E-Mail-Adresse des Benutzers.

In den beiden Passwortfeldern gibt man noch ein Passwort an und klickt dann auf “Save changes”. Komischerweise ist das Dialogfeld zum Erstellen von Usern aber noch offen. Macht sinn, wenn man noch welche erstellen will. Das will ich nicht, daher gehe ich ganz nach unten, und klicke auf “Close”.

Nun steht mein User auf der Seite. Daneben befinden sich Links, optisch sehen sie eher aus wie Schalter.

Klicke ich auf “Calendars”, sehe ich, welche Kalender für mich bereits vorhanden sind, ich kann Kalender zusätzlich erstellen, bearbeiten oder löschen. Hier befindet sich bereits ein Kalender, der sich “Default calendar” nennt. Klicke ich daneben auf “Edit”, habe ich folgende Felder:

  • Display name: Das ist der Anzeigename des Kalenders, hier steht “Default calendar”. Das ändere ich mal…
  • Description: Eine Beschreibung, auch das ändere ich mal.
  • Todos: Aktiviert man dies, so kann man hier auch Aufgaben eintragen. Das ist hier schon aktiv, das lasse ich mal so.
  • Notes: Aktiviert man dies, so sind auch Notizen im Kalender möglich. Das ist hier deaktiviert, ich aktiviere das mal.

Anschließend noch auf “Save changes” und danach auf “Close” klicken. Weitere Kalender brauche ich erst mal nicht. Sollte ich aber einen privaten und einen geschäftlichen Kalender haben wollen, so könnte ich mir jetzt einen weiteren anlegen. Da ich das nicht will, klicke ich weiter oben auf “Back to users list”.

Klicke ich nun auf “Adress books”, so habe ich die gleiche Ansicht wie eben, nur halt mit Adressbüchern, und nicht mit Kalendern. Also klicke ich auch hier auf Edit, um einige Einstellungen zu prüfen:

  • Display name: Ändere ich, dort steht “Default adress book”.
  • Description: Auch hier gebe ich eine Beschreibung ein.

Mehr gibt es hier nicht, ich klicke also auf “Save changes” und dann auf “Close”.

In beiden Fällen, direkt über dem Feld “Display name”, steht ein Wert, der später noch wichtig wird, die “Token ID”. Dies ist für die URL wichtig, wenn wir die Adressbücher und Kalender in die jeweiligen Programme eintragen. Bei beiden stand jetzt “default”, aber bei nachträglich erstellten Kalendern und Adressbüchern müsst ihr euch das angucken.

Mit der Weboberfläche sind wir erst mal fertig.

Kalender und Adressbuch nutzen

Um jetzt das Adressbuch und den Kalender mit dem Server synchronisieren zu können, sind mehrere Schritte von Nöten. Am wichtigsten ist, die Daten aus der iCloud zu befreien um sie in den Server importieren zu können. Hat man einen Mac, ist das sogar recht einfach. Wenn nicht, nun, den Fall kann ich jetzt nicht nachstellen, weil ich dieses Problem nicht habe.

Adressbuch sichern

Am einfachsten kann ich mein Adressbuch mit meinem iPhone sichern. Dafür habe ich eine App, die die Kontakte als Excel-Tabelle exportiert, und auch wieder importiert. Also starte ich Excel Contacts, … oh, Moment, die App heißt ja jetzt anders. OK, dann öffne ich halt die App SA Kontakte. :-) Hier kann ich meine Kontakte als Excel-Tabelle in meine Dropbox ablegen.

Nachdem ich dies getan habe, kann ich am Mac in der Anwendung Kontakte alle Kontakte löschen. Somit sind diese alle raus aus der iCloud. Anschließend kann ich auf beiden Geräten, dem iPhone und dem Mac, das Synchronisieren der Kontakte mit der iCloud deaktivieren.

Kalender sichern

Hier wüsste ich nicht, ob und wie das mit dem iPhone geht. Dies geht aber wunderbar mit dem Kalender auf dem Mac. Um den Kalender als ICS-Datei zu exportieren geht man folgendermaßen vor:

  • Ich öffne den Kalender am Mac.
  • Im Menü “Ablage” im Untermenü “Exportieren” aktiviere ich den Punkt “Exportieren”.
  • Im Dialogfeld wähle ich nun den Namen der Export-Datei und dessen Ort.

Das war es schon. Nach dem Aktivieren der Schaltfläche “Exportieren” befindet sich die Datei “Kalender.ics” in meinem Home-Verzeichnis.

Nun kann ich auch den Kalender in der App Kalender auf dem Mac löschen. Zuvor kann es sein, dass ich einen leeren neuen Kalender erstellen muss, weil sich der Standard-Kalender sonst nicht löschen lässt.

Anschließend kann ich die Kalendersynchronisation auf dem iPhone und dem Mac mit der iCloud deaktivieren.

Kalender und Kontakte auf dem Mac einrichten

Um die Kontakte und den Kalender nun am Mac zu nutzen, müssen noch die Accounts dort eingerichtet werden. Für den Kalender geht das wie folgt:

  • Ich öffne die Kalender-App und gehe mit Befehl+, in die Einstellungen.
  • Ich interagiere mit der Symbolleiste und aktiviere das Symbol für “Accounts”.
  • Mit VO+Pfeil-rechts gehe ich bis zur Optsionsschaltfläche “Account hinzufügen” und aktiviere diese.
  • Aus der Liste der Accounttypen wähle ich “CalDAV-Account hinzufügen”.
  • Im nächsten Dialogfeld wähle ich als Account-Typ “Manuell”, da Mac OSX bestimmt nicht meine Serveradresse kennt… :-)
  • Bei Benutzername und Passwort gebe ich die Daten ein, die ich bei der Erstellung des Benutzers im Baikal-System gewählt habe.
  • Als Serveradresse gebe ich folgendes ein: “http://subdomain.domain.de/baikal/cal.php/principals/benutzername”. Die Werte müsst ihr je nach euren Gegebenheiten anpassen. Das betrifft den Teil mit der subdomain und domain, sowie den Benutzernamen am Ende.
  • Anschließend noch auf “Erstellen” klicken und je nach Wunsch einige Anpassungen im Dialogfeld machen, wie Accountname usw.

Das gleiche mache ich jetzt für die Kontakte:

  • Ich öffne die Kontakte-App und gehe mit Befehl+, in die Einstellungen.
  • Ich interagiere mit der Symbolleiste, gehe zum Symbol “Accounts” und dann auf “Hinzufügen”.
  • In der Liste der Accounttypen wähle ich “Anderer Account”.
  • Accounttyp: CardDAV.
  • Benutzername und Passwort wie in Baikal eingerichtet.
  • Serveradresse: “http://subdomain.domain.de/baikal/card.php/”. Die Werte müsst ihr evtl. an eure Gegebenheiten anpassen.

Anschließend noch auf Erstellen klicken, evtl. noch die Accountbeschreibung anpassen und in den Server-Einstellungen SSL aktivieren.

Bei dem iPhone geht das übrigens nahezu genau so mit den gleichen Adressen. Ihr geht in den Einstellungen auf “Mail, Kontakte, Kalender”. Hier doppeltippt ihr die Taste “Account hinzufügen”. Jetzt könnt ihr als Account-Typ CalDAV oder CardDAV auswählen. Die einzugebenden Daten sind die gleichen, wie für die Mac-Varianten, daher gehe ich jetzt da nicht weiter drauf ein.

SSL-Verschlüsselung

Der Server ist ja schon SSL-verschlüsselt, was ja sogar durch eine Änderung von mir erzwungen wird. Der Mac, als auch das iPhone, werden über das selbsterstellte Zertifikat meckern. Man kann hier aber einmalig festlegen, dass dem Zertifikat getraut werden kann, somit hat man eine SSL-verschlüsselte Verbindung. Das gilt genau so für die Thunderbird-Synchronisation, wie ich sie weiter unten beschreibe. Auch hier kann man dem Zertifikat einmalig vertrauen. Danach ist auch diese Verbindung mit SSL gesichert.

Importieren des zuvor exportierten Kalenders

Die Kalender.ics-Datei, die ich vorhin exportiert hatte, möchte ich ja wieder im neuen Kalender haben. Also öffne ich mal die Kalender-App am Mac. Im Menü “Ablage” wähle ich den Punkt “Importieren”. Nachdem ich die Datei in der Liste ausgewählt und auf “Importieren” geklickt habe, dauert es je nach Größe der Datei eine Weile. Anschließend ist noch der Zielkalender zu wählen, fertig!

Adressen importieren

Hierzu bemühe ich mich wieder der SA Kontakte App. Das ist über das iPhone immer noch die einfachste Möglichkeit. Ich aktiviere den Reiter Import, wähle die zuvor exportierte Datei aus der Dropbox aus und starte den Import-Vorgang. Nach kurzer Zeit sind alle meine Adressen wieder in den Kontakten!

Geht auch Thunderbird?

Aber sicher doch! Es sind nur zwei Addons nötig, Lightning für Kalender und Aufgaben und der SOGO Connector für CardDAV. Lightning ist im Addon-Bereich des Thunderbirds zu finden, den SOGO Connector kann man hier downloaden. Die XPI-Datei des SOGO Connectors muss dann in Thunderbird unter “Extras” und dort unter “Addons” aus der Datei installiert werden.

Kalender in Lightning

Um den Kalender in Lightning einzubinden gehe ich wie folgt vor:

  • In Thunderbird, im Menü “Datei”, dort unter “Neu” wähle ich “Kalender”.
  • Aus der Auswahl wähle ich “Im Netzwerk”.
  • Bei Kalenderformat wähle ich “CalDAV.
  • Die Adresse ist: “http://subdomain.domain.de/baikal/cal.php/calendars/benutzername/default”. Die Werte müsst ihr an eure Gegebenheiten anpassen. Dabei ist “default” die Token ID des Standardkalenders. Wollt ihr einen zweiten Kalender, den ihr im Baikal-System hinterlegt habt, nutzen, so muss hier dessen Token ID hin. Wie man diese herausfindet, habe ich ja weiter oben schon beschrieben.
  • Offline-Unterstützung habe ich aktiviert und klicke auf “Weiter”.
  • Im nächsten Dialog vergebe ich einen Namen für den Kalender und gebe auch meine Mailadresse an. Anschließend klicke ich auf “Weiter”.
  • Nach einer Weile erscheint ein Dialogfeld, welches einem die Fertigstellung des Kalenders meldet. Hier klickt man auf “Fertig”.

Der Kalender ist jetzt aber noch nicht zu sehen. Zunächst muss ich die Maus irgendwie zum Kalendereintrag bringen, mit rechter Maustaste klicken und aus dem Kontextmenü “Synchronisieren” wählen. Nun werde ich nach Benutzernamen und Kennwort gefragt, und ob ich die Daten speichern will. Ab jetzt kommen die Kalenderdaten auf meinen Rechner.

Adressbuch in Thunderbird einrichten

Um das Adressbuch in Thunderbird einzubinden, gehe ich wie folgt vor. Dass der SOGO-Connector korrekt installiert wurde, setze ich einfach mal voraus… :-)

  • In Thunderbird öffne ich aus dem Menü “Extras” das Adressbuch.
  • Aus dem Menü “Datei” und dort aus dem Untermenü “Neu” wähle ich “Remote-Adressbuch”.
  • Verbindungsname: Ein Name für das Adressbuch.
  • URL: “http://subdomain.domain.de/baikal/card.php/addressbooks/benutzername/default”. Gegebenenfalls müsst ihr die Werte für euch anpassen. Auch hier gilt, für ein zweites Adressbuch muss “default” durch die Token ID des zweiten Adressbuches ersetzt werden.

Die anderen Einstellungen könnt ihr so vornehmen, wie euch danach ist. Das ist sowieso zu meist Geschmackssache, wann man über was informiert werden will. Jedenfalls klicke ich nun auf OK.

Damit die Kontakte nun sichtbar werden, also die erste Synchronisation durchgeführt wird, muss ich auf mein neues Adressbuch mit der rechten Maustaste Klicken und aus dem Kontextmenü “Synchronisieren” wählen. Nach Eingabe von Benutzernamen und Passwort sollten die Daten eintrudeln. Allerdings, wenn ihr den Kalender schon erfolgreich synchronisiert habt, wird nicht mehr nach Benutzername und Passwort gefragt, weil das ja dieselben sind, und Thunderbird diese ja schon kennt.

Fazit

Jetzt habe ich Kontakte und Kalender auf meinem eigenen Server, mein iPhone, Mac und mein Windows-PC synchronisieren sich damit prima. In der Familie habe ich auch noch jemanden mit einem Android-Gerät. Vielleicht kann ich den ja überreden, sich mal CalDAV-Sync und CardDAV-Sync auf sein Gerät zu installieren und mal zu probieren, ob es damit auch geht. Einen User kann ich ja mit wenigen Klicks erstellen. :-)

Homeserver 28: Von außen auf den Server zugreifen

Es gibt immer wieder Situationen, in denen es doch schön wäre, wenn man von außen auf den Server käme. Zum Beispiel, als mir letztens die Platten im RAID verrücktgespielt hatten. Da hätte ich von außen einiges tun können, so musste ich warten, bis ich wieder zu Hause bin. OK, in diesem Falle war das jetzt nicht so schlimm. Aber in der Zukunft soll der Server auch zum Videorekorder werden, und dann würde einfach nichts mehr aufgenommen werden. Das wäre dann schon nicht mehr so schön…

Hierbei gibt es zwei Zugangsarten, die für mich wichtig sind. Zum Einen möchte ich auf die Weboberfläche des Servers kommen. Hier könnte ich die Logs sehen, Temperaturen abfragen und später, wenn es denn mal eingerichtet ist, Aufnahmen programmieren. Alles natürlich, wie in den letzten Teilen beschrieben, SSL-verschlüsselt und Passwort-gesichert. Lest euch hier dazu noch mal die Artikel zur Webserver-Installation im Teil 20 und das Absichern des Webservers im Teil 23 durch.

Das ist jetzt aber eigentlich erst mal nur recht informativ, aber von hier aus kann ich nicht wirklich was tun. Also muss ich auch irgendwie auf die SSH-Oberfläche des Servers. Ich weiß nicht wirklich, ob das auch so über die gleiche Art funktioniert, wie für den Webserver, daher richte ich hierfür eine VPN-Verbindung ein. Die hat auch den Vorteil, dass ich auch auf die Datenverzeichnisse des Servers zugreifen kann.

Vorbereitungen

Viel gibt es da gar nicht vorzubereiten. Ich möchte, wenn ich mal nicht zu Hause bin, von meinem MacBook aus auf mein Netzwerk zugreifen können. Hierfür, und für noch eine ganze Anzahl anderer Aufgaben, habe ich ein Windows in einer virtuellen Maschine auf dem Mac laufen. In dieses Windows müssen alle Tools, die dafür benötigt werden, installiert werden. Dabei ist das bei mir z. B. Putti, oder wenn man möchte, Cygwin, als SSH-Client.

Fernzugriff auf den Webserver

Eigentlich braucht es hierfür nur einen DynDNS-Account. Da ich als Privatperson ja nicht immer eine feste IP-Adresse habe, braucht es so eine Hilfstechnik. Und da ich mein Netz mit einer Fritz!Box ans Netz angebunden habe, würde sich ja der MyFritz-Dienst anbieten. Also melde ich mich dort an.

MyFritz!-Konto erstellen

Ich öffne also den Webbrowser meiner Wahl und gebe in die Adresszeile “fritz.box”, natürlich ohne die Anführungsstriche, ein. Es öffnet sich das Login-Fenster der Fritz!Box, in das ich mein Passwort eingebe und Enter drücke.

Um nun zu der Funktion zu gelangen, unter der man sich einen MyFritz-Zugang anlegen kann, muss man auf den Link “Internet”, und dann den Link “MyFritz” klicken.

Hier wähle ich weiter unten aus, ob ich ein neues Konto erstellen möchte, oder ob ich meine Fritz!Box an einem vorhandenen Konto anmelden möchte. Da ich noch kein Konto habe, wähle ich “Neues MyFritz!-Konto erstellen” aus. Anschließend gebe ich noch meine Mailadresse ein und wähle mir ein Kennwort für den MyFritz!-Dienst. Danach klicke ich auf “Weiter”.

Nun sagt mir die Fritz!Box, dass ich einen Benutzer anlegen soll:

Für den Zugriff aus dem Internet ist die Einrichtung eines FRITZ!Box-Benutzers erforderlich. Der Internetzugriff ist nur mit Benutzername und Kennwort möglich.

OK, dann fülle ich mal die Felder aus, die mir hier angeboten werden. Im Feld “Name” wähle ich einen Benutzernamen, das Feld für die E-Mail-Adresse ist schon ausgefüllt, und dann muss noch ein Kennwort für den Fritz!Box-Benutzer festgelegt werden. Und hiernach klicke ich wieder auf “Weiter”.

Jetzt öffne ich mein Mailprogramm, denn bei meiner Anmeldung an den MyFritz!-Dienst hat mir das System eine Mail geschickt, in der ein Bestätigungslink ist. Diesen klicke ich an.

Es öffnet sich nun der Webbrowser. Hier muss man jetzt die Nutzungsbedingungen für MyFritz! durchlesen und mit einem Kontrollkästchen akzeptieren. Klickt man dann auf “Konto aktivieren”, wird das MyFritz!-Konto bestätigt und die Fritz!Box daran angemeldet.

Und wie geht es jetzt weiter?

Anmelden an der Fritz!Box

Zwei Dinge gilt es nun zu tun: Zum Einen möchte ich wissen, ob meine Fritz!Box von außen zugänglich ist, zum Anderen wüsste ich gerne den Link zu ihr. Also, nur um sicher zu gehen, schließe ich mal alle Browserfenster und öffne ein neues leeres Fenster. Hier gebe ich in die Adresszeile “myfritz.net” ein.

Auf dieser Seite kann ich mich nun anmelden, indem ich hier meine E-Mail-Adresse und mein MyFritz!-Kennwort eingebe. Weiter unten gibt es ein Kontrollkästchen, “Ich bin kein Roboter!”, dieses solltet ihr wirklich aktivieren. :-) Danach könnt ihr weiter unten auf die Schaltfläche “Zu meiner Fritz!Box”” klicken.

Jetzt passiert etwas ähnliches, wie mit meinem für meinen Webserver erstellten SSL-Zertifikat. Auf dieser Seite wird mir nun erklärt, was ich machen muss, aber das weiß ich ja schon aus Teil 23.

Wichtiger ist, dass hier auch der direkte Link zu meiner Fritz!Box steht. Dummerweise ist das aber ein Link, den sich keiner merken kann. Er sieht in etwa so aus:

https://XXX.myfritz.net:YYY/myfritz?user=meine_mailadresse%40gmx.de

Wobei das XXX für eine lange Buchstaben- und Zahlenkette steht, und als E-Mail-Adresse am Ende natürlich die Mailadresse, mit der ich mich angemeldet habe. Das YYY steht für eine zufällig vergebene Portnummer, die man in der Fritz!Box auch ändern kann. Wie gesagt, das kann sich ja keiner merken! Dafür muss ich noch eine Lösung finden!

Klicke ich auf diesen Link, erhalte ich die bekannte Fehlermeldung, dass der Verbindung nicht vertraut werden kann. Macht nix, ich kenne meine Fritz!Box, daher klicke ich wieder unten auf “Ich kenne das Risiko”. Nun klicke ich auf “Ausnahmen hinzufügen”, im folgenden Dialog auf “Zertifikat herunterladen”, hake das Kästchen bei “Diese Ausnahme dauerhaft speichern” an und klicke dann auf “Sicherheitsausnahme bestätigen”. Fertig, die Anmeldeseite meiner Fritz!Box öffnet sich.

Gerätefreigabe Einrichten

Ich will ja meinen Server von außen erreichen können. Also muss ich ihn ja auch für den Zugriff von außen freigeben. Hierfür gehe ich wieder auf die Benutzeroberfläche der Fritz!Box und gehe nacheinander im Navigationsbereich auf “Internet” und auf “Freigaben”.

In dieser Tabelle stehen alle Geräte, mit ihren von außen erreichbaren Adressen, auf die ich über meinen Browser zugreifen können möchte. Natürlich steht da jetzt noch kein Gerät, daher klicke ich auf “Neue MyFritz!-Freigabe”. Es öffnet sich ein Fenster, welches folgende Daten abfragt:

  • Netzwerkgerät: Hier wähle ich “server01″.
  • Anwendung: Hier wähle ich HTTPS-Server.
  • Verzeichnis: Das lasse ich leer, ist sowieso optional.

Anschließend klicke ich noch auf OK, damit wäre die Freigabe eingerichtet. Nun sehe ich in der Tabelle das Gerät, die Adresse und den dafür konfigurierten Dienst. Die Adresse für meinen Server sieht jetzt also so aus:

https://server01.xxx.myfritz.net:443

Wobei, den Port am Ende kann man auch weglassen, solange es ein Standard-HTTPS-Port ist. Die Fritz!Box selbst hat einen zufälligen Port erhalten, den muss ich angeben, wenn ich auf die Fritz!Box-Oberfläche aus dem Internet zugreifen möchte. Ich könnte mich hierfür natürlich auch einfach über myfritz.net anmelden.

So, auf meinen Server kann ich jetzt zugreifen, Logs sehen, Manpages lesen, aber das reicht mir ja noch nicht. Ich will auch per VPN auf SSH zugreifen können.

VPN einrichten

Um mit meinem iPhone oder meinem MacBook per VPN auf mein Netzwerk zugreifen zu können, muss ich dies in der Fritz!Box einstellen. Dies ist sogar recht einfach. Ich logge mich auf der Benutzeroberfläche der Fritz!Box ein und gehe im Navigationsbereich nacheinander auf “Internet” und “Freigaben”. Im oberen Bereich des Fensters wähle ich “VPN” aus. In der Tabelle stehen nun die verfügbaren VPN-Verbindungen. Da ist natürlich noch keine, daher füge ich mit der Schaltfläche “VPN-Verbindung hinzufügen” eine neue Verbindung hinzu.

Zunächst werde ich gefragt, was für eine Verbindung ich einrichten möchte. Ich wähle daher den Punkt “Fernzugang für einen Benutzer einrichten”.

Nun öffnet sich die Liste der in der Fritz!Box eingerichteten Benutzer. Ich wähle also den für MyFritz! eingerichteten Benutzer aus und betätige die “Bearbeiten”-Schaltfläche daneben. In der Liste der Berechtigungen aktiviere ich das Kontrollkästchen “VPN” und klicke dann auf OK.

Normalerweise sollte sich ein Fenster öffnen, welches zeigt, was man wo in sein iPhone oder Android-Gerät eingeben soll. Bei mir ist das nicht passiert, stattdessen habe ich einen OK-Schalter, der mir dann das Fenster öffnet. Das nutzt mir nur gerade nix, weil mein iPhone nicht geladen ist und am Strom hängt.

Das macht aber nichts, denn man kann sich die Daten jederzeit erneut anzeigen lassen. Man loggt sich einfach auf die Benutzeroberfläche der Fritz!Box ein, wählt im Navigationsbereich “System”, dort “Fritz!Box-Benutzer”, klickt neben dem für VPN berechtigten Benutzer auf “Bearbeiten” und kann sich weiter unten mit dem Link “VPN-Einstellungen anzeigen” das Fenster erneut anzeigen lassen. Hier folgt man dann einfach den Anweisungen.

Mit dem iPhone über VPN verbinden

Die Einstellungen in das iPhone zu fummeln ist etwas kompliziert. Gut für den, der eine externe Tastatur sein eigen nennt. Denn zum einen muss man die kryptische MyFritz!-Adresse eingeben und das Shared Secret, welches aus Zahlen, Klein- und Großbuchstaben besteht und 16 Stellen lang ist. Auch Benutzername und Kennwort kann man bei der Einrichtung der Verbindung im iPhone gleich angeben. Die Anleitung, die über den Link “VPN-Einstellungen anzeigen” geboten wird, hat bei meinem iPhone jedenfalls tadellos funktioniert.

Um mich nun mit dem VPN zu verbinden, sollte man zum Testen mal machen, schalte ich erst mal mein WLAN am iPhone ab. Ich will mich über das 3G-Netz verbinden. Nun gehe ich in die App Einstellungen. Jetzt befindet sich unterhalb von “Persönlicher Hotspot” der Schalter “VPN”. Wenn man den doppeltippt, dauert es eine Weile, bis die Verbindung aufgebaut ist, anschließend wechselt der Schalter von “Aus” zu “Ein”. Genau so kann man es auch wieder trennen.

Nun schließe ich mal die App Einstellungen, und gucke mal in die Statuszeile des iPhones. Neben dem Symbol für 3G gibt es jetzt auch ein VPN-Symbol. Also öffne ich doch mal eine App, die garantiert nur in meinem eigenen Heimnetz funktionieren sollte. Da bietet sich dreaMote an, um meine Dreambox zu steuern. Die App öffnet sich und nach einer Wartezeit von etwa 5 bis 8 Sekunden kann ich sogar meine Timer sehen. Damit steht fest, auf dem iPhone funktioniert VPN prima. Dann kann ich es in der App Einstellungen ja auch wieder trennen.

VPN am MacBook

Eigentlich werden hier die gleichen Angaben gemacht, nur der Weg ist geringfügig anders. Daher beschreibe ich mal den Vorgang, VPN am MacBook einzurichten. Ich verwende hier Yosemite 10.10.2, das nur, falls es bei anderen Versionen etwas anders aussieht. Ich denke aber, da dürfte es nicht so viele Unterschiede geben. Ich gehe zum Eintragen des VPN-Zugangs ins MacBook also folgendermaßen vor:

  • Mit VO+M gehe ich ins Menü und wähle aus dem Menü “Apple” die Systemeinstellungen.
  • Hier gehe ich zu “Netzwerk” und öffne es mit VO+Leertaste.
  • Mit VO+Pfeil-rechts gehe ich weiter, bis ich zu “Dienst hinzufügen” komme, und drücke dort VO+Leertaste.
  • Im Einblendmenü “Anschluss” wähle ich “VPN”.
  • Bei VPN-Typ wähle ich “Cisco IPSec”.
  • Bei Dienstname kann ich eine Beschreibung eingeben, die ist frei wählbar.

Anschließend aktiviere ich die Schaltfläche “Erstellen”. Nun befinde ich mich wieder in der Vorherigen Ansicht, und ein weiterer Dienst wurde meiner Dienste-Tabelle hinzugefügt. Dieser muss aber noch konfiguriert werden. Wenn ich jetzt also mit VO+Pfeil-rechts weitergehe, finde ich die Angaben über Serveradresse, Account-Name und Passwort, wo ich die gleichen Werte eingebe, wie beim iPhone.

Anschließend aktiviere ich noch die Schaltfläche “Authentifizierungseinstellungen”, weil hier noch paar Angaben gemacht werden müssen. Zum Beispiel der Shared Secret und der Gruppenname. Auch diese Angaben sind die gleichen, wie für das iPhone, also fülle ich das aus und bestätige das Dialogfenster mit der OK-Schaltfläche.

Ich könnte mich hier natürlich auch verbinden, das mache ich aber nicht. Aber hier ist ein Markierungsfeld, welches man durchaus aktivieren sollte. Denn wenn man “VPN-Status in der Menüleiste anzeigen” markiert hat, kann man sich ganz bequem über das Statusmenü mit dem VPN verbinden. Dann schließe ich das Fenster, bestätige, dass ich die Änderungen übernehmen will und schließe alle Fenster.

Die VPN-Verbindung am Mac ist zwar jetzt eingerichtet, ich kann sie aber gerade nicht testen. Ich bin ja in meinem eigenen WLAN, da macht das nicht so viel Sinn. Dies zu testen muss also warten, bis ich in einem anderen WLAN bin.

Vereinfachung der MyFritz!-URL

Es gibt bekanntlich viele Wege zur Fritz!Box, hier sind mal zwei davon.

  • Man könnte sich einen Account bei FreeDNS erstellen und hier eine Subdomain registrieren. Das ist sogar kostenlos.
  • Wenn man eigene Domains hat, könnte man sich evtl. ja auch eine Subdomain hier anlegen.

Beide Varianten hätten das gleiche Ziel, aber da ich bereits mehrere Domains habe, lege ich mir eine Subdomain an.

Ein Beispiel könnte so aussehen: Ich habe ja die Domain tuksub.de. Jetzt könnte ich mir eine Subdomain einrichten, wie z. B. “linuxserver”, und als Ziel gebe ich die kryptische MyFritz!-URL an. Wenn ich in meinen Browser jetzt also linuxserver.tuksub.de eingeben würde, würde mich der Browser automatisch auf server01.XXX.myfritz.net weiterleiten, wobei XXX für den kryptischen Buchstabensalat steht, den MyFritz! mir zugewiesen hat.

Natürlich war das nur ein Beispiel, die Tatsächliche Subdomain und Domain, unter der mein Server zu erreichen ist, behalte ich mal für mich… :-)

Fazit

Es klingt alles komplizierter, als es am Ende tatsächlich einzurichten war. Allerdings war dies ein Schritt, der lange überfällig war. Denn erst jetzt werden gewisse Dinge möglich. Zum Beispiel Fehlerbehebung und Statusabfrage von außen, Programmierung des Videorekorder-Dienstes, sobald der mal installiert ist und, was jetzt auch noch kommen soll, CardDAv und CalDAV zum Synchronisieren meiner Kalender- und Kontaktdaten mit meinen Mobilgeräten.

Aber was genau ich jetzt als nächstes tue, mal gucken. In viele Bereiche muss ich mich noch einlesen, dann geht es weiter!

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.