phpmyadmin 4.6.4 ist buggy – nicht für Sicherungen verwenden !

Ich hatte heute die Aufgabe, die Daten eines WordPress-Blogs von der MySQL-Datenbank eines Hosting Providers zu sichern und den Blog dann auf eine neue Datenbank bei einem anderen Provider umzuziehen. Dabei hat ein übler Bug in der phpMyAdmin-Version 4.6.4 etliche meiner Nerven verschlissen:

Auf Exports von Tabellen mit Kommentaren oder Spalten mit bestimmten HTML-Inhalten kann man sich bei der aktuellen Version (Stand 03.10.2016) leider nicht verlassen; der nachfolgende Import scheitert unter Umständen – vermutlich wegen einer fehlenden oder fehlerhaften Maskierung von Anführungszeichen.

Es dauerte aber eine ganze Weile, bis ich anfing, der Exportfunktion von phpMyAdmin zu misstrauen – vor allem, weil mir bei dem Provider keine Datenbank-Logs zur Verfügung standen. Ich konnte den Fehler aber an einer reduzierten “posts”-Testtabelle der WordPress-Installation nachvollziehen; der Export und nachfolgende Import schlägt mit der Version 4.6.4 reproduzierbar fehl – in meinem Fall sogar mit einem internen Server-Error.

Gott sei dank war die alte Datenbank noch nicht gelöscht! Ich konnte den Export/Import-Vorgang mit der auf die Schnelle installierten phpMyAdmin-Version 4.4.15.8 anschließend anstandslos und fehlerfrei durchführen.

Solche Bugs können üble Folgen haben, wenn man nach einer “Sicherung” naiverweise den alten Datenbank-Zustand löscht, ohne vorher an einer anderen Datenbank den Reimport getestet zu haben. Auch für phpMyAdmin gilt bei Sicherungen die alte Regel:
Immer erst die ganze Kette zur Restaurierung testen, bevor man irgendetwas löscht!

Dennoch: So ein Bug ist wirklich übel! Ich bin ein wenig sauer …. im Nachhinein fand ich dann unter github folgende Bug-Einträge:
https://github.com/phpmyadmin/phpmyadmin/issues/12086
https://github.com/phpmyadmin/phpmyadmin/issues/12453
Der erste davon wurde geschlossen, obwohl er offenbar immer noch oder wieder vorhanden ist.

SSH – Qt5-Anwendungen – KDE/Plasma 5 – falsche Fonts und fehlende Icons

Wenn man sich unter KDE 5 mit
“ssh -X remoteuser@sshhost
auf einem Host “sshhost“einloggt und dann Qt5-Anwendungen startet, werden die in der Regel nicht richtig angezeigt: Es fehlen Icons und die Fonts sind falsch.
(“remoteuser” und “sshhost” sind im Beispiel natürlich nur Dummy-Bezeichnungen, die durch richtige Werte ersetzt werden müssen.)

Ursache des Darstellungsproblems:
Qt5-Applikationen suchen die Einstellungen der aktuell laufenden Desktopumgebung – im Beispiel also auf auf dem per SSH angesprochenen Host “sshhost”. Dort wird aber KDE nicht erkannt, weil eine Umgebungsvariable nicht gesetzt ist, die normalerweise beim Start der Desktop-Umgebung belegt wird. Dort läuft ja aber für die ssh-Shell gar kein Desktop.

