Schuld daran war wie bei vielen anderen Sites PHP2Shell. Unter dem Namen laufen zwei kritische Lücken im PHP-Kern, über die Angreifer aus der Ferne und ohne Anmeldung eigenen Code auf dem Server ausführen können. Die PHP Foundation hat am 21. Oktober Korrekturen für PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Für ältere PHP-Versionen gibt es vom PHP-Projekt selbst nichts mehr.

PHP 7 als Dealbreaker

Genau das wurde dem SELFHTML-Wiki zum Verhängnis. Wie Matthias Scharwies im Forum schreibt, lief es auf einem Server namens „Wowbagger“ mit PHP 7, und Patches gibt es eben nur für PHP 8 und neuer. Forum und Blog blieben erreichbar, das Wiki hat das Team dagegen am 21. Oktober sicherheitshalber abgeschaltet, zeitgleich mit der Veröffentlichung der Details zur Lücke.

Wie Julius im SELFHTML-Blog erklärt, lief das Wiki noch mit MediaWiki 1.27, und das verträgt sich höchstens mit PHP 7.0. Darunter lag CentOS 7, das seit 2024 keinen Support mehr bekommt. Schon ein wenig bitterböse Ironie, dass ausgerechnet „das“ Web-Wiki an einer alten Gammelversion von PHP scheitert. Bekannt war das Problem seit Jahren, nur hatte sich die Umsetzung immer wieder verzögert.

Update statt Patch

Einen Patch für den alten Server lehnte das Team ab, weil er nur bis zum nächsten Problem halten würde. Stattdessen hat es das Wiki aktualisiert und auf einen neuen Server umgezogen, die SELFHTML-eigenen Anpassungen kamen danach. Ziel ist ein Webhosting-Paket bei manitu, das der Verein seit September nutzt und über das seit Mitte Oktober auch die E-Mails laufen.

Da MediaWiki pro Update höchstens eine LTS-Version überspringt, führte der Weg von 1.27 über 1.35, 1.43, 1.44 und 1.45 bis zu 1.46, jeweils in MediaWiki-Containern unter Docker beziehungsweise Podman. Den eigenen Skin und die Erweiterung „Selfhtml“, die ohne Änderungen nicht mit der neuen Version liefen, hat Julius anschließend mit Hilfe eines KI-Modells an MediaWiki 1.46 angepasst.

Wieder unter der alten Adresse

Seit Sonntagabend, 20 Uhr, ist das Wiki wieder unter wiki.selfhtml.org erreichbar, die Adresse next.selfhtml.org liefert inzwischen nur noch einen Fehler. Die Versionsseite meldet MediaWiki 1.46.2 statt 1.27.3, PHP 8.4.27 statt 7.0.33 und MariaDB 10.11.6 statt 5.5. Sprich, das Wiki springt über 19 MediaWiki-Versionen und läuft direkt mit der gegen PHP2Shell abgesicherten PHP-Version. Das ist mal ein ordentlicher Satz nach vorn.

Wer das alte Wiki kennt, wird sich sofort zurechtfinden, Skin und Erweiterung sehen aus wie früher. Ganz rund läuft allerdings noch nicht alles: Julius rechnet mit Fehlern und Merkwürdigkeiten und bittet darum, sie zu melden. Auf der Liste stehen außerdem ein echter Umbau von Skin und Erweiterung sowie das endgültige Aus für Wowbagger. Danach soll das Wiki auf MediaWiki 1.47 wechseln.

Die nächste LTS-Version soll im November erscheinen, ab dann will das Team dabei bleiben und regelmäßig Updates einspielen. In meinen Augen hat die Lücke damit am Ende sogar etwas Gutes bewirkt, denn das Wiki ist jetzt technisch wieder auf der Höhe der Zeit. Ein Dank geht an Julius, Matthias und das ganze Team. Wer SELFHTML unterstützen möchte, findet im Wiki eine Seite zum Spenden.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Abgedichtet sind die Lücken in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 8.1 und älter gibt es bislang keine regulären Releases mit dem Fix, da hilft nur der Umstieg auf einen unterstützten Zweig. Auf einem normalen Server erledigt das der Paketmanager. Bei Docker sieht die Sache anders aus: Jeder Container bringt sein eigenes PHP mit, und das bleibt so alt, wie das Image eben ist.

