UNIXwork

GraalVM ist eine erweiterte Java-VM, die neben Java noch diverse andere Sprachen unterstützt. Diese bietet einer bisher unerreichte Interoperabilität. So ist es beispielsweise möglich, von Java aus direkt auf Datenstrukturen oder Funktionen von Python oder JavaScript zuzugreifen.

Neu ist jetzt eine experimentelle Unterstützung für WebAssembly (WASM). WASM ist ein standardisierter Bytecode, der speziell für Browser entworfen wurde. Dieser soll es ermöglichen, dass neben JavaScript noch andere Programmiersprachen für Web-Client-Programmierung genutzt werden können, in dem diese zu WASM-Bytecode kompiliert werden. Dieser Bytecode kann jetzt auch von der GraalVM ausgeführt werden.

Damit kann nun jede Sprache, für die es WASM-Compiler gibt, auch innerhalb der GraalVM genutzt werden.

Wer sich das genauer anschauen möchte, sollte einen Blick in die offizielle Ankündigung werfen.

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.