Schlagwort-Archive: PHP

Herbstputz in doppeltem Sinne

Manchmal zieht sich der Frühlingsputz in den Herbst hinein, so war es in diesem Falle in Punkto Server-Putz der Fall. Am gestrigen Tage habe ich nun das Upgrade auf Debian 12 „Bookworm“ vorgenommen, das äußerst reibungslos lief. Nicht eine Sache hat gehakt, das sieht man als Admin auch selten – gute Arbeit, Debian-Crew! 🙂 Im gleichen Zuge habe ich dann spontan noch PHP von 8.1 auf 8.2 geupgradet, auch das lief ohne Probleme und die eingesetzten Scripte kommen ausgenscheinlich gut damit klar, perfekt. Das einzig etwas aufwändigere war das Grafana Update, da hat sich im Laufe der letzten Versionen dann doch etwas getan, aber auch das ließ sich gut in den Griff kriegen und läuft nun wieder in der aktuellsten Version.
Am heutigen Tage habe ich schließlich noch die Initiative ergriffen und geschaut, ob sich das Mailpostfach mit wenig Aufwand etwas entrümpeln lässt. Und siehe da: alleine durch die Löschung der durch Tripwire erzeugten Mails (habe ich aktuell ohnehin nicht mehr im Einsatz und rückwirkend werden diese nicht mehr benötigt) konnten unglaubliche rund 75 GB auf den Datenfriedhof wandern. Damit sinkt die aktuelle Mailbox Größe von knapp über 100 auf knapp unter 25 GB – das hat sich gelohnt 😀
Hier im übrigen ein hoch auf Thunderbird, das hab ich gestern mal wieder in der neusten Version eingerichtet. Die neue UI finde ich richtig schick und der Donnervogel scheint tatsächlich wieder eine moderne und interessante Wahl zu sein 🙂
In diesem Sinne: Itsumo kirei ni sōji shite kudasai („Allzeit gut putz“ auf japanisch, zumindest laut Google 😀 ).

Upgrade auf PHP 8.1 abgeschlossen

Zugegeben, das Upgrade auf die PHP 8.x Schiene hat diesmal etwas länger gedauert als vorangegangene Updates, aber bis zuletzt gab es kleinere „Sorgenkinder“ wie das genutzte Status Page Script Cachet. Letzteres wird aktuell nicht mehr aktiv weiterentwickelt, so schnell wird eine PHP 8 kompatible Version also nicht auftauchen. Dennoch sollte das natürlich nicht vom Umstieg abhalten – und so habe ich das Status Page Script erst einmal durch eine relativ statische Seite ersetzt 🙂
Der übrige Wechsel ging ausgesprochen problemlos vonstatten. Gängige Scripts wie WordPress, phpBB oder Nextcloud kommen mit PHP 8.1 zurecht, nur die eingesetzten Plugins können zur Stolperfalle werden. Hier hatte ich allerdings Glück, bis auf ein kleines Kompatibilitätsproblem bei einem phpBB Plugin scheinen die übrigen WordPress und phpBB Plugins mit der neuen Version zurecht zu kommen.
Und so beschränkte sich das Upgrade auf die Zusammenstellung der notwendigen configure Parameter (und ein Cleanup alter 😀 ) sowie einer kleinen Anpassung der Apache Konfiguration.
Damit hat das Upgrade auf die neuste Version doch noch just in time vor dem End of Life der PHP 7.4 Reihe geklappt 🙂

PHP 7.4 am Start