Welcher Container hat welches PHP?

Die erste Frage lautet also: In welchen Containern auf dem Heimserverchen steckt überhaupt ein PHP? Bei Nextcloud oder WordPress ist das klar, bei selbst gebauten Images oder kleinen Web-Apps weniger. Statt jeden Container einzeln abzuklappern, fragt die folgende Schleife alle laufenden Container nach ihrer PHP-Version und gleicht sie gleich mit den gepatchten Versionen ab.

for c in $(docker ps --format '{{.Names}}'); do
  v=$(docker exec "$c" php -r 'echo PHP_VERSION;' 2>/dev/null) || continue
  case "${v%.*}" in
    8.5) fix=8.5.12 ;;
    8.4) fix=8.4.27 ;;
    8.3) fix=8.3.36 ;;
    8.2) fix=8.2.35 ;;
    *)   fix=99 ;;
  esac
  if [ "$(printf '%s\n' "$fix" "$v" | sort -V | head -n1)" = "$fix" ]; then
    printf '\e[32m%-30s %-8s ok\e[0m\n' "$c" "$v"
  else
    printf '\e[31m%-30s %-8s anfällig?\e[0m\n' "$c" "$v"
  fi
done

Container ohne PHP überspringt die Schleife stillschweigend. Bei allen anderen landet die Version grün in der Ausgabe, wenn sie mindestens auf dem Stand des Patches ist, und rot, wenn sie darunter liegt. Rot gibt es auch für PHP 8.1, 7.x und älter, denn dafür existiert schlicht kein Fix. Bei mir sieht das Ergebnis so aus:

$ ./php2shell-simple.sh
nextcloud-app-1                8.5.12   ok
nextcloud-cron-1               8.5.12   ok
linuxundich-test-wordpress-1   8.3.36   ok
planetfoss-web                 8.3.33   anfällig?
sisu-web                       8.4.26   anfällig?

Nextcloud und das Test-WordPress hatten ihre Updates also schon gezogen, PlanetFOSS und die Seite für Sisu hingen dagegen noch hinterher. Das Fragezeichen hinter „anfällig“ ist übrigens Absicht. Die Schleife vergleicht nur die Versionsnummer. Nutzt ein Image das PHP-Paket von Debian, Ubuntu oder Alpine, kann der Fix zurückportiert sein, ohne dass sich die Nummer ändert. Dann hilft nur ein Blick in die Sicherheitsmeldungen der Distribution.

Genauer hinschauen lässt sich mit php2shell-check von EXT IT. Das MIT-lizenzierte Skript arbeitet nur lesend und bewertet PHP anhand der Paketversionen statt nur der Versionsnummer, berücksichtigt also auch zurückportierte Fixes. Es schaut in Docker-Container, FPM-Pools und noch laufende alte Prozesse und schickt auf Wunsch eine harmlose Anfrage an eure Website. Für die Container braucht es Root-Rechte oder die Mitgliedschaft in der Gruppe docker.

Die Projektseite schlägt den üblichen Einzeiler mit curl und sudo bash vor. Bei einem Skript, das mit Root-Rechten auf dem Server läuft, mag ich das nicht so gern. Ladet lieber das Skript samt SHA256SUMS aus den Releases herunter, prüft es mit sha256sum -c SHA256SUMS, lest einmal drüber und startet es dann von Hand. Ein „nicht anfällig“ ist laut den Entwicklern übrigens keine Garantie:

$ sudo bash php2shell-check.sh https://eure-seite.example

Auf meinem Heimserver lief das Skript mit sudo. Als Mitglied der Gruppe docker sähe es die Container zwar auch ohne Root-Rechte, laufende Prozesse anderer Benutzer und manche Logs blieben dann aber verborgen. Geholt und gestartet habe ich es so:

$ curl -fsSLO https://github.com/EXT-IT/php2shell-check/releases/latest/download/php2shell-check.sh
$ chmod +x php2shell-check.sh 
$ sudo ./php2shell-check.sh 

Das Urteil deckt sich mit der Schleife: planetfoss-web mit PHP 8.3.33 und sisu-web mit PHP 8.4.26 sind anfällig, Nextcloud und das Test-WordPress nicht. Zusätzlich hat es einen gestoppten Container von Tuxsucht gefunden, den meine Schleife glatt übersehen hat:

PHP in docker containers
  [ OK ] container      nextcloud-app-1 (nextcloud:35-apache)
         PHP 8.5.12 (fixed from 8.5.12)
[...]
  [VULN] container      planetfoss-web (planetfoss-web:local)
         PHP 8.3.33, fixed in 8.3.36
         -> Update PHP to 8.3.36 or later (container: pull the new image and recreate)
[...]
  [VULN] container      sisu-web (sisu-web:local)
         PHP 8.4.26, fixed in 8.4.27
[...]
  [WARN] container      php83 (stopped, tuxsucht-php)
         stopped, but its image ships PHP 8.3.33: it comes back vulnerable on the next start
[...]
Summary  2 vulnerable, 3 undecided, 12 warnings, 11 ok

Klar, docker ps listet eben nur laufende Container, und ein gestoppter Container nimmt keine Anfragen an. Startet ihn aber irgendwann jemand wieder, ist die Lücke sofort zurück. Deutlich wird das Skript außerdem beim Thema mod_php: Alle fünf laufenden Container liefern PHP über das Apache-Modul aus, und genau gegen dieses Setup demonstriert das Advisory einen kompletten Angriff ohne Anmeldung.

Bis zum Update schlägt das Skript als Notbehelf vor, session.upload_progress.enabled=0 und expose_php=0 zu setzen und post_max_size unter einem Viertel von memory_limit zu halten. Die Prüfung von außen hat dagegen wenig gebracht. Für die beiden Websites meldet das Skript nur, dass die Header keine PHP-Version verraten und keine WAF davorsteht. Über den Patchstand sagt das nichts, was das Skript auch ehrlich zugibt.

Und wie bekommt man das PHP aktualisiert?

Im Container selbst solltet ihr nichts aktualisieren, das wäre beim nächsten Neustart wieder weg. Stattdessen zieht ihr im jeweiligen Compose-Verzeichnis das neue Image und baut den Container damit neu auf. Bei selbst gebauten Images mit eigenem Dockerfile braucht es ein docker compose build --pull, damit Docker auch das Basis-Image frisch holt:

$ docker compose pull && docker compose up -d

Wichtig: Das hilft natürlich nur, wenn das Basis-Image die gepatchte Version auch schon enthält. Laut IT-Connect tauchten die neuen Tags anfangs sogar ohne Image dahinter auf, inzwischen liefern allgemeine Tags wie php:8.3-apache das gepatchte PHP. Wer dagegen eine feste Version wie php:8.4.24-fpm im Dockerfile stehen hat, muss sie selbst anheben. Lasst die Schleife nach dem Update einfach noch einmal laufen. Kümmert euch zuerst um die Container, die aus dem Internet erreichbar sind.

Wie das in der Praxis aussieht, zeigt die Testumgebung von PlanetFOSS. Das Image baut auf php:8.3-apache auf und packt im Dockerfile nur noch Erweiterungen wie GD und Intl dazu. Mein Deploy-Skript ruft zwar docker compose up -d --build auf, holt dabei aber kein neues Basis-Image, sondern nimmt das vom August aus dem Cache. Daher stammte das alte PHP 8.3.33. Erst --pull lädt die frische Fassung:

$ cd /data/docker/planetfoss
$ docker compose build --pull web
$ docker compose up -d web

Nach gut einer Minute stand das neue Image, und der Container lief mit PHP 8.3.36. Die Datenbank im selben Compose-Projekt bleibt davon unberührt, weil beide Befehle nur den Dienst web ansprechen. Die Schleife zeigt PlanetFOSS danach grün, und auch php2shell-check meldet nur noch sisu-web als anfällig. Das alte Image liegt übrigens noch als Leiche auf der Platte, docker image prune räumt es weg.

$ ./php2shell-simple.sh
[...]
nextcloud-cron-1               8.5.12   ok
linuxundich-test-wordpress-1   8.3.36   ok
sisu-web                       8.4.26   anfällig?

Alles in allem ist PHP2Shell ein gutes Beispiel dafür, dass Selfhosting mit Docker zwar bequem ist, die Updates aber nicht von allein kommen. Weitere Details zu den Lücken hat heise zusammengetragen. Wie man Container ohne viel Gefrickel auf Stand hält, habe ich mir übrigens in Docker-Container einfach aktuell halten mit Dockcheck angeschaut. Wie haltet ihr eure Container aktuell?

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Genau dafür gibt es jetzt PlanetFOSS. Die Seite läuft schon ein paar Tage im Probebetrieb, ab heute möchte ich sie offiziell starten. Die Idee ist ein Planet, der nicht an einem Projekt hängt, sondern themenübergreifend sammelt: Distributionen, Desktops, Kernel, Selfhosting, Gaming, Sicherheit, Politik. Dazu kommen Verlage, Blogs, Projektseiten und Videokanäle, auf Deutsch und Englisch, und jeder Besucher filtert selbst, welche Sprache er sehen will.

Magazin statt Liste

Optisch orientiert sich PlanetFOSS an einem modernen Computer-Magazin und nicht an der klassischen Planet-Liste. Es gibt einen Aufmacher, Karten mit Bild und Anriss, Rubriken und eine Leiste mit den Themen des Tages. Übernommen wird dabei nur, was die Seiten selbst für Vorschauen ausliefern, also Open-Graph-Angaben oder den Inhalt des RSS-Feeds. Jede Karte verlinkt direkt auf den Originalartikel, Volltexte gibt es nicht.

Auch beim Datenschutz habe ich mir Mühe gegeben. Die Vorschaubilder liegen als WebP auf dem eigenen Server, sodass keine Besucher-IP bei fremden Servern landet. Es gibt keine Cookies, keine externen Skripte und kein Tracking. Artikel lassen sich trotzdem mit einem Stern als lesenswert markieren, ohne Konto: Statt eines Captchas löst der Browser eine kleine Rechenaufgabe, gemerkt wird der Stern nur lokal im Browser.

Technisch steckt dahinter ganz klassisches PHP mit MySQL, ohne Framework, auf einem gewöhnlichen Webspace. Alle fünf Minuten stößt ein Cronjob den Takt an: Feeds abrufen, neue Artikel anreichern, einordnen, Startseiten neu erzeugen. Die eigentliche Arbeit steckt aber nicht im Abrufen, sondern im Sortieren. Denn eine Seite mit über hundert Quellen wird schnell zur Bleiwüste, wenn zehn Seiten über dasselbe berichten.

Aus gleichen Meldungen werden Bündel

Erscheint eine neue Firefox-Version, schreiben gefühlt alle darüber. Auf einer normalen Planet-Seite stünde dann zehnmal Firefox untereinander. PlanetFOSS vergleicht deshalb jeden neuen Artikel mit allen Artikeln anderer Quellen aus den letzten 48 Stunden. Steckt im Titel dasselbe Thema mit derselben Versionsnummer, etwa „Firefox 158“ oder „Ubuntu 26.10“, landen die Artikel in einem gemeinsamen Bündel, auch über die Sprachgrenze hinweg.

Daneben gibt es zwei weitere Signale. Verlinken zwei Meldungen auf dieselbe Primärquelle, etwa die Release Notes oder eine Pressemitteilung, gehören sie sehr wahrscheinlich zusammen. Allerweltsziele wie GitHub oder Wikipedia zählen dabei nicht. Als letzter Weg vergleicht der Sammler die Titel selbst: Stoppwörter fliegen raus, und wenn sich die restlichen Wörter zur Hälfte decken und dazu ein gemeinsames Thema auftaucht, ist es ein Bündel.

