Beiträge von antondollmaier

¯\_(ツ)_/¯

Wir setzen alle Systeme mit Puppet/Ansible auf. Die einzige Handarbeit sind die individuellen Secrets (LC-Lizenz, MySQL-Passwort, Monitoring) pro Server. Der Server ist dann in ca. 660 Sekunden aufgesetzt, inkl. ".skel"/custom.lua.

Ich hätte ja gerne noch ne Verwaltung der SSH-Keys über die UI/API (gerne auch so, dass wie bei den Crontabs die Datei überschrieben wird) und das idealerweise sogar mit Objekten/Referenzen und nicht nur Text, so dass der Austausch eines SSH-Keys auch direkt alle Referenzen davon austauscht (Stichwort Agentur mit vielen Webspaces/Kunden).

Was spricht dagegen, die ".skel"-Lösung serverweit umzusetzen? Wenn der Kunde kein SSH hat (das gibt's noch?), kann mit dem Verzeichnis halt nichts gemacht werden.

LiveConfig ist auf Port 8443 erreichbar, unabhängig von jeglicher Domain.

Du kannst also Proxy-Domains nach Belieben verwenden.

Es sollte lediglich der canonical host bzw. die http_proxy_url nicht aktiviert werden, weil sonst nur eine Domain verwendet werden würde.

Sorry für offtopic:

Zitat von flo4545

Ein Hostingunternehmen mit Mio Kunden wird sich seine eigene Software programmieren lassen und das wird garantiert keine Webanwendung im Browser sein - wohlmöglich noch mit PHP

och, du würdest dich wundern, für wie viele Millionen Euro Umsatz Typo3 (und PHP-Anwendungen) verwendet werden ...

LiveConfig wertet keine Dateigrößen aus, sondern greift auf die Dovecot Quotas zurück.

Bitte daher sicherstellen, dass die dortigen Werte passen: "doveadm quota get -u user@example.com" zeigt den Wert an - der sollte mit dem in LiveConfig übereinstimmen. Falls es dort Abweichungen zur realen Belegung gibt, kann das Quota mit "doveadm quota recalc -u user@example.com" neu berechnet werden.

Hallo,

DKIM hat mit Weiterleitungen nichts zu tun: die DKIM-Signatur wird beim Ursprungsserver eingefügt. Mails ohne DKIM, die weitergeleitet werden, bleiben auch so.

Wir haben Weiterleitungen zu GMX/Webde/Gmail usw bei uns komplett unterbunden (blacklisted). Bestehende Weiterleitungen blieben aktiv.

PHP-Mails sind ein Problem - in jeglicher Umgebung. Die Empfehlung ist hier, dass diese als "Default" gehen - aber signiert wird nichts. Kunden sind angehalten, SMTP zu verwenden. Und dort gibt's dann ja auch DKIM.

Wir hatten so Fälle des öfteren, nachdem Dritte eine Art DoS gegen LiveConfig gefahren haben. Lässt sich über das Access Log verifizieren. Dann schmiert der Webserver-Prozess schlichtweg weg.

Um hier proaktiv eingreifen zu können, überwachen wir den HTTP(S)-Port von LiveConfig im Monitoring und sind so informiert, falls was schief geht.

Zitat von True Studios

Nachdem ich die Schritte von dir befolgt habe, ist was ganz lustiges passiert. Zur Erklärung der Situation dieser Website: Es gibt derweilen eine Live-Seite die online ist, die "alte Seite" und diese läuft mit PHP 7.4.33. Wir arbeiten zur Zeit auf einer Subdomain www....../2024 mit PHP 8.3.9. Und nachdem ich die htaccess angepasst habe und das URL-Rewrite in Joomla eingeschaltet habe, führt die Website nun auf eine Unterseite der alte Website.

Bitte passt die Ordner-Struktur an und verschiebt die Dateien:

http://www.example.com -> htdocs/example.com

2024.example.com -> htdocs/joomla2024

Hierdurch ist die Trennung gewährleistet. In "joomla2024" muss dann auch eine eigene .htaccess von Joomla liegen.

Hallo Emily,

Zitat von True Studios

Gleich einmal vorweg: Ich bin leider kein Profi auf dem Gebiet Datenbanken. Daher folgende Fragen

Ach, wir sind ja auch noch beim Webserver

Zitat

Es liegt eine index.php im root-Ordner. Soll die weg? Wir haben grundsätzlich auch in jedem Image-Folder eine index.html, um unerwünschte Bild-Downloads zu uverhindern. Könnte das zu Problemen führen (also zu unserem Problem gerade vor allem)?

Nein, beides belassen. Allerdings sollten neben der index.php keine weiteren .HTML-Dateien mehr liegen.

Zitat

"Options +SymlinksIfOwnerMatch" setze ich quasi statt "Options +FollowSymlinks" und kommentiere in der htaccess nichts aus?

Korrekt.

Zitat

"Options -MultiViews" dann statt "Options -Indexes", oder zusätzlich in eine weitere Zeile dazu?

Zusätzlich einfügen, geht auch in einer Anweisung: "Options -MultiViews -Indexes"

Zuletzt: Error-Log aktivieren und auf dieses, nach mehrfachen Seitenaufrufen, Fehler prüfen.

Viele Grüße,
Anton

- bitte prüfen, ob eine index.html oder weitere Index-Dateien rumliegen.

- "Options +SymlinksIfOwnerMatch" setzen

- sowie mit "Options -MultiViews" die Multiviews deaktivieren

Das hat in der Vergangenheit gereicht.

Zitat von K3ule

antondollmaier Ja exakt, das ist ja das schräge.

Über https://mm-mg.de:8443 komme ich ja auch auf den Server.

Dann lief zwar LiveConfig, aber nicht der Apache. Wenn's jetzt passt, okay - aber LiveConfig läuft (im Gegensatz zu Plesk) als eigener Dienst, völlig unabhängig vom Apache.

Dein Webserver läuft und ist auf dieser IPv4/IPv6-Adresse erreichbar? Die Fehlermeldung sagt, dass das nicht der Fall sein.

Falls der Apache-Proxy nicht will, kann ich das ungültige SSL-Zertifikat akzeptieren. Endkunden werden dieses Zertifikat nicht nutzen. Monitoring stellt sicher, dass das Renewal der Subdomain sauber hinhaut.

Somit ist - mir / bei uns - der LiveConfig-Port selbst sowie das Zertifikat, das LiveConfig dafür verwendet, nicht relevant.

Nein, es ist keine Änderung nötig. Wichtig: zusätzliche Benutzer ("virtuell") können nur für FTP benutzt werden.

Ist derzeit nicht realisierbar, in LC3 aber enthalten.

Bei uns hat sich rausgestellt, dass die Kunden bei "E-Mail" links oben die Gesamt-Anzeige des zugewiesenen Mail-Quotas als "voll" interpretieren und gar nicht erst auf die Anzeige des einzelnen Postfachs achten - passiert gerade bei Kunden, die nur eine oder SEHR wenige Mailadressen nutzen.

Da hilft der Hinweis auf die Aktualisierung gar nicht: das Quota-Limit wird durch "Mails löschen" ja nicht geändert.

Hallo,

vielen Dank! Die Änderung ist auch empfehlenswert, um unterschiedliche Sprachen (Draft vs Entwürfe, ...) zu vereinheitlichen.

Randnotiz: im Changelog ist dazu von Postfix die Rede. Das betrifft aber ja Dovecot

Zitat von isphttp.de

Gibt es eigentlich eine Möglichkeit, Spamhaus mit öffentlichen DNS zu nutzen? Ich finde gerade die Wahl vom DNS kann schon einiges ausmachen, es ist Unverschämtheit, dass Spamhaus hier vorschreibt, welchen DNS man nicht zu nutzen hat.

Lg

Klar - den Dienst von Spamhaus kaufen (wie es deren AGB/T&S eigentlich auch vorsehen ).

Wir setzen eigene interne DNS-Resolver ein. Notfalls einen Unbound oder PowerDNS-Recursor mit auf das System werfen und direkt "localhost" als Resolver nutzen.

Dann gehen wir es doch durch:

- "Blacklist" ist vermutlich der Eintrag, welche E-Mail-Adressen am Postfach als Spam behandelt werden sollen. Wie ist der Eintrag aufgebaut? "*@example.com"?

- was loggt lcsam bei einer solchen problematischen Mail?

- hat LiveConfig den Eintrag in die Konfiguration vom Nutzer geschrieben? Sprich, was steht in der /var/lib/spamassassin/$VERTRAG_$USER? Ist der Eintrag dort aufgeführt?

- ist deine Mailadresse im /etc/postfix/spamassassin aufgeführt?

- "zieht" Spamassassin die Konfigurationsdatei überhaupt?

"Resolving timed out" riecht auffällig nach DNS-Fehler auf dem Server. Stimmt der Resolver?

CURL hat mit den anderen Optimierungen nichts am Hut, zumindest haben wir dahingehend gar nichts optimiert.