Gespräch:MediaWiki HTML 2

Über diese Seite Gespräch

MediaWiki HTML 2

4. März 2025 n. Chr. erst.
Ausgabe 00
Ausgabe 00
unüberarbeitet ungeprüft
keine Datei

Hilf mir bei der Installation

Sophos:

Gerne, welche Installation möchtest du ausführen?

Nikolaos:

httpd-vhosts.conf

Datei

Hallo, ich habe die virtual hosts Konfiguration laut Anhang. Wie kann ich es so einrichten, das wenn ich vergleichsweise nur die subdomain wiki.aewi.de in den Webbrowser als URL eingebe ich gleich zu https://wiki.aewi.de/mediawiki/index.php?title=Hauptseite weitergeleitet werden, sodaß ich nicht die volle URL eintippen muß.

Sophos:

Um sicherzustellen, dass wiki.aewi.de automatisch zu https://wiki.aewi.de/mediawiki/index.php?title=Hauptseiteweiterleitet, kannst du eine RewriteRule in deinem VirtualHost für wiki.aewi.de einfügen.

Anpassung der VirtualHost-Konfiguration für wiki.aewi.de

Bearbeite deine httpd-vhosts.conf und füge folgende Rewrite-Regeln in den <VirtualHost *:443>-Block für wiki.aewi.de hinzu:

apache

KopierenBearbeiten

ServerAdmin webmaster@aewi.de

ServerName wiki.aewi.de

DocumentRoot "/Library/WebServer/Documents"

Options Indexes FollowSymLinks MultiViews

AllowOverride All

Require all granted

</Directory>

# Automatische Weiterleitung zur Hauptseite von MediaWiki

RewriteEngine On

RewriteCond %{HTTP_HOST} ^wiki\.aewi\.de$ [NC]

RewriteCond %{REQUEST_URI} ^/$

RewriteRule ^/?$ https://wiki.aewi.de/mediawiki/index.php?title=Hauptseite [R=301,L]

# Sicherheit: Setzt den X-Content-Type-Options Header für Datei-Uploads

Header always set X-Content-Type-Options "nosniff"

</IfModule>

SSLEngine on

SSLCertificateFile "/etc/letsencrypt/live/aewi.de-0002/fullchain.pem"

SSLCertificateKeyFile "/etc/letsencrypt/live/aewi.de-0002/privkey.pem"

ErrorLog "/opt/homebrew/var/log/httpd/aewi.de-error_log"

CustomLog "/opt/homebrew/var/log/httpd/aewi.de-access_log" common

</VirtualHost>

Erklärung der Änderungen:

RewriteEngine On: Aktiviert die Modifikation von URLs.
RewriteCond %{HTTP_HOST} ^wiki.aewi.de$ [NC]: Stellt sicher, dass die Regel nur für wiki.aewi.de gilt.
RewriteCond %{REQUEST_URI} ^/$: Triggert die Weiterleitung nur, wenn der Benutzer nur wiki.aewi.de/eingibt (ohne weitere Pfade).
RewriteRule ^/?$ https://wiki.aewi.de/mediawiki/index.php?title=Hauptseite [R=301,L]: Leitet die Root-URL wiki.aewi.de/ dauerhaft (301 Redirect) zur MediaWiki-Hauptseite weiter.

Neustart des Apache-Servers

Nach dem Bearbeiten der Konfiguration muss Apache neu gestartet werden:

sh

KopierenBearbeiten

sudo apachectl restart

Damit sollte die Weiterleitung nun funktionieren. Falls es Probleme gibt, kannst du in die Apache-Logfiles schauen:

sh

KopierenBearbeiten

tail -f /opt/homebrew/var/log/httpd/aewi.de-error_log

Teste es, indem du einfach wiki.aewi.de in den Browser eingibst. 🎯

Nikolaos:

[media pointer="file-service://file-75yzWJpgKwkSDXXuoZQVuV"]

Funktioniert. Danke.

Wenn ich aewi.de aufrufe, habe ich im Webbrowser der Tab's immer das icon von phpMyAdmin anstelle das des jeweiligen Webdienst. siehe Anhang die ersten vier Tab's linkst, von denen nur der erste phpMyAdmin ist.

Wie kann ich erreichen, daß entweder jeder Tab das icon des jeweiligen Dienst oder alle ein bestimmtes generelles icon haben?

Sophos:

Das Problem liegt wahrscheinlich an der Favicon-Konfiguration deiner VirtualHosts oder an einem Cache-Problem im Browser. Hier sind die Schritte, um das Problem zu lösen:

1. Prüfe, ob jede Subdomain ihr eigenes Favicon hat

Jede deiner Subdomains sollte ihr eigenes Favicon definiert haben. Das wird normalerweise in der <head>-Sektion der HTML-Dateien oder in einer .htaccess-Datei konfiguriert.

Überprüfe, ob in den index.html oder index.php-Dateien deiner Webdienste eine korrekte Favicon-Definitionexistiert:

html

KopierenBearbeiten

Falls nicht, füge sie hinzu.

Falls du verschiedene Favicons für unterschiedliche Subdomains möchtest, dann stelle sicher, dass jede Subdomain ihr eigenes Favicon besitzt. Zum Beispiel:

wiki.aewi.de → /Library/WebServer/Documents/wiki/favicon.ico
pma.aewi.de (phpMyAdmin) → /opt/homebrew/share/phpmyadmin/favicon.ico
aewi.de (Hauptseite) → /Library/WebServer/Documents/favicon.ico

Falls du ein generelles Icon für alle Dienste möchtest, stelle sicher, dass jede Domain auf dasselbe Favicon verweist.

2. Anpassung der VirtualHost-Konfiguration

Falls Apache immer das falsche Icon ausliefert, kannst du für jede Subdomain explizit festlegen, welches Favicon verwendet wird. Füge diese Zeile in jeden VirtualHost-Block ein:

apache

KopierenBearbeiten

Alias /favicon.ico "/Library/WebServer/Documents/{dein-dienst}/favicon.ico"

Ein Beispiel für wiki.aewi.de:

apache

KopierenBearbeiten

ServerAdmin webmaster@aewi.de

ServerName wiki.aewi.de

DocumentRoot "/Library/WebServer/Documents/wiki"

Alias /favicon.ico "/Library/WebServer/Documents/wiki/favicon.ico"

Options Indexes FollowSymLinks MultiViews

AllowOverride All

Require all granted

</Directory>

SSLEngine on

SSLCertificateFile "/etc/letsencrypt/live/aewi.de-0002/fullchain.pem"

SSLCertificateKeyFile "/etc/letsencrypt/live/aewi.de-0002/privkey.pem"

ErrorLog "/opt/homebrew/var/log/httpd/wiki_error.log"

CustomLog "/opt/homebrew/var/log/httpd/wiki_access.log" common

</VirtualHost>

Achte darauf, dass du das richtige DocumentRoot und das richtige favicon.ico verwendest.

3. Leere den Browser-Cache und lade das Favicon neu

Wenn sich das Favicon nicht sofort ändert, dann liegt das oft am Cache deines Browsers. Lösche den Cache für deine Domains:

Manuell Cache für eine einzelne Seite löschen

Mac: CMD + Shift + R (Neuladen mit Cache-Leerung)
Windows/Linux: CTRL + Shift + R

Cache komplett löschen

Falls das nicht hilft, kannst du in den Browser-Einstellungen den gesamten Cache löschen:

Google Chrome: chrome://settings/clearBrowserData
Firefox: about:preferences#privacy → "Cookies und Website-Daten" löschen
Safari: Einstellungen → Datenschutz → Websitedaten verwalten

Falls es nach dem Cache-Löschen immer noch nicht funktioniert, probiere es mit einem Inkognito-Fenster oder einem anderen Browser.

4. Neustart des Apache-Servers

Falls Änderungen an der httpd-vhosts.conf gemacht wurden, starte Apache neu:

sh

KopierenBearbeiten

sudo apachectl restart

Teste es, indem du verschiedene Subdomains in neuen Tabs öffnest. Jetzt sollte jede Subdomain ihr eigenes Icon haben! 🎯

Nikolaos:

Ich will eigentlich das Seiten des MediaWiki auch das Falcon von MediaWiki haben. Cache leeren bringt da nichts, weil es irgendwann wieder so ist, wie es jetzt ist. wie kann ich für wiki.aewi.de dafür sorgen, dass das in MediaWiki festgelegte Logo verwendet wird?

Sophos:

Damit MediaWiki für wiki.aewi.de das offizielle Favicon von MediaWiki anzeigt und nicht das von phpMyAdmin oder anderen Diensten, gibt es mehrere Ansätze:

1. Sicherstellen, dass MediaWiki das richtige Favicon ausliefert

In der LocalSettings.php von MediaWiki kann explizit ein Favicon definiert werden. Öffne die Datei:

sh

KopierenBearbeiten

sudo nano /Library/WebServer/Documents/mediawiki/LocalSettings.php

Füge oder bearbeite folgende Zeile:

php

KopierenBearbeiten

$wgFavicon = "$wgResourceBasePath/resources/assets/favicon.ico";

Das favicon.ico von MediaWiki liegt standardmäßig unter:

sh

KopierenBearbeiten

/Library/WebServer/Documents/mediawiki/resources/assets/favicon.ico

Falls du ein benutzerdefiniertes Favicon möchtest, kannst du eine eigene Datei angeben, z. B.:

php

KopierenBearbeiten

$wgFavicon = "https://www.mediawiki.org/static/favicon/wikipedia.ico";

Speichere die Datei und lade die Seite neu.

2. Apache VirtualHost anpassen