Das Motto dabei lautet: lieber zu wenig als falsch bündeln. Ein fehlendes „auch bei“ fällt kaum auf, eine falsch zusammengeworfene Meldung dagegen sofort. Auf der Startseite erscheinen Bündel mit zwei Quellen als Karte mit einer Quellen-Leiste darunter. Ab drei Quellen wird daraus eine Story-Karte, die im Raster doppelt so breit ist und jeden weiteren Bericht mit eigener Schlagzeile und eigenem Link zum Original aufführt.

Neue Themen ohne Wörterbuch

PlanetFOSS hat ein Wörterbuch mit Begriffen wie GNOME, Plasma, Proxmox oder Steam. Das hilft bei den Rubriken, die zusätzlich ein kleiner Naive-Bayes-Klassifikator vergibt, und bei Versionsthemen. Nur tauchen in der Open-Source-Welt ständig neue Namen auf, die in keinem Wörterbuch stehen. Bei den ersten Tests fiel mir etwa ArtCraft auf: sieben Artikel zu einem neuen Projekt, und die Seite hatte davon nichts mitbekommen.

Seitdem sucht PlanetFOSS selbst nach neuen Namen. Ein Kandidat muss in den letzten 48 Stunden bei mindestens drei Quellen im Titel stehen (bei nur einer Sprache bei vier), in den vier Wochen davor aber höchstens einmal. Dazu kommt ein kleiner Trick: Ein Name wird nie kleingeschrieben. Wörter wie „released“ oder „Sicherheitslücke“ fallen damit heraus, ganz ohne endlose Stoppwortlisten. Der Rest wird zum neuen Thema.

Kometen und Supernovas

Jetzt wird es spannend. Der Name gibt das Bild vor: Kommt zu einem Thema auf einen Schlag sehr viel herein, etwa am Release-Tag einer neuen Ubuntu-Version, wird es zur Supernova, einem plötzlichen, sehr hellen Ausbruch. Nimmt ein Thema gerade erst Fahrt auf, ist es ein Komet. Und wenn der Ausbruch vorbei ist, bleibt noch eine Weile das Nachglühen.

Ein Komet entsteht, sobald mindestens drei verschiedene Quellen binnen zwölf Stunden über ein Thema schreiben. Er bekommt ein Abzeichen an seinen Karten und rückt in der Themen-Leiste nach vorne. Damit allgemeine Sammelthemen wie der Linux-Kernel nicht zum Dauerkometen werden, müssen sie zusätzlich doppelt so viele Quellen wie normal vorweisen. Hält ein Komet die Substanz nicht, fällt er wieder auf ein normales Thema zurück.

Eine Supernova braucht mehr. Vier Quellen müssen binnen 24 Stunden berichten, fast alle davon in den letzten zwölf Stunden. Das Thema muss breit gestreut sein, also mindestens zwei Arten von Quellen erreichen (Verlag, Blog, Projekt, Video) oder in beiden Sprachen auftauchen. Außerdem muss es mindestens dreimal so viele Quellen erreichen wie im Schnitt der letzten vier Wochen. Sonst wäre jede Ubuntu-Woche eine Supernova.

Einiges kennt PlanetFOSS dabei schon im Voraus. In einem Release-Kalender stehen die bekannten Termine von Ubuntu, GNOME, KDE Plasma, Fedora, Debian, dem Kernel und Firefox. Liegt ein Thema in diesem Fenster, reicht eine Quelle weniger zum Zünden. Gleichzeitig dürfen höchstens zwei Supernovas brennen, damit die Startseite nicht im Dauerfeuerwerk versinkt. Gibt es mehr Kandidaten, zünden die stärksten, der Rest bleibt vorerst ein Komet.

