Gespräch:Installation MariaDB III

Über diese Seite Gespräch

Installation MariaDB
ChatGPT Sophos GPT-4
17. Februar 2025 n. Chr. erst.
Ausgabe 03
Ausgabe 03
unüberarbeitet ungeprüft
↑ Installation MariaDB/Installation MariaDB II
keine Datei

Sophos:

Ja, es könnte tatsächlich kein Problem sein, dass die Gruppe staff gesetzt wird, wenn MariaDB vom angemeldeten User aus betrieben wird.

🔹 1️⃣ Warum setzt MariaDB staff als Gruppe?

Wenn MariaDB als angemeldeter User (aewi) betrieben wird, dann gehört der Prozess zur primären Benutzergruppe – in diesem Fall staff.
_mysql ist der Systembenutzer, aber da MariaDB über Homebrew installiert wurde, könnte es sein, dass Homebrew die Dienste in einer benutzerbasierten Umgebung laufen lässt.

📌 Überprüfung, wer MariaDB gestartet hat:

bash

KopierenBearbeiten

ps aux | grep mariadb

Falls MariaDB unter _mysql läuft, dann wäre staff tatsächlich falsch.
Falls es unter dem Benutzer aewi läuft, dann ist staff korrekt.

In deinem Fall:

bash

KopierenBearbeiten

_mysql 387 0,0 0,7 411659136 110048 ?? Ss 5:17pm 0:00.40 /opt/homebrew/opt/mariadb@10.5/bin/mariadbd --user=_mysql --datadir=/opt/homebrew/var/mariadb --socket=/opt/homebrew/var/mariadb/mariadb.sock

➡ MariaDB läuft unter _mysql, nicht aewi, deshalb sollte die Gruppe _mysql sein.

🔹 2️⃣ Ist staff als Gruppe problematisch?

Ja, wenn Apache oder PHP nicht auf den Socket zugreifen können.

Nein, wenn phpMyAdmin und MediaWiki trotzdem ohne Fehler auf MariaDB zugreifen können.

📌 Teste jetzt phpMyAdmin & MediaWiki erneut:

https://pma.aewi.de
https://wiki.aewi.de/mw-config/index.php?page=DBConnect

✅ Falls alles funktioniert, ist staff kein Problem.

❌ Falls du weiterhin den Fehler mysqli::real_connect(): (HY000/2002): No such file or directory bekommst, dann haben wir ein Berechtigungsproblem.

🔹 3️⃣ Alternative Lösung testen

Falls phpMyAdmin oder MediaWiki immer noch nicht funktionieren, dann teste bitte die automatische Berechtigungsanpassung:

1️⃣ Erstelle das Fix-Skript:

bash

KopierenBearbeiten

sudo nano /usr/local/bin/fix-mariadb-socket.sh

Füge Folgendes ein:

bash

KopierenBearbeiten

#!/bin/bash

chown _mysql:_mysql /opt/homebrew/var/mariadb/mariadb.sock

chmod 660 /opt/homebrew/var/mariadb/mariadb.sock

2️⃣ Speichern und ausführbar machen:

bash

KopierenBearbeiten

sudo chmod +x /usr/local/bin/fix-mariadb-socket.sh

3️⃣ Nach jedem Start ausführen lassen:

Füge dies zu com.mariadb.server.plist hinzu:

xml

KopierenBearbeiten

<key>StartInterval</key>

<key>Program</key>

<string>/usr/local/bin/fix-mariadb-socket.sh</string>

4️⃣ Plist neuladen & MariaDB starten:

bash

KopierenBearbeiten

sudo launchctl unload /Library/LaunchDaemons/com.mariadb.server.plist

sudo launchctl load /Library/LaunchDaemons/com.mariadb.server.plist

📌 Jetzt sollte der Socket nach jedem Start automatisch korrigiert werden.

🔹 Fazit

✅ Wenn alles funktioniert, dann ist staff kein Problem.

❌ Falls phpMyAdmin & MediaWiki nicht auf MariaDB zugreifen können, dann liegt es an falschen Berechtigungen.

🚀 Teste jetzt den Zugriff auf phpMyAdmin & MediaWiki und sag mir Bescheid!

Nikolaos:

Deine Alternative Lösung führt dazu, daß es nun keine mariadb.sock mehr gibt:

ls -l /opt/homebrew/var/mariadb/mariadb.sock

ls: /opt/homebrew/var/mariadb/mariadb.sock: No such file or directory

mariadb.sock wurde durch "sudo find / -name "mariadb.sock" 2>/dev/null" nicht gefunden.

Ich habe daher deiner Alternative Lösung wieder außer Betrieb genommen und mariadb startet wieder.

Wie oder wodurch wird der user aewi und staff als Rechte gesetzt?

2/2

Sophos:

Dass mariadb.sock nach meiner alternativen Lösung plötzlich nicht mehr existiert, bedeutet, dass MariaDB den Socket gar nicht mehr erstellt hat. Das kann daran liegen, dass der Dienst nicht korrekt gestartet wurde oder dass unsere Berechtigungsänderungen den Prozess gestört haben.

🔹 1️⃣ Warum wird staff als Gruppe gesetzt?

Die Gruppe staff wird automatisch zugewiesen, wenn ein Prozess als normaler Benutzer (aewi) läuft, anstatt als _mysql-Benutzer.

📌 Überprüfung, ob MariaDB als aewi oder _mysql läuft:

bash

KopierenBearbeiten

ps aux | grep mariadb

➡ Falls MariaDB unter _mysql läuft, sollte die Gruppe _mysql sein.

➡ Falls es unter aewi läuft, dann gehört es zur Benutzergruppe staff.

MariaDB wird von Homebrew als User aewi gestartet, wenn brew services start mariadb@10.5 verwendet wird.

📌 Wenn du willst, dass es als _mysql läuft, dann starte es mit:

bash

KopierenBearbeiten

sudo -u _mysql brew services start mariadb@10.5

✅ Damit sollte mariadb.sock unter _mysql:_mysql erstellt werden.

🔹 2️⃣ Was bestimmt den Besitzer von mariadb.sock?

📌 MariaDB selbst entscheidet, mit welchem Benutzer & Gruppe der Socket erstellt wird.

Das geschieht basierend auf:

Dem Benutzer, unter dem mariadbd läuft (_mysql oder aewi).
Den Startoptionen in my.cnf (wir haben bereits socket = /opt/homebrew/var/mariadb/mariadb.sockgesetzt).

📌 Überprüfung, mit welchem Benutzer MariaDB läuft:

bash

KopierenBearbeiten

ls -lah /opt/homebrew/var/mariadb/

➡ Falls staff als Gruppe erscheint, dann wurde MariaDB als aewi gestartet.

➡ Falls _mysql als Gruppe erscheint, dann wurde MariaDB korrekt als _mysql gestartet.

🔹 3️⃣ Wie erzwingen wir _mysql als Benutzer für den Start?

📌 Lösung 1: Setze explizit den Benutzer in der com.mariadb.server.plist

Ändere in der Datei /Library/LaunchDaemons/com.mariadb.server.plist:

xml

KopierenBearbeiten

<key>ProgramArguments</key>

<array>

<string>/opt/homebrew/opt/mariadb@10.5/bin/mariadbd</string>

<string>--user=_mysql</string>

<string>--datadir=/opt/homebrew/var/mariadb</string>

<string>--socket=/opt/homebrew/var/mariadb/mariadb.sock</string>

</array>

📌 Danach launchctl neu laden:

bash

KopierenBearbeiten

sudo launchctl unload /Library/LaunchDaemons/com.mariadb.server.plist

sudo launchctl load /Library/LaunchDaemons/com.mariadb.server.plist

sudo brew services restart mariadb@10.5

✅ Jetzt sollte mariadb.sock mit _mysql:_mysql erstellt werden.

📌 Lösung 2: Manuelles Starten mit _mysql

Falls Homebrew immer noch den falschen Benutzer verwendet, kannst du MariaDB manuell als _mysql starten:

bash

KopierenBearbeiten

sudo -u _mysql /opt/homebrew/opt/mariadb@10.5/bin/mariadbd --user=_mysql --datadir=/opt/homebrew/var/mariadb --socket=/opt/homebrew/var/mariadb/mariadb.sock &

✅ Danach sollte der Socket mit _mysql:_mysql korrekt erstellt werden.

🔹 Fazit

1️⃣ MariaDB wird als aewi gestartet → Gruppe ist staff.

2️⃣ MariaDB muss als _mysql gestartet werden, um mariadb.sock mit _mysql:_mysql zu erzeugen.

3️⃣ Lösung: Setze den --user=_mysql Parameter in com.mariadb.server.plist.

4️⃣ Falls das nicht funktioniert, starte MariaDB manuell als _mysql mit sudo -u _mysql.

🔥 Teste das & sag mir, ob es endlich klappt! 🚀

Nikolaos:

du drehst dich für mich offenbar im Kreis, gibst wiederholt dieselben Tipps als Lösung an, von denen wir bereits wissen, daß sie so nicht funktionierten.

1. Ich habe nach den Start den user auf _msql mit den Rechten gesetzt.

Ich habe dann den Zugriff getestet und dann komme ich auch nicht

1.1 MediaWiki: Cannot access the database: :real_connect(): (HY000/2006): MySQL server has gone away

1.2. phpmyadmin: mysqli::real_connect(): (HY000/2002): No such file or directory

MariaDB läuft jedoch!

1.3 ich kann mich trotz der Fehlermeldungen über "mariadb -u root -p" und über "mariadb -u root -p -h 127.0.0.1" mittels Terminal einloggen!

1.4. Also wird es nicht an den Rechten und dem User von mariadb.sock liegen – oder?

2.1 Die vergebenen Rechte sind derzeit:

ls -lah /opt/homebrew/var/mariadb/mariadb.sock

srw-rw---- 1 _mysql _mysql 0B 22 Feb 17:51 /opt/homebrew/var/mariadb/mariadb.sock

2.2 Allerdings kann ich mich mit folgendem nicht einloggen:

mariadb -u root -p --socket=/opt/homebrew/var/mariadb/mariadb.sock

Enter password:

ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/opt/homebrew/var/mariadb/mariadb.sock' (13)

Rechte sind "srw-rw----" und nicht "srwxrwxrwx", der richtige user _mysql ist gesetzt.

Müssen die Rechte anders sein? oder liegt es an etwas anderem?

6/6

Sophos:

Danke für deine Geduld. Wir konzentrieren uns jetzt nur auf die relevanten Punkte und drehen keine weiteren Schleifen.

🔍 1️⃣ Analyse der Situation

MariaDB läuft → Bestätigt durch Terminal-Zugriff mit mariadb -u root -p
phpMyAdmin & MediaWiki können sich nicht verbinden
Verbindungsversuch über --socket schlägt fehl mit Fehler (HY000/2002) und (HY000/2006)

📌 Daraus ergibt sich:

Der Socket existiert (mariadb.sock ist da).
MariaDB ist aktiv und läuft.
PHP/MySQL-Clients können sich trotzdem nicht verbinden. ➡ Problem liegt nicht an MariaDB selbst, sondern an der Kommunikation mit PHP/MySQL.

🔹 2️⃣ Fehlerursache: Socket-Fehlkonfiguration oder Berechtigungsproblem

📌 Erklärung für den Fehler ERROR 2002 (HY000): Can't connect to local MySQL server through socket

Error (13) bedeutet "Permission denied".
MediaWiki & phpMyAdmin laufen als Apache-User (_www), nicht als _mysql oder aewi.
Apache/_www darf nicht auf mariadb.sock zugreifen.

🛠 3️⃣ Lösung: Berechtigungen korrigieren

👉 Erlaube Apache (_www) Zugriff auf mariadb.sock.

bash

KopierenBearbeiten

sudo chown _mysql:_www /opt/homebrew/var/mariadb/mariadb.sock

sudo chmod 660 /opt/homebrew/var/mariadb/mariadb.sock

Dann testen:

bash

KopierenBearbeiten

mariadb -u root -p --socket=/opt/homebrew/var/mariadb/mariadb.sock

Falls es jetzt funktioniert:

PHP kann sich mit MariaDB verbinden.
phpMyAdmin & MediaWiki sollten wieder laufen.

Falls der Fehler bleibt:

📌 Schritt 2: Prüfe, ob PHP/MySQL die richtige Socket-Datei nutzt

bash

KopierenBearbeiten

php -i | grep -i mysql.default_socket

Falls da noch /tmp/mysql.sock steht, müssen wir das in php.ini anpassen.

🔹 4️⃣ Falls der Fehler bleibt: Direkt über TCP verbinden

Falls phpMyAdmin & MediaWiki weiterhin Probleme haben, zwinge sie, über 127.0.0.1 zu verbinden:

📌 In config.inc.php für phpMyAdmin:

php

KopierenBearbeiten

$cfg['Servers'][$i]['host'] = '127.0.0.1';

$cfg['Servers'][$i]['socket'] = ''; // Entferne die Socket-Verbindung

📌 In LocalSettings.php für MediaWiki:

php

KopierenBearbeiten

$wgDBserver = "127.0.0.1";

Danach Apache neu starten:

bash

KopierenBearbeiten

sudo brew services restart httpd

🚀 Fazit

Berechtigungsproblem: mariadb.sock gehört root:_mysql → Apache (_www) hat keinen Zugriff. ✅ Lösung: chown _mysql:_www und chmod 660 setzen.
Falls PHP falsch konfiguriert ist: ✅ PHP-mysql.default_socket muss /opt/homebrew/var/mariadb/mariadb.sock sein.
Falls das Problem bleibt: ✅ Direkt über 127.0.0.1 anstatt localhost verbinden.

💡 Teste das jetzt Schritt für Schritt & sag mir, wo wir noch haken! 🚀

Nikolaos:

Ich habe folgende Angaben bei MariaDB zu OSX gefunden.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<dict>

<key>Label</key> <string>com.mariadb.server</string>

<key>KeepAlive</key><true/>

<key>RunAtLoad</key><true/>

<key>LaunchOnlyOnce</key><false/>

<key>ExitTimeOut</key><integer>600</integer>

<key>WorkingDirectory</key><string>/usr/local/var</string>

<key>Program</key><string>/usr/local/bin/mysqld</string>

<key>ProgramArguments</key>

<array>

<string>/usr/local/bin/mysqld</string>

<string>--user=_mysql</string>

<string>--basedir=/usr/local/opt/mariadb</string>

<string>--plugin-dir=/usr/local/opt/mariadb/lib/plugin</string>

<string>--datadir=/usr/local/var/mysql</string>

<string>--log-error=/usr/local/var/mysql/Data-Server.local.err</string>

<string>--pid-file=/usr/local/var/mysql/Data-Server.local.pid</string>

<string>--sql-mode=ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION</string>

</array>

</dict>

</plist>

Ändere bitte die Dateipfade gemäß unserer Homebrew Installation.

Sophos:

Hier ist die angepasste com.mariadb.server.plist für deine Homebrew-Installation auf macOS, basierend auf den korrekten Pfaden für MariaDB 10.5, die du nutzt:

xml

KopierenBearbeiten

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<dict>

<key>Label</key>

<string>com.mariadb.server</string>

<key>KeepAlive</key>

<true/>

<key>RunAtLoad</key>

<true/>

<key>LaunchOnlyOnce</key>

<key>ExitTimeOut</key>

<key>WorkingDirectory</key>

<string>/opt/homebrew/var/mariadb</string>

<key>Program</key>

<string>/opt/homebrew/opt/mariadb@10.5/bin/mariadbd</string>

<key>ProgramArguments</key>

<array>

<string>/opt/homebrew/opt/mariadb@10.5/bin/mariadbd</string>

<string>--user=_mysql</string>

<string>--basedir=/opt/homebrew/opt/mariadb@10.5</string>

<string>--plugin-dir=/opt/homebrew/opt/mariadb@10.5/lib/plugin</string>

<string>--datadir=/opt/homebrew/var/mariadb</string>

<string>--log-error=/opt/homebrew/var/mariadb/mariadb.err</string>

<string>--pid-file=/opt/homebrew/var/mariadb/mariadb.pid</string>

<string>--socket=/opt/homebrew/var/mariadb/mariadb.sock</string>

<string>--sql-mode=ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION</string>

</array>

</dict>

</plist>

🛠 Installation & Aktivierung der neuen .plist

1️⃣ Speichern:

Speichere die Datei als /Library/LaunchDaemons/com.mariadb.server.plist

2️⃣ Berechtigungen setzen:

bash

KopierenBearbeiten

sudo chown root:wheel /Library/LaunchDaemons/com.mariadb.server.plist

sudo chmod 644 /Library/LaunchDaemons/com.mariadb.server.plist

3️⃣ Alten Dienst entladen, falls vorhanden:

bash

KopierenBearbeiten

sudo launchctl unload /Library/LaunchDaemons/com.mariadb.server.plist

4️⃣ Neue .plist laden & MariaDB starten:

bash

KopierenBearbeiten

sudo launchctl load /Library/LaunchDaemons/com.mariadb.server.plist

sudo brew services restart mariadb@10.5

5️⃣ Testen, ob MariaDB läuft:

bash

KopierenBearbeiten

ps aux | grep mariadb

ls -lah /opt/homebrew/var/mariadb/mariadb.sock

🔹 Fazit

✅ Jetzt sollte MariaDB automatisch beim Systemstart als _mysql laufen.

✅ Die korrekten Pfade für Homebrew und deine Installation sind jetzt in der .plist gesetzt.

✅ Falls es nach einem Neustart nicht funktioniert, überprüfe das Error-Log:

bash

KopierenBearbeiten

tail -n 50 /opt/homebrew/var/mariadb/mariadb.err

🔥 Teste es & sag mir Bescheid, ob alles läuft! 🚀

Nikolaos:

Damit bleibt zumindest alles beim alten. Also der Fehler ist derselbe, neue Fehler kamen nicht hinzu. User ist mysql staff:

Gehen wir mal davon aus, daß das richtig so ist und suchen den Fehler an anderer Stelle.

Sophos:

Da wir jetzt bestätigt haben, dass MariaDB korrekt läuft und die User/Gruppe von mariadb.sock wahrscheinlich nicht das Problem ist, fokussieren wir uns jetzt auf eine andere Fehlerquelle für phpMyAdmin & MediaWiki.

🔍 1️⃣ Was wir bereits wissen

MariaDB läuft einwandfrei, du kannst dich über Terminal & Querious einloggen.
MediaWiki & phpMyAdmin können sich nicht verbinden, Fehler:
- mysqli::real_connect(): (HY000/2002): No such file or directory
- Cannot access the database: :real_connect(): (HY000/2006): MySQL server has gone away
MariaDB-User & Berechtigungen sind korrekt
MariaDB läuft auf 127.0.0.1 & socket /opt/homebrew/var/mariadb/mariadb.sock
PHP und Apache laufen richtig

➡ Daraus folgt:

Das Problem liegt entweder an:

Falscher socket-Pfad in PHP / phpMyAdmin / MediaWiki
Apache kann sich nicht mit MariaDB verbinden (weil php-fpm oder mod_php falsch konfiguriert ist)

**🔹 2️⃣ Fehlersuche:

📌 1️⃣ Test: Läuft MySQL unter PHP?

Führe folgenden Befehl aus, um zu testen, ob PHP MySQL richtig erkennt:

bash

KopierenBearbeiten

php -i | grep -i mysql

Besonders wichtig sind die Zeilen:

pdo_mysql.default_socket
mysqli.default_socket

➡ Falls hier noch /tmp/mysql.sock steht, dann liegt das Problem darin!

🔹 Lösung: Setze den richtigen socket in php.ini

bash

KopierenBearbeiten

sudo nano /opt/homebrew/etc/php/8.2/php.ini

Suche nach dieser Zeile:

ini

KopierenBearbeiten

pdo_mysql.default_socket = /tmp/mysql.sock

Ändere sie zu:

ini

KopierenBearbeiten

pdo_mysql.default_socket = /opt/homebrew/var/mariadb/mariadb.sock

Speichern (CTRL + X, dann Y, dann Enter)

🚀 Danach PHP & Apache neu starten:

bash

KopierenBearbeiten

sudo brew services restart php@8.2

sudo brew services restart httpd

📌 2️⃣ Test: Verbindet sich phpMyAdmin über TCP statt Socket?

Falls PHP nicht über den Socket verbinden kann, erzwinge TCP als Verbindungsmethode für phpMyAdmin.

🔹 Ändere die config.inc.php von phpMyAdmin:

bash

KopierenBearbeiten

sudo nano /opt/homebrew/share/phpmyadmin/config.inc.php

Suche diese Zeile:

php

KopierenBearbeiten

$cfg['Servers'][$i]['host'] = 'localhost';

Ändere sie zu:

php

KopierenBearbeiten

$cfg['Servers'][$i]['host'] = '127.0.0.1';

unset($cfg['Servers'][$i]['socket']);

🚀 Apache neu starten:

bash

KopierenBearbeiten

sudo brew services restart httpd

Teste jetzt phpMyAdmin erneut!

📌 3️⃣ Test: Kann MediaWiki über TCP statt Socket verbinden?

🔹 Ändere die LocalSettings.php für MediaWiki:

bash

KopierenBearbeiten

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

Suche:

php

KopierenBearbeiten

$wgDBserver = "localhost";

Ändere zu:

php

KopierenBearbeiten

$wgDBserver = "127.0.0.1";

🚀 Apache neu starten & erneut testen

bash

KopierenBearbeiten

sudo brew services restart httpd

Teste jetzt MediaWiki erneut!

🔥 Fazit & Nächste Schritte

✅ Falls php -i | grep mysql noch /tmp/mysql.sock anzeigt → php.ini fixen
✅ Falls TCP für phpMyAdmin & MediaWiki das Problem löst, dann war die Socket-Verbindung das Problem
❌ Falls der Fehler bleibt, schauen wir uns das Apache-Log an:

bash

KopierenBearbeiten

tail -n 50 /opt/homebrew/var/log/httpd/error_log

🔥 Teste die Änderungen & sag mir, wo wir stehen! 🚀

Nikolaos:

Derzeit habe ich:

/* Authentication type */

