Posts by c64wolf

    Courier Auth seems to be broken after upgrade. I am sure I did try it once and it worked as I did document trying that, but now every time I restore the test container to the state it was after jessie and i-mscp upgrade was installed, the courier auth logs just this when trying to send email through smtp auth:
    Jun 21 17:20:26 web postfix/smtpd[3186]: warning: SASL authentication failure: cannot connect to Courier authdaemond: No such file or directory
    Jun 21 17:20:26 web postfix/smtpd[3186]: warning: xxxxxxxxxx.x.fi[xx.xx.xx.xx]: SASL LOGIN authentication failed: generic failure

    Here is my master.cf

    Code
    1. web:~# cat /etc/postfix/master.cf# POSTFIX(1) master(5) configuration file - auto-generated by i-MSCP# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN## ==========================================================================# service type private unpriv chroot wakeup maxproc command + args# (yes) (yes) (yes) (never) (100)# ==========================================================================smtp inet n - y - - smtpdsubmission inet n - y - - smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,rejectsmtps inet n - y - - smtpd -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,rejectpickup fifo n - y 60 1 pickupcleanup unix n - y - 0 cleanupqmgr fifo n - n 300 1 qmgrtlsmgr unix - - y 1000? 1 tlsmgrrewrite unix - - y - - trivial-rewritebounce unix - - y - 0 bouncedefer unix - - y - 0 bouncetrace unix - - y - 0 bounceverify unix - - y - 1 verifyflush unix n - y 1000? 0 flushproxymap unix - - n - - proxymapproxywrite unix - - n - 1 proxymapsmtp unix - - y - - smtprelay unix - - y - - smtp -o smtp_fallback_relay=showq unix n - y - - showqerror unix - - y - - errorretry unix - - y - - errordiscard unix - - y - - discardlocal unix - n n - - localvirtual unix - n n - - virtuallmtp unix - - y - - lmtpanvil unix - - y - 1 anvilscache unix - - y - 1 scacheimscp-arpl unix - n n - - pipe flags=O user=vmail:imscp argv=/var/www/imscp/engine/messenger/imscp-arpl-msgr $recipientmaildrop unix - n n - - pipe flags=DRhu user=vmail:mail argv=maildrop -w 90 -d ${user}@${nexthop} ${extension} ${recipient} ${user} ${nexthop} ${sender}


    And here is main.cf



    Container arch is i386.

    For the record, The SMTP auth did work after spamassassin installation, but for some reason it did meltdown as documented. Could not find anything else that would be useful in the logs.


    Also, I seem to have had amavis/spamassassin/clamav installed as leftover but as far as I know I have never configured those before installing the plugin. I just installed them with the intention to configure them sometime later (this was when the server as based on ispcp, long time ago!)

    Hello,


    My current setup is as follows:
    I-MSCP 1.4.6
    Debian Jessie 8.8
    SpamAssassin plugin 1.2.0


    I just installed the SpamAssassin plugin according to the plugin wiki and at first it seemed to work. I saw the spamassassin score in all received emails' headers. Now the headers just show X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on web.example.com but no score row, in spite of the email message. The same happens on regular email and GTUBE test email. I assume this is not normal behaviour? Shouldn't the GTUBE email be marked as *** SPAM ***?


    Here are the logs of the time period (grepped spamd from mail.log):
    http://pastat.fi/2259


    The email from this row shows the score in the email header when looking at email source code:
    Jun 21 13:05:39 web spamd[27657]: spamd: result: . 0 - FREEMAIL_FROM,HTML_MESSAGE,SPF_HELO_PASS,SPF_PASS scantime=4.1,size=6556,[email protected],uid=113,required_score=5.0,rhost=web.example.com.local,raddr=127.0.0.1,rport=59896,mid=<VI1PR0501MB3598DDA5B4525E88960503D8E8DA0@VI1PR0501MB3598.eurprd05.prod.outlook.com>,autolearn=ham autolearn_force=no


    However, this email from another free mail provider shows no score in source, just the X-Spam-Checker-Version:
    Jun 21 13:57:48 web spamd[29638]: spamd: result: . 0 - scantime=0.4,size=3753,[email protected],uid=113,required_score=5.0,rhost=web.example.com.local,raddr=127.0.0.1,rport=60014,mid=<[email protected]>,autolearn=ham autolearn_force=no


    I am new to SpamAssassin. On server side I am more accustomed to postgrey + client side spam filtering. Now trying to move from postgrey/clientside to SpamAssassin. I am not using roundcube at all on the server. I have i-mscp configured only with RainLoop. I am using default config.php for the SpamAssassin plugin.


    /var/log/mail.err looks like this:

    Code
    1. Jun 21 13:04:35 web spamass-milter[27678]: spamass-milter 0.3.2 startingJun 21 13:05:35 web spamass-milter[27678]: Could not retrieve sendmail macro "i"!. Please add it to confMILTER_MACROS_ENVFROM for better spamassassin resultsJun 21 14:23:50 web spamass-milter[1952]: spamass-milter 0.3.2 startingJun 21 14:24:34 web spamass-milter[1528]: spamass-milter 0.3.2 startingJun 21 14:32:34 web spamass-milter[1528]: Could not retrieve sendmail macro "i"!. Please add it to confMILTER_MACROS_ENVFROM for better spamassassin resultsJun 21 14:37:46 web spamass-milter[3480]: spamass-milter 0.3.2 startingJun 21 15:18:13 web spamass-milter[3480]: Could not retrieve sendmail macro "b"!. Please add it to confMILTER_MACROS_ENVRCPT for better spamassassin results


    /var/log/mail.warn looks mostly like this, I assume that the rows are just failed bruteforce attempts at the smtp auth, but now that I checked I do not seem to be able to connect with legitimate accounts either to smtp auth. This situation is probably related to the installation of the spamassassin plugin as the server has been running fine for more than 8 hours before the install:



    Code
    1. Jun 21 14:41:24 web postfix/smtpd[3597]: warning: SASL authentication failure: cannot connect to Courier authdaemond: No such file or directory
    2. Jun 21 14:41:24 web postfix/smtpd[3597]: warning: unknown[80.82.77.xx]: SASL LOGIN authentication failed: generic failure
    3. Jun 21 14:46:47 web postfix/smtpd[3610]: warning: SASL authentication failure: cannot connect to Courier authdaemond: No such file or directory
    4. Jun 21 14:46:47 web postfix/smtpd[3610]: warning: unknown[80.82.77.xx]: SASL LOGIN authentication failed: generic failure
    5. Jun 21 14:52:07 web postfix/smtpd[3617]: warning: SASL authentication failure: cannot connect to Courier authdaemond: No such file or directory
    6. Jun 21 14:52:07 web postfix/smtpd[3617]: warning: unknown[80.82.77.xx]: SASL LOGIN authentication failed: generic failure

    Any help or advise is appreciated. :)

    Thanks for the reply Nuxwin! Nice to see that there really was a bug in apparmor. Today I tried again to upgrade production to Jessie (and I-MSCP 1.4.6) and this time so far I have not observed the maildrop issue. What I did differently was making sure that systemd was not pulled in by the upgrade.


    Before Debian upgrade process I made sure that systemd is not pulled in by creating a file /etc/apt/preferences.d/local-pin-init

    Code
    1. Package: systemd-sysvPin: release o=DebianPin-Priority: -1


    Then I performed the distribution upgrade as standard:


    Code
    1. sed -i 's/wheezy/jessie/g' /etc/apt/sources.listapt-get updateapt-get upgradeapt-get dist-upgradeapt-get install -f

    Then before upgrading i-mscp I ran following commands:


    Code
    1. service apache2 stop
    2. pkill -KILL -f apache2
    3. apt-get --assume-yes --auto-remove purge apache2*
    4. rm -f /usr/lib/apache2/modules/mod_proxy_fcgi.so
    5. dpkg-divert --rename --remove /usr/lib/apache2/modules/mod_proxy_fcgi.so
    6. rm -rf /etc/apache2 /usr/lib/apache2 /var/lib/apache2

    And performed all things as required by i-mscp upgrade process and errata.



    So far I have tested that emails seem to work, websites work, and FTP works.


    I have not yet reactivated plugins (defaultpage, postgrey).


    Only odd thing I see in the logs is:
    Jun 21 01:26:19 webhost imapd-ssl: couriertls: /etc/imscp/imscp_services.pem: error:0906D06C:PEM routines:PEM_read_bio:no start line

    Thanks for testing. :)
    So you were using sysvinit in the container? Installing a brand new jessie from template is not the same as upgrading a container with i-mscp from wheezy to jessie. By default, the upgrade process pulls systemd into the container. Perhaps that could have caused the issue with apparmor and maildrop? I believe that whatever apparmor blocked caused the maildrop segfault. I will try the upgrade process again when 1.4.4 is released and next time I will configure the container so that systemd is not installed in the upgrade process.

    @c64wolf


    I'll do a test as soon as possible.

    Thanks Nuxwin! :) It seems that I have not received any emails from the period when the segfaulting started to happen, which would possibly indicate that the emails not delivered were in mail queue. Luckily I have a snapshot of the faulty upgraded container which I can use to restore the emails from the queue. I will need to investigate if I can just copy the queue over to the respective directory in the working container to have the mails delivered through proper path to mailboxes.

    Restoring the container from backup made everything work again (Wheezy, I-MSCP 1.3.16), so the issue resides somewhere in the upgrade process. Either Jessie works differently from AppArmor point of view or there is a configuration issue somewhere. During the upgrade process I did have to purge old apache and php packages to make the install work. Other than that the upgrade was standard (stop imscp_panel and imscp_daemon, change apt sources list entries to jessie, apt-get update && apt-get upgrade && apt-get dist-upgrade, apt-get install -f, apt-get autoremove, and upgrade of imscp by standard procedure).