Schlagwort-Archive: Anleitung

RHEL/CentOS 7 – Root Passwort zurücksetzen

In diesem Tutorial wird beschrieben, wie das root-Passwort bei RHEL/CentOS 7 mit Bordmitteln zurückgesetzt werden kann. Mit Bordmitteln bedeutet, dass hierbei keine externen Bootmedien verwendet werden.

Aufgepasst! Macht man bei der Ausführung der folgenden Prozedur Fehler, können diese dazu führen, dass man jeglichen Zugang zu einem System verliert. Möchte man die Vorgehensweise üben, empfehle ich, dies ausschließlich auf Testsystemen zu tun.

Die Ausgangssituation

Das root-Passwort eines RHEL/CentOS 7 Servers ist unbekannt und muss zurückgesetzt werden. Es ist keine geöffnete root-Shell vorhanden und es ist kein Benutzer am System angemeldet, welcher über vollständige sudo-Berechtigungen verfügt.

Das Passwort soll ohne Einsatz externer Bootmedien zurückgesetzt werden.

Vorgehensweise

Schritt 1: Es wird ein Neustart des Systems durchgeführt. Sobald das Grub2-Boot-Menü erscheint, wird der Bootloader-Countdown durch Drücken einer beliebigen Taste unterbrochen.

Nun wählt man den gewünschten Eintrag (dies ist meist der erste in der Liste) aus und wechselt mit Drücken der Taste ‚e‘ in den Bearbeitungsmodus (siehe Abbildung 1).

abb1-grub2-menu

Abbildung 1: Grub2-Bootmenü

Schritt 2: Der Cursor wird zur Kernel-Kommandozeile bewegt. Diese beginnt üblicherweise mit dem Wort linux16. Hier wird, wie in Abbildung 2, ein „rd.break“ an das Ende der Zeile angefügt.

edit-kernel-command-line

Abbildung 2: Bearbeitete Startparameter für den Kernel

Die Bearbeitung wird durch Drücken der Tastenkombination Strg+x beendet und der Bootvorgang fortgesetzt. Der Bootvorgang wird an der Stelle angehalten, an der man sich in der Initial-Ram-Disk befindet, direkt bevor das eigentliche System gestartet wird. An dieser Stelle findet man den Inhalt des eigentlichen /-Dateisystems unterhalb von /sysroot.

Schritt 3: Nach Schritt 2 befindet man sich nun in einer root-Shell. Da das eigentliche Dateisystem unterhalb von /sysroot schreibgeschützt eingehängt wurde, muss dieses zunächst remountet werden. Dies geschieht mit dem folgenden Kommando (vgl. Abbildung 3):

switch_root:/# mount -oremount,rw /sysroot
remount-sysroot

Abbildung 3: Remount /sysroot

Schritt 4: In diesem Schritt wechselt man mittels chroot1 in das /sysroot-Verzeichnis und setzt ein neues Passwort für den Benutzer root.

switch_root:/# chroot /sysroot
sh-4.2# passwd root
Changing password for user root.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

Wichtig: SELinux2 ist zu diesem Zeitpunkt noch nicht aktiv. Dies bedeutet, dass alle neuen Dateien ohne einen entsprechenden SELinux-Kontext erstellt werden. Das Programm passwd arbeitet so, dass es erst eine neue Datei erstellt und mit dieser anschließend die alte Datei überschreibt. Die neue Datei /etc/shadow besitzt damit keinen SELinux-Kontext.

Um sicherzustellen, dass alle Dateien (inkl. der /etc/shadow) während des Bootvorgangs mit einem SELinux-Label versehen werden, muss die Datei autorelabel im aktuellen Verzeichnis erstellt werden:

sh-4.2# touch /.autorelabel

Wichtig: Sämtliche Dateien und Verzeichnisse werden erneut mit einem SELinux-Label versehen. Dies kann bei großen Dateisystemen einige Zeit dauern. Um Zeit zu sparen, können Dateisysteme (außer dem Dateisystem auf dem sich die /etc/shadow befindet) in der /etc/fstab auskommentiert werden. Nachdem das SELinux-Relabeling durchgeführt und das System gestartet wurde, können diese wieder eingehängt werden.

Abschließend verlässt man durch zweimalige Eingabe von exit zuerst die chroot-Umgebung und anschließend die Debug-Shell der Ram-Disk (vgl. Abbildung 4). Das System setzt den Bootvorgang an der Stelle fort, an der dieser unterbrochen wurde.

autrelabel

Abbildung 4

Es werden zunächst sämtliche Dateien von SELinux relabelt und anschließend ein Neustart ausgeführt.

Hinweis: Vergisst man die Datei .autorelabel zu erstellen und wird SELinux im Modus „Enforcing“ ausgeführt, kann man sich nach einem Neustart nicht am System anmelden. Man muss dann erneut booten und obige Schritte ausführen, um die Datei erstellen zu können.

Wurden die oben aufgeführten Schritte erfolgreich angewendet, kann man sich nun mit dem vergebenen Passwort am System anmelden und hat damit die Kontrolle zurückgewonnen.

Auch wenn ich diese Anleitung mehrere Male erfolgreich getestet habe, wünsche ich uns allen, dass wir sie möglichst niemals brauchen werden.

Thunderbird Adressbuch mit ownCloud Kontakten synchronisieren

Dieser Artikel basiert auf der offiziellen ownCloud Dokumentation1 und beschreibt die Einrichtung eines Thunderbird-Adressbuchs zur Synchronisation mit den ownCloud-Kontakten.

contacts-carddav-link

Menü zum CardDAV-Link

Neben dem Thunderbird-Mailclient wird die Erweiterung Lightning2 benötigt. Wie man diese Erweiterung nutzt, um z.B. den ownCloud-Kalender mit Thunderbird zu synchronisieren, habe ich bereits an dieser Stelle beschrieben.

Um neben dem Kalender auch die Kontakte synchronisieren zu können, wird darüber hinaus der Sogo Connector3 benötigt. Am einfachsten installiert man diese Erweiterung, indem man einen Rechtsklick auf die Erweiterung ausführt und „Ziel speichern unter..“ aus dem Kontextmenü auswählt. In Thunderbird richtet man diese Erweiterung ein, indem man im Add-on Menü die Option „Add-on aus Datei installieren…“ auswählt.

