UNIXwork

• The Origins of Malloc
• X and NeWS history: X was a distributed database system in which operations on some of the databases have visual side-effects.
• The Cost Of Open Sourcing Your Project

Dieser Artikel ist eine kurze Anleitung für die Einrichtung des LDAP-Clients unter Solaris. Der Artikel gilt sowohl für das aktuelle Solaris 11 als auch Solaris 10.

Netzwerk-Konfiguration (nur Solaris 11)

Solaris 11 hat für die Netzwerkkonfiguration zwei Profile (NCP): DefaultFixed und Automatic. Der LDAP-Client funktioniert jedoch nicht mit dem Automatic-NCP, daher muss zwingend DefaultFixed verwendet werden. Zumindestens wenn Solaris über die Live-CD installiert wurde ist standardmäßig das Automatic-NPC aktiv. Dies muss dann geändert werden.

netadm enable -p ncp defaultfixed

Danach muss noch das Netzwerk manuell konfiguriert werden. Wer einfach DHCP verwenden will kann dies folgendermaßen tun:

ipadm create-ip net0
ipadm create-addr -T dhcp net0/v4

DNS geht dann übrigens noch nicht, das beheben wir aber später.

LDAP-Client konfigurieren

Dieser Schritt ist identisch unter Solaris 10 und 11. Der folgende Befehl konfiguriert den LDAP-Client.

ldapclient manual -a credentialLevel=proxy -a authenticationMethod=simple \
	-a defaultSearchBase=dc=example,dc=com -a domainName=example.com \
	-a defaultServerList=<ip> -a proxyDN=<admin-cn> -a proxyPassword=<admin-pw> \
	-a serviceSearchDescriptor=group:ou=Groups,dc=example,dc=com

Standardmäßig werden Benutzer in ou=People,dc=example,dc=com gesucht (für den Basis-DN dc=example,dc=com). Wo genau nach Gruppen gesucht wird weiß ich gar nicht, weshalb ich auch mit -a serviceSearchDescriptor=group:ou=Groups,dc=example,dc=com den passenden DN angebe. Wer dies für User ändern will kann dies mit -a serviceSearchDescriptor=passwd und -a serviceSearchDescriptor=shadow tun.

Name-Service konfigurieren

Nachdem der LDAP-Client konfiguriert ist, ist der Name Service Switch für die meisten eher suboptimal konfiguriert, denn Hostnamen werden per LDAP gesucht und nicht mehr mittels DNS. Unter Solaris 11 ändert man dies nur mit ein paar Befehlen:

svccfg -s "name-service/switch" setprop 'config/host = astring: "files dns"'
svcadm refresh name-service/switch
svcadm restart name-service/switch

Unter Solaris 10 muss die Datei /etc/nsswitch.conf angepasst werden. Dafür ändert man nur folgende zwei Zeilen:

hosts: files dns
ipnodes: files dns

PAM konfigurieren

Die User existieren zwar schon, einloggen kann man sich jedoch nicht. Unter Solaris 11 ersetzt man dafür in den Dateien /etc/pam.d/login und /etc/pam.d/other die Zeile auth required pam_unix_auth.so.1 mit folgenden zwei Zeilen:

auth binding          pam_unix_auth.so.1 server_policy
auth required         pam_ldap.so.1

Unter Solaris 10 muss nur die Datei /etc/pam.conf geändert werden. Die Zeile

login   auth required       pam_unix_auth.so.1

ersetzt man durch

login   auth binding        pam_unix_auth.so.1 server_policy
login   auth required       pam_ldap.so.1

und die Zeile

other   auth required       pam_unix_auth.so.1

mit

other   auth binding        pam_unix_auth.so.1 server_policy
other   auth required       pam_ldap.so.1

Danach kann man sich gewohnt mit su oder in Gnome mit LDAP-Benutzern einloggen.

Dateien auf der Kommandozeile kann man recht einfach mit openssl verschlüsseln.

openssl aes-256-cbc -in file.txt -out file.enc

Entschlüsseln geht mit:

openssl aes-256-cbc -d -in file.enc -out file.txt

Der Key wird dabei aus einem Passwort generiert, welches von openssl abgefragt wird.

Möchte man von dav verschlüsselte Dateien von Hand mit openssl entschlüsseln, wird es ein wenig komplizierter. Die Keys die von dav verwendet werden, werden binär in Dateien gespeichert. Ein AES256-Key ist dann einfach eine 32 bytes große Datei.

Datei entschlüsseln

Zuerst muss der Key in eine für das openssl-Tool kompatible Form gebracht werden, nämlich ein Hex-String ohne Space.

hexdump -ve '/1 "%02X"' < ~/.dav/keys/mykey > mykey.hex

Dann muss aus der verschlüsselte Datei (hier im Beispiel encfile) noch der Initialisierungsvektor extrahiert werden. Dieser wird von dav nämlich immer an den Anfang der Datei gepackt. Die restlichen Bytes sind dann die eigentlichen verschlüsselten Daten.

