Posts by freedom

    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.

    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.

    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.

    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.

    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

    Hello again,


    as Nuxwin stated here, I updated the i-mscp instance to the new build number, while a new error occured.


    Distro: Debian Jessie 8.7

    I-MSCP Version: 1.5.3 (error with newest build number in the last step)


    In the last step of the updating process, the installer aborted with the following error.


    Code
    1. [ERROR] main::setupDbTasks: Modules::ServerIP::add: Failed to get unit file state for networking.service: No such file or directory at /usr/local/src/imscp-1.5.3-2018120800/engine/PerlLib/iMSCP/Provider/Service/Debian/Systemd.pm line 64.
    2. ...propagated at /usr/local/src/imscp-1.5.3-2018120800/engine/PerlLib/iMSCP/DbTasksProcessor.pm line 496.
    3. [ERROR] autoinstaller::Functions::install: An error occurred while performing installation steps


    Didn't had such problems before. And we don't want to update to Debian Stretch, because we're already setting up an new server with the newest Debian and I-MSCP Version. We just want to update the old one, as stated from Nuxwin , to prevend any more complications while we're migrating our pages and projects one by one. The error points to an missing file in the update folder, is this correct?


    Kind regards,

    freedom

    I was able to find and fix the error. We removed one customer with the Domain ID 21 some weeks ago, without revoking the certificate before. We thought that the certificate would be removed aswell and everything was working until today.


    The above cert_id 98 was aimed to domain_id 21, which was deleted some time ago and because of that i-mscp responds correctly with an error. After removing the not needed cert_id 98 from the table ssl_certs, which had the status "toadd", we were able to restart everything and everything works now.


    We can start again to migrate our customers to the new server with i-mscp now.

    I don't know if its a bug, or was just a problem on our side with the not removed mysql entry from the not needed ssl cert after removing the corresponding domain, so I thought I give the answer here aswell.

    The problem is solved.

    Hello,


    today we want to move one customer account to a new one, because of migration progresses in our company. I-MSCP got stucked while adding the new domain and we tried to reconfigure imscp to check where a problem is, or the problem is already fixed with that. Unfortunately, the problem is still existing and the reconfiguration failed.


    After we searched the logs and checked a Let's encrypt renewal log, it seems that there was already a problem, which causes the problem now aswell.


    Log from the renewal:

    Code
    1. [Sat Jan 12 00:00:15 2019] [error] main: Couldn't process Let's Encrypt renewal tasks: Modules::SSLcertificate::_loadData: DBD::mysql::db do failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FROM ssl_certs WHERE cert_id = '98'' at line 1 at /var/www/imscp/gui/plugins/LetsEncrypt/cron/../../../../engine/PerlLib/Modules/SSLcertificate.pm line 256.
    2. ...propagated at /var/www/imscp/gui/plugins/LetsEncrypt/cron/../../../../engine/PerlLib/iMSCP/DbTasksProcessor.pm line 496.


    Log from todays reconfigure:

    Code
    1. [Sat Jan 12 17:15:18 2019] [error] main::setupDbTasks: Modules::SSLcertificate::_loadData: DBD::mysql::db do failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FROM ssl_certs WHERE cert_id = '98'' at line 1 at /var/www/imscp/engine/setup/../PerlLib/Modules/SSLcertificate.pm line 256.
    2. ...propagated at /var/www/imscp/engine/setup/../PerlLib/iMSCP/DbTasksProcessor.pm line 496.

    Both errors are pointing to an MYSQL Syntax Error with cert_id 98. We already tried to investigate but could not find the problem yet.


    Does anyone have an idea why the plugin is not able to do it's work? Everything worked before that point.


    Thank you for your time.