Archiv der Kategorie: paedML

LDAPs via HAProxy

Situation: LDAPs Verbindungen sollen via pfSense und dem dortigen HAProxy an den LD-Server ge-proxied werden, um mehr Kontrolle über die zulässigen LDAP-Hosts zu haben als mit plain LD-Server.

Problem: Obwohl die LDAPs Verbindung vom Client via pfSense und HAProxy zum lokalen LDAP-Server klappt, geht keine Antwort vom LDAP-Server nach Außen.

Lösung: TLS1.3 verbieten – mit TLS1.2 funktioniert es. Das Feld im Frontend nennt sich „Advanced ssl options“ und braucht den folgenden Eintrag:

no-tlsv13

Dann ist es im übrigen auch auf der pfSense einstellbar, dass es Wurst sein soll, dass das LDAP-Zertifikat auf dem LD-Server self signed ist. Hauptsache das Zertifikat in Richtung Internet ist sauber (z.B. Let’sEncrypt-Certificate mit ACME Plugin für pfSense), damit sich z.B. ein Moodle verbinden kann.

Tools zum Debuggen: tcpdump, Apache directory Studio

Q2A mit LDAP gegen LD Server

Question 2 Answer ist eine nette PHP-MySQL-Alternative to askbot und bringt hier auch ein LDAP Auth-Plugin mit. Will man dieses nutzen, um gegen einen LD-Server zu authentifizieren, dann kann man die folgenden Einstellungen wählen, damit „es tut“:

Selbstverständlich wäre hier für den Produktivbetrieb in unsicherer Umgebung LDAPs und Port 636 zu wählen.

Ich bin zuerst nicht auf die Idee gekommen, hier AD auszuwählen und versucht zuerst mit OpenLDAP zum Ziel zu gelangen. Das wollte nicht klappen, so dass ich in einem Anfall von „mal gucken“ plötzlich wie oben gezeigt Erfolg hatte.

LM 6.1

Auf linuxmuster.net liegt seit ein paar Tagen die Beta der nächsten Version als VM für alle möglichen VM Hostsysteme. Ich hab das hier mal unter VirtualBox auf meinem Laptop für eine Konfiguration ausprobiert, die nur green und red als Interfaces nutzt.

Die heruntergeladenen Archive lokal mit tar xvfJ archiv.tar.xz entpacken und dann in VBox über das Menü /Datei /Appliance importieren in VBox … naja, eben: importieren. Dann erfolgen einige Anpassungen.

Da ich auf meinem, doch etwas älteren, Laptop als VMHost nur 4GB RAM habe, gab ich der Firewall die voreingestellten 256MB, dem Server 1GB und dem Client unter Lubuntu 512MB. Da musste mein Laptop zwar schwer schnaufen – und auch der virtualisierte Server – aber es läuft, wenn man Lubuntu 12.04 von der Alternate CD installiert .

Firewall

Die MAC Adresse der Netzwerkkarte, die später die rote Schnittstelle werden soll, habe ich hinten mit einer 0 versehen und lasse diese NATen.

Die Schnittstelle, die später mal grün sein soll, versah ich am Ende der MAC mit einer 1 und stellte diese auf „Internes Netzwerk“.

Blau will ich hier auf dem Laptop zum Testen nicht nutzen, also hab ich das „Kabel“ schlicht entfernt und die Schnittstelle nicht angeschlossen.

Beim Hochfahren des IPCop wählte ich nicht den voreingestellten PAE Kernel. Die Firewall kommt mit 256 MB RAM. Da erschien mir das nicht sinnvoll zu sein.

IPFire motzt dann beim Hochfahren, dass es seine Schnittstellen nicht finden kann, was an dieser Stelle nicht weiter stört.

Hat man sich als root und dem Passwort muster einmal eingeloggt, kann man sich durch den Setup-Prozess von IPFire hangeln, den ein setup auslöst.

Die bestehende Zuordnung der Netzwerkkarten muss man zuerst entfernen und dann neu vornehmen. Die vorher vergebenen MAC Adressen helfen bei der Orientierung.

Ein Ping ins Netz zeigt nach Beendigung des Setups, ob alles geklappt hat.

Server

Das Netzwerkinterface des Servers konfiguriert man sich in VBox wie die grüne Schnittstelle des IPFire als „Internes Netzwerk“.

