Lüftertausch bei Synology NAS DS509+ und Ausschalten des Lüfteralarms

Bei uns im Flur steht eine Synology DS509+, also ein Netzwerkspeicher, auf den alle Geräte im lokalen Netz zugreifen können.

Synology Diskstation DS509+ im Betrieb, darauf steht eine Fritz!Box 7590
Synology DS509+ in Betrieb

Kurz nachdem ich die Laufwerke letztens wieder über NFS mit meinem PC verbunden hatte (und damit eventuell die Systemlast etwas erhöhte), ging an der DiskStation ein Lüfteralarm an mit der Meldung, dass Lüfter 1 stehen geblieben sei. Das war auch tatsächlich das, was ich vorfand, einer der beiden Gehäuselüfter stand, während der andere lief. Kurzerhand bestellte ich also zwei neue, sehr günstige und laut Amazon sehr leise Lüfter mit den passenden Maßen (80x80mm) und tauschte gleich beide alten Lüfter aus. In diesem Zuge habe ich das komplette Gerät von innen entstaubt und gereinigt.

DS509+ Lüfter im Gehäuse von hinten
DS509+ Lüfter im Gehäuse von hinten

Der Austausch an sich ist überhaupt kein Problem, die Lüfter sind Standard-Teile und passen natürlich auf die Löcher, die dreipoligen Stecker passen auf die Pins am Mainboard. Nach dem Austausch startete die DiskStation ganz normal, die Lüfter drehten und waren tatsächlich flüsterleise. Allerdings wurde nach kurzer Zeit wieder der Lüfteralarm ausgelöst. Nach kurzer Recherche stellte ich fest, dass in der Synology DS509+ (wie in vermutlich jeder DiskStation) ein proprietärer Dienst namens scemd die Sensoren überwacht und Alarme und ähnliches auslöst. Dieser Dienst überwacht offenbar auch die Lüfterdrehzahl, die mit den alten OEM-Lüftern nicht mehr übereinstimmte. Der Dienst scemd hat prinzipiell auch eine Konfigurationsdatei (/usr/syno/etc/scemd.xml), jedoch lässt sich hier die Soll-Drehzahl (oder irgendeine andere Drehzahl) nicht ändern. Offenbar ist diese hardcoded irgendwo im Programm hinterlegt. Die einzige Möglichkeit, die ich finden konnte, war, die Lüfterprüfung komplett auszuschalten. Unter /sys/module/ppc85xx_synobios/parameters/ findet sich eine Datei mit dem Namen check_fan und vermutlich dem Inhalt „1“. Ändert man dies zu „0“, prüft scemd nicht mehr, ob die Lüfter die gewünschte Umdrehungszahl haben.

Synology DS509+ zeigt im Dashboard einen Lüfterfehler an
Synology DS509+ Lüfterfehler

Diese Datei wird allerdings bei jedem Systemstart erzeugt und der Wert auf 1 gesetzt. Ändert man sie also, wird der Alarm nach dem nächsten Neustart wiederkommen. Sinnvoller ist ein Script, welches die Datei nach dem Start des Systems wieder auf 0 setzt:

echo "echo 0 > /sys/module/ppc85xx_synobios/parameters/check_fan" > /usr/syno/etc.defaults/rc.d/S99zz_fan_check_
disable.sh

chmod +x /usr/syno/etc.defaults/rc.d/S99zz_fan_check_
disable.sh

Dieses Script wird nun als letztes beim Startup ausgeführt und schreibt eine 0 in die oben genannte Datei.

Nun werden keine Lüfteralarme mehr ausgelöst, man sollte also selbst nachsehen, ob beide Gehäuselüfter ordnungsgemäß funktionieren. Einen CPU-Lüfter besitzt das Gerät nicht, hier muss also auch nichts überwacht werden.

Die Kühlleistung der beiden neuen Lüfter ist übrigens absolut okay bisher, im Idle haben die Festplatten eine Temperatur von 24°C bis 27°C, in Benutzung etwa 30°C bis 33°C.

Synology DS509+ zeigt im Dashboard die Temperatur der Festplatten (etwa 24°C bis 27°C im Idle) an
Synology DS509+ Temperatur der Festplatten

NFS-Probleme bei altem NAS und Ubuntu oder Debian beheben (Synology mit altem DSM)

Vor einiger Zeit kaufte ich mir über eBay günstig eine gebrauchte Synology DiskStation DS509+, also ein NAS (Network Attached Storage) für fünf Festplatten.

Auf meinem PC (Ubuntu) sind die diversen Ordner über NFS (Network File System) in der fstab eingetragen, werden dementsprechend beim Start gleich eingebunden und sind lokal verfügbar. Bis vor einer Weile lief das auch alles super so. Bis zu einem Distributionsupgrade. Seitdem meckert NFS mit folgender Fehlermeldung:

NFS: nfs4_discover_server_trunking unhandled error -22. Exiting with error EIO

Ich vermutete, dass es an der völlig veralteten Version des DiskStationManagers (DSM, das Betriebssystem der DiskStation) handelt, dessen NFS-Version nicht mehr mit modernen Betriebssystemen kompatibel ist. Leider werden die alten Geräte nicht weiter mit Updates versorgt.
Ich habe mich nun bereits länger nicht mehr mit diesem Problem beschäftigt, da ich die DiskStation im Grunde genommen am PC nicht wirklich nutze, heute stolperte ich aber durch Zufall über die Lösung, als ich für die Einrichtung eines anderen Gerätes etwas zu NFS recherchierte: Es gibt eine Mountoption „nfsvers“, mit der die Version des zu nutzenden NFS-Protokolls gewählt werden kann. Gibt man „nfsvers=2“ als Mountoption an, lässt sich der entfernte Ordner wieder mounten.

fstab Einträge für NFS-Laufwerke auf der Diskstation
fstab Einträge für NFS-Laufwerke auf der Diskstation

ownCloud für Android hat Probleme mit Sonderzeichen

Ich betreibe seit langer Zeit ownCloud-Instanzen, um damit Daten zwischen diversen Geräten zu synchronisieren. Installation und Konfiguration sind sehr einfach und es gibt (neben WebDAV) native Clients für alle von mir genutzten Betriebssysteme.

Vor einiger Zeit habe ich ein Passwort geändert. Die Desktop-Clients unter Windows 7 und Debian funktionierten mit dem neuen Passwort anstandslos, ownCloud für Android hingegen nicht. Nach einigem Herumprobieren fand ich heraus, dass es eine hochgestellte 3 war (³), die das Problem verursachte. Ich änderte daraufhin das Passwort erneut (es enthielt weiterhin Sonderzeichen) und es funktionierte auf allen Geräten.

Seitdem ist einiges an Zeit vergangen und letztens erinnerte mich meine Passwort-Routine, das ownCloud-Passwort mal wieder zu ändern. Gesagt, getan und oh Wunder, ein Sonderzeichen funktionierte auf dem Android-Client nicht.

Dieses Mal war meine Neugier größer, ich deaktivierte die Zwangsumleitung auf HTTPS und schnitt den Netzwerkverkehr der App beim Einloggen über eine unverschlüsselte Verbindung mit. Die Login-Daten mit einigen Sonderzeichen sehen in der App so aus:

ownCloud-Login mit Sonderzeichen
ownCloud-Login mit Sonderzeichen

Im Mitschnitt sieht man schnell, wieso das Passwort nicht funktionieren kann (abgesehen davon, dass der Nutzer nicht existiert):

Netzwerk-Mitschnitt vom Login bei ownCloud mit Sonderzeichen
Netzwerk-Mitschnitt vom Login bei ownCloud mit Sonderzeichen

Halten wir also fest: Bestimmte Sonderzeichen werden von der „originalen“ ownCloud-Android-App zu Fragezeichen umgewandelt und so gesendet. Die „Standard-Sonderzeichen“ wie ?$% usw. scheinen zu funktionieren.

Da die App sowieso nicht unbedingt meine Definition einer guten Synchronisations-App erfüllt: Kann mir jemand eine gute WebDAV-App nennen, die unter Android die Verbindung mit ownCloud übernimmt und vielleicht auch mit den spezielleren Sonderzeichen klar kommt?

Outlook.com und Office365 – Update in der Spambehandlung?