Sind die beiden Erweiterungen erfolgreich installiert, kann das Adressbuch eingerichtet werden. Dazu öffnet man das Thunderbird-Adressbuch aus der Symbolleiste. Im sich öffnenden Fenster wählt man Datei->Neu->Remote-Adressbuch.

Der Verbindungsname kann frei gewählt werden. Bei URL wird der CardDAV-Link eingetragen, den man in den Einstellungen der ownCloud-Kontakte findet. Die Einstellungen verbergen sich hinter dem kleinen Zahnradsymbol.

remote-addressbook-settings

Remote-Adressbuch-Einstellungen

Die weiteren Optionen können nach den persönlichen Vorlieben gewählt werden. Einzig den Haken bei „Nur lesbar“ sollte man nicht setzen, wenn man über Thunderbird auch neue Kontakte in der ownCloud anlegen möchte.

Fertig. Damit sind die ownCloud-Kontakte in den Mailclient integriert und lassen sich z.B. für die Autovervollständigung der E-Mail-Adressen in neuen Nachrichten nutzen.

Cisco AnyConnect VPN Client unter Ubuntu installieren

Dieser Artikel beschreibt die Installation des Cisco AnyConnect VPN Client unter Ubuntu Trusty Tahr.

Laut einem Dokument1, dass ich bei der Universität Bielefeld gefunden habe, werden Ubuntu 9.x und 10.x unterstützt. Ich konnte den Client jedoch auch problemlos unter Ubuntu 14.01.1 LTS installieren.

Dazu habe ich einfach das Installationsskript vpnsetup.sh heruntergeladen, ausführbar gemacht und ausgeführt.

:~$ wget https://github.com/Tronde/Schriftrolle/blob/master/vpnsetup.sh
:~$ sudo chmod u+x vpnsetup.sh
:~$ sudo ./vpnsetup.sh

Ist das Setup durchgelaufen, kann der Client aus dem Anwendungsmenü heraus gestartet werden.

cisco anyconnect secure mobility client

Cisco AnyConnect Secure Mobility Client

In das Feld „Connect to“ müsst ihr nun nur noch eureb Verbindungsserver eintragen und schon kann es losgehen.

Die Installation ist damit abgeschlossen. Das war es schon. 🙂

Installation von VMware Tools in einer Ubuntu VM

Um den Netzwerkadapter VMXNET31 in einem virtuellen Ubuntu verwenden zu können, müssen die VMware Tools installiert sein.

Dieser Artikel beschreibt zwei Methoden, wie dies getan werden kann. Ich gehe dabei ausschließlich auf die Installation unter Verwendung der Kommandozeile (CLI) ein.

Methode 1 – Open-VM-Tools

Dieser Abschnitt basiert auf dem VMware Knowledge Base Artikel KB20738032.

Bei den open-vm-tools handelt es sich um die Open Source Implementierung der VMware Tools. Die Vorteile dieser Implementierung sind:

  • Die Open-VM-Tools sind in den offiziellen Paketquellen von Ubuntu enthalten. Dadurch wird das Deployment von virtuellen Ubuntu VMs entschieden vereinfacht. Die Installation kann direkt aus den Quellen durchgeführt werden. Es muss nicht auf separate Quellen zurückgegriffen werden.
  • Keine Downtime für das Update der VMware Tools. Das Paket open-vm-tools wird automatisch über die Paketverwaltung aktualisiert.
  • Keine Kompatibilitätsprüfung erforderlich. Aus den Paketquellen wird automatisch das zum Betriebssystem passende Paket installiert.

Die Installation der Tools ist denkbar einfach und geschieht z.B. mittels:

sudo apt-get install open-vm-tools

VMware empfiehlt ausdrücklich die Verwendung der Open-VM-Tools.3 Wer sich über den aktuellen Entwicklungsstand der Open-VM-Tools informieren möchte, kann dies auch direkt auf GitHub tun. 4

Methode 2

Diese Methode verbleibt der Vollständigkeit halber im Artikel. Es wird ausdrücklich Methode 1, wegen der dort genannten Vorteile, empfohlen.

Dieser Abschnitt basiert auf dem VMware Knowledge Base Artikel KB10225255 und führt die einzelnen Schritte auf, die benötigt werden, um die VMware-Tools in einer VM mit Ubuntu zu installieren.

Abhängigkeiten der VMware-Tools

Um die VMware Tools installieren zu können, müssen folgende Pakete auf dem System installiert sein:

  • gcc
  • binutils
  • make
  • kernel sources

Installation auf der Kommandozeile

Als Erstes wird ein Rechtsklick auf die VM in der Bestandsliste des vSphere-Clients ausgeführt. Aus dem Kontextmenü wählt man „Gast -> VMware Tools installieren/aktualisieren“.

In der laufenden Ubuntu-VM werden nun die folgenden Kommandos ausgeführt:

sudo mkdir /mnt/cdrom
sudo mount /dev/cdrom /mnt/cdrom
tar xzvf /mnt/cdrom/VMwareTools-.tar.gz -C /tmp/
cd /tmp/vmware-tools/distrib/
sudo ./vmware-install.pl -d

Nach Abschluss der Installation ist ein Neustart auszuführen. Nun kann anstatt des veralteten E1000 auch der aktuelle Netzwerkadapter VMXNET3 zur VM hinzugefügt und verwendet werden.

Ein Kalender für die Terminverwaltung

Nachdem ich in diesem Jahr bereits die Kontrolle über meine E-Mail-Postfächer zurück erlangt habe1, gehe ich in diesem Artikel auf die Einrichtung eines Kalenders für die Terminverwaltung im Web und auf diversen Clients ein.

Zu Beginn des Artikels stehen meine Anforderungen an eine Kalender-Lösung. Anschließend gebe ich einen kleinen Überblick über verschiedene kostenlose Lösungen, bevor ich die Lösung näher beschreibe, für die ich mich letztendlich entschieden habe.

Eines sei vorab schon verraten. Bei allen Lösungen handelt sich sich um Software, die auf einem Linux-Webserver installiert werden kann. Die Verwendung eines Root-Servers stellt die größtmögliche Kontrolle über das eigene System und die eigenen Daten sicher.

Anforderungen

Die gesuchte Lösung soll die folgenden Anforderungen erfüllen:

  1. Der Kalender kann auf einem eigenen Server gehosted werden.
  2. Die Terminverwaltung kann über einen Webbrowser erfolgen.
  3. Der Kalender kann unter den mobilen Betriebssystemen Android und iOS genutzt werden.
  4. Eine Nutzung des Kalenders mit dem Mozilla Thunderbird-Plugin Lightning ist ebenfalls möglich.
  5. Mit Hilfe des Kalenders können Termine zwischen den genannten Betriebssystemen und Anwendungen synchronisiert werden.