Eine Supernova brennt mindestens zwölf Stunden. Danach kühlt sie ab, wenn sechs Stunden lang nichts mehr kommt oder die Zahl der Quellen unter die Hälfte der Spitze fällt. Kommt eine zweite Welle, etwa die ersten Tests ein paar Tage nach dem Release, kann sie erneut zünden. Nach 72 Stunden landet das Thema im Archiv, die Themenseite bleibt aber erreichbar und sammelt auch spätere Beiträge.

So entsteht die Startseite

Brennt eine Supernova, steht sie als eigenes Band ganz oben über dem Aufmacher, mit der Zahl der Beiträge und Quellen und einer Reihe Karten, sortiert nach offiziellen Ankündigungen, Meldungen, Tests, Anleitungen und Videos. Was in diesem Band steht, taucht weiter unten nicht noch einmal auf. Zusätzlich verschickt PlanetFOSS eine halbe Stunde nach dem Zünden einen Beitrag an das Konto @planetfoss auf Mastodon.

Für alles andere vergibt die Seite Punkte. In die Wertung gehen die Größe des Bündels, die Sterne der Besucher, ein aktives Supernova-Thema und das Gewicht der Quelle ein. Geteilt wird das Ganze durch das Alter des Artikels, sodass ältere Beiträge nach und nach nach unten rutschen. Über wen viele berichten, der hält sich also länger oben, aber eben nicht ewig.

Beim Aufmacher zählt Wichtigkeit vor Frische, nur stammen die Kandidaten aus den letzten 24 Stunden und bringen bevorzugt ein großes Bild mit. Als Alter eines Bündels gilt der zweitjüngste Bericht: Schreiben weitere Quellen, bleibt es vorne, ein einzelner Nachzügler reicht dafür nicht. Steht ein Beitrag schon über acht Stunden im Aufmacher, verliert er die Hälfte seiner Punkte, nach 14 Stunden drei Viertel.

Damit eine fleißige Quelle nicht die ganze Seite füllt, achtet die Auswahl außerdem auf Vielfalt. Im Aufmacher und bei den Top-Meldungen daneben stammt jeder Beitrag von einer anderen Quelle, im Bereich „Neueste“ kommen höchstens zwei Artikel von derselben Seite. Dadurch bekommen auch kleinere Blogs ihren Platz neben den großen Verlagen, und die Startseite wirkt bei jedem Besuch ein Stück anders.

Statistik statt KI

Eine KI, die Texte zusammenfasst oder Themen errät, steckt in PlanetFOSS übrigens nicht. Alles läuft über Zählen, Vergleichen und ein paar Schwellenwerte. In meinen Augen ist das sogar der bessere Weg: Es kostet nichts, schickt keine Daten nach außen und bleibt nachvollziehbar. Wenn eine Supernova zündet, lässt sich genau sagen, warum. Entwickelt habe ich die Seite allerdings selbst KI-unterstützt.

Ganz ohne Nachjustieren ging es natürlich nicht. Anfangs zündete etwa eine Supernova zu Microsoft Defender, obwohl sich die vier Meldungen über 18 Stunden verteilten. Seitdem muss ein Ausbruch wirklich frisch sein. Auch Ubuntu 26.10 zündete am Release-Tag zunächst zwei Stunden zu spät, weil es gegen alle Ubuntu-Meldungen gerechnet wurde. Versionsthemen bekommen deshalb inzwischen ihren eigenen Normalwert.

Solche Fälle schaue ich mir regelmäßig an, dafür legt die Seite alle sechs Stunden einen Schnappschuss von Themen, Bündeln und Aufmachern ab. Von daher wird sich die Logik sicherlich noch weiter verändern. Ein falsches Bündel oder ein Komet, der keiner sein sollte, lässt sich im Admin-Bereich von Hand korrigieren. Die Korrekturen respektiert der Algorithmus beim nächsten Durchlauf brav.