Falls Apache das falsche Favicon bereitstellt, kannst du das mit einer Alias-Direktive überschreiben.

Öffne deine httpd-vhosts.conf:

sh

KopierenBearbeiten

sudo nano /opt/homebrew/etc/httpd/extra/httpd-vhosts.conf

Füge in den <VirtualHost>-Block für wiki.aewi.de folgende Zeile hinzu:

apache

KopierenBearbeiten

Alias /favicon.ico "/Library/WebServer/Documents/mediawiki/resources/assets/favicon.ico"

Ein vollständiges Beispiel:

apache

KopierenBearbeiten

ServerAdmin webmaster@aewi.de

ServerName wiki.aewi.de

DocumentRoot "/Library/WebServer/Documents/mediawiki"

Alias /favicon.ico "/Library/WebServer/Documents/mediawiki/resources/assets/favicon.ico"

Options Indexes FollowSymLinks MultiViews

AllowOverride All

Require all granted

</Directory>

SSLEngine on

SSLCertificateFile "/etc/letsencrypt/live/aewi.de-0002/fullchain.pem"

SSLCertificateKeyFile "/etc/letsencrypt/live/aewi.de-0002/privkey.pem"

ErrorLog "/opt/homebrew/var/log/httpd/wiki_error.log"

CustomLog "/opt/homebrew/var/log/httpd/wiki_access.log" common

</VirtualHost>

Starte Apache neu:

sh

KopierenBearbeiten

sudo apachectl restart

Jetzt sollte das MediaWiki-Favicon für wiki.aewi.de geladen werden.

3. Hardcodiertes Favicon in MediaWiki einfügen

Falls es immer wieder überschrieben wird, kannst du das Favicon direkt in der MediaWiki-HTML-Vorlage definieren. Öffne die Datei:

sh

KopierenBearbeiten

sudo nano /Library/WebServer/Documents/mediawiki/skins/Vector/skin.json

Suche nach:

json

KopierenBearbeiten

"features": {

"favicon": "$wgResourceBasePath/resources/assets/favicon.ico"

}

Falls es fehlt, füge es hinzu. Danach musst du MediaWiki einmal leeren und neuladen:

sh

KopierenBearbeiten

php maintenance/run.php rebuildLocalisationCache

4. DNS und Browser-Cache prüfen

Falls du ein falsches Icon siehst, liegt es möglicherweise noch im Cache deines DNS oder Browsers:

Lokalen Cache leeren: sh KopierenBearbeiten sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
Browser-Cache komplett ignorieren: Öffne wiki.aewi.de in einem Inkognito-Fenster und überprüfe, ob das richtige Favicon geladen wird.

Erwartetes Ergebnis

Jetzt sollte wiki.aewi.de zuverlässig das MediaWiki-Favicon anzeigen, während andere Seiten ihre eigenen Icons behalten. 🚀

Nikolaos:

kann das favico.ico auch ein .svg sein?

Muß ich den Alias in httpd-vhosts.conf dann wir folgt setzen?:

Alias /favicon.ico "/Library/WebServer/Documents/mediawiki/resources/assets/favicon.svg"

Antworte nur kurz ohne weitere Tipps

2/2

Sophos:

Ja, das Favicon kann ein .svg sein. Der Alias müsste dann so gesetzt werden:

apache

KopierenBearbeiten

Alias /favicon.ico "/Library/WebServer/Documents/mediawiki/resources/assets/favicon.svg"

Nikolaos:

Wi kann ich erreichen, dass der Cache einen Webbrowser nicht mehr nur aewi.de absichert sondern einen cache für eine Subdomain wie wiki.aewi.de speichert?

Sophos:

Du kannst das Caching für jede Subdomain separat steuern, indem du richtige Cache-Control-Header setzt. Füge in den <VirtualHost>-Block für wiki.aewi.de in der httpd-vhosts.conf folgende Zeilen hinzu:

apache

KopierenBearbeiten

Header set Cache-Control "public, max-age=86400, must-revalidate"

</IfModule>

Falls du einen Proxy-Cache wie Varnish oder Cloudflare nutzt, solltest du sicherstellen, dass er Subdomains getrennt behandelt.

Nikolaos:

Änderungen für Alias /favicon.ico und IfModule mod_headers sind ohne Erfolg.

Webbrowser cache ist zuvor gelöscht gewesen, es wurde wieder nur ein cache für aewi.de angelegt und es wird im Tab des Webbrowser immer noch das icon von phpMyAdmin angezeigt.

Scheu nochmals die Konfiguration von httpd-vhost.conf, die ich dir bereits als Anhang zuvor gegeben habe durch, da gibt es ja für 443 aewi.de, welche zuerst kommt.

Sophos:

Das Problem liegt daran, dass der erste VirtualHost für aewi.de definiert ist. Apache nutzt den ersten definierten VirtualHost für Anfragen, die keiner anderen Konfiguration eindeutig zugewiesen werden. Da wiki.aewi.de als ServerAlias in aewi.de existiert, wird dieser VirtualHost als Standard verwendet, wodurch das falsche Favicon geladen wird.

Lösung: Reihenfolge der VirtualHosts anpassen

Setze den VirtualHost für wiki.aewi.de vor den für aewi.de in der Datei httpd-vhosts.conf.

Aktuelle Reihenfolge (fehlerhaft):

apache

KopierenBearbeiten

ServerName aewi.de

ServerAlias www.aewi.de wiki.aewi.de ose.aewi.de api.aewi.de pma.aewi.de

...

</VirtualHost>

ServerName wiki.aewi.de

...

</VirtualHost>

Hier wird wiki.aewi.de als Alias von aewi.de behandelt, wodurch es das falsche Favicon lädt.

Korrigierte Reihenfolge (richtig):

Platziere den VirtualHost für wiki.aewi.de an die erste Stelle:

apache

KopierenBearbeiten

ServerAdmin webmaster@aewi.de

ServerName wiki.aewi.de

DocumentRoot "/Library/WebServer/Documents/mediawiki"

Alias /favicon.ico "/Library/WebServer/Documents/mediawiki/resources/assets/favicon.ico"

Options Indexes FollowSymLinks MultiViews

AllowOverride All

Require all granted

</Directory>

Header set Cache-Control "public, max-age=86400, must-revalidate"

</IfModule>

SSLEngine on

SSLCertificateFile "/etc/letsencrypt/live/aewi.de-0002/fullchain.pem"

SSLCertificateKeyFile "/etc/letsencrypt/live/aewi.de-0002/privkey.pem"

ErrorLog "/opt/homebrew/var/log/httpd/wiki_error.log"

CustomLog "/opt/homebrew/var/log/httpd/wiki_access.log" common

</VirtualHost>

ServerAdmin webmaster@aewi.de

ServerName aewi.de

ServerAlias www.aewi.de ose.aewi.de api.aewi.de pma.aewi.de

DocumentRoot "/Library/WebServer/Documents/aewi"

...

</VirtualHost>

Warum funktioniert das?

Jetzt wird wiki.aewi.de als eigenständige Domain behandelt und nicht mehr als Alias von aewi.de.
Der Browser kann jetzt separaten Cache für wiki.aewi.de anlegen.
Das richtige Favicon von MediaWiki wird verwendet.

Neustart von Apache

sh

KopierenBearbeiten

sudo apachectl restart

Danach den Browser-Cache nochmal leeren oder ein Inkognito-Fenster testen. Jetzt sollte wiki.aewi.de als eigene Website mit eigenem Cache und richtigem Favicon behandelt werden. 🚀

Nikolaos:

brauche ich "ServerAlias www.aewi.de ose.aewi.de api.aewi.de pma.aewi.de" überhaupt noch, wenn ich doch für jeden Dienst eine direkte URL habe?

Sophos:

Nein, du benötigst die ServerAlias-Einträge nicht mehr, wenn jeder Dienst eine eigene VirtualHost-Deklaration hat. Jeder VirtualHost sollte dann nur für seine spezifische Subdomain zuständig sein.

Was passiert, wenn du ServerAlias entfernst?

Jede Subdomain (wiki.aewi.de, pma.aewi.de, ose.aewi.de, etc.) wird nur noch von ihrem eigenen VirtualHost verarbeitet.
Die Subdomains werden nicht mehr als Alias von aewi.de behandelt, was Verwechslungen beim Favicon-Cache verhindert.
Der Browser kann für jede Subdomain einen separaten Cache anlegen.

Empfohlene Anpassung:

Ersetze diesen fehlerhaften Eintrag:

apache

KopierenBearbeiten

ServerName aewi.de

ServerAlias www.aewi.de wiki.aewi.de ose.aewi.de api.aewi.de pma.aewi.de

...

</VirtualHost>

Mit:

apache

KopierenBearbeiten

ServerName aewi.de

DocumentRoot "/Library/WebServer/Documents/aewi"

...

</VirtualHost>

ServerName wiki.aewi.de

DocumentRoot "/Library/WebServer/Documents/mediawiki"

...

</VirtualHost>

ServerName pma.aewi.de

DocumentRoot "/opt/homebrew/share/phpmyadmin"

...

</VirtualHost>

ServerName ose.aewi.de

...

</VirtualHost>

Ergebnis:

✅ Jede Domain wird sauber getrennt behandelt.

✅ Der Browser erkennt sie als eigenständige Websites und speichert separate Cache-Daten.

✅ Das richtige Favicon wird für jede Subdomain geladen. 🚀

Nach der Änderung:

sh

KopierenBearbeiten

sudo apachectl restart

Teste es dann erneut in einem Inkognito-Fenster.

Nikolaos:

httpd-vhosts.conf