Kurz angeschaut

Auf der Suche nach einer Lösung habe ich mir die folgenden Projekte kurz angeschaut. Auch wenn ich mich im Endeffekt für ownCloud entschieden habe, führe ich sie hier auf. Evtl. ist jemandem von euch mit einer dieser Lösungen am besten gedient.

Bei sabre/dav2 handelt es sich um einen CardDAV, CalDAV und WebDAV Server. SabreDAV ist komplett in PHP geschrieben und bietet vielfältige Möglichkeiten zum Teilen und Delegieren.

DAViCal3 ist ein Server, welcher Kalendereinträge im iCalendar-Format speichern und bereitstellen kann. DAViCal ist in den Ubuntu-Paketquellen enthalten und im Ubuntuusers.de Wiki existiert ein deutschsprachiger Artikel4 dazu.

Radicale5 ist ein sehr einfach einzurichtender Server. Er ist in Python geschrieben und wurde unter der GPL 3 veröffentlicht.

Der ownCloud-Kalender

Meine Entscheidung ist auf den ownCloud6-Kalender gefallen. Er erfüllt alle oben genannten Anforderungen. Darüber hinaus benutze ich bereits eine ownCloud-Instanz zur Verwaltung meiner Kontakte, Bilder und diverser Dateien.

Die Nutzung des ownCloud-Kalenders im Webbrowser ist selbsterklärend. Daher gehe ich an dieser Stelle nur auf die Einrichtung unter iOS, dem Thunderbird-Plugin Lightning und Android ein.

Für alle drei Clients benötigen wir die CalDAV-Adresse des Kalenders. Diese kann man sich anzeigen lassen, indem man auf das Zahnrad unten Links in der Kalenderansicht klickt.

owncloud_calendar

Ansicht eines ownCloud-Kalenders

Einrichtung unter iOS

Die hier beschriebene Einrichtung gilt für iOS 7.1.2. Für andere Versionen müssen die einzelnen Schritte evtl. an die jeweilige Version angepasst werden.

  1. Gehe zu „Einstellungen“ -> „Mail, Kontakte, Kalender“ -> „Account hinzufügen“.
  2. Wähle den Punkt „Andere“ -> „CalDAV-Account hinzufügen“.
  3. Bei „Server“ wird der Hostname eingetragen. Dies ist typischerweise der Name, den man in die Adresszeile des Webbrowsers einträgt, um sich mit der eigenen ownCloud zu verbinden. Benutzername und Kennwort entsprechen den Informationen, mit denen man sich an seiner ownCloud anmeldet. Anschließend kann man noch eine Beschreibung eingeben, um den Kalender in der Übersicht wiederzuerkennen.
  4. Im weiteren Verlauf aktiviert man SSL, falls der eigene Server dies unterstützt.
  5. Bei „Account-URL“ wird die URL eingetragen, welche im ownCloud-Kalender unter „iOS/OS X CalDAV-Adresse“ angezeigt wird.

Viel Spaß mit dem ownCloud-Kalender auf dem iPhone.

Einrichtung in Lightning

Lightning7 ist ein Kalenderplugin für den Mailclient Thunderbird. Es kann über die Thunderbird-Einstellungen -> Add-ons recht simpel gesucht und installiert werden.

In der Ansicht „Erweiterungen“ können die Lightning-Einstellungen konfiguriert werden. Die Dialogfelder sind übersichtlich und zum Großteil selbsterklärend. Anschließend geht es in der Kalenderansicht weiter.

Mit einem Rechtsklick in die Kalenderspalte kann ein neuer Kalender hinzugefügt werden. Im Dialogfenster ist „Im Netzwerk“ auszuwählen und im darauf folgenden Fenster die CalDAV-Adresse des Servers anzugeben.

calendar-caldav-link

CalDAV-Link des Kalenders

Doch Achtung, hier muss der korrekte CalDAV-Link verwendet werden. Dies ist nicht, wie man vermuten könnte, der primäre CalDAV-Link, welcher unter den Kalendereinstellungen der ownCloud zu sehen ist. Statt dessen ist der CalDAV-Link zu verwenden, der direkt neben dem Kalender eingeblendet werden kann.

Im folgenden Dialogfeld kann noch eine Farbe für den Kalender ausgewählt werden und es empfiehlt sich die Offline-Funktionalität zu aktiveren. So kann man den Kalender auch verwenden, wenn keine Online-Verbindung besteht.

Damit ist die Einrichtung des ownCloud-Kalenders in Lightning abgeschlossen.

Einrichtung unter Android

Ich habe den Kalender unter Android 5.0.2 durchgeführt. Die Einrichtung sollte unter den übrigen Android-Versionen jedoch ähnlich verlaufen.

Um den ownCloud-Kalender unter Android nutzen zu können, muss zuerst eine App installiert werden, welche die CalDAV-Unterstützung nachrüstet. Ich habe mich für die kostenlose App „Cal DAV Sync Free Beta“ entschieden. In diese werden Benutzername und Passwort eingetragen, mit denen man sich an seiner ownCloud anmeldet. Hier wird die primäre CalDAV-Adresse aus den Kalendereinstellungen eingetragen, um den Kalender einzubinden.

Damit sind die wichtigsten Einstellungen vorgenommen und der Einrichtungsdialog kann bis zum Ende durchlaufen werden.

Fazit

Die Einrichtung des ownCloud-Kalenders in den verschiedenen Anwendungen und Betriebssystemen ist nicht schwer, sofern man die korrekte CalDAV-Adresse für die jeweilige Anwendung verwendet.

Damit ist ein weiterer Schritt abgeschlossen, die Kontrolle über die eigenen Daten zurückzugewinnen. Der Google-Kalender kann nun in den Ruhestand geschickt werden. 🙂

Die Termine können nun auf den verschiedenen Geräten verwaltet und synchronisiert werden. Für mich eine zufriedenstellende Lösung.

ownCloud Major-Update durchführen

Auf meinem privaten Linux-Server lief bis vor kurzem noch ownCloud 7.0.4. In diesem Artikel möchte ich kurz dokumentieren, wie das Update auf Version 8.0.0 durchgeführt wurde.

