WordPress – Einstellung der Fontsize des Text-Editors

WordPress 3.x (x >= 2) nutzt den MS Consolas Font im Text-Editor. Hier meine ich den Minimal-Editor, in dem man selbst HTML/CSS-Befehle eingeben kann und nicht den Visual Editor..

Der Consolas TTF-Font sieht unter Linux nach meinem Dafürhalten nicht besonders gut aus. Hinzu kommt, dass die von WordPress eingestellte Standard-Font-Größe des Minimal-Editors auf meinen hochauflösenden Laptopschirmen einfach zu klein ist. “Ctrl +” im Browser hilft auch nicht wirklich, da dann alle Bereiche der Seite vergrößert werden und das Editor-Fenster zu klein wird.

Nun weiß man, dass das eine Einstellungssache ist. Aber welches CSS-File muss man editieren ? Für die Style-Vorgaben der generierten Webseiten und auch für die Styles des Visual-Editors gibt es unter dem Menüpunkt Design den Editor, mit dem man die zugehörigen CSS-Dateien online bearbeiten kann. Für die CSS-Files, die das Layout der Admin- oder Redakteurs-Oberfläche steuern, habe ich dagegen keine einfache Bearbeitungsmöglichkeit gefunden.

Zu meiner Überraschung erwies sich eine Suche im Internet bzgl. entsprechender Hinweise als wahre Odyssee. Es gibt zwar Hinweise, aber die meisten sind veraltet. Daher an dieser Stelle ein paar Hinweise:

Die CSS-Steuerung der verschiedenen Seiten und Elemente der Admin-Oberfläche erstreckt sich inzwischen über eine Vielzahl von Dateien, die in folgendem Verzeichnis liegen:

wp-admin/css

Nun möchte man meinen, dass man da was Passendes finden würde. Falsch gedacht !

Ich habe dann in einem Verzweiflungsanfall die CSS-Analyse-Tools von FF benutzt, um den CSS-Klassennamen für das Textarea-Feld im Editor-Bereich zu finden, und mich danach auf die Suche nach Eintragen in CSS-Dateien in mehreren Verzeichnissen gemacht. Fündig wurde ich schließlich in folgendem File :

wp-includes/css/editor.min.css

Vor weiteren Aktionen legt man nun eine Sicherungskopie dieser Datei an. Nun ist dieses File nicht ganz leicht zu editieren, da alle CSS-Anweisungen in eine einzige lange, komprimierte Zeile geschrieben wurden. Manche Editoren mögen die entstehenden Zeilenlängen nicht. Aber man setze z.B. in Kate die erlaubte Zeilenlänge auf 300000 Characters und schon ist man wieder im Spiel. Nun gilt es die Anweisungen für

.wp-editor-container    textarea.wp-editor-area

zu finden. Dort fügt man dann die gewünschte “font-size” und “font-family” hinzu. Und schon sieht der WordPress Text-Editor wieder so gut aus wie in alten Zeiten.

wp_1_600

Andere Alternativen zur Abänderung der CSS-Vorgaben bestehen darin, eine Inline-Style-Vorgabe in die Datei

wp-admin/post.php

beim Textarea-Feld einzufügen. Oder man arbeite mit dem netten Plugin “Add Admin CSS” und gebe dort die Vorgaben für “.wp-editor-container    textarea.wp-editor-area” im gewöhnlichen CSS-Format ein. Letztere Methode hat auch den Vorteil, dass sie evtl. WordPress-Updates überlebt.

Denn eine Abkehr von der aktuellen CSS-Politik und einen Veränderung der Position und Namen der Files, die das Layout steuern, kommt mit Sicherheit eher früher als später. Bis dahin jedenfalls weiter viel Spass beim Bloggen!

Kurzreview Eclipse 4.3 Kepler mit PDT und Aptana

