Posts by fulltilt

    I use a small hetzner cloud server for development purposes ...

    now I have added a FLOATING IP in /etc/network

    https://docs.hetzner.com/cloud…persistent-configuration/


    afterwards I run i-mscp setup with the new floating IP, it works and is shown as eth0:2 in ifconfig ...


    how should it look in the panel configuration under server IP addresses?

    It still shows eth0 for the new IPaddress, should it be set to eth0:2 instead eth0 or can I keep default eth0?

    So aus der Ferne scheinen mir alle E-Mails von extern zu stammen, ausser, die I-MSCP-Plugins hätten sich bei Dir in einer anderen Reihenfolge installiert. Spamassassin kommt ja (oder sollte) vor OpenDKIM kommen. Und Spamassassin erkennt hier eine DKIM-Signatur: DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF


    Wie hast Du hostkarma derzeit eingebunden? Ich setze die RBL nicht in Spamassassin ein, sondern in Postfix/Postscreen. Wobei ich Hostkarma nicht einsetze.


    ich meine auch das Problem wurde durch die DNSBL checks in SA verursacht, bis jetzt sehe ich nichts auffälliges ...


    hier mal das vorige DNSBL setup

    Code
    1. #/etc/spamassassin/init.pre
    2. loadplugin Mail::SpamAssassin::Plugin::URIDNSBL

    skip_rbl_checks 0 in der local.cf und der settings table vom Plugin


    die Situation scheint sich zu bessern, lag wohl an dem aktivierten DNSBL check, hier sind noch ein paar eigenartige, scheint sich um Weiterleitungen zu handeln

    Code
    1. spamd: result: Y 8 - DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,LIST_UNSUBSCRIBE,SPF_HELO_PASS,SPF_PASS,T_REMOTE_IMAGE,URIBL_BLACK scantime=0.4,size=60407 [...] required_score=7.0,rhost=localhost,raddr=127.0.0.1,rport=/var/run/spamassassin.sock,mid=<2ptg6qev1wgp7nt4gl6El_dsFV9SluHGR4c9q0ALgpdBZaG4vS9asm2SP0XJVVQ@ip10.rp02.net>,autolearn=disabled
    2. und diese hier vermutlich der autoresponder
    3. spamd: result: Y 9 - AWL,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS,HTML_IMAGE_RATIO_02,HTML_MESSAGE,SPF_HELO_PASS,SPF_PASS,URIBL_GREY,WEIRD_PORT scantime=0.6,size=20475 [...] required_score=7.0,rhost=localhost,raddr=127.0.0.1,rport=/var/run/spamassassin.sock,mid=<iSYhEZCa9HscuHP9Nc6nxszR4haHZJjWUpBc6XDfk@localhost.localdomain>,autolearn=disabled
    4. spamd: result: Y 9 - AWL,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS,HTML_IMAGE_RATIO_02,HTML_MESSAGE,SPF_HELO_PASS,SPF_PASS,URIBL_GREY,WEIRD_PORT scantime=0.2,size=20849 [...] required_score=7.0,rhost=localhost,raddr=127.0.0.1,rport=/var/run/spamassassin.sock,mid=<BmTIQln3SWsABGmQlc4FD0rjFAn51inDkRzCGgXMrg@localhost.localdomain>,autolearn=disabled

    die beiden letzten sind interessant localhost.localdomain existiert nicht in den configs, nehme mal an es war eine Attacke und der autoresponder ist hier aktiv

    Danke, gute Idee ich checke das nachher mal ... hab gestern das DNSBL mal rausgenommen aus der local.cf und die settings in der table wieder auf skip_rbl_checks 1 gesetzt.

    Ich poste später etwas vom Output, muss gerade dringend ein Web umziehen ;-)

    I was able to solve the problem!

    Yesterday there were two upgrades via sury.org ...

    I guess something went wrong due to an incorrect dependency list from sury

    after the update it showed:

    Code
    1. The following packages were automatically installed and are no longer required:
    2. php5.6-imagick php7.0-apcu-bc php7.0-imagick php7.1-apcu-bc php7.1-imagick php7.2-apcu-bc php7.2-imagick php7.3-apcu-bc
    3. php7.3-imagick php7.4-imagick php7.4-imap

    after I reinstalled php7.0-apcu-bc and php7.0-apcu it works, no more zend files are generated when the panel URL is visited by a browser


    I feel a little better now ;-)

    before yesterday's PHP update I only saw these zend files once generated in the cache ... now these files are generated when the login page is vsited by a webbrowser


    also group permission shows that any customer and mail is a member of the vu2000 group

    is that really correctly?

    Code
    1. # grep 'vu2000' /etc/group
    2. mail:x:8:vu2000
    3. imscp:x:1002:vmail,vu2000
    4. vu2000:x:1003:www-data
    5. vu2009:x:1004:www-data,vu2000
    6. vu2010:x:1006:www-data,vu2000
    7. vu2011:x:1007:www-data,vu2000
    8. # groups vu2000
    9. vu2000 : vu2000 mail imscp vu2009 vu2010 vu2011

    No worries, fulltilt!


    The files are owned by vu2000 and 400 (u+rw). No one else beside vu2000 and root can read these files (beside you allowed someone). They are necessary for caching. If you switch caching off, they won't be generated.

    OK, the files are owned by vu2000:vu2000 but the permission mode is 0600 (rw)

    everything is stored inside ... all configs, keys, passwords everything