Ich hatte das Problem schon mal behandelt – allerdings für root-Shells und lokale Starts von Qt5-Anwendungen auf ein und demselben System (siehe https://linux-blog.anracom.com/2016/01/27/opensuse-leap-42-1-kde-5-unzureichende-darstellung-und-kleine-fonts-in-qt5-anwendungen-die-von-root-gestartet-werden/).

Die gleiche Thematik verfolgt einen aber natürlich auch in Shells, die mit SSH geöffnet werden.

Lösungsansatz:
Man kann der SSH-Sitzung die notwendige Umgebungsvariable am Prompt nachliefern. Nämlich über:

remoteuser@sshhost:~>export XDG_CURRENT_DESKTOP=KDE

Erfolgte die SSH-Sitzung aus einem Gnome-Desktop heraus, so wählt man natürlich eher:

remoteuser@host:~>export XDG_CURRENT_DESKTOP=GNOME

Arbeitet man lokal und remote grundsätzlich nur unter KDE, so kann man die Einstellung

export XDG_CURRENT_DESKTOP=KDE

auch in der Datei “~/.profile” verankern. Die Umgebungsvariable wird dann für alle Login-Sitzungen gesetzt.

Arbeitet man allerdings nicht nur remote auf dem Host “sshhost” und wechselt man dort (!) gelegentlich zwischen KDE und Gnome, so ist wohl eine vorherige Abfrage in der “~/.profile” sinnvoller – und man entscheidet sich nur im Zweifel für KDE:

[ “$XDG_CURRENT_DESKTOP” = “KDE” ] || [ “$XDG_CURRENT_DESKTOP” = “GNOME” ] || export XDG_CURRENT_DESKTOP=KDE

Bessere interaktive Lösung:
Man verankert in der “~/.profile” für den Fall einer SSH-Verbindung eine interaktive Abfrage, die den SSH-Nutzer festlegen lässt, welche Desktop-Umgebung den anschließend gestarteten Qt5-Anwendungen vorgegaukelt werden soll. Die entsprechende Desktop-Umgebung muss auf dem SSH-Host natürlich vom User konfiguriert worden sein.

Der Aufbau eines entsprechenden Shellskripts ist eine nette kleine Übungsaufgabe, bei deren Lösung ggf. folgender Link weiterhilft:
http://unix.stackexchange.com/questions/9605/how-can-i-detect-if-the-shell-is-controlled-from-ssh

Nachtrag 01.11.2016: SSH, KDE und User root

Will man aus irgendwelchen Gründen für den User “root” über SSH grafische Anwendungen starten, so nützt im Gegensatz zur Situation in einer bereits laufenden grafischen KDE-Umgebung nichts, einfach “kdesu …” zu benutzen. Wir hatten dieses Vorgehen im Artikel Opensuse Leap 42.1 / KDE 5 – unzureichende Darstellung (kleine Fonts, fehlende Icons) von Qt5-Anwendungen, die von root gestartet werden empfohlen. Ist eine SSH-Shell dazwischengeschaltet, so muss die oben erläuterte Umgebungsvariable vor Anwendung des “kdesu”-Befehls für eine grafische Qt5-Anwendung
explizit gesetzt werden.

CPU Kühler Alpenföhn Brocken 2 – Empfehlung für Linux Workstations

ich hatte letzte Woche eine neue Linux-Workstation für eine Kunden aufzusetzen. Dabei kam ein i7-6700K-Prozessor von Intel zum Einsatz. Auf der Suche nach einem passenden Lüfter blieb ich dann beim Brocken 2 (siehe http://www.alpenfoehn.de/cpu-kuehler/brocken-2) hängen; nicht zuletzt aufgrund seines Preises.

Nach ersten Eindrücken möchte an dieser Stelle eine Empfehlung aussprechen:

Ich hatte noch nie so niedrige CPU-Temperaturen in irgendeinem von mir gebauten PC-System ( ca. 32° Celsius CPU-Temperatur im Linux-Normalbetrieb (Lüfter auf 640 U/min; aktive Anwendungen: Libreoffice / Kontact / VMware mit Win7/ 2xKVM mit Linux-Systemen). Im völligen Leerlauf (obwohl es sowas unter Linux ja nicht gibt) erreicht man je nach Umdrehungszahl des Lüfters deutlich unter 26° Celsius; das hängt von der Umgebungstemperatur und in meinem Fall auch von den vorgegebenen Lüfterprofilen des UEFI-Bios ab). Bei leichtem Overclocking und Annäherung an Vollast ergab sich folgendes Bild: 8 CPU-Threads bei 99% führen zu maximal 70&deg Peaks bei ca. 1110 U/min; Celsius bei ca. 22° Raumtemperatur (erreicht durch x-faches Starten von glxspheres).

Der Kühler erfüllt seine Aufgabe also gut – auch wenn man, wie ich, nur die einfache Variante mit einem Lüfter wählt. Der Brocken 2 lässt sich bei Bedarf immer noch auf 2 Lüfter aufstocken.

Aber:
Der Kühler ist mit seinen physikalischen Dimensionen ein wahres Monster! Ich empfehle jedem, die Dimensionsangaben (http://www.alpenfoehn.de/images/Produkte/Abmessungen/AbmessungenBrocken2.pdf)vor einem Kauf genau zu studieren und mit dem Platz im Gehäuse zu vergleichen; die Bauhöhe von 16,5 cm ist mit der Breite des Gehäuses zu vergleichen – und bitte ab CPU-Oberfläche messen! Auch sollte man sich mit dem Abstand des ersten RAM-Steckplatzes vom CPU-Sockel befassen. Ebenso wichtig: Je nach Mainboard liegt der erste PCIE-Steckplatz so hoch, dass es zu einer Kollision mit dem Kühlkörper kommen kann.

Ich kann im Moment nur über das in den Kunden-PC verbaute Board reden: Ein AsRock Z170 Extreme7. Da sind die Abstände in Richtung RAM und PCI-E-Steckplatz gerade so ausreichend – wir reden aber in beiden Fällen über weniger als 1 mm. Das ist bei Platinen mit hohen Lötstellen am ersten PCI-E2.0 x1-Steckplatz bereits kritisch; die Rippen des Kühlkörpers sind da gefährlich nah. Ich habe den PCI-Slot freigelassen. Zwischen der Oberkante des ersten RAM-Moduls (G.Skill D464GB 3200-14 Ripjaws V Black K4 GSK) und dem Kühlkörper ist ein winziger Schlitz gerade noch zu erahnen.

20160930_190310_400

Aufzupassen sollte man auch bzgl. der Richtung des Luftstroms. In dem vom Kunden vorgegebenen Gehäuse wird Luft von vorne angezogen und nach hinten abgeführt. Der Lüfter sollte dann so verbaut werden, dass er nicht gegen den Luftstrom arbeitet – in unserem Fall musste der Lüfter wie auf der Alpenföhn-Webseite abgebildet ( siehe: http://www.alpenfoehn.de/images/Produkte/Bilder/Brocken2/Brocken2_91.jpg) montiert werden; mit der Blasrichtung in den Kühlkörper-Aufbau hinein.

20160930_190518_400

(Die gelbliche Farbe in dem von mir gemachten Bild ist nur ein Reflex einer Lampe; der Kühlkörper ist in Wirklichkeit silbern.)

Plus:

  •  + Sehr
    gute Kühlleistung.
  •  + Praktisch unhörbar – auch wenn der Lüfter mal auf Vollast drehen sollte. (Was ich aber bislang trotz Auslastung von 8 Threads bei normalem Luftstrom im Gehäuse und Standard-Lüfterprofil des BIOS noch nicht erzwingen konnte.)
  •  + Der Kühlturm ist gegenüber der CPU leicht nach hinten versetzt ausgerichtet, so dass zum Bereich der der RAM-Steckplätze in der Regel noch etwas Platz bleibt – minimal, aber es reicht.
  •  + Flexibilität im Bereich von etwa einem halben Zentimeters bzgl. der Höhe, in der der Lüfter am Kühlkörper angebracht werden kann (das kann einem bei hohen RAM-Modulen vor Kollisionsproblemen mit dem RAM schützen).
  •  + Aus meiner Sicht preiswert!

Minus:

  • Die großen Dimensionen des Kühlkörpers sind ein Nachteil – das Teil passt mit seiner Bauhöhe sicher nicht in jedes Gehäuse. Auf manchen Mainboards mag es zu Platzproblemen in Richtung RAM oder PCIE-Steckplätze kommen.
  • Der Einbau selbst ist ein wenig hakelig. Bzgl. des Anziehens der Schrauben für die Befestigung des tragenden Gerüsts am Mainboard sollte man ein wenig aufpassen. Im Gegensatz zu den Abbildungen in der Einbauanleitung gilt: Die Klemmen für den Lüfter sind seitlich (!) und nicht oben/unten am Kühlkörper zu befestigen!

Viel Spaß ansonsten mit diesem CPU-Kühler, der im Gegensatz zu einem Alpenföhn Wärme nicht zu- sondern abführt !

Apache Rewrite für zwei Domänen, die gemeinsame Datei-Ressourcen nutzen

Gestern wurden wir mit zwei Websites konfrontiert, die wir um einen Blog ergänzen sollten. Die Webserver-Installation, die wir vorfanden, war interessant und hat uns ein wenig beschäftigt:

Zwei Domain-Namen (alpha.de und beta.de) waren beim Hosting-Provider mit ein und demselben Webserver-Verzeichnis verbunden. Dieses wiederum wies zwei Unterverzeichnisse auf, in denen sich vor allem HTML-Seiten zu den verschiedenen Domänen befanden. Die Idee hinter diesem Setup war wohl, von den Webseiten beider Domänen aus gemeinsame Datei-Ressourcen im Hauptverzeichnis zu nutzen.

Setup zur Nutzung gemeinsamer Datei-Ressourcen durch zwei Web-Domänen auf demselben Webserver

Nennen wir das Hauptverzeichnis mal dir_domains und die Subverzeichnisse dir_alpha und dir_beta.

Die Webseiten von alpha.de und beta.de nutzen gleiche Datei-Ressourcen (CSS-Dateien, Javascripts, PHP-Programme, …). Entsprechende Verzeichnisse fanden sich unter dir_domains:

dir_domains (Webserververzeichnis für Domains alpha/beta)
|__css
|__js
|__php
|__index.php
| ….
|
|__dir_alpha
|        |__index.html
|        |…(HTML-Dateien für die Domäne beta.de)
|        | ….
|__dir_beta
         |__index.html
         |… (HTML-Dateien für die Domäne beta.de)
         |…

Die Datei index.php übernahm die Zugangssteuerung für die Startseiten: Je nach Domain-Anforderung (alpha.de oder beta.de) des Users wurde dieser auf die jeweilige Index-Seite unter dir_alpha oder dir_beta umgelenkt. So weit, so gut – oder eher so schlecht ….

Nach Inaugenscheinnahme der beiden Domänen im Internet war mir klar, warum das so aufgesetzt worden war:

Die Webseiten unter alpha.de bzw. beta.de haben einen ganz ähnlichen Aufbau und nutzen gleiche PHP-Programme und Scripts. Da bei der Anforderung von Ressourcen wie CSS-/JS-/PHP-Dateien Domaingrenzen in der Verzeichnisstruktur des Web-Servers normalerweise nicht überschritten werden dürfen, waren die Web-Designer gezwungen gewesen, beiden Domänen dasselbe Hauptverzeichnis des gehosteten Webserver-Accounts zuzuweisen. Zur Kompensation musste eine Art Umlenkung auf die jeweiligen Verzeichnisstrukturen integriert werden. (Anmerkung am Rande: Die Domängrenzen, im Sinne von Verzeichnisgrenzen, gelten übrigens nicht für Include-Dateien, die in PHP-Programmen nachgeladen werden. Solche Include-Dateien kann man ruhig oberhalb des Domainverzeichnisses unterbringen!).

Was war am Setup schlecht?

Während die Nutzung gemeinsamer Ressourcen durchaus zu befürworten ist, war die “Umlenkung” durch das PHP-Skript schlecht gelöst. Sie funktionierte eigentlich nur für den Aufruf einer der beiden Domän-Namen selbst (Umlenkung auf die jeweilige index.html-Seiten). Die Navigation innerhalb der Webseiten einer Domäne war über relative Pfade gelöst; sobald ein User sich einmal innerhalb einer Domäne bewegte, funktionierte deshalb alles aus Nutzersicht alles bestens.

Aber: Der Aufruf einer spezifischen Seite einer Domäne über eine direkte Eingabe in die Adresszeile des Browsers – z.B. http://alpha.de/infos/impressum.html – funktionierte mit dem vorhandenen PHP-Script nicht. Das Script index.php kümmerte sich nur um die Index-Seiten der Domänen. Es wurde als Index-Datei ja nur dann aktiv, wenn eine der Domän-Adressen alpha.de oder beta.de ohne weitere Zusätze im Browser
aufgerufen wurde.

Lösungsansatz über Apache Rewrite

Bei dem gehosteten Webserver handelte es sich um einen Apache-Server. Eine saubere Lösung für den gewünschten Setup-Ansatz mit geteilten Datei-Ressourcen besteht dann natürlich darin, das Apache Rewrite-Modul (mod_rewrite) zu nutzen. Die Servereinstellungen beim Provider waren so, dass die Rewrite Engine über lokale “.htaccess”-Dateien aktiviert und gesteuert werden konnte. Wir haben dann folgenden einfachen Vorschlag umgesetzt:

Inhalt der .htaccess-Datei für das Verzeichnis dir_domains:

Options +FollowSymLinks 
RewriteEngine On 
RewriteBase /

RewriteRule ^alpha/(.*)$ - [L]
RewriteRule ^beta/(.*)$ - [L]

RewriteRule ^css/(.*)$ - [L]
RewriteRule ^images/(.*)$ - [L]
RewriteRule ^php/(.*)$ - [L]
RewriteRule ^script/(.*)$ - [L]

RewriteCond %{SERVER_NAME} alpha.de [OR]
RewriteCond %{SERVER_NAME} www.alpha.de
RewriteRule ^$ alpha/index.html [L]

RewriteCond %{SERVER_NAME} alpha.de [OR]
RewriteCond %{SERVER_NAME} www.alpha.de
RewriteRule ^(.*)$ alpha/$1 [NC,L]

RewriteCond %{SERVER_NAME} beta.de [OR]
RewriteCond %{SERVER_NAME} www.beta.de
RewriteRule ^$ beta/index.html [L]

RewriteCond %{SERVER_NAME} beta.de [OR]
RewriteCond %{SERVER_NAME} www.beta.de
RewriteRule ^(.*)$ beta/$1 [NC,L]

 
Die ersten 2 Rewrite-Regeln sorgen dafür, dass keine Umlenkung mehr vorgenommen wird, wenn man sich bereits im Verzeichnisbereich der Seite befindet. Dieser Vorspann ist wichtiger, als man meinen möchte: die nachfolgenden Regeln würden für sich allein zu einer unbegrenzten Iteration von Rewrites führen!

Die nächsten 4 Regeln sorgen dann dafür, dass Verweise auf die gemeinsam genutzten Ressourcen-Verzeichnisse und zugehörige GET-Anforderungen an den Server unangetastet bleiben. Diese Verzeichnisse werden ja aus dem HTML-Code der Webseiten unter dem alpha- bzw. dem beta-Sub-Verzeichnis referenziert; z.B. über relative Pfade.

Danach kommen die eigentlichen Umlenkungsregeln. Wir haben hier die Grundregel befolgt, dass eine oder mehrere Rewrite Conditions sich nur und ausschließlich auf die nächste Rewrite Rule beziehen – also auf genau eine Rewrite Rule! Das wird in der hektik oft übersehen; es gibt keine native Klammerung mehrerer Rewrite Rules zu Rewrite Conditions. Allerdings kann man mit Negationen der Bedingungen und Skip-Zusätzen hinter den Rewrite-Regeln tricksen. Um das Verständnis nicht zu erschweren, haben wir hier auf solche Hacks verzichtet.

Wird keine Dateiname angegeben – ist also der Pfad hinter dem Domain-Anteil leer – wird auf die jeweilige Index-Seite umgelenkt. Sind konkrete Webseiten einer Domäne angefordert, wird auf die gewünschte Datei im jeweiligen Unterverzeichnis verwiesen.

Das war es schon; die Datei index.php kann und sollte danach gelöscht werden. Unser Kunde kann nun 2 Domänen im gleichen Webserververzeichnis nutzen und zwischen beiden Implementierungen gemeinsame Ressourcen teilen. Eigentlich eine nette kleine Geschichte, die ich vielleicht auch mal für eigene Sites nutzen werde – Apache sei Dank!

VMware Workstation WS 11 unter Opensuse Leap 42.1

Habe heute ein Upgrade eines Opensuse 13.1-Systems auf Opensuse Leap 42.1 durchgeführt. Das ging – bis auf einige typische OS 42.1-Probleme, die ich bereits an anderer Stelle in diesem Blog beschrieben habe, ganz gut.

Gestolpert bin ich dann allerdings über ein Problem mit der VMware-Workstation. Die auf dem fraglichen System installierte Version war WS 11.1.0.

Da sich der Kernel gegenüber der Version von 13.1 inzwischen natürlich massiv verändert hatte (aktuelle Leap42.1-Kernelversion 4.1.27), führte der Versuch VMware WS zu starten, zu einer automatisch eingeleiteten Neu-Kompilation der wichtigsten VMware-Module. Dieser Kompilationsversuch scheitert aber leider an dem vmnet-Modul; nachfolgend ein Auszug aus der Log-Datei:

2016-09-26T14:13:52.987+02:00| vthread-4| I120: Successfully extracted the vmnet source.
2016-09-26T14:13:52.987+02:00| vthread-4| I120: Building module with command “/usr/bin/make -j8 -C /tmp/modconfig-jZLoM6/vmnet-only auto-build HEADER_DIR=/lib/modules/4.1.31-30-default/build/include CC=/usr/bin/gcc IS_GCC_3=no”
2016-09-26T14:13:54.615+02:00| vthread-4| W110: Failed to build vmnet. Failed to execute the build command.
….
2016-09-26T14:14:12.914+02:00| vthread-4| I120: Read 17587 symbol versions
2016-09-26T14:14:12.914+02:00| vthread-4| I120: Invoking modinfo on “vmmon”.
2016-09-26T14:14:12.919+02:00| vthread-4| I120: “/sbin/modinfo” exited with status 0.
2016-09-26T14:14:12.919+02:00| vthread-4| I120: Invoking modinfo on “vmnet”.
2016-09-26T14:14:12.924+02:00| vthread-4| I120: “/sbin/modinfo” exited with status 256.
2016-09-26T14:14:13.334+02:00| vthread-4| I120: Setting destination path for vmnet to “/lib/modules/4.1.31-30-default/misc/vmnet.ko”.
2016-09-26T14:14:13.334+02:00| vthread-4| I120: Extracting the vmnet source from “/usr/lib/vmware/modules/source/vmnet.tar”.
2016-09-26T14:14:13.344+02:00| vthread-4| I120: Successfully extracted the vmnet source.
2016-09-26T14:14:13.344+02:00| vthread-4| I120: Building module with command “/usr/bin/make -j8 -C /tmp/modconfig-sDUVWe/vmnet-only auto-build HEADER_DIR=/lib/modules/4.1.31-30-default/build/include CC=/usr/bin/gcc IS_GCC_3=no”
2016-09-26T14:14:14.951+02:00| vthread-4| W110: Failed to build vmnet. Failed to execute the build command.

Dieses Problem lässt sich beheben, ohne gleich für teures Geld auf die WS 12 upgraden zu müssen. Es handelt sich nämlich um einen Fehler, der in einer späteren Version behoben wurde.

Kurz gesagt: Version 11.1.4 der WS runterladen => Installieren => VM-Ware WS auch unter Opensuse Leap 42.1 weiter betreiben !