Vor einiger Weile hatte ich mich wegen der miserablen Performance enttäuscht von Eclipse 4.2 Juno mit PDT abgewandt. Besonders bei Benutzung der neuen GTK-Oberfläche tauchten immer wieder lange andauernde 100%-Peaks in der CPU-Belastung von 1 bis 2 CPU-Cores auf. Auf meinem schwachbrüstigen Laptop eine Katastrophe – aber auch auf einem gut ausgestatten Desktop-Rechner eine echte Belastung.

Im besonderen galt dies beim Hin- und Herziehen von Tabs zwischen zwei getrennten parallelen, vertikalen Editor-Bereichen der GUI von Juno. Das Öffnen des Outline-Bereiches machte das System nochmal träger. Die parallel Sicht auf mehrere geöffnete Files sowie den Outline-Bereich benötige ich beim Arbeiten mit vielen Klassenbibliotheken aber immer wieder.

Es half keine Herumdoktern an den Speichereinstellungen für die JVM. Genausowenig half eine Umstellung auf die klassische Eclipse GUI. Daneben gab es auch immer wieder seltsame Probleme mit einer parallelen Installation von Aptana und PDT 3.1/3.2. Die Content Assist Vorschläge wurden entweder gar nicht oder nicht immer vollständig angezeigt. Die Schwierigkeiten waren sowohl bei Einsatz von Suns JVM für Java 7 als auch von OpenJDK 1.7 gegeben. Alles unter Opensuse 12.2 und 12.3 (64 Bit).

Für meine PHP-Entwicklungsarbeiten griff ich aus diesen Gründen bis gestern immer noch auf Eclipse 3.7 “Indigo” zurück.

Nun ist Eclipse in der Version 4.3 unter dem Namen “Kepler” erschienen. Daher habe ich gestern erneut einen Anlauf mit dieser aktuellen Eclipse-Version und dem zugehörigen PDT 3.2 plus Aptana Studio 3 unternommen. Und diesmal wurde ich nicht entäuscht:

Alles funktioniert wie es soll und das wirklich performant. Allerdings musste ich meine unter Indigo aufgebauten Workspaces unter Rückgriff auf vorhandene SVN-Repositories komplett neu aufbauen. Erst danach lief alle fehlerfrei.

eclipse_kepler_1_600

An den Standard Speichereinstellungen habe ich nichts verändert. Die “eclipse.ini” sieht daher wie folgt aus:

-startup
plugins/org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar
–launcher.library
plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.200.v20130521-0416
-product
org.eclipse.epp.package.standard.product
–launcher.defaultAction
openFile
-showsplash
org.eclipse.platform
–launcher.XXMaxPermSize
256m
–launcher.defaultAction
openFile
–launcher.appendVmargs
-vmargs
-Dosgi.requiredJavaVersion=1.6
-XX:MaxPermSize=256m
-Xms40m
-Xmx512m

Es gab und gibt nach bislang 12 Stunden Arbeit keinerlei Hänger und keine Peaks in der CPU zu bemängeln! Das Arbeiten mit mehreren parallel angezeigten Editor- und GUI-Bereichen läuft sehr flüssig. Das Verschieben von Tabs für geöffnete Dateien zwischen zwei Darstellungsbereichen führt zwar zu einer kurzfristigen Belastung mehrerer CPU-Kerne – aber eben wirklich nur sehr kurzzeitig und das ist nicht als Bremse für das Arbeiten wahrnehmbar. Auch die Build-Operation für Projekte laufen mit angemessener Geschwindigkeit.

Aptana lässt sich parallel zu PDT einsetzen. Man kann zwischen den verschiedenen “Natures” entsprechend “facettierter” Projekte nach Lust und Laune hin- und herschalten. Die Content-Assists-Hinweise kommen entsprechend. Ich nutze z.T. den Aptana-Editor, um HTML-Code in TPL-Files für die Template-Engines Pear-ITX oder Smarty zu bearbeiten. Ich schätze dabei die browser-bezogenen Content Assist Hinweise. Aber auch der Wechsel zum normalen WST-HTML-Editor mit dessen Content-Assists-Fähigkeiten für HTML- und CSS-Vorschlägen klappt einwandfrei.