Im Detail ist der Setup-Prozess im Handbuch für Version 6.0 beschrieben.

Nach dem Hochfahren des Servers einloggen (linuxadmin, muster), etwas Zeit verstreichen lassen, bis der Server Kontakt über die VBox interne Schnittstelle zum IPFire erhalten hat und dann mit ping testen, ob die Namensauflösung klappt. Dann mit sudo apt-get update ; sudo apt-get dist-upgrade evtl. vorhandene Updates einspielen und nun – nach einem Wechsel in eine Root-Shell mit sudo su – – das eigentliche Setup beginnen durch Eingabe von

linuxmuster-setup –first

Das kann dauern. LM6.1 zieht nun alle möglichen Pakete aus dem Netz, bis der eigentliche Installationsdialog beginnt (zu diesem siehe den Link zum Handbuch weiter oben).

Subnetting hab ich nicht aktiviert. Ich will vor allem mit Linbo spielen, weil wir schulintern gerade einige Höllenprobleme mit einer zickigen Hardwareklasse (Lenovo T410) haben. Alle anderen Einstellungen habe ich deswegen so übernommen, wie vom Installer als default vorgesehen.

Clients

Die Netzwerkkarten von virtuellen Clients werden wie die grüne Schnittstelle am IPFire bzw. wie die Serverschnittstelle als Internes Netzwerk konfiguriert.

Will man echte Clients testen, dann muss man sich mehr Arbeit machen. In diesem Fall legt man sich auf dem Host-System eine Netzwerkbrücke auf einer unkonfigurierten physischen Schnittstelle ethX an und verpasst dieser eine passende interne IP (siehe Netzwerksetup Homeserver NXT). Statt mit dem Internen Netzwerk von VBox verbindet man dann IPFire und Server mit dieser Bridge.

Ich weiß nicht, ob ich das extra schreiben muss, aber das klappt nur mit Netzwerkschnittstellen am Host in die man ein Kabel stecken kann. WLAN Interfaces sind außen vor. Wer WLAN virtualisiert und keine AccessPoints hierzu nutzen will, kann sich mit USB WLAN Sticks helfen, die man als USB Gerät an die VM durchreicht.

An diese physikalische Schnittstelle des Hosts hängt man einen Switch und an den Switch wiederum den physikalischen Client. Voila.

Sofern die MAC Adressen gleich bleiben, kann man dann zwischen dem physikalischen, ge-bridge-ten Netz und dem VBox internen Netz an den ausgeschalteten VMs hin- und her-schalten wie man will.

linuxmuster.net

Der Verein linuxmuster.net ist nun aus der Taufe gehoben. Auch wenn man nicht mit Code und eigener Arbeitszeit zum Projekt beitragen kann oder will … Fördermitglieder sind ja auch gerne gesehen, erlauben diese doch die Arbeit der Entwickler an dieser freien Lösung für Schulnetze auf Basis von Debian / Ubuntu.

Man stelle sich schlicht vor, 100 Menschen spenden jeweils einen Jahresbeitrag von 50€. Das tut dem Einzelnen nicht arg weh, entspricht dies doch nicht einmal einer Packung Tabak mit Blättchen und Filter – aber mit dem Geld könnte man für das Projekt schon fast eine Stelle für einen Hauptamtlichen finanzieren.

Ein Traum.

Jetzt muss ich an der Schule noch weiter drängeln, damit wir als Institution mit an Bord kommen. Auf den Weg haben wir uns gemacht – Windows ist in eine Virtuelle Maschine gesperrt, damit auch die Redmondfraktion beruhigt werden kann.

paedML auf Virtualbox

Hier hatte ich schon einmal kurz beschrieben, wie man sich eine paedML unter VirtualBox einrichtet. Die aktuelle 5.0.4er paedML brauchte ich neulich (zum Zwecke der Bugsuche auf dem Schulserver) mal wieder und deswegen hier eine Aktualisierung der Hinweise.

Zuerst den IPCop einrichten.

Das erste Interface, das dessen Setup-Prozess findet, wird die grüne Schnittstelle. Deswegen wird die erste Netzwerkkarte in VBox gleich auf inet gesetzt.