Nachdem das letzte große PHP Upgrade auf meinem Server (zum damaligen Zeitpunkt auf PHP 7.2) schon vor rund 1,5 Jahren erfolgte, wurde es langsam Zeit für ein Upgrade auf die letzte stabile Version 7.4. Diesen Schritt hatte ich schon früher eingeplant, allerdings ist es immer so eine Sache mit der Kompatibilität der eingesetzten Anwendungen auf PHP-Basis. Zuletzt haben die frischen neuen Versionen des phpBB (3.3) und von Nextcloud (18) aber für die notwendige Unterstützung der aktuell empfohlenen PHP Version gesorgt, sodass einem Upgrade nun endgültig nichts mehr im Wege stand. Das Upgrade gestaltete sich durchweg unproblematisch, bis auf kleinere Änderungen bei den configure-Flags lief der Umstieg reibungslos. Auch Cachet kommt im aktuellen 2.4er Branch (der noch nicht stabil ist) unter PHP 7.4 zurecht, dasselbe gilt augenscheinlich auch für GNU Social, obwohl es schon seit längerer Zeit nicht mehr aktiv weiterentwickelt wird.
Mit dem nächsten Sprung auf PHP 8.0 mag das ganze anders aussehen, aber bis dahin bleibt ja noch etwas Zeit. Für den Moment ist wieder alles up-to-date 🙂

Upgrade auf Debian Stretch 9.0 geglückt

Im zweiten Anlauf ist mir in der vergangenen Nacht das Upgrade des Servers auf Debian Stretch geglückt. Damit ist etwas mehr als eine Woche nach dem Release von Debian Stretch die Hauptarbeit bereits abgeschlossen. Grundsätzlich habe ich direkte Upgrades auf die Nachfolgeversion von Debian bislang gemieden und stets auf eine (meistens deutlich spätere) Neuinstallation gesetzt. Auch diesmal stand dieser Weg bei mir ganz oben auf der Liste, allerdings habe ich mich dann doch relativ schnell für das Upgrade umentschieden – auch nachdem erste Berichte von einem grundsätzlich relativ reibungslosen Prozess berichteten. Bei vergangenen Debian Upgrades sah das zum Teil noch anders aus.
Das eigentliche Systemupgrade lief bei mir am problemlosesten, großartige Auseinandersetzungen mit Abhängigkeiten traten nicht zu Tage. Konfigurationsdateien diverser genutzter Pakete habe ich vorerst beibehalten und werde diese ggf. zu einem späteren Zeitpunkt gegenüber neuen Versionen vergleichen. Kritische Änderungen, die eine sofortige Aktion erfordern würden, gab es bei diesen nicht. Dies betraf vor allem Postfix und Dovecot, sodass der Mailserver auch weiterhin gewohnt seinen Dienst ohne direkten Eingriff verrichtet.
Apache und PHP kompiliere ich auf dem Server stets selbst, der Neueinstieg von OpenSSL 1.1 in Debian Stretch hat mir hier vor allem bei Apache das erste Problem beschert. Die kürzlich erschienene Apache Version 2.4.26 ist die erste, die OpenSSL 1.1 offiziell unterstützt – alles darunter führt zwangsläufig zu Frustrationen. Wichtig ist also, gleich die neuste Version zu wählen. Die aktuelle PHP Version 7.1.6 ist ebenfalls OpenSSL 1.1 kompatibel, auch wenn bei der Kompilierung noch einige Warnungen ausgespuckt werden. Die PHP Erweiterung curl erfordert zudem noch das Paket libcurl4-openssl-dev. Hier benötigt es dann noch einen Symlink, damit der Konfigurationsvorgang ohne Fehler durchläuft.
Das reguläre Upgrade auf Stretch betrifft vor allem bisherige Nutzer von MySQL, sofern die entsprechenden Debianpakete genutzt werden. Während des Upgrades findet dann ein automatischer Umstieg auf MariaDB statt. Mich hat dies nicht betroffen, da ich MySQL separat installiert habe. Die zugehörige MariaDB Library scheint zudem größtenteils MySQL-kompatibel zu sein, sodass sich auch Dovecot und Postfix daran nicht aufhängen. PHP nutzt über mysqlnd sowieso seine eigene MySQL-Library.
Der größte sichtbare Benefit mit dem Umstieg auf Debian Stretch war für mich die Möglichkeit, das HTTP/2 Modul des Apache Webservers zu aktivieren. Unter Debian Jessie war dies ohne Fallstricke nicht möglich, da die dortige OpenSSL Version und nötige libnghttp2 Bibliothek zu alt waren. Beides hat sich nun gelöst, sodass nach der Nachinstallation des libnghttp2-dev Pakets und anschließenden Kompilierung HTTP/2 final aktiviert werden konnte. Damit ist auch dieser letzte große Punkt auf der ToDo Liste verschwunden 🙂
Im Großen und Ganzen ist das Upgrade unter dem Strich also sehr weich verlaufen. Eine Neuinstallation hätte da weitaus mehr Zeit und Planung beansprucht. Auch wenn noch kleinere Nacharbeiten anstehen: der größte Teil ist geschafft und der Server damit für die nächste Zeit wieder auf dem aktuellsten Stand. Danke, liebes Debian Team!

