UNIXwork

Nach vier Jahren Abstinenz jetzt wieder macOS? Was hab ich nur getan.

Von April 2009 bis September 2013 war ich schon mal Mac-User. Mich hat damals zum einen das OS interessiert, aber vor allem war ich vom Mac mini begeistert. Kompakte Hardware mit ausreichend Leistung, sehr leise und stromsparend. Irgendwann hat die Leistung jedoch nicht mehr gereicht und von OS X war ich auch genervt.

Der Wechsel zurück zu Linux war absolut schmerzlos. Irgendwelche spezielle Software, die nur unter OS X und nicht unter Linux läuft, hab ich nicht wirklich benutzt. Und Gnome 3 wirkte auf mich auch ein bisschen wie OS X. Aber Linux-Desktops wie Gnome 3 oder andere sind von der Funktionalität und Produktivität macOS oder Windows deutlich überlegen. Bei der Diskussion, was nun das beste Desktop-OS ist, wird gerne gesagt, dass Linux Gefrickel ist, wärend auf dem Mac alles einfach funktioniert. Das mag zwar sein. Doch wie oft installiert man das OS neu oder richtet neue Hardware ein? Vielleicht ist die Installation etwas frickeliger bei Linux (wobei sie mit meiner Hardware absolut problemlos ist), doch beim täglichen Arbeiten zählen andere Dinge. Windows und macOS können dann nur mit der größeren Auswahl an Anwendersoftware punkten.

Also warum sollte man als glücklicher Linux-User wieder zurück? Ohne Mac (meine Hackintosh-Versuche waren mehr oder weniger erfolglos) war ich nicht mehr in der Lage meine Software unter macOS zu testen. Auch weiß ich, dass dav unter einem aktuellen macOS nicht ohne weiteres kompiliert. Und meine Pläne für ein Multiplattform-GUI-Framework fallen ohne Mac auch aus. Auch ärgerte es mich, dass ich als Unix-Fan keinen Zugriff auf einen wichtigen Vertreter dieser Gattung hatte. Es musste also wohl oder übel wieder Apfel-Hardware her.

Die Auswahl ist da allerdings eher schlecht. Leider schafft es Apple nicht mehr, brauchbare Hardware zu bauen. Notebooks wollte ich nicht. Abgesehn davon taugen die auch nichts. Mac Pro ist alt und für die Tonne. Der iMac fällt auch aus, weil er ein AiO ist. Also muss wieder der Mac mini her. Das "aktuelle" Modell ist jedoch nicht nur von 2014, es ist auch noch schlechter als das Vorgängermodell von 2012.

Und der Mac mini ist jetzt auch gar nicht mal so gut. Selbst wenn man ein Modell mit aktueller CPU und wechselbaren RAM und SSD hätte. Vergleichbare Konkurrenzprodukte sind einfach besser. Mein aktueller Linux-PC ist ein Fujitsu D756. Ebenso leise und stromsparend, dafür keine verlötete CPU, kein verlöteter RAM, Platz für einige Disks und PCIe-Karten. Das ist jetzt jedoch ein Small Form Factor PC und nicht ganz so mini. Ich halte diese Geräteklasse zwar für überlegen, aber es gibt von PC-Herstellern auch deutlich kleinere Systeme. Ich fasse es zwar nicht, dass ich was positives über Lenovo sage, aber den ihr ThinkCentre M710/M910 Tiny ist ein sehr interessanter PC. Kleiner als der Mac mini, dafür leistungsfähiger, wartungsfreundlicher, erweiterbarer und mit mehr Schnittstellen. Günstiger glaube ich auch noch. Apple sollte also deutlich mehr tun als nur ein einfaches Update des Mac minis zu bringen.

Letztendlich hab ich dann doch den 2012er Mac mini gekauft. Dank Apple sind die Teile gebraucht nur zu abartig überhöhten Preisen erhältlich. An macOS muss ich mich jetzt erstmal wieder gewöhnen. Mein Haupt-Desktop wird definitiv Linux bleiben, weil ich da einfach die viel bessere Hardware für habe und die Bedienung von Gnome 3 einfach besser ist. Eine Chance gebe ich macOS aber schon, denn so ein bisschen hat mir das OS ja schon gefallen. Ein bisschen...

• 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.