LXC - I-MSCP 1.4.x - Debian Wheezy to Jessie

  • @c64wolf


    I'll do a test as soon as possible.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • @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.

  • @c64wolf


    I cannot confirm your problems with proxmox 4.4-13 and a fresh i-MSCP installation through our development branch (1.4.x). There are no maildrop's segfault. I can send/receive mails to/from outside-world.


    You should make sure to update your container correctly. Best is to wait for i-MSCP 1.4.4 version.


    In order, I've done the following:

    • I've updated my proxmox to version 4.4-13 using the deb http://download.proxmox.com/debian jessie pve-no-subscription repository
    • I've created a new container using latest debian template
    • I've installed new i-MSCP instance in the container, following the howto available at i-MSCP inside a LXC container (Managed by Proxmox 4.4)
    • I've created a reseller and a customer
    • I've created a mail account

    RESULT


    I've been able to send and receive mail to/from outside-world






    Note that init system was SysVinit (default).

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • 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.

  • May 19 16:09:01 web kernel: [335147.880658] audit: type=1400 audit(1495199341.753:872): apparmor="DENIED" operation="file_lock" profile="lxc-container-imscp" pid=26284 comm="(ionclean)" family="unix" sock_type="dgram" protocol=0 addr=none

    This message has nothing to do with your maildrop segfaults. It comes from the phpsessionclean service that cannot start due to the new network namespace requirement (PrivateNetwork=true in the /lib/systemd/system/phpsessionclean.service file) and that can't be setup without the SYS_ADMIN capability and network permissions (apparmor). I need to investigate this issue because normaly you have already the SYS_ADMIN capability and the network permissions (apparmor).


    Edit: This is a bug in apparmor. See https://bugs.launchpad.net/ubu…rce/apparmor/+bug/1575779


    However, note that the phpsessionclean service is not needed with i-MSCP. Therefore, you can safetely disable it:

    Shell-Script
    1. # systemctl stop phpsessionclean.timer
    2. # systemctl disable phpsessionclean.timer
    3. # systemctl mask phpsessionclean.timer
    4. # systemctl mask phpsessionclean.service
    5. # reboot

    For the rest, I'll do some tests with systemd.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • 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

  • Installed the defaultpage plugin and spamassassin (with default configuration). Still no sight of maildrop segfault.

  • 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

  • Thread closed for the same reasons as explained here: SpamAssassin not blocking GTUBE test email

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206