Microsoft sorgt neuerdings öfter mal für Überraschungen. Diesmal veröffentlichen sie einen Texteditor für Linux und OS X, der trotz seines Namens nichts mit der Visual Studio IDE zutun hat.
Unter Scientific Linux 7 ließ sich Visual Studio Code problemlos starten. Der Editor setzt auf Chromium auf, was ihn zwar halbwegs plattformunabhängig macht, jedoch fühlt sich das Userinterface teilweise träge an. Zumindestens die Menüs werden etwas langsam gerendert.
Vom Funktionsumfang ist Visual Studio Code recht gut ausgestattet. Syntaxhighlighting für viele Sprachen, ein bisschen Codecompletion, Integration von git und Debugging für Mono- und Node-Anwendungen. Interessant ist auch die Markdown-Preview-Funktion, die bei mir aber nur funktionierte, wenn die Datei auf .md endete. Für C/C++ kann der Editor aber bei weitem nicht mit einer IDE mithalten.
Visual Studio Code kann man hier downloaden.
Golem berichtet, dass ab sofort das Raspberry Pi 2 erhältlich ist. Die neue Version hat vier Cortex A7 Kerne und 1 GByte RAM. Der Rest ist weitgehend wie beim Raspberry Pi B+, auch der Grafikkern ist der gleiche.
Insgesammt eine sehr erfreuliche Nachricht. Die Leistung des Raspberry Pi war deutlich schwächer im Vergleich zu den ganzen Konkurrenten. Besonders der größere Arbeitsspeicher dürfte einige neue Anwendungsfelder eröffnen.
Unter Fedora/RHEL kommt standardmäßig der System Security Services Daemon für die Authenticationverwaltung zum Einsatz, aber auch unter anderen Distributionen lässt sich SSSD nachinstallieren. Ich möchte hier kurz beschreiben, wie sich mit SSSD LDAP-Authentication einrichten lässt. Die traditionellere Methode wird in einem anderen Artikel beschrieben.
Unter Fedora/RHEL gibt es das Tool authconfig-gtk, mit dem sich ldap per GUI konfigurieren lässt. Ohne GUI reicht es die Datei /etc/sssd/sssd.conf zu bearbeiten. Dazu fügt man zuerst die ldap-Konfiguration ein:
[domain/mydomain]
autofs_provider = ldap
cache_credentials = True
ldap_search_base = dc=example,dc=com
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldap://ldapserver/
ldap_id_use_start_tls = True
ldap_tls_cacertdir = /etc/openldap/cacerts
Der Domainname ist frei wählbar und es muss noch angegeben werden, dass diese Domain verwendet werden soll. Die [sssd] Sektion enthält den Eintrag domains, der die Domainnamen kommagetrennt enthält.
[sssd]
...
domains = mydomain
Das war nur ein einfaches Beispiel. Mehr Informationen gibt es in der sehr ausführlichen Dokumentation.
Dass man X11-Anwendungen auch remote per ssh ausführen kann dürfte allseits bekannt sein. Die Anwendung ist dann allerdings an die ssh-Sitzung gebunden. Wird diese terminiert, wird auch die Anwendung beendet. Mit dem Tool Xpra (X Persistent Remote Applications) kann man jedoch auch Anwendungen Remote starten und dann nahtlos auf andere Computer bzw Displays übertragen oder die lokale Sitzung unterbrechen und später wieder aufnehmen.
Die Bedienung ist denkbar einfach. Zuerst muss nur die Anwendung auf dem Server gestartet werden:
xpra start ssh:user@server:100 --start-child=gedit
Dieser Befehl baut eine Verbindung zum Server auf und startet die gewünschte Anwendung, die nach dem Login auch gleich auf dem Client angezeigt wird. Die Zahl 100 steht für das Display ist frei wählbar. Wichtig dabei ist, dass man jedes Display nur für eine Anwendung benutzen kann. Möchte man mehrere Anwendungen starten, wählt man einfach eine andere Displaynummer.
Der lokale xpra-Prozess kann einfach beendet werden und die Anwendung läuft auf dem Server weiter. Möchte man später die Verbindung wieder herstellen, egal ob vom gleichen Computer oder einem anderen, geht das auch sehr einfach:
xpra attach ssh:user@server:100
Auf dem Server kann man sich mit xpra list eine Liste aller Sitzungen anzeigen lassen und mit xpra stop :100 ein Display und damit auch die Anwendung wieder stoppen.
LDAP-Server gibt es einige. Am meisten verbreitet ist wohl OpenLDAP. Ich persöhnlich finde OpenLDAP allerdings zu frickelig, vor allem seit slapd.conf abgeschafft wurde, und die Konfiguration auch über ldap geschieht. Glücklicherweise gibt es einige Alternativen, z.B. den 389 Directory Server von Red Hat, und natürlich OpenDJ, worum es in diesem Artikel auch gehen soll.
OpenDJ ist ein Fork von OpenDS, einem von Sun Microsystems in Java entwickelten LDAP-Server. Nach der Übernahme von Sun durch Oracle wurde die Entwicklung von OpenDS jedoch eingestellt, daher gründeten ehemalige Sun-Mitarbeitern die Firma ForgeRock und forkten OpenDS. OpenDJ hat daher einen gewissen kommerziellen Charakter, allerdings ist es trotzdem OpenSource-Software.
OpenDJ gibt es unter anderem als einfaches zip-Package zu downloaden. Für die normalen Releases muss man sich registrieren, jedoch nicht für die Nightly-Builds. Da es sich um Java-Software handelt, benötigt man natürlich eine JRE. Nach dem Download einfach das zip-Package in den gewünschten Installationsort entpacken. Danach muss nur noch das setup-Script ausgeführt werden. Dieses startet einen kinderleichten grafischen- oder CLI-Assistenten, in dem alles nötige konfiguriert wird.
Nach dem Setup wird gewöhnlich eine Server-Instanz gestartet und es wird gefragt, ob man das Control-Panel (Button mit der Aufschrift "Steuerbereich starten") starten möchte. Dies kann man später auch alles manuell machen. Im opendj/bin Verzeichnis liegen alle nötigen Skripte (start-ds, stop-ds, control-panel).
Das Control-Panel macht OpenDJ so benutzerfreundlich. Es ist sowohl möglich lokale Server, als auch entfernte Server damit zu administrieren.
Neben typischen Aufgaben wie LDIF Im- und Export und Schema-Verwaltung, gibt es auch die Möglichkeit, LDAP-Einträge zu verwalten. Man kann sich also auch einen separaten LDAP-Client sparen.
Ganz nett ist auch, dass OpenDJ standardmäßig mit allen wichtigen Schemas ausgeliefert wird. Einfacher kann man den Einstieg in die LDAP-Welt nicht machen.