Beiträge von kai

    Ich habe mich dann doch getraut das Altsystem noch auf eine aktuelle pda Version zu bringen.


    Vorher Umstellung auf Apache 2.4 via /opt/pdadmin/bin/select-webserver.sh AP24.

    Ging nicht, Webserver nicht erreichbar, weil die /usr/local/pd-admin2/httpd-2.4/conf/httpd24.conf-template leer war 8|


    Datei mit dem Template aus dem Updater/Installer ersetzt -> wieder alles OK.

    Update auf pda v4.100 -> OK


    Migration nochmal getestet -> lz4 fehlte auf Quell- und Zielserver(!)

    Information vom Quellserver: </opt/pdadmin/bin/home-tar.sh: Zeile 11: type: lz4: Nicht gefunden.>


    Die Migration hat nun also funktioniert :thumbup:

    Hallo,


    nach *sehr* langer Zeit wurde es mal wieder Zeit für neue Hardware und ich möchte gerne alle Accounts/Kunden vom Altsystem auf das neue bringen.

    neu: pda v4.100 / seu 6-0.406

    alt: pda v4.76 / seu *2*-0.377


    Altversion ist noch auf Apache 2.2 und alter Reihe 2.

    Ich nehme an, dass der Import für solch einen Versionsunterschied nicht gebaut wurde?


    Fehlermeldung:

    Code
    Not a HASH reference at /opt/pdadmin/bin/import-customer line 529.
    at /opt/pdadmin/bin/import-customer line 529
    main::create_domainkeys('eingldbp', 'ARRAY(0x16aba30)') called at /opt/pdadmin/bin/import-customer line 1076
    main::import_customer_data('HASH(0x16b8dd0)', 'HASH(0x16dd078)', 'ARRAY(0x16b9280)', 0) called at /opt/pdadmin/bin/import-customer line 1194
    main::main() called at /opt/pdadmin/bin/import-customer line 1227
    curl: (23) Failure writing output to destination
    (import-customer.sh:112
    Zitat

    Gibt es eventuell ein Problem mit dem Resolver oder bei der DNS-Aufloesung der konkreten Domain?


    Die konkrete Domain ist varoenergy.com


    Auf meinem Server läuft dnscache.


    Probleme bei der AUflösung kann ich erstmal nicht erkennen.
    Oder gibt es konkrete Tests die ich durchführen könnte?




    Hallo,


    ein Kunde beschwert sich, dass Mails von einem, Geschäftspartner nicht ankommen.
    In den Logs sind mir dann große Lücken (1 Minute) zwischen Annahme der SMTP Verbindung und der Ausgabe des Greylistings aufgefallen:


    Code
    Feb 24 06:05:50 srv smtpd: 1519448750.421517 tcpserver: pid 31119 from 66.193.80.133
    Feb 24 06:05:50 srv smtpd: 1519448750.422567 tcpserver: ok 31119 srv.wfx.de:::ffff:78.46.87.195:25 3.mx3west.email.active.com:::ffff:66.193.80.133::46752
    ...
    Feb 24 06:06:51 srv greylisting[31182]: sender egal@example.org, address 66.193.80.133 bypassed: SPF ok.
    Feb 24 06:06:51 srv smtpd: 1519448811.021372 tcpserver: end 31119 status 256



    Kommt smtp_greylist.pl als Fehlerquelle in Frage?
    Kann ich sehen, wieviel Zeit dafür drauf geht?
    Passiert da noch mehr als Greylisting?
    (z.B. Prüfung "Mailserver ohne PTR record")


    ODER muss ich rblspp unter die Lupe nehmen?


    Danke,


    Kai

    Zitat

    Ich weiß nicht wozu diese dienen, gehe aber davon aus, dass für SSL-Zertifikat auch Änderungen in der DB notwendig sind.


    Deswegen ja

    SQL
    UPDATE vhosts SET ssl_enabled = '1', ssl_active='1', sni = '1' WHERE name = 'www' AND domain = (SELECT id FROM domains WHERE name = 'domain.org')


    Damit werden die Zertifikate in /opt/pdadmin/sslcerts/ genutzt.
    Zumindest reichen die aufgelisteten manuellen Schritte pro Domain, damit die unter https läuft...

    Die Idee finde ich gut :)


    Da der Wrapper /opt/pdadmin/bin/certbot-auto meine Umgebung leider nicht unterstützt, hantiere ich mit getssl herum :-\


    Eigentlich müsste man das nur noch scripten und hätte eine Lösung die unabhängig von der Umgebung ist.


    Mit "gibt es ein Script" meinte ich innerhalb von pdadmin.


    Die .qmail Datein haben schon einige Updates/Migrationen mitgemacht.
    Die ganz alten sehen z.B. so aus:


    Code
    |/home/popuser/spamfilter.pl
    /home/popuser/popboxen/example.org/spam_spa/Maildir/

    Nach (viel zu) langer Zeit habe ich mal wieder ein Update von pd-admin (von 4.23) und Standardumgebung (0.224) gemacht.


    Das System lief bereits unter dovecot 2.0.


    Mit den Hinweisen in Migration zu Dovecot hat die Umstellung aber grundsätzlich funktioniert :)


    Zusätzlich musste ich folgendes tun:
    - das Verzeichnis /var/qmail/simscan/.nfs-tmp hatte den falschen owner (root:simscan anstatt simscan:simscan)
    - pdadmin.conf umstellen auf $mail_delivery_agent = 'sieve22';
    - die bisherigen sieve Nutzer umstellen
    -- finden: find /home/popuser/popboxen/ -maxdepth 3 -name ".qmail" | xargs fgrep "dovecot"
    -- fixen: /usr/local/pd-admin2/dovecot-2.2/libexec/dovecot/deliver anstatt /usr/local/pd-admin2/libexec/dovecot/deliver


    Dazu meine Frage(n):
    Gibt es ein Script um alle .qmail Dateien auf den aktuellen Stand zu bringen?
    Ist die Zeile |/home/popuser/mailquotacheck.sh noch aktuell?


    *update*
    - In meiner Installation gibt es kein "httpd24.conf-template" -> wo ist das normalerweise enthalten?
    -- ich vermute mal in der Reihe 2 gar nicht...!?

    Ich hab das Problem jetzt auch durch djbdns gelöst.
    https://cr.yp.to/djbdns/run-cache.html


    Das hat den netten Nebeneffekt, dass die spamassasin URIBL wieder funktioniert, anstatt ständig solche Meldungen zu sehen :)


    Code
    URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
    See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-blockfor more information.

    Der Thread ist zwar schon ewig alt, aber wurde das nochmal aufgeklärt?
    Bewirkt der Schalter etwas? Oder muss ich qmail selbst mit dem nötigen Patch versorgen damit der ANY DNS Aufruf abgestellt wird?

    wenn ich die Scripte richtig überblicke sollte das auch funktionieren, wenn man vorher bereits mit ci2dc.sh auf dovecot2 umgestellt hatte.


    Hattest du das damals ausprobiert?
    Ich hänge noch auf einer pdadmin version < 4.24 und hatte vor zwei Jahren auf dovecot2 umgestellt (courier (ssl) -> dovecot ssl).


    Nun habe ich irgendwie "respekt" vor dem Update auf >= 4.24
    Läuft das? Muss ich vorher oder nachher noch manuell ran?

    Hatte sich das noch geklärt? Habe grad da gleiche Problem. Meine Vermutung ist, dass das von mir eingesetzte smtp-poplock im Zusammenspiel mit dovecot buggy ist.
    Ich benutze anscheinend noch Version 2.04 und in den Folge Versionen wurde was am logparsing getan.


    Hättest du auch dovecot und 2.04 am laufen?

    Zitat

    Um pd-admin mit HTTPS zu schuetzen, speichern Sie Ihr SSL-Zertifikat unter /opt/pdadmin/sslcerts/$hostname-{key,cert,cacert} ($hostname ist dabei der pd-admin-Hostname). Danach fuehren Sie das Skript /opt/pdadmin/bin/httpd_vhosts.pl aus.


    Das habe ich getan und mir damit (logischerweise) das bereits auf der Haupt-IP konfigurierte SSL-Zertifikat für einen Domain _deaktiviert_.


    Das dort so abgelegt Zertifikat taucht ja auch nicht in der Admin-Oberfläche auf, so dass man aufpassen muss, dass man kan Zertifikat auf die Haupt-IP konfiguriert. richtig(?)

    Umstellung courier (mit SSL) -> dovecot inkl. SSL
    - <HOSTNAME> durch eigenen Hostname ersetzen


    self-signed-cert generieren

    Code
    cd /opt/pdadmin/sslcerts/
    openssl req -x509 -newkey rsa:4096 -keyout <HOSTNAME>-key -out <HOSTNAME>-cert -days 2000 -nodes


    config dovecot
    vi /usr/local/pd-admin2/etc/dovecot.tmpl/conf.d/10-mail.conf

    Code
    namespace {
      prefix = INBOX.
      separator = .
      inbox = yes
    }


    vi /usr/local/pd-admin2/etc/dovecot.tmpl/conf.d/10-ssl.conf

    Code
    ssl = yes
    ssl_cert = </usr/local/pd-admin2/share/imapd.pem
    ssl_key = </usr/local/pd-admin2/share/imapd.key
    ssl_parameters_regenerate = 168
    ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL


    vi /usr/local/pd-admin2/etc/dovecot.tmpl/conf.d/15-lda.conf

    Code
    postmaster_address = postmaster@<HOSTNAME>
    hostname = <HOSTNAME>


    alte Services sichern

    Code
    mkdir /opt/backup/ci2dc
    cp -a /service/courier* /opt/backup/ci2dc/
    cp -a /service/qmail* /opt/backup/ci2dc/


    Code
    # ggf. alte pop3d/imapd.pem löschen
    rm /usr/local/pd-admin2/share/pop3d.pem
    rm /usr/local/pd-admin2/share/imapd.pem



    Wäre schön wenn es für den letzten Schritt noch ein Script geben würde...


    Dann für Thunderbird das Sieve Plugin besorgen:
    https://github.com/thsmi/sieve/tree/master/nightly


    Damit wäre dann die ganzen stunnel Gebilde hinfällig.
    Was ich sehr gut find, da ich grad selbst wieder auf eine stunnel Version < 4.45 reingefallen bin und mir für wenige Tage ein OpenRelay auf 465 gebaut hatte :(


    Da ich noch nicht so fit bin bzgl. dovecot.


    Gibt es sonst noch nützliche Konfigurationen bzgl. Sicherheit etc. in dovecot?