Schaut doch einfach mal auf planetfoss.net vorbei und sagt mir, was ihr davon haltet. Welche Quellen fehlen euch noch, und welche Blogs, Magazine oder andere Veröffentlichungen aus der deutschen oder englischen Linux- und Open-Source-Welt sollten unbedingt mit auf den Planeten? Vorschläge nehme ich gerne in den Kommentaren entgegen. Wer selbst ein Blog betreibt und lieber nicht dabei sein möchte, findet auf der Seite natürlich auch einen Weg zum Abmelden.

Update: Warum die Sternchen auf PlanetFOSS kein Milchglas mehr tragen und was das mit einem Speicherleck in WebKitGTK zu tun hat, lest ihr in WebKitGTK 2.54: Kleines Sternchen, großes Speicherleck.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

ShellCheck gibt es unter shellcheck.net im Netz und auch in der Paketverwaltung der meisten Linux-Distributionen. Unter Debian/Ubuntu, wie auch unter Arch Linux lässt sich das Programm direkt mit einem Kommando einspielen. Anschließend könnt ihr das kleine Programm direkt auf euer Skript loslassen. Solltet ihr auf einem System arbeiten, auf dem sich keine weiteren Programme installieren lassen oder wo euch dazu die nötigen Rechte fehlen, könnt ihr auf die webbasierte Variante zurückgreifen. Am Ende zeigen diese immer dasselbe Ergebnis an.

### ShellCheck unter Debian/Ubuntu installieren...
$ sudo apt install shellcheck

### ShellCheck unter Arch Linux installieren...
$ sudo pacman -S shellcheck

