Wie aus heiterem Himmel kann Firefox nicht mehr auf die lokalen Dateien innerhalb der Webserverumgebung zugreifen und dieser Artikel beschreibt die Lösungsversuche…

Firefox und IPv6:

Eine erste Internetsuche führte mich zu einem möglichen Lösungsansatz in Zusammenhang mit den neuen IP-Adressen IPv6. Im Firefox sollte die “about:config“ Adresse eingegeben und eine Suche mit dem Suchbegriff “ipv6“ gestartet werden. Der Wert für “network.dns.disableIPv6“ sollte, falls im System auch IPv6 Adressen genutzt werden (ping auf localhost), auf “true“ gestellt werden.

QUELLE: Webseite von Fabian Martin

Auch wenn die Problembeschreibung nicht ganz mit meiner Situation passte, habe ich diesen Weg versucht, doch eine Verbesserung konnte ich so auch nicht erzielen. Firefox weigerte sich weiterhin lokale Dateien (HTML und PHP) aus der localhost-Umgebung anzuzeigen. Außerhalb der localhost-Umgebung konnten Dateien aber geöffnet werden.

Firefox und https:

Sollte es vielleicht an https liegen? Firefox fügte diesen Teil den HTML-Dateien und auch der localhost-Adresse automatisch zu. Im Firefox sollte die “about:config“ Adresse eingegeben und eine Suche mit dem Suchbegriff “https“ gestartet werden. Der Wert für “browser.fixup.fallback-to-https“ auf “false“ gestellt werden. Damit sollte Firefox im Fallback nicht mehr auf das https Protokoll weiterleiten…

QUELLE: Webseite von Netzware

Auch dieser Versuch brachte keine Verbesserung und Firefox weigerte sich weiterhin lokale Dateien (HTML und PHP) aus der localhost-Umgebung anzuzeigen.

Webserver Konfiguration:

Nun richtete sich mein Blick auf den Webserver und somit auf den Apache. Mit dem Terminalbefehl “apache2 -v“ habe ich die Version meines Apache Webservers als Vesion 2.4.52 ermittelt.

Mit dem Terminalbefehl “systemctl status apache2“ kann der Status des Apache Webservers angezeigt werden und hier wurde klar, dass der Server nicht gestartet werden konnte. Eine frische Installation an einem Testsystem lief dann erfolgreich ab und nach entfernen von https vor dem localhost konnten auch wieder html-Dateien aus der localhost-Umgebung angezeigt werden.

Bei einer Installation nach vorheriger Löschung an einem anderem Testsystem ging es leider nicht und ich entschied mich dann für den harten Weg und habe händisch als Administrator einfach den Apache Ordner (unter /etc) gelöscht und auch den PHP-Ordner (/usr/lib)…

Nun führte ich eine Neuinstallation von Apache durch.

• sudo apt install apache2
• sudo chown -cR BENUTZER:GRUPPE /var/www

Der zweite hier gelistete Befehl passt die Zugriffsrechte an. Letztendlich war auch das alles vergebene Mühe, denn Firefox zickte immer noch rum.

Die Konfigurationsdatei für Apache und die Module:

Die Fehlermeldung von “systemctl status apache2“ zeigte auf die Konfigurationsdatei des Webservers und dort auf Zeile 146 mit den Angaben zur Modulkonfiguration und je nach Szenario war der Zugriff auf oder der Ladevorgang von einem bestimmten Modul nicht möglich. Nach mehreren “sudo apt purge apache2“ und anschließenden Neuinstallationen und Kopiervorgängen für die Konfigurationsdatei und das betreffende Modul, ist es mir gelungen den Apache wieder lauffähig zu bekommen.

Die Konfigurationsdatei für Apache findet sich unter “etc/apache2/apache2.conf“ und wurde von mir als Teil der Problemlösung auch von einem lauffähigen System auf das fehlerhafte System kopiert. Welcher Schritt genau das Problem gelöst hat, kann ich hier leider nicht abschließend festhalten. Vermutlich war es eine gute Mischung aus Neuinstallation und dem Kopiervorgang der Module. Die Module in “/usr/lib/apache2/modules/“ und hier das Modul “mod_access_combat.so“ machten zumindest einen Teil des Problems aus.

LÖSUNG = PHP Neuinstallation:

Nach einigen Experimenten brachte nur die vollständige Entfernung und Neuinstallation den Erfolg.

• sudo apt purge php8.*
• sudo apt autoremove –purge
• php -v
• sudo apt install php
• sudo service apache2 restart

Die regulären Deinstallationen ließen wohl noch Reste der Konfiguration im System zurück und deshalb hatte es mit “sudo apt remove php“ nicht funktioniert und auch “sudo apt purge php“ brachte keinen Erfolg – es brauchte also noch die Versionsbezeichnung. Mit dem Sternchen wird eine Wildcard gesetzt und mit “php -v“ und oder “whereis php“ kann geprüft werden, ob das System wirklich sauber ist und PHP vollständig entfernt wurde und dann und nur dann funktionierte auch die Neuinstallation.