Zuerst ist sicherzustellen, dass man eine aktuelle Datensicherung der ownCloud-Installation mit dazugehöriger Datenbank hat.

Vor dem Update habe ich im Administrationsbereich meiner ownCloud die beiden Apps „Contacts“ und „Calendar“ deaktiviert. Laut unbestätigten Quellen im Internet können damit seltene Probleme vermieden werden. Dirk und hefeweiz3n haben mich in den Kommentaren zu diesen Artikel darauf hingewiesen, dass dieser Hinweis in der offiziellen ownCloud Dokumentation zu finden ist.1 Und ich dachte mir: „Better safe than sorry.“ 😉

Zunächst lädt man sich das aktuelle ownCloud Release in ein beliebiges Verzeichnis herunter und entpackt es dort.

wget https://download.owncloud.org/community/owncloud-8.0.0.tar.bz2
tar -xjf owncloud-8.0.0.tar.bz2

Anschließend wechselt man in das DocumentRoot der ownCloud-Installation und löscht dort alle Dateien und Verzeichnisse mit Ausnahme von config und data. Dies kann man z.B. schnell erreichen, wenn im DocumentRoot folgender Befehl ausgeführt wird:

find . -mindepth 1 -maxdepth 1 ! -path ./data ! -path ./config -exec rm -rf {} \;

Nun können die heruntergeladenen Dateien in das DocumentRoot kopiert werden. Im Anschluss sind lediglich die Benutzerrechte zu kontrollieren. Der Benutzer, unter dem der Webserver läuft, muss wieder überall Leserechte erhalten.

Zum Abschluss ruft man die ownCloud-Installation auf und führt die Datenbankaktualisierung durch.

Abschließend nicht vergessen, die Plugins wieder zu aktivieren.

Fertig!

An dieser Stelle noch einmal vielen Dank an kofrezo für seine Tipps vor dem Update.

Icinga 2 auf dem Raspberry Pi 2 installieren

Icinga 2 ist der Nachfolger des weit verbreiteten Monitoring Systems Icinga 1.1 Icinga 2 wurde dabei von Grund auf neu entwickelt. Um mich ein wenig mit Icinga 2 vertraut zu machen, möchte ich gern eine Testinstallation auf einem Raspberry Pi 2 ausführen und ein bis zwei Hosts in meinem Heimnetzwerk damit überwachen.

Dieser Artikel dokumentiert die Installation von Icinga 22 mit der Benutzeroberfläche Icinga Web 23 auf einem Raspberry Pi 2 Model B.

Voraussetzung für die Installation ist ein Raspberry Pi 2 Model B mit einem aktuellen Raspbian Image (Wheezy/Jessie).4 Vorhergehende Versionen des Raspberry Pi sind aufgrund der ARMv6-Architektur ungeeignet. Es ist mir nicht gelungen, Icinga 2 auf früheren Versionen des Pi zu kompilieren.

Es wird vorausgesetzt, dass man weiß, wie das Image auf die SD-Karte kopiert, der Pi in Betrieb genommen und aktualisiert wird. Grundsätzliche Kenntnisse im Umgang mit der Bash werden ebenfalls vorausgesetzt. Wer hier nochmal nachlesen möchte, kann dies im Artikel „Auf den Pi gekommen“ tun.

Installationsvoraussetzungen

Da icinga2 nicht in den Paketquellen von Raspbian enthalten ist, werden zunächst die Paketquellen des Debian Monitoring Projects hinzugefügt. 5

Da für die folgenden Kommandos Root-Rechte benötigt werden, wechselt man zuerst in eine Root-Shell:

$ sudo -s
#

Anschließend erstellt man mit einem Editor die Datei /etc/apt/sources.list.d/debmon.list und fügt folgende Zeile ein:

# Für Debian Wheezy:
deb http://debmon.org/debmon debmon-wheezy main

# Für Debian Jessie:
deb http://debmon.org/debmon debmon-jessie main

Damit die Paketverwaltung nicht bei jedem Update meckert, wird mit folgendem Kommando der Schlüssel der Paketquelle hinzugefügt:
$ wget -O - http://debmon.org/debmon/repo.key 2>/dev/null | apt-key add -
OK

Um die neue Paketquelle nutzen zu können, wird diese zuerst neu eingelesen:

apt-get update

Man hat diesen Abschnitt erfolgreich absolviert, wenn sich folgende Pakete in den verwendeten Paketquellen finden lassen:

$ apt-cache search icinga2
icinga-web-config-icinga2-ido-mysql - host and network monitoring system - config for Icinga 2 MySQL IDO
icinga-web-config-icinga2-ido-pgsql - host and network monitoring system - config for Icinga 2 PgSQL IDO
icinga2 - host and network monitoring system
icinga2-bin - host and network monitoring system - daemon
icinga2-classicui - host and network monitoring system - classic UI
icinga2-common - host and network monitoring system - common files
icinga2-dbg - host and network monitoring system - debug symbols
icinga2-doc - host and network monitoring system - documentation
icinga2-ido-mysql - host and network monitoring system - MySQL support
icinga2-ido-pgsql - host and network monitoring system - PostgreSQL support
python-icinga2 - host and network monitoring system - Python module

Achtung: Der folgende Teil des Artikels ist mittlerweile veraltet. Dies bedeutet insbesondere, dass ihm wichtige Details für die erfolgreiche Installation von icinga2 und icingaweb2 fehlen. Leider fehlt mir die Zeit, um diesen Artikel zu aktualisieren. Ich empfehle, sich für die Installation an die offizielle Dokumentation zu halten:

  1. Setting up Icinga 2
  2. Install Icingaweb2

Installation von Icinga 2

Die Installation kann nun durch Aufruf von

# apt-get install icinga2

gestartet werden.

Während der Installation von icinga2 werden die folgenden drei Funktionen aktiviert, welche für die grundlegende Funktionalität von icinga2 benötigt werden.

  • checker für die Ausführung von Checks
  • notification, um Nachrichten versenden zu können
  • mainlog, um in die icinga2.log Datei schreiben zu können

Ob diese Funktionen korrekt aktiviert wurden, kann mit folgendem Kommando überprüft werden:

# icinga2 feature list
Disabled features: api command compatlog debuglog gelf graphite icingastatus livestatus perfdata statusdata syslog
Enabled features: checker mainlog notification

