Lizenz-Upgrade geht problemlos.
Ein "Merge" mehrerer Standard-Server ist nicht (ohne weiteres und manuelle DB-Gepfusche) möglich. Das schlägt spätestens dann fehl, wenn es den selben Vertrags/Account-Namen (z.B. "web1") auf mehreren Servern gibt. Im Business-Verbund/"Cluster" müssen alle Vertragsnamen absolut eindeutig sein (und sind es auch).
Ist dann dennoch ein Relayhost bzw. ein Empfänger-spezifischer Transport. Kann die UI machen, öffnet aber Missbrauch Tür und Tor:
- was passiert bei Bounces?
- wie reagiert dein Server, wenn dein Zielserver die Mail als Spam aussortiert?
- Ist der Zielserver überhaupt sauber konfiguriert? Stichwort SPF/DMARC
- was du vor hast, wäre außerdem eine Split-Zone: der MX der Domain ist nur für einen Teil der E-Mails der Domain zuständig. Weiß der andere Server, wie die weiteren Mailadressen in der Zone für ausgehende Mails erreicht werden können?
Alles in allem - IMHO nichts für "mal eben schnell" oder "direkt in der GUI eintragbar".
Danke Anton. Durchklicken ist bei 400 Domains keine Option. SOAP habe ich noch nie benutzt und aktuell auch kein wirkliches Interesse, mich damit auseinanderzusetzen. Gibt es denn wirklich keinen Weg, dass LC die Konfiguration aller Kunden und Verträge vollständig nochmal auf den Server durchdrückt? Das finde ich echt subotimal, um es vorsichtig und nett auszudrücken.
Stimme dir zu.
DNS-Änderungen, wenn die Zone schon angelegt ist, können mit dem IP-Change gemacht werden.
Ein Wechsel intern->extern ist meines Wissens nicht "bulk" möglich.
SOAP-API oder Durchklicken.
¯\_(ツ)_/¯
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:
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.
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,
Gleich einmal vorweg: Ich bin leider kein Profi auf dem Gebiet Datenbanken. Daher folgende Fragen
Ach, wir sind ja auch noch beim Webserver 
ZitatEs 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.
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.