$cfg['Servers'][$i]['auth_type'] = 'cookie';

/* Server parameters */

$cfg['Servers'][$i]['host'] = '127.0.0.1';

$cfg['Servers'][$i]['socket'] = '/opt/homebrew/var/mariadb/mariadb.sock';

$cfg['Servers'][$i]['port'] = '3306';

$cfg['Servers'][$i]['connect_type'] = 'socket';

$cfg['Servers'][$i]['compress'] = false;

$cfg['Servers'][$i]['AllowNoPassword'] = false;

$cfg['Servers'][$i]['user'] = 'root';

$cfg['Servers'][$i]['password'] = '44%%55Aufeinwort';

Wie soll och es ändern?

4/4

Sophos:

Deine aktuelle Konfiguration in config.inc.php für phpMyAdmin ist gut, aber es gibt eine mögliche Fehlkonfiguration bei der Verbindungsmethode.

🔹 1️⃣ Änderungen in config.inc.php

🚀 Lösung: Entferne die socket-Verbindung & erlaube TCP

Ändere den Block auf:

php

KopierenBearbeiten

/* Authentication type */

$cfg['Servers'][$i]['auth_type'] = 'cookie';

/* Server parameters */

$cfg['Servers'][$i]['host'] = '127.0.0.1'; // Erzwinge TCP-Verbindung

unset($cfg['Servers'][$i]['socket']); // Entferne die Socket-Verbindung

$cfg['Servers'][$i]['port'] = '3306';

$cfg['Servers'][$i]['connect_type'] = 'tcp'; // TCP statt Socket

$cfg['Servers'][$i]['compress'] = false;

$cfg['Servers'][$i]['AllowNoPassword'] = false;

$cfg['Servers'][$i]['user'] = 'root';

$cfg['Servers'][$i]['password'] = '44%%55Aufeinwort';

🔹 2️⃣ Apache & PHP neu starten

Nach der Änderung musst du Apache & PHP neu starten, damit die Änderungen greifen:

bash

KopierenBearbeiten

sudo brew services restart php@8.2

sudo brew services restart httpd

🔹 3️⃣ Testen

1️⃣ Gehe zu: https://pma.aewi.de/phpmyadmin/

2️⃣ Melde dich mit root und deinem Passwort an.

3️⃣ Falls es immer noch nicht geht:

Fehlermeldung notieren & mir schicken.
Error-Logs prüfen:

bash

KopierenBearbeiten

tail -n 50 /opt/homebrew/var/log/httpd/error_log

🔥 Teste das & sag mir, ob phpMyAdmin jetzt funktioniert! 🚀

Nikolaos:

Wie steht es um die Reihenfolge des Start der Dienste?

Wenn phpmyadmin noch den alten mariabd.sock einliest und dann erst Mariadb startet und einen neuen Socket anlegt, könnte dies der Grund sein?

Wir sollten haben:

1. dnsamask

2. mariadb

3. http

4. php

5. wireguard

oder?

Derzeit ist es so:

sudo brew services list

Password:

Name Status User File

dnsmasq started root /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist

httpd started root /Library/LaunchDaemons/homebrew.mxcl.httpd.plist

mariadb@10.5 stopped root /Library/LaunchDaemons/homebrew.mxcl.mariadb@10.5.plist

php@8.2 started root /Library/LaunchDaemons/homebrew.mxcl.php@8.2.plist

wireguard wird nicht durch homebrew gelistet, da es eigens gestartet wird.

wenn die brew liste die Startlreihenfolge ist, dann startet mariadb vor php und es düfte keine Rolle spielen.

wir können ja ganz einfach erstmal nur mariadb als erstes starten – oder?

3/3

Sophos:

Ja, die Startreihenfolge der Dienste kann eine Rolle spielen, wenn Dienste voneinander abhängen.

🔹 1️⃣ Optimale Startreihenfolge

Dein Vorschlag ist richtig, die Dienste sollten in folgender Reihenfolge starten:

1️⃣ dnsmasq (damit DNS-Auflösung für lokale Domains funktioniert)

2️⃣ mariadb (weil phpMyAdmin & MediaWiki darauf zugreifen)

3️⃣ httpd (Apache) (weil PHPMyAdmin & MediaWiki über den Webserver laufen)

4️⃣ php (weil Apache auf PHP-Funktionen zugreift)

5️⃣ wireguard (weil Fernzugriff & VPN unabhängig sind)

🔹 2️⃣ Aktuelle Reihenfolge laut brew services list

Derzeit sieht deine Startreihenfolge so aus:

bash

KopierenBearbeiten

dnsmasq ✅ gestartet

httpd ✅ gestartet

mariadb@10.5 ❌ STOPPED

php@8.2 ✅ gestartet

👉 Problem:

MariaDB ist gestoppt! Das bedeutet, dass phpMyAdmin & MediaWiki keinen Zugriff auf die Datenbank haben können.
Apache (httpd) und PHP (php@8.2) starten, bevor MariaDB läuft.
phpMyAdmin lädt den alten mariadb.sock ein, der nicht mehr existiert → Das führt zu Fehlern.

📌 Lösung: Wir müssen sicherstellen, dass mariadb@10.5 als erstes startet.

🔹 3️⃣ Lösung: Startreihenfolge manuell anpassen

👉 Schritt 1: Stoppe alle Dienste

bash

KopierenBearbeiten

sudo brew services stop php@8.2

sudo brew services stop httpd

sudo brew services stop mariadb@10.5

sudo brew services stop dnsmasq

👉 Schritt 2: Starte die Dienste in der richtigen Reihenfolge

bash

KopierenBearbeiten

sudo brew services start dnsmasq

sudo brew services start mariadb@10.5

sudo brew services start httpd

sudo brew services start php@8.2

👉 Schritt 3: Überprüfe, ob alles korrekt gestartet wurde

bash

KopierenBearbeiten

sudo brew services list

Erwartetes Ergebnis:

sql

KopierenBearbeiten

Name Status User File

dnsmasq started root /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist

mariadb@10.5 started root /Library/LaunchDaemons/homebrew.mxcl.mariadb@10.5.plist

httpd started root /Library/LaunchDaemons/homebrew.mxcl.httpd.plist

php@8.2 started root /Library/LaunchDaemons/homebrew.mxcl.php@8.2.plist

🔹 4️⃣ Automatische Startreihenfolge bei Systemstart sicherstellen

Wenn du möchtest, dass mariadb@10.5 IMMER als erstes startet, kannst du die plist-Konfiguration anpassen.

👉 Füge KeepAlive für MariaDB ein

bash

KopierenBearbeiten

sudo nano /Library/LaunchDaemons/homebrew.mxcl.mariadb@10.5.plist

Füge zwischen <dict> und </dict> diese Zeilen hinzu:

xml

KopierenBearbeiten

<key>KeepAlive</key>

<true/>

<key>RunAtLoad</key>

<true/>

🚀 Danach die .plist erneut laden & testen

bash

KopierenBearbeiten

sudo launchctl unload /Library/LaunchDaemons/homebrew.mxcl.mariadb@10.5.plist

sudo launchctl load /Library/LaunchDaemons/homebrew.mxcl.mariadb@10.5.plist

✅ Fazit

MariaDB muss vor Apache & PHP starten!
Stoppe alle Dienste & starte sie in der richtigen Reihenfolge.
Falls nach einem Neustart die falsche Reihenfolge geladen wird, passe die .plist an.

🔥 Teste das & sag mir, ob phpMyAdmin & MediaWiki jetzt laufen! 🚀

Nikolaos:

es gibt einen brew Befehl um die Starreihenfolge zu ändern – oder?

Sophos:

Ja, Homebrew selbst hat keinen direkten Befehl, um die Startreihenfolge zu ändern, aber du kannst die Reihenfolge über brew services steuern, indem du die Dienste in der gewünschten Reihenfolge neu registrierst.

🔹 1️⃣ brew services nutzt launchctl

Homebrew verwendet launchctl, um Dienste beim Booten zu starten. Die Startreihenfolge basiert darauf, in welcher Reihenfolge die Dienste geladen werden.

💡 Einfach gesagt:

Je später ein Dienst gestartet wurde, desto weiter unten steht er in der Priorität.

→ Das bedeutet, dass ein später gestarteter Dienst einen früher gestarteten überholen kann.

🔹 2️⃣ Lösung: Brew-Dienste in der richtigen Reihenfolge registrieren

👉 Schritt 1: Stoppe alle Brew-Dienste

bash

KopierenBearbeiten

brew services stop php@8.2

brew services stop httpd

brew services stop mariadb@10.5

brew services stop dnsmasq

👉 Schritt 2: Starte die Dienste in der gewünschten Reihenfolge

bash

KopierenBearbeiten

brew services start dnsmasq

brew services start mariadb@10.5

brew services start httpd

brew services start php@8.2

💡 Jetzt merkt sich brew services, dass mariadb@10.5 vor Apache und PHP gestartet wurde.

🔥 Teste das mit:

bash

KopierenBearbeiten

brew services list

Falls ein Dienst nicht als started angezeigt wird, musst du ihn nochmal manuell starten.

🔹 3️⃣ Alternativ: Reihenfolge über launchctl anpassen

Falls brew services start nicht die Reihenfolge speichert, kannst du launchctl direkt benutzen.

👉 Schritt 1: Stoppe alle brew-Dienste

bash

KopierenBearbeiten

sudo launchctl bootout system /Library/LaunchDaemons/homebrew.mxcl.php@8.2.plist

sudo launchctl bootout system /Library/LaunchDaemons/homebrew.mxcl.httpd.plist

sudo launchctl bootout system /Library/LaunchDaemons/homebrew.mxcl.mariadb@10.5.plist

sudo launchctl bootout system /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist

👉 Schritt 2: Lade die Dienste in der richtigen Reihenfolge

bash

KopierenBearbeiten

sudo launchctl bootstrap system /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist

sudo launchctl bootstrap system /Library/LaunchDaemons/homebrew.mxcl.mariadb@10.5.plist

sudo launchctl bootstrap system /Library/LaunchDaemons/homebrew.mxcl.httpd.plist

sudo launchctl bootstrap system /Library/LaunchDaemons/homebrew.mxcl.php@8.2.plist

🚀 Danach überprüfen:

bash

KopierenBearbeiten

launchctl list | grep homebrew

→ Falls MariaDB nicht startet, versuche diesen Fix:

bash

KopierenBearbeiten

sudo launchctl enable system/homebrew.mxcl.mariadb@10.5

🔹 4️⃣ Automatische Reihenfolge nach Neustart sicherstellen

Falls Homebrew nach jedem Neustart die falsche Reihenfolge lädt, kannst du einen "Verzögerten Start" für Apache & PHP hinzufügen.

📌 Erstelle ein Start-Skript für die korrekte Reihenfolge

bash

KopierenBearbeiten

sudo nano /Library/LaunchDaemons/com.local.startup.plist

Füge Folgendes ein:

xml

KopierenBearbeiten

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<dict>

<key>Label</key>

<string>com.local.startup</string>

<key>ProgramArguments</key>

<array>

<string>sleep 10 && brew services start httpd && sleep 5 && brew services start php@8.2</string>

</array>

<key>RunAtLoad</key>

<true/>

<key>KeepAlive</key>

<true/>

</dict>

</plist>

📌 Danach aktivieren:

bash

KopierenBearbeiten

sudo chown root:wheel /Library/LaunchDaemons/com.local.startup.plist

sudo chmod 644 /Library/LaunchDaemons/com.local.startup.plist

sudo launchctl load /Library/LaunchDaemons/com.local.startup.plist

🚀 Nach dem nächsten Neustart werden HTTP & PHP verzögert gestartet, nachdem MariaDB läuft.

✅ Fazit

1️⃣ brew services speichert die Reihenfolge basierend auf der Reihenfolge, in der die Dienste gestartet werden.

2️⃣ Falls brew services nicht ausreicht, kann launchctl für eine genauere Kontrolle genutzt werden.

3️⃣ Falls nach einem Neustart immer noch Probleme bestehen, kann ein startup-Skript mit launchctl helfen.

🔥 Teste zuerst nur brew services & sag mir, ob das Problem dann behoben ist! 🚀

Nikolaos:

Hat nicht funktioniert.

was ist mit folgendem:

If you need to have this software first in your PATH instead consider running:

echo 'export PATH="/opt/homebrew/opt/mariadb@10.5/bin:$PATH"' >> ~/.zshrc

echo $PATH

/opt/homebrew/opt/mariadb@10.5/bin:/opt/homebrew/opt/mariadb@10.5/bin:/opt/homebrew/opt/php/sbin:/opt/homebrew/opt/php/bin:/opt/homebrew/opt/mysql@8.0/bin:/opt/homebrew/opt/httpd@2.4/bin:/opt/homebrew/opt/php@8.2/sbin:/opt/homebrew/opt/php@8.2/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin

which mysql

/opt/homebrew/opt/mariadb@10.5/bin/mysql

which mariadb

/opt/homebrew/opt/mariadb@10.5/bin/mariadb

aewi@AEWI ~ %

warum ist da mysql und mariadb mit einem unterschiedlichen Path angegeben? Warum ist da überhaupt noch mysql vorhanden?

Wir haben folgende Reihenfolge und mysql@8.0 in /Users/aewi/.zshrc:

export PATH="/opt/homebrew/opt/php@8.2/bin:$PATH"

export PATH="/opt/homebrew/opt/php@8.2/sbin:$PATH"

export PATH="/opt/homebrew/opt/httpd@2.4/bin:$PATH"

export PATH="/opt/homebrew/opt/mysql@8.0/bin:$PATH"

export HOMEBREW_NO_AUTO_UPDATE=1

export PATH="/opt/homebrew/opt/php/bin:$PATH"

export PATH="/opt/homebrew/opt/php/sbin:$PATH"

export PATH="/opt/homebrew/opt/mariadb@10.5/bin:$PATH"

3/3

Sophos:

Da haben wir den Fehler gefunden! 🎯

Das Problem entsteht durch zwei unterschiedliche Einträge für MySQL und MariaDB im $PATH. Dies führt dazu, dass dein System an bestimmten Stellen möglicherweise auf eine falsche (alte) Installation verweist.

🔹 1️⃣ Ursache des Problems

Deine aktuelle $PATH-Konfiguration enthält doppelte und widersprüchliche Einträge:

/opt/homebrew/opt/mysql@8.0/bin
/opt/homebrew/opt/mariadb@10.5/bin (sogar doppelt vorhanden)

👉 Obwohl mysql als Alias für MariaDB existiert, verweist dein System auf beide Pfade. Dies verursacht potenzielle Konflikte, besonders bei phpMyAdmin und MediaWiki.

🔹 2️⃣ Lösung: Pfad korrigieren und aufräumen

Schritt 1: Editiere .zshrc

bash

KopierenBearbeiten

nano ~/.zshrc

Ersetze alle Einträge in deiner .zshrc, die auf MariaDB/MySQL verweisen, durch diesen einzigen Eintrag:

bash

KopierenBearbeiten

export PATH="/opt/homebrew/opt/mariadb@10.5/bin:$PATH"

❗️Entferne unbedingt diese Zeile vollständig:

bash

KopierenBearbeiten

export PATH="/opt/homebrew/opt/mysql@8.0/bin:$PATH"

✅ Speichern (STRG+O) und schließen (STRG+X).

🔹 3️⃣ Aktualisiere die Shell und überprüfe

bash

KopierenBearbeiten

source ~/.zshrc

✅ Prüfe erneut mit:

bash

KopierenBearbeiten

echo $PATH

Erwartetes Ergebnis (ohne MySQL@8.0!):

swift

KopierenBearbeiten

/opt/homebrew/opt/mariadb@10.5/bin:/opt/homebrew/opt/php@8.2/bin:/opt/homebrew/opt/php@8.2/sbin:/opt/homebrew/opt/httpd@2.4/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:...

🔹 4️⃣ Prüfe den Erfolg

bash

KopierenBearbeiten

which mysql

which mariadb

Erwartetes Ergebnis:

swift

KopierenBearbeiten

/opt/homebrew/opt/mariadb@10.5/bin/mysql

/opt/homebrew/opt/mariadb@10.5/bin/mariadb

⚠️ Wichtig: MySQL@8.0 darf nicht mehr im $PATH erscheinen!

🔹 5️⃣ Neustart der Dienste in korrekter Reihenfolge

Um alles sauber neu zu starten:

bash

KopierenBearbeiten

brew services stop php@8.2

brew services stop httpd

brew services stop mariadb@10.5

brew services stop dnsmasq

brew services start dnsmasq

brew services start mariadb@10.5

brew services start httpd

brew services start php@8.2

✅ Überprüfe abschließend den Status erneut:

bash

KopierenBearbeiten

brew services list

🔥 Fazit & Erfolgstest

Durch das Entfernen der veralteten Pfade (mysql@8.0) und die korrekte Reihenfolge für MariaDB im $PATH sollten sich deine bisherigen Probleme endlich lösen.

Teste nun erneut phpMyAdmin und MediaWiki:

👉 phpMyAdmin:

https://pma.aewi.de/phpmyadmin/

👉 MediaWiki:

https://wiki.aewi.de/

🔥 Teste das jetzt und gib mir Bescheid! 🚀

1/2

Nikolaos:

Warum ist da

export PATH="/opt/homebrew/opt/php@8.2/bin:$PATH"

und

export PATH="/opt/homebrew/opt/php/bin:$PATH"

enthalten?

Warum hat php@8.2 nur eine bin aber keine sbin?

export PATH="/opt/homebrew/opt/php@8.2/bin:$PATH"

keine sbin also es ist nicht enthalten:

export PATH="/opt/homebrew/opt/php@8.2/sbin:$PATH"

2/2

Sophos:

Gute Fragen! Lass uns das genau analysieren. 🔍

🔹 1️⃣ Warum gibt es zwei PHP-Pfade?

Dein .zshrc enthält:

bash

KopierenBearbeiten

export PATH="/opt/homebrew/opt/php@8.2/bin:$PATH"

export PATH="/opt/homebrew/opt/php/bin:$PATH"

/opt/homebrew/opt/php@8.2/bin → Das ist der spezifische Pfad zu PHP 8.2, falls du mehrere Versionen installiert hast.
/opt/homebrew/opt/php/bin → Das ist der allgemeine Symlink, der auf die aktuell installierte Standard-PHP-Version verweist.

👉 Normalerweise reicht einer dieser Einträge aus!

💡 Falls du nur PHP 8.2 nutzen willst, solltest du den generischen php/bin-Pfad entfernen.

✅ Empfohlene Zeile für .zshrc:

bash

KopierenBearbeiten

export PATH="/opt/homebrew/opt/php@8.2/bin:$PATH"

✂️ Entferne:

bash

KopierenBearbeiten

export PATH="/opt/homebrew/opt/php/bin:$PATH"

🔹 2️⃣ Warum gibt es keinen /opt/homebrew/opt/php@8.2/sbin?

Die meisten Homebrew-PHP-Versionen enthalten keine sbin-Verzeichnisse, weil PHP-CLI-Skripte nicht in sbin, sondern in bin liegen.

👉 Überprüfe selbst:

bash

KopierenBearbeiten

ls -lah /opt/homebrew/opt/php@8.2/

Falls dort kein sbin-Ordner existiert, bedeutet das, dass Homebrew diese PHP-Version ohne sbin kompiliert hat.

✅ Lösung:

Falls kein /opt/homebrew/opt/php@8.2/sbin/ existiert, entferne einfach diesen Eintrag aus .zshrc:

bash

KopierenBearbeiten

export PATH="/opt/homebrew/opt/php@8.2/sbin:$PATH"

🔹 3️⃣ Finaler .zshrc-Fix

Hier ist die optimierte .zshrc-Konfiguration für dein Setup:

bash

KopierenBearbeiten

export PATH="/opt/homebrew/opt/php@8.2/bin:$PATH"

export PATH="/opt/homebrew/opt/httpd@2.4/bin:$PATH"

export PATH="/opt/homebrew/opt/mariadb@10.5/bin:$PATH"

export HOMEBREW_NO_AUTO_UPDATE=1

🔥 Speichern (STRG+O, ENTER, STRG+X) und Shell neu laden:

bash

KopierenBearbeiten

source ~/.zshrc

✅ Überprüfe anschließend mit:

bash

KopierenBearbeiten

echo $PATH

which php

which mariadb

which mysql

Erwartete Ergebnisse:

/opt/homebrew/opt/php@8.2/bin/php
/opt/homebrew/opt/mariadb@10.5/bin/mariadb
/opt/homebrew/opt/mariadb@10.5/bin/mysql

🎯 Fazit

Doppelter PHP-Pfad entfernt (php/bin wird nicht benötigt).
sbin entfernt, da es für PHP 8.2 nicht existiert.
Homebrew-MySQL entfernt, damit nur noch MariaDB genutzt wird.
Reihenfolge optimiert, damit alle Dienste korrekt geladen werden.

🚀 Teste das jetzt & sag mir Bescheid, ob es funktioniert!

Nikolaos:

Der Fehler bleibt. Wir haben also etwas jedoch nicht den Fehler gefunden.

phpmyadmin: mysqli::real_connect(): (HY000/2002): No such file or directory

Sophos:

Da der Fehler "mysqli::real_connect(): (HY000/2002): No such file or directory" immer noch besteht, bedeutet das, dass PHP nicht mit MariaDB kommunizieren kann.

Lass uns gezielt nach der Ursache suchen! 🔍

✅ 1️⃣ Erste Überprüfung: Funktioniert PHPs MySQL-Erweiterung?

Führe diesen Befehl aus:

bash

KopierenBearbeiten

php -i | grep -i mysql

🔹 Erwartetes Ergebnis:

Es sollte nicht leer sein!
Falls PHP MySQL nicht erkennt, dann fehlt die PHP-MySQL-Erweiterung.

Falls keine Ausgabe kommt, installiere MySQL für PHP:

bash

KopierenBearbeiten

brew install php-mysql

brew services restart php@8.2

Teste dann erneut:

bash

KopierenBearbeiten

php -i | grep -i mysql

✅ 2️⃣ Überprüfung der MySQL-Socket-Einstellungen in PHP

