Zitat- Ändern der /etc/dovecot/dovecot.conf würde helfen, ist aber nicht nachhaltig:
Die Änderungen in die dovecot.conf.local übernehmen und via "doveconf -n" verifizieren sollte reichen.
Zitat- Ändern der /etc/dovecot/dovecot.conf würde helfen, ist aber nicht nachhaltig:
Die Änderungen in die dovecot.conf.local übernehmen und via "doveconf -n" verifizieren sollte reichen.
Laut erstem Beitrag kam es zu Fehlern im logrotate.service.
Daher: "journalctl -u logrotate.service" aufrufen und prüfen, ob es dort Einträge gibt. Ggf. auch tatsächlich bis 00:00 Uhr warten und im "journalctl -f" mitverfolgen, was so passiert.
Spannend empfinde ich jedoch, dass Logrotate überhaupt um 00:00 Uhr läuft. Standard ist eigentlich 06:25 Uhr für die Dailys.
Logrotate manuell ausführen (logrotate -v -f /etc/logrotate.conf)
Und jetzt eine vielleicht "ganz dumme" Frage: wie wird der Upload-Scan deaktivert, so das Kunden unter PHP 5.6. wieder Daten hochladen können?
PHP-Einstellungen und den Wert entfernen.
Vermutlich zu viel Spam bei GMX/WebDE eingekippt. Die pflegen beide interne Sperrlisten (sind ja eh der selbe Laden).
Gibt es eine Möglichkeit den Mailserver im nachhinein zu verändern?
nein, die bei der Erstellung von Verträgen ausgewählten Servernamen (Web/Mail/DB) lassen sich über die GUI im Nachhinein nicht mehr ändern.
Also beim besten Willen, natürlich KANN man das machen. Man kann und muss aber wohl zuallererst vom Hersteller/Entwickler einer Software , die lange lange aus dem Pre-Release heraus ist, erwarten, dass diese versionsaktuell dokumentiert ist.
Vollste Zustimmung.
ZitatAber hier die Verantwortung auf den Kunden abzuwälzen - so wie von dir vorgeschlagen - ist definitiv nicht der richtige Ansatz.
Das Schlagwort ist hier doch "Kontext-abhängig". Den meisten Endkunden ist weder das bisherige Handbuch, noch das neue Hosting-Handbuch zumutbar (IMHO!). Dafür sind die dortigen Anleitungen zu sehr als Handbuch und weniger als Schritt-für-Schritt-Anleitung gehalten.
Letzteres kann ich IMHO nicht von der LiveConfig GmbH einfordern.
ich stehe bei meinen Kunden nun auch als unprofessionell dar, denn natürlich kommuniziere ich meinen Kunden, wo sich das offizielle Handbuch von LiveConfig beim Herstelle befindet und muss mir dann von meinen Kunden sagen lassen, dass da nichts mehr ist.
Neben der Option, sich das Handbuch zu kopieren und selbst zu hosten/anzubieten, bestünde ja auch noch die Option, sich selbst die für die Endkunden relevante Dokumentation zu erstellen.
Dann sind auch die Screenshots immer aktuell, oder zumindest kann man diese immer selbst aktualisieren.
Falls es jemanden interessiert: Ich habe es mit Transport (http://www.postfix.org/transport.5.html) und custom.lua lösen können. Alle externen Weiterleitungen werden nun von einer von mir festgelegten IP-Adresse verschickt.
Darf man fragen, wie?
Gibt es ein Befehl, die Zonen aus der Liveconfig neu zu schreiben?
Jain.
Die Domain erst auf "externe Nameserver" setzen (Serial notieren/merken).
Danach wieder auf "interne Nameserver" mit der gewünschten DNS-Vorlage. Serial ggf. erhöhen, um definitiv höher zu sein als die vorherige.
Guten Morgen,
Es wäre geil, wenn es möglich wäre Docker Installationen wie bei Plesk installieren zu können.
Ich hätte da gerne einige Anwendungen die derzeit Lahm auf meiner Synology laufen auf meinem Liveconfig Server System.
Darf ich vorschlagen, dafür eine zweite VM mit Rancher aufzusetzen und die ganze Docker-Geschichte nicht in LiveConfig zu ziehen?
- Privilegien-Problematik: Docker-Container laufen als root.
- Unix-Philosophie: ein Tool für einen Zweck
- Kunden-Quotas (der Volumes, der Images, ..., aber auch CPU/Memory)
- Port-Weiterleitungen (funktioniert hinter Apache nicht vernünftig, also müsste Nginx überall davor)
Die Feature-Wunsch-Liste bei LiveConfig ist aktuell schon ziemlich lang, zumal [url=https://www.liveconfig.com/de/forum/threads/2455-Docker-Hosting?highlight=docker]der Vorschlag bereits da war[/quote].
Last but not least gibt es nun auch fertige PHP-Pakete mit dem IonCube-Loader (aktuellste Version) für PHP 5.6-7.4.
Sehr cool - Dankeschön!
Ihr lässt Eure Maschinen ohne Test automatisch updaten?
Wir haben eine Test-Umgebung, bei der die Pakete vorab geprüft werden.
ZitatOder habt Ihr ein eigenes firmeninternes Repository?
Haben wir, natürlich.
ZitatWie gewährleistet Ihr mit dem automatischen Update die Verfügbarkeit?
Kommt auf die Definition von "Verfügbarkeit" an. Reboots durch Kernels sind im Zuge der Wartungsfenster möglich. Durch redundante Maschinen oder entsprechende SLA wird die Verfügbarkeit gewährleistet.
Diese Anfragen häufen sich - einige Kunden finden es nicht selbsterklärend.
Das Problem tritt IMHO nur im Zusammenhang mit eigenen DNS-Einträgen auf: bisher wird dort nur "Zone" und nicht "Subdomain" als Konstrukt erkannt.
Grundsätzlich finde ich die Fortführung der Logik konsequent.
ZitatWas haltet ihr von einer Zeile oder einem Symbol "neue Subdomain" unterhalb jeder Domain
Zumindest bei den "eigenen DNS-Einträgen" würde das helfen.
Neue Subdomain: "_25._tcp.mail", dann dort Webspace deaktivieren und den TLSA-Record erstellen.
wer von euch lässt LiveConfig automatisch updaten? Kann mir jemanden sagen, wie man das am besten bewerkstelligt?
Konfigurationsmanagement (Puppet/Ansible/Salt) kann Pakete auf die gewünschten Versionen heben.
Alternativ Cronjobs oder UnattendedUpgrades.
Wir fahren ein wöchentliches Wartungsfenster, in dem dann auch LiveConfig aktualisiert wird.
Ja, am besten machst Du Dir einen Grep auf die /etc/postfix/virtual_alias (erste Spalte) in eine Datei
ZitatZu den falsch konfigurierten Zwischenzertifikaten: wir erweitern LiveConfig aktuell, dass es beim Start alle SSL-Intermediates prüft und auf abgelaufene Zwischenzertifikate oder fälschlicherweise konfigurierte Root-CA-Zertifikate hinweist.
yeah!
ZitatUrsprünglich wollten wir diese auch automatisch löschen, das ist aber nicht ganz trivial, da eventuelle Ketten damit ungewollt unterbrochen werden könnten. Wir lassen uns da aber auch etwas einfallen.
Eventuell als Idee:
https://github.com/zakjan/cert-chain-resolver
Nimmt das Zertifikat und sucht die CA-Chain selbst raus.
Nicht als Reseller den Endkunden-Vertrag editieren, sondern als Admin den Reseller-Vertrag bearbeiten.
Dort gibt es dann unterhalb des "eigene DNS-Einträge erlaubt/verboten"-Dropdown auch die Auswahl der DNS-Vorlage (in Version 2.9 gerade verifiziert).
ich habe hier eine Multiserver Umgebung mit eigenen NS. Wenn der Admin Domains für sich oder für Kunden anlegt, werden die internen NS zur Auswahl angeboten, wenn dies ein Reseller tut, gibt es nur die Option externe NS.
Ja:
Reseller-Vertrag bearbeiten, Tab Domains. Dort dann die DNS-Vorlage, die der Reseller nutzen darf, auswählen.
Funktioniert hier alles problemlos.