### Die Hilfe zu ShellCheck...
$ shellcheck --help
unrecognized option `--help'

Usage: shellcheck [OPTIONS...] FILES...
  -e CODE1,CODE2..  --exclude=CODE1,CODE2..  exclude types of warnings
  -f FORMAT         --format=FORMAT          output format
  -C[WHEN]          --color[=WHEN]           Use color (auto, always, never)
  -s SHELLNAME      --shell=SHELLNAME        Specify dialect (sh,bash,dash,ksh)
  -x                --external-sources       Allow 'source' outside of FILES.
  -V                --version                Print version information

Im Terminal zeigt ShellCheck die Hinweise auf schlechten Skript-Stil in seiner Ausgabe farbiert markiert an. Die Beschreibung hinter den Report-Codes (SC2046, SC2086 etc.) gibt euch einen ersten Eindruck davon, was ihr falsch macht. Für weiterführende Details gebt ihr den Code in die Suchfunktion des ShellCheck-Wiki ein. Dort erklärt ShellCheck genauer, was ihr warum falsch macht, zudem gibt es dort Beispiele, wie man die angemahnte Stelle besser gestalten sollte.

Alternativ kopiert ihr euren Code in die webbasierte Version von ShellCheck. Dies macht zwar ein wenig Arbeit, dafür könnt ihr die Report-Codes direkt anklicken, woraufhin euch der Browser direkt auf die Wiki-Seite führt. Diese Variante ist also besonders dann sinnvoll, wenn ihr ein längeres Skript mit vielen Fehlern überprüfen wollt. So erspart man sich das Hin- und Herkopieren der Fehlercodes zwischen Terminal und Browser.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Auf Systemen mit Debian oder Ubuntu lässt sich PhpSysInfo aus den Paketquellen schnell installieren, aber auch andere Distributionen führen das PHP-Skript in ihren Paketquellen. Mehr als das Tool aus den Paketquellen zu holen und ins Verzeichnis des Webservers zu verlinken ist eigentlich nicht zu tun. Wer PhpSysInfo „richtig“ installieren möchte, kann dem Skript natürlich auch eine eigene Subdomain oder ähnliches spendieren, aber das bekommt ihr sicherlich auch ohne mich hin

$ sudo apt-get install phpsysinfo
$ ln -s /usr/share/phpsysinfo /var/www/

Alternativ lassen sich die aktuellen Releases auch per Hand vom Github des Projekts laden. Zur Installation muss man das Skript lediglich nach /var/www entpacken und die Rechte so setzen, dass der Webserver auf die Daten zugreifen kann. Eine aktuelle Version des Skripts ist etwa dann nötig, wenn man mit PSIAndroid auf seine PhpSysInfo-Installation zugreifen möchte. So macht man PhpSysInfo fit fürs Handy, da die Webansicht leider noch nicht für die Darstellung auf mobilen Browser vorbereitet ist.

Mit linux-dash gibt es jedoch seit Oktober letzten Jahres eine etwas moderner gestaltete Alternative zu PhpSysInfo, die sich inzwischen recht gut entwickelt hat. Wie auch PhpSysInfo muss linux-dash einfach nur auf den Webspace gepackt werden. Als einzige Abhängigkeiten braucht es einen Webserver und PHP5, was sowieso klar sein sollte, sowie php5-json als zusätzliches Paket, anschließend kann man das Skript direkt im Webserver aufrufen. Aufgrund des responsiven Layouts braucht es für linux-dash auch nicht zwingend eine Handy-App, das Skript macht auch direkt im Handy-Browser eine ordentliche Figur.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Der Client basiert auf zahlreichen quelloffenen Bibliotheken, ist aber wohl selber leider proprietär. Er läuft unter Windows XP, Vista und Sieben und braucht .Net 4 zum Funktionieren. Ist das Framework noch nicht installiert, dann wird es vom Setup automatisch aus dem Netz geladen und auf dem System installiert.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Das Skript stammt von Martin Wimpress, der auf Flexion.Org über Linux und freie Software bloggt. Das Skript lädt das aktuelle JDK aus dem Netz direkt bei Oracle herunter, entpackt die Daten und schnürt aus dem ganzen Salat ordentliche Pakete, die dann über die Paketverwaltung installiert und auch wieder deinstalliert werden können.

$ cd ~/
$ wget https://raw.github.com/flexiondotorg/oab-java6/master/oab-java6.sh -O oab-java6.sh
$ chmod +x oab-java6.sh
$ sudo ./oab-java6.sh

Ihr könnt direkt die obigen Befehle übernehmen und im Terminal ausführen. Gebt der Aktion ein bisschen Zeit, es müssen einige Daten aus dem Netz geladen werden und der Paketbau braucht auch ein Weilchen. Macht das Ganze daher nicht auf dem langsamsten Rechner mit der dünnsten Internet-Anbindung.

Vor der Installation „eures“ Oracle-Javas würde ich noch kurz mit Synaptic prüfen, ob das Open-JDK und alles was sonst noch dazu gehört, installiert wurde. Falls ja, kommt es immer gerne zu Verwirrungen, welches Java denn nun genutzt wird. Danach findet Ihr die Pakete unter /var/local/oab/deb auf eurer Platte, von dort installiert ihr bspw. direkt mit dpkg das Wichtigste.

$ cd /var/local/oab/deb
$ sudo dpkg -i sun-java6-bin*.deb sun-java6-jre*.deb sun-java6-plugin*.deb

Abschließend würde ich noch kurz checken, ob Oracle-Java nun auch wirklich euer Standard-Java ist. Ein kurzer Aufruf von java -version schafft da recht schnell Klarheit. Falls dort weiterhin das Open-JDK auftaucht, so habt Ihr doch nicht alle Pakete des Open-JDK erwischt. Alternativ zur Deinstallation könnt Ihr auch das Alternativen-System bemühen, ein sudo update-alternatives --config java müsste euch das zu nutzende Java auswählen lassen.

$ java -version
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)

Das Skript funktionierte bei mir unter Ubuntu Oneiric und Precise (32- und 64-Bit) ohne Probleme. Weitere Informationen zum Programm findet Ihr im Blog des Autors oder auch auf der github-Seite des Projekts.

Ob es sich „lohnt“ auf die Oracle-JRE umzusteigen, will ich mal unbeantwortet lassen. Ich würde den Umstieg nur dann empfehlen, wenn es mit dem Open-JDK Probleme gibt und das „Original“ diese eben nicht aufweist. Mit dem Oracle-JRE läuft Glasnost nun und zeigt, dass Kabel Deutschland doch keine Ports blockiert.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.