Hier eine kleine Anleitung, wie man Authentifizierung über LDAP in FreeBSD konfiguriert. Es gibt auch eine offizielle Anleitung, jedoch ist mir aufgefallen, dass nicht alle Schritte dort nötig sind.
Nach einer frischen FreeBSD-Installation müssen erst folgende Pakete installiert werden:
$ pkg install openldap26-client pam_ldap nss_ldap
Dies dürfte zum einen erstmal überhaupt das Too pkg installieren und anschließend die angegebenen Pakete.
Jetzt wird es spannend. Die offizielle FreeBSD-Dokumentation erwähnt zum einen die Konfigurationsdatei /usr/local/etc/ldap.conf. Des Weiteren muss noch pam unter /etc/pam.d/ und nss über die Konfigurationsdatei /etc/nsswitch.conf konfiguriert werden.
Aber interessanterweise scheint dies in meinem FreeBSD 12.1 nicht so der Fall zu sein. Die Datei ldap.conf existiert, jedoch musste ich sie nicht anpassen. Stattdessen muss die Datei /usr/local/etc/nss_ldap.conf angepasst werden. Hier muss der LDAP-Server angegeben werden.
host 192.168.178.20 # ldap server ip or hostname
# The distinguished name of the search base.
base dc=example,dc=com
Falls nötig kann auch ein binddn angegeben werden:
binddn cn=admin,dc=example,dc=com
bindpw secret
Danach müssen in der Datei /etc/nsswitch.conf folgende Zeilen geändert werden, damit Benutzer und Gruppen auch über LDAP geladen werden:
group: files ldap
passwd: files ldap
Das wars. PAM musste ich aus irgendeinem Grund nicht anpassen. Meine ldap-User werden mit getent passwd angezeigt. Login mit su oder ssh funktioniert auch.
Update vom 09.10.2022: Package-Name openldap-client auf openldap26-client geändert.
Wenn man für seine Anwendung eine embedded Datenbank braucht, aber keine Schrott-DB wie SQLIte (no offense) benutzen will, kann man auch einfach Postgresql nutzen. Ganz ohne umständliche systemweite Installation. Man benötigt nur die Binaries, die man natürlich bequem per Paketverwaltung installieren kann, und eine Konfiguration, die in keinster Weise mit anderen Postgres-Instanzen interferiert.
Erreichen kann man dies sehr einfach. Es gibt nur zwei Hindernisse:
-
Postgresql legt standardmäßig Dateien in /var/run/postgresql/ ab, wie z.B. die Unix-Domain-Sockets. Mehrere Instanzen könnten sich da in die Quere kommen. Des Weiteren fehlen normalen Benutzern die nötigen Schreibrechte.
-
Kollision von TCP-Ports ist möglich. Außerdem sind offene TCP-Ports natürlich ein potentielles Sicherheitsproblem.
Die Lösung ist trivial. Man kann einfach in der Konfiguration ein anderes Verzeichnis angeben. Und TCP-Verbindungen deaktivieren wir einfach, denn wer keine Ports braucht, dem können sie auch nicht fehlen.
Was wir zunächst benötigen, ist ein schöner Ort für unsere Datenbank. Hier im Beispiel ist das $HOME/pg/
$ mkdir $HOME/pg
Danach erstellen wir eine Konfiguration für unsere Datenbank mit dem Postgresql-Tool initdb
$ cd $HOME/pg
$ initdb -D data
Dies erstellt den Ordner data, der diverse Konfigurationsdateien, aber auch die eigentlichen Daten der Datenbank enthält.
In $HOME/pg/data/ befindet sich die Konfigurationsdatei postgresql.conf. In dieser müssen wir zwei Dinge ändern bzw. einfügen. Um das TCP-Socket zu deaktivieren:
listen_addresses = ''
Das Verzeichnis, in welchem Postgresql sein Unix-Domain-Socket ablegt, wird über die Direktive unix_socket_directories konfiguriert. Hier geben wir am besten keinen absoluten Pfad an, sondern einen relativen Pfad. Dieser bezieht sich auf das data-Verzeichnis.
unix_socket_directories = 'run'
Das run-Verzeichnis muss noch angelegt werden
$ mkdir $HOME/pg/data/run
Nun kann der Server auch schon gestartet werden.
$ pg_ctl -D $HOME/pg/data start
Was wir noch brauchen ist eine Datenbank. Diese wird mit createdb angelegt.
$ createdb -h $HOME/pg/data/run/ mydb
Das wars. Jetzt kann man sich mit beliebigen Clients verbinden. Dabei muss dann nur das Verzeichnis $HOME/pg/data/run angegeben werden. Um sich z.B. mit psql zu verbinden:
$ psql -h $HOME/pg/data/run/ -d mydb
Statt mit dem -h Parameter kann man den Pfad auch mit der Umgebungsvariable PGHOST angeben.
Wenn man jetzt weitere Postgresql-Instanzen benötigt, kann man einfach wieder mit initdb eine erstellen, und dann reicht es, wenn die Konfigurationsdatei wieder entsprechend angepasst wird.
Das Ganze ist sehr praktisch für Software-Testumgebungen oder wenn eine Anwendung seine eigene DB mitbringen soll.
Für alle Benutzer von NEdit, oder besser XNEdit, hier ein kleiner Tipp, wie man sein Leben im Umgang mit XML vereinfachen kann. Maschinell erstellte XML-Dateien zu bearbeiten kann manchmal ziemlich nerven, nämlich wenn diese nicht für den menschlichen Betrachter formatiert sind. Mit dem Tool xmllint, welches Teil von libxml2 ist, lässt sich dieses Problem lösen:
xmllint --format file.xml > formatted.xml
Die Ausgabe hiervon ist ein schön formatiertes XML-Dokument mit eingerückten Tags.
Da man natürlich nicht ständig irgendwelche Kommandos in der Shell ausführen möchte, bevor man eine Datei öffnet, empfiehlt es sich, xmllint in XNEdit zu integrieren. Hierfür müssen wir dem Shell-Menü einen neuen Befehl hinzufügen.
Die Einstellungen dafür öffnet man über Preferences → Default Settings → Customize Menus → Shell Menu...
Dort wählen wir zuerst oben links New und geben bei Menu Entry einen passenden Namen für den Menüeintrag ein.
Die Einstellungen, die wir dann noch benötigen, sind:
Command Input: document
Command Output: same document
Output replaces input
Der Befehl, der ausgeführt werden soll ist:
xmllint --format -
Ein Klick noch auf OK und der neue Menüeintrag steht im Shell-Menü zur Verfügung. Danach kann nach dem Öffnen einer XML-Datei über das Shell-Menü unser XML-Formatierungsbefehl ausgeführt werden.
Um X11-Anwendungen unter Windows auszuführen, benötigt man einen X-Server. Empfehlenswert ist da VcXsrv. Damit ist es problemlos möglich, Remote-X11-Anwendungen innerhalb von ssh-Sitzungen mit Putty auszuführen. Ebenso eignet sich VcXsrv für den Fall, dass man mittels WSL grafische Anwendungen ausführen möchte.
VcXsrv kann die X-Clients als einzelne separate Fenster in Windows anzeigen, aber auch im Vollbildmodus betrieben werden, was das Ausführen einer kompletten X11-Desktop-Sitzung möglich macht.
Copy & Paste funktioniert und auch bei der Texteingabe mit Umlauten sind mir keine Probleme aufgefallen. Das ganze macht für mich einen ganz brauchbaren Eindruck.
Mein bevorzugtes Tool, um z.B. aus PDFs Seiten zu extrahieren oder Dokumente zusammenzufügen, war mal pdftk, was allerdings nicht mehr weiterentwickelt wird und da es auch auf gcj basiert, der auch Geschichte ist, kriegt man es auch nicht mehr wirklich zum laufen. Als Alternative habe ich stapler entdeckt, was ähnlich leicht zu benutzen ist. Das Tool gibts auch im Fedora-Repo, dort heißt es allerdings pdf-stapler und wird auch über diesen Namen aufgerufen. Bei Ubuntu gibts das Programm hingegen nicht im Repository.
Hier mal ein paar Beispiele:
Seiten extrahieren
stapler sel doc.pdf 1 out.pdf
stapler sel doc.pdf 4-6 out.pdf
Reihenfolge von Seiten umkehren
stapler sel doc.pdf 3-1 out.pdf
Seiten drehen
stapler sel doc.pdf 1D out.pdf
stapler sel doc.pdf 1L out.pdf
stapler sel doc.pdf 1R out.pdf
D steht für Down, L für Left und R für Right.
Dokumente zusammenfügen
stapler sel file1.pdf file2.pdf out.pdf
Es können nach dem Dateinamen auch Selektierungsanweisungen (siehe oben) angegeben werden:
stapler sel file1.pdf 1-2 file2.pdf 6-9 out.pdf
Dokument splitten
stapler split doc.pdf