Finally: PHP 7.1 auch hier

Vor zwei Wochen war es endlich soweit: nach Monaten der Gespanntheit erschien die finale phpBB Version 3.2. Diese fällt nicht ganz so spektakulär wie die vorangegangene 3.1 aus, doch das kleine aber dennoch wichtigste Detail verbirgt sich wie so oft im Hintergrund – phpBB 3.2 ist nun vollständig PHP 7 kompatibel!
Das war Anlass genug, das notwendige Upgrade des Blue X Forums bereits am vergangenen Wochenende (problemlos) durchzuführen.
Nachdem damit auch das letzte Script PHP 7 Kompatibilität aufwies, konnte im nächsten Schritt der Umstieg auf PHP 7 angegangen werden. Ende 2016 ist zudem bereits PHP 7.1 erschienen, sodass ich direkt den Wechsel auf PHP 7.1.0 gewagt habe. Bislang ohne offensichtliche Fehler, so darf ein Wechsel gerne öfter ablaufen 😀
Sollten Euch dennoch an irgendeiner Stelle Ungereimtheiten auffallen, bitte in den Kommentaren vermerken – danke! 🙂

Yella Entwicklung wieder aufgenommen

„Alle Versionen wieder kommt die Pausenzeit“ – das könnte man so ohne Zweifel unterschreiben. Nachdem die letzte Yella Version schon gefühlte Jahre alt ist, habe ich heute mit der Entwicklung der nächsten Version begonnen. Das Schöne ist, dass ein solches Hobbyprojekt immer dann da ist, wenn Bedarf danach besteht. Nach dem Beziehungsende vergangene Woche ist das eine tolle Möglichkeit, um etwas abzuschalten. Das Leben muss weitergehen – und die Entwicklung darf das ruhig auch. Die erste Änderung ist bereits in die Versionsverwaltung eingecheckt und auch eine der Tabellen wurde prompt mit einem Optimize zerschossen.

Zerschossene Tabelle
Zerschossene Tabelle

Glücklicherweise konnte ich diese kurzerhand per phpMyAdmin wieder von der produktiven Version in die Entwicklungsversion duplizieren. Bis zur endgültigen neuen Version gibt es noch viel zu tun, aber gerade bei einem Hobbyprojekt gilt: it’s done when it’s done – the most important thing is that it’s fun! 🙂

ob_gzhandler Bug in PHP 5.4.4

Mein freudestrahlender Beitrag auf Facebook über das erfolgreiche Serverupgrade wurde von Stefan aka xxoun heute wie folgt kommentiert:

versprochen, bald isses mit den glücksmomenten auch schon wieder vorbei 😉