Aptanas PHP-Unterstützung benutze ich in der Regel nicht und
habe ich daher nicht wirklich getestet. Ein kurzes Umschalten auf die Aptana Editoren und Aptanas Content Assist für PHP zeigte mir aber keine unerwarteten Probleme.

Die SVN-Anbindung über Subversive und die Polarion-Konnektoren lief wie erwartet. Ein Gleiches gilt für MyLyn

Kurzum:
Für PHP-Projekte stellt Eclipse 4.3 “Kepler” endlich eine ernsthafte, weil funktionierende und performante “Eclipse 4.x”-Alternative zu Indigo dar. Ich kann den Umstieg wirklich empfehlen.

Ein kleiner Wermutstropfen
Schade irgendwie, dass es der HTML-“Web Page Editor” bisher nicht in die “WTP 3.5” -Repositories von Kepler geschafft zu haben scheint. Aber eine Installation aus den WTP 3.3.2 Ressourcen scheint keine größere Probleme zu machen.

phpMyAdmin Vers. 4.x und 5.x – Configuration Storage, Control User pma und zugehörige Tabellen

PhpMyAdmin hat sich ja seit der Version 4 dahingehend geändert, dass man seine Konfigurationseinstellungen für die GUI partiell in dafür bereitgestellten Datenbanktabellen hinterlegen muss. Hat man diese Tabellen nicht angelegt, weisen einen nach der phpMyAdmin-Grundinstallation Hinweise am unteren Ende der GUI auf bestehende Konfigurationsdefizite hin.

Ich vergesse nach der erfolgreich abgeschlossenen Einrichtung von phpMyAdmin auf einem Kundenserver leider selbst immer wieder, was genau man für die Einrichtung der “Konfigurationsdatenbank” und des zugehörigen Users im Rahmen der phpMyAdmin-Installation tun muss. Der Vorgang ist leider etwas umständlich. Wer immer sich diesen Installationsweg ausgedacht hat, sollte mal einen Kurs in Usability belegen.

Ich kritisiere dabei gar nicht die technische Umsetzung der Speicherung der Konfigurationseinstellungen für verschiedene User in Tabellen. Es geht mehr darum, welchen Aufwand man bei der Installation betreiben muss, um überhaupt ein konfigurierbares phpMyAdmin zu bekommen, das die vorgenommenen GUI-Einstellungen beim Verlassen des Programms nicht vergisst. Das ist wirklich keine Reklame für Opensource …. ganz im Gegensatz zu den schnörkellosen, einfach zu installierenden und gut zu bedienenden 3er-Versionen von phpMyAdmin.

Zudem ist die Basiseinstellung des 4er-GUI-Layouts in mancherlei Hinsicht einfach grässlich und im Vergleich zu den 3er-Versionen des Programms wenig ergonomisch. Daher schreibe ich die notwendigen Schritte hier mal auf.

Addendum 18.07.2022: Obwohl dieser Post ursprünglich für die Version 4.3 geschrieben wurde, gilt der Inhalt analog für aktueller Versionen 5.x.

Schritt 1: Einrichten der Konfigurationstabellen

Im Installationsverzeichnis von phpMyAdmin auf dem Web-Server – in meinem Fall

/srv/www/htdocs/phpmyad/

befindet sich ein Subverzeichnis “examples” mit folgender Datei:

examples/create_tables.sql

Addendum 18.07.2022: In einer aktuellen Version 5.2 von phpMyAdmin befindet sich die Datei im Verzeichnis “sql”.

Die Datei beinhaltet die notwendigen SQL-Statements zur Generierung der erforderlichen Tabellen. Zur Durchführung der Statements importiert man die Datei einfach mit phpMyAdmin:

phpmyad_1_600

Danach findet man folgende Tabellen einer neuen Datenbank “phpmyadmin” vor:

phpmyad_2

Addendum 18.07.2022: In aktuelleren Versionen von phpMyAdmin hat sich die Anzahl der Tabellen der Datenbank “phpmyadmin” erhöht:

Achtung:

Verwaltet man mit einer phpMyAdmin-Installation mehrere MySQL-Datenbank-Instanzen auf unterschiedlichen Datenbankservern, so muss man diesen Import-Schritt auf jeder Datenbank-Server–Instanz vornehmen!

Schritt 2: Anlegen eines Control-Users “pma”

Nun legt man mit Hilfe von phMyAdmin einen Datenbank-User “pma” an und erteilt ihm alle Rechte an der eben angelegten Datenbank “phpmyadmin”. Am einfachsten geht das über den Reiter “Rechte” bei geöffneter Datenbank “phpmyadmin”:

phpmyad_4_600

phpmyad_3_600

Dieser User mit den Rechten am sog. “Configuration Storage”, nämlich der Datenbank phpmyadmin, wird auch als “Control User” bezeichnet. Wir merken uns das vergebene Password. Auch diesen Schritt muss man natürlich für jede der mit der aktuellen phpMyAdmin-Installation ggf. verwalteten Datenbank-Server-Instanzen vornehmen.

Hinweis: Greift man nicht über “localhost” sondern einen Domainnamen auf phpMaAdmin zu, so muss der User pma auch für die Domaine angelegt werden, der der aktuelle Host zugeordnet ist. Also etwa

Create USER 'pma'@'mytux.mylocaldomain.de' IDENIFIED BY 'DEIN_PMA_PASSWORD';

Auch dieser User muss die nötigen Rechte an der Bank “phpmyadmin” erhalten.

Addendum 18.07.2022: Die Einschränkungen der Rechte des Users ‘pma’ durch die ersten Statements sind relativ restriktiv. Eine andere Wahl der Rechtezuteilung findet ihr hier:
www.workshop.ch/ openmind/ 2013/12/24/ phpmyadmin-zusatzfunktionen-aktivieren-mit-dem-configuration-storage/

Schritt 3: Ergänzung der Datei “config.inc.php”

Der nächste Schritt besteht darin, die Datei “confic.inc.php” im phpMyAdmin-Installationsvezeichnis des Webservers um Informationen zum User “pma” und zu den eben angelegten Konfigurationstabellen zu ergänzen:

$cfg['Servers'][$i]['pmadb'] = 'phpmyadmin';<br>
$cfg['Servers'][$i]['controluser'] = 'pma';<br>
$cfg['Servers'][$i]['controlpass'] = 'DEIN_PMA_PASSWORD';<br>
 <br>
$cfg['Servers'][$i]['bookmarktable'] = 'pma__bookmark';<br>
$cfg['Servers'][$i]['relation'] = 'pma__relation';<br>
$cfg['Servers'][$i]['userconfig'] = 'pma__userconfig';<br>
$cfg['Servers'][$i]['table_info'] = 'pma__table_info';<br>
$cfg['Servers'][$i]['column_info'] = 'pma__column_info';<br>
$cfg['Servers'][$i]['history'] = 'pma__history';<br>
$cfg['Servers'][$i]['recent'] = 'pma__recent';<br>
$cfg['Servers'][$i]['table_uiprefs'] = 'pma__table_uiprefs';<br>
$cfg['Servers'][$i]['tracking'] = 'pma__tracking';<br>
$cfg['Servers'][$i]['table_coords'] = 'pma__table_coords';<br>
$cfg['Servers'][$i]['pdf_pages'] = 'pma__pdf_pages';<br>
$cfg['Servers'][$i]['designer_coords'] = 'pma__designer_coords';<br>

Addendum 18.07.2022: In aktuelleren Versionen 5.x sieht das so aus:

/**
 * phpMyAdmin configuration storage settings.
 */

/* User used to manipulate with storage */
$cfg['Servers'][$i]['controluser'] = 'pma';
$cfg['Servers'][$i]['controlpass'] = 'YOUR_PMA_PASSWORD';

/* Storage database and tables */
$cfg['Servers'][$i]['pmadb'] = 'phpmyadmin';
$cfg['Servers'][$i]['bookmarktable'] = 'pma__bookmark';
$cfg['Servers'][$i]['relation'] = 'pma__relation';
$cfg['Servers'][$i]['table_info'] = 'pma__table_info';
$cfg['Servers'][$i]['table_coords'] = 'pma__table_coords';
$cfg['Servers'][$i]['pdf_pages'] = 'pma__pdf_pages';
$cfg['Servers'][$i]['column_info'] = 'pma__column_info';
$cfg['Servers'][$i]['history'] = 'pma__history';
$cfg['Servers'][$i]['table_uiprefs'] = 'pma__table_uiprefs';
$cfg['Servers'][$i]['tracking'] = 'pma__tracking';
$cfg['Servers'][$i]['userconfig'] = 'pma__userconfig';
$cfg['Servers'][$i]['recent'] = 'pma__recent';
$cfg['Servers'][$i]['favorite'] = 'pma__favorite';
$cfg['Servers'][$i]['users'] = 'pma__users';
$cfg['Servers'][$i]['usergroups'] = 'pma__usergroups';
$cfg['Servers'][$i]['navigationhiding'] = 'pma__navigationhiding';
$cfg['Servers'][$i]['savedsearches'] = 'pma__savedsearches';
$cfg['Servers'][$i]['central_columns'] = 'pma__central_columns';
$cfg['Servers'][$i]['designer_settings'] = 'pma__designer_settings';
$cfg['Servers'][$i]['export_templates'] = 'pma__export_templates';

Man beachte dabei, dass es zwischen dem Prefix “pma” und dem Tabellennamen 2 (!) Unterstriche gibt.

Im diskutierten Beispiel sind wir davon ausgegangen, dass wir die Serverinstanz mit dem Index “$i” mit den Informationen versorgt haben.

Natürlich gilt auch hier, dass man diese Einstellungen separat pro MySQL-Datenbankserver-Instanz, die mit phpMyAdmin verwaltet werden soll, anlegen muss. Sind mehrere Instanzen gegeben, ist es also wichtig, im Script “config.inc.php” den Index $i explizit hochzuzählen bzw. auf den richtigen Wert für die jeweilige Instanz zu setzen.

Man verlässt dann phpMyAdmin und loggt sich erneut in die GUI ein. Es sollten nun keine Hinweise mehr zu Konfigurationsdefiziten erscheinen.

Schritt 4: Vornehmen von Änderungen

Wir sind nun in der Lage, die gewünschten Änderungen am GUI-Layout pro Serverinstanz vorzunehmen und dauerhaft in den angelegten Tabellen zu hinterlegen. Als Beispiel ändern wir die parallele Anzeige von Icons und Menüpunkt-Texten auf den Seiten zur Bearbeitung der Tabellen so ab, dass nur noch die Icons angezeigt werden:

phpmyad_5_600

Nicht vergessen, den Button “Speichern” zu drücken. Ganz so praktisch und informativ wie die GUIs der 3er-Version wird phpMyAdmin in der Version wohl erst wieder nach einiger Zeit werden.

Trotzdem viel Spaß beim künftigen Herumprobieren mit eigenen Einstellungen in den aktuellen Versionen von phpMyAdmin.

Adendum 18.07.2022: Bevor ich es vergesse: Der schlimmste lebende Faschist und Kriegsverbrecher ist der Putler!

Sehr gute Erfahrungen mit SSD Samsung 840 PRO

Auf einem vorgestern eingerichteten Laptop unter Linux habe ich die eingebaute SATA3 HD gegen eine SSD ausgetauscht.

Gewählt hatte ich die “Samsung SSD 840 PRO” in der 256 GB-Variante. Animiert dazu hatte mich folgender Testbericht:

http://www.guru3d.com/articles_pages/samsung_840_pro_ssd_benchmark_review_test,16.html

Wie die dortigen Vergleiche zeigen, ist das Pro in der Datenträger-Bezeichnung durchaus bedeutsam, weil die Pro-Variante gegenüber der Basis-Variante nochmal deutliche Performance-Vorteile bringt.

Im BIOS muss man für den Betrieb der SSD das SATA-Interface auf AHCI umstellen.

http://wiki.ubuntuusers.de/SSD/Grundlagen

Optimierungstipps findet man z.B. hier:

https://sites.google.com/site/easylinuxtipsproject/ssd-in-opensuse
http://www.linuxbibel.org/ssd_optimieren.html
http://wiki.ubuntuusers.de/SSD/TRIM
http://www.pcwelt.de/ratgeber/Linux-Special-SSDs-unter-Linux-6593528.html
http://wiki.siduction.de/index.php?title=Solid_State_Disks_%28SSDs%29_unter_Linux_optimal_nutzen

Am wichtigsten erscheint es mir bei normaler Nutzung und in dem Fall, dass man keine weitere normale Festplatte verfügbar hat, die Option “noatime” für das “ext4”-Filesystem zu nutzen sowie regelmäßig händisch oder über cron den Befehl

fstrim -v /

abzusetzen. Logs im tempfs unterzubringen ist zwar nett, aber auch eine Übung, die im Ernstfall wertvolle Informationen kosten kann.

Erster Eindruck von der Performance
Ich wurde nicht entäuscht. Unter Opensuse 12.3 erlebte ich für eine normale Desktop-Konfiguration ohne Serverkomponenten

  • Shutdownzeiten deutlich unter 2 Sekunden
  • Bootzeiten im Anschluss an Grub 2 von unter 4,5 Sekunden (inkl. Hochfahren von KDM – also bis zum grafischen Login).

Da kommen meine als Raid 10 am 3ware-Controller konfigurierten SATA 2 Platten der Workstations nicht mit. Es fehlt ein Faktor 2 bei gleicher Konfiguration. Das setzt sich mit Faktoren von 1.6 bis 2.0 bei Tests mit “bonnie++” zu verschiedenen Lese- und Schreib-Vorgängen so fort.

Die Samsung SSD 840 Pro hält wirklich, was sie verspricht.

Fazit:
Wer seine Linux-Systeme richtig beschleunigen möchte, richte sich eine SSD des genannten Typs als Träger für die Systempartition ein.

Wenn man gegen SSD-Ausfälle gefeit sein möchte, kaufe man sich für etwa den gleichen Preis (rund 205 Euro) zwei “128 GB”-SSD-Platten des hier betrachteten Typs und fahre die im Raid 1 Verbund an einem passenden “SATA 3”-Controller. Andere erstrebenswerte Konfigurationen wie etwa Raid 10 wären für mich auf Basis von SSDs nicht erschwinglich.

User-Daten, Anwendungsdaten, Datenbanken, etc. und alles, wo ein hoher Schreibdurchsatz gegeben ist, lege man dagegen auf konventionellen Platten (in einem geeigneten, performancesteigernden Raid-Verbund) ab – schlicht um die Lebenszeit der SSD zu verlängern.

opensuse 12.3, LDAP, sssd – III

In den vorigen Beiträgen

opensuse 12.3, LDAP, sssd – I
opensuse 12.3, LDAP, sssd – II

zu meiner kleinen LDAP-Reihe für OS 12.3 bin ich darauf eingegangen, dass der OpenLDAP-Server seit OS 12.2 wegen sssd TLS/SSL-fähig ausgelegt werden muss. In diesem Beitrag treffe ich mittels YaST2 die Vorbereitungen, um die TLS-Fähigkeit zu erreichen und lege dafür Zertifikate an.

Im weiteren Verlauf des Textes bezeichne ich als “LDAP-Server” dasjenige Server-System unter Opensuse 12.3, das eine OpenLDAP-Implementierung beinhaltet. Im LDAP-Baum werden später gemäß suse-spezifischer Regeln Standardobjekte für die Beherbergung von User- und Gruppen-Informationen angelegt. Der LDAP-Baum beinhaltet dann auch die Credentials für eine User-Authentifizierung.

