Beiträge von Sumeragi

    Da ich jüngst darauf gestoßen bin:


    Im Installationsskript install-all.sh finden sich folgende Zeilen

    Bash
    chown popuser:popuser /opt/pdadmin/bin/forward_filter
    chmod 4755 /opt/pdadmin/bin/forward_filter

    Zum Ausführungszeitpunkt ist die Datei jedoch noch nicht angelegt, wodurch es zu einem Fehler kommt. Verschiebt man die Zeilen z.B. an das Ende des Installationstionsskripts passt alles.


    Dies sind somit die richtigen und vorgesehenen Berechtigungen für forward_filter ;)

    Für groff muss man das Paket groff-base verwenden. Und ImageMagick ist im epel Repository verfügbar:

    libnsl und libxcrypt wird als 32bit Version benötigt. Installiert habe ich aber auch die 64bit Variante.


    Ansonsten habe ich im Anhang einmal die Ausgabe von rpm -qa angefügt. Ich weiß nämlich nicht, ob das Image bei B&K identisch mit den Images unter centos.org ist. Bei mir war z.B. von vorn herein das epel Repository installiert und aktiviert. Bisher musste ich dies immer nachträglich hinzufügen.

    Der Fehler ist ja, dass die DNS Server nicht erreicht werden konnten. Ich sehe hier kein Fehler in Zusammenhang mit einem falschen Perl Interpreter.


    Leider setze ich kein Debian ein, um dies selber zu testen. Besteht das Problem denn weiterhin? Was passiert wenn man die NS manuell abfragt?

    Ich nutze leider kein Debian, um hier weiter helfen zu können. Jedoch...

    bei der Installation unter Debian 10.1 ist mir folgendes aufgefallen…

    Code
    […]
    configuring simscan ...
    grep: /etc/tcp.smtp: No such file or directory
    grep: /etc/tcp.msa: No such file or directory
    simscan cdb file built. /var/qmail/simcontrol/simcontrol.cdb
    […]

    wird hier während der Installation /usr/local/pd-admin2/CONFIGURE/configure-sc.sh ausgeführt. In dem Skript sind die Zeilen

    Bash
    24: if ! grep var/qmail/bin/simscan /etc/tcp.smtp 1>/dev/null; then
    34: if ! grep var/qmail/bin/simscan /etc/tcp.msa 1>/dev/null; then

    enthalten. stdout wird zwar nach /dev/null geleitet, nicht aber stderr. Da die Dateien nicht existieren, gibt es als ein Fehler. Innerhalb der folgenden If-Anweisung werden die Dateien dann angelegt. Dies tritt bei jeder Distribution auf und hat nichts mit Debian 10 zu tun :)

    Also libnsl habe ich jetzt mal installiert.

    Es muss auch libxcrypt.i686 installiert werden. Dies hatte ich über sehen :-( Hatte ohne diese auch Probleme mit dem Apache Service. Mit Installation der beiden Libs habe ich dann keine Probleme bei CentOS 8. Erste Tests mit Anlegen von Domains, Lets Encrypt Zertifikaten und Mail-Zustellung klappten ohne Probleme.

    Mein (Test-)Server ist bei B&K. Dort wird CentOS 8 aus einem vorgefertigten Image installiert und bereit gestellt. Ich musste lediglich die üblichen Pakete + libnsl und libxcrypt installieren. Hilft vielleicht eine Auflistung meiner installierten Pakete zum Abgleich?

    Wenn man schon kein aktuelles Debian10 mehr als Basis nutzen kann wäre es hilfreich wenn wir eine Anleitung für centOS8 bekommen so das alle notwendigen Pakete auf eine Minimalinstallation dazu kommen um letsencrypt, fail2ban etc. aufzusetzen. Denn so langsam brauche ich eine Strategie um neue Server aufzusetzen. Neue Server mit Debian9 sind aus meiner Sicht problematisch weil die lebensdauer auch absehbar kleiner wird.

    fail2ban und letsencrypt sind nicht Bestandteil von pd-admin bzw. der Serverumgebung.


    Für fail2ban gibt es hier im Forum bereits ein Thread dazu. Da dieser schon älter, sowie lang und unübersichtlich ist, würde ich vorschlagen einfach mal einen Neuen zu öffnen. Vielleicht explizit zu der Version 0.10 aus CentOS 8.

    pd-admin bringt eine Lets Encrypt Funktionalität mit. Der certbot selber ist aber nicht Bestandteil von pd-admin oder der Serverumgebung. Dieser wird bei erstmaliger Ausführung der letsencrypt Binary automatisch installiert. Ich habe damit keinerlei Probleme, auch nicht unter CentOS 8.

    Sieht interessant aus. Ich habe jedoch Zweifel, ob rspamd out of the box effektiver ist. Performater offenbar schon, da in C geschrieben. Aber auch rspamd ist auf z.b. DNSRBLs angewiesen oder lernt anhand eines Bayes Filters. Dies bietet auch Spamassassin. Zudem benötigt rspamd den Dienst Redis. Somit müsste auch Redis mit in die SE.

    Laut Apple Postmater Seite werden eingehende Mails zwar auf SPF und DKIM geprüft, es wird dies aber nicht vorausgesetzt. Was genau bemängelt Apple denn? Ist der SPF vielleicht falsch gesetzt?

    Man sollte beachten, dass Weiterleitungen auch Spam weiterleiten. Meiner Erfahrung nach hat man dadurch meist Probleme, weil Anbieter Rate-Limits haben oder die IP temporär blockieren.

    Mit root:root und SETUID Berechtigungen (einem S statt X) wird die Datei mit root Berechtigungen ausgeführt.


    Dies kann zum Einen ein Sicherheitsrisiko darstellen. Bei Sicherheitslücken im Skript kann dies ein Einfallstor sein.


    Zum Anderen liegen die Mailboxen unter /home/popuser. Daher kann es sehr gut sein, dass die Ausführung des Skripts als Nutzer popuser erfolgen muss und nicht root. Zum Beispiel weil andere Umgebungsvariablen, Home Verzeichnis, etc verwendet werden.


    Die Ausführung als root bedeutet nicht automatisch, dass dann alles passt weil root alles darf und kann.


    Bei mir klappt alles und die Dateien sehen wie folgt aus:

    Bash
    # ls -al /opt/pdadmin/bin/forward_filter*
    -rwsr-xr-x. 1 popuser popuser 9547 29. Jun 2016 /opt/pdadmin/bin/forward_filter
    -rwxr-x---. 1 popuser popuser 212 1. Jul 2016 /opt/pdadmin/bin/forward_filter.pl

    SETUID ist nur bei der forward_filter binary gesetzt. Das Perl Skript hat dies nicht gesetzt.

    Wenn ein SE Update PHP Aktualisierungen enthalten, müssen zusätzlich installierte Extension nachinstalliert werden.


    Ich hatte dazu Mal ein Skript gepostet. Dieses führe ich immer manuell nach einem SE Update aus. Sicherlich kann man dies auch weiter automatisieren.

    Der genannte Bug bezieht sich ausschließlich auf PHP 7.4. In dem genannten Bug Report wurde sogar mit PHP 7.2 und 7.3 getestet und der Bug trat nur bei PHP 7.4 auf.


    Der "memory allocation" Fehler deutet darauf hin, dass das Limit für den Arbeitsspeicher im Angebot des Endkunden zu niedrig eingestellt ist. Ich empfehle hier mindestens 768MB. Nextcloud selber empfiehlt bereits ein Minimum von 512MB.


    Die Angaben memory_cost, time_cost, threads sind zudem Parameter der password_hash()-Funktion. Daher wird ein Eintrag in der php.ini auch keinerlei Wirkung haben, da diese nirgends übergeben werden.

    dürfte eigentlich nicht sein. Ich habe Nestcloud 16 unter der SE 6 schon zum Laufen bekommen. Ich habe allerdings

    Code
    extension_dir=""
    extension=apcu.so

    in der php.ini stehen und nicht den vollständigen Pfad. Der kann sich ja mit einem Update der SE immer wieder ändern.