Beiträge von antondollmaier

  • Postfix: Übermittlungsstatus (DMD) aktivieren

    Zitat von armin.moradi

    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.


    Code
    postfix.LOCALCONFIG = {
  ['smtpd_discard_ehlo_keywords'] = "silent-discard"
}

  • LiveConfig 3

    Zitat von kk

    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.

  • Debian Trixie

    Zitat von weltmeister

    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.

  • LiveConfig 3

    Zitat von weltmeister

    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.

  • LiveConfig 3

    Zitat von Systemhaus-EHST

    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.

  • Ausblick auf das nächste große Release

    Zitat von mklahm

    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.

  • Ausblick auf das nächste große Release

    Zitat von kk

    Prometheus-Metriken sind an sich schon vorbereitet, für den Anfang aber noch eher rudimentär (der Appetit kommt beim Essen, es wird sich zeigen welche Daten sinnvoll sind). Weitere Details in Kürze (aktuell sind noch andere Themen etwas wichtiger)

    Danke! Ein einfaches "up" oder "liveconfig_build_info{version=3.0.0-rc10} 1" wäre ja für den Anfang ausreichend ;)

  • Mails händisch löschen? /var/mail oder /var/spool ?

    Zitat von isphttp.de

    danke für eure Unterstützung. Ich habe jetzt das Postfach durch die passwd gefunden. Aber nun stellt sich die Frage, was genau hier zu löschen ist? Um das Postfach zu leeren?


    Ich würde jetzt die Ordner "new" und "cut" leeren und danach die

    dovecot.index, dovecot.list.index und dovecot.mailbox.log löschen, damit diese neu generiert werden:

    Der bessere Weg wäre, die Tools von Dovecot zu benutzen und nicht manuell in den Dateien zu arbeiten. Dovecot hat zwar Möglichkeiten, auf Fehler zu reagieren, sinnvoll ist es nicht. Bei mySQL würde auch keiner auf die Idee kommen, die table.frm manuell zu löschen statt "DROP TABLE" zu nutzen.


    Daher:


    https://serverfault.com/a/769223


    Bzw direkt: https://doc.dovecot.org/main/core/man/doveadm-expunge.1.html

    Code
    doveadm expunge -u $EMAIL mailbox INBOX all

    Dann sind alle Mails in der INBOX weg.

    Zitat

    antondollmaier, welchen Befehl meinst du genau?

    Den von mir zitierten "doveadm user $EMAIL".

  • Weitere DNS Server als Externe

    - neue VMs für DNS erstellen

    - dein Haupt-Server benötigt LiveConfig Business.

    - LiveConfig Client auf den DNS-VMs installieren

    - Serververwaltung: DNS konfigurieren

    - DNS-Verwaltung: deine DNS-Vorlage so konfigurieren, dass die neuen DNS-VMs verwendet werden.


    Klappt hier (vgl. ns1.aditsystems.hosting) einwandfrei.


    Würde vermutlich auch ohne LiveConfig auf den DNS-Slaves funktionieren, dann must du aber jede Zone einzeln erstellen und wieder löschen. PowerDNS könnte mit "Hidden Primary" und "Superslave" arbeiten, aber das hat wieder andere Probleme (been there, done that - unabhängig von LiveConfig).

  • Kunde lässt sich nicht löschen

    Wenn MySQL/MariaDB bereits auf der Node aktiv ist: direkt auch LiveConfig auf mySQL migrieren.


    Ja, man kann SQLite nutzen. Ja, es ist durchaus sinnvoll in manchen Setups. Ja, man baut sich eine Abhängigkeit mehr ein.


    Aber MySQL hat durchaus seine Vorteile gegenüber SQLite...