Ich Update den Pi mit sudo apt update und danach sudo apt upgrade. Es werden über 500 MB geladen und installiert, naja nach einem halben Jahr. Der OS Codename ist Bookworm, aktuell wäre Trixie, man kann aber nicht von einer zur anderen Version springen, leider.
Ich riskiere es und mache auch noch ein sudo apt autoremove, das listet nur Linux-Headers also Kernel die weg können, ich sage JA.
Ich starte den Pi neu mit shutdown -r (Neustart)
Ich suche nach einer Möglichkeit die 64GB SD-Partition auf die vollen 128GB der SD-Karte aufzublasen und finde schnell raspi-config das schon installiert ist. Das bietet unter die Funktion Expand Filesystem, die genau dafür gedacht ist.
Ich drücke ENTER : es kommt KEINE textliche oder grafische Vor-Ansicht bei so einer wichtigen Aktion. Nur eine Meldung root Partition wurde auf volle Größe erweitert, Neustart erforderlich, der auch direkt angeboten wird … bibber
raspi-config – Partitions-Erweiterung
Danach teste ich mit lsblk die Partitions-Größen
lsblk – Partitionen
Sieht ja erstmal OK aus, ich gebe noch ein df -h /home/pi
df -h /home/pi
Das mache es dann ganz deutlich, Available 102GByte im Home-Directory, also auf dem gesamten root-Pfad.
Nein ist besser so, sonst werkelt der Pi nur auf der halben SD-Karte rum, was diese schneller altern läßt. Nach der Erweiterung kann der Pi auf der gesamten SD-Karte wirken.
Was für ein Drama mal wieder. Nach Jahren treuer Dienste funktioniert plötzlich mein Raspberry Pi 3 B+ nicht mehr. Ich stele fest das die LAN Verbindung nicht mehr leuchtet. Dann fällt mir auf, das die ACT LED nix mehr macht.
Sofort schreibe ich auf eine andere SD-Karte ein Raspi-OS-Image, nix, die ACT (Drive-Activitäten) LED ist tot. Kurz nehme ich den steinalten Raspberry Pi 2, alles gut mit der ACT-LED.
Nach intensiven Test’s bestelle ich einen Raspberry 4 B mit 1GB.
Lasset die Spiele beginnen
Der Pi 4 ist angekommen und ich stecke Hoffnungsvoll die alte 64GB SD-Karte rein, jau, er bootet in den Desktop. Fröhlich passe ich die IP-Adresse wieder an, teste, alles bestens. Und ab damit ins 19″-Rack … nix geht mehr, wieder alles zum Arbeits-PC um letztlich festzustellen – die 64GB SD-Karte ist TOT/DEFEKT/ENDE. Dabei hatte ich am Pi 4 vorm Umbau sogar einen SHUTDOWN gemacht und gewartet bis die Drive LED aus bleibt !!
TOTAL-KATASTROPHE, denn wie der Mensch so ist länger schon kein BACKUP mehr über’s LAN gesichert. Das letzte BACKUP stammt von 09-2025 :O
So ein MIST jetzt beginnt wieder dieser ganze Dreck mit OS/APACHE/PHP/SSL/HTTPS-ZERTIFIKATE/MYSQL/WORDPRESS. Das ist ein tagelanges Gefrickel, oft ohne Sinn und Verstand.
Was ich versucht habe
Zuerst händisch wieder alles nach irgendwelchen kruden Anleitungen/Video’s zusammen-installiert.
Dann nach Tag 1 finde ich durch Zufall ein IMAGE-File auch von 09-2025. Tja, dann bin ich ja gleich fertig. Da ich Images wenn überhaupt nur mit Clone/Rescue-Zilla erstellt haben kann, Kinderspiel…von wegen.
Ich habe bestimmt EINEN TAG damit verbracht sowohl mit Clonezilla als auch mit Rescuezilla das Image zurück zu spielen, KEINE Chance.
Clonezilla ist da mal die größte Enttäuschung. Das Teil listet das Save/Restore Directory nicht mal ansatzweise komplett, findet das Image gar nicht obwohl es vor der Nase liegt.
Rescuezilla ist da viel schöner, wunderbar kann man mit der Maus navigieren. Es findet das Image ohne Probleme. Leider endet die Freude beim zurückspielen. Erst werden Partitionen generiert, dann kommt die Haupt Partition dran…ERROR. Rescuezilla meckert weil beim Ziel-Datenträger ein paar hundert Bytes zu viel/wenig da sind. Absolut lachhaft, altes Image stammt von besagter 64GB SD-Karte und soll neu auf eine 128GB SD-Karte. Wo kann es hier kapp oder eng werden ?!?!?
Jetzt kommt der größte Witz, die USB-Abbilderstellung von Linux Mint schafft es ganz easy das Image zurückzuspielen. Leider enthält der wp-content-Ordner von WordPress danach aber viel zu wenig Daten.
Jedenfalls läuft der Pi 4 erstmal mit diesem Image. Es beginnt eine Odyssee des Hacken’s per Putty, Rechte neu vergeben, Passworte vergeben, Datenbank manuell erstellen dann Import eines Datenbank-Dump’s. Dann noch WordPress die DB-Zugangsdaten beibringen.
Endlich nach gefühlt 3 Tagen sehe ich Licht am Ende des Tunnels.
Ich sehe meine Webseite, natürlich verstümmelt ohne Grafiken. Durch totalen Zufall ist der letzte erhaltene POST einer über Zertifikat Erstellung, ich folge meinem eigenen Schrieb und siehe da die Seite wieder in voller Pracht.
Dann stelle ich in WordPress unter Einstellungen/Allgemein diese beiden Seiten-Links um lösche /wordpress hinter der URL, bibbernd speichere ich. Erst klappt danach nix mehr, kriege es aber schnell wieder hin.
Dann machen natürlich wieder die Permalinks Probleme, EINFACH funktioniert, BEITRAGSNAME geht schlecht/nicht weil bestimmte Links damit nicht funktionieren. Genau das hatte ich schon mal und zum Glück hatte ich notiert wie die Lösung war.
In der /etc/apache2/apache2.conf muß unter <Directory var/www/> Allow Override auf ALL stehen. Danach mysql (mariaDB) und Apache durchstarten. Leider funktionieren danach die Permalinks mit Beitragsname genau so wenig.
Permalinks und Apache-Rewrite
.htaccess Rewrite manuell hinzugefügt
Weil WordPress normalerweise bei jeder Permalink Änderung + Speichern eine versteckte .htaccess generiert, das aber dieses mal NICHT tut, erstelle ich mühsam Eine per Hand im html-Ordner
Und siehe da, mit der Permalink-Einstellung auf Beitragsname funktioniert es nun wieder.
Und ich wette das hat mit den Schreibrecht-Problem zu tun das ich nun beschreibe.
WordPress kann nicht Uploaden/Plugins Updaten usw.
Was ist das nun wieder, WordPress meckert herum will ich Bilder (Medien) uploaden.
Keine Server Schreibrechte
Auch nach intensiver Recherche finde ich keine Lösung. Und natürlich mache ich ein chown rekursiv für verschiedenste Ordner.
Nächster Morgen
Es kann so einfach sein, chown ist die Lösung. Ich habe (warum auch immer) WordPress 2x, einmal direkt im html-Ordner und einmal in html/wordpress. Welches ist nun das ECHTE ?
Rekursiv, also incl. aller Unterordner, gebe ich folgenden Befehl ein :
ES GEHT WIEDER – WordPress kann Uploaden und es gehen auch Plugin-Updates wie gewohnt.
Nun will ich schauen WO die Bilder-Upload’s nun landen.
Leider kommt durch das chown plötzlich mein pi User nicht mehr in den html-Ordner. Ich füge den pi User der Gruppe www-data hinzu mit :
sudo usermod -a -G www-data <Benutzername> sudo systemctl restart apache2
Nö, geht immer n.n. Da fällt mir ein, das man User Ab/Anmelden muß damit Änderungen wirksam werden. Und es funktioniert, mein Pi-User kommt wieder auf html und alle Unterordner.
Ich schaue nach wo nun der neu kreierte 2026/03-Ordner liegt und es ist /var/www/html/wp-content/uploads/2026/03
Also dürfte das WordPress in html/wordpress irrelevant sein. Bevor ich den Ordner lösche benenne ich Ihn testweise um.
sudo mv wordpress / aaaa/
WordPress läuft weiter, ich lösche den aaaa-Ordner mit sudo rm -R aaaa
Nachtrag
Und sieh mal einer an, nachdem ich eben die Permalink-Einstellungen änderte/speicherte hat WordPress in MEINE hand-getippte .htaccess die gleichen Einträge nochmals eingetragen. Ich lösche dort als mein mühsam hand-getipptes raus weil doppelt.
Eigentlich sehe ich mir aus nostalgischen Gründen sehr gerne YT-Video’s über Heimcomputer an. War selber 20 Jahre C-64/AMIGA süchtig.
In den letzten Jahren gibt es immer mehr Video’s über ALLE Arten der Homecomputer-Aufrüstung.
Eine lange Zeit fand ich das eigentlich sehr interessant. Z.B. das Hauptthema Bildausgabe an modernen Monitoren. Macht auch total Sinn, endlich mal den guten alten Homecomputer mit super Bild.
Was es da nicht alles gibt. Z.B. Raspberry Pi Lösungen mit Platinchen auf die dann ein Raspberry Pi kommt und alles dann auf den CPU-Sockel. Am Amiga sehr interessant. Bildet dann der Pi doch in Software eine ganze (schnelle) CPU/GPU nach, erzeugt per HDMi ein gestochen scharfes Bild und bietet quasi beliebig viel RAM an.
Ein AMIGA mit tollem Bild, ohne ende RAM und ‘ner unübertroffen schnellen CPU. Das alles für recht wenig Geld.
OK, man kauft sich so eine Adapterplatine, hat vielleicht noch einen Pi irgendwo rumliegen, baut alles um FÜR WAS ?!!
Das frage ich mich dann immer … verliert man hier den Blick auf das große ganze ?
Denn ist ein AMIGA auch noch so schnell und macht man das modernste OS drauf, wer will sowas in 2023 benutzen ?!
Alles läuft seit Jahren stabil auf meinem Raspberry Pi Webserver.
Aber wenn man zu zufrieden ist wird einem Langweilig und man macht manche Dummheit.
Alles fing damit an, das ich merkte die Statistik ist ja mal ziemlich tot, null Traffic.
Ich benutzte die Funktion Werkzeuge/Website-Zustand. Irgendwie knallte ich das neuste PHP 8.x drauf, was ein Aufruf der phpinfo.php auch bestätigte.
Ich glaube ab dann lief mein phpMyAdmin nicht mehr und das DRAMA nahm seinen tagelangen grausamen Lauf.
Ich hatte also zwei Hauptprobleme, Webseite “nicht” erreichbar und kein phpMyAdmin mehr.
phpMyAdmin
Habe ich auch nach Tagen nicht mehr ans laufen gebracht, ca. 1000x remove –purge dann wieder install gemacht. Immer und immer wieder kommt ERROR 1045. Die Installation scheitert am simplen Anmelden an der Datenbank, welches aber manuell klasse Funktioniert. Selbst wenn ich es mal schaffte das die Installation durch kam (kann mich nicht erinnern wie=Linux Delirium) startete phpMyAdmin nicht. Es lag auch keine phpmyadmin.php im Web-Root-Ordner.
Alles auf Anfang
Zweite 32GB SD-Karte her, Raspbian komplett neu installiert, dann wieder die Odyssee Apache, PHP, FTP, phpMyAdmin, WordPress. Lief erwartungsgemäß sauber durch.
Erst versuchte ich es mit Plugins wie DUPLICATOR oder BackupWordpress, keinen Erfolg. DUPLICATOR rödelte rum um dann zu melden NÖ – warum ging aus den Rückmeldungen nicht annähernd hervor, DANKE. BackupWordpress war nicht dazu zu bewegen eine externe Datei zu akzeptieren (oder auch nur zu finden), DANKE !!
Dann schlaue Idee gehabt, den jungen WordPress-Ordner mit den ollen Daten komplett überschreiben. Klappte auch, Webseite lief Lokal, phpMyAdmin hatte ich aber dadurch schon wieder abgeschossen (Applaus).
Irgendwie schaffte ich es auch noch den FTP-Server zu schmelzen ich gab die Arbeit an der 2ten SD-Karte auf. Wieder zum Original.
Webseite von außen erreichbar aber LEER
Eigentlich ist (und war) die Webseite von Außen erreichbar. Nur irgendwie landet man immer auf einer leeren weißen Seite.
Nach einem Tag Kampf (verloren) kam mir Abends die Idee “die sagen doch oft ALLE Plugins deaktivieren”. Totaler Quatsch würde ich normalerweise sagen, aber in der Not.
Ich glaubte es nicht, alle Plugins deaktiviert, Seite wird von Außen wieder sauber dargestellt. Plugin eingegrenzt auf WpStatistic (die Sau).
Sofort deinstalliert und ein anderes Statistik-Plugin drauf….dabei stelle ich fest, das es quasi KEINE brauchbaren Statistik Plugins gibt. Was habe ich davon wenn ich weiß welche Suchmaschinen meine Webseite besucht haben. Mich würde einzig und allein interessieren welche Posts wie oft aufgerufen wurden oder welche Suchbegriffe eingegeben wurden.
Und immer wieder werden Funktionen nur gegen Geld nutzbar. Habe jetzt mal alle Statistik-Plugins deinstalliert, 2021 … traurig aber so ist es.
Soweit läuft nun wieder alles bis auf phpMyAdmin, und das kriege ich auch noch hin …. Nö
WordPress 5.2.1 ist verfügbar – Bitte aktualisiere jetzt
Klar mache ich, wie schon dutzende male – nicht dieses mal denn eine Meldung sagt ich muß auch PHP updaten.
WordPress Update nur mit PHP Update möglich
Das war Vormittags nun ist es Abend und wieder einmal danke Linux. Danke für einen Tag an dem ich ca. eine Millionen unterschiedliche Meinungen lesen durfte wie so was wohl zu handeln sei.
Als ich vor kurzem meinen T-Com Anschluß auf IP umstellte mußte ich Zweck’s IP-Telefonie Nutzung auch meinen Router auswechseln. Ich habe günstig einen Speedport W724V bekommen, der auch anstandslos funktioniert.
Da diese Webseite auf einem Raspberry PI in meinem LAN läuft würde ich auch gerne zum bearbeiten von Posts direkt auf Diesen zugreifen was mit meinem alten Router gut funktionierte. Leider funktioniert das mit dem W724V gar nicht mehr. Der Router scheint nicht zu merken das Er doch selber die WAN-IP hat die durch die DynDNS-Namensauflösung herauskommt.
Ein nslookup in der Windows Konsole ergibt meine aktuelle WAN-IP, ein tracert meiner Domain bekommt irgendwann aber einen Timeout.
Nach einigen Tagen und herumprobieren mit dem Firefox REDIRECT welche beliebige Domainnamen (per Wildcard auch alle Unterseiten) durch eine IP ersetzen kann, stieß ich auf eine Lösung.
Im Forum der Telekom empfahl ein User folgendes.
Im Speedport unter Heimnetzwerk/Heimnetzwerk (LAN)/Übersicht der Geräte im Heimnetzwerk den Webserver ausfindig machen und dessen Namen auf den Domainnamen ändern (z.B. 64kilobyte.zapto.org). Dann noch am Raspberry IPV6 aktivieren mit…
sudo nano /etc/modules
in der Datei am Ende diese Zeile einfügen
ipv6
mit STRG + O speichern und mit STRG + X verlassen
ob es geklappt hat sieht man mit
ifconfig
Steht dort bei “eth0” eine IPv6-Adresse die mit “fe80” beginnt und den Gültigkeitsbereich “Verbindung” hat, ist IPv6 eingeschaltet und man kann es im lokalen Netzwerk verwenden.
Ist bei “eth0” zusätzlich eine Zeile mit “inet6-Adresse” und dem Gültigkeitsbereich “Global” vorhanden , dann müssten auch IPv6-Verbindung ins Internet möglich sein. Prüfbar mit…
ping6 google.de
Abbruch des Ping mit STRG + C
Bei mir klappt es nun das ich im LAN verbleibe wenn ich am Raspberry Seiten bearbeite.
Neulich wollte ich meinen Blog wieder in’s Leben rufen. Da solch ein Webserver Tag und Nacht laufen muß sollte der Rechner auf dem das läuft möglichst sparsam und günstig sein. Da kam ich auf den Raspberry PI. Beim PI schien es mir recht einfach zu sein ein OS aufzuspielen und man findet im Netz genügend Anleitungen wie ein Webserver und WordPress installiert werden.
