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.