Wie recht er doch hatte, der erste Bug in der neuen PHP Version ist schon gefunden. Erst geschah es beim Aufruf des phpBB3 ACP, dann im WordPress Backend: die Seiten wurden entweder nicht richtig dargestellt oder es kam gleich eine Fehlermeldung mit Hinweis auf den ob_gzhandler. Nach einer kurzen Recherche ist klar, dass der Fehler eindeutig in PHP 5.4.4 begründet liegt (siehe https://bugs.php.net/bug.php?id=62335). Hoffen wir, dass er in der nächsten Version wieder behoben wird (scheinbar war er bereits behoben, wurde dann aber wieder „integriert“). Bis dorthin hilft der folgende Workaround über die .htaccess:

php_flag zlib.output_compression Off

Upgrade auf Apache 2.4 und PHP 5.4

Das Apache 2.4 und PHP 5.4 vor wenigen Monaten relativ zeitlich gleich erschienen sind, hatte Synergieeffekte zur Folge: das Upgrade auf die beiden neuen Versionen konnte miteinander verbunden werden. Im Grunde genommen hatte ich bereits im April vor das Upgrade vorzunehmen, habe es letztendlich aber bis zum heutigen Tage immer wieder vor mir hergeschoben. Wenn man einige Ursprungsbugs betrachtet, war diese Entscheidung vielleicht gar nicht mal so verkehrt. Die Zeit währenddessen habe ich zudem dazu genutzt, mich über mögliche Probleme schlau zu machen, sodass ich für den heutigen Tag relativ gut gerüstet schien.
Die beiden Hauptkonfigurationsdateien httpd.conf und die php.ini habe ich von den neuen Versionen übernommen und an meine bisherige Konfiguration per WinMerge angepasst. Natürlich haben beide neue Versionen in ihren jeweiligen Konfigurationsdateien Spuren hinterlassen, insgesamt lässt sich jedoch sagen, dass diese glücklicherweise relativ undramatisch ausfielen und durch Kompatibilitätsmodule wie z.B. mod_access_compat abgefedert werden konnten. Am eigentlichen Kompilierungsvorgang änderte sich auch wenig.
Und so startete die neue Generation der Webserverumgebung am Schluss nach wenigen kleinen Fehlern problemlos. Damit dürfte für die nächsten Monate wieder Ruhe einkehren, der große Wechsel ist geschafft 🙂
In den nächsten Monaten gilt nun der Hauptaugenmerk den PHP Scripts, die teilweise noch nicht ganz an PHP 5.4 angepasst sind. Wenn ihr irgendwo den ein oder anderen Fehler entdecken solltet, würde ich mich über eine kleine Mitteilung freuen. Vielen Dank! 🙂

PS: Man sollte natürlich Monitoring-Systeme vor geplanten Wartungsarbeiten abschalten, um nicht unnötig an SMS Nachrichten zu gelangen. Hinterher ist man immer schlauer 😀

mysqlnd – ein Segen!

Auf mysqlnd bin ich ehrlich gesagt auch erst kürzlich durch eine Surftour auf php.net gestoßen. Ich habe mich heute dann aber relativ spontan dafür entschieden, PHP mit mysqlnd nochmals neu zu kompilieren. Neben dem Hauptvorteil, dass man nicht mehr auf die jeweils installierte MySQL Client Bibliothek kompilieren muss (yeah, keine Hinweise mehr!) hat es bei mir auch eine kleine Lästigkeit beseitigt. Obwohl ich als MySQL Socket Pfad /tmp/mysql.sock an allen möglichen Stellen angegeben hatte, haben einige wenige Skripte weiterhin in /var/run/mysqld danach gesucht. Nun gut, ein kleiner Link hat das ganze beseitigt, aber das war eher ein Workaround. Mit mysqlnd funktioniert die Sache nun ohne auch ohne, sehr schick.

Erste Alpha von PHP 5.3 erschienen

Late Static Binding, Namensräume, Lambda-Funktionen, Closures. Wem bei diesen Worten das Herz aufgeht, darf sich auf die kommende PHP Version 5.3 freuen. In einer ersten Alpha Version ist die neuste PHP Version nun erschienen. PHP 5.3 wird damit einige Dinge, die eigentlich für PHP 6.0 geplant waren, vorwegnehmen. Die erste stabile Version unter der neuen Versionsnummer soll zwischen September und Oktober erscheinen. Auch in Sachen Geschwindigkeit soll PHP 5.3 nochmals eine Steigerung darstellen, weshalb sicherlich auch Administratoren, die mit den genannten Schlagworten nicht viel anfangen können, ihren Teil an dieser Version haben werden.
Persönlich freue ich mich schon sehr auf diese neue Version, bewegt sich PHP doch steil Richtung PHP 6.0, das einige bisherige Konzepte über Board wirft und neuen Dingen Einzug gewährt. Dank eigenem Server ist ein Wechsel zudem zeitnah möglich, das ermöglicht eine baldige Nutzung in eigenen Skripten. Mancher Webhoster agiert hier verständlicherweise etwas zögerlicher, aber letztendlich wird es früher oder später den meisten zur Verfügung stehen.