Mit der Installation von icinga2 wurden die beiden Pakete monitoring-plugins-basic und monitoring-plugins-common mit installiert. Diese stellen verschiedene Check-Plugins bereit, welche man im Verzeichnis /usr/lib/nagios/pluins finden kann.

Für eine ausführliche Beschreibung aller installierten Konfigurationsdateien ist ein Blick in die offizielle Icinga 2 Dokumentation angeraten. 6

Installation von Icinga Web 2

Um die Installationsvoraussetzungen7 zu schaffen, werden zuerst die folgenden Pakete installiert.

# apt-get install mysql-server icinga2-ido-mysql apache2 libapache2-mod-php5

Ich habe mich für Apache als Webserver entschieden, da laut Dokumentation die Debian Pakete für Icinga Web 2 vom Apache abhängen.8

Während der Installation der Pakete werden die benötigten Daten durch einen Konfigurationsassistenten abgefragt. Man sollte sich die hier getätigten Eingaben notieren, um später darauf zurückgreifen zu können.

Damit DB IDO als Backend9 verwendet werden kann, muss die entsprechende Funktion in icinga2 aktiviert werden.

# icinga2 feature enable ido-mysql

Für die Installation von Icinga Web 2 hält man sich strikt an die Anweisungen in der Installation.md.

Hilfe bei Problemen

Als ich im Epiphany-Browser des Raspberry Pi die URL http://localhost/icingaweb2/setup aufgerufen habe, wurde mir nichts weiter als ein „Fatal error“ präsentiert. Hierbei handelt es sich um einen bekannten Bug (https://dev.icinga.org/issues/8370).

Als Workaround habe ich einen anderen Webbrowser (Chrome) verwendet. Damit konnte ich die Installation abschließen.

Hilfe habe ich im Forum auf www.monitoring-portal.de gefunden.

Die Installation ist damit abgeschlossen und ich habe nun ein Testsystem, mit dem ich mich tiefer in Icinga 2 einarbeiten kann.

Der eigene Mailserver – Teil 4

Herzlich willkommen zum vierten und letzten Teil dieser Artikelreihe. An dieser Stelle haben wir bereits einen voll funktionsfähigen und sicher konfigurierten E-Mail Server. E-Mailkonten können im MUA unserer Wahl eingerichtet und genutzt werden. Auf dem Server selbst können mit Leichtigkeit neue Benutzer, Mailboxen und Aliase angelegt werden. Was bleibt also noch zu tun?

Dieser Artikel beschreibt wie man das System noch weiter härten kann. Es wird gezeigt, wie der Webmailer RoundCube eingerichtet wird und wie man den Zugriff auf diesen absichert. Der Artikel endet mit einem kleinen Ausblick, um welche Features der Server noch erweitert werden könnte.

Und los geht’s!

DNS-based Blackhole List (DNSBL)

DNS-based Blackhole Lists oder kurz DNSBL sind Listen, welche von IP-Adressen oder Adressbereiche enthalten, von denen aus Spam versendet wurde.

SpamAssassin, welches in Teil 3 eingerichtet wurde, prüft bereits etliche dieser Listen und markiert eingehende E-Mails entsprechend. Dieser Artikel geht noch einen schritt weiter und beschreibt wie Postfix so konfiguriert werden kann, dass E-Mails auf Basis dieser Listen abgewiesen werden. Dazu wird in Postfix die Funktion Postscreen1 aktiviert.

Um Postscreen zu aktivieren, muss die Datei /etc/postfix/master.cf bearbeitet werden. Zu Beginn der Datei sollten folgende Einträge zu finden sein:

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      inet  n       -       -       -       -       smtpd
#smtp      inet  n       -       -       -       1       postscreen
#smtpd     pass  -       -       -       -       -       smtpd
#dnsblog   unix  -       -       -       -       0       dnsblog
#tlsproxy  unix  -       -       -       -       0       tlsproxy
submission inet n       -       -       -       -       smtpd

Hier ist die erste Zeile aus- und die folgenden vier einzukommentieren, so dass die Zeilen anschließend wie folgt aussehen:

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
#smtp      inet  n       -       -       -       -       smtpd
smtp      inet  n       -       -       -       1       postscreen
smtpd     pass  -       -       -       -       -       smtpd
dnsblog   unix  -       -       -       -       0       dnsblog
tlsproxy  unix  -       -       -       -       0       tlsproxy
submission inet n       -       -       -       -       smtpd

Falls diese Zeilen fehlen sollten, müssen sie am Anfang der master.cf eingefügt werden. Durch diese Zeilen werden die benötigten lokalen Ports und Unix Sockets, für den Postscreen Prozess, geöffnet.

Nach dieser Änderung ist die Datei /etc/postfix/main.cf am Ende um folgende Einträge zu ergänzen. Hier wird Postfix mitgeteilt, dass Postscreen zu nutzen ist und welche DNSBLs verwendet werden sollen.

postscreen_greet_action = enforce
postscreen_dnsbl_action = enforce
postscreen_access_list = permit_mynetworks
postscreen_dnsbl_sites = zen.spamhaus.org, b.barracudacentral.org, bl.spamcop.net

Die erste Zeile bewirkt, dass alle Server abgewiesen werden, die versuchen den Verbindungsaufbau in irgendeiner Form abzukürzen (um schneller Spam versenden zukönnen). In Zeile 2 wird die Prüfung anhand von DNSBLs aktiviert. Zeile 3 fügt den Inhalt der Variable „mynetworks“ hinzu, um LAN Clients von der Prüfung auszuschließen. In der vierten Zeile werden schließlich drei DNSBLs angegeben, welche zur Prüfung herangezogen werden.

Es können natürlich auch mehr, als drei DNSBLS angegeben werden. Darüber hinaus bietet Postscreen noch eine Reihe weiterer Konfigurationsparameter. Für weitere Informationen zu diesen Parametern wird auf die Dokumentation verwiesen.2

Jetzt kann Postfix mit dem Befehl

sudo service postfix restart

neugestartet werden und schon ist die neue Konfiguration aktiv. Wer sehen möchte wie Postscreen arbeitet, kann sich selbst eine E-Mail senden und das Log /var/log/mail.log studieren.

Webmail mit allem was dazugehört

Wenn es um Webmail geht, ist zuerst die Entscheidung zu fällen wo Webmail gehosted werden soll und welche Anwendung man dafür verwenden möchte. Für große Umgebungen ist man gut beraten Webmail auf einem separaten Server zu installieren. Für die eingene kleine Umgebung kann man Webmail jedoch auch mit auf dem E-Mailserver installieren, wenn der eigene Server über genügend RAM und CPU Leistung verfügt.

