Daniel

Xenserver 7: NFS ISO-Store von Synology NAS einrichten

von

XENSERVER auf einem dedicated Rootserver

Ich möchte hier kurz beschreiben, wie man ein NFS-Share von einer Synology NAS, die in einem lokalen Netzwerk steht, einem XENSERVER (dedicated Rootserver), zur Verfügung stellt.

Die ISO-Dateien werden von einem beliebigen PC im lokalen Netzwerk auf das Share abgelegt und stehen dem Xenserver, nach Einbindung des ISO-Repositories zur Verfügung.

Ports (Virtual Server)

Da die Synology-NAS in meinem internen Netzwerk steht und ich aus dem Internet heraus (vom dedicated Rootserver) auf die NFS-Freigabe zugreifen will, muss eine entsprechende Portweiterleitung erfolgen.

Auf meinem TP-Link Router nennt sich dies „Virtual Server“.

Die Weiterleitungen sind folgende:

NFS-Server (Synology NAS)

Als NFS-Server fungiert meine Synology NAS mit DSM 6.0.1-7393 Update 2.

Damit NFS überhaupt funktioniert, muss in der Systemsteuerung der Synology unter Dateidienste NFS aktiviert werden. Optimalerweise setzt man auch gleich das Häkchen bei „NFSv4-Unterstützung“ aktivieren.

Nachdem das  NFS-Service nun „scharf geschaltet“ ist, muss noch eine Freigabe erstellt werden. Zu diesem Zweck, wechselt man in der Synology Systemsteuerung zu den Gemeinsamen Ordnern.

Über den Button „Erstellen“ erfolgt die Konfiguration der Freigabe.

Im Folgefenster können Berechtigungen für lokale Benutzer gesetzt werden. Da man mit einem PC (z.B. SMB-Share) auf die Freigabe zugreift, um ISO-Files abzulegen, muss hier ein User mit entsprechenden Berechtigungen gewählt / oder zuvor angelegt und die Berechtigungen entsprechend gesetzt werden.

Wichtig ist jedoch vor allem der Reiter „NFS-Berechtigungen“, denn dort wird definiert, welche IP-Adressen auf den NFS-Server (die Freigabe) zugreifen dürfen.

In das Feld Hostname oder IP wird die Adresse des NFS-Client eingetragen. (Somit darf nur von dieser IP aus auf NFS zugegriffen werden!) Der NFS-Client ist in diesem Fall der XenServer. Die Privilegien müssen auf Lesen/Schreiben gesetzt sein.

Somit ergeben sich folgende Einstellungen.

Ganz unten im Fenster sieht man den Mountpfad, welcher in dieser Konfiguration: /volume1/NFS_ISO lautet. Der Pfad wird später für die Einbindung der Freigabe auf dem Xenserver verwendet.

Somit sind alle Vorarbeiten auf dem NAS abgeschlossen.

ISO Repository auf dem Xenserver einbinden

Für die Verwaltung des Servers, verwende ich OpenXenManager.

Die Serververbindung ist bereits aufgebaut. Nach einem Rechtsklick auf den Server, welcher auf der linken Seite des OpenXenManager aufgeführt wird, wählt man „New Storage Repository“.

Im Folgefenster wird „ISO Library – NFS ISO“ gewählt. (Aufgrund meiner hohen Auflösung und dem angepassten Skalierung sind die Screenshots leider unschön.)

Im Feld „Share Name“ ist die öffentliche IP des NFS-Servers gefolgt vom lokalen Mountpfad des NFS-Share (in diesem Falle /volume1/NFS_ISO) einzutragen.

Genaugenommen also z.B.: 123.456.789.001:/volume1/NFS_ISO

Wobei es sich bei oben angeführter IP nur um eine fiktive Adresse handelt, die durch die korrekte öffentliche IP – über die die Synology NAS anzusprechen ist- zu ersetzen ist.

Das Ergebnis der Übung – ein NFS ISO Store ist eingebunden.

Download und ablegen des ISO Files

Auf dem lokalen PC kann man sich aufgrund dessen, dass auch eine normale SMB Freigabe erstellt wurde, mit dem Share verbinden und legt dort beispielsweise den Debian Netinstaller (ISO) ab.

Eine VM installieren

Nach Ablage des ISO Files im NFS-Share, muss am Xenserver ein Rescan des ISO-Repositories erfolgen.

Danach kann eine neue VM angelegt werden und die zu installierende ISO-Datei vom NFS-Share aus gewählt werden.

Nach dem Start der VM, präsentiert sich der Debian Installer. Die Daten kommen hierbei dann von der ISO Datei, die per NFS-Share eingebunden wurde.

 

 

 

 

Xenserver 7 auf einem dedicated Rootserver

von

Meine bisherigen Virtualisierungserfahrungen habe ich einerseits auf Microsofts Hyper-V und andererseits auf VMWARE ESXI gemacht. Den Xenserver hatte ich bislang komplett aussen vor gelassen.

Grund genug also, den Xenserver zu testen. Für den Test habe ich einen dedicated Rootserver mit 32GB Ram, 1TB Festplattenspeicher und einem I7 Prozessor verwendet.  Verbaut ist ausserdem eine Realtek-NIC (r8169).

Installation

Für die Installation bestelle ich einen kostenpflichtigen Remotemanagement Zugang (KVM Spider). Die ISO Datei des Xenserver lade ich auf meinen lokalen PC. Die Remotekonsole basiert auf Java, weshalb am PC die aktuelle Version des Java Runtime Environment installiert sein muss.

Da die Sicherheitsmechanismes des JRE mittlerweile sehr strikt sind, muss für die IP, oder auch für die Adresse, die für das Remotemanagment verwendet wird, eine Ausnahme erstellt werden.

