Wann gibt es diese Funktion? Das wäre eine große Hilfe, vor allem bei Kunden, die immer wieder anfragen... wäre das eine sorge weniger.
Geht doch schon: lcphp:
Beiträge von antondollmaier
-
-
Das dürfte vorrangig an den Hetzner-IPs liegen. Wir haben aktuell keine Probleme.
-
Das wäre schlecht. Wie gesagt, 99,99% aller Kunden wissen wirklich nicht, das man erst den Haken in LiveConfig setzen muss
Wir haben die Selbstverwaltung der Postfächer über den LCDEFAULTS "mail.weblogin.enabled=1" pauschal aktiv. Es gibt, IMHO, nur wenige Gründe, weshalb sich die Postfach-Nutzer nicht selbst anmelden können dürfen.
-
-
Tut es.
Wir trennen in unseren Cloud-Umgebungen unter Debian die Mount-Punkte auf:
- das Betriebssystem mit Logs, Konfiguration etc (/boot hat keine Relevanz)
- /var/www für die Webseiten. Das Dateisystem-Quota kann bequem im laufenden Betrieb aktiviert werden.
- /var/lib/mysql für ... mySQL.
- /var/mail für Mail
Quotas sind somit effektiv nur auf /var/www notwendig.
Nebeneffekt: ein voller /var/www-Mountpunkt macht der Datenbank nichts aus.
Ich freue mich natürlich über eine Rückmeldung, ob die Anleitung bei dir funktioniert.
-
Wir haben ein (Python-)Script mit Cache, das Mails ähnlich dem Mail-Quota rausschickt. Wäre aber dennoch schön, wenn das integriert wäre, auch wenn die Mailadresse nicht für jeden Endkunden verpflichtend ist.
-
Auf dem Server ist Letsencrypt installiert und aktiv... aber die Config fehlt (auch wenn ich einen neuen LetsEncrypt anlege unter SSL Zertifikate -> SSL Anbieter).
Bin ich in den falschen Einstellungen?
Welche Konfiguration sollte denn fehlen? LiveConfig benötigt keinen certbot.
-
Zitat: "bei anderen Hostern muss ich auch nichts selbst kopieren, da geht das automatisch".
Es hat sicher seine Gründe, warum der Kunde sich für euch/uns entschieden hat. Die automatische Migration war's initial ja nicht ...
-
Dafür wird:
- eines der managesieve-Plugins in RoundCube
- sowie die ManageSieve-Konfiguration im Dovecot
benötigt.
Achtung: LiveConfig konfiguriert den Autoresponder auch über Sieve. Nutzt der Kunde seine E-Mail-Filter und konfiguriert dann einen Autoresponder, so sind die eigenen Filter plötzlich deaktiviert.
-
In LiveConfig 2 konnten Endkunden ohne eigenen Let's-Encrypt-Account bislang keine Zertifikate für z.B. Subdomains selber anlegen.
Häufig war/ist einfach als "admin" ein LE-Account eingerichtet, und beim Anlegen neuer Domains konnte mit einer (sogar vorausgewählten) Checkbox automatisch ein Let's-Encrypt-Zertifikat dafür eingerichtet werden. Der Endkunde hat von dem Zertifikat selbst üblicherweise praktisch nichts mitbekommen (die technischen Details interessieren die meisten Anwender ja auch nicht).
Das klappt aber nur für Domains. Wenn der Kunde in LC2 eine eigene Subdomain will, dann brauchen sie auch den eigenen Account, um das Zertifikat selbst zu erstellen.
Schön, dass das mit LC3 nun anders läuft und der Kunden-eigene Account somit weg fällt.
-
Allgemein zu Let's Encrypt: es ist nicht notwendig, dass sich Endkunden eigene Let's-Encrypt-Accounts anlegen. Im Idealfall sollte TLS inzwischen völlig transparent für Endkunden funktionieren: der Admin richtet einen "zentralen" Let's-Encrypt-Account ein, und Endkunden aktivieren beim Anlegen/Bearbeiten einer Subdomain lediglich die TLS-Checkbox. Den Rest macht LiveConfig automatisch.
Das ist aber neu in LiveConfig3 (und so auch sinnvoll!), aber bisher in LiveConfig2 so nicht gewesen - oder hab ich die letzten 10 Jahre da was falsch benutzt?
-
Ich würde die Datei nach /etc/liveconfig/lua.d legen. Nach /usr/lib kommen IMHO die Paket-Defaults.
Weitere Infos: https://www.liveconfig.com/de/…admin/lua.html#custom-lua
-
Folgende Zeile steht in der alten main.cf Datei:
smtpd_discard_ehlo_keywords = silent-discard, dsn
die neue Zeile sieht so aus:
smtpd_discard_ehlo_keywords = silent-discard
Empfehlung: das Ganze in die custom.lua aufnehmen, sonst ist die Konfiguration beim nächsten "Service neu konfigurieren" via LiveConfig weg.
Codepostfix.LOCALCONFIG = { ['smtpd_discard_ehlo_keywords'] = "silent-discard" } -
Zu Wildcard-Zertifikaten: wie sähe der Anwendungsfall hierfür aus? Es "kostet" ja nichts, jeweils einzelne Zertifikate auszustellen.
Prinzipiell wären Wildcard-Zertifikate mit LC3 realisierbar, vorausgesetzt die betroffene Domain wird auch von LiveConfig im DNS verwaltet.
Der Vorteil wäre eher die DNS-Validierung, die für Wildcard-Zertifikate ja zwingend nötig ist.
Somit könnten auch Webserver, die nur im internen LAN (bzw privates VLAN hinter VPN) erreichbar sein können, ein valides SSL-Zertifikat erhalten.
Und: der Hostname taucht nicht mehr im Transparency-Log auf.
-
So sehe ich das auch, aber Sie glauben gar nicht, wie viele Kunden das noch immer nutzen. Eine "zwangsabschaltung" würde mit Kommentaren wie folgt enden: "dann suchen wir uns eben einen anderen Hoster, der das unterstützt." Oder Bewertungen bei Google: "Der Hoster hat meine Webseite geschrottet"... Das ist wie in den Flugzeugen mit den Disketten oder den Faxgeräten in den Behörden - mit den ewig gestrigen braucht man da nicht zu diskutieren.
Bestandssysteme laufen lassen, Neusysteme aktuell halten. Altsysteme bekommen keine neuen Funktionen. Wenn der Kunde diese neuen Funktionen will, muss er auf ein neues System wechseln - und da geht dann kein PHP 5.6 mehr.
Wir werden nun allen Kunden, die PHP 5.6 weiterhin verwenden, den Vertrag zum Ende der Laufzeit kündigen. Diese Wahl haben ja auch wir Hoster. Damit wird keine Webseite geschrottet und der Kunde kann sich bequem den für sein Schrott-System passenden Anbieter suchen. Negative Bewertungen erwarte ich bei dem Vorgehen auch nicht.
Randnotiz: ihr habt ja da alle AV-Verträge. Steht da drinnen "Systeme nach Stand der Technik"? Das wäre dann nämlich falsch - PHP 5.6 entspricht definitiv nicht mehr dem Stand der Technik. Die Diskussion, inwieweit wir Hoster uns haftbar machen würden, überlasse ich den Juristen.
-
Mailkonten werden nicht gelöscht sondern werden durchgestrichen mit einem grauen Uhrensymbol dargestellt. Hier besteht Handlungsbedarf.
Was steht im Log vom LiveConfig-Dienst dazu?
Wir fahren unsere Systeme pauschal auf Debug-Mode, um wirklich alle Logs mitzubekommen. Das war in der Vergangenheit schon hilfreich.
-
wenn man eine Domain löscht, und anklickt das alle Zertifikate mit gelöscht werden sollen, wird die Domain gelöscht aber die Zertifikate nicht.
Passend dazu: wenn der Kunde gelöscht wird, werden die Zertifikate gleich mit gelöscht? Wir haben ohne Ende Reste in der Datenbank, die auch schön renewed versucht werden.
-
Randnotiz: der "include_path" muss eigentlich gar nicht via LiveConfig gesetzt werden. Wir haben diese Einstellung weder als Admin noch für Benutzer verfügbar.
-
Ist hier geplant, den Terminalzugriff hinter einer Jail zu verstecken?
Das gleiche gilt natürlich auch für den SSH-Zugriff.
Rein das Terminal ist sinnfrei, wenn SSH dann nicht eingesperrt wäre.
Jails sind schwierig und nur bedingt sinnvoll. Es müssten dann alle benötigten Programme (rsync, PHP, ...) mit allen Libraries mit in alle Jails kopiert werden. Das ist ein großer Wartungsaufwand und äußerst fehleranfällig.
Die von dir angesprochenen Backups in /var/backups wären bei uns dpkg und alternatives. Die sind unkritisch. Gefunden habe ich noch "shadow.bak", die allerdings auch auf Grund fehlender Berechtigungen nicht kopiert werden kann - passt.
Letztendlich müsste, neben SSH, dann auch ein Jail für PHP selbst verwendet werden. Sonst bin ich über "system('ls /var/backups');" auch wieder "draußen".
Persönliche Meinung: es ist sinnvoller, die Server allgemein zu härten. Leserechte entziehen, wenn nötig - und ja, manche Daten scheinen auf den ersten Blick ein Problem zu sein, sind aber schlichtweg für den Betrieb für alle lesbar nötig (Beispiel: /etc/passwd, damit die Directory Listings auch richtig angezeigt werden können).
Wir setzen bei uns noch "/var/www" auf 0751. Damit ist ein Directory Listing ("ls -la /var/www") nicht mehr möglich. Lässt sich aber durch die passwd auch umgehen, wenn es jemand drauf anlegt.
-
Prüfe bitte die Einträge in der "DBS"-Tabelle zum Vertrag. Außerdem das LiveConfig-Prozess-Log prüfen, weshalb die Datenbank oder der FTP-Account nicht gelöscht werden konnte.