Führe diesen Befehl aus:

bash

KopierenBearbeiten

php -i | grep -i default_socket

🔹 Erwartetes Ergebnis:

plaintext

KopierenBearbeiten

pdo_mysql.default_socket => /opt/homebrew/var/mariadb/mariadb.sock

mysqli.default_socket => /opt/homebrew/var/mariadb/mariadb.sock

mysql.default_socket => /opt/homebrew/var/mariadb/mariadb.sock

Falls ein falscher Wert wie /tmp/mysql.sock erscheint, dann muss das in php.ini korrigiert werden.

👉 Schritt 1: Editiere PHPs php.ini

bash

KopierenBearbeiten

nano /opt/homebrew/etc/php/8.2/php.ini

🔹 Füge oder ändere diese Zeilen:

ini

KopierenBearbeiten

pdo_mysql.default_socket=/opt/homebrew/var/mariadb/mariadb.sock

mysqli.default_socket=/opt/homebrew/var/mariadb/mariadb.sock

mysql.default_socket=/opt/homebrew/var/mariadb/mariadb.sock

Speichern (STRG+O, ENTER, STRG+X).

👉 Schritt 2: PHP neu starten

bash

KopierenBearbeiten

brew services restart php@8.2

👉 Schritt 3: Teste erneut

bash

KopierenBearbeiten

php -i | grep -i default_socket

Falls der Wert jetzt /opt/homebrew/var/mariadb/mariadb.sock ist, dann probiere erneut phpMyAdmin!

✅ 3️⃣ Überprüfung der config.inc.php von phpMyAdmin

Falls phpMyAdmin noch immer nicht funktioniert, überprüfe die Konfiguration:

bash

KopierenBearbeiten

nano /opt/homebrew/share/phpmyadmin/config.inc.php

🔹 Stelle sicher, dass diese Zeilen enthalten sind:

php

KopierenBearbeiten

$cfg['Servers'][$i]['host'] = '127.0.0.1';

$cfg['Servers'][$i]['socket'] = '/opt/homebrew/var/mariadb/mariadb.sock';

$cfg['Servers'][$i]['port'] = '3306';

$cfg['Servers'][$i]['connect_type'] = 'socket';

$cfg['Servers'][$i]['compress'] = false;

$cfg['Servers'][$i]['AllowNoPassword'] = false;

👉 Danach Apache neu starten

bash

KopierenBearbeiten

brew services restart httpd

🚀 Teste phpMyAdmin erneut! Falls es immer noch nicht geht, überprüfe die Apache-Fehlerlogs:

bash

KopierenBearbeiten