Ein anderer Opensuse 12.3-basierter PC oder Server, auf dem ein User, dessen Daten im LDAP hinterlegt sind, sich einloggen will, bezeichnen wir nachfolgend dagegen als Linux- “Host” unseres Netzwerkes. Ziel ist es, den User mit Hilfe des LDAP_Servers zu authentifizieren und ihm bzw. anderen Programmen auf dem Host das Arbeiten mit dem LDAP-Server zu ermöglichen.

CA und Common Server Certificate für einen LDAP-Server

Verschlüsselte Verbindungen wie TLS/SSL basieren u.a. auf Zertifikaten. Ein asymmetrisches Sicherheitsverfahren leitet die Client/Server-Kommunikation ein. Dabei werden der private wie der öffentliche Schlüssel eines Servers eingesetzt: Der Erhalt des Server-Zertifikats dient dem Client zur Prüfung der Identität des Servers. Nach erfolgreicher Authentizitätsprüfung sendet der Client dem Server eine Zufallssequenz (pre-master-secret). Dieser Austausch erfolgt verschlüsselt unter Zuhilfenahme des öffentlichen Server-Keys (aus dem Zertifikat). Server und Client berechnen dann auf Basis definierter Verfahren einen gemeinsamen Schlüssel für das anschließend eingesetzte symmetrische (und deshalb schnelle) Verschlüsselungsverfahren für den eigentlichen Datenaustausch. Weitere detailliertere Infos erhält man hier :

http://de.wikipedia.org/wiki/Transport_Layer_Security

Zertikate – im besonderen Server-Zertifikate – werden über eine übergeordnete Instanz ausgestellt. Diese Instanz ist ein sog. “Certificate Authority”, kurz CA. Bei der Kommunikation von Clients mit Servern, die sich über Zertifikate ausweisen, muss das Serverzertifikat und damit die Identität des Servers mittels Informationen der CA als unabhängiger dritter Instanz verifiziert werden.

Hatte man für sein eigenes Netzwerk bislang keine CA generiert, so wird dies nun zwingend erforderlich, wenn Netzwerk-Hosts mit ihrem SSSD den zentralen LDAP-Server zur User-Authentifizierung nutzen sollen.

Es ist wahrscheinlich, dass auf dem zentralen LDAP-Server weitere Server-Dienste laufen werden. Daher kann es sinnvoll sein, auf diesem Server ein von SuSE so genanntes “Common Server Certificate” [CSC] zu implementieren. Ich zeige kurz für zwei Fälle, wie das geht.

Neu im Vergleich zu meinem früheren Artikel Opensuse 12.1 – LDAP -II ist hier lediglich der Einsatz des CSC.

Fall 1: LDAP-Server und CA-Server sind identisch

In unserem Fall setze ich aus Testzwecken neben einer vorhandenen Root-CA eine weitere namens “anraconb” für meine Tests auf. Dies geschieht mittels des YaST2-Moduls >> “CA-Management”. Im sich öffnenden Fenster drücken wir den Button “Create CA” und
füllen im nächsten Dialogfenster die erforderlichen Informationen aus:

LDAP_OS123_2

Die CA soll logisch später für eine virtuelle Spieldomaine namens “anraconb.de” zuständig sein und Zertifikate für Server und ggf. auch Clients in dieser Domaine ausstellen. Nachdem die CA erzeugt ist, können wir diese über den entsprechenden Button in der Grundmaske des YaST2-CA-Managements “betreten”:

LDAP_OS123_3

LDAP_OS123_4

Um ein kopierbares Zertifikatsfile der CA verfügbar zu haben, exportieren wir unser Zertifikat in eine PEM-Datei. Ich lege diese in einem Verzeichnis “/etc/certs” unter dem Namen “anraconb_CA.pem” ab.

Nun legen wir dann für unseren LDAP-Server ein “Server-Zertifikat” an. Nachdem dieses später auf dem gleichen System wie die CA zum Einsatz kommen wird, handelt es sich aus Sicht der späteren Client-Hosts um ein “Self Signed Cerificate”. Aber das kümmert uns im Moment noch nicht.

