Beiträge von KB19

    Falls jemanden noch was einfällt, woran ich hätte denken sollen, bitte Bescheid sagen ^^

    Bash
    find /etc -type f -exec grep -FH 10.0.0.1 {} +
    
    # Eventuell auch noch mit einer anderen Schreibweise,
    # falls es in irgendeiner Datei als Regex vorkommt...
    find /etc -type f -exec grep -FH '10\.0\.0\.1' {} +

    Habe ich was verpasst? Seit wann ist netcup ein "Massenhoster" am deutschen Markt? Ist netcup schon so groß oder definiere ich "Massenhoster" anders? ^^


    (Zitat Beitrag im SSF)

    Meine Joins sind vermutlich nicht kompatibel mit SQLite… :D

    Das war bei Postfix übrigens das kleinste Problem. Die Joins sind zu 100% kompatibel, ich musste nur ein paar CONCAT() Aufrufe durch || ersetzen.


    Aber ein eigenes PHP-Script, das Aliase u.a. bei Aliasdomains komplett auflöst und mittels Cron in einer Tabelle speichert ist MySQL-Only. Das muss ich erst einmal auf SQLite (oder gleich PDO) umschreiben. Das kommt davon, wenn man sich beim Programmieren denkt: "Das brauchst du niemals für einen anderen DB-Typ!" X/

    Sobald ich über SSH drauf bin, ist alles im grünen Bereich. Ich müsste es mal loggen, wie es vorher aussieht, ohne haveged. Mit haveged sieht es derzeit so aus:

    Code
    # uptime
     16:06:23 up  2:14,  1 user,  load average: 0,00, 0,00, 0,00
    
    # cat /proc/sys/kernel/random/entropy_avail
    2442

    Danke für den wertvollen Tipp mit rng-tools, das kannte ich (wie haveged) bisher noch nicht.

    Loxley Glücklicherweise brauche ich kein explizites Update irgendwelcher Daten, außer beim Quota-Dict. Funktioniert mit einem Test-Insert übrigens nicht:

    Code
    Jul 28 14:04:32 example dovecot: auth-worker(1583): Panic: Trying to allocate 0 bytes
    Jul 28 14:04:32 example dovecot: auth-worker(1583): Error: Raw backtrace: […]

    Auf einem Debian Buster System (VPS 200 G8) startet PHP-FPM nach dem Booten nie automatisch. Ein manuell ausgelöster Start zeigt keine Probleme.

    Nach einer kurzen Internetrecherche scheint es an fehlender Entropie von /dev/random zu liegen. Einige Tipps empfehlen, dass man haveged installieren soll. Und tatsächlich, danach startet der Dienst nach dem Booten ohne Probleme. Ob man es anders lösen kann, ohne irgendwelche Startverzögerungen, muss ich erst testen.


    Hat sonst noch jemand dieses Problem? :/

    Bist Du sicher, dass Du _einzelne_ selects schreiben musst?

    Um beim Beispiel Dovecot mit SQLite zu bleiben: Ich kann bei

    user_query/password_query/iterate_query doch nur eine Abfrage angeben, oder was meinst Du?


    Meine Stored Procedure bzw. jetzt der Query ist nur so kompliziert, weil ich eine vergleichsweise komplexe Quota-Konfiguration für den User zurückgebe, die geänderte Maximallimits der Domain halbwegs beachtet. (Und bei MySQL halt auch noch nologin/reason.)

    Warum brauchst Du für jede Website eine eigene IPv6-Adresse mit passendem rDNS-Eintrag?

    Kann man die rDNS Einträge im CCP/SCP mittels der API verändern?

    Derzeit nicht. Es gab dazu schon einmal eine Diskussion, die vom Wunsch her ähnlich ist: Reverse DNS Deligation für IPv6


    btw: Bitte beachte, dass man rDNS-Einträge für IPv6-Adressen im CCP zwar setzen, aber nicht mehr vollständig löschen kann! Das ist aus technischen Gründen leider (noch) nicht möglich. Du kannst sie nachher nur ändern.

    Ich muss halt die ganzen SQL-Dateien für Postfix und Dovecot eventuell anpassen. Meine Joins sind vermutlich nicht kompatibel mit SQLite… :D

    Viel schlimmer! Ich habe ganz vergessen, dass ich das bei meinen anderen Systemen nur noch über Stored Procedures löse, da die Queries relativ komplex geworden sind. Jetzt darf ich 100+ Zeilen Stored Procedures so umschreiben, damit sie als einzelner Query in SQLite lauffähig sind. Einige Komfortfunktionen wie der Grund beim verweigerten Login (Domain deaktiviert; Mailbox deaktiviert; Transport falsch; Wartungsarbeiten; …) müssen dabei leider wegfallen.


    Aber ich wurschtel mich weiter durch, ich will auf dem Testsystem keinen DB-Server! ^^ Und wieder ein wenig über SQLite zu lernen schadet sich auch nicht.

    Bei SQLite gehört die Datei (und der Ordner, da PFA sonst nicht läuft!) einfach postfix:postfixadmin, und in die neue Gruppe postfixadmin packe ich www-data sowie dovecot. Die Rechte kann man auf 0570 und 0460 setzen. Notfalls kann man mit ACLs arbeiten.


    Afaik greift Dovecot auf User/Pass DB nämlich mit den Rechten des übergeordneten Prozesses zu und nicht mit den Rechten des Postfachnutzers. Alles andere wäre auch fatal, weil die Zugangsdaten z.B. zu MySQL ansonsten ungeschützt wären.


    PFA und Roundcube laufen per Default, wenn über APT installiert, beide über www-data. Die FCGI-Konfiguration von PHP diesbezüglich zu ändern geht auch nicht, weil die Rechte der Systemordner sonst nicht mehr dazu passen.


    Ich teste das nachher mal kurz, ob das klappen würde.

    Das ist ein Henne-Ei-Problem. Der Clientsupport für SNI wird schon kommen, je mehr Dienste es unterstützen. Thunderbird und K9 können damit angeblich schon umgehen, getestet habe ich es allerdings noch nicht.

    Danke für Euer Feedback! :)

    Du musst für virtuelle User auch keine Datenbank aufsetzen.

    Klar, aber welche Möglichkeit hat der User dann, sein eigenes Passwort zu ändern? Ohne den Admin zu nerven. Diesen Anspruch habe ich selbst bei einem Testsystem. Dafür müsste ich erst irgendein Script programmieren.


    Es wird wahrscheinlich auf ein klassisches Postfixadmin Setup hinauslaufen, allerdings mit einer SQLite Datenbank. Den Webserver und PHP brauche ich sowieso für Roundcube. Das sollte im Vergleich zu MySQL ähnlich sein und gleichzeitig genügend Komfort bieten. Ich muss halt die ganzen SQL-Dateien für Postfix und Dovecot eventuell anpassen. Meine Joins sind vermutlich nicht kompatibel mit SQLite… :D

    warum dürfen sich Deine User per SSH auf den Server einloggen?

    Die Grundidee beim Testsystem war, dass jeder User einen normalen Account bekommt, seine Mails in ~/.maildir liegen und über SSH mindestens das Passwort ändern darf. Ob er mehr darüber ausführen darf, stand noch nicht 100% fest. Auf jeden Fall war es ein einfaches, schnell zu realisierendes Testsetup, mit dem ich gleich loslegen konnte. Bezüglich Mails verwerfe ich diese Idee jetzt wieder… :)


    Immerhin weiß ich jetzt, dass Postfix und Dovecot mit dem neuen Submissiond gut zusammenarbeiten und es sich lohnt, in das Vmail-Setup mit PFA zu investieren.

    KB19 LDAP ist dein Freund. OpenLDAP möchte dir helfen.

    Uff, das erhöht die Komplexität aber noch mehr, oder? =O

    "absolut nichts falsch gemacht haben" und auf einer Blacklist landen widerspricht sich irgendwie etwas :/

    Mindestens eine der genannten Blacklists nimmt schnell ganze Subnetze auf. Die IP-Nachbarn haben nichts verbrochen und schauen erst einmal doof.


    Oder man bekommt einen neuen Server, dessen IP-Adresse wegen einer Sache von vor ~4 Jahren noch geblacklistet ist. Die Liste verweigert aber die Austragung, wenn man sich nicht kompliziert registriert oder gar Gebühren (!) im zwei-/dreistelligen Bereich zahlt.

    dovecot-submissiond hat einen Haken bei meinem Testsetup: Damit das funktioniert, muss ein lokaler Postfix-Port verfügbar sein, der den XCLIENT-Befehl erlaubt. Dieser Port muss deshalb selbstverständlich durch eine Firewall gefiltert werden, damit wirklich nur Dovecot darauf Zugriff hat. Das wäre mit dem Owner-Match eigentlich keine großartige Sache…


    Das Problem daran: dovecot-submissiond wird logischerweise mit den Rechten des Postfachnutzers ausgeführt. Bei einem typischen Virtual-Setup (wie auf meinen regulären Systemen), wo es nur eine einzige UID/GID für alle Mailboxen gibt und unter diesem User nichts anderes ausgeführt werden kann, würde das kein Problem sein. Das Testsystem basiert aber auf den normalen Useraccounts von Linux, ohne Datenbank und sonstigem Schnickschnack. F… X/


    Die Jackpotfrage: Wie löse ich das jetzt?

    • Den lokalen Usern die Rechte zum Login entziehen.
    • Umstellen auf rein virtuelle User mit einer Datenbank.
    • Irgendeine andere Möglichkeit, die ich übersehe.

    Vorschläge? ;(

    mainziman Bei Spamhaus und SORBS wäre ich halt vorsichtig. Deren Geschäftspraktiken sind alles andere als gut. Wenn man sich auf die als einziges Kriterium verlässt, sind Fehlalarme vorprogrammiert. Das wird legitime Absender, die absolut nichts falsch gemacht haben, sicher freuen…