Java Konfigurieren – Reiter Sicherheit – Ausnahmeliste – Siteliste bearbeiten…

Nun sollte sich die Remotekonsole öffnen lassen.

KVM Spider Probleme mit dem Keyboard

Nachdem das ISO File im Remotemanagement gemountet war, hoffte ich nun auf eine problemlose Installation. Wäre da nicht das Problem mit dem Keyboard gewesen. Ich kannte das schon von einem anderen Hoster. Das Keyboard funktioniert anfangs, nach dem Restart dann jedoch u.U. nicht, oder vielleicht doch… So kann ich jedenfalls nicht vom eingebundenen ISO booten. Ich komme nicht in das Bootmenü des Bios.

Nach mehreren erfolglosen Versuchen, die Sachlage mit dem Support zu klären und endlich ein funktionierendes Remotemanagement zur Verfügung gestellt zu bekommen, begebe ich mich selbst auf Ursachenforschung- Schließlich übermittle ich dem Support einige Settings, die man wohl im Bios (USB Einstellungen) vornehmen muss, damit KVM funktioniert.

Endlich, das Setup läuft

Das ISO-File ist eingebunden und das Setup läuft. Da es so geradlinig und selbsterklärend ist, verzichte ich auf Screenshots. Sämtliche Hardware wird out-of-the-box erkannt. Einzig die zu verwendende Festplatte, der Servername, die Netzwerkeinstellungen und das Rootpasswort sind zu konfigurieren bzw. auszuwählen.

Management per XenCenter

Um den Server managen zu können, benötigt man XenCenter, welches – wie der XenServer – kostenlos zur Verfügung steht. Nach der Installation muss der XenServer (Host) noch in XenCenter hinzugefügt werden.

Wenn man will, kann ein Masterpasswort für das XenCenter gesetzt werden. Dies ist allerdings nur dann sinnvoll, wenn man mehrere Hosts betreibt, da die Passwörter aller Hosts im Center gespeichert werden können und die Entsperrung aller Server aufeinmal dann mit dem Masterpasswort geschieht.

Im Funktionsumfang nicht beschnitten

Obwohl es sich bei Xenserver um die kostenlose Version (ohne Support) handelt, ist sie im Funktionsumfang in keinster Weise beschnitten. VMs können migriert, kopiert, verschoben, exportiert, importiert, konvertiert usw. werden.

Festplattenmanager / Storage Repository

Was mir fehlt, ist das Verwalten von lokal am Server installierten Festplatten. Will man eine weitere Festplatte als Storage-Repository einbinden, kann dies nur per Konsole erfolgen.

Verwaltung per Web-Gui  „Xen Orchestra“

Wenn man den Xenserver gerne per Webgui administrieren will, kann man auf Xen Orchestra zurückgreifen. Eine gute Installationsanleitung findet sich auf der Website von tecmind.com.

Fazit

Meiner Ansicht nach stellt Xenserver eine ernstzunehmende Alternative zu den anderen Virtualisierungsplattformen dar. Einzig bei einigen Verwaltungsfunktionen hätte ich gerne eine etwas komfortablere Bedienung per GUI. Soweit von mir bislang korrekt interpretiert, gibt es eine eher geringere Anzahl von Drittanbieter „Backup-/Restoresoftware“.

Ansonsten ist Xenserver ein tolles Produkt!

 

 

E-Book: Rootserver unter Debian GNU Linux

von

Aufgrund einiger Projekte, die ich im Team mit einem guten Freund durchgezogen habe und da mir das Schreiben nach wie vor sehr viel Spaß macht, habe ich mich vor einigen Monaten dazu entschlossen, ein weiteres E-Book zu erstellen. Diesmal weg von nur einem Cloudservice (a la Owncloud) hin zur Mutter aller Server.

Ich habe mich bemüht, möglichst viele Aspekte zu beleuchten. Das Buch soll bei der Installation, Konfiguration und Absicherung unterstützen und vielleicht so manche Anregung liefern.

Von 03.02.2017 bis 04.02.2017 gibt es eine kostenlose Werbeaktion.

 

 

 

Modsecurity im Produktiveinsatz – wp-cron.php

von

Ich bin im Moment gerade dabei, ein wenig mit modsecurity zu kämpfen. Kämpfen, ja das kommt ungefähr hin.

Solange man sich mit seinen FalsePositives in der Phase2 bewegt, kann man problemlos per LocationMatch Ausnahmen erstellen. Wenn jedoch bereits in Phase 1 Falscherkennungen stattfinden, greift LocationMatch nicht mehr.

Beispielsweise hätten wir hier so einen Fall:

 ModSecurity: Access denied with code 403 (phase 1). Operator EQ matched 0 at REQUEST_HEADERS. [file „/usr/share/modsecurity-crs/base_rules/modsecurity_crs_20_protocol_violations.conf“] [line „312“] [id „960012“] [rev „1“] [msg „POST request missing Content-Length Header.“] [data „0“] [severity „WARNING“] [ver „OWASP_CRS/2.2.9“] [maturity „9“] [accuracy „9“] [tag „OWASP_CRS/PROTOCOL_VIOLATION/INVALID_HREQ“] [tag „CAPEC-272“] [hostname „www.example.com“] [uri „/wp-cron.php“] [unique_id „WGUSaFmj4VQAAALcXyYAAAAI“]

Laut Logfile, wird hier in Phase 1 mit einem 403 zurückgeschossen. Bei dem aufgerufenen uri, handelt es sich jedoch um wp-cron.php, welches vom Webserver selbst (WordPress) gestartet wird.

Da wir uns in besagter Phase 1 befinden, kann man nicht per LocationMatch arbeiten.

Ich bin momentan noch auf der Suche nach einer Lösung…