LDAP_OS123_5

Bei der Bezeichnung “common name” sollte der FQDN des Servers eingetragen werden. Dies ist wichtig ! Wir werden an verschiedenen Stellen eine exakte Übereinstimmung des Zertifikatsnamens mit dem FQDN des Servers benötigen.

LDAP_OS123_6

Nachdem das Zertifikat angelegt ist, exportieren wir dieses und den zugehörigen Key in unverschlüsselter Form erneut als Dateien:

LDAP_OS123_7

Etwas scrollen hätte übrigens zeigt, dass YaST hier RSA-basierte Zertifikate und Schlüssel erzeugt:

LDAP_OS123_18

Nun zum Export als File:

LDAP_OS123_8

LDAP_OS123_9

Das Key-File enthält den “Private Key” für künftige Verschlüsselungen! Key-Files, die aus dem Certificate Management exportiert wurden, müssen daher in besonderer Weise geschützt werden und sollten zunächst nur root zum Lesen zur Verfügung stehen.

Abschließend wählen wir als weitere Exportfunktion den “Export als Common Server Certificate”.

LDAP_OS123_10

Opensuse legt dann die Dateien erneut an – allerdings an definierter Stelle, die dann später von allen möglichen YaST2-Modulen genutzt wird. Man findet die erforderlichen Zertifikats- und Key-Dateien unter

  • /etc/ssl/servercerts/servercert.pem
  • /etc/
    ssl/servercerts/serverkey.pem

Die Zertifikatsdatei der CA wird unter

  • /etc/ssl/certs/YaST-CA.pem

angelegt

Fall 2: LDAP-Server und CA-Server sind nicht identisch

Natürlich müssen wir auf dem CA-Server ein Zertifikat für den LDAP-Server ausstellen. Dieser wird dann natürlich einen anderen Namen haben – z.B. “xlamp.anraconb.de”.

Alles läuft auf dem CA-Server praktisch identisch zum oben beschriebenen Vorgehen ab, bis wir das erstellte Server-Zertifikat exportieren. Wir müssen hier einen zusätzlichen Export als “p12”-Datei vornehmen.

LDAP_OS123_17

Man beachte, dass man hier neben dem Zertifikatsnamen ein weiteres Passwort angeben muss.

Dieses File kopieren wir dann per scp auf den Zielserver – also den LDAP-Server. Am besten in das gleiche Verzeichnis “/etc/certs”. Dort schützen wir es, indem wir Lese- und Schreibrechte nur an root vergeben ! Diesen Schritt bitte nicht vergessen !

Auf dem LDAP-Server importieren wir dann das p12-File über “Yast2 >> Common Server Certificate” über die Taste “Import/Replace”. Als Ergebnis werden auf dem LDAP-Server dann in den gleichen Verzeichnissen wie oben beschrieben die notwendigen Files angelegt – u.a. auch das der CA.

Fazit

Eine CA für das eigene Netzwerk ist schnell angelegt. Für seine Server – hier den LDAP-Server – erzeugt man ebenso schnell ein RSA-basiertes Zertifikat und importiert dieses dann auf dem Zielserver mittels YaST als “Common Server Zertifikat”. Das so erhaltene Zertifikat und der private Schlüssel des Servers können dann bei der TLS-Absicherung des LDAP-Servers eingesetzt werden.

Natürlich können aber auch andere Serverdienste die Zertifikatsfiles und die generierten Schlüssel für eine SSL/TLS-Absicherung verwenden – z.B. vsftp, Apache, Cyrus IMAP.

Im nächsten Beitrag dieser Serie legen wir einen LDAP-Server unter Opensuse 12.3 an. Damit wir im Gegensatz zu früheren Artikeln bzgl. LDAP unter Opensuse 12.1 auch was neues lernen, werde ich dabei auch kurz zeigen, was man tun muss, um den LDAP-Server monitoring- und munin-fähig aufzusetzen.