Author Archives: Ralph Mönchmeyer

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

Posted on by

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

Posted on by

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

Posted on by

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 !