Posts by freedom

  • Latest MariaDB repo data seems to be incompatible with Debian 9

    Hi kess and Nuxwin,

    I checked the files from your instructions and did the following changes:

    I can confirm, your instructions work as expected and the problem from the first post seems to be related. I have now MariaDB 10.2.29 and no pending updates from apt update. Thank you very much.

    PS: In the instructions above, you used libmysqlclient18 instead of libmariadbclient18, thats why I was confused first. But after I saw the commit on GitHub I understood your instructions. Thank you both!

  • Latest MariaDB repo data seems to be incompatible with Debian 9

    Hello together,


    is there any known incompatibility with I-MSCP, Debian Stretch (9.11) and MariaDB 10.2? We're currently using MariaDB 10.1.41 from the first installation of I-MSCP on our new server. Now we would like to switch to MariaDB 10.2, using the autoinstaller, because it's a software requirement for one of our web services. I found this thread and a lot of information regarding i-mscp is compatible with MariaDB 10.2, but I would like to make sure there's no surprise waiting for me.

    So my questions would be:

    • Is this a real bug regarding debian stretch and i-mscp 10.2 or is this a local problem? Unfortunately there was no update since november 3rd.
    • I guess the switch would be going with the autoinstaller using perl imscp-autoinstall -dr sql. Is this correct?


    Thank you for any additional information.

  • Phpswitcher 5.0.5 Bug - Default php pool config and sockets gets deleted when creating a new customer

    Hello,


    since Phpswitcher plugin version 5.0.3 we had the same problem as described in PhpSwitcher 5.0.3 Problem, which got already fixed with version 5.0.4. But there was as second problem, which points at the default php version and not the ones added from the phpswitcher.


    I'll explain:

    Problem A - got resolved with 5.0.4:

    If using the apt-get upgrade the socks and pool configuration files from sites which used additional phpversions got removed and not created again. Therefore the sites failed with service 503. A simple perl /var/www/imscp/engine/imscp-rqst-mngr -v fixed this in the meantime and the problem got fixed entirely with Phpswitcher 5.0.4. But at the same time a Problem B existed.

    Problem B - exists since 5.0.3 and still in 5.0.5:

    When switching a site back to the default phpversion or when creating a new customer with default phpversion, the same problem from above now hits all pages wich are using the default php version. The command perl /var/www/imscp/engine/imscp-rqst-mngr -v is not able to fix this problem, but with a fast reconfiguration perl /var/www/imscp/engine/setup/imscp-reconfigure -danv this problem gets hotfixed aswell in the meantime. But it seems like there is still another problem hidden in the phpswitcher.

    For debugging help:

    • Create a new customer with default phpversion or switch one site back to the default phpswitcher with latest version Phpswitcher 5.0.5
    • The new customer got created successfully and the corresponding php-fpm process is restarted - in my case php7.1-fpm.
    • Only the pool configuration for the new or switched customer is created, every other page using the same phpversion, throws a service 503 error.
    • The apache2 error logs are helping - see:
    Code
    1. [Wed Oct 23 18:02:10.640520 2019] [proxy:error] [pid 27801:tid 139865844823808] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/php7.1-fpm-any.domain.de.sock (any.domain.de) failed
    2. [Wed Oct 23 18:02:10.640539 2019] [proxy_fcgi:error] [pid 27801:tid 139865844823808] [client REDACTED] AH01079: failed to make connection to backend: httpd-UDS, referer: https://any.domain.de
    • Using perl /var/www/imscp/engine/setup/imscp-reconfigure -danv to let i-mscp fix these problem.
    • Pool configurations and sockets for default php version gets recreated and every page is working again.


    Additional information:

    • Default PHP Version in use: PHP 7.1.32-1+0~20190902.23+debian9~1.gbp9d1be7 (cli) (built: Sep 2 2019 13:35:11) ( NTS )
    • I-MSCP Version: i-MSCP 1.5.3 Build: 2018120800 Codename: Ennio Morricone
    • OS: Debian 9.11 stretch
    • Phpswitcher Version: Current 5.0.5
    • Additional PHP version installed from package and used in phpswitcher: PHP 7.2.23-1+0~20191008.27+debian9~1.gbp021266 (cli) (built: Oct 8 2019 05:48:16) ( NTS )


    If there is any other question, I'm happy to answer and help to find the problem.


    Kind regards,

    freedom

  • clamav-milter issues after debian update

    Nuxwin


    I copy pasted the same content, my fault. I fixed the output above.


    Correct output of cat /etc/clamav/clamav-milter.conf is:


    And yes. The clamav plugin is installed and activated in i-mscp. It seems to work without any problems now. But I can confirm, that the clamav package update changed something in the config, it was displayed in the apt upgrade process. I think it was the milter configuration file.


    I can see that your clamav-milter.conf is different from mine.

  • clamav-milter issues after debian update

    Hi Nuxwin,


    You are right. I found the README file in the directory of the plugin.


    After restarting the clamav-daemon and the clamav-milter:


    Output of ls -la /run/clamav:

    Code
    1. ls -la /run/clamav
    2. total 4
    3. drwxr-xr-x 2 clamav root 80 Sep 11 17:34 .
    4. drwxr-xr-x 33 root root 1200 Sep 11 17:29 ..
    5. -rw-r--r-- 1 clamav root 5 Sep 11 17:34 clamav-milter.pid
    6. srw-rw-rw- 1 clamav clamav 0 Sep 11 17:34 clamd.ctl


    Output of ls -la /var/spool/postfix/clamav:

    Code
    1. ls -la /var/spool/postfix/clamav
    2. total 8
    3. drwxr-xr-x 2 clamav root 4096 Sep 11 17:34 .
    4. drwxr-xr-x 22 root root 4096 Apr 29 00:29 ..
    5. srw-rw-rw- 1 clamav clamav 0 Sep 11 17:34 clamav-milter.ctl


    Output of cat /etc/clamav/clamd.conf:


    Output of cat /etc/clamav/clamav-milter.conf:


    The weird thing now is:


    The previous problem described by fulltilt and myself does not show again after the current restart, but did before. See:




    Output of tail -f /var/log/clamav/clamav-milter.log after the update until now:

    Code
    1. tail -f /var/log/clamav/clamav-milter.log
    2. Wed Sep 11 02:00:19 2019 -> WARNING: No clamd server appears to be available
    3. Wed Sep 11 02:15:53 2019 -> +++ Started at Wed Sep 11 02:15:53 2019
    4. Wed Sep 11 02:15:53 2019 -> WARNING: No clamd server appears to be available
    5. Wed Sep 11 02:16:52 2019 -> WARNING: No clamd server appears to be available
    6. Wed Sep 11 02:45:07 2019 -> +++ Started at Wed Sep 11 02:45:07 2019
    7. Wed Sep 11 02:45:07 2019 -> WARNING: No clamd server appears to be available
    8. Wed Sep 11 17:32:46 2019 -> +++ Started at Wed Sep 11 17:32:46 2019
    9. Wed Sep 11 17:32:46 2019 -> WARNING: No clamd server appears to be available
    10. Wed Sep 11 17:34:33 2019 -> +++ Started at Wed Sep 11 17:34:33 2019


    The latest restart at 17:34:33 2019 - right before I started to check everything again - seems to fixed the problem itself, because the previous error WARNING: No clamd server appears to be available isn't there anymore.

  • clamav-milter issues after debian update

    Hi again,


    DrCarsonBeckett: We did not change the config ourselves. The clamav package got updated on debians side and therefore it got updated with an apt-get upgrade (or apt upgrade). And as fulltilt already said, on some systems - an this should be the usual case - the system detects your config and asks if you want to use the new version or your currently using version of the configuration. Additional, you have the option to show the difference and check for yourself.


    But this was not the case in some updates from fulltilt and it was not the case in my update. In these updates the question never got asked and the config is overridden by the clamav package itself. Reinstall from the clamav plugin doesn't solve this and as written above, the latest clamav update seems to be not fully compatible with the latest plugin version.


    I can confirm that it's somewhat still working, but from time to time the error will be shown in the log.


    So the question would be:


    Nuxwin What is the correct way to handle this, until the new clamav plugin, which will be not free anymore, will be released? Should we stay in this situation until then, disable the clamav plugin, or is there any fix for the moment? Unfortunately the clamav readme from the i-mscp plugin is removed, therefore I wasn't able to check and fix the config change myself.


    I still do not understand why the package update did not ask for the config change. For instance: The last update asked for exact the same case, when we updated e.g. the telegraf package. And since you usually have the option: Check the difference between the two and decide which config to use, you can protect yourself from any problems and add new configuration parts for yourself later.


    The weird thing is, that the first error, which also appeared in the mail.err log file, is not there anymore so clamav seems to work for the moment.

  • clamav-milter issues after debian update

    Hi fulltilt,


    I just updated my Debian Stretch server and have the same problem with clamav after the update finished.

    Were you able to solve the problem on your server?


    Unfortunately, the clamav readme - from the no longer supported plugin - got removed on github, so I would like to know if someone was able to fix this. Seems to be a compability problem with the newest clamav update and the plugin configuration.


    Kind regards.

  • Typo in command changed ownership of files in /var. Can I-mscp fix this?

    Hello guys,


    unfortunately in between a server migration a typo in a command changed the ownership of all files in /var to root:root, so of course we got some problems now and the main problem is, that i-mscp stopped working completely. Is i-mscp able to fix file permissions with this packages (e.g. mysql/mariadb apache etc.), or do I need to reinstall the whole server because of this?


    It's really a bad thing, because we nearly finished the migration and then an unfortunately typo crashed nearly everything connected with /var. Any ideas how I could fix that?


    OS: Debian 9.8 Stretch

    I-MSCP Version: 1.5.3 (2018120800)


    Kind regards,

    freedom