Dies gilt selbstverständlich nur, wenn man die Server+IPCop Installation für Testzwecke auf dem heimischen Rechner haben will. Virtualisiert man sich die Installation in der Schule mit Hilfe von VBox (was durchaus so performant ist wie unter Xen oder KVM), dann würde man in diesem Schritt eine der physikalischen NICs des Wirtsrechners im promiscuous Modus wählen – aber hierzu an anderer Stelle mehr.

Die zweite Schnittstelle im IPCop wird später dann das rote Interface und deswegen steht dieses hier und für den geschilderten Zweck (Spielwiese für zu Hause) auf NAT.

Um die beiden Netzwerkkarten im IPCop-Setup leichter unterscheiden zu können, wählt man sich hier einen anderen NIC Typ aus, als für die erste Schnittstelle. Wer sich total vertut, kann aber auch auf dem IPCop selbst die Kartenzuordnungen ändern, ohne ins Setup zu gehen – hier steht wie.

Im Setup des IPCop dann für GREEN den gewünschten Adressbereich auswählen (10.16.1.1 etc.) – für RED wird DHCP ausgewählt, was einem die restliche Konfiguration erspart (DNS usw). Ist der Cop mal an Bord, dann diesen booten und mit ping überprüfen, ob er ins Netz kommt. Erst weitermachen, wenn auch die Namensauflösung klappt.

Dann den 5.0.4er Server aufsetzen, der bei mir nur mit PAE/NX = aktiv booten wollte:

Dessen Netzwerkkonfiguration ist nun die folgende:

Über die VirtualBox Bridge intnet kommunizieren die beiden miteinander – und auch alle Client-Rechner, die man sich testweise und ebenfalls unter VBox dazu installiert.

Virtualbox saved state recovery

Für den Wirtsrechner kam ein neuer Kernel, ein Reboot wurde notwendig. Auf mein Virtualbox Start-Stop-Skript vertrauend startete ich den Wirt neu, ohne vorher die virtuellen Maschinen einzeln anzuhalten oder einzufrieren – was auch bei den meisten reibungslos funktionierte, nicht jedoch bei der virtualisierten paedML. Die warf mir nach dem Reboot die folgende Meldung entgegen:

The VM is missing a block device. Please make sure the source and target VMs have compatible storage configurations

Ein Beitrag im Forum bei Virtualbox lies vermuten, dass die Lösung nah ist. Hier wird empfohlen, in der .vbox Datei den stateFile=“{xxxxxxxxxx-xxxx-xxxx-xxxxxxxx}.sav“ Eintrag zu löschen. Leider half das bei mir nicht.

Dafür half es, den saved state zu verwerfen. In der grafischen Oberfläche ist das lediglich ein Klick auf den Knopf Discard. VBox warnt dann, dass dies dem Ziehen des Netzsteckers gleichkomme … was auch nicht weiter schlimm ist. Im dümmsten Fall bekommt fsck Arbeit.

Es geht aber auch auf der Shell mit

vboxmanage discardstate name_der_vm

wie das Handbuch zu VBox ausführt.

Netzwerkkartenwechsel

Bei der Virtualisierung bestehender Maschinen erhalten diese in ihrer dann virtuellen Umgebung einen anderen Netzwerkkarten Typ und damit auch eine neue Schnittstellen-Bezeichnung. Dies sorgt dann für Probleme, wenn z.B. eth0 auf eine fixe IP Adresse gelegt war, sich nun die virtuelle Maschine mit der „neuen“ Karte aber so fühlt, als hätte diese nur eth1. Diese Schnittstelle ist dann nämlich nicht konfiguriert und die VM kommt nicht ins Netz.

Abhilfe schafft die Bearbeitung der Datei

/etc/udev/rules.d/70-persistent-net.rules

In diese trägt Ubuntu ein, welcher Karte es welche Schnittstellen-Bezeichnung zugewiesen hat und hier kann man dann die nicht benötigten Zuweisungen (an die nicht mehr vorhandenen Karten) löschen und die bestehenden anpassen (also eth1 durch eth0 ersetzen).

Reboot und tut.

Auch praktisch ist dieses Vorgehen auf einem IPCop, der zwei identische NICs verbaut hat. Da darf man im Setup nämlich raten, welche NIC nun welches Netz erhalten hat. Kein Drama, wenn es den IPCop in real gibt. Da steckt man schlicht die Kabel um. Wenn man jedoch einen UnCop aufgesetzt hat und ein Interface an einer Bridge hängt, dann ist das schon fummeliger, weil die Re-konfiguration im Virtualisierer erfolgen muss.

Einfacher geht es durch Anpassung dieser Datei auf dem IPCop selbst:

/var/ipcop/ethernet/settings

Nach einem Reboot klappt es dann wieder mit der Verbindung.

Truecrypt mit Benutzerrechten

Da Lehrer ihren Rechner in einem gemischten Betrieb – privat und dienstlich – einsetzen, müssen diese besondere Vorkehrungen treffen, dass Schülerdaten nicht in fremde Hände gelangen können. Das Programm der Wahl hierzu ist Truecrypt.

Ist man Root an seinem Rechner hat man keine Probleme mit Truecrypt, das für das Einbinden von Tresordateien Adminrechte benötigt. Die treten erst auf, wenn weitere Mitglieder der Familie (oder Kollegen, Schüler etc.) den Rechner ebenfalls nutzen wollen. Diesen nun für das Einbinden von Truecrypt Volumes Adminrechte zu geben ist nicht schlau. Besser ist der folgende Weg:

sudo visudo

startet einen speziellen Editor für die Datei /etc/sudoers. Hier dann am Ende die folgenden Zeilen hinzufügen:

# Truecrypt fuer normale Nutzer

%users ALL=(root) NOPASSWD:/usr/bin/truecrypt

Jetzt haben alle Mitglieder der Benutzergruppe users die Möglichkeit ohne Eingabe eines Passworts Truecrypt auszuführen. Damit keine Missverständnisse auftreten: Für das Öffnen einer Tresordatei braucht man selbstverständlich weiterhin das zu dieser passende Passwort!

Wer noch radikalere Lösungen bevorzugt, könnte dieses Recht auch allen Nutzern unabhängig von der konkreten Benutzergruppe geben:

ALL ALL=(root) NOPASSWD:/usr/bin/truecrypt

Weitere Informationen sowie Installations- und Konfigurationshinweise für Windows sind auf dem LFB zu finden. Weitere Informationen rund um sudo Konfigurationsmöglichkeiten sind bei ubuntuusers im Wiki.

OpenLML in Virtualbox

Um linbo für mein Schulnetz zu testen und ein paar neue Geräte, die mit dem Rembo/MySHN der paedML nicht zurecht kommen mit Images zu versorgen hab ich mir auf meinem Laptop die OpenSource Version der paedML mit integriertem IpCop installiert. Im Vorfeld rätselte ich noch herum, wie wohl das Netzwerksetup aussehen müsse, damit der Server dann nach Außen über WLan ins Netz kommt, während die LAN Buchse meines Laptops dann das 10.16er Netz sei, über die dann PXE Boot möglich wäre. Es geht ganz einfach:

Für die „nach Außen“ zeigende Netzwerkkarte (ROT – aus Sicht des IpCop) wählte ich eine Intel Karte und stellte diese in Virtualbox auf NAT.

Für die „nach Innen“ zeigende Netzwerkkarte (GRÜN – aus Sicht des IpCop) wählte ich zur leichteren Unterscheidung eine PCnet Karte, schloss diese an eine Netzwerkbrücke an und verpasste ihr die Schnittstelle, die auf meinem Laptop das LAN Interface ist – also eth0.

Für Versuche in einem vollständig virtualisierten Netz, in dem auch die Clients auf Virtualbox liefen, stellte ich dann die zweite Netzwerkkarte des Servers wie auch die erste des Clients jeweils um auf Internes Netzwerk.

paedML2twitter

Michael hat mir eine geschickte Exportfunktion für meinen Nagios zukommen lassen. Zu bearbeiten ist

/etc/nagios2/conf.d/linuxmuster_main.cfg

Zusätzlich einzutragen ist:

# ‚external-support‘ contact definition
# do NOT change this!
define contact{
contact_name external-support
alias Fernwartung
service_notification_period 24×7
host_notification_period 24×7
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify-by-email
host_notification_commands host-notify-by-email
email geheim@twittermail.com
}

Ob ich das allerdings über längere Zeit so machen werde, weiß ich noch nicht. twittermail.com ist schnarchlangsam. Ich denke im Moment deswegen eher über Jabber oder identi.ca nach. Mal sehen.

/localhost

127.0.0.1