In der Standardkonfiguration funktioniert das nicht, da der http-Prozess auf das spool-Verzeichnis keinen Zugriff hat. Abschalten lässt sich das mit folgendem Befehl:
setsebool -P httpd_can_sendmail 1
Kategorien
Schlagwort: linux
Das Ganze klingt zwar nach bösem Voodoo, funktioniert aber tatsächlich: Kernel SamePage Merging. Möglich ist das seit Kernel 2.6.32 und funktioniert, vereinfacht dargestellt, so, dass der Kernel versucht, identische Speicherinhalte zu identifizieren und diese quasi intern zu verlinken.
In der Praxis setze ich das auf einem von mir verwalteten Cluster mit 14 Knoten ein, der mit der auf Virtualisierung und Clustering spezialisierten Linux-Distribution Proxmox läuft. Proxmox vereint KVM und containerbasierte Virtualisierung unter einem Dach, indem auf der einen Seite ein angepasster Linux-Kernel für die paravirt-ops-Schnittstelle eingesetzt und auf der anderen Seite OpenVZ für die containerbasierte Virtualisierung verwendet wird. Der letzte Artikel hier handelt von diesem Thema. Proxmox wird direkt auf jedem der Knoten installiert und danach über eine recht komfortable und moderne Weboberfläche administriert.
Zurück zum Thema, KSM. Ich habe einen entsprechenden Kernel auf einem der Knoten installiert und betreibe auf diesem drei KVM-Maschinen mit Windows Server 2008 R2. Alle drei Maschinen haben 4 GB RAM zugewiesen bekommen, sollten also 12 GB RAM benötigen. Jetzt kommt der Knackpunkt: jeder dieser Knoten verfügt nur über 8 GB physikalischen Speicher. Rein rechnerisch klappt das also nicht, der Knoten müsste anfangen zu swappen. In der grafischen Übersicht des Knotens zeigt Proxmox eine RAM-Auslastung von theoretischen 10 GB an, tatsächlich werden aber nur ungefähr 3,75 GB verwendet, über die Hälfte des verbauten RAMs ist also noch frei. Da die Basis aller drei Installation identisch ist, kann der nun theoretisch drei Mal belegte Speicher zu einem Bereich zusammengefasst und somit zu 2/3 eingespart werden.
Das Verfahren hat natürlich nicht nur Vorteile: die aufwändigere Speicherverwaltung kostet CPU-Zeit. Wenn aber zu erwarten ist, dass die installierten VMs hauptsächlich viel RAM aber wenig Rechenleistung benötigen, spielt das eine eher untergeordnete Rolle. In meinem Falle kommt pro Knoten ein Intel Core2Quad Q9550 zum Einsatz. CPU-Leistung ist also ausreichend da.
RedHat hat es geschafft, auf einer Testmaschine mit 16 GB RAM 52 (!) VMs mit Windows XP parallel zu betreiben, jeder Maschine war 1 GB virtuelles RAM zugeordnet worden. Noch mal in Zahlen: theoretisch belegt worden wären 52 GB, praktisch genutzt aber nur 16 GB.
Kategorien
Port-Weiterleitung mittels SSH
Ich hatte soeben das Problem, dass ich gern auf einen Dienst zugegriffen hätte, der auf einer entfernten Maschine auf Port 443 läuft. Außerhalb des eigenen Netzes, also für IP-Adressen, die nicht im gleichen Netzssegment liegen, wurde der Zugriff auf Port 443 aber gesperrt. Über eine SSH-Verbindung am Terminal mit Lynx zu arbeiten fiel auch aus, da der Webservice massiven Einsatz von JavaScript macht und ohne dieses quasi nicht benutzbar ist.
Also musste eine Möglichkeit her, trotz der Einschränkung auf diesen Service zuzugreifen. Eine lokale Portweiterleitung mittels SSH erbrachte den gewünschten Effekt. Hierfür wird eine Art Datenumleitung eingerichtet, mit deren Hilfe man die Anfrage- und Antwortpakete an den jeweils zuständigen Port umleitet.
https://gist.github.com/481534
Der Befehl ssh sollte bekannt sein. Die Option -L bindet einen lokalen Port an einen Remote-Port, wie auch im Beispiel zu sehen ist. Über [email protected] meldet man sich dann mit gültigen Zugangsdaten an der Maschine an, auf der der Service läuft.
Konkret habe ich in meinem Falle den lokalen Port durch 14500 ersetzt, den Remote-Port durch 443. SSH baut die Verbindung und damit auch den Tunnel auf, et voilà, schon kann man über den Browser mittels
http(s)://localhost:14500
auf den Webservice zugreifen. Die Einschränkung im Zielnetz, dass Port 443 nach außen nicht erreichbar sein darf ist somit umgangen.