Schlagwort-Archive: Gentoo

[Gentoo] Apache 2.4.26 + WordPress: Invalid post type

Hmk? After the latest system updates on Gentoo I noticed WordPress was no longer able to open any kind of post list (“invalid post type”), edit posts (you do not have access to this kind of post) or create posts (form shown, but right sidebar missing). Not quite uncommon, but this time it was no broken plugin – I could reproduce the same behavior with several other WordPress instances with different versions – even a fresh install. That’s a new one.

After some probing around I’m fairly certain Apache 2.4.26 is the culprit, after downgrading to 2.4.25 the problem disappeared. All other downgrades like PHP 7.0.15 instead of PHP 7.0.19 didn’t show any effect. I yet have to confirm which combination ultimately triggers the error (FPM? Event-MPM?), but if you have similar errors: Here is your starting point…

ZFS/ZOL: Pool UNAVAIL nach Reboot

Nicht schön. Nach dem Reboot eines Server musste ich feststellen, dass diverse Storages nicht mehr zugreifbar waren. Schnell stellte sich heraus, dass alle ZFS-Pools offline waren und die Geräte mit der Meldung “too many errors” als FAULTED markiert wurden.

Nunja, Consumer-Platten traue ich ja viele defekte zu, aber drei unabhängige Platten gleichzeitig? Eher nein. Auch S.M.A.R.T. zeigte keine wirklich bedenkenswerten Werte. Aufschlussreicher ist da schon das Kernel-Log:

*kick* Da war ja was. ZOL läuft wegen der Lizenzproblematik als Kernel-Modul. Ich hatte zuletzt am Kernel einige Treiber nachgezogen. Hierbei sind zwar Version und Ablageort gleich geblieben, offenbar ist aber die ABI etwas gewandert, sodass SPL/ZFS etwas verwirrt den Dienst quittierten.

Für Gentoo heißt das einmal Module neu Bauen, in meinem Fall

 

Alternativ und in den meisten Fällen zuverlässiger ist es nach jeder Kernel-Änderung alle Module automatisch neu zu erstellen:

Storage online, Admins glücklich, Update-Doku ergänzt. Passt.

Gentoo: Pakete von Distcc/pump ausnehmen

Verteiltes Kompilieren mit distcc und pump macht vor allem auf langsamen Systemen eine Menge Sinn. Leider vertragen nicht alle Pakete diese Lastverteilung, so z.B. mysql/mariadb. Um einzelne Pakete von distcc oder pump auszunehmen geht man wie folgt vor:

Folgende Dateien erstellen:

Nun ggf. den Ordner /etc/portage/package.env anlegen und dort – analog zu package.use/package.keywords/… – dateien für die Pakete anlegen, z.B.

So wird z.B. für MariaDB der Pump-Modus abgeschaltet, distcc bleibt jedoch aktiv. Alternativ kann die ebenfalls erstellte no-distcc.conf verwendet werden um das verteilte Kompilieren komplett zu unterbinden.

Gentoo: OpenSSL ohne ECDHE

Unter Gentoo unterstützt OpenSSL standardmäßig kein ECDHE, welches für aktuelle Crypto kaum wegzudenken ist. Ursache sind die Lizenzbestimmungen bzw. Patente: Teile der Quellen dürfen ausschließlich als Sourcecoude verteilt werden und müssen daher aus vorkompilierten Teilen wie z.B. der Stage3 entfernt werden. Dieses entfernen wird über die USE-Flag “bindist” (Binary distribution) gesteuert, welche standardmäßig eingeschaltet ist. Um OpenSSL mit EC-Cryoto zu bauen muss bindist entfernt werden – z.B. durch ein “-bindist” in der globalen make.conf. Nach rebuild von OpenSSL und OpenSSH (sowie ggf anderer Abhängigkeiten und darauf aufbauende Software wie der Webserver) per

sollte die Crypto auch unter Gentoo verfügbar sein.

Synergy 1.7.6 (Pro) unter Gentoo nutzen

Synerwas?

Synergy ist eine Software um eine Tastatus/Maus-Kombination mit mehreren Rechnern nutzen zu können. Bewegt man z.B. die Maus am Haput-PC an den rechten Bildschirmrand steuert man fortan den danebenstehenden Laptop. Sehr praktisch, wenn man viele Systeme nebeneinander stehen hat. Alles konfigurierbar, versteht sich.