Im März 2013 schrieb ich einen Artikel über die Behandlung eingehender Mails an Postfächer bei outlook.com und hotmail. Status damals war: Es gibt offensichtlich geblockte IP-Ranges, von denen Mails angenommen, aber nicht dem Empfänger zugestellt werden. Der Sender weiß so nicht, dass seine Mail nicht ankam, der Empfänger weiß nicht, dass er etwas hätte empfangen können. Eine gefährliche Situation also.

Im SSF wurde nun ein Erfahrungsbericht über Hosted Exchange bei OVH geschrieben (Hint: Nicht toll), von wo nach einigen Vorkommnissen ein Wechsel zu Microsoft selbst mit Office365 vollzogen wurde. Das weckte in mir die Erinnerung an die Erfahrungen mit Microsoft-Mailexperten damals, woraufhin ich gemeinsam mit dem Verfasser die heutige Konfiguration prüfte.

Kurz gesagt, das Verhalten von damals konnte ich nicht nachstellen.

Mein produktiver Mailserver wurde damals nach längerem Hin und Her mit dem Support entblockt und kann heute Mails an outlook.com senden, sie landen allerdings reproduzierbar im Spam.
Sende ich eine Mail an das Konto bei Office365, kommt diese ohne Beanstandung mit einem Spam-Level von 1 durch (als Spam werden Nachrichten zwischen 5 und 10 gewertet).

Sende ich eine Mail von einem meiner Server bei OVH stellt sich das Szenario anders, aber okay dar.
outlook.com bricht die Kommunikation nach dem mail from: ab mit folgender Fehlermeldung:
mail from: testmail@helium.fmaihost.de
550 SC-001 (BAY004-MC1F41) Unfortunately, messages from 37.59.60.14 weren't sent. Please contact your Internet service provider since part of their network is on our block list. You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors.
Connection closed by foreign host.

Sende ich vom gleichen Server eine Mail an das Konto bei Office365, kommt die Mail auch hier anstandslos durch.

Es ist zwar beides Outlook, die Spam-Filter unterscheiden sich aber offenbar stark, für die Kostenlosen Postfächer bei outlook.com werden offensichtlich IP-Bereiche gewisser Hoster komplett gesperrt. Ärgerlich für Kunden von OVH.

Ab sofort nur noch HTTPS

Wer das hier liest, tut dies über eine mit einem von Let’s Encrypt ausgestellten Zertifikat verschlüsselte Verbindung.

Komischer Satz, ist aber so, ich habe die Seite komplett auf HTTPS umgestellt, alle internen Links geändert und alle eingebundenen Medien aktualisiert, es sollte nun also alles verschlüsselt sein.

Danke an natenom für den dezenten Hinweis, sich mal wieder mit dem Thema SSL/TLS zu beschäftigen. Tatsächlich ist jetzt, wo Let’s Encrypt produktiv nutzbar ist, der Aufwand kein Grund mehr, Internetseiten nicht verschlüsselt zu übertragen. Schon StartSSL war ja eine deutliche Hilfe, nun muss man aber noch nicht einmal mehr lange warten, bis Zertifikate ausgestellt werden.

Hier habe ich aufgeschrieben, wie man das Hostingpanel ISPConfig so patcht, dass es automatisiert Zertifikate von Let’s Encrypt anfordert.

ISPConfig: Zertifikate von Let’s Encrypt automatisch erstellen

Let’s Encrypt ist eine neue CA (Zertifizierungsstelle), die seit kurzem im Produktivbetrieb kostenlose TLS-Zertifikate vergibt.

Das ganze läuft automatisiert, die CA stellt dafür ein Script zur Verfügung, welches sämtliche Kommunikation mit den Servern von Let’s Encrypt regelt. Das Anfordern und erneuern von Zertifikaten ist also sehr einfach und mit einem Befehl über die Kommandozeile zu erledigen.

Für Hosting-Anbieter (oder Selbsthoster) ist Let’s Encrypt natürlich eine tolle Möglichkeit, die Webseiten schnell und kostenlos mit einem validen Zertifikat zu versehen. Für Anbieter mit dem Control Panel ISPConfig gibt es inzwischen eine externe Lösung, um die Zertifikatanforderung nahtlos in die Weboberfläche zu integrieren. Die externe Erweiterung soll eventuell in den nächsten Versionen von ISPConfig fester Teil der Software werden, bisher ist das aber noch nicht der Fall, das Panel muss also gepatcht werden.

Die Erweiterung von alexalouit ist auf github zu finden und kann unter Debian leicht installiert werden. Vorher muss allerdings das Script von Let’s Encrypt installiert werden, ebenfalls von github:

cd /tmp
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto

Der Installer kann abgebrochen werden, bevor er beim Anfordern von Zertifikaten hilft, das wollen wir schließlich über ISPConfig erledigen.

Nun wird „ISPConfig-letsencrypt“ geklont:

cd /tmp
git clone https://github.com/alexalouit/ISPConfig-letsencrypt.git
cd ISPConfig-letsencrypt

Auch hier gibt es einen automatischen Installer, der die Erweiterung installiert und ISPConfig patcht (Dateien verschieben, Datenbank aktualisieren und Konfiguration anpassen):

root@helium:/tmp/ISPConfig-letsencrypt# php -q install.php
Create backup on /var/backup/ directory
/bin/tar: Entferne führende „/“ von Elementnamen
Backup finished
Copy Let's Encrypt configuration.
Start MySQL update..
Configure Apache and reload it.
Create backup cronjob on /var/backup/ directory
Add a cronjob for renewal certs
And finally, update ISPConfig.
Done my job. Enjoy!

Ist dies erledigt, erscheint in ISPConfig in den Einstellungen einer Website neben dem bisher vorhandenen Kontrollkästchen „SSL“ auch das Kontrollkästchen „Let’s Encrypt“:

ISPConfig: Website-Einstellungen mit Kontrollkästchen für Let's Encrypt
ISPConfig: Website-Einstellungen mit Kontrollkästchen für Let’s Encrypt

Setzt man diesen Haken (der Haken bei SSL setzt sich dann automatisch), wird bei der Aktion „Zertifikat Erstellen“ im Tab „SSL“ nicht mehr ein selbstsigniertes Zertifikat auf dem Server generiert, sondern es wird eines bei Let’s Encrypt angefordert. wird automatisch ein Zertifikat von Let’s Encrypt angefordert und die Seite damit ausgestattet. Im SSL-Tab muss und darf nichts weiter getan werden.

Mehr ist gar nicht notwendig, nach kurzer Zeit ist das Zertifikat im Ordner von Let’s Encrypt hinterlegt und wird in den SSL-Ordner der Seite gelinkt. Auch die Änderungen in den vhosts werden automatisch vorgenommen. Die Seite ist nun über https abrufbar und das Zertifikat wird von den meisten vernünftigen Browsern als vertrauenswürdig angezeigt:

Website mit dem über ISPConfig abgerufenen Let's Encrypt Zertifikat
Website mit dem über ISPConfig abgerufenen Let’s Encrypt Zertifikat

Raspberry Pi als „Cloud“ oder NAS?

Es geisterte ja heute durch das gesamte Internet und somit auch an mir vorbei: Western Digital plant, eine Vielzahl von Netzwerkspeichern auf Basis einer speziellen WD-Festplatte und einem Raspberry Pi auf den Markt zu schmeißen unter dem klangvollen Namen PiDrive. Das ganze ist derzeit in der Entwicklungsphase bei WDLabs (der aktuelle Stand lässt sich wohl aber in Amerika bereits kaufen) und soll mit OwnCloud ausgeliefert werden.

Ich bin ja ein großer Fan des Raspberry Pi und habe privat einen Raspberry Pi B, B+ und seit neuestem auch einen Raspberry Pi 2 B als Mediacenter. Die Dinger machen sich echt gut, sei es als 24/7 Monitor-Device, als Bastelgerät für SPS-Spielereien oder Modbus-Erweiterung derselben für Aufgaben, die ein Linuxrechner einfach besser hin bekommt.

Allerdings fingen schon beim Lesen der Überschriften bei mir die Warnlichter an zu leuchten: Der Netzwerkadapter (10/100 MBit/s) wird vom USB 2.0-Controller bereitgestellt. USB 2.0 hat eine theoretische Bandbreite von bis zu 480MBit/s, davon bleiben vielleicht so 400MBit/s tatsächlich übrig. Insgesamt können also über LAN und USB etwa 50MByte/s übertragen werden.
Der Ethernet-Port hat eine Übertragungsrate von 100MBit/s, was etwa 12MByte/s entspricht.

Das reicht natürlich. Für die Sachen, die man mit nem Raspberry Pi so macht: Webcamstream, Bastelcomputer, Mediacenter usw.
Wenn es aber darum geht, Daten im lokalen Netzwerk vorzuhalten, sind 100MBit/s nicht besonders schön. Erst recht nicht, wenn man beispielsweise das Netzlaufwerk auf einem anderen Rechner einbinden will. Da sind die Kapazitätsgrenzen schnell erreicht, vor allem, wenn eventuell zwei Rechner gleichzeitig Daten haben wollen. Wenn man Sachen aus dem Netz läd, ist sowas zu verschmerzen (da wären 100MBit/s ja fast das obere Ende), aber das will man ja eigentlich nicht auf Geräten haben, die im internen Gigabit-LAN Daten vorhalten sollen.

Klar, das Ding kostet auch nicht viel, da kann man nicht viel verlangen. Ich würde aber sagen, dass es einfach das falsche Gerät ist, um ein NAS oder eine Cloud wie OwnCloud bereitzustellen, auf der mehr als nur ein paar MP3 und Urlaubsfotos gespeichert werden (von der Datensicherheit mal abgesehen). Es gibt inzwischen viele andere Anbieter günstiger Mini-Computer, die dann auf andere Bereiche spezialisiert sind.

via: t3n, Heise

Bild: Owncloud

ISPConfig 3: Adaptec RAID-Status im Monitoring anzeigen

ISPConfig hat eine praktische Funktion im Backend: Es zeigt wichtige Informationen über den Systemstatus an, so unter anderem auch den Status des Software- oder Hardware-RAIDs. Leider wird bisher nur mdraid (Software), mpt-status (LSI), sowie tw_cli (3ware) unterstützt, ich besitze allerdings einen Server mit einem Adaptec-RAID, welches mit dem Tool arcconf überwacht werden kann.

Den Status Quo fand ich also nicht so toll und fand auch keine fertigen Lösungen, die auf eine aktuelle Version (derzeit 3.0.5.4p5) von ISPConfig passen. Also erweiterte ich die Abfrage und stelle sie nun hier zur Verfügung.

Voraussetzung: die Datei arcconf muss auf dem Server im Verzeichnis /sbin vorhanden sein.

ISPConfig ist modular aufgebaut, die Abfrage des Systemstatus wird über die Datei monitor_core_module.inc.php im Ordner /usr/local/ispconfig/server/mods-available realisiert, diese fragt allerdings nur Daten aus den monitor_tools ab, welche sich in der Datei monitor_tools.inc.php im Ordner /usr/local/ispconfig/server/lib/classes befindet.

Hier findet sich auch die Funktion monitorRaid(), welche hier benötigt wird. Hier suchen wir folgende Zeile (am Anfang der Funktion):

/*
* Check, if Software-RAID is enabled
*/

Davor fügen wir nun die Abfrage von arcconf ein:

/*
* Check, if arcconf is present
*/
if (file_exists('/sbin/arcconf')) {
	/*
	* Fetch the output
	*/
	$data['output'] = shell_exec('arcconf GETCONFIG 1 LD');
	$state = 'ok';
	if(is_array($data['output'])) {
		foreach ($data['output'] as $item) {
			/*
			* The output contains information for every RAID and every HDD.
			* We only need the state of the RAID
			*/
			if (strpos($item, 'Logical device name                      : RAID') !== false) {
				/*
				* We found a raid, process the state of it
				*/
				if (strpos($item, 'Optimal') !== false) {
					$this->_setState($state, 'ok');
				} else {
					/* we don't know the state. so we set the state to critical, that the
					* admin is warned, that something is wrong
					*/
					$this->_setState($state, 'critical');
				}
			}					
		}
	}
}

Ich habe versucht, mich an die in der Datei vorhandenen Strukturen zu halten. Der Code prüft, ob die Datei /sbin/arcconf existiert. Wenn ja, führt es die Datei mit den Parametern GETCONFIG 1 LD aus, was uns die Info über den RAID-Controller zurück gibt.

Adaptec RAID: Ausgabe von arcconf wird im ISPConfig-Monitoring angezeigt
Adaptec RAID: Ausgabe von arcconf wird im ISPConfig-Monitoring angezeigt

Nun wird geprüft, ob der Controller ein RAID enthält und dann, ob der Status „Optimal“ ist. Wenn ja, wird $state als „ok“ zurück gegeben, wenn nein, als „critical“. Meine Ausgabe kennt bisher nur diese beiden Stadien, da ich leider bisher die anderen Outputs von arcconf nicht kenne (falls sie mir jemand nennen kann: bitte einen Kommentar hinterlassen). Mir reicht das bisher so, wenn das RAID nicht optimal ist, bekomme ich so eine kritische Warnung.

Fragen und Anregungen nehme ich natürlich immer gerne in den Kommentaren entgegen.

Fritz!Box zurücksetzen ohne Netzwerkzugriff

Ich brauchte heute einen Switch, um mehrere Geräte mit statischen IPs zu verbinden. Da ich keinen solchen frei hatte, nahm ich eine alte Fritz!Box Fon WLAN 7390, die ich mal zu einem VDSL-Vertrag bekam. Leider nutzte ich diese Box zuletzt als Switch ohne DHCP an einer anderen Fritz!Box und aus irgendeinem Grund fand ich keinerlei Möglichkeit mehr, auf die Administrationsoberfläche zuzugreifen.

Ich durchstöberte also die AVM-Hilfeseiten und fand eine Möglichkeit, die Box (die übrigens keinen Hardware-Resettaster mehr hat) ohne Zugriff auf das Netzwerk zurückzusetzen. Das freute mich natürlich, weil ich so nicht weiter nach Möglichkeiten für ein Reset suchen musste, wunderte mich andererseits, weil es eine ziemlich offene Tür in ziemlich viele Fritz!Boxen sein dürfte.

Zuerst: Durch eine saubere Konfiguration lässt sich das ganze schnell aus der Welt schaffen. Aber wer macht denn sowas? Und: Die Möglichkeit besteht nur, wenn die DECT-Funktion der Box aktiviert ist.

Es ist ganz einfach: Die Box kann als Basisstation für DECT-Telefone genutzt werden. Und das wird sie vermutlich auch recht häufig. Wieso ein Kabel zur Basisstation des Telefons legen, wenn man selbiges auch gleich an der Fritz!Box anmelden kann?
Ist diese Funktion aktiv, kann man sich irgendein DECT-Telefon nehmen und die Basis suchen. Hat das Telefon die Box gefunden, fragt es nach der PIN. Diese Pin ist in der Fritz!Box standardmäßig auf 0000 eingestellt. Man kann sie ändern. Man wird dazu allerdings nicht aufgefordert und wörtlich steht dort zur PIN:

Damit Sie mit Ihren Schnurlostelefonen über die FRITZ!Box telefonieren können, müssen diese an der FRITZ!Box angemeldet sein. Für die Anmeldung benötigen Sie eine PIN. Diese legen Sie hier fest und geben sie während der Anmeldung im Telefon ein.
Vorbelegt ist die PIN 0000. Sie können diese PIN beibehalten oder eine andere PIN eingeben.

Wenn Sie ein FRITZ!Fon mithilfe der „automatischen Anmeldung“ anmelden möchten, darf die vorbelegte PIN nicht verändert werden.

Soweit so gut. Ich würde vermuten, dass die PIN an fast allen Geräten auf 0000 steht. Man tippt also am DECT-Mobilteil die 0000 ein und kann sich mit der Fritz!Box verbinden. Nun kann man verschiedene Dinge tun:

Einerseits ist des angemeldete Telefon nun teil des Systems und man kann Anrufe entgegennehmen und ausgehende tätigen, andererseits kann man über die Tastencodes einige Dinge an der Box verstellen: WLAN ein-/ausschalten, die Box neu starten, den Anrufbeantworter anrufen, auf allen Geräten „Bier holen!“ anzeigen lassen, die Box neustarten oder eben auf Werkseinstellungen zurücksetzen.

Falls man beispielsweise das WLAN-Passwort kennt, die Funktion aber ausgeschaltet ist, kann man sie so einfach einschalten. Kennt man das WLAN-Passwort, welches werksseitig vergeben wurde, nicht aber das geänderte aktuelle, setzt man die Box zurück und kann sich mit dem alten Passwort mit dem Netzwerk verbinden.

ISPConfig 3: Jailkit nachträglich installieren

Mit ISPConfig 3 ist es möglich, den Hosting-Kunden bzw. Benutzern einen Zugriff auf den ihnen zugewiesenen Webspace per SSH zu gewähren, die Benutzer werden mittels Jailkit in ihren Ordner gechrootet.

Da ISPConfig bei der Einrichtung überprüft, welche Dienste verfügbar sind und diese dann konfiguriert, muss Jailkit eigentlich installiert werden, bevor ISPConfig installiert wird. Stellt man nun nachher fest, dass man Jailkit nun doch benötigt, ist das natürlich doof. Es gibt aber einen Weg, Jailkit bei einer bestehenden ISPConfig-Installation nachträglich zu konfigurieren und einzubinden, diesen möchte ich hier zeigen. Das nachfolgende Tutorial wurde mit Version 3.0.5.4p2 durchgeführt, es sollte aber auch mit älteren Versionen so funktionieren. Alles weitere geschieht natürlich auf eigene Gefahr.

Zuerst muss Jailkit natürlich heruntergeladen und installiert werden, wie es z.B. das Perfect Server Tutorial bei Howtoforge zeigt (die Version von Jailkit muss natürlich angepasst werden):

apt-get install build-essential autoconf automake1.9  libtool flex bison
cd /tmp
wget http://olivier.sessink.nl/jailkit/jailkit-2.17.tar.gz
tar xvfz jailkit-2.17.tar.gz
cd jailkit-2.17
./configure
make
make install

Nun muss ISPConfig erneut heruntergeladen und entpackt werden:

cd /tmp
wget http://www.ispconfig.org/downloads/ISPConfig-3-stable.tar.gz
tar xvfz ISPConfig-3-stable.tar.gz
cd ispconfig3_install/install

Danach muss die Datei update.php geändert werden. Hierzu suchen wir die folgende Zeile in der Datei:

if($reconfigure_services_answer == 'yes') {

die darauf folgenden Zeilen löschen wir bis zu den Zeilen

//** Configure Jailkit
swriteln('Configuring Jailkit');
$inst->configure_jailkit();

Diese lassen wir stehen und löschen darunter wieder alle weiteren Zeilen bis zur schließenden Klammer. Der Abschnitt sieht nun so aus:

//** Shall the services be reconfigured during update
$reconfigure_services_answer = $inst->simple_query('Reconfigure Services?', array('yes', 'no'), 'yes','reconfigure_services');

if($reconfigure_services_answer == 'yes') {

                //** Configure Jailkit
                swriteln('Configuring Jailkit');
                $inst->configure_jailkit();

}

//** Configure ISPConfig

Die Datei wird gespeichert. Nun müssen wir das Update starten, indem wir folgenden Befehl eingeben:

php -q update.php

Der automatische Updater startet und fragt uns einige Fragen, die wir wie folgt beantworten:

Shall the script create a ISPConfig backup in /var/backup/ now? (yes,no) [yes]: yes
Reconfigure Permissions in master database? (yes,no) [no]: no
Reconfigure Services? (yes,no) [yes]: yes

Nun werden die Services rekonfiguriert. Da wir eben in der update.php sämtliche Services außer Jailkit gelöscht haben, wird nur Jailkit konfiguriert, der Rest bleibt unangetastet. Als nächstes kommt die Ausgabe „Updating ISPConfig“. Das wollen wir ja nicht, deshalb brechen wir das Script an dieser Stelle mit Strg + C ab.

Das wars eigentlich. Nun sollten noch die Dateien in /tmp gelöscht werden und Jailkit sollte verfügbar sein und funktionieren.