tail -n 50 /opt/homebrew/var/log/httpd/*.log

✅ 4️⃣ Finaler Test: Funktioniert eine Direktverbindung mit PHP?

Falls phpMyAdmin immer noch nicht geht, dann testen wir eine manuelle PHP-Verbindung zu MariaDB.

👉 Erstelle eine Testdatei

bash

KopierenBearbeiten

nano /opt/homebrew/share/phpmyadmin/test_db.php

🔹 Füge folgenden Code ein:

php

KopierenBearbeiten

<?php

$mysqli = new mysqli('127.0.0.1', 'root', 'DEINPASSWORT', '', 3306, '/opt/homebrew/var/mariadb/mariadb.sock');

if ($mysqli->connect_error) {

die("Verbindung fehlgeschlagen: " . $mysqli->connect_error);

} else {

echo "Verbindung erfolgreich!";

}

?>

📌 Speichern (STRG+O, ENTER, STRG+X).

👉 Testen:

Öffne https://pma.aewi.de/test_db.php in deinem Browser.

🔹 Erwartetes Ergebnis:

"Verbindung erfolgreich!"

Falls ein Fehler kommt, liegt das Problem entweder bei:

Der Socket-Verbindung (Punkt 2️⃣ nochmals prüfen)
Den Benutzerrechten in MariaDB (SELECT user, host FROM mysql.user; prüfen)

🔥 Fazit

1️⃣ PHP muss MySQL korrekt geladen haben → php -i | grep -i mysql testen.

2️⃣ Die MySQL-Socket-Pfade müssen stimmen → php.ini & config.inc.php korrigieren.

3️⃣ Falls phpMyAdmin nicht geht, teste eine einfache test_db.php-Verbindung.

4️⃣ Apache & PHP nach jeder Änderung neustarten!

🚀 Führe diese Schritte aus und sag mir das Ergebnis! 💪

Nikolaos:

1. php -i | grep -i mysql

mysqli.default_socket => /tmp/mysql.sock => /tmp/mysql.sock

mysqli nutzt also weiterhin "/tmp/mysql.sock"?

2. wird da auf zwei verschiedene Datenbanken verwiesen?

2.1 which mysql

/opt/homebrew/opt/mariadb@10.5/bin/mysql

2.2 which mariadb

/opt/homebrew/opt/mariadb@10.5/bin/mariadb

Sophos:

Ja, hier sind zwei Probleme erkennbar:

🚨 Problem 1: PHP verwendet den falschen MySQL-Socket (/tmp/mysql.sock statt /opt/homebrew/var/mariadb/mariadb.sock)

Das bedeutet, dass PHP immer noch nicht mit der richtigen MariaDB-Installation verbunden ist.

✅ Lösung: Korrigiere die Socket-Pfade in php.ini

1️⃣ Öffne die PHP-Konfigurationsdatei:

bash

KopierenBearbeiten

nano /opt/homebrew/etc/php/8.2/php.ini

2️⃣ Finde und ersetze folgende Zeilen:

ini

KopierenBearbeiten

mysqli.default_socket = /opt/homebrew/var/mariadb/mariadb.sock

pdo_mysql.default_socket = /opt/homebrew/var/mariadb/mariadb.sock

mysql.default_socket = /opt/homebrew/var/mariadb/mariadb.sock

3️⃣ Speichern & schließen (STRG+O, ENTER, STRG+X).

4️⃣ PHP neu starten:

bash

KopierenBearbeiten

brew services restart php@8.2

5️⃣ Testen, ob der Pfad nun korrekt ist:

bash

KopierenBearbeiten

php -i | grep -i mysql

👉 Erwartetes Ergebnis:

ini

KopierenBearbeiten

mysqli.default_socket => /opt/homebrew/var/mariadb/mariadb.sock

Falls weiterhin /tmp/mysql.sock angezeigt wird, dann:

bash

KopierenBearbeiten

sudo launchctl stop homebrew.mxcl.php@8.2

sudo launchctl start homebrew.mxcl.php@8.2

🚀 Teste danach phpMyAdmin erneut!

🚨 Problem 2: MySQL und MariaDB haben unterschiedliche Pfade

Hier ist der Konflikt:

which mysql → /opt/homebrew/opt/mariadb@10.5/bin/mysql
which mariadb → /opt/homebrew/opt/mariadb@10.5/bin/mariadb

Das ist kein direkter Fehler, aber es kann verwirrend sein. Homebrew hat mysql als Symlink für MariaDB gesetzt. Falls du sicherstellen willst, dass alles korrekt funktioniert, prüfe:

👉 Welches MySQL-Programm verwendet wird:

bash

KopierenBearbeiten

mysql --version

mariadb --version

Falls mysql --version MariaDB anzeigt, dann ist alles korrekt.

Falls stattdessen noch ein MySQL 8.0 auftaucht, entferne es mit:

bash

KopierenBearbeiten

brew uninstall mysql@8.0

brew unlink mysql@8.0

brew cleanup

Danach sicherstellen, dass MariaDB verwendet wird:

bash

KopierenBearbeiten

brew link --force --overwrite mariadb@10.5

🚀 Teste phpMyAdmin nach diesen Änderungen erneut!

Nikolaos:

Wenn "pdo_mysql.default_socket = /opt/homebrew/var/mariadb/mariadb.sock" für den lokalen Zugriff ist, was ist der für den remote Zugriff oder den Zugriff über VPN https://pma.aewi.de…?

Sophos:

Für den Remote-Zugriff oder den Zugriff über VPN (z. B. https://pma.aewi.de), wird kein Socket (.sock-Datei) verwendet, sondern die Verbindung erfolgt über TCP/IP.

Das bedeutet, dass pdo_mysql.default_socket nur für lokale Verbindungen verwendet wird.

👉 Für den Fernzugriff müssen wir den Hostnamen & die Port-Einstellungen richtig setzen.

✅ Lösung: PHP & phpMyAdmin für Remote-Zugriff über VPN konfigurieren

1️⃣ MySQL-Socket für lokale Verbindungen behalten

In php.ini bleibt für lokale Verbindungen:

ini

KopierenBearbeiten

pdo_mysql.default_socket = /opt/homebrew/var/mariadb/mariadb.sock

mysqli.default_socket = /opt/homebrew/var/mariadb/mariadb.sock

mysql.default_socket = /opt/homebrew/var/mariadb/mariadb.sock

🚀 Diese Werte sind nur für 127.0.0.1 oder localhost relevant.

2️⃣ Remote-Zugriff über VPN oder externen Host

Für https://pma.aewi.de muss MariaDB auf einer IP-Adresse erreichbar sein. Standardmäßig bindet sich MariaDB nur an 127.0.0.1, also kein externer Zugriff erlaubt!

👉 Lösung: In my.cnf (MariaDB-Konfiguration) erlauben wir den Fernzugriff:

bash

KopierenBearbeiten

nano /opt/homebrew/etc/my.cnf

Ändere folgende Zeilen:

ini

KopierenBearbeiten

[mysqld]

bind-address = 0.0.0.0

port = 3306

🚀 Das erlaubt den Zugriff von externen Geräten (z. B. über VPN oder LAN).

👉 Starte MariaDB neu, damit die Änderungen aktiv werden:

bash

KopierenBearbeiten

brew services restart mariadb@10.5

3️⃣ phpMyAdmin für Remote-Host konfigurieren

Falls phpMyAdmin über VPN genutzt wird, muss der Remote-Host gesetzt sein.

👉 Öffne die config.inc.php von phpMyAdmin:

bash

KopierenBearbeiten

nano /opt/homebrew/share/phpmyadmin/config.inc.php

🔹 Füge einen neuen Server-Eintrag für Remote-Zugriff hinzu:

php

KopierenBearbeiten

$i++;

$cfg['Servers'][$i]['host'] = 'pma.aewi.de'; // VPN oder Remote-Host

$cfg['Servers'][$i]['port'] = '3306'; // Standard-Port für MariaDB

$cfg['Servers'][$i]['connect_type'] = 'tcp';

$cfg['Servers'][$i]['AllowNoPassword'] = false;

$cfg['Servers'][$i]['user'] = 'root';

$cfg['Servers'][$i]['password'] = 'DEIN_PASSWORT';

👉 Danach Apache neu starten, damit phpMyAdmin die Änderungen übernimmt:

bash

KopierenBearbeiten

brew services restart httpd

✅ 4️⃣ Letzter Test: Verbindung aus der Ferne

Teste jetzt über dein VPN:

bash

KopierenBearbeiten

mysql -u root -p -h pma.aewi.de

🔹 Falls kein Fehler kommt, funktioniert der Zugriff über VPN.

🔹 Falls "Access denied", dann muss MariaDB den Zugriff erlauben:

sql

KopierenBearbeiten

GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'DEIN_PASSWORT' WITH GRANT OPTION;

FLUSH PRIVILEGES;

🚀 Nun sollte phpMyAdmin unter https://pma.aewi.de funktionieren!

🔥 Fazit

✅ Lokale Verbindungen nutzen weiterhin den Socket (mariadb.sock).

✅ Remote-Verbindungen über VPN nutzen TCP/IP (bind-address = 0.0.0.0).

✅ phpMyAdmin muss für den Remote-Host konfiguriert sein.

🚀 Teste die Änderungen und gib mir dein Feedback! 💪

Nikolaos:

Fehler ist nun behoben.

Wir haben offenbar die ganze Zeit an MariaDB rumgebastelt obwohl es php die Path und .zshrc war.

Der Zugang über VPN und lokal mittels "https://aewi.de/phpmyadmin/index.php?" ist nun möglich, sollte aber "https://pma.aewi.de/phpmyadmin/index.php?" sein, also "https://pma.aewi.de…" und nicht "https://aewi.de…"

Was muß dazu geändert werden?

httpd-vhosts.conf ist richtig konfiguriert.

in httpd.conf ist folgendes aktiv:

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

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

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

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

in dnsmasq.conf ist folgendes aktiv:

address=/aewi.de/192.168.2.3

address=/wiki.aewi.de/192.168.2.3

address=/api.aewi.de/192.168.2.3

address=/pma.aewi.de/192.168.2.3

address=/phpmyadmin/192.168.2.3

in config.inc.php ist folgendes aktiv:

$cfg['Servers'][$i]['host'] = '127.0.0.1';

Welche Einträge sind falsch oder fehlen?

address=/aewi.de/192.168.2.3 soll spotter die home-Website sein.

Sudomains sollen die verschiedenen Dienste direkt ansprechen.

2/2

Sophos:

✅ Lösung: phpMyAdmin auf pma.aewi.de umleiten

Der Fehler liegt vermutlich daran, dass phpMyAdmin noch unter aewi.de läuft, obwohl du es unter pma.aewi.dehaben möchtest.

Wir müssen sicherstellen, dass:

Apache die Subdomain pma.aewi.de korrekt verarbeitet.
phpMyAdmin nur unter pma.aewi.de läuft.
dnsmasq die Domain-Zuordnung korrekt macht.

1️⃣ HTTPD: VirtualHost für pma.aewi.de

📌 Bearbeite die Datei /opt/homebrew/etc/httpd/extra/httpd-vhosts.conf

bash

KopierenBearbeiten

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

🚀 Ändere oder ergänze folgenden Eintrag für pma.aewi.de:

apache

KopierenBearbeiten

ServerName pma.aewi.de

DocumentRoot "/opt/homebrew/share/phpmyadmin"

AllowOverride All

Require all granted

</Directory>

SSLEngine on

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

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

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

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

</VirtualHost>

🔥 Speichern & schließen (STRG+O, ENTER, STRG+X).

🚀 Apache neu starten:

bash

KopierenBearbeiten

brew services restart httpd

2️⃣ dnsmasq: Sicherstellen, dass pma.aewi.de richtig aufgelöst wird

📌 Bearbeite die Datei /opt/homebrew/etc/dnsmasq.conf

bash

KopierenBearbeiten

nano /opt/homebrew/etc/dnsmasq.conf

🔹 Stelle sicher, dass die folgende Zeile enthalten ist:

ini

KopierenBearbeiten

address=/pma.aewi.de/192.168.2.3

🚀 dnsmasq neu starten:

bash

KopierenBearbeiten

brew services restart dnsmasq

3️⃣ phpMyAdmin: Hostname anpassen

📌 Bearbeite die Datei /opt/homebrew/share/phpmyadmin/config.inc.php

bash

KopierenBearbeiten

nano /opt/homebrew/share/phpmyadmin/config.inc.php

🔹 Setze den Host explizit auf pma.aewi.de:

php

KopierenBearbeiten

$cfg['Servers'][$i]['host'] = 'pma.aewi.de';

🚀 Speichern & schließen (STRG+O, ENTER, STRG+X).

🚀 Apache erneut neu starten:

bash

KopierenBearbeiten

brew services restart httpd

4️⃣ Letzter Test

🔹 Öffne in deinem Browser:

👉 https://pma.aewi.de/phpmyadmin/index.php

👉 Falls es nicht funktioniert, prüfe mit:

bash

KopierenBearbeiten

nslookup pma.aewi.de

👉 Falls nslookup nicht 192.168.2.3 zurückgibt, leere den DNS-Cache:

bash

KopierenBearbeiten

sudo dscacheutil -flushcache

sudo killall -HUP mDNSResponder

🚀 Jetzt sollte phpMyAdmin nur noch unter pma.aewi.de erreichbar sein! 🎯

Nikolaos:

Die einzige Änderung war also "$cfg['Servers'][$i]['host'] = 'pma.aewi.de';"

Nun kann ich mich dennoch mit "https://pma.aewi.de…" und "https://aewi.de…" anmelden.

Was muß ich ändern, damit ich nur über "https://pma.aewi.de…" phpmyadmin nutzen kann?

Sophos:

Um sicherzustellen, dass phpMyAdmin nur über https://pma.aewi.de erreichbar ist, müssen wir zwei Dinge tun:

Apache blockiert phpMyAdmin-Zugriff über aewi.de.
phpMyAdmin leitet alle Anfragen auf pma.aewi.de um.

1️⃣ Apache: Zugriff auf phpMyAdmin nur für pma.aewi.de erlauben

📌 Öffne die Datei /opt/homebrew/etc/httpd/extra/httpd-phpmyadmin.conf

bash

KopierenBearbeiten

nano /opt/homebrew/etc/httpd/extra/httpd-phpmyadmin.conf

🚀 Füge folgende Regeln hinzu:

apache

KopierenBearbeiten

Require all denied

</Directory>

ServerName pma.aewi.de

DocumentRoot "/opt/homebrew/share/phpmyadmin"

Require all granted

AllowOverride All

</Directory>

SSLEngine on

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

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

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

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

</VirtualHost>

📌 Speichern & schließen (STRG+O, ENTER, STRG+X).

🚀 Apache neu starten:

bash

KopierenBearbeiten

brew services restart httpd

🔹 Jetzt ist phpMyAdmin nur noch unter pma.aewi.de erreichbar!

🔹 Falls jemand https://aewi.de/phpmyadmin/ aufruft, erhält er eine Zugriff verweigert (403 Forbidden) Meldung.

2️⃣ Optional: Automatische Weiterleitung zu pma.aewi.de

Falls du möchtest, dass Anfragen an aewi.de/phpmyadmin/ automatisch zu pma.aewi.de umgeleitet werden, dann:

📌 Öffne /opt/homebrew/etc/httpd/extra/httpd-vhosts.conf:

bash

KopierenBearbeiten

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

🔹 Füge am Ende diese Zeilen hinzu:

apache

KopierenBearbeiten

ServerName aewi.de

Redirect 301 /phpmyadmin https://pma.aewi.de/phpmyadmin

</VirtualHost>

🚀 Apache erneut neu starten:

bash

KopierenBearbeiten

brew services restart httpd

🔥 Fazit

✅ phpMyAdmin ist nur über https://pma.aewi.de erreichbar.

✅ Falls jemand https://aewi.de/phpmyadmin aufruft, wird er umgeleitet oder blockiert.

🎯 Teste jetzt & gib mir dein Feedback! 🚀

Nikolaos:

zu 1. Apache: Zugriff auf phpMyAdmin nur für pma.aewi.de erlauben

du gibst da httpd-phpmyadmin.conf an, ist es nicht richtiger dies in httpd-vhost.conf einzufügen?

in httpd-phpmyadmin.conf steht nur folgendes:

Alias /phpmyadmin /opt/homebrew/share/phpmyadmin

Options Indexes FollowSymLinks MultiViews

AllowOverride All

Require all granted

</Directory>

Sophos:

Ja, du hast recht! Die VirtualHost-Konfiguration gehört in die httpd-vhosts.conf, nicht in httpd-phpmyadmin.conf.

Die httpd-phpmyadmin.conf sollte nur für das Alias und die grundlegenden Zugriffsrechte sorgen. Die eigentliche Zugriffsbeschränkung und Umleitung müssen wir in httpd-vhosts.conf umsetzen.

✅ Korrekte Konfiguration in httpd-vhosts.conf

📌 Öffne die Datei /opt/homebrew/etc/httpd/extra/httpd-vhosts.conf

bash

KopierenBearbeiten

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

🚀 Füge folgende Einträge hinzu oder passe bestehende an:

apache

KopierenBearbeiten

# Erlaubt phpMyAdmin NUR über pma.aewi.de

ServerName pma.aewi.de

DocumentRoot "/opt/homebrew/share/phpmyadmin"

Require all granted

AllowOverride All

</Directory>

SSLEngine on

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

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

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

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

</VirtualHost>

# Blockiert den Zugriff auf phpMyAdmin über aewi.de

ServerName aewi.de

Require all denied

</Directory>

</VirtualHost>

📌 Speichern & schließen (STRG+O, ENTER, STRG+X).

🚀 Apache neu starten:

bash

KopierenBearbeiten

brew services restart httpd

🔥 Was passiert jetzt?

✅ phpMyAdmin ist nur über https://pma.aewi.de/phpmyadmin erreichbar.

✅ Falls jemand https://aewi.de/phpmyadmin aufruft, erhält er eine "403 Forbidden" Fehlermeldung.

🔁 Alternative: Automatische Weiterleitung

Falls du nicht blockieren, sondern automatisch umleiten möchtest, ersetze diesen Block:

apache

KopierenBearbeiten

ServerName aewi.de

Require all denied

</Directory>

</VirtualHost>

durch:

apache

KopierenBearbeiten

ServerName aewi.de

Redirect 301 /phpmyadmin https://pma.aewi.de/phpmyadmin

</VirtualHost>

📌 Apache erneut neu starten:

bash

KopierenBearbeiten

brew services restart httpd

🔹 Jetzt wird jede Anfrage an https://aewi.de/phpmyadmin automatisch zu https://pma.aewi.de/phpmyadminumgeleitet.

🎯 Fazit

🔹 Methode 1 (403 Forbidden) = phpMyAdmin auf aewi.de ist blockiert.

🔹 Methode 2 (Redirect 301) = Alle Anfragen an aewi.de/phpmyadmin werden umgeleitet.

✨ Wähle, was für dich am besten passt! 🚀

Nikolaos:

Ich habe rebdirekt wie folgt in httpd-vhosts.conf für phpmyadmin und mediawiki eingegeben:

ServerName aewi.de

ServerAlias www.aewi.de

# Redirect phpMyAdmin

Redirect 301 /phpmyadmin https://pma.aewi.de/phpmyadmin

# Redirect MediaWiki

Redirect 301 /mediawiki https://wiki.aewi.de

SSLEngine on

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

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

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

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

</VirtualHost>

Wenn ich das tue, kann ich die Seiten lokal jedoch nicht über wireguard aufrufen. Was ist an der Konfiguration falsch? oder was muß ich für wireguard ergänzen oder ändern?

Müssen die Einträge an einer bestimmten Stelle sein, damit sie funktionieren?

DNS ist dnsmasq. Intern wird kein VPN genutzt. Wenn von Außen über VPN Anfragen hereinkommen, werden diese offenbar nicht aufgelöst und an die Subdomain weitergeleitet. Es könnte also eine Einstellung in dnsmasq oder wireguard sein.

3/3

Sophos:

Damit phpMyAdmin und MediaWiki über VPN (WireGuard) korrekt erreichbar sind, müssen wir sicherstellen, dass:

WireGuard-Clients die korrekten DNS-Einträge erhalten.
Apache die Anfragen aus dem VPN-Netz richtig verarbeitet.
dnsmasq korrekt für VPN-Clients auflöst.
Die Redirect-Regeln richtig greifen.

🔹 1. WireGuard-Clients müssen die korrekten DNS-Einträge erhalten

📌 Öffne die WireGuard-Konfiguration auf dem Server:

bash

KopierenBearbeiten

sudo nano /etc/wireguard/wg0.conf

🔹 Füge sicherheitshalber dnsmasq als DNS-Server hinzu:

ini

KopierenBearbeiten

[Interface]

Address = 10.0.0.1/24

ListenPort = 51820

PrivateKey = SERVER_PRIVATE_KEY

DNS = 192.168.2.3 # Dein DNS-Server mit dnsmasq

📌 Speichern & WireGuard neu starten:

bash

KopierenBearbeiten

sudo systemctl restart wg-quick@wg0

🚀 Überprüfe auf einem VPN-Client:

bash

KopierenBearbeiten

nslookup pma.aewi.de

nslookup wiki.aewi.de

Erwartetes Ergebnis: 192.168.2.3

🔹 2. Apache VirtualHosts für VPN erweitern

📌 Ändere die httpd-vhosts.conf, um auch VPN-Anfragen zu verarbeiten.

bash

KopierenBearbeiten

ServerName aewi.de

ServerAlias www.aewi.de

# Redirects

Redirect 301 /phpmyadmin https://pma.aewi.de/phpmyadmin

Redirect 301 /mediawiki https://wiki.aewi.de

# Erlaubt Zugriffe aus VPN-Netz

Require ip 192.168.2.0/24

Require ip 10.0.0.0/24 # Falls VPN-Netz in 10.0.0.x liegt

</Directory>

Require ip 192.168.2.0/24

Require ip 10.0.0.0/24

</Directory>

SSLEngine on

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

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

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

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

</VirtualHost>

📌 Speichern & Apache neu starten:

bash

KopierenBearbeiten

brew services restart httpd

🚀 Jetzt sollten auch VPN-Clients Zugriff haben.

🔹 3. dnsmasq muss VPN-Clients auflösen

📌 Öffne dnsmasq.conf:

bash

KopierenBearbeiten

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

🔹 Ergänze sicherheitshalber die VPN-Clients:

ini

KopierenBearbeiten

address=/pma.aewi.de/192.168.2.3

address=/wiki.aewi.de/192.168.2.3

listen-address=192.168.2.3

listen-address=10.0.0.1

📌 dnsmasq neu starten:

bash

KopierenBearbeiten

brew services restart dnsmasq

🚀 Überprüfe von einem VPN-Client:

bash

KopierenBearbeiten

nslookup wiki.aewi.de

nslookup pma.aewi.de

✅ Sollte 192.168.2.3 liefern.

🔹 4. Firewall prüfen (falls nötig)

Falls du macOS‘ pf-Firewall oder eine andere Firewall nutzt, überprüfe, ob Port 443 für VPN-Clients erlaubt ist:

bash

KopierenBearbeiten

sudo pfctl -sr | grep 443

Falls nichts zurückkommt, kannst du eine Regel setzen:

bash

KopierenBearbeiten

echo "pass in on en0 proto tcp from 10.0.0.0/24 to any port 443" | sudo pfctl -f -

🔹 🔥 Fazit

🔹 WireGuard-Clients erhalten nun korrekte DNS-Infos.

🔹 Apache akzeptiert Zugriffe von VPN-Clients.

🔹 dnsmasq löst VPN-Anfragen richtig auf.

🔹 Firewall-Regeln sind geprüft.

✨ Jetzt testen! 🚀

Nikolaos:

dnsmasq ist derzeit: listen-address=127.0.0.1,192.168.2.3

was bewirkt "listen-address=10.0.0.1" anstelle von "listen-address=127.0.0.1"

Sophos:

📌 Wirkung von listen-address in dnsmasq.conf

🔹 Derzeitige Konfiguration:

ini

KopierenBearbeiten

listen-address=127.0.0.1,192.168.2.3

✅ Bedeutet, dass dnsmasq nur auf localhost (127.0.0.1) und im LAN (192.168.2.3)` Anfragen annimmt.

❌ VPN-Clients (10.0.0.x) können DNS-Anfragen möglicherweise nicht auflösen.

🔹 Alternative: listen-address=10.0.0.1

ini

KopierenBearbeiten

listen-address=10.0.0.1

✅ dnsmasq hört nur auf dem VPN-Interface

❌ Lokale Anfragen aus 127.0.0.1 oder 192.168.2.3 würden nicht beantwortet.

⚠️ Das wäre ein Problem für lokale Dienste.

🔹 Empfohlene Konfiguration für LAN + VPN

✅ Falls VPN-Clients auch Anfragen an dnsmasq senden sollen, ergänze 10.0.0.1:

ini

KopierenBearbeiten

listen-address=127.0.0.1,192.168.2.3,10.0.0.1

🔹 Jetzt kann dnsmasq Anfragen von lokalen Diensten (127.0.0.1), LAN (192.168.2.3) und VPN-Clients (10.0.0.1) bearbeiten.

🔹 Erforderlich, wenn WireGuard-Clients auch pma.aewi.de und wiki.aewi.de korrekt auflösen sollen.

🚀 So testen, ob VPN-Clients pma.aewi.de richtig auflösen können:

1️⃣ Auf einem VPN-Client (über WireGuard) ausführen:

bash

KopierenBearbeiten

nslookup pma.aewi.de 10.0.0.1

✅ Erwartete Antwort:

bash

KopierenBearbeiten

Server: 10.0.0.1

Address: 10.0.0.1#53

Name: pma.aewi.de

Address: 192.168.2.3

❌ Falls keine oder eine falsche IP zurückkommt, liegt das Problem entweder an dnsmasq oder der VPN-Konfiguration.

🔥 Fazit

Aktuelle Einstellung (127.0.0.1,192.168.2.3) erlaubt KEINE DNS-Anfragen über VPN.
Empfohlen: listen-address=127.0.0.1,192.168.2.3,10.0.0.1, damit VPN-Clients pma.aewi.de und wiki.aewi.de auflösen können.
Nach Änderung dnsmasq neu starten: bash KopierenBearbeiten brew services restart dnsmasq

Nikolaos:

Kann man nicht aewi.de mit etwas belegen, so daß keine rebdirect's erforderlich sind, weil da ein Dienst läuft, z.b. Homepage?

AEWI Homepage unter /Library/WebServer/Documents/aewi/index.html

2/2

Sophos:

AEWI Homepage unter aewi.de ohne Redirects einrichten

Ja, das ist möglich! Anstatt Redirects für aewi.de zu nutzen, kannst du dort eine eigene Website (z. B. deine AEWI-Homepage) hosten. Hier ist die richtige Konfiguration:

1️⃣ Apache Virtual Host für aewi.de mit Homepage

Öffne die Datei /opt/homebrew/etc/httpd/extra/httpd-vhosts.conf und ändere oder füge Folgendes hinzu:

apache

KopierenBearbeiten

ServerAdmin webmaster@aewi.de

ServerName aewi.de

ServerAlias www.aewi.de

DocumentRoot "/Library/WebServer/Documents/aewi"

Options Indexes FollowSymLinks MultiViews

AllowOverride All

Require all granted

</Directory>

SSLEngine on

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

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

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

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

</VirtualHost>

📌 Erläuterung:

DocumentRoot "/Library/WebServer/Documents/aewi" sorgt dafür, dass aewi.de die dort gespeicherten Inhalte (z. B. index.html) lädt.
Keine Redirects – aewi.de zeigt eine echte Website an.
SSL ist aktiviert, sodass https://aewi.de funktioniert.

2️⃣ Virtual Hosts für Subdomains (pma.aewi.de, wiki.aewi.de)

Damit pma.aewi.de und wiki.aewi.de weiterhin auf phpMyAdmin bzw. MediaWiki verweisen, brauchst du folgende Virtual Hosts in httpd-vhosts.conf:

📌 phpMyAdmin unter pma.aewi.de

apache

KopierenBearbeiten

ServerAdmin webmaster@aewi.de

ServerName pma.aewi.de

DocumentRoot "/opt/homebrew/share/phpmyadmin"

Options Indexes FollowSymLinks MultiViews

AllowOverride All

Require all granted

</Directory>

SSLEngine on

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

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

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

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

</VirtualHost>

📌 MediaWiki unter wiki.aewi.de

apache

KopierenBearbeiten

ServerAdmin webmaster@aewi.de

ServerName wiki.aewi.de

DocumentRoot "/Library/WebServer/Documents/wiki"

Options Indexes FollowSymLinks MultiViews

AllowOverride All

Require all granted

</Directory>

SSLEngine on

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

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

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

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

</VirtualHost>

3️⃣ Änderungen in dnsmasq.conf

Damit auch das DNS korrekt aufgelöst wird, solltest du sicherstellen, dass dnsmasq für aewi.de, pma.aewi.de und wiki.aewi.de auf die richtige IP zeigt.

📌 Prüfe /opt/homebrew/etc/dnsmasq.conf und ergänze oder überprüfe folgende Zeilen:

ini

KopierenBearbeiten

address=/aewi.de/192.168.2.3

address=/wiki.aewi.de/192.168.2.3

address=/api.aewi.de/192.168.2.3

address=/pma.aewi.de/192.168.2.3

🔹 Falls Änderungen gemacht wurden, dnsmasq neu starten:

bash

KopierenBearbeiten

brew services restart dnsmasq

4️⃣ Apache Neustart

Nach diesen Änderungen Apache neu starten:

bash

KopierenBearbeiten

brew services restart httpd

5️⃣ Testen

📌 Testen im Browser

https://aewi.de → Sollte deine AEWI-Homepage anzeigen
https://pma.aewi.de → Sollte phpMyAdmin öffnen
https://wiki.aewi.de → Sollte MediaWiki öffnen

📌 Überprüfen mit nslookup oder dig

Falls etwas nicht geht, prüfe, ob die Domains korrekt aufgelöst werden:

bash

KopierenBearbeiten

nslookup aewi.de

nslookup pma.aewi.de

nslookup wiki.aewi.de

✅ Sollte 192.168.2.3 zurückgeben.

🔥 Fazit

KEINE Redirects mehr erforderlich!
aewi.de hat jetzt eine richtige Homepage (/Library/WebServer/Documents/aewi)
phpMyAdmin (pma.aewi.de) und MediaWiki (wiki.aewi.de) sind als eigene Subdomains erreichbar.
Apache, dnsmasq und MariaDB arbeiten sauber zusammen. 🚀

Nikolaos:

OK. welche Änderungen benötigt http.conf damit ich bei Aufruf von aewi.de auf https://aewi.de/index.html lande?

muß ich DocumentRoot "/Library/WebServer/Documents", dann nicht auf DocumentRoot "/Library/WebServer/Documents/aewi" ändern?

2/2

Sophos:

Ja, du musst die DocumentRoot-Einstellung in httpd.conf oder deiner httpd-vhosts.conf so ändern, dass sie direkt auf das Verzeichnis zeigt, in dem sich die index.html deiner AEWI-Homepage befindet.

1️⃣ httpd-vhosts.conf anpassen

Falls du Virtual Hosts nutzt (empfohlen), ändere oder erstelle folgenden Eintrag in /opt/homebrew/etc/httpd/extra/httpd-vhosts.conf:

apache

KopierenBearbeiten

ServerAdmin webmaster@aewi.de

ServerName aewi.de

ServerAlias www.aewi.de

DocumentRoot "/Library/WebServer/Documents/aewi"

Options Indexes FollowSymLinks MultiViews

AllowOverride All

Require all granted

</Directory>

SSLEngine on

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

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

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

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

</VirtualHost>

🔹 Wichtige Änderungen:

DocumentRoot "/Library/WebServer/Documents/aewi" verweist direkt auf den Ordner mit der index.html
<Directory "/Library/WebServer/Documents/aewi"> gibt Zugriff auf dieses Verzeichnis

2️⃣ Falls kein VirtualHost genutzt wird – httpd.conf anpassen

Falls du keinen VirtualHost für aewi.de nutzt, kannst du die Einstellung direkt in /opt/homebrew/etc/httpd/httpd.conf ändern:

Suche nach:

apache

KopierenBearbeiten

DocumentRoot "/Library/WebServer/Documents"

Und ersetze es durch:

apache

KopierenBearbeiten

DocumentRoot "/Library/WebServer/Documents/aewi"

Speichern und schließen.

3️⃣ Apache und DNS neu starten

Nach den Änderungen musst du Apache und dnsmasq neu starten:

bash

KopierenBearbeiten

brew services restart dnsmasq

brew services restart httpd

Falls du eine Firewall oder WireGuard verwendest, stelle sicher, dass aewi.de in der internen DNS-Konfiguration richtig weitergeleitet wird.

4️⃣ Testen

Rufe https://aewi.de in deinem Browser auf – es sollte nun die index.html aus /Library/WebServer/Documents/aewi geladen werden.
Falls der Browser noch eine alte Weiterleitung nutzt, lösche den Cache:
- Strg + Shift + Entf (Windows/Linux) oder Cmd + Shift + Entf (Mac)
- Oder öffne die Seite im Inkognito-Modus.

Falls die Startseite nicht geladen wird, überprüfe die Apache-Logs:

bash

KopierenBearbeiten

tail -n 50 /opt/homebrew/var/log/httpd/aewi_error.log

🔥 Fazit

aewi.de zeigt jetzt die richtige index.html-Datei aus /Library/WebServer/Documents/aewi an.
Falls du httpd-vhosts.conf nutzt, sind keine weiteren Änderungen an httpd.conf nötig.
Apache muss nach den Änderungen neu gestartet werden.

✅ Ergebnis: https://aewi.de lädt die Homepage ohne Redirects. 🚀

Nikolaos:

Homepage funktioniert jetzt.

Welche Konfiguration brauche ich jetzt für Mediawiki LocalSettings.php?

Derzeit für den Anbindung enthalten ist:

# Protect against web entry

if ( !defined( 'MEDIAWIKI' ) ) {

exit;

}

## Uncomment this to disable output compression

# $wgDisableOutputCompression = true;

$wgSitename = "AufEinWort";

$wgMetaNamespace = "AufEinWort";

## The URL base path to the directory containing the wiki;

## defaults for all runtime URL paths are based off of this.

## For more information on customizing the URLs

## (like /w/index.php/Page_title to /wiki/Page_title) please see:

## https://www.mediawiki.org/wiki/Manual:Short_URL

$wgScriptPath = "";

## The protocol and server name to use in fully-qualified URLs

$wgServer = "https://wiki.aewi.de";

## The URL path to static resources (images, scripts, etc.)

$wgResourceBasePath = $wgScriptPath;

## The URL paths to the logo. Make sure you change this from the default,

## or else you'll overwrite your logo when you upgrade!

$wgLogos = [

'1x' => "$wgResourceBasePath/resources/assets/change-your-logo.svg",

'icon' => "$wgResourceBasePath/resources/assets/change-your-logo.svg",

];

$wgCookiePrefix = "aewi"; // Eindeutiger Präfix für alle Cookies

$wgCookieSecure = false;

$wgCookieSameSite = "Lax";

## UPO means: this is also a user preference option

$wgEnableEmail = true;

$wgEnableUserEmail = true; # UPO

$wgEmergencyContact = "klaus.feldmann@online.de";

$wgPasswordSender = "klaus.feldmann@online.de";

$wgEnotifUserTalk = false; # UPO

$wgEnotifWatchlist = false; # UPO

$wgEmailAuthentication = true;

## Database settings

$wgDBtype = "mysql";

$wgDBserver = "127.0.0.1"; # or localhost

$wgDBname = "mediawiki";

$wgDBuser = "root";

$wgDBpassword = "44%%55Aufeinwort";

# MySQL specific settings

$wgDBprefix = "";

$wgDBssl = true;

# MySQL table options to use during installation or update

$wgDBTableOptions = "ENGINE=InnoDB, DEFAULT CHARSET=binary";

Sophos:

Deine aktuelle LocalSettings.php-Konfiguration sieht größtenteils korrekt aus, aber es gibt einige Punkte, die überprüft oder optimiert werden sollten, um MediaWiki erfolgreich mit MariaDB unter https://wiki.aewi.de zu verbinden.

🔍 Wichtige Punkte zur Prüfung:

Datenbankverbindung – MariaDB
- 127.0.0.1 als wgDBserver ist korrekt, aber teste auch localhost.
- Falls SSL nicht zwingend erforderlich ist, setze $wgDBssl = false;.

Wiki-Pfad ($wgScriptPath)

- Derzeit ist $wgScriptPath = ""; gesetzt, aber wenn MediaWiki in einem Unterverzeichnis wie /wiki liegt, sollte es "/wiki" sein.

SSL-Optionen für die Datenbank ($wgDBssl)

- Falls keine SSL-Verbindung zur Datenbank erforderlich ist, setze $wgDBssl = false;.

✅ Korrigierte LocalSettings.php

Hier ist die optimierte Konfiguration:

php

KopierenBearbeiten

# Schutz gegen direkten Webzugriff

if ( !defined( 'MEDIAWIKI' ) ) {

exit;

}

## Grundkonfiguration

$wgSitename = "AufEinWort";

$wgMetaNamespace = "AufEinWort";

## Server- und URL-Konfiguration

$wgServer = "https://wiki.aewi.de";

$wgScriptPath = "/wiki"; # Falls MediaWiki unter /wiki installiert ist

$wgResourceBasePath = $wgScriptPath;

## Logo-Einstellungen

$wgLogos = [

'1x' => "$wgResourceBasePath/resources/assets/change-your-logo.svg",

'icon' => "$wgResourceBasePath/resources/assets/change-your-logo.svg",

];

## Cookie-Einstellungen

$wgCookiePrefix = "aewi";

$wgCookieSecure = true; # Falls Wiki nur über HTTPS läuft

$wgCookieSameSite = "Lax";

## E-Mail-Einstellungen

$wgEnableEmail = true;

$wgEnableUserEmail = true;

$wgEmergencyContact = "klaus.feldmann@online.de";

$wgPasswordSender = "klaus.feldmann@online.de";

$wgEnotifUserTalk = false;

$wgEnotifWatchlist = false;

$wgEmailAuthentication = true;

## Datenbank-Konfiguration

$wgDBtype = "mysql";

$wgDBserver = "127.0.0.1"; # Falls Verbindungsprobleme auftreten, versuche "localhost"

$wgDBname = "mediawiki";

$wgDBuser = "root";

$wgDBpassword = "44%%55Aufeinwort";

$wgDBprefix = "";

$wgDBssl = false; # Falls kein SSL für DB-Verbindung benötigt wird

## MySQL spezifische Einstellungen

$wgDBTableOptions = "ENGINE=InnoDB, DEFAULT CHARSET=utf8mb4";

$wgDBmysql5 = false; # Falls MediaWiki speziell für MySQL 5.7 kompatibel sein muss, auf true setzen

## Debugging (optional bei Problemen)

#$wgShowExceptionDetails = true;

#$wgShowDBErrorBacktrace = true;

🛠️ Wichtige Änderungen:

$wgScriptPath = "/wiki"; → Falls MediaWiki unter https://wiki.aewi.de/wiki läuft.
$wgDBssl = false; → SSL nur aktivieren, wenn benötigt.
$wgCookieSecure = true; → Falls nur HTTPS genutzt wird.
$wgDBTableOptions = "ENGINE=InnoDB, DEFAULT CHARSET=utf8mb4"; → UTF8MB4 für bessere Unicode-Unterstützung.

📌 Weitere Überprüfungen

Falls MediaWiki immer noch nicht funktioniert:

Prüfe, ob MariaDB richtig läuft bash KopierenBearbeiten brew services list | grep mariadb
Falls mariadb@10.5 stopped angezeigt wird: bash KopierenBearbeiten brew services restart mariadb@10.5
Testen der MySQL/MariaDB-Verbindung Versuche, dich direkt mit der Datenbank zu verbinden: bash KopierenBearbeiten mariadb -u root -p -h 127.0.0.1 mediawiki
Falls das nicht geht, versuche: bash KopierenBearbeiten mariadb -u root -p -h localhost mediawiki
Apache VirtualHost für MediaWiki prüfen Stelle sicher, dass httpd-vhosts.conf folgende Konfiguration enthält: apache KopierenBearbeiten <VirtualHost *:443>
ServerName wiki.aewi.de
DocumentRoot "/Library/WebServer/Documents/wiki"
<Directory "/Library/WebServer/Documents/wiki">
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>
SSLEngine on
SSLCertificateFile "/etc/letsencrypt/live/aewi.de/fullchain.pem"
SSLCertificateKeyFile "/etc/letsencrypt/live/aewi.de/privkey.pem"
ErrorLog "/opt/homebrew/var/log/httpd/wiki_error.log"
CustomLog "/opt/homebrew/var/log/httpd/wiki_access.log" common
</VirtualHost>
DNS und Subdomains überprüfen Stelle sicher, dass wiki.aewi.de in dnsmasq.conf korrekt eingetragen ist: ini KopierenBearbeiten address=/wiki.aewi.de/192.168.2.3
Nach Änderungen: bash KopierenBearbeiten brew services restart dnsmasq
brew services restart httpd

🛠️ Fazit

Wiki sollte unter https://wiki.aewi.de/wiki erreichbar sein.
Falls nicht, prüfe DNS, VirtualHost, MariaDB-Verbindung und Apache-Logs.

Falls noch Probleme bestehen, welche Fehlermeldung erscheint aktuell in MediaWiki? 🚀

Nikolaos:

Danke. Müßte "$wgDBtype = "mysql";" nicht dann "$wgDBtype = "mariadb";" sein?

Sophos:

Nein, $wgDBtype = "mysql"; ist richtig – auch für MariaDB.

📌 Warum bleibt es "mysql" und nicht "mariadb"?

MariaDB ist ein MySQL-Derivat
- MediaWiki verwendet die MySQL-API, die auch für MariaDB funktioniert.
- In MediaWiki gibt es keine separate Einstellung für MariaDB, weil sich MariaDB gegenüber Anwendungen wie MySQL verhält.

MediaWiki erkennt automatisch MariaDB

- Falls du mariadb anstelle von mysql setzt, wird MediaWiki die Datenbank nicht finden.
- Intern erkennt MediaWiki die Version und passt sich an.

Bestätigung durch MediaWiki-Dokumentation

- Die offizielle MediaWiki-Dokumentation verwendet ebenfalls mysql für MariaDB: 👉 MediaWiki Database Configuration

🛠️ Fazit

Lasse $wgDBtype = "mysql"; so stehen.
MediaWiki erkennt MariaDB automatisch und funktioniert einwandfrei. 🚀

Nikolaos:

Ich konnte mich nun in MediaWiki einloggen.

Ich erhalte folgende Fehlermeldung:

[e0f31c40bfdc837630cd90be] /index.php FatalError: If you use a relative URL for $wgArticlePath, it must start with a slash (<code>/</code>).<br><br>See <a href="https://www.mediawiki.org/wiki/Manual:$wgArticlePath">https://www.mediawiki.org/wiki/Manual:$wgArticlePath</a>.

Backtrace:

from /Library/WebServer/Documents/mediawiki/includes/Request/PathRouter.php(184)

#0 /Library/WebServer/Documents/mediawiki/includes/Request/WebRequest.php(200): MediaWiki\Request\PathRouter->validateRoute(string, string)

#1 /Library/WebServer/Documents/mediawiki/includes/Request/WebRequest.php(398): MediaWiki\Request\WebRequest->getPathInfo(string)

#2 /Library/WebServer/Documents/mediawiki/includes/Setup.php(466): MediaWiki\Request\WebRequest->interpolateTitle()

#3 /Library/WebServer/Documents/mediawiki/includes/WebStart.php(85): require_once(string)

#4 /Library/WebServer/Documents/mediawiki/index.php(50): require(string)

#5 {main}

Sophos:

Der Fehler hängt mit der Konfiguration von $wgArticlePath in deiner LocalSettings.php zusammen.

✅ Lösung: $wgArticlePath richtig setzen

Öffne LocalSettings.php und überprüfe oder füge folgende Zeile hinzu:

php

KopierenBearbeiten

$wgArticlePath = "/wiki/$1";

Stelle sicher, dass der Wert mit einem Slash (/) beginnt.

🔍 Warum tritt der Fehler auf?

LocalSettings.php erwartet, dass $wgArticlePath mit einem Slash (/) beginnt, wenn du eine relative URL verwendest.
Falls es leer ist oder einen falschen Wert hat (z. B. "wiki/$1" ohne /), führt das zu diesem Fehler.

🛠 Falls du Short URLs nutzen willst:

Füge in LocalSettings.php hinzu: php KopierenBearbeiten $wgScriptPath = "/mediawiki";
$wgArticlePath = "/wiki/$1";
Apache Rewrite-Regeln in .htaccess oder httpd-vhosts.conf setzen Falls du kurze URLs (Short URLs) möchtest, sollte in httpd-vhosts.conf oder einer .htaccess-Datei Folgendes stehen: apache KopierenBearbeiten RewriteEngine On
RewriteRule ^/?wiki(/.*)?$ /mediawiki/index.php [L]
Hierbei wird /wiki/Artikelname auf /mediawiki/index.php?title=Artikelname umgeleitet.

📌 Fazit

Setze $wgArticlePath = "/wiki/$1"; in LocalSettings.php.
Falls du Short URLs möchtest, füge eine Rewrite-Regel hinzu.
Danach starte Apache neu: sh KopierenBearbeiten sudo brew services restart httpd

Das sollte dein Problem beheben. 🚀

Nikolaos:

Ich habe alle Änderungen durchgeführt und habe nun den Fehler 404.

Welche URL muß ich nun nutzen? ist "https://wiki.aewi.de/Hauptseite" richtig?

3/3

Sophos:

Ja, die URL https://wiki.aewi.de/Hauptseite ist grundsätzlich korrekt, wenn du die Short-URL-Konfiguration richtig vorgenommen hast. Da du aber jetzt einen 404-Fehler bekommst, gibt es ein Problem mit der Rewrite-Regel oder der Apache-Konfiguration.

🔍 Fehleranalyse: Warum 404 nach Short-URL-Umstellung?

Die häufigsten Ursachen für diesen Fehler sind:

Rewrite-Regeln in Apache greifen nicht oder sind deaktiviert. → Ist das mod_rewrite-Modul in Apache aktiv?
Die DocumentRoot-Einstellung verweist nicht auf das richtige Verzeichnis. → Ist das DocumentRoot in httpd-vhosts.conf korrekt gesetzt?
MediaWiki erwartet die URL noch im alten Format. → Hast du nach der Änderung den Apache-Server neugestartet?

🛠 Schritt-für-Schritt-Lösung:

1️⃣ Apache-Config überprüfen

Öffne deine httpd-vhosts.conf und stelle sicher, dass folgendes für wiki.aewi.de gesetzt ist:

apache

KopierenBearbeiten

ServerName wiki.aewi.de

DocumentRoot "/Library/WebServer/Documents/mediawiki"

Options FollowSymLinks

AllowOverride All

Require all granted

</Directory>

# SSL-Konfiguration (falls nötig)

SSLEngine on

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

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

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

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

</VirtualHost>

⚠️ Falls DocumentRoot falsch gesetzt ist (z. B. auf /Library/WebServer/Documents anstatt /Library/WebServer/Documents/mediawiki), dann funktioniert die Short-URL nicht.

2️⃣ Rewrite-Regel in .htaccess oder httpd-vhosts.conf aktivieren

Falls noch nicht geschehen, füge in .htaccess im mediawiki-Verzeichnis folgendes hinzu:

apache

KopierenBearbeiten

RewriteEngine On

RewriteRule ^/?wiki(/.*)?$ /mediawiki/index.php [L,QSA]

Falls du .htaccess nicht nutzt, dann stattdessen in httpd-vhosts.conf:

apache

KopierenBearbeiten

Options FollowSymLinks

AllowOverride All

Require all granted

RewriteEngine On

RewriteRule ^/?wiki(/.*)?$ /mediawiki/index.php [L,QSA]

</Directory>

3️⃣ MediaWiki LocalSettings.php anpassen

Stelle sicher, dass die folgenden Zeilen in LocalSettings.php korrekt sind:

php

KopierenBearbeiten

$wgScriptPath = "/mediawiki";

$wgArticlePath = "/wiki/$1";

$wgUsePathInfo = true; // Aktiviert die Nutzung von Short-URLs

Falls Short URLs nicht gewollt sind, kannst du $wgArticlePath wieder auf den Standard zurücksetzen:

php

KopierenBearbeiten

$wgArticlePath = "$wgScriptPath/index.php?title=$1";

4️⃣ Apache- und DNS-Dienste neustarten

Nach jeder Änderung Apache und dnsmasq neustarten:

sh

KopierenBearbeiten

sudo brew services restart httpd

sudo brew services restart dnsmasq

Falls du Änderungen an LocalSettings.php gemacht hast, lösche den MediaWiki-Cache:

sh

KopierenBearbeiten

rm -rf /Library/WebServer/Documents/mediawiki/cache/*

5️⃣ Testen, ob die URL funktioniert

Teste die Standard-MediaWiki-URL:
- https://de.wikipedia.org/w/index.php/Hauptseite Falls das geht, aber https://wiki.aewi.de/wiki/Hauptseite nicht, dann gibt es ein Problem mit der Rewrite-Regel.

Falls du eine 404-Seite bekommst, überprüfe die Apache-Logs: sh KopierenBearbeiten tail -f /opt/homebrew/var/log/httpd/wiki_error.log

📌 Fazit

404-Fehler kommt meist von falscher DocumentRoot-Einstellung oder fehlerhafter Rewrite-Regel.
Apache-Config (httpd-vhosts.conf) und MediaWiki-Config (LocalSettings.php) müssen zusammenpassen.
Apache nach jeder Änderung neustarten!
Teste, ob die Standard-URL (/mediawiki/index.php/Hauptseite) geht – wenn ja, dann liegt es nur an der Rewrite-Regel.

Teste das und sag mir, ob es jetzt funktioniert! 🚀

Nikolaos:

Ich kann das MediaWiki Setup durchführen, jedoch erhalte ich einen 404 Fehler, wenn ich nach dem Setup die Hauptseite aufrufe. Ich weiß nicht ob der Server .htaccess nutzt?

2/2

Sophos:

Da du das MediaWiki-Setup erfolgreich durchführen konntest, aber beim Aufruf der Hauptseite einen 404-Fehlerbekommst, liegt das Problem höchstwahrscheinlich an einer fehlenden oder nicht funktionierenden .htaccess-Dateioder an der Apache-Konfiguration (Rewrite-Module nicht aktiv).

🔍 Fehlersuche: Nutzt dein Server .htaccess?

Führe diesen Befehl aus, um zu überprüfen, ob .htaccess überhaupt existiert:

sh

KopierenBearbeiten

ls -la /Library/WebServer/Documents/mediawiki/

Falls die Datei .htaccess fehlt, erstelle sie mit folgendem Inhalt:

sh

KopierenBearbeiten

touch /Library/WebServer/Documents/mediawiki/.htaccess

🛠 Schritt-für-Schritt-Lösung

1️⃣ Stelle sicher, dass Apache .htaccess erlaubt

Öffne httpd-vhosts.conf und überprüfe, ob in deinem VirtualHost für wiki.aewi.de folgendes enthalten ist:

apache

KopierenBearbeiten

ServerName wiki.aewi.de

DocumentRoot "/Library/WebServer/Documents/mediawiki"

Options FollowSymLinks

AllowOverride All

Require all granted

</Directory>

SSLEngine on

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

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

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

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

</VirtualHost>

⚠️ Falls AllowOverride None gesetzt ist, ändere es zu AllowOverride All!

2️⃣ .htaccess für MediaWiki aktivieren

Falls die Datei .htaccess nicht existiert oder leer ist, erstelle sie mit folgendem Inhalt:

apache

KopierenBearbeiten

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^wiki/(.*)$ /mediawiki/index.php?title=$1 [L,QSA]

Speichere die Datei und setze die richtigen Berechtigungen:

sh

KopierenBearbeiten

sudo chmod 644 /Library/WebServer/Documents/mediawiki/.htaccess

sudo chown _www:_www /Library/WebServer/Documents/mediawiki/.htaccess

3️⃣ Apache-Modul mod_rewrite aktivieren

Falls mod_rewrite nicht aktiv ist, musst du es in Apache aktivieren:

sh

KopierenBearbeiten

sudo sed -i '' 's/#LoadModule rewrite_module/LoadModule rewrite_module/' /opt/homebrew/etc/httpd/httpd.conf

Danach Apache neustarten:

sh

KopierenBearbeiten

sudo brew services restart httpd

Überprüfe, ob mod_rewrite geladen ist:

sh

KopierenBearbeiten

apachectl -M | grep rewrite

Falls rewrite_module (shared) erscheint, ist es aktiv.

4️⃣ LocalSettings.php anpassen

In LocalSettings.php sollten die folgenden Einträge vorhanden sein:

php

KopierenBearbeiten

$wgScriptPath = "/mediawiki";

$wgArticlePath = "/wiki/$1";

$wgUsePathInfo = true;

Falls du nicht sicher bist, ob das Problem von MediaWiki kommt, teste die direkte URL:

https://de.wikipedia.org/w/index.php/Hauptseite

Falls das funktioniert, aber https://wiki.aewi.de/wiki/Hauptseite nicht, dann gibt es ein Problem mit .htaccess.

5️⃣ Apache-Logdateien prüfen

Falls es immer noch nicht geht, sieh dir die Logs an:

sh

KopierenBearbeiten

tail -f /opt/homebrew/var/log/httpd/wiki_error.log

Hier siehst du, warum Apache die Seite nicht findet.

📌 Fazit

Falls .htaccess nicht existiert, erstelle sie mit den Rewrite-Regeln.
AllowOverride All muss in httpd-vhosts.conf gesetzt sein.
Prüfe, ob mod_rewrite aktiviert ist.
Falls Short URLs (/wiki/Hauptseite) nicht funktionieren, teste zuerst die lange URL (/mediawiki/index.php/Hauptseite).

Teste das und sag mir, ob es funktioniert! 🚀

Nikolaos:

Zuvor war folgendes nicht enthalten:

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

Warum ist es jetzt enthalten?

Sophos:

Die beiden Zeilen:

apache

KopierenBearbeiten

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

haben eine wichtige Funktion beim URL-Rewriting für MediaWiki und verhindern, dass echte Dateien und Verzeichnisse von der Rewrite-Regel betroffen sind.

🔍 Warum sind diese Bedingungen wichtig?

Diese Bedingungen bedeuten:

RewriteCond %{REQUEST_FILENAME} !-f → Falls die angeforderte URL zu einer existierenden Datei gehört, wird sie nicht umgeschrieben.
RewriteCond %{REQUEST_FILENAME} !-d → Falls die angeforderte URL zu einem existierenden Verzeichnis gehört, wird sie nicht umgeschrieben.

Ohne diese Bedingungen könnte Apache auch Dateien und Verzeichnisse umleiten, die eigentlich direkt erreichbar sein sollten.

Das kann zu Problemen führen, wenn z. B. Bilder, CSS- oder JavaScript-Dateien von MediaWiki nicht mehr geladen werden.

🛠 Beispiel für das Problem ohne diese Zeilen

Ohne diese Zeilen:

Browser ruft /wiki/logo.png auf
Apache denkt, dass /wiki/logo.png eine Wiki-Seite ist und leitet zu /mediawiki/index.php?title=logo.pngum
Das Bild wird nicht geladen ❌

Mit diesen Zeilen:

Browser ruft /wiki/logo.png auf
Apache sieht, dass /wiki/logo.png eine existierende Datei ist
Apache lässt das Bild in Ruhe und es wird normal geladen ✅

📌 Fazit

Diese zwei Zeilen sind ein Best Practice für Rewrite-Regeln in Apache, um zu verhindern, dass echte Dateien und Verzeichnisse falsch umgeleitet werden.

👉 Falls dein MediaWiki ohne diese Zeilen einwandfrei funktioniert, kannst du es auch ohne testen. Aber normalerweise sind sie empfehlenswert. ✅

Möchtest du die Rewrite-Regeln noch weiter anpassen oder testen? 🚀

Nikolaos:

Ersteinmal den normalen Zugriff ermöglichen und dann auf kurze URL umstellen.

Was muß dafür eingestellt sein?

Sophos:

📌 MediaWiki – Normaler Zugriff ohne kurze URLs

Bevor du kurze URLs (Short URLs) einrichtest, sollten wir sicherstellen, dass dein MediaWiki normal erreichbar ist. Dafür müssen folgende Punkte stimmen:

1️⃣ Standard-URL für den Zugriff auf MediaWiki

Aktuell sollte dein Wiki unter folgender URL erreichbar sein:

👉 https://de.wikipedia.org/w/index.php/Hauptseite

Falls das nicht funktioniert, prüfen wir, ob LocalSettings.php und httpd-vhosts.conf korrekt konfiguriert sind.

2️⃣ LocalSettings.php anpassen

In LocalSettings.php sollten die Einstellungen für die Standard-URL so aussehen:

php

KopierenBearbeiten

$wgScriptPath = "/mediawiki"; // Standard-Pfad für MediaWiki

$wgScriptExtension = ".php"; // Standard-Erweiterung für MediaWiki-Skripte

$wgServer = "https://wiki.aewi.de"; // Domain des Wikis

$wgArticlePath = "$wgScriptPath/index.php/$1"; // Standard-Artikel-Pfad

$wgUsePathInfo = true; // Nutzung von "index.php/Artikelname"

Falls du MediaWiki in /Library/WebServer/Documents/mediawiki installiert hast, sollte $wgScriptPath auf diesen Ordner verweisen.

3️⃣ Apache VirtualHost für wiki.aewi.de

Dein httpd-vhosts.conf sollte folgende Konfiguration enthalten:

apache

KopierenBearbeiten

ServerAdmin webmaster@aewi.de

ServerName wiki.aewi.de

DocumentRoot "/Library/WebServer/Documents/mediawiki"

Options Indexes FollowSymLinks

AllowOverride All

Require all granted

</Directory>

SSLEngine on

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

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

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

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

</VirtualHost>

Falls dein MediaWiki in einem anderen Ordner liegt, ändere den Pfad von DocumentRoot und <Directory>entsprechend!

👉 DocumentRoot muss auf den MediaWiki-Ordner zeigen, nicht auf /Library/WebServer/Documents.

4️⃣ Apache HTTP-Server prüfen und neu starten

Apache-Konfiguration testen:

sh

KopierenBearbeiten

sudo apachectl configtest

Erwartete Antwort:

✅ Syntax OK

Apache neu starten:

sh

KopierenBearbeiten

sudo brew services restart httpd

5️⃣ MediaWiki-Datenbankverbindung prüfen

Falls nach diesen Änderungen noch Fehler 404 oder 500 auftreten, prüfe, ob MariaDB die Wiki-Datenbank erkennt.

sh

KopierenBearbeiten

mariadb -u root -p -e "SHOW DATABASES;"

Sollte mediawiki nicht aufgelistet sein, wurde die Datenbank nicht korrekt importiert.

📌 Ergebnis

✔ Nach diesen Änderungen sollte dein Wiki über

👉 https://de.wikipedia.org/w/index.php/Hauptseite

erreichbar sein.

📌 Sobald das funktioniert, können wir kurze URLs (Short URLs) einrichten. 🚀

Teste es und gib mir Bescheid, ob es funktioniert! 🔍✅

Nikolaos:

"$wgScriptExtension = ".php";" hatt ich noch nie eingestellt. Warum dies nun?

Sophos:

📌 $wgScriptExtension = ".php"; – Brauchst du das wirklich?

Nein, wenn du es bisher nicht verwendet hast, brauchst du es nicht zwingend. Es wird normalerweise nur verwendet, wenn du explizit sicherstellen willst, dass MediaWiki die .php-Endung für Skripte beibehält.

Wann wird $wgScriptExtension gebraucht?

✅ Falls deine URL so aussehen soll:

👉 https://de.wikipedia.org/w/index.php/Hauptseite

Dann brauchst du die Zeile nicht.

❌ Falls deine URL aber stattdessen so aussehen soll:

👉 https://de.wikipedia.org/w/index/Hauptseite.php

Dann wäre $wgScriptExtension = ".php"; nötig.

🔹 Fazit:

Da du bisher ohne diese Einstellung gearbeitet hast und du URLs mit /index.php/Hauptseite nutzt, kannst du es einfach weglassen. 🚀

Lass es uns so einfach wie möglich halten! 😃

Gibt es noch andere Probleme mit der Erreichbarkeit von MediaWiki? 🔍

Nikolaos:

Ich habe es auf ohne kurze URL umgestellt und erhalte folgenden Fehler:

[3f2b0de25b0da68b81d22475] /index.php FatalError: If you use a relative URL for $wgArticlePath, it must start with a slash (<code>/</code>).<br><br>See <a href="https://www.mediawiki.org/wiki/Manual:$wgArticlePath">https://www.mediawiki.org/wiki/Manual:$wgArticlePath</a>.

Backtrace:

from /Library/WebServer/Documents/mediawiki/includes/Request/PathRouter.php(184)

#0 /Library/WebServer/Documents/mediawiki/includes/Request/WebRequest.php(200): MediaWiki\Request\PathRouter->validateRoute(string, string)

#1 /Library/WebServer/Documents/mediawiki/includes/Request/WebRequest.php(398): MediaWiki\Request\WebRequest->getPathInfo(string)

#2 /Library/WebServer/Documents/mediawiki/includes/Setup.php(466): MediaWiki\Request\WebRequest->interpolateTitle()

#3 /Library/WebServer/Documents/mediawiki/includes/WebStart.php(85): require_once(string)

#4 /Library/WebServer/Documents/mediawiki/index.php(50): require(string)

#5 {main}

Was muß ich ändern?

Sophos:

Der Fehler deutet darauf hin, dass $wgArticlePath in deiner LocalSettings.php entweder nicht korrekt gesetzt istoder eine falsche Syntax hat.

🛠 Lösung: Stelle $wgArticlePath richtig ein

Öffne deine LocalSettings.php
Finde oder füge folgende Zeilen hinzu:

php

KopierenBearbeiten

$wgArticlePath = "/index.php/$1";

Prüfe $wgUsePathInfo Falls es in deiner LocalSettings.php fehlt, füge es hinzu:

php

KopierenBearbeiten

$wgUsePathInfo = true;

Speichern und testen: Rufe die Hauptseite mit https://wiki.aewi.de/index.php/Hauptseite auf.

Erklärung: Warum dieser Fehler?

Wenn $wgArticlePath gesetzt ist, erwartet MediaWiki eine relative URL, die mit / beginnt.
Falls $wgArticlePath leer ist oder nicht gesetzt wurde, versucht MediaWiki dennoch, es zu verwenden → Fehler.

🔎 Falls es danach nicht funktioniert:

📌 Debug-Check: Gib diesen Befehl im Terminal ein, um zu prüfen, ob die Datei noch vorhanden ist:

bash

KopierenBearbeiten

cat /Library/WebServer/Documents/mediawiki/LocalSettings.php | grep wgArticlePath

Falls dort nichts erscheint, wurde die Zeile nicht richtig gespeichert.

Probier es aus und sag mir, ob es nun funktioniert! 🚀😊

Nikolaos:

ich habe es geänder. Nun habe ich keine php Seite sondern es sieht aus wie html.

was muß ich ändern?

php muß integriert sein wenn phpmyadmin richtig anzeigt oder?

2/2

Sophos:

Ja, wenn deine MediaWiki-Seite wie reines HTML aussieht (ohne Styling oder ohne, dass PHP richtig verarbeitet wird), dann gibt es wahrscheinlich ein Problem mit der PHP-Integration in Apache. Da phpMyAdmin korrekt funktioniert, bedeutet das aber, dass PHP grundsätzlich läuft.

🛠 Schritte zur Fehlerbehebung:

1️⃣ Prüfe, ob Apache PHP richtig verarbeitet

Gib im Terminal folgenden Befehl ein:

bash

KopierenBearbeiten

php -v

Falls PHP funktioniert, sollte eine Ausgabe erscheinen wie:

PHP 8.2.x (cli) (built:...)

Falls du eine Fehlermeldung bekommst, ist PHP nicht korrekt installiert oder nicht aktiviert.

2️⃣ Prüfe, ob Apache PHP als Modul geladen hat

Führe folgenden Befehl aus:

bash

KopierenBearbeiten

sudo apachectl -M | grep php

Falls PHP korrekt geladen ist, sollte eine Zeile erscheinen wie:

bash

KopierenBearbeiten

php_module (shared)

Falls keine Ausgabe erscheint, bedeutet das, dass Apache PHP nicht verarbeitet.

➡ Lösung:

Öffne die Datei /opt/homebrew/etc/httpd/httpd.conf und prüfe, ob diese Zeile vorhanden und nicht auskommentiert (#) ist:

apache

KopierenBearbeiten

LoadModule php_module /opt/homebrew/opt/php/lib/httpd/modules/libphp.so

Falls sie fehlt oder auskommentiert ist, füge sie hinzu oder entferne das #, dann speichere und starte Apache neu:

bash

KopierenBearbeiten

sudo brew services restart httpd

3️⃣ Prüfe, ob index.php erlaubt ist

Öffne /opt/homebrew/etc/httpd/httpd.conf und prüfe diese Zeile:

apache

KopierenBearbeiten

DirectoryIndex index.html index.php

Falls index.php fehlt, füge es hinzu, dann speichere und Apache neu starten:

bash

KopierenBearbeiten

sudo brew services restart httpd

4️⃣ Teste, ob PHP überhaupt ausgeführt wird

Erstelle eine Datei phpinfo.php im MediaWiki-Verzeichnis: bash KopierenBearbeiten echo "<?php phpinfo(); ?>" | sudo tee /Library/WebServer/Documents/mediawiki/phpinfo.php
Rufe in deinem Browser auf: https://wiki.aewi.de/phpinfo.php

Falls du die PHP-Infoseite siehst, funktioniert PHP grundsätzlich. Falls nicht, liegt das Problem bei Apache.

5️⃣ Falls MediaWiki nur als HTML lädt

Falls MediaWiki kein CSS oder JavaScript lädt, könnte es sein, dass der load.php-Pfad falsch ist.

Setze in deiner LocalSettings.php:

php

KopierenBearbeiten

$wgScriptPath = "/mediawiki";

$wgResourceBasePath = "$wgScriptPath";

Dann Apache neu starten:

bash

KopierenBearbeiten

sudo brew services restart httpd

Probier die Schritte aus und sag mir, welche Ergebnisse du bekommst. 🚀🔥

Nikolaos:

Ich bin jetzt in MediaWiki.

Der Fehler lag an httpd-vhost.conf.

1. "<Directory "/Library/WebServer/Documents/mediawiki">" muß wenn "$wgScriptPath = "/mediawiki";" ist, dann auf "<Directory "/Library/WebServer/Documents">" stehen.

2. "DocumentRoot "/Library/WebServer/Documents/mediawiki" muß wenn "$wgScriptPath = "/mediawiki";" ist, dann auf "DocumentRoot "/Library/WebServer/Documents" stehen.

Trotz unserem Import der Daten ist die Datenbank leer.

Gib mir bitte den mariadb import Befehl für den import der mediawiki Datenbank, die bestehende Daten überschreibt.

Sophos:

Um die MediaWiki-Datenbank aus einer SQL-Datei zu importieren und bestehende Daten zu überschreiben, kannst du folgenden MariaDB-Befehl verwenden:

📌 Befehl für den Import mit Überschreiben der bestehenden Daten

bash

KopierenBearbeiten

mariadb -u root -p mediawiki < /Users/aewi/mediawiki.sql

🛠 Erklärungen:

mariadb -u root -p → Loggt dich als root in MariaDB ein.
mediawiki → Ziel-Datenbank, in die importiert wird.
</Users/aewi/mediawiki.sql → Gibt die Quelle der zu importierenden Daten an.
< → Leitet den Inhalt der SQL-Datei als Eingabe für MariaDB weiter.

⚠ Wichtige Hinweise:

Falls die Datenbank mediawiki noch nicht existiert, erstelle sie vorher mit: bash KopierenBearbeiten mariadb -u root -p -e "CREATE DATABASE IF NOT EXISTS mediawiki;"
Falls die bestehende Datenbank bereits Tabellen enthält und überschrieben werden soll, kannst du vorher alle Tabellen DROPPEN (LÖSCHEN) mit: bash KopierenBearbeiten mariadb -u root -p mediawiki -e "DROP DATABASE mediawiki; CREATE DATABASE mediawiki;"
Falls der Import scheitert, kann es an fehlenden Berechtigungen liegen. Stelle sicher, dass du als root-Benutzer arbeitest oder mit einem Benutzer, der Zugriff auf die mediawiki-Datenbank hat.
Prüfe nach dem Import, ob die Tabellen gefüllt sind: bash KopierenBearbeiten mariadb -u root -p -e "USE mediawiki; SHOW TABLES;"

🚀 So überprüfst du, ob der Import erfolgreich war:

Einloggen in MariaDB bash KopierenBearbeiten mariadb -u root -p
Datenbank auswählen sql KopierenBearbeiten USE mediawiki;
Anzeigen aller Tabellen sql KopierenBearbeiten SHOW TABLES;
Überprüfen, ob Seiten aus MediaWiki vorhanden sind sql KopierenBearbeiten SELECT * FROM page LIMIT 10;

🛠 Falls du nach dem Import Fehler bekommst:

"ERROR 1062 (23000): Duplicate entry" → Bedeutet, dass die Datenbank bereits Inhalte hat. → Lösung: DROP DATABASE vorher ausführen.
"ERROR 1046 (3D000): No database selected" → Lösung: Führe USE mediawiki; aus, bevor du SHOW TABLES; verwendest.

📌 Alternative: Datenbank-Import mit mysql statt mariadb

Falls mariadb nicht funktioniert, kannst du auch mysql nutzen:

bash

KopierenBearbeiten

mysql -u root -p mediawiki < /Users/aewi/mediawiki.sql

Da MariaDB ein Drop-in-Replacement für MySQL ist, sollte das ebenfalls klappen.

🔹 Teste den Import und prüfe danach, ob die Seiten wieder da sind! 🚀🔥

Nikolaos:

1. Ich habe die Datenbank importiert und "php maintenance/run.php update" ausgeführt.

2. php maintenance/run.php update

MediaWiki 1.43.0 Updater

Your composer.lock file is up to date with current dependencies!

Going to run database updates for mediawiki

Depending on the size of your database this may take a while!

Abort with control-c in the next five seconds (skip this countdown with --quick) ...0

Can not upgrade from versions older than 1.35, please upgrade to that version or later first.

Der importierte dump.sql stammt von mysql 5.7 und MediaWiki 1.43.

3. Ich erhalte in MEdiaWIki folgende Fehlermeldung:

Original exception: [b3f72d616d6e1054a3ce009e] /mediawiki/index.php? Wikimedia\Rdbms\DBQueryError: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading or after adding a new extension?

Please see https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Upgrading and https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:How_to_debug for more information.

Error 1146: Table 'mediawiki.user' doesn't exist

Function: MediaWiki\User\User::loadFromDatabase

Query: SELECT user_id,user_name,user_real_name,user_email,user_touched,user_token,user_email_authenticated,user_email_token,user_email_token_expires,user_registration,user_editcount,user_actor.actor_id FROM `user` JOIN `actor` `user_actor` ON ((user_actor.actor_user = user_id)) WHERE user_id = 1 LIMIT 1

User Tabelle ist offenbar nicht zugänglich oder hat keinen Inhalt?

Ich kann auch nicht auf die mediaWiki Settings Seite gelangen. das Datenbank Schema muß an sich ein Update durchlaufen, damit die neue Datenbank übereinstimmend ist.

Also es ist ein mysql dump von Wikimedia 1.43.x und mySQL 5.7.x, also die richtige Version, die kein Update von 1.35 auf 1.43 braucht!

Ich hatte dieses dump bereits zuvor erfolgreich in meinem alten Wikimedia Server importiert. Dies ging also!

Was jetzt anders ist, ist dass wir eine mysql Datenbank in MariaDB importieren!

Ich habe mit phpmyadmin nachgeschaut und die user Tabelle ist da und enthält angelegte user!

Das Schema von MariaDB könnte anders sein und muß ein update erhalten.

6/6

Sophos:

Das Problem liegt wahrscheinlich an Unterschieden im Datenbankschema zwischen MySQL 5.7 und MariaDB 10.5sowie unvollständigen Verweisen nach dem Import.

Da die User-Tabelle vorhanden ist, aber MediaWiki sie nicht erkennt, könnte es an fehlenden Indexen, Primärschlüsseln oder utf8mb4-Einstellungen liegen.

🔹 1. Prüfen, ob die Tabelle user existiert und korrekt ist

Führe in MariaDB folgende Abfragen aus:

sql

KopierenBearbeiten

USE mediawiki;

SHOW TABLES LIKE 'user';

DESCRIBE user;

SELECT * FROM user LIMIT 5;

Falls SHOW TABLES LIKE 'user'; keine Ergebnisse liefert, wurde die Tabelle nicht korrekt importiert.
Falls DESCRIBE user; fehlschlägt, gibt es ein Problem mit den Spalten.
Falls SELECT * FROM user; keine Daten liefert, sind die User nicht vorhanden.

🔹 2. Indexe & Primärschlüssel reparieren

MariaDB kann mit manchen Indexen aus MySQL 5.7 Probleme haben. Probiere daher:

sql

KopierenBearbeiten

USE mediawiki;

ALTER TABLE user ENGINE=InnoDB;

REPAIR TABLE user;

ANALYZE TABLE user;

OPTIMIZE TABLE user;

Falls InnoDB nicht funktioniert, probiere ENGINE=Aria;.

🔹 3. Fehlende Tabellen nach dem Import erstellen

Falls maintenance/run.php update nicht läuft, kann es helfen, manuell fehlende Tabellen zu erzeugen:

sql

KopierenBearbeiten

USE mediawiki;

CREATE TABLE IF NOT EXISTS user (

user_id INT(10) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,

user_name VARCHAR(255) NOT NULL,

user_real_name VARCHAR(255) DEFAULT NULL,

user_email VARCHAR(255) DEFAULT NULL,

user_password VARCHAR(255) DEFAULT NULL,

user_token VARCHAR(255) DEFAULT NULL,

user_touched VARCHAR(14) NOT NULL DEFAULT '',

user_registration VARCHAR(14) DEFAULT NULL,

user_editcount INT(11) DEFAULT NULL,

user_email_authenticated DATETIME DEFAULT NULL,

user_email_token VARCHAR(255) DEFAULT NULL,

user_email_token_expires DATETIME DEFAULT NULL

);

🔹 4. actor-Tabelle prüfen & reparieren

Die Fehlermeldung enthält auch actor, also prüfen wir sie:

sql

KopierenBearbeiten

USE mediawiki;

SHOW TABLES LIKE 'actor';

DESCRIBE actor;

SELECT * FROM actor LIMIT 5;

Falls sie fehlt:

sql

KopierenBearbeiten

CREATE TABLE IF NOT EXISTS actor (

actor_id INT(10) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,

actor_user INT(10) UNSIGNED DEFAULT NULL,

actor_name VARCHAR(255) NOT NULL

);

🔹 5. utf8mb4-Probleme beheben

MySQL 5.7 nutzt utf8mb4-Encoding, aber MariaDB kann manchmal utf8 nach dem Import setzen:

sql

KopierenBearbeiten

ALTER DATABASE mediawiki CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

ALTER TABLE user CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

ALTER TABLE actor CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

🔹 6. maintenance/run.php erneut ausführen

Falls die Tabellen jetzt korrekt sind:

bash

KopierenBearbeiten

php maintenance/run.php update --quick

Falls es wieder an der Version 1.35 liegt, könntest du es mit --skip-external-dependencies versuchen:

bash

KopierenBearbeiten

php maintenance/run.php update --skip-external-dependencies

🚀 Teste jetzt, ob MediaWiki funktioniert!

Falls noch Fehler bestehen, lass mich wissen, welche Tabellen in phpMyAdmin fehlen oder leer sind.

Nikolaos:

Ich habe dir gesagt, daß die user Tabellen alle da sind und du tust so, als würde ich dir dies nicht gesagt haben und gibst mir lauter unnötige Anweisungen!

Sophos:

Da die User-Tabelle vorhanden ist, aber MediaWiki sie nicht erkennt, müssen wir uns auf mögliche Inkompatibilitäten zwischen MySQL 5.7 und MariaDB 10.5 konzentrieren.

Da maintenance/run.php update wegen der Version 1.35 fehlschlägt, versuchen wir eine alternative Aktualisierung:

🔹 1. MediaWiki-Update mit --skip-external-dependencies erzwingen

Falls einige Extensions oder Module fehlen, kann ein erzwungenes Update helfen:

bash

KopierenBearbeiten

php maintenance/run.php update --skip-external-dependencies

Falls das nicht funktioniert, probiere:

bash

KopierenBearbeiten

php maintenance/run.php update --quick

🔹 2. MediaWiki erkennt die Tabelle nicht – mögliche Ursachen

Da du sagst, dass die user-Tabelle existiert, aber MediaWiki sie nicht findet, prüfen wir:

A) Ist MediaWiki mit der richtigen Datenbank verbunden?

Teste direkt in PHP mit:

php

KopierenBearbeiten

<?php

$mysqli = new mysqli("127.0.0.1", "root", "44%%55Aufeinwort", "mediawiki");

if ($mysqli->connect_error) {

die("Verbindung fehlgeschlagen: " . $mysqli->connect_error);

}

echo "Verbindung erfolgreich!";

?>

Speichere es als test_db.php und rufe https://wiki.aewi.de/test_db.php auf.

Falls kein Fehler kommt, ist die Verbindung richtig. Falls doch, müssen wir die LocalSettings.php korrigieren.

B) Hat MediaWiki die user-Tabelle aus der richtigen Datenbank?

Führe in mariadb aus:

sql

KopierenBearbeiten

USE mediawiki;

SHOW TABLES;

SELECT COUNT(*) FROM user;

Falls SHOW TABLES; die user-Tabelle nicht anzeigt, ist der Import schiefgelaufen.
Falls SELECT COUNT(*) FROM user; 0 zurückgibt, fehlen die Benutzer.
Falls die Tabelle da ist und Benutzer hat, aber MediaWiki sie nicht findet, gibt es ein Problem mit der Datenbankverbindung oder Tabellenpräfixen.

C) Wurde wgDBprefix in LocalSettings.php gesetzt?

Falls die user-Tabelle eigentlich mw_user oder wiki_user heißt, muss LocalSettings.php angepasst werden:

Suche in LocalSettings.php:

php

KopierenBearbeiten

$wgDBprefix = "";

Falls du z. B. mw_ als Präfix hast, setze:

php

KopierenBearbeiten

$wgDBprefix = "mw_";

Falls kein Präfix existiert, lösche diese Zeile!

🔹 3. Teste nun den Login

Falls du den MediaWiki-Login testen willst, kannst du auch direkt einen neuen Admin anlegen:

bash

KopierenBearbeiten

php maintenance/createAndPromote.php --force --sysop --bureaucrat "AdminUser" "NeuesPasswort"

Das legt einen neuen Benutzer mit Admin-Rechten an.

🔹 4. Prüfe die Fehlerlogs von MediaWiki

Falls immer noch Fehler auftreten, schalte das Debugging in LocalSettings.php an:

php

KopierenBearbeiten

$wgShowExceptionDetails = true;

$wgShowSQLErrors = true;

$wgDebugDumpSql = true;

$wgLogQueries = true;

$wgDebugLogFile = "/var/log/mediawiki_debug.log";

Starte Apache neu und schau, was in /var/log/mediawiki_debug.log steht.

Fazit

Da die user-Tabelle vorhanden ist, aber nicht erkannt wird:

✅ Stelle sicher, dass MediaWiki mit der richtigen Datenbank verbunden ist

✅ Prüfe, ob wgDBprefix in LocalSettings.php richtig gesetzt ist

✅ Starte das Update-Skript mit --skip-external-dependencies

✅ Falls nichts hilft, lege einen neuen Benutzer mit createAndPromote.php an

Falls noch Probleme bestehen, sag mir genau, welche dieser Schritte fehlschlägt. 🚀

Nikolaos:

Ich erinnerte mich, daß ein Präfix auf "$wgDBprefix = "wiki_";" gesetzt war und ich habe das in LocalSettings.php geändert und nun kann ich auf alles zugreifen.

Das MediaWiki ist nun von meinem M1 und M2 im LAN erreichbar.

Ich bin über WLAN mit meinem iPhone im gleichen Netzwerk und kann die Hauptseite des MediaWiki nicht erreichen.

Muß dazu noch etwas in der Fritz!Box umgestellt werden, damit WLA auch den DNS Server vom M1 nutzt, oder muß in dnsmasq noch WLAN besonders behandelt werden?

Sophos:

Ja, damit dein iPhone über WLAN im gleichen Netzwerk auf das MediaWiki zugreifen kann, muss das DNS-Setupin der Fritz!Box angepasst werden, damit dnsmasq auf dem M1 als bevorzugter DNS-Server genutzt wird.

🔹 1. Prüfe, ob dein iPhone den richtigen DNS-Server nutzt

Bevor du etwas änderst, teste zuerst auf dem iPhone:

Öffne die WLAN-Einstellungen
Tippe auf das verbundene WLAN-Netzwerk
Scrolle runter und prüfe den Eintrag "DNS-Server"

Falls dort die IP-Adresse der Fritz!Box (meist 192.168.178.1) steht, dann leitet dein iPhone DNS-Anfragen an die Fritz!Box und nicht an den M1.

🔹 2. M1 als DNS-Server in der Fritz!Box eintragen

Falls dein iPhone die Fritz!Box als DNS-Server nutzt, dann leite alle DNS-Anfragen von der Fritz!Box an dnsmasq auf dem M1 weiter.

Änderung in der Fritz!Box:

Öffne die Fritz!Box: 👉 http://fritz.box
Gehe zu: ➝ Internet → Zugangsdaten → DNS-Server
Setze dort den primären DNS auf die IP des M1
- Falls dein M1 z. B. die IP 192.168.2.3 hat, dann setze: arduino KopierenBearbeiten Primärer DNS-Server: 192.168.2.3
- Sekundärer DNS-Server: 8.8.8.8 (Google DNS oder 1.1.1.1 von Cloudflare)

Übernehme die Einstellungen & starte die Fritz!Box neu

❗ Wichtig: Falls du die DNS-Einstellungen manuell in der Fritz!Box änderst, betrifft das alle Geräte im Netzwerk. Falls etwas nicht funktioniert, kannst du es jederzeit rückgängig machen.

🔹 3. Alternativ: DNS manuell auf dem iPhone setzen

Falls du die Fritz!Box nicht ändern willst, kannst du auf dem iPhone den DNS manuell setzen:

WLAN-Einstellungen öffnen
Auf das verbundene Netzwerk tippen
Auf "DNS konfigurieren" tippen
Von "Automatisch" auf "Manuell" umstellen
DNS-Server des M1 eintragen cpp KopierenBearbeiten 192.168.2.3
8.8.8.8 (optional als zweiter DNS)
Speichern & testen

Jetzt sollte dein iPhone direkt dnsmasq vom M1 nutzen.

🔹 4. Falls es immer noch nicht geht – Prüfe dnsmasq

Falls du dnsmasq auf dem M1 nutzt, stelle sicher, dass es auf alle Interfaces lauscht, damit auch WLAN-Geräte Anfragen stellen können.

🔹 Checke die dnsmasq.conf:

Öffne sie mit:

bash

KopierenBearbeiten

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

Stelle sicher, dass folgende Zeile enthalten ist:

ini

KopierenBearbeiten

listen-address=127.0.0.1,192.168.2.3

Falls du IPv6 im Netzwerk nutzt, kannst du noch hinzufügen:

ini

KopierenBearbeiten

listen-address=::1,192.168.2.3

Dann dnsmasq neu starten:

bash

KopierenBearbeiten

sudo brew services restart dnsmasq

🔹 5. Teste den Zugriff vom iPhone

Jetzt kannst du testen, ob dein iPhone die richtige DNS-Auflösung hat.

Öffne die Kurzbefehle-App
Erstelle eine neue Shell-Kurzbefehlsaktion
Füge den folgenden Befehl ein: bash KopierenBearbeiten nslookup wiki.aewi.de
Führe den Kurzbefehl aus.

Falls 192.168.2.3 zurückgegeben wird, funktioniert der DNS-Server.

Falls es immer noch nicht geht, versuche dein iPhone kurz im Flugmodus zu setzen und dann wieder ins WLAN zu wechseln.

🔹 Fazit

✅ Falls dein iPhone die Fritz!Box als DNS nutzt, leite DNS-Anfragen an den M1 weiter

✅ Falls du nur das iPhone ändern willst, setze manuell 192.168.2.3 als DNS

✅ Falls es immer noch nicht geht, prüfe, ob dnsmasq richtig konfiguriert ist

Teste das und sag mir, ob es klappt! 🚀

Nikolaos:

Ich mußte mnur die Webseitendaten von aewi.de auf meinem iPhone in Safari löschen.

Jetzt geht auch der Zugriff auf MediaWiki von Geräten im WLAN..

VPN über iPhone war offenbar auch davon betroffen. Ich kann nun auch über LTE G5 auf MediaWiki mittels wireguard VPN

Sophos:

Perfekt! 🎉 Dass der Safari-Cache das Problem war, ist ein klassisches Beispiel für lokale DNS-/Caching-Probleme, die sich auf den Zugriff auswirken können.

Nun funktioniert:

✅ MediaWiki über WLAN

✅ MediaWiki über WireGuard VPN (LTE/G5)

✅ phpMyAdmin über die korrekte Subdomain

✅ Homebrew-Dienste korrekt gestartet

✅ MariaDB mit den richtigen Konfigurationen

Das System ist jetzt also genau so, wie du es brauchst. 🚀

Falls später noch Probleme auftreten (z. B. Zugriffe nicht funktionieren), lohnt es sich immer:

Browser-Cache zu leeren
nslookup oder dig zu testen
ping oder traceroute auf die Subdomains auszuführen

Super Arbeit – dein Setup ist jetzt optimal! 🎯💪

Nikolaos:

Noch nicht ganz. Wir installieren gleich in einem weiteren Chat ElasticSearch und weitere Erweiterungen in MediaWiki.

Weiß du, was ich in LocalSettings.php eingeben muß, damit ich E-Mails aus MediaWiki heraus versenden kann. Gibt mir bitte die Einstellungen.

Sophos:

Ja, um E-Mails aus MediaWiki zu versenden, musst du in der LocalSettings.php einige Parameter setzen. Hier sind die grundlegenden Einstellungen für den E-Mail-Versand:

1️⃣ Allgemeine Einstellungen für E-Mail-Versand

Füge diese Zeilen in deine LocalSettings.php ein:

php

KopierenBearbeiten

$wgEnableEmail = true;

$wgEnableUserEmail = true; # Ermöglicht das Versenden von E-Mails zwischen Benutzern

$wgEmergencyContact = "admin@aewi.de"; # E-Mail-Adresse für Notfallkontakte

$wgPasswordSender = "no-reply@aewi.de"; # Absenderadresse für automatisch gesendete E-Mails

$wgEnotifUserTalk = true; # E-Mail-Benachrichtigung für Benutzer-Diskussionsseiten

$wgEnotifWatchlist = true; # E-Mail-Benachrichtigung für beobachtete Seiten

$wgEmailAuthentication = true; # Benutzer müssen ihre E-Mail bestätigen

# Falls du ein SMTP-Relay nutzen möchtest:

$wgSMTP = [

'host' => "smtp.aewi.de", # Dein SMTP-Server

'IDHost' => "aewi.de", # Deine Domain

'port' => 587, # SMTP-Port (465 für SSL, 587 für TLS)

'auth' => true, # Authentifizierung aktivieren

'username' => "noreply@aewi.de", # Dein SMTP-Benutzername

'password' => "DEIN_SICHERES_PASSWORT", # Dein SMTP-Passwort

'secure' => "tls" # "tls" oder "ssl", je nach Server

];

2️⃣ SMTP-Alternative: System-Mailer verwenden (Sendmail, Postfix, Exim)

Falls dein Server einen Mailserver wie Postfix oder Exim4 nutzt, kannst du MediaWiki stattdessen den lokalen Mail-Transport nutzen lassen:

php

KopierenBearbeiten

unset( $wgSMTP ); # Deaktiviert SMTP und nutzt das System

💡 Hinweis: Falls dein Mailserver nicht richtig konfiguriert ist, kann dies dazu führen, dass E-Mails als Spam eingestuft oder blockiert werden.

3️⃣ Testen des E-Mail-Versands

Du kannst prüfen, ob MediaWiki E-Mails versenden kann, indem du als angemeldeter Benutzer:

Auf „E-Mail an diesen Benutzer senden“ gehst (Benutzer-Profil)
Ein Passwort zurücksetzt
php maintenance/showJobs.php ausführst – falls E-Mails in der Warteschlange hängen.

Falls es nicht funktioniert:

Prüfe die Mailserver-Logs (/var/log/mail.log oder /var/log/exim4/mainlog)
Teste mail() in PHP: php KopierenBearbeiten <?php
mail('test@aewi.de', 'Test-Mail', 'Dies ist ein Test!');
?>

Damit sollten E-Mails aus MediaWiki heraus funktionieren! 🚀

Nikolaos:

Derzeit nutze ich 1und1, meine email ist Klaus.feldmann@online.de

Wenn ich doch jetzt eine eigene Domain habe, könnte ich ja meine eigenen E-Mails auf aewi.de verwenden.

Würde ich dies auf Selfhost oder auf meinem M1 einrichten?

Sophos:

Ja, du hast jetzt zwei Möglichkeiten:

Einen eigenen Mailserver auf deinem M1 einrichten
Einen externen Anbieter (Selfhost, Posteo, Mailbox.org, IONOS etc.) nutzen

Ich erkläre dir beide Varianten mit den jeweiligen Vor- und Nachteilen:

1️⃣ Eigenen Mailserver auf deinem M1 einrichten (Postfix & Dovecot)

Wenn du vollständige Kontrolle über deine E-Mails möchtest, kannst du auf deinem M1-Server einen eigenen Mailserver einrichten. Dies bedeutet:

✅ Vorteile:

Absolute Kontrolle über deine E-Mails
Keine Abhängigkeit von Dritten
Eigene E-Mail-Adressen @aewi.de für unbegrenzt viele Benutzer
Keine monatlichen Kosten

❌ Nachteile:

Komplexe Einrichtung (Mailserver + DNS + SPF, DKIM, DMARC)
Hohe Wartung (Spam-Schutz, Backups, Updates)
Mögliche Blacklist-Probleme (große Provider blockieren eigene Mailserver)

Notwendige Dienste:

Postfix (SMTP-Server für den E-Mail-Versand)
Dovecot (IMAP/POP3-Server für den E-Mail-Empfang)
SpamAssassin + ClamAV (Anti-Spam & Anti-Virus)
Let’s Encrypt SSL/TLS für sichere Verbindungen

Für einen Mailserver auf dem M1 müsstest du DNS-Einstellungen wie MX, SPF, DKIM und DMARC setzen.

2️⃣ Externen Anbieter wie Selfhost, Mailbox.org oder IONOS nutzen

Wenn du weniger Aufwand möchtest, kannst du einen externen E-Mail-Hoster nutzen, der dir Postfächer für @aewi.debereitstellt.

✅ Vorteile:

Einfach und schnell eingerichtet
Keine Wartung nötig
Hohe Verfügbarkeit, kein Risiko von Blacklistings
Spam-Filter & Backups vom Anbieter

❌ Nachteile:

Monatliche Kosten (1-5€ pro Postfach)
Keine vollständige Kontrolle

Empfohlene Anbieter für eigene Domains:

Selfhost.de → Günstige Mail-Postfächer für eigene Domains
Mailbox.org → Datenschutzfreundlich, sehr gute Features
IONOS (1&1) → Direkte Weiterverwendung deiner Domain bei IONOS

Falls du bereits 1&1 (IONOS) nutzt, kannst du dort einfach ein E-Mail-Postfach für @aewi.de einrichten, ohne einen neuen Anbieter zu wählen.

📌 Empfehlung für dich

Da du bereits mit Selfhost arbeitest und deine Domain aewi.de besitzt, empfehle ich:

➡ E-Mail-Hosting bei Selfhost oder IONOS zu aktivieren

➡ Postfix auf dem M1 nur als SMTP-Relay zu nutzen (um Mails aus MediaWiki zu senden)

Falls du den Mailserver selbst hosten willst, können wir das natürlich einrichten – ist aber aufwendiger! 😊

Nikolaos:

Ich habe meine Email von 1und1 für MediaWiki eingerichtet. jetzt ist die Frage, wie ich dies in MediaWIki testen kann, ob MediaWiki E-Mails versendet?

2/2

Sophos:

Du kannst testen, ob MediaWiki erfolgreich E-Mails versenden kann, indem du folgende Methoden ausprobierst:

1️⃣ Passwort-Zurücksetzen-Funktion testen (einfachste Methode)

MediaWiki verschickt automatisch E-Mails, wenn du dein Passwort zurücksetzen möchtest.

So testest du den E-Mail-Versand:

Öffne dein Wiki und logge dich aus.
Gehe zu: https://wiki.aewi.de/index.php?title=Spezial:Passwort_vergessen
Gib deinen Benutzernamen oder deine E-Mail-Adresse ein.
Falls der Mailversand funktioniert, solltest du eine E-Mail erhalten.
Falls keine E-Mail ankommt: Gibt es eine Fehlermeldung oder kommt sie im Spam-Ordner an?

2️⃣ Spezialseite "E-Mail an Benutzer" testen

Falls die Passwort-Zurücksetzung funktioniert, kannst du auch die eingebaute Funktion für Benachrichtigungen testen:

Gehe auf Spezial:Emailuser https://wiki.aewi.de/index.php?title=Spezial:E-Mail_versenden
Wähle einen Benutzer mit einer E-Mail-Adresse.
Sende eine Testnachricht.
Falls der Benutzer die E-Mail erhält, funktioniert MediaWikis E-Mail-System.

3️⃣ Manuell per PHP testen

Falls die oberen Tests fehlschlagen, kannst du prüfen, ob PHP überhaupt E-Mails versenden kann.

Erstelle eine Datei testmail.php in deinem Webserver-Verzeichnis (/Library/WebServer/Documents/ oder /opt/homebrew/var/www/).
Füge folgenden Code ein:

php

KopierenBearbeiten

<?php

$to = "deine-email@aewi.de";

$subject = "MediaWiki E-Mail Test";

$message = "Dies ist eine Test-E-Mail von MediaWiki.";

$headers = "From: wiki@aewi.de\r\n";

if (mail($to, $subject, $message, $headers)) {

echo "E-Mail wurde erfolgreich gesendet.";

} else {

echo "E-Mail konnte nicht gesendet werden.";

}

?>

Rufe die Datei in deinem Browser auf: https://wiki.aewi.de/testmail.php
Falls die Nachricht gesendet wird, liegt das Problem in MediaWiki.

4️⃣ Log-Dateien prüfen

Falls keine E-Mails ankommen, prüfe die Log-Dateien von MediaWiki:

MediaWiki Fehlerlog (falls aktiviert): bash KopierenBearbeiten tail -n 50 /var/log/mediawiki.log
Mailserver-Log (Postfix, falls lokal genutzt): bash KopierenBearbeiten tail -n 50 /var/log/mail.log

Falls MediaWiki eine Fehlermeldung ausgibt oder Logs vorhanden sind, kann man den Fehler weiter eingrenzen.

Falls keine E-Mail ankommt, müssen wir prüfen, ob:

Die richtige SMTP-Konfiguration in LocalSettings.php steht.
PHP mail() funktioniert (Testmail oben).
Deine 1&1 Mailserver die E-Mails blockieren (SPF/DKIM-Fehler?).

Teste das mal und sag mir, was passiert! 😊

Nikolaos:

Hat MediaWiki einen eigenen MailServer integriert. Ich verstehe nicht wie das funktioniert, wenn auf dem M1 und MediaWiki kein MailServer installiert ist. Erkläre es mir bitte.

Sophos:

MediaWiki hat keinen eigenen Mailserver, sondern nutzt externe Mailserver, um E-Mails zu versenden. Die E-Mails werden entweder über die PHP mail()-Funktion oder über einen SMTP-Server versendet.

🔹 Wie funktioniert der E-Mail-Versand in MediaWiki?

MediaWiki kann auf zwei Arten E-Mails versenden:

1️⃣ PHP mail()-Funktion (Standard)

PHP enthält die Funktion mail(), die mit dem auf dem Betriebssystem installierten Mailserver zusammenarbeitet.
macOS hat normalerweise Postfix als Mailserver installiert.
MediaWiki ruft mail() auf, Postfix versendet die E-Mail.
Problem: Wenn kein Mailserver auf dem M1 läuft oder falsch konfiguriert ist, funktioniert das nicht.

📌 Lösung: Falls kein Mailserver installiert ist, musst du entweder einen installieren (Postfix) oder SMTP benutzen.

2️⃣ SMTP-Server (Empfohlen)

Anstatt einen lokalen Mailserver zu nutzen, kann MediaWiki über einen externen Mailserver E-Mails verschicken (z. B. 1und1, Google, Mailgun).
Du gibst in LocalSettings.php deine SMTP-Zugangsdaten an.
MediaWiki verbindet sich dann mit dem Mailserver von 1und1 und sendet die E-Mails über diesen Server.

📌 Vorteil: Kein lokaler Mailserver erforderlich, funktioniert sofort!

🔹 SMTP in MediaWiki einrichten (Empfohlen)

Da du eine E-Mail-Adresse von 1und1 hast (klaus.feldmann@online.de), kannst du MediaWiki so konfigurieren, dass es die E-Mails über den 1und1 SMTP-Server sendet.

Füge folgende Zeilen in LocalSettings.php ein:

php

KopierenBearbeiten

$wgEnableEmail = true;

$wgEnableUserEmail = true;

$wgEmergencyContact = "klaus.feldmann@online.de";

$wgPasswordSender = "klaus.feldmann@online.de";

$wgSMTP = [

'host' => 'smtp.1und1.de', # SMTP-Server von 1und1

'IDHost' => 'online.de', # Domain

'port' => 587, # Port 587 für TLS (Alternativ: 465 für SSL)

'username' => 'klaus.feldmann@online.de', # Dein 1und1-Login

'password' => 'DEIN_PASSWORT', # Dein Passwort für 1und1

'auth' => true, # Authentifizierung aktivieren

'secure' => 'tls' # 'tls' für TLS, 'ssl' für SSL

];

⚠️ WICHTIG:

Ersetze DEIN_PASSWORT mit deinem echten Passwort (oder benutze einen App-Spezifischen Key von 1und1, falls verfügbar).
Falls TLS nicht funktioniert, probiere secure => 'ssl' und port => 465.

🔹 Wie teste ich, ob E-Mail funktioniert?

Nachdem du die LocalSettings.php geändert hast, kannst du testen, ob E-Mail funktioniert:

1️⃣ Passwort-Zurücksetzen-Funktion testen

Gehe zu: https://wiki.aewi.de/index.php?title=Spezial:Passwort_vergessen
Gib deine E-Mail-Adresse ein.
Falls alles funktioniert, solltest du eine E-Mail erhalten.

2️⃣ Spezialseite "E-Mail an Benutzer" testen

Gehe zu: https://wiki.aewi.de/index.php?title=Spezial:E-Mail_versenden
Wähle einen Benutzer mit einer hinterlegten E-Mail.
Sende eine Testnachricht.

🔹 Alternative: Lokalen Mailserver einrichten (Postfix)

Falls du keinen externen SMTP-Server nutzen willst, kannst du auf deinem M1 einen Mailserver (Postfix) einrichten.

Dies ist komplizierter, weil du:

Postfix konfigurieren musst.
SPF/DKIM/DMARC für deine Domain setzen musst.
Wahrscheinlich von vielen E-Mail-Anbietern blockiert wirst.

Daher empfehle ich SMTP mit 1und1, weil es schneller, einfacher und sicherer ist.

🚀 Fazit

Beste Lösung: SMTP mit 1und1 in LocalSettings.php einrichten.
Test: Spezialseite Spezial:Passwort_vergessen oder Spezial:E-Mail_versenden.
Kein eigener Mailserver nötig, da MediaWiki SMTP nutzen kann.

Falls du weitere Fragen hast, sag Bescheid! 😊

Nikolaos:

E-Mail an Benutzer und Passwort zurücksetzen kann ich erst benutzen, wenn meine E-Mail Adresse beim MediaWiki bestätigt ist.

Ich habe Email in MediaWiki mit meinem 1und1 account eingestellt und eine Email aus MediaWiki zur Bestätigung meiner E-MAil Adresse abgesendet. Ich habe jedoch keine bekommen.

Muß im M1 Sever oder dnsmasq noch etwas eingerichtet werden, damit E-MAils versendet werden können. Müssen eventuell Ports bei M1 und oder Fritz!Box freigegeben werden?

Sophos:

Wenn du keine E-Mail von MediaWiki bekommst, kann das mehrere Ursachen haben. Lass uns die möglichen Fehlerquellen systematisch durchgehen.

🔍 1. Überprüfung der MediaWiki SMTP-Einstellungen

Bitte öffne LocalSettings.php und überprüfe, ob die SMTP-Einstellungen korrekt sind:

php

KopierenBearbeiten

$wgEnableEmail = true;

$wgEnableUserEmail = true;

$wgEmergencyContact = "klaus.feldmann@online.de";

$wgPasswordSender = "klaus.feldmann@online.de";

$wgSMTP = [

'host' => 'smtp.1und1.de', # 1&1 SMTP-Server

'IDHost' => 'online.de', # Domain

'port' => 587, # TLS (Alternativ: 465 für SSL)

'username' => 'klaus.feldmann@online.de', # Dein 1&1-Login

'password' => 'DEIN_PASSWORT', # Dein Passwort für 1&1

'auth' => true,

'secure' => 'tls' # 'tls' oder 'ssl'

];

Falls TLS nicht funktioniert, versuche secure => 'ssl' und port => 465.

➡️ Falls hier ein Fehler ist, werden E-Mails nicht gesendet!

🔍 2. Teste den E-Mail-Versand direkt über PHP

Um zu testen, ob PHP generell E-Mails über 1und1 versenden kann, erstelle eine Datei testmail.php im Webserver-Ordner /Library/WebServer/Documents/ mit folgendem Inhalt:

php

KopierenBearbeiten

<?php

$to = "DEINE_EMAIL@online.de";

$subject = "Test-Mail von MediaWiki";

$message = "Wenn du diese Nachricht erhältst, funktioniert der SMTP-Versand.";

$headers = "From: klaus.feldmann@online.de" . "\r\n" .

"Reply-To: klaus.feldmann@online.de" . "\r\n" .

"X-Mailer: PHP/" . phpversion();

$mail_sent = mail($to, $subject, $message, $headers);

if ($mail_sent) {

echo "E-Mail wurde gesendet!";

} else {

echo "E-Mail konnte nicht gesendet werden.";

}

?>

Dann rufe im Browser auf:

🔗 https://aewi.de/testmail.php

📌 Falls hier ein Fehler kommt, liegt es an der PHP-Mail-Funktion oder der Firewall.

🔍 3. MediaWiki-Fehlerlog überprüfen

MediaWiki speichert Fehler manchmal in einem Log. Führe im Terminal aus:

bash

KopierenBearbeiten

tail -n 50 /opt/homebrew/var/log/httpd/aewi_error.log

Falls dort ein Fehler steht wie Could not authenticate, dann gibt es ein Problem mit den SMTP-Einstellungen oder dem Passwort.

🔍 4. Überprüfe, ob Ports blockiert sind (Firewall & Fritz!Box)

Da dein M1-Server hinter einer Fritz!Box läuft, könnte die Firewall bestimmte Ports blockieren.

🔥 1. M1-Firewall prüfen

Öffne das Terminal und gib ein:

bash

KopierenBearbeiten

sudo pfctl -sr | grep 587

Falls keine Ausgabe kommt, könnte die Firewall Port 587 blockieren.

Lösung: Erlaube den Ausgangs-Traffic über Port 587:

bash

KopierenBearbeiten

sudo pfctl -F all

🔥 2. Fritz!Box: Portfreigabe prüfen

Gehe ins Fritz!Box-Menü: http://fritz.box
Internet > Filter > Listen > Gesperrte Ports → Stelle sicher, dass Port 587 oder 465 nicht gesperrt sind.
Internet > Freigaben > Portfreigaben → Stelle sicher, dass ausgehende SMTP-Verbindungen erlaubt sind.

Falls Port 587 oder 465 gesperrt ist, füge eine Freigabe für SMTP (Mail-Versand) hinzu.

🔍 5. E-Mail-Logs von 1und1 prüfen

Falls der Fehler immer noch besteht, logge dich in dein 1und1 E-Mail-Konto ein:

📌 https://login.ionos.de/ → E-Mail-Postfach

Dort gibt es oft ein E-Mail-Protokoll oder eine Fehlernachricht, falls 1und1 die E-Mail ablehnt.

🔍 6. DNS-Einstellungen für E-Mail-Versand (SPF, DKIM, DMARC)

Wenn du später @aewi.de als Absender nutzen willst, musst du in deinem DNS-Server (Selfhost oder Fritz!Box) SPF, DKIM und DMARC-Einträge setzen.

Das ist aber für den aktuellen Test nicht nötig!

🚀 Fazit

1️⃣ Teste mit testmail.php, ob PHP überhaupt E-Mails versenden kann.

2️⃣ Überprüfe das MediaWiki-Errorlog, ob dort ein SMTP-Fehler steht.

3️⃣ Firewall & Fritz!Box prüfen, ob Port 587 (TLS) oder 465 (SSL) blockiert ist.

4️⃣ Logge dich in 1und1 ein, um Fehlernachrichten zu sehen.

Falls du noch Fragen hast oder weitere Tests brauchst, sag Bescheid! 😊

Nikolaos:

ist die Portfreigabe für den M1 für SSL auf TCP zu stellen?

Sophos:

Ja, die Portfreigabe für SSL auf dem M1 sollte auf TCP gestellt werden, da E-Mail-Kommunikation über das Transmission Control Protocol (TCP) läuft.

🚀 Relevante Ports für den Mail-Versand (SMTP)

Für den E-Mail-Versand aus MediaWiki über 1&1 (IONOS) benötigst du folgende ausgehenden TCP-Ports:

Protokoll	Port	Beschreibung
SMTP (SSL)	465	Sichere E-Mail-Übertragung mit SSL
SMTP (TLS)	587	Sichere E-Mail-Übertragung mit STARTTLS
SMTP (Unverschlüsselt)	25	Wird oft blockiert, nicht empfohlen

📌 Empfohlen:

Port 587 (TLS), wenn $wgSMTP['secure'] = 'tls';
Port 465 (SSL), wenn $wgSMTP['secure'] = 'ssl';

🔍 Port 25 nicht freigeben! Viele Provider (auch 1und1) blockieren ihn für den ausgehenden Mail-Versand.

🛠️ 1. Firewall auf dem M1 für ausgehenden Mail-Verkehr freigeben

Terminal öffnen und folgenden Befehl ausführen: bash KopierenBearbeiten sudo pfctl -sr | grep 465
Falls keine Ausgabe kommt, könnte die Firewall den Mail-Verkehr blockieren.
Regel setzen, um ausgehende Mails zu erlauben: bash KopierenBearbeiten sudo pfctl -F all

Falls du eine spezifische Regel für Port 465 oder 587 hinzufügen willst:

bash

KopierenBearbeiten

echo "pass out quick on en0 proto tcp from any to any port {465, 587} keep state" | sudo pfctl -f /etc/pf.conf

Dann die Firewall neu starten:

bash

KopierenBearbeiten

sudo pfctl -f /etc/pf.conf && sudo pfctl -e

🛠️ 2. Fritz!Box: Portfreigabe für SMTP

Logge dich auf der Fritz!Box ein (http://fritz.box).
Gehe zu: Internet → Freigaben → Portfreigaben.
Neue Freigabe hinzufügen:
- Protokoll: TCP
- Portbereich: 465 - 465 oder 587 - 587 (je nachdem, was du nutzt)
- Gerät: M1-Server (z.B. AEWI.local oder IP 192.168.2.3)
- Freigabetyp: Nur ausgehend (keine eingehenden SMTP-Verbindungen nötig!)

Speichern und Router neu starten.

🛠️ 3. Testen, ob die Ports nun offen sind

Führe auf dem M1 folgenden Befehl aus:

bash

KopierenBearbeiten

nc -zv smtp.1und1.de 587

Falls alles richtig konfiguriert ist, sollte erscheinen:

bash

KopierenBearbeiten

Connection to smtp.1und1.de port 587 [tcp/smtp] succeeded!

Falls kein Erfolg, überprüfe:

Fritz!Box Einstellungen (Ports freigegeben?)
M1-Firewall (pfctl-Regeln richtig?)
1und1 E-Mail-Logins in MediaWiki korrekt?

🔍 Fazit

✅ Ja, die Portfreigabe für SSL (Port 465) oder TLS (Port 587) muss auf TCP gestellt werden.

✅ Freigabe auf der Fritz!Box für ausgehende Verbindungen

✅ M1-Firewall prüfen und ggf. Port manuell öffnen

✅ Mit nc -zv smtp.1und1.de 587 testen, ob die Verbindung klappt.

Falls du Fragen hast oder der Test fehlschlägt, sag Bescheid! 🚀😊

Nikolaos:

was muß als IDHost für 1und1.de eingetragen werden?

'host' => "smtp.1und1.de", # Dein SMTP-Server

'IDHost' => "1und1.de", # Deine Domain

ist das richtig?

2/2

Sophos:

Ja, das ist fast richtig, aber für 1und1 (IONOS) solltest du als IDHost deine eigene Domain verwenden, also die Domain, von der aus du die E-Mails verschickst.

🔹 Richtig für deine 1und1 E-Mail (klaus.feldmann@online.de):

php

KopierenBearbeiten

$wgSMTP = [

'host' => "smtp.1und1.de", # Der SMTP-Server von 1und1/IONOS

'IDHost' => "online.de", # Deine Absender-Domain

'port' => 587, # Nutze 587 für STARTTLS oder 465 für SSL

'auth' => true, # Authentifizierung erforderlich

'username' => "klaus.feldmann@online.de",

'password' => "dein_passwort",

'secure' => "tls", # Alternativ "ssl" bei Port 465

];

🔹 Falls du eine eigene Domain nutzt (aewi.de):

Falls du eine eigene Domain (z. B. aewi.de) als Absender nutzen möchtest, dann sollte IDHost entsprechend geändert werden:

php

KopierenBearbeiten

'IDHost' => "aewi.de",

Aber Achtung:

1&1 (IONOS) könnte E-Mails mit einer nicht registrierten From-Adresse (@aewi.de) blockieren, wenn sie nicht zu deinem 1&1-Konto gehört.

🔍 Fazit

IDHost sollte die Domain des Absenders sein.
Für 1und1-Adressen (@online.de, @gmx.de, etc.): php KopierenBearbeiten 'IDHost' => "online.de"
Für eigene Domains (z. B. aewi.de): php KopierenBearbeiten 'IDHost' => "aewi.de"
Nutze Port 587 mit TLS oder Port 465 mit SSL.

Falls E-Mails nicht ankommen, überprüfe die SPF/DKIM-Einstellungen deiner Domain in den 1und1-DNS-Einträgen! 😊🚀

Nikolaos:

Hallo. MariaDB startet nicht mehr beim Neustart des M1.

Gebe mir bitte gemäß unserer Installation aus diesem Chat die Befehle, wie ich testen kann, warum das so ist.

Sophos:

Hallo! Um herauszufinden, warum MariaDB beim Neustart nicht mehr automatisch startet, folge diesen Schritten:

1️⃣ Prüfe den Status von MariaDB nach dem Neustart

bash

KopierenBearbeiten

sudo brew services list | grep mariadb

Falls es als "stopped" angezeigt wird, bedeutet das, dass es nicht automatisch gestartet wurde.

2️⃣ Prüfe, ob MariaDB manuell gestartet werden kann

bash

KopierenBearbeiten

sudo brew services restart mariadb@10.5

Falls MariaDB jetzt funktioniert, aber nach einem Neustart nicht mehr, gibt es ein Problem mit der Autostart-Konfiguration.

3️⃣ Starte MariaDB manuell und prüfe die Fehler

bash

KopierenBearbeiten

sudo mariadbd --user=_mysql --datadir=/opt/homebrew/var/mariadb --socket=/opt/homebrew/var/mariadb/mariadb.sock

Falls es nicht startet, wird eine Fehlermeldung ausgegeben.

4️⃣ Überprüfe die Log-Dateien

Zeige die letzten 50 Zeilen des Fehlerprotokolls an:

bash

KopierenBearbeiten

tail -n 50 /opt/homebrew/var/mariadb/mariadb.err

Falls die Datei nicht existiert, prüfe:

bash

KopierenBearbeiten

ls -lah /opt/homebrew/var/mariadb/

Falls mariadb.err fehlt, wurde sie nicht erstellt oder hat keine Schreibrechte.

5️⃣ Prüfe, ob der Dienst in launchctl registriert ist

bash

KopierenBearbeiten

sudo launchctl list | grep mariadb

Falls der Dienst nicht registriert ist, bedeutet das, dass die .plist-Datei fehlt oder fehlerhaft ist.

6️⃣ Prüfe die .plist-Datei von MariaDB

bash

KopierenBearbeiten

cat /Library/LaunchDaemons/com.mariadb.server.plist

Falls sie nicht existiert, muss sie neu erstellt werden.

Falls sie existiert, kannst du versuchen, sie manuell zu laden:

bash

KopierenBearbeiten

sudo launchctl bootstrap system /Library/LaunchDaemons/com.mariadb.server.plist

Falls das fehlschlägt, könnte ein Berechtigungsproblem vorliegen.

7️⃣ Überprüfe die Berechtigungen der .plist-Datei

bash

KopierenBearbeiten

ls -lah /Library/LaunchDaemons/ | grep mariadb

Falls com.mariadb.server.plist nicht root:wheel gehört, setze die Berechtigungen richtig:

bash

KopierenBearbeiten

sudo chown root:wheel /Library/LaunchDaemons/com.mariadb.server.plist

sudo chmod 644 /Library/LaunchDaemons/com.mariadb.server.plist

Danach erneut versuchen, die Datei zu laden:

bash

KopierenBearbeiten

sudo launchctl bootstrap system /Library/LaunchDaemons/com.mariadb.server.plist

8️⃣ Prüfe, ob die Konfigurationsdateien korrekt sind

Prüfe, ob my.cnf an der richtigen Stelle liegt:

bash

KopierenBearbeiten

ls -lah /opt/homebrew/etc/my.cnf

cat /opt/homebrew/etc/my.cnf

Falls my.cnf fehlt oder falsch ist, muss sie korrigiert werden.

9️⃣ Prüfe, ob der MariaDB-Binary existiert

bash

KopierenBearbeiten

ls -lah /opt/homebrew/opt/mariadb@10.5/bin/mariadbd

Falls mariadbd nicht existiert, könnte MariaDB beschädigt sein.

Dann versuche eine Neuinstallation:

bash

KopierenBearbeiten

brew uninstall mariadb@10.5

brew install mariadb@10.5

🔍 Fazit

Falls MariaDB manuell startet, aber nicht automatisch, liegt es an launchctl oder der .plist-Datei.
Falls MariaDB gar nicht startet, überprüfe die Log-Dateien und Berechtigungen.
Falls my.cnf oder die .plist-Datei falsch ist, müssen sie korrigiert werden.

Führe die Tests durch und sende mir die Fehlerausgaben! 😊🚀

Nikolaos:

1. sudo mariadbd --user=_mysql --datadir=/opt/homebrew/var/mariadb --socket=/opt/homebrew/var/mariadb/mariadb.sock

2025-02-24 16:11:46 0 [Warning] Setting lower_case_table_names=2 because file system for /opt/homebrew/var/mariadb/ is case insensitive

mariadbd: Can't create file '/opt/homebrew/var/mariadb/mariadb.err' (errno: 13 "Permission denied")

2025-02-24 16:11:46 0 [Note] Starting MariaDB 10.5.28-MariaDB-log source revision 7eded23be6597b4c485e8cad1538f2ae14541f91 server_uid VRGbu/3gwfDm4tZskCDjP9JYCaM= as process 5340

2025-02-24 16:11:46 0 [ERROR] mariadbd: File '/opt/homebrew/var/mariadb/aria_log_control' not found (Errcode: 13 "Permission denied")

2025-02-24 16:11:46 0 [ERROR] mariadbd: Got error 'Can't open file' when trying to use aria control file '/opt/homebrew/var/mariadb/aria_log_control'

2025-02-24 16:11:46 0 [ERROR] Plugin 'Aria' registration as a STORAGE ENGINE failed.

2025-02-24 16:11:46 0 [ERROR] InnoDB: The innodb_system data file 'ibdata1' must be writable

2025-02-24 16:11:46 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.

2025-02-24 16:11:46 0 [Note] Plugin 'FEEDBACK' is disabled.

2025-02-24 16:11:46 0 [ERROR] Could not open mysql.plugin table: "Unknown storage engine 'Aria'". Some plugins may be not loaded

2025-02-24 16:11:46 0 [ERROR] Failed to initialize plugins.

2025-02-24 16:11:46 0 [ERROR] Aborting

2. tail -n 50 /opt/homebrew/var/mariadb/mariadb.err

250224 08:23:14 mysqld_safe Starting mariadbd daemon with databases from /opt/homebrew/var/mysql

2025-02-24 8:23:14 0 [Warning] Setting lower_case_table_names=2 because file system for /opt/homebrew/var/mysql/ is case insensitive

/opt/homebrew/opt/mariadb@10.5/bin/mariadbd: Please consult the Knowledge Base to find out how to run mysqld as root!

2025-02-24 8:23:14 0 [ERROR] Aborting

250224 08:23:14 mysqld_safe mysqld from pid file /opt/homebrew/var/mysql/dns.fritz.box.pid ended

250224 08:23:24 mysqld_safe Starting mariadbd daemon with databases from /opt/homebrew/var/mysql

2025-02-24 8:23:24 0 [Warning] Setting lower_case_table_names=2 because file system for /opt/homebrew/var/mysql/ is case insensitive

/opt/homebrew/opt/mariadb@10.5/bin/mariadbd: Please consult the Knowledge Base to find out how to run mysqld as root!

2025-02-24 8:23:24 0 [ERROR] Aborting

250224 08:23:24 mysqld_safe mysqld from pid file /opt/homebrew/var/mysql/dns.fritz.box.pid ended

250224 08:23:34 mysqld_safe Starting mariadbd daemon with databases from /opt/homebrew/var/mysql

2025-02-24 8:23:34 0 [Warning] Setting lower_case_table_names=2 because file system for /opt/homebrew/var/mysql/ is case insensitive

/opt/homebrew/opt/mariadb@10.5/bin/mariadbd: Please consult the Knowledge Base to find out how to run mysqld as root!

2025-02-24 8:23:34 0 [ERROR] Aborting

250224 08:23:34 mysqld_safe mysqld from pid file /opt/homebrew/var/mysql/dns.fritz.box.pid ended

250224 08:23:45 mysqld_safe Starting mariadbd daemon with databases from /opt/homebrew/var/mysql

2025-02-24 8:23:45 0 [Warning] Setting lower_case_table_names=2 because file system for /opt/homebrew/var/mysql/ is case insensitive

/opt/homebrew/opt/mariadb@10.5/bin/mariadbd: Please consult the Knowledge Base to find out how to run mysqld as root!

2025-02-24 8:23:45 0 [ERROR] Aborting

250224 08:23:45 mysqld_safe mysqld from pid file /opt/homebrew/var/mysql/dns.fritz.box.pid ended

250224 08:23:55 mysqld_safe Starting mariadbd daemon with databases from /opt/homebrew/var/mysql

2025-02-24 8:23:55 0 [Warning] Setting lower_case_table_names=2 because file system for /opt/homebrew/var/mysql/ is case insensitive

/opt/homebrew/opt/mariadb@10.5/bin/mariadbd: Please consult the Knowledge Base to find out how to run mysqld as root!

2025-02-24 8:23:55 0 [ERROR] Aborting

250224 08:23:55 mysqld_safe mysqld from pid file /opt/homebrew/var/mysql/dns.fritz.box.pid ended

250224 08:24:05 mysqld_safe Starting mariadbd daemon with databases from /opt/homebrew/var/mysql

2025-02-24 8:24:05 0 [Warning] Setting lower_case_table_names=2 because file system for /opt/homebrew/var/mysql/ is case insensitive

/opt/homebrew/opt/mariadb@10.5/bin/mariadbd: Please consult the Knowledge Base to find out how to run mysqld as root!

2025-02-24 8:24:05 0 [ERROR] Aborting

250224 08:24:05 mysqld_safe mysqld from pid file /opt/homebrew/var/mysql/dns.fritz.box.pid ended

250224 08:24:15 mysqld_safe Starting mariadbd daemon with databases from /opt/homebrew/var/mysql

2025-02-24 8:24:15 0 [Warning] Setting lower_case_table_names=2 because file system for /opt/homebrew/var/mysql/ is case insensitive

/opt/homebrew/opt/mariadb@10.5/bin/mariadbd: Please consult the Knowledge Base to find out how to run mysqld as root!

2025-02-24 8:24:15 0 [ERROR] Aborting

250224 08:24:15 mysqld_safe mysqld from pid file /opt/homebrew/var/mysql/dns.fritz.box.pid ended

250224 08:24:25 mysqld_safe Starting mariadbd daemon with databases from /opt/homebrew/var/mysql

2025-02-24 8:24:25 0 [Warning] Setting lower_case_table_names=2 because file system for /opt/homebrew/var/mysql/ is case insensitive

/opt/homebrew/opt/mariadb@10.5/bin/mariadbd: Please consult the Knowledge Base to find out how to run mysqld as root!

2025-02-24 8:24:25 0 [ERROR] Aborting

250224 08:24:25 mysqld_safe mysqld from pid file /opt/homebrew/var/mysql/dns.fritz.box.pid ended

2025-02-24 8:31:11 0 [Note] /opt/homebrew/opt/mariadb@10.5/bin/mariadbd (initiated by: unknown): Normal shutdown

2025-02-24 8:31:11 0 [Note] InnoDB: FTS optimize thread exiting.

2025-02-24 8:31:11 0 [Note] InnoDB: Starting shutdown...

2025-02-24 8:31:11 0 [Note] InnoDB: Dumping buffer pool(s) to /opt/homebrew/var/mariadb/ib_buffer_pool

2025-02-24 8:31:11 0 [ERROR] InnoDB: Cannot open '/opt/homebrew/var/mariadb/ib_buffer_pool.incomplete' for writing: Permission denied

2025-02-24 8:31:11 0 [ERROR] InnoDB: Operating system error number 13 in a file operation.

2025-02-24 8:31:11 0 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.

2025-02-24 8:31:11 0 [Note] InnoDB: Shutdown completed; log sequence number 6446020822; transaction id 146814

2025-02-24 8:31:11 0 [Note] Event Scheduler: Purging the queue. 0 events

2025-02-24 8:31:11 0 [Note] /opt/homebrew/opt/mariadb@10.5/bin/mariadbd: Shutdown complete

3. sudo launchctl list | grep mariadb

- 1 com.mariadb.server

Hast du eine Idee?

Sophos:

Ja, ich sehe mehrere Probleme, die dazu führen, dass MariaDB nicht richtig startet:

🔍 Analyse der Fehler

Fehlende Schreibrechte auf /opt/homebrew/var/mariadb/ swift KopierenBearbeiten mariadbd: Can't create file '/opt/homebrew/var/mariadb/mariadb.err' (errno: 13 "Permission denied")
→ MariaDB hat keine Berechtigung, die Datei zu schreiben → Berechtigungen müssen überprüft und ggf. korrigiert werden
Fehlende Schreibrechte auf InnoDB-Datenbankdateien swift KopierenBearbeiten 2025-02-24 8:31:11 0 [ERROR] InnoDB: Cannot open '/opt/homebrew/var/mariadb/ib_buffer_pool.incomplete' for writing: Permission denied
→ InnoDB kann seine Dateien nicht bearbeiten → MariaDB läuft möglicherweise nicht mit dem richtigen Benutzer
Problem mit mysqld_safe und launchctl swift KopierenBearbeiten /opt/homebrew/opt/mariadb@10.5/bin/mariadbd: Please consult the Knowledge Base to find out how to run mysqld as root!
→ MariaDB versucht, als root zu laufen, aber das ist nicht erlaubt. → launchctl oder homebrew.mxcl.mariadb@10.5.plist könnte falsch konfiguriert sein.

🔧 Schritt-für-Schritt-Lösung

1️⃣ Prüfe und korrigiere die Berechtigungen

Führe folgenden Befehl aus, um die Berechtigungen richtig zu setzen:

bash

KopierenBearbeiten

sudo chown -R _mysql:_mysql /opt/homebrew/var/mariadb

sudo chmod -R 755 /opt/homebrew/var/mariadb

🔹 Erklärung:

chown -R _mysql:_mysql: Setzt _mysql als Besitzer für den gesamten MariaDB-Ordner
chmod -R 755: Setzt Lese- und Schreibrechte für _mysql

2️⃣ Prüfe, ob der MariaDB-Prozess noch läuft

bash

KopierenBearbeiten

ps aux | grep mariadb

Falls ein Prozess läuft, stoppe ihn:

bash

KopierenBearbeiten

sudo killall -9 mariadbd

3️⃣ Prüfe, ob launchctl den richtigen Dienst verwendet

bash

KopierenBearbeiten

sudo launchctl list | grep mariadb

Falls dort homebrew.mxcl.mariadb@10.5 steht, muss Homebrew den Dienst korrekt registrieren.

Falls nicht, dann versuche folgendes:

bash

KopierenBearbeiten

sudo launchctl unload /Library/LaunchDaemons/com.mariadb.server.plist

sudo launchctl load /Library/LaunchDaemons/com.mariadb.server.plist

Falls das nicht hilft, kannst du MariaDB erneut mit Homebrew registrieren:

bash

KopierenBearbeiten

sudo brew services restart mariadb@10.5

4️⃣ Prüfe die MySQL-Konfigurationsdatei (my.cnf)

Falls Homebrew die falsche Datenbankdatei benutzt, stelle sicher, dass sie korrekt konfiguriert ist:

bash

KopierenBearbeiten

cat /opt/homebrew/etc/my.cnf

Sie sollte enthalten:

ini

KopierenBearbeiten

[mysqld]

datadir = /opt/homebrew/var/mariadb

socket = /opt/homebrew/var/mariadb/mariadb.sock

bind-address = 127.0.0.1

[client]

socket = /opt/homebrew/var/mariadb/mariadb.sock

Falls datadir oder socket auf /opt/homebrew/var/mysql verweist, ändere es auf /opt/homebrew/var/mariadb.

5️⃣ Prüfe, ob MariaDB nun startet

bash

KopierenBearbeiten

sudo mariadbd --user=_mysql --datadir=/opt/homebrew/var/mariadb --socket=/opt/homebrew/var/mariadb/mariadb.sock

Falls es ohne Fehler läuft, beende es mit CTRL + C und starte es über Homebrew:

bash

KopierenBearbeiten

sudo brew services start mariadb@10.5

✅ Erwartetes Ergebnis

Nach diesen Schritten sollte MariaDB:

Automatisch beim Booten starten
Keine Fehler mehr wegen fehlender Berechtigungen haben
Über brew services list als "started" angezeigt werden

🚀 Falls es noch Probleme gibt

Falls MariaDB nach einem Neustart wieder nicht startet:

Poste die Ausgabe von: bash KopierenBearbeiten ls -lah /opt/homebrew/var/mariadb/
sudo launchctl list | grep mariadb
tail -n 50 /opt/homebrew/var/mariadb/mariadb.err
Falls nötig, lösche den mariadb.sock-Socket und starte MariaDB neu: bash KopierenBearbeiten sudo rm -f /opt/homebrew/var/mariadb/mariadb.sock
sudo brew services restart mariadb@10.5

Probiere die Schritte aus und gib mir Bescheid! 😊🚀

Nikolaos:

Ich habe nur die Berechtigungen neu gesetzt. MariaDB ist wieder beim Neustart automatisch gestartet. Danke für die Unterstützung.

Sophos:

Super! 🎉 Dass es nur an den Berechtigungen lag, zeigt, wie wichtig es ist, die richtigen Nutzerrechte für MariaDB sicherzustellen. Jetzt läuft alles wieder automatisch beim Neustart – genau so soll es sein.

Falls du noch weitere Fragen hast oder wir demnächst ElasticSearch für MediaWiki installieren, sag einfach Bescheid. 🚀😃