Clamav with axigem VM

I recently installed the VM community version of Axigen as a VM in proxmox using other online guidelines. Its working good behind a HAPROXY and works pretty well even with automigration. But fixing ClamAV seems to be problem for me.

The standard Ubuntu repository Ubuntu install only generated “Could not connect” in Axigen webgui (even after installing clamav in the deamon). Even follow all the guides about /var/run/clamav/clamd.ctl availbility… this does not restart or show as Availble in axigen Webgui.

I managed to fix this by installing ClamAV from deb package from ClamAV directly. After reboot it stops working again.

i tried…

  1. checked patchs given in /etc/clamav *.conf that users have access
  2. Add clamav into axigen group
    3 . Start clamav as user axigen
    Still not working…
    Maybe not related to axigen, but how clamav works with axigen.
    Anything is appreciated…
    Thank you.

Oh, I’m running the virtualbox VM download thats installs on Ubuntu 22.04 with free license. But this is not making sense… I followed the KB article how to install ClamAV-daemon and freshclam. The only difference is that I managed to get it to run on 1.2.0 version of ClamAV with upgrade from ClamAV themselves.

I can only now see that either is my axigen broken, or there is a bug in Axigen, or if any depencies broken somewhere…

  1. ClamAV is running fine, on 127.0.0.1:3310 with recommended settings from KB.
    - Socket file is not needed, but I tried with or without it. No difference.
    - TCPAddr 127.0.0.1 → clamd.conf
    - TCPSocket 3310 → clamd.conf
    - Clamav-daemon and Freshclam run as user axigen update and scan as they should
    - clamav folders set “chowned” to axigen user.
  2. VM has ufw turned off (this is inside my LAN anyway)
  3. “netstat lnp | grep 3310” shows clamd listen on port 3310
  4. axigen.cfg file show filter is i believe correct and indeed supposed to use correct port "address = “inet://127.0.0.1:3310”
  5. apparmor has accepted the queue scan directory with edit in the apparmor file, but it doesn’t work with apparmor turned off anyway.
  6. I can telnet directly towards 127.0.0.1 port 3310… PING answers PONG and session close
  7. clam-av.afsl looks normal to me…

Still, Axigen insist, clamav filter is “not available” in webadmin and if i try to enable it, incoming mails got reverted to the queue. I disable the clamav in webadmin and “retry” in queue and the emails arrives.

I have spent hours and hours… over several days on this… axigen logfile says afsl file is loaded… that’s it. Tried add log for filter but nothing is there.
“axigen WEBADMIN:000030E0: Filter ClamAV loaded from file /opt/axigen/afsl/clam-av.afsl”

Hello,

Without some extra Axigen logs we could not guess where is exactly the problem.

Thus, please increase PROCESSING log level to Protocol Communication and login into WebAdmin so the status of all filters will be re-checked.

Post here the PROCESSING logs generated at that time - you should see some log lines related to delivery test messages (that will be discarded) for random “filterDetect” accounts (one for each existing filter).

HTH,
Ioan

PS: This is how it should look for ClamAV filter (example taken from one of our test instalations running Ubuntu 22) - let’s see what we see for your specific case

2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Shepherd thread received signal for processing
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Set recipient <filterDetect-002D5CDA@~filter-test> state to RECEIVED
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Set mail state to PROCESSING
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Start processing mail
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Set recipient <filterDetect-002D5CDA@~filter-test> state to PROCESSING
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Start filter <filterDetect-002D5CDA>
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Processing started
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Shepherd thread finished processing signal
2023-10-09 07:12:06 +0000 16 mini PROCESSING:002D5CDA: >> SCAN
2023-10-09 07:12:06 +0000 16 mini PROCESSING:002D5CDA: >> /var/opt/axigen//queue/2D/D5CDA.00
2023-10-09 07:12:06 +0000 16 mini PROCESSING:002D5CDA: << /var/opt/axigen//queue/2D/D5CDA.00: OK
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Filter ClamAV(127.0.0.1:3310):[PASS]: OK
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Finished filtering mail object 2D5CDA with filter: <filterDetect-002D5CDA>
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Set recipient <filterDetect-002D5CDA@~filter-test> data version to 1
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Set recipient <filterDetect-002D5CDA@~filter-test> state to PROCESSING
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Start filter discarder
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Finished filtering mail object 2D5CDA with filter: discarder
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Set recipient <filterDetect-002D5CDA@~filter-test> state to FILTER DISCARD
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Set recipient <filterDetect-002D5CDA@~filter-test> state to SENT
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Set mail state to PROCESSED
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Processing finished
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Shepherd thread received signal for delivery
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Shepherd thread finished delivery signal
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: No recipient is ready for delivery
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Set mail state to SENDING
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Delivery attempt completed for mail 2D5CDA; schedule for cleanup
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Set mail state to SENT
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Shepherd thread received signal for cleanup
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Start mail cleanup
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Mail removed from queue
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Set mail state to REMOVED
2023-10-09 07:12:06 +0000 08 mini PROCESSING:002D5CDA: Shepherd thread finished cleanup signal

Thank you for you answer… My issue was eventually found to be quite simple.
As I first installed repository ClamAV 0.103.9 which was NOT working at all as described above (I believe ClamAV in repository is actually v 1.03-9). I removed the installation and installed the deb package for 1.2.0 from ClamAV homepage. I could start “clamd” from console and it worked, but with systemd it didn’t, even ClamAV itself happily reported running fine even with testing with telnet it responded.

Well, the (a bit embarrassing) root cause…
was that my startup files in systemd was pointing at the old version which was not properly removed. Fixing the path in /usr/lib/systemd/system/clamav-daemon.service file to point at 1.2.0 version and it worked.

Conclusion…
Axigen does not work with Clamav from repository. Properly remove any repo version and Install the deb from ClamAV homepage. Update the path to the clamd file systemd in /usr/lib/systemd/system/clamav-daemon.service, run “systemctl daemon-reload”. Done.