Datei

favicon und eigener cache je Webdienst funktionieren noch nicht. Was mache ich an der Konfiguration von httpd.vhosts.conf falsch?

Sophos:

Hier sind die Hauptprobleme in deiner httpd-vhosts.conf, die dafür sorgen, dass das Favicon und der Cache für jede Subdomain nicht korrekt funktionieren:

1. DocumentRoot für wiki.aewi.de zeigt auf das falsche Verzeichnis

Der DocumentRoot für wiki.aewi.de zeigt aktuell auf:

apache

KopierenBearbeiten

DocumentRoot "/Library/WebServer/Documents"

Das bedeutet, dass favicon.ico von dort gesucht wird, statt aus dem richtigen MediaWiki-Verzeichnis.

Lösung:

Setze den DocumentRoot explizit auf den MediaWiki-Ordner:

apache

KopierenBearbeiten

DocumentRoot "/Library/WebServer/Documents/mediawiki"

Das sorgt dafür, dass alle statischen Dateien, einschließlich favicon.svg, richtig geladen werden.

2. Alias /favicon.ico ist mehrfach definiert

Du hast den Alias für das Favicon sowohl bei aewi.de als auch bei wiki.aewi.de gesetzt:

apache

KopierenBearbeiten

Alias /favicon.ico "/Library/WebServer/Documents/mediawiki/resources/assets/favicon.svg"

Problem: Apache verwendet das erste gefundene Favicon für alle Subdomains.

Lösung:

Entferne den Alias aus dem VirtualHost für aewi.de, da jede Subdomain ihr eigenes Favicon haben sollte.
Stelle sicher, dass wiki.aewi.de das richtige Favicon bereitstellt.

Korrigierter Block für wiki.aewi.de:

apache

KopierenBearbeiten

ServerAdmin webmaster@aewi.de

ServerName wiki.aewi.de

DocumentRoot "/Library/WebServer/Documents/mediawiki"

Alias /favicon.ico "/Library/WebServer/Documents/mediawiki/resources/assets/favicon.svg"

Options Indexes FollowSymLinks MultiViews

AllowOverride All

Require all granted

</Directory>

Header set Cache-Control "public, max-age=86400, must-revalidate"

</IfModule>

SSLEngine on

SSLCertificateFile "/etc/letsencrypt/live/aewi.de-0002/fullchain.pem"

SSLCertificateKeyFile "/etc/letsencrypt/live/aewi.de-0002/privkey.pem"

ErrorLog "/opt/homebrew/var/log/httpd/wiki_error.log"

CustomLog "/opt/homebrew/var/log/httpd/wiki_access.log" common

</VirtualHost>

Entferne den Alias aus dem Block für aewi.de, sodass er nicht überschrieben wird.

3. Cache-Control-Header wird möglicherweise von Let’s Encrypt überschrieben

Du hast mod_headers korrekt gesetzt, aber der Block für Let's Encrypt könnte eine Ausnahme darstellen. Versuche, den Cache-Control-Header für jede Subdomain spezifisch zu setzen und teste mit:

apache

KopierenBearbeiten

Header always set Cache-Control "public, max-age=86400, must-revalidate"

</IfModule>

Falls es immer noch nicht funktioniert, prüfe mit:

sh

KopierenBearbeiten

curl -I https://wiki.aewi.de/favicon.ico

Ob der Cache-Control-Header wirklich richtig ausgeliefert wird.

4. Apache-Cache & Browser-Cache zurücksetzen

Falls der Fehler immer noch besteht, liegt es möglicherweise an lokalen Caches. Setze Apache's Cache zurück:

sh

KopierenBearbeiten

sudo apachectl stop

