Manche Proxies kennen Möglichkeiten, um dieses Problem zu umgehen. SNIProxy lässt sich in einem transparenten Modus betreiben, in dem die Quell-Adresse der Verbindungen beibehalten wird.

SNIProxy im transparenten Modus

SNIProxy in den transparenten Modus zu versetzen ist auf den ersten Blick ganz einfach: Über die Konfigurationsdirektive source client im passenden Listener teilt man dem SNIProxy mit, er möchte doch bitte als Quell-Adresse für die Verbindungen gegen innen die ursprüngliche IP des Clients verwenden, z.B. so:

listen 192.168.1.15 80 {
   proto http
   source client
....

Als Beispiel verwenden wir 192.168.1.15 als IP für den Proxy. Es gibt dabei allerdings die eine oder andere Hürde zu umschiffen:

• Der transparente Modus funktioniert nur bei Listenern, die nur eine IP-Version verwenden. Es ist also notwendig, separate Listener für IPv4- und IPv6-Verbindungen einzurichten. In obigem Beispiel geben wir explizit die Adresse an, auf die der Listener hören soll, d.h. wir legen uns in diesem Beispiel auf IPv4 fest.
• Die Antwort-Pakete der Webserver, auf die SNIProxy weiterverbindet, müssen durch den Proxy-Rechner geroutet werden. Im einfachsten Fall wird dieser als Router aufgesetzt und die Webserver erhalten ihn als Default-Gateway.
• Auf dem Proxy-Rechner selbst muss per IPTables dafür gesorgt werden, dass die Pakete auch tatsächlich durch den transparenten Proxy laufen.
   

iptables und Policy Route auf dem Proxy-Rechner

Damit der Transparentmodus richtig funktioniert, müssen Pakete passend geleitet werden. Dies geschieht durch eine separate Routing-Tabelle, auf die Pakete per Markierung durch iptables geleitet werden:

iptables -t mangle -N DIVERT
iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
iptables -t mangle -A DIVERT -j MARK --set-mark 1
iptables -t mangle -A DIVERT -j ACCEPT

ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100

Auf dem Proxy-Rechner muss ausserdem Forwarding eingeschaltet sein, z.B. durch folgende Einträge in /etc/sysctl.conf:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

Webtraffic auf den Webservern durch den Proxy umleiten

Im einfachsten Fall wird ganz einfach die Default-Route der Webserver auf den Proxy gelegt. Das ist nicht immer praktikabel. Eine Variante davon ist, lediglich die Antworten des Webservers über den Proxy umzuleiten. Auch dies gelingt mit einer Policy-Route und einer iptables-Markierung, etwa so:

iptables -t mangle -A OUTPUT -p tcp --sport 443 -j MARK --set-mark 0x8
iptables -t mangle -A OUTPUT -p tcp --sport 80 -j MARK --set-mark 0x8

ip rule add fwmark 8 lookup 101
ip route add 192.168.1.15 dev eth0 table 101
ip route add default via 192.168.1.15 table 101

Auch hier gegen wir als Beispiel wieder vom auf der Adresse 192.168.1.15 laufenden Proxy aus und leiten alle ausgehenden Pakete mit Quellport 80 oder 443 auf diesen um.

Versuchen Sie einmal, ob es funktioniert, wenn Sie

• die Shift-Taste gedrückt halten
• mittels 

  :set mouse=r

  die Mausunterstützung ziemlich einschränken

Wenn im vim die Mausunterstützung eingeschaltet ist und das Terminal dies unterstützt, dann wird eine Selektion per Maus vom vim abgefangen. Typischerweise verwendet vim das *-Register (System-Clipboard), so dass eigentlich alles wie gewohnt funktioniert. In manchen Konstellationen funktioniert allerdings die Mausunterstützung im Terminal, aber nicht das System-Clipboard. Dann bleiben Selektionen nur innerhalb der gleichen vim-Instanz verfügbar, aber es ist nicht möglich, z.B. zwischen verschiedenen Fenstern zu Copy&Pasten.

Die Lösung besteht darin, die Mausunterstützung auszuschalten (dann wird auch wieder die Copy&Paste-Funktion des Systems aktiv) oder per Druck auf die Shift-Taste nur für gerade diese Selektion per System zu machen.

Für diese Probleme gibt es verschiedene Ursachen und verschiedene Lösungen.

Eine, die uns immer wieder auch bei den härteren Fällen hilft, ist der

WSUS Offline Updater

Seine Funktion klingt auf den ersten Blick überflüssig: Das Tool lädt Updates von den offiziellen Microsoft-Update-Quellen herunter und installiert sie dann in einem zweiten Schritt. Das hat allerdings zwei Vorteile gegenüber dem in Windows eingebauten Windows-Update:

1. Sind die Updates einmal heruntergeladen, dann kann man sie gleich auf mehreren PCs installieren, ohne sie nochmals herunterzuladen
2. Stottert das normale Windows-Update, dann schafft es der WSUS Offline Updater meistens, die Updates doch noch zu installieren

Die Nutzung ist denkbar einfach:

• Laden Sie das Tool von der Webseite des WSUS Offline Updater herunter und packen Sie in aus
• Starten Sie das UpdateGenerator.exe, wählen Sie aus, für welche Betriebssystemversionen und (allenfalls) Office-Versionen Sie Updates bereitstellen möchten
• Mehrfachnennungen sind möglich
• Klicken Sie Start
• Nach einiger Zeit sind die Updates bereit zur Installation
• Starten Sie nun im client-Verzeichnis den UpdateInstaller
• Der Bequemlichkeit halber können Sie allenfalls die Option zum automatischen Reboot anwählen
• Starten Sie den Updater per Klick auf Start

Falls Sie mehrere Windows-Installationen aufdatieren möchten, können Sie nachdem der UpdateGenerator seine Arbeit getan hat, das komplette Verzeichnis auf mehreren PCs nutzen, ohne die Updates immer wieder herunterzuladen.

Nach Fertigstellung des Updates sollten Sie nicht vergessen, Windows Update noch einmal durchzuführen – der Offline Updater erwischt nicht immer alle Updates.

Nach einigem Suchen konnten wir feststellen, dass Linux beim Zugriff auf die per Adaptec RAID 8405 eingebundenen Disk-Volumes hing. Offenbar wurde vor einiger Zeit eine Änderung im aacraid-Treiber vorgenommen, der genau die von uns beobachteten Hänger verursacht. Betroffen sind dabei unseres Wissens mindestens Debian, RedHat/CentOS, SuSE – vermutlich aber alle Distributionen.

Als Workaround hat in unserem Fall geholfen, den aacraid-Treiber mit der Option

aac_sync_mode=1"

zu verwenden. Da der Treiber bereits relativ früh im Bootprozedere benötigt wird verwenden wir die entsprechende Option bereits direkt auf der Kernel-Kommandozeile als

aacraid.aac_sync_mode=1

Unter Debian erreichen wir dies, indem wir den folgenden Eintrag in /etc/default/grub vornehmen:

GRUB_CMDLINE_LINUX="aacraid.aac_sync_mode=1" 

Nicht vergessen: Nach Modifikation der Datei muss »update-grub» ausgeführt werden.

Wie Sie Argumente zur Kernel-Kommandozeile hinzufügen ist distributionsabhängig – konsultieren Sie die jeweilige Dokumentation.

Wir stellen eine solche auf unserer Download-Seite zur Verfügung. Die Funktionsweise ist betont simpel

• es handelt sich um ein einfaches Shell-Skript
• das Sie aus Cron regelmässig (1x pro Minute ist zu empfehlen) starten
• es holt aus /var/log/syslog (Sie können es an Ihr System anpassen, indem Sie /var/log/syslog z.B. durch /var/log/messages ersetzen) Logeinträge erfolgreicher POP3/IMAP-Logins
• unter /var/spool/pop-before-smtp merkt es sich die gefundenen IP-Adressen und den Zeitpunkt, wann diese zuletzt im Log aufgetaucht sind
• aus dieser Information generiert es Einträge in /etc/mail/access und löscht sie (nach 50 Minuten) auch wieder

Die meisten Sendmail-Standardinstallationen verwenden sowieso /etc/mail/access, d.h. das Skript funktioniert sofort ohne Änderung an der Sendmail-Konfiguration. Sollte dies doch nicht der Fall sein, so lässt sich die access-Datei so in sendmail.mc konfigurieren:

FEATURE(`access_db', , `skip')dnl

Falls die Access-Datei in Ihrem Fall nicht unter /etc/mail liegt, passen Sie den Pfad im Skript an.

Trotzdem erwarten Sie bitte keine Wunder. Es handelt sich um eine schreiend einfache Quick&Dirty-Lösung, die uns auch schon aus der Patsche geholfen hat. Sie hat auch Nachteile:

• Unterstützung für Dovecot und Courier ist implementiert. Verwenden Sie einen POP/IMAP-Server, mit dem das Skript nicht zusammenarbeitet, dann müssen die grep- und sed-Anweisungen passend angepasst werden.
• Zur Zeit unterstützt das Skript IPv6-Adressen nicht
• Der Aufruf per Cron sorgt dafür, dass maximal die Zeit zwischen zwei Aufrufen vergehen kann, bis SMTP nach einer erfolgreichen Anmeldung freigeschaltet wird
• Da das Skript direkt /etc/mail/access bearbeitet, muss man bei manuellen Änderungen darauf Rücksicht nehmen, dass die Datei während des Bearbeitens auch mal aufdatiert werden kann.
• Weder das Abarbeiten des Logs per tail noch das Aufnehmen von Adressen in /etc/mail/access ist besonders elegant oder effizient und nur für kleine Mailserver geeignet. Verwalten Sie auf Ihrem Mailserver tausende von Mailboxen, dann nehmen Sie sich bitte die Zeit, eine effizientere Implementation zu verwenden oder noch besser POP-Before-SMTP auszumerzen.
• IPv6-Unterstützung fehlt noch.

• auf webbasierte Gerätekonfigurationen zuzugreifen
• Probleme der Anwender vor Ort mit dem Internetzugang nachvollziehen zu können

Tatsächlich genügt ein Shell-Zugang per SSH, um notfalls wie im entfernten Netz zu surfen. Dazu gehen wir wie folgt vor:

• einen SSH-Tunnel auf einen Rechner vor Ort aufbauen
  • per Kommandozeile (OpenSSH unter Linux oder auf dem Mac): Verwenden Sie zum Einloggen zusätzlich die Option -D 2001
  • per Putty: Navigieren Sie in der Oberfläche zu SSH / Tunnels, tragen unter Source Port 2001 ein, selektieren die Option Dynamic und fügen mit Add dieses Portforwarding hinzu. Loggen Sie sich nun wie gewohnt per Putty ein.
• Starten Sie einen Browser. In den Einstellungen (unter Windows: Internet Optionen) konfigurieren Sie einen manuellen Proxy: Geben Sie als SOCKS Host "localhost" an und als Port "2001"
• Wenn Sie nun einen URL öffnen, wird die Anforderung durch den SSH-Tunnel auf den entfernten Rechner übertragen und von diesem ausgeführt
• Beachten Sie, dass auf diese Weise die Namensauflösung immer noch lokal bei Ihnen stattfindet – Sie werden also Geräte vor Ort eher mit IP-Adresse als mit Namen ansprechen (Sie können mit der Proxy-DNS-Einstellung experimentieren, wenn Ihr Browser Sie anbietet)

Vergessen Sie nicht, nach getaner Arbeit die Proxy-Einstellung wieder zu entfernen.

Die bevorzugte Methode, um verteilten Storage in Proxmox-Clustern zu verwenden, ist aktuell CEPH. CEPH ist ein grossartiger Ansatz, jedoch auch nicht ganz einfach in Betrieb zu nehmen und für einen kleinen Cluster eigentlich überdimensioniert.

DRBD hingegen ist recht schnell in Betrieb genommen, und fügt sich problemlos in eine Serverinstallation mit LVM ein.

Der Storage-Treiber basierend auf DRBD-Manager wird zwar mit Proxmox noch mitgeliefert, aber ist nicht mehr wirklich unterstützt, seit es um DRBD-Manager einiges Hin- und Her um dessen Lizenzierung gab.

Die im Moment im Proxmox-Wiki empfohlene Variante, zwei DRBD-Volumes zu verwenden, ist unflexibel, funktioniert eigentlich nur mit zwei Knoten, und bietet ein hohes Risiko.

DRBD mit LVM ohne DRBD-Manager

Wir haben uns deshalb entschieden, DRBD mit einem eigenen Storage-Plugin für uns wieder auf eine Weise verfügbar zu machen, wie sie uns gut passt: Mit DRBD-Volumes aufsetzend auf LVM, aber ohne den DRBD-Manager zu verwenden. In diesem Modell wird eine LVM-Volumegroup benötigt (die aber z.B. mit einer lokalen Storage-Volumegroup identisch sein kann). Jede virtuelle Disk erhält zwei LVM-Volumes: Eines für die Metadaten, eines für die Daten. Darauf aufsetzend wird ein DRBD-Volume konfiguriert mit Synchronisation gegen einen Partnerknoten. Die virtuelle Maschine kann also jederzeit auf einem der beiden Partnerknoten laufen. Gibt es mehr als zwei Knoten im Netz, so wird jede VM (und Disk) jeweils auf zwei Knoten lauffähig sein – auf Mehrfachspiegel via DRBD verzichten wir aus Performance- und Komplexitätsgründen.

Bitte beachten Sie: Dieses Storage-Plugin basiert auf bestehenden Storage-Plugins von Proxmox und steht deshalb unter der AGP-Lizenz. Wir verwenden dieses Plugin selbst und stellen es so zur Verfügung, wie es für unsere Zwecke taugt. Wir übernehmen keinerlei Garantie dafür, dass es Ihren Anforderungen entspricht.

Installation und Inbetriebnahme

Bevor Sie DRBD in Betrieb nehmen sollten Sie dafür sorgen, dass auf Ihrem System LVM aufgesetzt ist und mindestens eine Volumegroup existiert. Eine bereits bestehende Volumegroup ist in Ordnung, wenn es Sie nicht stört, dass Sie dann evtl. die DRBD-Volumes dann auch in dieser als Inhalt auftauchen.

Unser DRBD-Storage-Plugin finden Sie unter Downloads als Debian-Paket. Laden Sie es herunter und installieren es auf allen Knoten mit

apt install ./pvedrbd-*.deb

Unter /etc/pve/storage.cfg wird automatisch eine Standardkonfiguration eingerichtet. Für ganz einfache Fälle sollte dies bereits genügen, aber es lohnt sich vielleicht, an dieser Stelle kurz ein bisschen nachzudenken, wie der Cluster aussehen soll. In der Konfigurationsdatei:

voldrbd: drbdstor
    vgname sys
    shared
    #peers 
    #peerips

Lässt sich mit der Option vgname die zu verwendende Volume Group konfigurieren. Standardmässig wird einfach die erste gefundene verwendet. Die auskommentierten Optionen peers und peerips sollten eine Liste der Knoten, auf denen DRBD Volumes anlegen soll sowie deren IP-Adressen eingetragen werden. Wir hier nichts angegeben, so werden alle Proxmox-Knoten im Cluster mit der IP verwendet, auf die deren Namen auflöst.

In allen nicht trivialen Clustern ist es anzuraten, auf jedem Rechner ein separates Interface für die DRBD-Synchronisation zu verwenden. Dessen IP-Adresse wird unter peerips eingetragen. Für einen einfachen Zwei-Knoten-Cluster mit den Knoten pve1 und pve2 und den IP-Adressen im Synchronisationsnetz 192.168.33.1 und 192.168.33.2 tragen Sie also in storage.cfg folgendes ein:

  peers pve1 pve2
  peerips 192.168.33.1 192.168.33.2

Nach einem Nuestart des pvedaemon sollte nun das Storage drbdstore auftauchen und verwendet werden können.

Verwendung mit nur einem Knoten

Beim Aufsetzen eines Clusters kann es notwendig sein, die VMs schon mal aufzusetzen, obwohl noch kein zweiter Knoten vorhanden ist. Verwenden Sie dann als zweiten Knoten (peers) den Namen none und seine künftige IP-Adresse unter peerips. So lassen sich die DRBD-Volumes noch ohne Synchronisationspartner aufsetzen.

Zur Zeit ist ein späteres Aufsetzen der Synchronisation noch mit Handarbeit verbunden. Dazu in einem späteren Artikel mehr.

Verwendung mit mehr als zwei Knoten

Die aufgesetzten DRBD-Volumes werden – falls mehr als ein Knoten vorhanden ist – immer paarweise synchronisiert. Mehrfachspiegel werden in dieser einfachen Konfiguration nicht unterstützt. Sie können steuern, auf welchen Knoten Spiegel eingerichtet werden: Wenn Sie eine virtuelle Disk auf einem Knoten einrichten, dann wird der Synchronisationspartner auf dem nächsten Knoten in der peer-Liste eingerichtet.

Ein späterer Umzug des Synchronisationspartners ist zur Zeit noch Handarbeit. Dazu in einem späteren Artikel mehr.

Live-Migration

In der Standardkonfiguration von DRBD nach der Installation ist kein Dual-Primary-Modus konfiguriert und folgerichtig muss eine VM zur Migration zuerst heruntergefahren werden, bevor die VM auf dem Partnerknoten hochgefahren werden kann.

Möchten Sie zwingend Live-Migration nutzen, dann müssen Sie in DRBD den Dual-Primary-Modus konfigurieren.

Dies bietet jedoch auch Risiken!

Eine dieser ganz simplen und oft benötigten Aufgaben ist das Einrichten einer Gruppe, deren Mitglieder das Recht erhalten, Rechner in die Domäne aufzunehmen. Tatsächlich ist diese Aufgabe mit samba-tool zu bewältigen, auch wenn die Lösung alles andere als naheliegend ist.

Wir verwenden dazu das folgende Skript:

#!/bin/sh

user=Administrator
stty -echo
read -p "Password for $user: " pw
echo ""
stty echo
read -p "Group: " group

objectsid=`ldbsearch -H ldap://localhost  \
-U "Administrator%$pw" "(&(objectclass=group)(cn=$group))" \
objectSid | \
sed -e ':a;$!{N;ba};s/\n //g' -e 's/.*objectSid: //' -e 's/\n.*//' -n -e '/^S-1/p'`
if [ "$objectsid" = "" ]; then
    echo Group $group not found
    exit 1
fi
echo "Group SID: $objectsid"

dn=`ldbsearch -H ldap://localhost  \
-U "Administrator%$pw" "(&(objectclass=container)(cn=computers))" \
dn | \
sed -e ':a;$!{N;ba};s/\n //g' -e 's/.*dn: //' -e 's/\n.*//' -n -e '/=/p'`
if [ "$dn" = "" ]; then
    echo "Computers container not found"
    exit 1
fi
echo "Computers DN: $dn"

samba-tool dsacl set --action=allow --objectdn="$dn" \
--sddl="(OA;CI;CCDC;BF967A86-0DE6-11D0-A285-00AA003049E2;;$objectsid)"\
"(OA;CIIO;SWWP;F3A64788-5306-11D1-A9C5-0000F80367C1;BF967A86-0DE6-11D0"\
"-A285-00AA003049E2;$objectsid)(OA;CIIO;SWRPWP;72E39547-7B18-11D1-ADEF"\
"-00C04FD8D5CD;BF967A86-0DE6-11D0-A285-00AA003049E2;$objectsid)(OA;CIIO;"\
"RPWP;4C164200-20C0-11D0-A768-00AA006E0529;BF967A86-0DE6-11D0-A285-"\
"00AA003049E2;$objectsid)(OA;CIIO;CR;00299570-246D-11D0-A768-00AA006E0529;"\
"BF967A86-0DE6-11D0-A285-00AA003049E2;$objectsid)"

Um das Skript zu nutzen muss bereits eine Gruppe existieren. Deren Name wird vom Skript ebenso abgefragt wie das Passwort des Administrators. Per ldbsearch wird dann die SID der Gruppe und die DN des Computers-Container eruiert. Mittels samba-tool werden für die gefundene Gruppe die nötigen Berechtigungen erteilt.

Referenz: Delegating domain join privileges in Samba 4 from the command line (or not) sowie Active Directory Permissions : Security Descriptors