Opensuse 12.3, mysql/mariadb, logrotate-Fehler

Nach der Umstellung auf die Maria DB unter Opensuse 12.3 bin ich mal wieder über einen mysql-logrotate-Fehler gestolpert.

2013-05-18T10:45:03.378467+02:00 myserv logrotate: ALERT exited abnormally with [1]
2013-05-18T10:45:03.379471+02:00 myserv logrotate: #007/usr/bin/mysqladmin: flush failed; error: ‘Unknown error’
2013-05-18T10:45:03.379739+02:00 myserv logrotate: /logrotate.d/mysql failed, probably because
2013-05-18T10:45:03.379926+02:00 myserv logrotate: the root acount is protected by password.
2013-05-18T10:45:03.380190+02:00 myserv logrotate: See comments in /logrotate.d/mysql on how to fix this
2013-05-18T10:45:03.380359+02:00 myserv logrotate: error: error running non-shared postrotate script for /var/log/mysql/mysqld.log of ‘/var/log/mysql/mysqld.log ‘

Die Ursache dieses Fehlers ist, dass der mysql-root-Account – also der Administrator Account für die mysql/mariadb-Datenbank – natürlich mit einem Passwort geschützt ist. Wo muss man das eintragen ?

Der Hinweis in der Fehlermeldung ist ein wenig irreführend. Natürlich gibt es kein “/logrotate.d”-Verzeichnis. Aber sehr wohl ein Verzeichnis “/etc/logrotate.d”. Dort findet man auch die Steueranweisungen für mysql, und zwar in der Datei:

/etc/logrotate.d/mysql

In dieser Datei findet man folgenden Hinweis:

# If the root user has a password you have to create a
# /root/.my.cnf configuration file with the following
# content:
#
# [mysqladmin]
password = %Tromsoe!
user= root
#
# where “” is the password.
#
# ATTENTION: This /root/.my.cnf should be readable ONLY
# for root !

Das machte die Sache schon klarer, löste sie aber nicht, denn das .my.cnf – File war bei mir bereits korrekt vorhanden.
Also lag der Verdacht nahe, dass es noch ein weiteres rechte-Problem beim Zugriff auf das Log-Verzeichnis für MySQL selbst geben könnte.

Folgender Novell-Bugzilla-Beitrag und die darin beschriebenen Schritte lösten dann mein Problem

https://bugzilla.novell.com/show_bug.cgi?id=763150#c7

This bug seems to occur still on openSuSe 12.3. Simply
chown mysql /var/log/mysql
chmod 750 /var/log/mysql
will fix it.

Danke an den Autor Thomas Wagner !

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.