dd if=encfile of=iv.bin bs=16 count=1
dd if=encfile of=encdata bs=16 skip=1
hexdump -ve '/1 "%02X"' < iv.bin > iv.hex 

Jetzt haben wir den Key und den IV in passender Form und können die Datei mit openssl entschlüsseln:

openssl aes-256-cbc -d -K `cat mykey.hex` -iv `cat iv.hex` -in encdata -out file

Datei verschlüsseln

Um eine Datei zu verschlüsseln brauchen wir zunächst einen zufälligen Initialisierungsvektor.

dd if=/dev/random of=iv.bin bs=16 count=1
hexdump -ve '/1 "%02X"' < iv.bin > iv.hex

Dann können wir die Datei mit openssl verschlüsseln und anschließend mit cat den IV und die verschlüsselte Datei zusammenfügen:

openssl aes-256-cbc -K `cat mykey.hex` -iv `cat iv.hex` -in file.txt -out encdata
cat iv.bin encdata > file.enc

Vor langer Zeit wurde es gefordert und hier ist es: eine Anleitung inklusive Erklärung wie man mit netcat einen Proxy für eine TCP-Verbindung baut, der bei Bedarf auch den Traffic anzeigt oder speichert.

Zunächst einmal benötigt man einen Server zu dem der Client sich normalerweise direkt verbinden würde. Wer live mittesten will, kann sich mit netcat einen basteln:

nc -l -p 1220

Nun wollen wir aber einen Proxy. Hierfür lauschen wir mit einem weiteren netcat-Prozess auf einem anderen Port. Der Client soll sich dann mit dem Proxy verbinden, und der Proxy soll den Traffic an den Server (Port 1220) senden. Bevor wir zur kompletten Lösung für bidirektionale Traffic-Weiterleitung kommen, hier erstmal der einfache Fall nur für eine Richtung.

nc -l -o 1221 | nc localhost 1220

Mit einer einfachen Pipe wird die Ausgabe des Proxies, also die Daten, die der Client sendet, zu dem Server gesendet. Alles was der Server sendet, wird jedoch vom netcat-Prozess, der den Proxy mit dem Server verbindet (nc localhost 1220), auf stdout ausgegeben. Was also fehlt ist, dass die Ausgabe dieses Prozesses als Eingabe für den Proxy dient. Und dafür benutzen wir eine Named Pipe (FIFO).

Eine normale Pipe besteht nur aus zwei Filedeskriptoren und kann daher nur an Kindprozesse weitergegeben werden. Eine FIFO hingegen wird im Dateisystem abgebildet und jeder Prozess kann auf diese zugreifen. Erstellen können wir eine FIFO mit dem Befehl mkfifo.

mkfifo fifo

Dann erweitern wir den Befehl für den Proxy noch so, dass der Proxy-Prozess seine Eingabe aus der FIFO bezieht und der zweite netcat-Prozess seine Ausgabe in die FIFO schreibt.

nc -l -o 1221 < fifo | nc localhost 1220 > fifo

Jetzt wird der ganze Traffic in beide Richtungen weitergereicht, wir wollen ihn jedoch noch im Terminal anzeigen lassen oder loggen. Hierfür verwenden wir das Tool tee, welches seine Eingabe auf stdout ausgibt und sie zusätzlich noch in eine Datei schreibt. Damit können wir jetzt z.B. den Traffic in zwei separaten Dateien loggen:

nc -l -p 1221 < fifo | tee client.log | nc localhost 1220 | tee server.log > fifo

Den Traffic im Terminal anzeigen kann man, in dem man /dev/tty zur Hilfe nimmt. Dieses ist ein spezielles Device, was für das Terminal des aktuellen Prozesses steht. Daten, die wir in /dev/tty reinschreiben, werden im Terminal ausgegeben.

nc -l -p 1221 < fifo | tee /dev/tty | nc localhost 1220 | tee fifo

Eine weitere Möglichkeit ist, den Traffic in eine weitere FIFO zu schreiben. Aus dieser kann man in einem anderen Terminal dann mit cat oder einem anderen Programm den Traffic live mitlesen.

mkfifo traffic
nc -l -p 1221 < fifo | tee traffic | nc localhost 1220 | tee traffic > fifo

Beachten muss man dabei jedoch, dass man erst aus der traffic-FIFO liest, bevor Daten übertragen werden, da das Öffnen einer FIFO blockiert, bis das andere Ende geöffnet wird. Solange also die traffic-FIFO nicht geöffnet wird, blockieren die tee-Prozesse, was das ganze Konstrukt aufhält.

Mal wieder Mist in Mercurial committed? Kein Problem. Mit der Strip Extension können Changesets entfernt werden. Praktischerweise ist diese auch standardmäßig bei Mercurial dabei und muss nur noch aktiviert werden. Hierfür muss in der .hgrc-Datei des Repositories folgendes eingefügt werden:

[extensions]
strip =

Danach kann ein Changeset und alle seine Nachfolger mit dem strip Befehl entfernt werden:

hg strip <rev>

Falls Änderungen schon auf einen Server gepusht wurden, kann man dies auch dort erledigen, falls man Shell-Zugriff hat.