sudo rm -rf /opt/homebrew/var/cache/httpd/*

sudo apachectl start

Danach den Browser-Cache nochmals löschen oder ein Inkognito-Fenster nutzen.

Jetzt sollte jede Subdomain ihr eigenes Favicon und einen separaten Cache haben! 🚀

Nikolaos:

in /opt/homebrew/var/cache/httpd/ ist keine einzige Datei enthalten – wo wird dann der Cache gespeichert?

Sophos:

Wenn in /opt/homebrew/var/cache/httpd/ keine Dateien vorhanden sind, nutzt Apache entweder keinen eigenen Cache, oder er speichert den Cache an einem anderen Ort.

1. Apache-Cache-Speicherorte prüfen

Apache kann Caching an verschiedenen Orten verwalten. Überprüfe folgende mögliche Verzeichnisse:

1.1 Überprüfe den Cache-Speicherort mit dem Apache-Modul mod_cache

Falls mod_cache aktiv ist, kannst du die Konfigurationsdatei prüfen:

sh

KopierenBearbeiten

grep -i "CacheRoot" /opt/homebrew/etc/httpd/httpd.conf

Falls dort eine Zeile wie diese erscheint:

nginx

KopierenBearbeiten

CacheRoot "/var/cache/apache2/proxy"

Dann speichert Apache dort seinen Cache.

Falls nichts zurückkommt, hat Apache kein konfiguriertes Cache-Verzeichnis.

1.2 Falls mod_cache aktiv ist, Cache-Ordner leeren

Falls mod_cache aktiv ist, lösche den Cache mit:

sh

KopierenBearbeiten

sudo rm -rf /var/cache/apache2/proxy/*

und starte Apache neu:

sh

KopierenBearbeiten

sudo apachectl restart

2. Prüfen, ob der Cache in mod_expires oder mod_headers aktiv ist

Falls der Apache-Cache nicht aktiv ist, aber die Subdomains trotzdem falsche Icons laden, könnte der Browser-Cache oder ein Reverse-Proxy (z. B. Cloudflare, Varnish) dazwischenfunken.

Überprüfe in der httpd.conf, ob mod_expires oder mod_headers aktiv ist:

sh

KopierenBearbeiten

grep -E 'mod_expires|mod_headers' /opt/homebrew/etc/httpd/httpd.conf

Falls aktiv, stelle sicher, dass jede Subdomain ihre eigenen Cache-Header setzt.

3. Prüfen, ob mod_cache_disk verwendet wird

Apache kann mod_cache_disk als Speicherort für den Cache nutzen. Suche nach einer Konfigurationsdatei mit:

sh

KopierenBearbeiten

grep -Ri "CacheDirLevels" /opt/homebrew/etc/httpd/

Falls es Treffer gibt, könnte Apache einen internen Disk-Cache haben, den du mit:

sh

KopierenBearbeiten

sudo rm -rf /var/cache/mod_cache_disk/*

leeren kannst.

Falls kein Apache-Cache aktiv ist, dann hält der Browser die alten Icons im Cache. In diesem Fall solltest du ein Inkognito-Fenster nutzen oder einen anderen Browser testen.

Nikolaos:

1. grep -i "CacheRoot" /opt/homebrew/etc/httpd/httpd.conf

ohne Antwort

2. CacheRoot "/var/cache/apache2/proxy"

zsh: command not found: CacheRoot

3. grep -E 'mod_expires|mod_headers' /opt/homebrew/etc/httpd/httpd.conf

#LoadModule expires_module lib/httpd/modules/mod_expires.so

LoadModule headers_module lib/httpd/modules/mod_headers.so

4. grep -Ri "CacheDirLevels" /opt/homebrew/etc/httpd/

ohne Antwort

was nun?

Sophos:

Da dein Apache keinen internen Cache aktiviert hat (kein CacheRoot, kein mod_cache_disk), liegt das Problem höchstwahrscheinlich an einem der folgenden Punkte:

1. Browser-Cache hält weiterhin alte Daten

Auch wenn du den Cache gelöscht hast, kann der Browser trotzdem die alten Daten aus einem anderen Speicherwiederherstellen.

Lösung: Erzwinge das Neuladen der Favicons

Führe in der Browser-Entwicklerkonsole (F12 → Konsole) Folgendes aus:

javascript

KopierenBearbeiten

fetch('/favicon.ico', { cache: 'reload' }).then(response => console.log(response));

Falls das Favicon immer noch falsch geladen wird, versuche:

sh

KopierenBearbeiten

curl -I https://wiki.aewi.de/favicon.ico

Falls dort eine Cache-Control-Zeile steht, die nicht das gewünschte Verhalten hat, ist der falsche Cache noch aktiv.

2. Überprüfen, ob der falsche VirtualHost greift

Falls das falsche Favicon geladen wird, könnte Apache immer noch den falschen VirtualHost als Standard behandeln. Prüfe mit:

sh

KopierenBearbeiten

sudo apachectl -S

Wenn wiki.aewi.de nicht korrekt als eigener VirtualHost angezeigt wird, könnte es sein, dass Apache weiterhin aewi.de als Standard verwendet.

Falls aewi.de zuerst kommt, versuche die Reihenfolge in httpd-vhosts.conf zu ändern:

Setze den VirtualHost für wiki.aewi.de ganz nach oben.
Starte Apache neu: sh KopierenBearbeiten sudo apachectl restart

3. Apache-Logs auf Fehler prüfen

Falls das Problem weiterhin besteht, überprüfe die Apache-Logs:

sh

KopierenBearbeiten

tail -f /opt/homebrew/var/log/httpd/aewi.de-error_log

Falls dort Fehler zu favicon.ico oder Headers erscheinen, könnte eine falsche Alias-Zuweisung das Problem verursachen.

Falls diese Schritte nicht helfen, kannst du versuchen, die favicon.ico direkt von einem anderen Ort zu laden, indem du eine absolute URL verwendest:

php

KopierenBearbeiten

$wgFavicon = "https://www.mediawiki.org/static/favicon/wikipedia.ico";

Das stellt sicher, dass kein lokales Caching mehr auftritt. 🚀

Nikolaos:

trotz das ich das favicon richtig gesetzt habe, bleibt immer das von phpmyadmin dominant.

Folgendes ist wirkungslos:

Alias /favicon.ico "/Library/WebServer/Documents/mediawiki/images/icons/Favicon.ico "

Das Muster für eine Webseite ist:

in irgendeinem Cache hängt das favicon von phpMyAdmnin

1. Prüfe, ob die Datei existiert und Zugriffsrechte sind richtig

2. Korrigiere den Alias in httpd-vhosts.conf: ist richtig eingetragen

curl -I https://wiki.aewi.de/Favicon.ico

HTTP/1.1 200 OK

Was mache ich falsch?

4/4

Sophos:

Da phpMyAdmin weiterhin das dominante Favicon bleibt, liegt das Problem höchstwahrscheinlich daran, dass der Browser oder Apache die Datei favicon.ico falsch zuweist oder cached. Hier sind die nächsten gezielten Schritte, um das Problem zu beheben:

1. Prüfen, ob das richtige Favicon ausgeliefert wird

Obwohl curl -I bereits eine 200 OK-Antwort liefert, könnte der Inhalt noch das falsche Icon sein.

Führe deshalb einen direkten Vergleich aus:

sh

KopierenBearbeiten

md5sum /Library/WebServer/Documents/mediawiki/images/icons/Favicon.ico

und lade dann das ausgelieferte Favicon herunter:

sh

KopierenBearbeiten

wget -O downloaded_favicon.ico https://wiki.aewi.de/Favicon.ico

md5sum downloaded_favicon.ico

Falls die Hashes unterschiedlich sind, wird noch immer das falsche Icon ausgeliefert.

2. Prüfen, welche Datei tatsächlich geladen wird

Öffne die Entwicklerkonsole (F12 in Chrome oder Firefox), dann:

Gehe zu „Netzwerkanalyse“ (Network)
Filtere nach „favicon“
Klicke auf den Request für favicon.ico
Prüfe den Response Headers → Location oder Content-Type

Falls dort phpMyAdmin oder ein anderer Pfad steht, ist noch eine falsche Zuweisung aktiv.

3. Erzwingen, dass wiki.aewi.de ein eigenes Favicon verwendet

Falls Alias /favicon.ico nicht greift, setze es direkt in der HTML-Vorlage von MediaWiki.

Bearbeite die Datei LocalSettings.php:

sh

KopierenBearbeiten

sudo nano /Library/WebServer/Documents/mediawiki/LocalSettings.php

Füge diese Zeile hinzu oder ändere sie:

php

KopierenBearbeiten

$wgFavicon = "/mediawiki/images/icons/Favicon.ico";

Falls das nicht greift, kannst du auch eine absolute URL setzen:

php

KopierenBearbeiten

$wgFavicon = "https://wiki.aewi.de/mediawiki/images/icons/Favicon.ico";

4. Apache zwingend auf das richtige Favicon leiten

Falls Apache immer noch das falsche Icon ausliefert, erzwinge es mit:

apache

KopierenBearbeiten

RedirectMatch 301 ^/favicon.ico$ https://wiki.aewi.de/mediawiki/images/icons/Favicon.ico

Füge das in den <VirtualHost>-Block für wiki.aewi.de.

5. Letzter Schritt: Browser-Cache endgültig umgehen

Falls alle Änderungen gemacht wurden, erzwinge eine Neulandung:

Öffne die Entwicklertools (F12) → Application Tab → Clear Storage

Oder direkt:

sh

KopierenBearbeiten

rm -rf ~/.cache/google-chrome

rm -rf ~/.mozilla/firefox

Jetzt den Browser neu starten.

Jetzt sollte wiki.aewi.de sein eigenes Favicon korrekt nutzen! 🚀

Nikolaos:

wir haben im Verlauf der Installation des M1 als Webserver die Dateien hosts, httpd.conf, httpd-ssl.conf, und httpd-vhosts.conf konfiguriert.

Ich verstehe deren Hierarchie nicht. "hosts" hattest du bereits gesagt, daß diese wahrscheinlich nicht mehr genutzt wird und eh nur ein Resolver auf 127.0.0.1 ist, der von dnsmasq erledigt wird. Wie ist die Hierarchie der anderen?

ist httpd-ssl.conf noch aktiv oder durch httpd-vhost.conf ersetzt?

kann httpd.conf dieses Verhalten mit favicon und cache der subdomains verursachen?

Sophos:

Die Hierarchie der Konfigurationsdateien von Apache auf deinem M1-Webserver sieht wie folgt aus:

1. httpd.conf (Hauptkonfigurationsdatei)

Funktion:

Lädt alle Module (z. B. mod_rewrite, mod_ssl, mod_vhost_alias).
Definiert Standardwerte für den gesamten Apache-Server.
Inkludiert andere Konfigurationsdateien (z. B. httpd-vhosts.conf und httpd-ssl.conf).

Relevanz für dein Problem:

✅ Ja, httpd.conf kann das Verhalten von Favicons und Cache beeinflussen, wenn dort mod_cache, mod_headersoder fehlerhafte Standard-Dokumentenpfade (DocumentRoot) gesetzt sind.

Prüfe, ob in httpd.conf problematische Einstellungen vorhanden sind:

sh

KopierenBearbeiten

grep -E 'Cache|Expires|DocumentRoot' /opt/homebrew/etc/httpd/httpd.conf

Falls dort mod_cache oder DocumentRoot auf /opt/homebrew/share/phpmyadmin zeigt, könnte das erklären, warum phpMyAdmin dominiert.

2. httpd-ssl.conf (Spezielle SSL-Konfiguration)

Funktion:

Definiert SSL-spezifische Einstellungen für Apache.
Enthält Zertifikate und TLS-Einstellungen.
Kann eigene VirtualHosts enthalten, aber wird oft durch httpd-vhosts.conf ersetzt.

Ist httpd-ssl.conf noch aktiv?

Das hängt davon ab, ob sie in httpd.conf eingebunden ist. Prüfe es mit:

sh

KopierenBearbeiten

grep httpd-ssl.conf /opt/homebrew/etc/httpd/httpd.conf

Falls du eine Zeile siehst wie:

apache

KopierenBearbeiten

Include etc/httpd/extra/httpd-ssl.conf

dann ist sie noch aktiv. Falls nicht, dann wurde sie durch httpd-vhosts.conf ersetzt.

3. httpd-vhosts.conf (Virtuelle Hosts für Subdomains)

Funktion:

Enthält alle spezifischen Domains und Subdomains.
Definiert eigene DocumentRoot, RewriteRules, Cache-Control, etc.
Wird von httpd.conf über eine Include-Direktive geladen.

Hierarchie mit httpd.conf und httpd-ssl.conf

Falls httpd-vhosts.conf aktiv ist, überschreibt es httpd.conf.
Falls httpd-ssl.conf aktiv ist, überschreibt es httpd-vhosts.conf für SSL-spezifische Einstellungen.

Prüfe, ob httpd-vhosts.conf aktiv geladen wird:

sh

KopierenBearbeiten

grep httpd-vhosts.conf /opt/homebrew/etc/httpd/httpd.conf

Falls du diese Zeile findest:

apache

KopierenBearbeiten

Include etc/httpd/extra/httpd-vhosts.conf

Dann ist httpd-vhosts.conf für alle Subdomains aktiv.

Zusammenfassung der Apache-Hierarchie:

httpd.conf → lädt Module und Basis-Konfiguration.
httpd-ssl.conf (wenn aktiv) → definiert SSL für Apache.
httpd-vhosts.conf → definiert die Subdomains und kann httpd-ssl.conf überschreiben.
hosts-Datei → für lokale DNS-Overrides (bei dir ersetzt durch dnsmasq).

Da httpd.conf die Hauptkonfiguration verwaltet, kann sie tatsächlich das Verhalten von Favicon und Cache für Subdomains beeinflussen. Falls dort fehlerhafte DocumentRoot-Einstellungen oder mod_cache-Regeln existieren, könnte das phpMyAdmin-Favicon überschrieben werden.

Lösung:

Prüfe die genannten Einstellungen in httpd.conf.
Falls nötig, korrigiere oder entferne problematische Cache- oder Alias-Regeln.
Starte Apache neu: sh KopierenBearbeiten sudo apachectl restart

Jetzt sollten Subdomains ihr eigenes Favicon und Cache-Verhalten haben! 🚀

Nikolaos:

1. grep -E 'Cache|Expires|DocumentRoot' /opt/homebrew/etc/httpd/httpd.conf

# DocumentRoot: The directory out of which you will serve your

# DocumentRoot "/Library/WebServer/Documents"

DocumentRoot "/Library/WebServer/Documents/aewi"

# access content that does not live under the DocumentRoot.

2. grep httpd-ssl.conf /opt/homebrew/etc/httpd/httpd.conf

Include /opt/homebrew/etc/httpd/extra/httpd-ssl.conf

3. grep httpd-vhosts.conf /opt/homebrew/etc/httpd/httpd.conf

Include /opt/homebrew/etc/httpd/extra/httpd-vhosts.conf

in den Dateien stehen voneinander abweichende Einstellungen, vergleichsweisehat httpd-ssl.conf noch alte Zertifikate enthalten. In httpd.conf stehen gleiche oder andere Konfigurationen wie in httpd-vhosts.conf.

Sophos:

Da deine httpd.conf, httpd-ssl.conf und httpd-vhosts.conf teilweise widersprüchliche oder doppelte Einstellungen enthalten, solltest du eine einheitliche Struktur herstellen, um Fehler wie das falsche Favicon oder Caching-Problemezu vermeiden.

Schritt 1: Kollisionen zwischen den Dateien auflösen

Die Reihenfolge der Apache-Ladereihenfolge ist:

httpd.conf (Hauptkonfiguration) → Definiert Standardwerte und lädt Module → Lädt httpd-ssl.conf und httpd-vhosts.conf
httpd-ssl.conf (wenn aktiviert) → Definiert SSL-Parameter und Zertifikate
httpd-vhosts.conf → Definiert Subdomains, eigene Regeln für VirtualHosts → Überschreibt httpd.conf, falls nötig

🔍 Problem:

httpd.conf enthält eine DocumentRoot-Definition, die mit httpd-vhosts.conf in Konflikt stehen könnte.
httpd-ssl.conf hat alte Zertifikate, die ggf. nicht mehr gültig sind.
Eventuell gibt es doppelte oder fehlerhafte Alias /favicon.ico-Zuweisungen.

Schritt 2: Überflüssige Einstellungen aus httpd.conf entfernen

Da httpd-vhosts.conf für die Subdomains verantwortlich ist, kannst du in httpd.conf unnötige oder kollidierende Einstellungen auskommentieren oder entfernen:

Öffne httpd.conf:

sh

KopierenBearbeiten

sudo nano /opt/homebrew/etc/httpd/httpd.conf

Entferne oder kommentiere alle redundanten DocumentRoot-Einträge:

apache

KopierenBearbeiten

# DocumentRoot "/Library/WebServer/Documents"

# DocumentRoot "/Library/WebServer/Documents/aewi"

Lass nur diesen Eintrag aktiv:

apache

KopierenBearbeiten

Include /opt/homebrew/etc/httpd/extra/httpd-vhosts.conf

Falls mod_cache oder mod_expires geladen wird, deaktiviere es testweise:

apache

KopierenBearbeiten

#LoadModule cache_module lib/httpd/modules/mod_cache.so

#LoadModule cache_disk_module lib/httpd/modules/mod_cache_disk.so

#LoadModule expires_module lib/httpd/modules/mod_expires.so

Speichern mit CTRL + X, Y, ENTER.

Schritt 3: httpd-ssl.conf aufräumen

Da du httpd-vhosts.conf für die SSL-Subdomains nutzt, kannst du httpd-ssl.conf entweder vollständig deaktivieren oder nur die relevanten Zertifikate aktualisieren.

Option A: httpd-ssl.conf deaktivieren (empfohlen)

Falls alle SSL-Konfigurationen in httpd-vhosts.conf geregelt werden, dann entferne httpd-ssl.conf aus httpd.conf:

sh

KopierenBearbeiten

sudo nano /opt/homebrew/etc/httpd/httpd.conf

Kommentiere diese Zeile aus:

apache

KopierenBearbeiten

#Include /opt/homebrew/etc/httpd/extra/httpd-ssl.conf

Speichern, dann Apache neu starten:

sh

KopierenBearbeiten

sudo apachectl restart

Falls du es nicht deaktivieren möchtest, stelle sicher, dass die SSL-Zertifikate und Einstellungen mit httpd-vhosts.conf übereinstimmen.

Schritt 4: httpd-vhosts.conf bereinigen

Jetzt stellst du sicher, dass jede Subdomain nur in httpd-vhosts.conf geregelt wird.

Falls Alias /favicon.ico für jede Subdomain doppelt definiert ist, behalte nur eine Instanz pro VirtualHost.

Falls weiterhin das phpMyAdmin-Favicon dominant ist, versuche:

apache

KopierenBearbeiten

RedirectMatch 301 ^/favicon.ico$ /mediawiki/images/icons/Favicon.ico

in den wiki.aewi.de-VirtualHost zu setzen.

Schritt 5: Apache-Cache & Browser-Cache endgültig leeren

Da sich viele Konfigurationen geändert haben, bereinige Apache und den Browser:

sh

KopierenBearbeiten

sudo apachectl stop

sudo rm -rf /opt/homebrew/var/cache/httpd/*

sudo apachectl start

Browser-Cache löschen:

Chrome: chrome://settings/clearBrowserData
Firefox: about:preferences#privacy → „Cache leeren“

Jetzt sollte dein Webserver eindeutige Subdomains, sauberes Favicon-Handling und korrekten Cache haben! 🚀

Nikolaos:

httpd.conf

Datei

httpd-vhosts.conf

Datei

vergleiche bitte die beiden Dateien und benenne mir deren Abweichungen oder Fehler.

Sophos:

Hier sind die wichtigsten Abweichungen und möglichen Fehler zwischen httpd.conf und httpd-vhosts.conf:

1. Konflikte bei DocumentRoot

httpd.conf: apache KopierenBearbeiten DocumentRoot "/Library/WebServer/Documents/aewi"
httpd-vhosts.conf: apache KopierenBearbeiten <VirtualHost *:443>
ServerName aewi.de
DocumentRoot "/Library/WebServer/Documents/aewi"
</VirtualHost>
<VirtualHost *:443>
ServerName wiki.aewi.de
DocumentRoot "/Library/WebServer/Documents"
</VirtualHost>

🔴 Problem:

httpd.conf setzt DocumentRoot auf "/Library/WebServer/Documents/aewi", aber wiki.aewi.de hat in httpd-vhosts.conf eine abweichende DocumentRoot-Definition.
Wenn httpd.conf als Standard greift, könnte wiki.aewi.de den falschen DocumentRoot verwenden.

✅ Lösung:

Entferne DocumentRoot "/Library/WebServer/Documents/aewi" aus httpd.conf, da httpd-vhosts.confbereits DocumentRoot für alle VirtualHosts definiert.

2. Alias /favicon.ico überschneidet sich oder ist falsch gesetzt

In httpd-vhosts.conf für wiki.aewi.de: apache KopierenBearbeiten Alias /favicon.ico "/Library/WebServer/Documents/mediawiki/images/icons/Favicon.ico "
Es gibt kein Alias /favicon.ico für pma.aewi.de, aber phpMyAdmin setzt sein eigenes Icon, was dominant sein könnte.

🔴 Problem:

Falls ein übergeordneter Alias /favicon.ico in httpd.conf existiert, überschreibt dieser die Einstellung für wiki.aewi.de.
In httpd-vhosts.conf ist nach Favicon.ico ein Leerzeichen, was unter Umständen zu Problemen führen kann.

✅ Lösung:

Entferne alle Alias /favicon.ico-Zuweisungen aus httpd.conf.
Korrigiere das Alias in httpd-vhosts.conf: apache KopierenBearbeiten Alias /favicon.ico "/Library/WebServer/Documents/mediawiki/images/icons/Favicon.ico"

3. httpd-ssl.conf wird geladen, aber httpd-vhosts.conf regelt auch SSL

In httpd.conf: apache KopierenBearbeiten Include /opt/homebrew/etc/httpd/extra/httpd-ssl.conf
In httpd-vhosts.conf: apache KopierenBearbeiten <VirtualHost *:443>
SSLEngine on
SSLCertificateFile "/etc/letsencrypt/live/aewi.de-0002/fullchain.pem"
SSLCertificateKeyFile "/etc/letsencrypt/live/aewi.de-0002/privkey.pem"
</VirtualHost>

🔴 Problem:

SSL-Konfiguration könnte doppelt geladen werden, wenn sowohl httpd-ssl.conf als auch httpd-vhosts.conf SSL-Einstellungen haben.

✅ Lösung:

Falls httpd-vhosts.conf bereits SSL regelt, deaktiviere httpd-ssl.conf in httpd.conf:

apache

KopierenBearbeiten

#Include /opt/homebrew/etc/httpd/extra/httpd-ssl.conf

Und starte Apache neu:

sh

KopierenBearbeiten

sudo apachectl restart

4. mod_cache und mod_expires sind in httpd.conf deaktiviert, aber in httpd-vhosts.conf genutzt

In httpd.conf: apache KopierenBearbeiten #LoadModule cache_module lib/httpd/modules/mod_cache.so
#LoadModule cache_disk_module lib/httpd/modules/mod_cache_disk.so
#LoadModule expires_module lib/httpd/modules/mod_expires.so
In httpd-vhosts.conf: apache KopierenBearbeiten <IfModule mod_headers.c>
Header always set Cache-Control "public, max-age=86400, must-revalidate"
</IfModule>

🔴 Problem:

Falls mod_cache oder mod_expires benötigt wird, ist es in httpd.conf auskommentiert und könnte dadurch nicht greifen.

✅ Lösung:

Falls Caching aktiv sein soll, aktiviere mod_cache und mod_expires in httpd.conf:

apache

KopierenBearbeiten

LoadModule cache_module lib/httpd/modules/mod_cache.so

LoadModule cache_disk_module lib/httpd/modules/mod_cache_disk.so

LoadModule expires_module lib/httpd/modules/mod_expires.so

Starte Apache neu:

sh

KopierenBearbeiten

sudo apachectl restart

5. pma.aewi.de setzt möglicherweise eine dominante Weiterleitung

In httpd-vhosts.conf für pma.aewi.de: apache KopierenBearbeiten RewriteEngine On
RewriteCond %{HTTP_HOST} ^pma\.aewi\.de$ [NC]
RewriteCond %{REQUEST_URI} ^/$
RewriteRule ^/?$ https://pma.aewi.de/phpmyadmin/index.php? [R=301,L]

🔴 Problem:

Falls diese Regel auch auf wiki.aewi.de wirkt, könnte sie falsche Header oder das falsche Favicon setzen.

✅ Lösung:

Stelle sicher, dass die Regeln nicht global aktiv sind.
Prüfe mit: sh KopierenBearbeiten curl -I https://wiki.aewi.de/favicon.ico
Falls pma.aewi.de als Weiterleitung erscheint, wurde die falsche Rewrite-Regel angewendet.

Zusammenfassung der Hauptprobleme & Lösungen

Problem	Lösung
Doppelte DocumentRoot in httpd.conf und httpd-vhosts.conf	Entferne DocumentRoot aus httpd.conf
Alias /favicon.ico in httpd-vhosts.conf hat Leerzeichen	Korrigiere das Alias
SSL ist doppelt in httpd-ssl.conf & httpd-vhosts.conf	Deaktiviere httpd-ssl.conf
mod_cache und mod_expires sind in httpd.confauskommentiert	Falls benötigt, aktiviere sie
Rewrite-Regel von pma.aewi.de könnte andere Subdomains beeinflussen	Prüfe mit curl -I https://wiki.aewi.de/favicon.ico

Nach diesen Änderungen sollte jede Subdomain ihr eigenes Favicon und Cache-Verhalten haben. 🚀

2/2

Nikolaos:

1. Der Fehler mit dem phpMyAdmin und Favicon ist durch deaktivieren von DocumentRoot "/Library/WebServer/Documents/aewi" in httpd.conf gelöst worden.

2. Mediawiki ist nicht mehr online wenn ich folgende Module aktiviere:

LoadModule cache_module lib/httpd/modules/mod_cache.so

LoadModule cache_disk_module lib/httpd/modules/mod_cache_disk.so

LoadModule expires_module lib/httpd/modules/mod_expires.so

3. ich nehme an, daß die Dateien host und httpd-ssl.conf sich auf das native Apache und die Dateien httpd.conf und httpd-vhosts.conf auf homebrew httpd Apache beziehen – richtig?

Sophos:

Ja, deine Annahme ist korrekt! Hier ist die genaue Aufschlüsselung:

/etc/hosts (falls vorhanden) → Diese Datei dient nur der lokalen Namensauflösung und hat nichts mit Apache direkt zu tun.
- Da du dnsmasq nutzt, wird hosts vermutlich nicht mehr verwendet.

httpd-ssl.conf → Gehört zum nativen Apache auf macOS und definiert standardmäßig die SSL-Konfiguration.

- Da du Homebrew-Apache verwendest (httpd über Homebrew installiert), könnte diese Datei veraltet sein oder inaktiv sein.
- Falls httpd-vhosts.conf bereits SSL regelt, ist httpd-ssl.conf überflüssig.

httpd.conf und httpd-vhosts.conf → Diese gehören zu Homebrew Apache (/opt/homebrew/etc/httpd/)und steuern den aktuellen Webserver.

- httpd.conf → Lädt Module und definiert globale Einstellungen.
- httpd-vhosts.conf → Enthält die spezifischen Subdomains und VirtualHosts.

Warum ist MediaWiki nach Aktivierung der Caching-Module offline?

Mögliche Gründe:
1. mod_cache oder mod_expires kollidiert mit mod_rewrite von MediaWiki → Falls mod_cache URLs zwischenspeichert, kann es sein, dass MediaWiki-Anfragen nicht korrekt verarbeitet werden.
2. Apache versucht zwischengespeicherte Versionen von MediaWiki-Seiten zu laden → Falls MediaWiki Header wie Cache-Control: no-cache sendet, gibt es Konflikte.
Lösung: Falls Caching benötigt wird, kann mod_cache selektiv deaktiviert werden nur für MediaWiki, indem du in httpd-vhosts.conf für wiki.aewi.de folgendes einfügst: apache KopierenBearbeiten <VirtualHost *:443>
ServerName wiki.aewi.de
DocumentRoot "/Library/WebServer/Documents/mediawiki"
<Directory "/Library/WebServer/Documents/mediawiki">
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Require all granted
</Directory>
# Caching explizit für MediaWiki-Seiten deaktivieren
<IfModule mod_cache.c>
CacheDisable /
</IfModule>
<IfModule mod_expires.c>
ExpiresActive Off
</IfModule>
SSLEngine on
SSLCertificateFile "/etc/letsencrypt/live/aewi.de-0002/fullchain.pem"
SSLCertificateKeyFile "/etc/letsencrypt/live/aewi.de-0002/privkey.pem"
</VirtualHost>

Falls du Caching global aktivieren, aber MediaWiki ausnehmen möchtest, kannst du mod_cache in httpd.conf aktiv lassen und CacheDisable nur in httpd-vhosts.conf für wiki.aewi.de setzen.

Jetzt sollte dein Setup sauber laufen! 🚀

Nikolaos:

Ich versuche die Sache mal anders anzugehen.

httpd.conf fällt dadurch auf, daß es vor allem zu ladende Module und grundlegendste Einstellungen zu Ports etc. enthält und httpd-vhosts fällt dadurch auf, daß es die eigentlichen http und https Dienste als Hosts konfiguriert.

Richtig?`

Sophos:

Ja, genau richtig!

Zusammenfassung der Aufgaben beider Dateien:

httpd.conf (globale Apache-Konfiguration)
- Lädt die Apache-Module (LoadModule).
- Setzt globale Servereinstellungen wie:
  - Ports (Listen 80, Listen 443).
  - Standard DocumentRoot (falls httpd-vhosts.conf nicht greift).
  - Globale Directory-Regeln (z. B. AllowOverride für .htaccess).
- Inkludiert weitere Konfigurationsdateien (Include), z. B.: apache KopierenBearbeiten Include /opt/homebrew/etc/httpd/extra/httpd-vhosts.conf
- Include /opt/homebrew/etc/httpd/extra/httpd-ssl.conf
- Hauptaufgabe: Globale Steuerung und Modulverwaltung.

httpd-vhosts.conf (VirtualHosts-Konfiguration)

- Definiert spezifische Hosts und Subdomains (ServerName, ServerAlias).
- Legt für jede Website/Subdomain ein eigenes DocumentRoot fest.
- Setzt Rewrite-Regeln (mod_rewrite).
- Enthält SSL-Einstellungen (falls nicht in httpd-ssl.conf ausgelagert).
- Kann Cache- und Header-Regeln für einzelne Domains/Subdomains setzen.

Fazit:

✅ httpd.conf → Steuert Apache global und lädt Module.

✅ httpd-vhosts.conf → Konfiguriert konkrete Webseiten und Subdomains.

Falls ein VirtualHost definiert ist, überschreibt er globale DocumentRoot-Einstellungen aus httpd.conf. 🚀

Nikolaos:

Warum definiere ich dann "ServerName aewi.de" in httpd.conf und dann nochmals in htppd-vhost.conf? Warum nicht nur einmal?

Sophos:

Gute Frage! Das liegt an der Unterschiedlichkeit der Rollen von httpd.conf und httpd-vhosts.conf in Apache.

Warum ServerName in beiden Dateien auftaucht

In httpd.conf: apache KopierenBearbeiten ServerName aewi.de
→ Diese Zeile gibt Apache einen Standard-Hostnamen, falls kein passender VirtualHost gefunden wird. → Falls httpd-vhosts.conf nicht geladen ist oder ein Fehler hat, würde Apache ohne diese Zeile nicht starten.
In httpd-vhosts.conf: apache KopierenBearbeiten <VirtualHost *:443>
ServerName aewi.de
</VirtualHost>
→ Hier wird der tatsächliche Host für aewi.de konfiguriert (z. B. mit DocumentRoot, SSL, Logs etc.). → VirtualHosts überschreiben die globale ServerName-Angabe aus httpd.conf.

Könnte man ServerName aewi.de aus httpd.conf entfernen?

✅ Ja, wenn httpd-vhosts.conf immer geladen wird.

❌ Nein, falls es ein Fallback braucht.

Falls du sicherstellen willst, dass Apache immer einen definierten Standard-Host hat, kannst du es so lösen:

Belasse ServerName in httpd.conf, aber nur als Fallback für Fehlerfälle: apache KopierenBearbeiten ServerName localhost
Konfiguriere aewi.de nur in httpd-vhosts.conf.

Ergebnis:

Apache hat immer einen Startwert (localhost), falls httpd-vhosts.conf nicht geladen wird.
Jede Domain wird nur einmal in httpd-vhosts.conf konfiguriert. 🚀

Nikolaos:

Was für ein Fallöback Fall könnte auftreten? wenn nur httpd.conf geladen werden würde, wäre der Server unbrauchbar –richtig?

im Grunde könnte ich auch alles aus httpd-vhosts.conf in httpd.conf konfigurieren – richtig?

Sophos:

Ja, du hast es genau richtig erfasst!

1. Warum gibt es ServerName als Fallback in httpd.conf?

Das ist ein historisches Apache-Design, um zu verhindern, dass Apache ohne gültigen ServerName startet.

Falls kein ServerName gesetzt ist, gibt Apache beim Start eine Warnung aus: vbnet KopierenBearbeiten AH00558: httpd: Could not reliably determine the server's fully qualified domain name
Ein ServerName in httpd.conf stellt sicher, dass Apache auch ohne httpd-vhosts.conf startet, selbst wenn er dann keinen echten VirtualHost hat.

Aber du hast völlig recht:

👉 Falls httpd-vhosts.conf nicht geladen wird, ist der Server unbrauchbar, weil keine Websites definiert sind.

➡️ Fazit:

✅ Du kannst ServerName aus httpd.conf entfernen, solange httpd-vhosts.conf immer geladen wird.

2. Könnte man alles aus httpd-vhosts.conf in httpd.conf schreiben?

✅ Ja, technisch ist das möglich!

❌ Aber es wäre eine schlechte Idee.

Warum?

📌 Trennung von globalen & host-spezifischen Einstellungen

httpd.conf verwaltet globale Servereinstellungen (Module, Ports, Logging).
httpd-vhosts.conf hält die Websites & Subdomains getrennt.
Falls du mehrere Domains/Subdomains hast, wäre eine httpd.conf mit allem drin unübersichtlich und schwer wartbar.

📌 Flexibilität für Änderungen

Wenn du httpd-vhosts.conf separat hältst, kannst du neue Domains leicht hinzufügen oder ändern, ohne die Hauptkonfiguration (httpd.conf) anzufassen.

📌 Updates & Kompatibilität

Viele Linux-Distributionen, Homebrew & macOS erwarten die Trennung.
Falls du Apache später updatest oder auf einen neuen Server migrierst, bleibt die Trennung von httpd.confund httpd-vhosts.conf ein Vorteil.

➡️ Fazit:

🔹 Ja, du könntest alles in httpd.conf packen, aber es wäre chaotisch & unpraktisch.

🔹 Die Trennung macht Wartung, Erweiterung und Fehleranalyse viel einfacher. 🚀

Nikolaos:

OK Danke. Verstanden.

Warum laden wir in httpd.conf "Include /opt/homebrew/etc/httpd/extra/httpd-phpmyadmin.conf" welches folgendes lediglich enthält?:

Alias /phpmyadmin /opt/homebrew/share/phpmyadmin

Require all granted

</Directory>

Dies steht doch auch im Grunde in httpd-vhost.conf – oder?

Sophos:

Gute Frage! Warum wird httpd-phpmyadmin.conf extra geladen, wenn phpMyAdmin bereits in httpd-vhosts.confdefiniert ist?

1. Was macht httpd-phpmyadmin.conf genau?

apache

KopierenBearbeiten

Alias /phpmyadmin /opt/homebrew/share/phpmyadmin

Require all granted

</Directory>

📌 Was passiert hier?

Es definiert eine Alias-Weiterleitung, damit phpMyAdmin über /phpmyadmin erreichbar ist, unabhängig von einer Domain.
Es erlaubt globalen Zugriff auf /opt/homebrew/share/phpmyadmin, sodass es in jeder Domain aufgerufen werden könnte.

2. Warum ist das in httpd-vhosts.conf eigentlich schon enthalten?

In httpd-vhosts.conf gibt es bereits:

apache

KopierenBearbeiten

ServerName pma.aewi.de

DocumentRoot "/opt/homebrew/share/phpmyadmin"

</VirtualHost>

📌 Unterschied zu httpd-phpmyadmin.conf:

Hier ist phpMyAdmin nur unter pma.aewi.de erreichbar.
Ohne httpd-phpmyadmin.conf kannst du phpMyAdmin nicht über aewi.de/phpmyadmin oder wiki.aewi.de/phpmyadmin aufrufen.

3. Kann httpd-phpmyadmin.conf entfernt werden?

✅ Ja, wenn du phpMyAdmin nur unter pma.aewi.de nutzen möchtest.

❌ Nein, falls du phpMyAdmin auch über aewi.de/phpmyadmin oder andere Subdomains brauchst.

➡️ Fazit:

🔹 Falls du phpMyAdmin nur unter pma.aewi.de nutzen willst, kannst du Include httpd-phpmyadmin.conf aus httpd.conf entfernen.

🔹 Falls du es zusätzlich global über /phpmyadmin in jeder Domain aufrufen willst, dann lass die Include-Anweisung in httpd.conf aktiv. 🚀

Nikolaos:

ich habe es ausgeschaltet. Ich habe extra die Subdomains zur Trennung der Dienste mit Zertifikaten für jede subdomain eingerichtet, weil du es so empfohlen hattest. Beide Wege zu konfigurieren und zu laden ergibt für mich keinen Sinn – oder?

Es wird in httpd.conf. "Include /opt/homebrew/etc/httpd/extra/proxy-html.conf" geladen. Diese Datei gibt es in dem Verzeichnis nicht und Proxy wird in httpd-vhosts.conf geregelt. Kann dann auch ausgeschaltet werden – oder?

Sophos:

Ja, du hast es genau richtig erkannt!

1. httpd-phpmyadmin.conf abschalten ✅

Da du für jede Subdomain eigene VirtualHosts mit SSL-Zertifikaten nutzt, ist es sinnlos und redundant, phpMyAdmin zusätzlich global unter /phpmyadmin erreichbar zu machen.

➡️ Fazit:

✅ Include /opt/homebrew/etc/httpd/extra/httpd-phpmyadmin.conf kann in httpd.conf entfernt oder auskommentiert werden.

2. proxy-html.conf abschalten, weil Datei nicht existiert ✅

Apache versucht in httpd.conf folgendes zu laden:

apache

KopierenBearbeiten

Include /opt/homebrew/etc/httpd/extra/proxy-html.conf

Aber diese Datei existiert nicht.

➡️ Folge:

Apache gibt beim Start eine Warnung oder Fehlermeldung aus (AH00526: Syntax error: File not found).
Proxy-Einstellungen sind bereits in httpd-vhosts.conf geregelt.

➡️ Fazit:

✅ Include /opt/homebrew/etc/httpd/extra/proxy-html.conf kann in httpd.conf entfernt oder auskommentiert werden.

Allgemeines Fazit:

🔹 Doppelte oder nicht vorhandene Includes rauswerfen verbessert die Performance und reduziert mögliche Fehlerquellen.

🔹 Deine aktuelle Trennung von Diensten per Subdomains ist jetzt sauber und logisch aufgebaut! 🚀

Nikolaos:

httpd.conf

Datei

Wir haben in mehreren Kreisläufen verschiedenste Sachen installiert und uns so von Stufe zu Stufe zu dem was jetzt ist hin entwickelt. Dabei haben wir aufgrund von Fehlermeldungen auch hier und da etwas probiert, jedoch gewiß nicht wieder alles ausgetragen und zurückgestellt oder gelöscht, was wir nicht mehr brauchten oder dann doch anders gemacht haben.

Der M1 sollte anders als üblich installiert werden, da er nicht öffentlich sein soll und auch ich nicht für dessen Schutz sorgen kann. Daher mag so manches anders sein als gewöhnlich und üblich.

Überprüfe nochmals die httpd.conf auf Fehler oder Überflüssige Anteile und gebe eine Liste der Änderungen oder Fragen aus.

Sophos:

Hier sind die empfohlenen Änderungen, Bereinigungen und Fragen für deine httpd.conf basierend auf meiner Analyse:

1. Überflüssige oder nicht vorhandene Includes entfernen

Folgende Includes sind entweder überflüssig oder existieren nicht:

🔹 Include /opt/homebrew/etc/httpd/extra/proxy-html.conf

🔴 Problem: Die Datei existiert nicht und sollte auskommentiert oder entfernt werden.
✅ Lösung: Entferne oder kommentiere es so aus: apache KopierenBearbeiten # Include /opt/homebrew/etc/httpd/extra/proxy-html.conf

🔹 Include /opt/homebrew/etc/httpd/extra/httpd-ssl.conf

🔴 Problem: Falls alle SSL-Einstellungen in httpd-vhosts.conf definiert sind, ist diese Datei unnötig und kann Konflikte verursachen.
✅ Lösung: Falls httpd-ssl.conf nicht benötigt wird, auskommentieren: apache KopierenBearbeiten # Include /opt/homebrew/etc/httpd/extra/httpd-ssl.conf

🔹 Include /opt/homebrew/etc/httpd/extra/httpd-phpmyadmin.conf

🔴 Problem: Du hast phpMyAdmin über pma.aewi.de als eigene Subdomain konfiguriert. Das Include ist daher überflüssig.
✅ Lösung: Auskommentieren oder entfernen: apache KopierenBearbeiten # Include /opt/homebrew/etc/httpd/extra/httpd-phpmyadmin.conf

2. Problematische DocumentRoot-Einträge entfernen

🔹 Mehrere DocumentRoot-Definitionen existieren in der Datei.

DocumentRoot "/Library/WebServer/Documents"
DocumentRoot "/Library/WebServer/Documents/aewi"
🔴 Problem: In httpd-vhosts.conf sind bereits alle DocumentRoot-Einstellungen für jede Subdomain definiert.
✅ Lösung: Entferne alle DocumentRoot-Einträge in httpd.conf: apache KopierenBearbeiten # DocumentRoot "/Library/WebServer/Documents"
# DocumentRoot "/Library/WebServer/Documents/aewi"

3. Problematisches ServerName

🔹 ServerName aewi.de ist in httpd.conf definiert, aber auch in httpd-vhosts.conf.

🔴 Problem: Falls httpd-vhosts.conf geladen wird, ist ServerName in httpd.conf überflüssig.
✅ Lösung: Falls du es nicht als Fallback brauchst, entferne es oder setze stattdessen: apache KopierenBearbeiten ServerName localhost

4. Unnötige oder problematische Module entfernen

🔹 Folgende Module sind deaktiviert, aber wurden früher aktiviert oder ausprobiert. Falls du sie nicht brauchst, kannst du sie komplett entfernen:

mod_cache
mod_cache_disk
mod_expires
mod_proxy_html
✅ Lösung: Falls Caching oder Proxy für proxy_html nicht verwendet wird, entferne sie komplett aus der Datei: apache KopierenBearbeiten # LoadModule cache_module lib/httpd/modules/mod_cache.so
# LoadModule cache_disk_module lib/httpd/modules/mod_cache_disk.so
# LoadModule expires_module lib/httpd/modules/mod_expires.so
# LoadModule proxy_html_module lib/httpd/modules/mod_proxy_html.so

5. Directory-Block für /Library/WebServer/Documents/aewi aufräumen

🔹 Aktuell in httpd.conf:

apache

KopierenBearbeiten

AllowOverride All

Options Indexes FollowSymLinks

AllowOverride None

Require all granted

</Directory>

🔴 Problem:
- AllowOverride All und AllowOverride None widersprechen sich.
- DocumentRoot wird in httpd-vhosts.conf geregelt, also ist dieser Block überflüssig.
✅ Lösung: Falls dieser Block nicht für einen speziellen Zweck benötigt wird, entferne ihn komplett.

6. Sonstige Optimierungen

🔹 Port 8080 wird nicht genutzt, kann entfernt werden

apache

KopierenBearbeiten

Listen 8080

✅ Falls kein Dienst diesen Port nutzt, entferne diese Zeile.

🔹 KeepAlive optimieren

apache

KopierenBearbeiten

KeepAlive On

MaxKeepAliveRequests 100

KeepAliveTimeout 5

Falls der Server hohe Last hat, könnte ein niedrigerer KeepAliveTimeout helfen (z. B. 2 statt 5).

Zusammenfassung der Änderungen

Änderung	Grund	Lösung
Include /opt/homebrew/etc/httpd/extra/proxy-html.conf entfernen	Datei existiert nicht	# Include /opt/homebrew/etc/httpd/extra/proxy-html.conf
Include /opt/homebrew/etc/httpd/extra/httpd-ssl.conf entfernen	Falls httpd-vhosts.confSSL regelt	# Include /opt/homebrew/etc/httpd/extra/httpd-ssl.conf
Include /opt/homebrew/etc/httpd/extra/httpd-phpmyadmin.conf entfernen	phpMyAdmin ist über pma.aewi.de konfiguriert	# Include /opt/homebrew/etc/httpd/extra/httpd-phpmyadmin.conf
DocumentRoot-Einträge entfernen	Wird bereits in httpd-vhosts.conf gesetzt	# DocumentRoot "/Library/WebServer/Documents/aewi"
ServerName aewi.de durch localhostersetzen	httpd-vhosts.conf regelt ServerNames	ServerName localhost
Unnötige Module (mod_cache, mod_expires, mod_proxy_html) entfernen	Werden nicht genutzt, könnten Probleme verursachen	# LoadModule cache_module lib/httpd/modules/mod_cache.so
<Directory "/Library/WebServer/Documents/aewi">entfernen	Wird von httpd-vhosts.conf geregelt	Komplett entfernen
Port 8080 entfernen (Listen 8080)	Falls nicht genutzt	# Listen 8080

Fazit

✅ Nach diesen Änderungen ist die httpd.conf aufgeräumt, optimiert und konfliktfrei!

✅ httpd-vhosts.conf regelt nun vollständig alle Webseiten & Subdomains.

✅ Kein unnötiges Laden von Modulen oder Includes, die nicht gebraucht werden.

🚀 Jetzt ist der Webserver sauber & effizient konfiguriert!

Nikolaos:

Habe ich bereinigt.

"Include /opt/homebrew/etc/httpd/extra/httpd-phpmyadmin.conf" mußte ich wieder aktivieren, da sonst phpMyAdmin nicht erreichbar ist.

Wenn ein Eintrag enthalten ist wie folgt:

#

# ScriptSock: On threaded servers, designate the path to the UNIX

# socket used to communicate with the CGI daemon of mod_cgid.

#

#Scriptsock cgisock

</IfModule>

Dann ist zwischen "<IfModule cgid_module>" und "</IfModule>" nichts aktiv und der Eintrag könnte komplett mit # versehen werden, oder?

Sophos:

Ja, genau! 🎯

Wenn innerhalb des <IfModule>-Blocks alles auskommentiert ist, also:

apache

KopierenBearbeiten

#

# ScriptSock: On threaded servers, designate the path to the UNIX

# socket used to communicate with the CGI daemon of mod_cgid.

#

#Scriptsock cgisock

</IfModule>

dann wird kein aktiver Befehl ausgeführt.

✅ Lösung:

Du kannst den gesamten Block entweder vollständig entfernen oder auskommentieren:

apache

KopierenBearbeiten

# <IfModule cgid_module>

# #

# # ScriptSock: On threaded servers, designate the path to the UNIX

# # socket used to communicate with the CGI daemon of mod_cgid.

# #

# #Scriptsock cgisock

# </IfModule>

🔹 Falls du CGI nicht nutzt (z. B. für Perl oder Python-Skripte), kann der Block weg.

🔹 Falls du unsicher bist, lass ihn einfach auskommentiert, dann kannst du ihn später reaktivieren. 🚀

Nikolaos:

Perl oder Python-Skripte werden wir noch für Pywikibot brauchen. Sollte da dann dieser Aktiviert und mit einem Parameter versehen sein?

Sophos:

Ja, wenn du Python-Skripte für Pywikibot oder Perl-Skripte nutzen willst, dann sollte CGI aktiviert und richtig konfiguriert sein.

1. mod_cgid oder mod_cgi aktivieren

Da dein Apache als Event-MPM (mod_mpm_event) läuft, brauchst du mod_cgid (für threaded Apache) statt mod_cgi (für Prefork-Modus).

📌 Prüfen, ob mod_cgid aktiv ist:

sh

KopierenBearbeiten

apachectl -M | grep cgi

Falls die Ausgabe leer ist, aktiviere das Modul in httpd.conf:

apache

KopierenBearbeiten

LoadModule cgid_module lib/httpd/modules/mod_cgid.so

Dann Apache neu starten:

sh

KopierenBearbeiten

sudo apachectl restart

2. CGI-Verzeichnisse erlauben

Falls du CGI-Skripte aus bestimmten Verzeichnissen ausführen möchtest, füge in httpd.conf oder httpd-vhosts.confhinzu:

apache

KopierenBearbeiten

Options +ExecCGI

AddHandler cgi-script .cgi .pl .py

Require all granted

</Directory>

Falls du CGI für alle Subdomains nutzen möchtest, setze das global:

apache

KopierenBearbeiten

ScriptSock /opt/homebrew/var/run/httpd/cgisock

</IfModule>

🔹 ScriptSock legt den Unix-Socket für CGI-Kommunikation fest.

🔹 Falls mod_cgid aktiv ist, kann Apache CGI über diesen Socket effizienter verarbeiten.

3. Python für Pywikibot freigeben

Falls Pywikibot direkt aus Apache ausgeführt werden soll, muss cgi-bin auch für Python .py-Skripte erlaubt sein:

apache

KopierenBearbeiten

Options +ExecCGI

AddHandler cgi-script .py

Require all granted

</Directory>

Zusätzlich kann es nötig sein, die erste Zeile in den .py-Skripten als Shebang anzugeben:

python

KopierenBearbeiten

#!/usr/bin/env python3

4. Apache neu starten & testen

Nach der Konfiguration:

sh

KopierenBearbeiten

sudo apachectl restart

Dann teste ein einfaches CGI-Skript (test.py) im cgi-bin-Verzeichnis:

python

KopierenBearbeiten

#!/usr/bin/env python3

print("Content-type: text/html\n")

print("<html><body><h1>CGI funktioniert!</h1></body></html>")

Rufe es im Browser auf:

arduino

KopierenBearbeiten

http://aewi.de/cgi-bin/test.py

🚀 Jetzt ist Apache für Pywikibot & CGI-Skripte bereit!

Nikolaos:

1. apachectl -M | grep cgi

[Tue Mar 04 18:49:47.676120 2025] [so:warn] [pid 6010:tid 8456128576] AH01574: module proxy_fcgi_module is already loaded, skipping

proxy_fcgi_module (shared)

war bereits geladen

2. für chi-bin ist bereits folgendes enthalten:

AllowOverride None

Options None

Require all granted

</Directory>

Was ist nun richtiger?

Options +ExecCGI

AddHandler cgi-script .py

Require all granted

</Directory>

oder

Options +ExecCGI

AddHandler cgi-script .cgi .pl .py

Require all granted

</Directory>

Wir nutzen PHP-FPM anstelle von nur php!

Beantworte kurz: Ist das jetzt wichtig, oder können wir das auch machen wenn wir per, Python und Pywikibot einrichten?

4/4

Sophos:

✅ Antwort:

Das kannst du auch später machen, wenn du Perl, Python und Pywikibot einrichtest. Jetzt ist es nicht dringend.

Falls du später CGI nutzt, dann empfohlen:

apache

KopierenBearbeiten

Options +ExecCGI

AddHandler cgi-script .cgi .pl .py

Require all granted

</Directory>

Damit alle gängigen CGI-Dateitypen erlaubt sind. 🚀

Nikolaos:

aber wir haben ein anderes Verzeichnis oder?

AllowOverride None

Options None

Require all granted

</Directory>

Sophos:

Ja, genau! Dein aktuelles CGI-Verzeichnis ist /opt/homebrew/var/www/cgi-bin, nicht /Library/WebServer/Documents/cgi-bin.

✅ Falls du dieses Verzeichnis behalten willst, dann sollte die Konfiguration so angepasst werden:

apache

KopierenBearbeiten

Options +ExecCGI

AddHandler cgi-script .cgi .pl .py

Require all granted

</Directory>

Damit sind CGI-Skripte für Perl, Python und Pywikibot später nutzbar, ohne das Verzeichnis zu wechseln. 🚀