Die im Folgenden beschriebene Webmail-Konfiguration setzt sich im wesentlichen aus diesen Anwendungen zusammen:

Jede der genannten Anwendungen ist so umfangreich, dass man ihnen einen eigenen Artikel oder gar eine eigene Artikelreihe widmen kann. Dieser Artikel beschränkt sich daher darauf, eine möglichst sichere Webmail-Konfiguration zu erstellen.

Wo möglich verwende ich die Version einer Anwendung, welche über die Paketquellen zur Vergfügung gestellt wird. Da PHP-FPM nicht in den Paketquellen für Ubuntu 14.04.1 enthalten ist, greife ich hierbei auf ein PPA zurück.

Als erstes werden Nginx und MySQL aus den Paketquellen installiert.

sudo apt-get install nginx-full mysql-server

Zusammen mit den Paketen werden alle benötigten Abhängigkeiten installiert. Nach einigen Minuten wird man aufgefordert ein Passwort für den MySQL-Benutzer „root“ zu vergeben. Für diesen Benutzer sollte ein möglichst langes und komplexes Passwort vergeben werden.

PHP-FPM ist in Trusty noch nicht in den Paketquellen enthalten. Daher wird zuerst ein PPA zur Paketverwaltung hinzugefügt.

add-apt-repository ppa:ondrej/php5
apt-get update
apt-get install php5-fpm php5-mysqlnd php-pear php5-mcrypt php5-intl

Fall man beim Hinzufügen des PPA die folgende Fehlermeldung erhält, fehlt noch ein Paket, welches wie folgt nachinstalliert werden kann. Anschließend kann das PPA wie oben beschrieben hinzugefügt werden.

:~$ sudo add-apt-repository ppa:ondrej/php5
sudo: add-apt-repository: command not found
:~$ sudo apt-get install software-properties-common
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
  gir1.2-glib-2.0 libcurl3-gnutls libdbus-glib-1-2 libgirepository-1.0-1
  librtmp0 python3-dbus python3-gi python3-pycurl python3-software-properties
Vorgeschlagene Pakete:
  python-dbus-doc python3-dbus-dbg libcurl4-gnutls-dev python3-pycurl-dbg
Die folgenden NEUEN Pakete werden installiert:
  gir1.2-glib-2.0 libcurl3-gnutls libdbus-glib-1-2 libgirepository-1.0-1
  librtmp0 python3-dbus python3-gi python3-pycurl python3-software-properties
  software-properties-common
0 aktualisiert, 10 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 818 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 3.451 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] J

Im Anschluss an die Installation wird der PHP Interpreter konfiguriert. Dazu gehört, dass PHP-FPM statt über TCP Sockets über UNIX Sockets kommuniziert. Dazu wird in der Datei /etc/php5/fpm/pool.d/www.conf folgende Zeile einkommentiert, bzw. hinzugefügt, falls sie fehlt.

listen = /var/run/php5-fpm.sock

Anschließend werden die Zugriffsrechte für den Socket korrekt gesetzt.

listen.owner = www-data
listen.group = www-data

Hier kann noch eine Menge mehr konfiguriert werden. Zum Beispiel kann PHP-FPM zur Nutzung von memcached konfiguriert werden, welches die Auslieferung von PHP-Anwendungen beschleunigt. Dies würde jedoch den Umfang dieser Artikelreihe sprengen. Steht genügend RAM zur Verfügung, sei auf die Dokumentation zu PHP-FPM verwiesen, um memcached einzurichten.

Wie nach allen Änderungen an Konfigurationsdateien, ist auch hier der betroffene Dienst neu zu starten.

service php5-fpm restart

Nun geht es wieder um Nginx. Als erstes wird die Hauptkonfigurationsdatei /etc/nginx/nginx.conf bearbeitet. Sie sollte anschließend wie folgt aussehen:

user www-data;
worker_processes 2;
pid /run/nginx.pid;

events {
	worker_connections 1024;
	multi_accept on;
}