Leider hat die Software einen faden Beigeschmack: Zwar ist der Kern Open Source (GPL), wird vom Hersteller aber nur noch gegen Geld zum Download angeboten. Neue Funktionen sind ebenfalls nur noch mit DRM-online-Aktivierung verfügbar und während die Anpassung an neue Betriebssysteme soweit zügig von statten geht ist die Stabilität in meinen Augen eher auf dem absteigenden Ast.

Wie auch immer: Ich komme nicht drumrum. An einem Arbeitsplatz stehen 4 Rechner nebeneinander und ich habe keinen Nerv ständig die Tastaturen zu wechseln. Da ich dank einer Spende aus Full-Open-Source-Zeiten einen Zugang zu den Downloads habe und meine bisherige Version mit Windows 10 und Server 2016 einige Probleme hat heißt es Aktualisieren.

TLS? Proxy? WTF?

Also rauf auf die Webseite, Login-Formular ausgefüllt und … man landet auf einer HTTP-Seite. Auf der das Login-Cookie unverschlüsselt durch die Gegend geht. Great.

Weiter mit dem Windows-Setup. Installieren, aktivieren. Immerhin: Bei der Aktivierung wird offenbar die OS-API verwendet und der Request augenscheinlich per TLS mit OCSP-Abfrage über den Systemproxy übermittelt. Beim anschließenden Download der Plugins ist dann jedoch Schluss: Direktes CONNECT ohne Möglichkeit einen Proxy einzustellen. Ohne direkten Internetzugriff am Rechner also nicht viel Möglichkeiten.

Konfigurationsterror

Die Konfiguration gestaltet sich mühselig, da Dienst und GUI ständig abstürzten. Letztendlich griff ich auf den Texteditor für die Konfigurationsdatei zurück. Das ging in der Vorversion rigendwie besser. Immerhin: Im Betrieb scheint es bisher stabil zu funktionieren.

Linux? Eat my binary!

Etwas mehr Probleme hatte ich jedoch mit Linux: Im Konstrukt ist ein Gentoo-Rechner, welcher ebenfalls gesteuert werden soll. Die aktuelle Version ist dank GPL über Portage verfügbar und schnell kompiliert und installiert. Nach Eingabe meiner Zugangsdaten verwandelt sie sich nach kurzem Plugin-Download zur Pro-Version. Immerhin. Nur Verbinden geht nicht.

Auslöser ist die Pro-Version: Diese kann – im Gegensatz zum OSS-Kern – eine Verschlüsselte Verbindung zwischen den beteiligten Rechnern nutzen, sodass nicht jeder Netznutzer alle Tastenanschläge mitlesen kann. Dieses Pro-Feature ist jedoch nicht in den Quellcodes vorhanden sondern wird als “Plugin” bei der Installation heruntergeladen und in ~/.synergy/plugins/ deponiert. Plugin heißt hierbei .so-Library. In Binär. Natürlich gelinkt gegen Bibliotheken bzw. Dateinamen, die ich nicht habe.

Konkret geht es um folgende Liste:

  • linux-vdso.so.1
  • libpthread.so.0
  • libcurl.so.4
  • libSM.so.6
  • libICE.so.6
  • libXtst.so.6
  • libX11.so.6
  • libXext.so.6
  • libXinerama.so.1
  • libXrandr.so.2
  • libXi.so.6
  • libssl.so.10
  • libcrypto.so.10
  • libdl.so.2
  • libstdc++.so.6
  • libm.so.6
  • libgcc_s.so.1
  • libc.so.6
  • libidn.so.11
  • libldap-2.4.so.2
  • liblber-2.4.so.2
  • libresolv.so.2
  • libgnutls.so.28
  • libgcrypt.so.20
  • libz.so.1
  • libuuid.so.1
  • libxcb.so.1
  • libXrender.so.1
  • libtasn1.so.6
  • libnettle.so.6
  • libhogweed.so.4
  • libgmp.so.10
  • libgpg-error.so.0
  • libXau.so.6
  • libXdmcp.so.6

Die Libraries selbst sollten auf einem Desktop-System meist vorhanden sein, nachinstallieren musste ich jedenfalls bei mir nichts. Problematisch waren jedoch libssl.so.10 und libcrypto.so.10 – diese sind unter Gentoo nicht verfügbar und dürften sich auf OpenSSL mit einer Version >= 1.0 beziehen. Die Dateibenennung scheint dabei von Debian(?) zu stammen und wird bei Gentoo anders durchgeführt. Da hierdurch das Plugin nicht lädt wird es ignoriert und die Verbindung zu dem bereits eingerichteten Windows-Clients schlägt, wegen der fehlenden Cryptofunktion, fehl. Zwar erscheint dies auch im Synergy-Log, versteckt sich aber zwischen den ganzen Connect-Nachrichten und ist schnell zu übersehen:

Als Quick’n’Dirty-Workarround habe ich bei mir die angemeckerten Dateinamen als Symlink auf die echten OpenSSL-Files angelegt.

Zumindest für’s erste ist hiermit das Plugin funktionsfähig und die Software wieder nutzbar. Sonderlich schön ist es trotzdem nicht.

Gentoo dev-lang/yasm-1.2.0-r1: Segfault während compile

Narf? Segfault bei der Gentoo-Grundinstallation? Unschön. Verursacher ist dev-lang/yasm-1.2.0-r1, welches irgendwo als dependency gezogen wurde. Der Code ist dabei nicht sehr hilfreich:

Auch dmesg macht nicht viel schlauer:

Libc sollte funktionieren, alle anderen Pakete zeigten keine Fehler, aber zur Sicherheit mal neu kompilieren: Keine Änderung. Auch mein Versuch die als unstable markierte Version dev-lang/yasm-1.3.0 zu verwenden wirft die gleiche Meldung. Müssen wir wohl tiefer rein.

Erster Schritt: Handarbeit. Im passenden Ordner unter /var/tmp/Portage führe ich make selbst aus – kein Fehler. Schlecht, denn ein Fehler den man nicht reproduzieren kann, kann man auch nur schwer beheben. Also anderer Weg: In /usr/portage/dev-lang/yasm finden sich die passenden ebuilds – mit ebuild *1.2.0* compile lässt sich der Vorgang starten, mit anderen Befehlen am Ende auch selektiv einzelne Schritte durchführen. Treffer, hier tritt der Fehler auch auf. Nachdem spielen mit der make.conf (Stichwort CFLAGS, USE, …) keine Bessung zeigte bleibt dann nur ein Blick ins Innere. re2c wird aus eigenen Quellen gebaut und ist nicht mit dev-util/re2c verbunden. Ich nenne nach einem fehlgeschlagenen Compile die re2c-Binary um und lege unter selben Namen ein Script an, welches die original-Binary mit strace zur Fehlersuche aufruft:

Ergebnis:

Also hat es mit /tmp zu tun? Die Datei existiert nicht, schreibrechte sollte der Prozess auch haben. /tmp ist auf dem System nicht speziell eingerichtet, es liegt auf der root mit ext4 und rw,relatime,data=ordered. Auf anderen Systemen, welche keine Probleme haben, liegt es im RAM. Ist eventuell ext4 und dessen Funktionsumfang das Problem? Also schnell ein mount -t tmpfs -o noexec,nosuid tmp /tmp hinterher und nochmal versucht – fehlerfrei. Vermutlich fehlt in ext4 eine Dateioperation oder irgendwo kracht es beim asynchronen Betrieb zwischen löschen und neu erstellen. Warum es ohne portage/ebuild funktioniert ist dann immer noch die Frage. Wie auch immer: tmpfs stand ohnehin noch auf der Todo-Liste, worksforme.

Automatische Kicad BZR-Builds unter Gentoo

KiCad ist ein neuer, mächtiger Editor zum Entwurf von Schaltungen. Leider ist die letzte mehr-oder-weiniger-Stable, welche unter Gentoo im Portage-Tree verfügbar ist, von 2013 und lässt einige nette Funktionen vermissen. Wer mehr möchte greift üblicherweise direkt auf den Entwicklungszweig zurück, welcher in einem BZR-Repository bereitsteht. Für auf Debian und Redhat basierende Distributionen gibt es ein Installationsscript, welches sich um alle Voraussetzungen und den Build-Prozess kümmert. Für Gentoo stehen Ebuilds im Displacer-Overlay bereit. Da die Overlays bei mir nicht sauber funktionierten habe ich nebenbei™ das offizielle Script um die Gentoo-Deps erweitert. Nicht schön, aber macht das Leben leichter. Kompletter Code mit patchfile ist drüben bei gist verfügbar.

[Gentoo] Installation von dev-ruby/ffi-1.9.4 schlägt fehl

Die Installation von dev-ruby/ffi-1.9.4, welches als Dep gezogen wurde, machte auf einem Server Probleme. Unter anderem war folgende Meldung zu lesen:

cannot load such file -- rspec/core/rake_task

Woher die Anforderung kam oder warum keine Dep da ist konnte ich nicht direkt sehen, ein manuelles Installieren von dev-ruby/rspec sollte jedoch die nötigen Voraussetzungen schaffen um das Kompilieren zu ermöglichen.