Über find und mtime habe ich auch schon nachgedacht, klappt aber nicht. Die vier Quellbilder sind ja maximal 1 Minute alt und werden zur Sekunde 0 neu (über-) geschrieben.
Ok, das habe ich dann falsch verstanden, mein Fehler.
Über find und mtime habe ich auch schon nachgedacht, klappt aber nicht. Die vier Quellbilder sind ja maximal 1 Minute alt und werden zur Sekunde 0 neu (über-) geschrieben.
Ok, das habe ich dann falsch verstanden, mein Fehler.
Falls jemanden noch was einfällt, woran ich hätte denken sollen, bitte Bescheid sagen
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…
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!"
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:
# 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.
Wurde sie im SCP wirklich diesem Server zugewiesen? Starte mal tcpdump und schau, welche ARP/ICMP Pakete zu dem Zeitpunkt herein kommen.
Oder mit dem find-Befehl und der mtime spielen. Sprich: Nur kopieren, was älter als x Minuten ist.
Loxley Glücklicherweise brauche ich kein explizites Update irgendwelcher Daten, außer beim Quota-Dict. Funktioniert mit einem Test-Insert übrigens nicht:
Auf einem Debian Buster System (VPS 200 G8) startet PHP-FPM nach dem Booten nie automatisch. Ein manuell ausgelöster Start zeigt keine Probleme.
# service php7.2-fpm status
● php7.2-fpm.service - The PHP 7.2 FastCGI Process Manager
Loaded: loaded (/lib/systemd/system/php7.2-fpm.service; enabled; vendor preset: enabled)
Active: failed (Result: timeout) since Sat 2018-07-28 13:35:32 CEST; 9min ago
Docs: man:php-fpm7.2(8)
Process: 450 ExecStart=/usr/sbin/php-fpm7.2 --nodaemonize --fpm-config /etc/php/7.2/fpm/php-fpm.conf (code=killed, signal=TERM)
Main PID: 450 (code=killed, signal=TERM)
Jul 28 13:34:01 example.net systemd[1]: Starting The PHP 7.2 FastCGI Process Manager...
Jul 28 13:35:32 example.net systemd[1]: php7.2-fpm.service: Start operation timed out. Terminating.
Jul 28 13:35:32 example.net systemd[1]: php7.2-fpm.service: Failed with result 'timeout'.
Jul 28 13:35:32 example.net systemd[1]: Failed to start The PHP 7.2 FastCGI Process Manager.
Alles anzeigen
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.
Deinem vServer ist ein ganzes /64-Subnetz zugewiesen. Um die Einrichtung musst Du Dich innerhalb Deines Systems kümmern!
Das CCP oder SCP hat nach der Aktivierung von IPv6 nichts mehr damit zu tun. Oder meinst Du die PTR-Records? (rDNS)
Ich muss halt die ganzen SQL-Dateien für Postfix und Dovecot eventuell anpassen. Meine Joins sind vermutlich nicht kompatibel mit SQLite…
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.
Aus Stored Procedures…
Bildschirmfoto_2018-07-28_00-48-06.png
…werden langsam Queries…
Bildschirmfoto_2018-07-28_00-45-23.png
…die sogar etwas ausspucken. Ob es das richtige Ergebnis ist, muss ich erst überprüfen…
(Mit freundlichen Grüßen aus der Hölle!)
Diese Idee ist auch nicht blöd…
My solution was to create the database as world-readable, mode 644, but
to store it in two secured directories. The database is created in one
of them, and hardlinked into the other.
The two directories are /etc/X/private, owned root:X, mode 750:
drwxr-x--- 2 root dovecot 37 2012-01-13 16:31 /etc/dovecot/private
drwxr-x--- 2 root postfix 37 2012-01-13 16:32 /etc/postfix/private
/etc/dovecot/private:
total 28
-rw-r--r-- 4 root root 526 2012-01-13 00:04 README
-rw-r--r-- 2 root root 21504 2012-02-14 09:01 mail.sqlite
/etc/postfix/private:
total 28
-rw-r--r-- 4 root root 526 2012-01-13 00:04 README
-rw-r--r-- 2 root root 21504 2012-02-14 09:01 mail.sqlite
Alles anzeigen
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…
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?
"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…
Die Jackpotfrage: Wie löse ich das jetzt?
Vorschläge?
Weiterer Vorteil: Dovecot unterstützt SNI, Postfix nicht.
Stimmt, ein weiterer Pluspunkt. Danke für den Hinweis!
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…