http {
	sendfile on;
	tcp_nopush on;
	tcp_nodelay on;
	keepalive_timeout 10 10;
	types_hash_max_size 2048;
	server_tokens off;
	port_in_redirect off;
	client_max_body_size 4096k;
	client_body_timeout 10;
	client_header_timeout 10;
	send_timeout 10;

	include /etc/nginx/mime.types;
	default_type application/octet-stream;

	access_log /var/log/nginx/access.log;
	error_log /var/log/nginx/error.log;

	# Gzip Settings
	gzip on;
	gzip_disable "msie6";
	gzip_min_length 1100;
	gzip_vary on;
	gzip_proxied any;
	gzip_buffers 16 8k;
	gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/rss+xml text/javascript image/svg+xml application/x-font-ttf font/opentype application/ vnd.ms-fontobject;

	# Sitewide SSL settings
	ssl_session_cache shared:SSL:10m;
	ssl_buffer_size 4k;

	# Sitewide proxy settings
	set_real_ip_from 127.0.0.1;
	real_ip_header X-Forwarded-For;

	# Virtual Host Configs
	include /etc/nginx/conf.d/*.conf;
	include /etc/nginx/sites-enabled/*;
}

Der Wert von worker_processes ist auf die Anzahl der physikalisch vorhandenen CPU Cores zu setzen.

Als nächstes wird die Datei /etc/nginx/conf.d/php5-fpm.conf mit folgendem Inhalt erstellt.

upstream php5-fpm-sock {
	server unix:/var/run/php5-fpm.sock;
}

Damit wird eine Variable namens „php5-fpm-sock“ erstellt, welche auf den Unix Socket verweist.

Nun wird die Datei /etc/nginx/sites-available/roundcube erstellt und mit folgendem Inhalt befüllt.

server {
	server_name www.domainname.tld;
        listen 80;
	return 301 https://mail.domainname.tld$request_uri;
}

server {
	server_name mail.domainname.tld;
        listen 80;
	return 301 https://$host$request_uri;
}

# HTTPS server
server {
	listen 443 ssl spdy default_server;
	server_name mail.domainname.tld;
	root /usr/share/nginx/roundcube;
	index index.html index.php;
	autoindex off;

	ssl on;
	ssl_certificate /etc/ssl/private/ssl-chain-mail-domainname.pem;
	ssl_certificate_key /etc/ssl/private/domainname-private-ssl.key;
	ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
	ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS;
	ssl_prefer_server_ciphers on;
	ssl_ecdh_curve secp521r1;

	# Client auth via certs
#	ssl_client_certificate /etc/ssl/private/yourdomain.crt;
#	ssl_trusted_certificate /etc/ssl/private/yourdomain.crt;
#	ssl_verify_client on;

	location / {
#		if ($ssl_client_s_dn !~* "you@yourdomain.com") {
#			return 301 http://www.jurassicsystems.com/;
#		}
#		error_page 403 @fallback;
	}

	location ~ ^/(README|INSTALL|LICENSE|CHANGELOG|UPGRADING)$ {
		deny all;
	}

	location ~ ^/(bin|SQL)/ {
		deny all;
	}

	location ~ ^/.*\.php {
		try_files $uri =404;
		include fastcgi_params;
		fastcgi_pass php5-fpm-sock;
		fastcgi_param HTTPS on;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		fastcgi_intercept_errors on;
	}

	location @fallback {
		return 301 http://www.domainname.tld/;
	}
}

Ist die Datei erstellt wird ein symbolischer Link im Verzeichnis /etc/nginx/sites-enabled erstellt und der Link auf die Standardseite gelöscht.

ln -s /etc/nginx/sites-available/roundcube /etc/nginx/sites-enabled/roundcube
rm /etc/nginx/sites-enabled/default

Anschließend benötigt Nginx einen Neustart.

Sind Webserver und Interpreter funktionsfähig, wird es Zeit sich um die MySQL Datenbank zu kümmern.

Erstellung der Datenbank

Zum Glück gibt es hier nicht viel zu tun. Der MySQL Server ist in der Standardkonfiguration bereits recht sicher konfiguriert. Mit dem hier beschriebenen Setup wird der MySQL Server nicht aus dem Internet erreichbar sein und diesen Umstand sollte man nicht ändern.

Als Erstes startet man das SQL Interfaces und verbindet sich mit dem root-Benutzer.

mysql -u root -p

Mit den folgenden Kommandos wird nun eine Datenbank für roundcube angelegt und ein Benutzer mit Zugriffsrechten auf diese Datenbank erstellt.

create database roundcubedb;
grant all on roundcubedb.* to 'roundcubedb'@'localhost' identified by 'enter-a-password-here';
exit

Fertig. Webserver, PHP Interpreter und Datenbankserver inkl. Benutzer sind einsatzbereit. Jetzt fehlt nur noch die eigentliche Webmail Anwendung.

Installation von Roundcube

Die Webmail Anwendung wird direkt von der Roundcube Download Seite heruntergeladen. Auf dem Server können wir den Download direkt auf der Kommandozeile starten.

http://downloads.sourceforge.net/project/roundcubemail/roundcubemail/1.0.4/roundcubemail-1.0.4.tar.gz
tar -xzvf roundcubemail-1.0.4.tar.gz

Anschließend wird das entpackte Verzeichnis an die korrekte Stelle im Dateisystem manövriert und die Zugriffsrechte korrekt gesetzt.

rm -rf /usr/share/nginx/roundcube
mv /usr/share/nginx/roundcubemail-1.0.4 /usr/share/nginx/roundcube
chown -R www-data:www-data /usr/share/nginx/roundcube

Nun wird die URL https://mail.domainname.tld/installer im Webbrowser aufgerufen und der Webinstaller gestartet.

roundcube-webmail-installer

Start des Roundcube Webmail Installationsprogramms

Auf der Startseite des Installationsprogramms wird geprüft, ob alle Voraussetzungen für die Installation erfüllt sind. Hier sollte alles OK sein, außer bei den nicht installierten DBMSs und der Datums- und Zeitkonfiguration ganz am Ende der Seite.

Auf der zweiten Seite sind die Optionsfelder mit den individuellen Werten der eigenen Installation auszufüllen. Das Feld product_name sollte auf einen Wert gesetzt werden, der beschreibt, um wessen Webmailer es sich hierbei handelt. Die Checkbox ip_check sollte aktiviert werden, um Roundcube’s Session-Sicherheit zu steigern. Des Weiteren sollte der Wert des Felds identities_level auf „many identities with possibility to edit all params but not email address“ gesetzt werden. Damit sind Benutzer in der Lage alle Optionen in Roundcube anzupassen, ohne die eigene E-Mail Adresse ändern zu können. Damit ist es ihnen möglich ihr eigenes Passwort zu ändern.

Anschließend werden die Angaben zur eigenen Datenbank gemacht. Das Feld db_prefix kann leer gelassen werden.

Abschließend wird mit einem Klick auf Create Config die Konfigurationsdatei /usr/share/nginx/roundcube/config.inc.php erstellt. Die folgende Seite kann mit einem Klick auf Continue bestätigt werden.

Roundcube_Config_created

Die Roundcube Konfiguration wurde erstellt.

Auf der letzten Seite des Installers wird mit einem Klick die Datenbank initialisiert. Darüber hinaus können hier noch weitere Tests ausgeführt werden. Verlaufen alle Tests erfolgreich, so ist es geschafft. Bevor man den eigenen Roundcube Webmailer nutzt, sollte man noch das Verzeichnis des Webinstallers entfernen.

rm -rf /usr/share/nginx/roundcube/installer

Herzlich willkommen im eigenen Webmail-Interface.

roundcube-webmail-interface

Roundcube Webmail Interface

Damit sind wir am Ende der vierteiligen Artikelreihe angelangt. Nach einem langen Weg ist der eigene E-Mail Server fertig. Er kann E-Mails empfangen und versenden. Und dies von Desktop Mailclients, Smartphones, Tablets oder via Webmail. Der Server ist sicher konfiguriert und es wurde alles getan, damit die eigenen Mails nicht von fremden Spamfiltern herausgefischt werden.

Persönliches Fazit

Zuerst möchte ich Lee Hutchinson danken, dessen hervorragende, englischsprachige Artikelreihe3 mich dazu angeregt hat, mich selbst an einem E-Mail Server Projekt zu versuchen.

Am Ende dieser Artikelreihe habe ich viel über E-Mail im allgemeinen sowie MTAs, MDAs und MUAs im speziellen erfahren. Darüber hinaus konnte ich mich mit etlichen Techniken beschäftigen, die helfen, einen Server zu härten und vor den Gefahren des Internets zu schützen. Allein das war es wert, den ganzen Konfigurationsaufwand auf sich zu nehmen. Und hey, ich habe jetzt meinen eigenen Mailserver. 🙂

Ich kann mir vorstellen, zukünftig auf dem bisher erreichten aufzubauen. So ist es denkbar eine zertifikatbasierte Webmail-Anmeldung zu implementieren oder einen Kalenderserver zu integrieren. Mehr dazu in folgenden Artikeln.

Ein paar Worte noch zum Schluss. Haltet euer System stets Up-to-Date!

Ihr könnt euch die Arbeit ein klein wenig erleichtern, in dem ihr die Installation von Sicherheitsupdates auf dem Server automatisiert.

Ihr seid für die Sicherheit eures Servers verantwortlich. Pflegt ihn und haltet ihn aktuell. Nichts ist schlimmer als veraltete Systeme, die im Internet vor sich hin gammeln.

Automatische Installation von Sicherheitsupdates

Wie bei jedem Betriebssystem sollten auch bei Ubuntu regelmäßig Updates installiert werden. Dabei handelt es sich um Fehlerkorrekturen, welche die Stabilität des Systems verbessern und insbesondere potenzielle oder erwiesene Sicherheitslücken schließen.1

Die Installation von Sicherheitsupdates ist eine Aufgabe, die man hervorragend automatisieren kann, um administrativen Aufwand zu sparen. Dazu installiert man unter Ubuntu das folgende Paket:

sudo apt-get install unattended-upgrades

Um die automatischen Updates zu aktivieren, wird die Datei /etc/apt/apt.conf.d/10periodic angelegt bzw. bearbeitet. Diese sollte mindestens die folgenden Einträge enthalten:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::Unattended-Upgrade "1";

In der Datei /etc/apt/apt.conf.d/50unattended-upgrades wird festgelegt, welche Art von Updates automatisch installiert werden sollen. Möchte man ausschließlich Sicherheitsupdates automatisch installieren lassen, so ist dies mit der folgenden Konfiguration möglich:

// Automatically upgrade packages from these (origin:archive) pairs
Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
//      "${distro_id}:${distro_codename}-updates";
//      "${distro_id}:${distro_codename}-proposed";
//      "${distro_id}:${distro_codename}-backports";
};

Damit ist schon alles Nötige getan. Unter /var/log/unattended-upgrades findet man noch ein Log, um überprüfen zu können, welche Änderungen am System durch die automatische Updateinstallation durchgeführt wurden.

Synology RAID Volume mit größeren Festplatten erweitern

Diese Anleitung beschreibt, wie man die Speicherkapazität des RAID Volume einer Synology Diskstation durch Einsatz größerer Festplatten erweitern kann. Sie basiert auf der englischsprachigen Anleitung aus dem Synology Wiki.1

In meinem Beispiel wird die Kapazität eines Synology Hybrid RAID2 erweitert. Die Anleitung funktioniert jedoch analog auch für:

  • RAID-1
  • RAID-5
  • RAID-5+Hot-Spare
  • RAID-6
  • Synology Hybrid RAID

Die Anleitung wurde mit der Firmware DSM 5.0-4493 Update 1 erstellt.

Vorsicht!
Bevor irgendwelche Arbeiten an der RAID-Konfiguration durchgeführt werden, sollte eine Datensicherung der Dateien durchgeführt werden, die aktuell auf der Diskstation gespeichert sind. So kann einem Datenverlust in Folge eines Fehlers vorgebeugt werden.

Beginn der Arbeiten

systemstatus

Systemzustand der DS213air

Zuerst werfen wir noch einen kleinen Blick in den Systemstatus, um zu prüfen, dass unsere Diskstation und unser RAID Volume in Ordnung sind. Ist alles in Ordnung, können wir wie im Folgenden beschrieben, die erste Festplatte gegen ein größeres Laufwerk ersetzen.

Ich selbst besitze eine DS213air. Da bei diesem Modell die Festplatten nicht im laufenden Betrieb gewechselt werden können, muss die Diskstation zuerst heruntergefahren werden.

Schritt 1
Nachdem die Diskstation vom Strom getrennt wurde, öffnet ihr das Gehäuse. Nun könnt ihr eine der Festplatten gegen eine größere Festplatte austauschen. Mit welcher Festplatte ihr dabei beginnt, ist egal. Dies bleibt euch überlassen.

Schritt 2

ds213air_open2

Offenes Gehäuse der DS213air

Die Diskstation wird wieder an den Strom angeschlossen und eingeschaltet. Ich habe das Gehäuse für diesen Schritt offen gelassen, da ich später ja auch noch die zweite Festplatte ersetzten möchte.

Nach dem Hochfahren ertönt ein Signalton. Dieser weist darauf hin, dass das RAID Volume beschädigt ist.

 

 

Schritt 3
Wir melden uns an der Diskstation an und deaktivieren in der geöffneten Systemsteuerung zuerst den Signalton.

Schritt 4
Wechselt in den Speicher-Manager. Hier wird euch das fehlerhafte Volume angezeigt. Mit einem Klick auf „Verwalten“ startet ihr den Volume Manager Assistent. Klickt euch durch den Assistenten und startet damit die Reparatur eures Volumes.

Die Reparatur kann je nach Größe eures Volumes mehrere Stunden dauern. Mit dem nächsten Schritt darf erst fortgefahren werden, wenn die Reparatur erfolgreich beendet wurde.

Schritt 5
Zeigt der Speicher-Manager für euer Volume wieder den Status Normal, könnt ihr die Schritte 1-4 für die zweite Festplatte wiederholen.

Ende der Erweiterung
Nach der erneuten Reparatur des Volumes wird der Speicherplatz des Synology Hybrid RAID automatisch erweitert und steht euch zur Nutzung zur Verfügung. Ein Blick in den Speicher-Manager bestätigt das Ergebnis.

storagemanager

Überblick Speicher-Manager

Fazit: So einfach ist es, den Speicherplatz für eure Fotos, Videos und die Musiksammlung zu erweitern. Ich hoffe, dass diese Anleitung euch bei der Vergrößerung eurer Volumes unterstützt. Habt ihr Verbesserungsvorschläge, Kommentare oder konstruktive Kritik, so benutzt bitte die Kommentarfunktion zum Beitrag. Ich werde dann versuchen, eure Anmerkungen in den Beitrag einzuarbeiten.