[Indimail-support] clamd removed from IndiMail package

[A. Offerman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Thanks for removing clamd/freshclam from the IndiMail package: it had
always been interfering with the clamd package on CentOS: causing
dyn.libs from the IndiMail install to be called from
/usr/bin/freshclam (causing library version conflicts), and ownership
conflicts (clam vs. clamav) of /var/log/clamav/freshclam.log

I'm not sure whether this should have been a minor update, since I had
to find out the hard way clamd was gone %-)

The messages logged from the SMTP daemons:
"qq unable to run QHPSI scanner (#4.3.0) (temporary)"
caused by /var/indimail/bin/clamdscan (and
/var/indimail/bin/freshclam) no longer being available.

So I edited these QHPSI variable files:
/service/fetchmail/variables/QHPSI
/service/qmail-smtpd.25/variables/QHPSI
/service/qmail-smtpd.465/variables/QHPSI
/service/qmail-smtpd.587/variables/QHPSI
setting the scanner to: /usr/bin/clamdscan (was:
/var/indimail/bin/clamdscan).
(vim `grep -l clam /service/*/variables/*`)

Then I disabled the clamd and freshclam services:
touch /service/clamd/down
touch /service/freshclam/down
service indimail restart
var/indimail/bin/svstat /service/*

And re-enabled the original clamd:
service clamd status
chkconfig --list clamd
chkconfig clamd on
service clamd start

Run clamdscan and freshclam by hand to make sure they are running
without any problems.
In my case I had to restore the original /etc/cron.daily/freshclam and
/etc/logrotate.d/clamav files.

Hope this can be of help to others.


And finally a question: what is the best way to deal with all these
configuration parameters? The outdated path to the clamd/freshclam
binaries is still in the run scripts /service/*/run and in the
configuration files /var/indimail/etc/*
Should I re-run a configuration script? Which one? And if I do: will
the changes I made to the variable files /service/*/variables/* be
overwritten/lost?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJTU7ZVAAoJECfzYtonqXzEYBIH/2dzKjr+dflFauFm2Buv02NF
uM9/ropcG3HYcIioLLXspgg5/34CSDqDAJVfdw7jgBwIVc+TKl0olp2iCZwkQwbD
F0Vfp+Ikk/Zzwy8WCMXIIsGbBcqmWjNapM06T2jYIBwrP8f4664oGVzFsYntArkK
/X0JklF4KN5Y4v5A0FSIWd0LQAIp+Z4PJ8HaFcBMKmb0zCiUS5y3XeRERtz2HRy/
/ucF/wfIm3UdSrnEnzrQGbteYG8t2Erm0cJoixEa6xnXJsriDaWyRF27sffFuCDG
yN14YYTA1WuyXOXicXZemJyAuiWaclYdvb1mYuwdD7a3bxAwZOr5Eqvj36M4P/A=
=x9gq
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
Indimail-support mailing list
Indimail...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/indimail-support

[Manvendra Bhangui]

On Sun, Apr 20, 2014 at 5:28 PM, A. Offerman <adr...@offerman.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Thanks for removing clamd/freshclam from the IndiMail package: it had
always been interfering with the clamd package on CentOS: causing
dyn.libs from the IndiMail install to be called from
/usr/bin/freshclam (causing library version conflicts), and  ownership
conflicts (clam vs. clamav) of /var/log/clamav/freshclam.log

I'm not sure whether this should have been a minor update, since I had
to find out the hard way clamd was gone %-)

Yes. I removed clamav package as indimail kept on getting outdated with every new release of clamav package.

For a new installation, this is not an issue as the svctool command will recreate the service with the correct path in QHPSI. For upgrade however it is best to just use svctool to recreate the SMTP/fetchmail services. You also need to update QHPSI in /var/indimail/control/defaultqueue/QHPSI. Else qmail-inject will have an issue injecting emails.

Yes this definitely will be helpful to all users. Thank you.

 

And finally a question: what is the best way to deal with all these
configuration parameters? The outdated path to the clamd/freshclam
binaries is still in the run scripts /service/*/run and in the
configuration files /var/indimail/etc/*
Should I re-run a configuration script? Which one? And if I do: will
the changes I made to the variable files /service/*/variables/* be
overwritten/lost?

Any custom changes that you have made to variables will be lost if you re-run svctool. The best method is to edit /service/*/variables/QHPSI and edit /service/clamd/run, /service/freshclam/run (remember that -f option in freshclam installed in CentOS does not work). Make sure that you have Foreground option enabled in /etc/freshclam.conf and /etc/clamd.conf.

[Manvendra Bhangui]

On Sun, Apr 20, 2014 at 5:28 PM, A. Offerman <adr...@offerman.com> wrote:

And finally a question: what is the best way to deal with all these
configuration parameters? The outdated path to the clamd/freshclam
binaries is still in the run scripts /service/*/run and in the
configuration files /var/indimail/etc/*
Should I re-run a configuration script? Which one? And if I do: will
the changes I made to the variable files /service/*/variables/* be
overwritten/lost?

This just gave me an idea for the next release. A new option --warn, --no-overwrite to svctool that will warn/preserve variables that have been customized. 

[A. Offerman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/20/2014 04:50 PM, Manvendra Bhangui wrote:
> On Sun, Apr 20, 2014 at 5:28 PM, A. Offerman <adr...@offerman.com
> <mailto:adr...@offerman.com>> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>
>
> Thanks for removing clamd/freshclam from the IndiMail package: it
> had always been interfering with the clamd package on CentOS:
> causing dyn.libs from the IndiMail install to be called from
> /usr/bin/freshclam (causing library version conflicts), and
> ownership conflicts (clam vs. clamav) of
> /var/log/clamav/freshclam.log
>
> I'm not sure whether this should have been a minor update, since I
> had to find out the hard way clamd was gone %-)
>
>
> Yes. I removed clamav package as indimail kept on getting outdated
> with every new release of clamav package.
>
> For a new installation, this is not an issue as the svctool command
> will recreate the service with the correct path in QHPSI. For
> upgrade however it is best to just use svctool to recreate the
> SMTP/fetchmail services. You also need to update QHPSI in
> /var/indimail/control/defaultqueue/QHPSI. Else qmail-inject will
> have an issue injecting emails.

Thanks! I was unaware of that directory before when editing DKIMSIGN,
DKSIGN, SPAMEXITCODE and SPAMFILTER. So that's corrected now as well.

> And finally a question: what is the best way to deal with all
> these configuration parameters? The outdated path to the
> clamd/freshclam binaries is still in the run scripts /service/*/run
> and in the configuration files /var/indimail/etc/* Should I re-run
> a configuration script? Which one? And if I do: will the changes I
> made to the variable files /service/*/variables/* be
> overwritten/lost?
>
> Any custom changes that you have made to variables will be lost if
> you re-run svctool.

I have always been reluctant to run svctool myself, being afraid to
lose the configuration adjustment I did by hand. But then, as addition
above shows, you always run the risk of forgetting something %-)

> The best method is to edit /service/*/variables/QHPSI and edit
> /service/clamd/run, /service/freshclam/run (remember that -f option
> in freshclam installed in CentOS does not work). Make sure that you
> have Foreground option enabled in /etc/freshclam.conf and
> /etc/clamd.conf.

Ah, what you suggest is to have clamd and freshclam run under control
of svctool.

What I did now is disable the clamd/freshclam configuration of IndiMail:

touch /service/clamd/down
touch /service/freshclam/down
service indimail restart

and keep clamd/freshclam as they come with CentOS:

chkconfig clamd on
service clamd start

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJTV7IXAAoJECfzYtonqXzELIIH/1F7wt5Nq/YqAC+qE5hLIZT/
cNcxp2DqXOvbcBN/hzU/VgcWxWooSCKBq+zMCQIfVwUEk3LHcWXUFn5TXF5nB/ZH
OhTNvHXsZs3bQinugAMfgQnr5DEtVt2GinY6D+/YsSVqfcN3EhWgheYIO8r3JVNR
dtH+OZrP0ODVWad9avNvUYMPQm4VeTIdxKeVwFrPwnmUBrtBnKmucDoILXCK6UG9
gJT+kSndwJGESqoVfeuTwzpoG+asxoXnVM6LBPK2pd4MedK6J8zxhJDISOlJ6MP0
gTMh0j4Q/LnS1gzQTXuMmhW3rYFfIH6L2Cm/fgzYqDJlVnCjIlABrawrbb0uxuM=
=OA8j
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform

[A. Offerman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'd say there is a need... :-)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJTV7JjAAoJECfzYtonqXzERtUH/iywKKcsBWYilVCV7En9CVHZ
jv4prXilyPR9cNzXkQ1wtFujZO5PYeeuzkh6xE5PVVTj7aHIjHbFMs3QnOzeTHKP
VTUnAxqndJz7+YyDbwk/LyWAdyRgFUzyAogDWyaRa8fvcN7KFJJqYdlf4UODjPIF
OCb9Lspc+jk8oGHp+0yjzNBDPYXjdY7FJQFvGUjg9WatgZhQj0qP7ANIGdy14mUB
fH10SVeaOEYp49SAOufoDIRANzWc2I+z/vLjRo/8foQWIz8+xb3NEj0/sEwIBFNS
XiLRt91aK0EIU1NIl9zC/VtlluoZno3diLu3p9tww9FeSHeszpGNnKODJnI3Zmw=
=qGrZ

-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform