Re: Packaging guidelines with regards to packages that use Clam Antivirus scanner

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/22/2011 06:52 PM, Stephen John Smoogen wrote:
2011/12/22 "Jóhann B. Guðmundsson"<johannbg@xxxxxxxxx>:
I'm in the midst of converting legacy sysv init scripts that use
/usr/share/clamav/clamd-wrapper to native systemd units and I have noticed
some discrepancy in their packaging which indicate a lack of guidelines.

Granted that I'm no clamav expert but from what I can tell the packages that
use the clamd-wrapper should all be doing the same thing and the package
that does it most right from my point of view is exim-clamd and the worst
one being dansguardian ( which seems to be yet another package we ship that
is neglected by it's maintainer(s) I come across in the migration process).
Clamav has been a special set of packages with a convoluted history
from when it was a package in Fedora Extras. It has many ideas that
were experimented with back then but not used later. It is probably a
package that needs  a serious rethunk. How it is started and packaged
has effects on other packages so it is a Gordian knot.



Which we will unloose in the form of policy...

I guess the first to be asked should packages like exim and others be the ones to ship their clamav configurations ( as opposed to them being a sub package of clamav it self )?

If not should those packages not be having their clamav configuration in a separate sub package as exim does?

Should those packages regardless if they are sub packages of their relevant components or of clamav it self use the same default configuration as their bases ( most do btw ).

Which brings us to the configuration file with unification I would like to see inn...

We would be basing our packaging guidelines around these set of defaults in the default configuration files ( and the default configuration should be used as the bases for any package using this it's well documented ).

LogFile /var/log/clamd/foo.log
LogSyslog yes
PidFile /run/clamd/clamd-foo.pid
TemporaryDirectory /var/lib/clamd/foo
LocalSocket /run/clamd/clamd-foo.sock
User foo
AllowSupplementaryGroups yes

Rest would be package specific defaults if any other than these

Followed by unit files that looks likes this...

clamd-foo.service

[Unit]
Description=Clamd foo An Interface Between MTA And Content Checkers
Requires=clamd-foo.socket
After=network.target

[Service]
Type=forking
PIDFile=/run/clamd/clamd-foo.pid
ExecStart=/usr/sbin/clamd -c /etc/clamd.d/foo.conf

[Install]
WantedBy=multi-user.target
Also=clamd-foo.socket

clamd-foo.socket

[Unit]
Description=Clamd Socket for foo

[Socket]
ListenStream=/run/clamd/clamd-foo.socket

[Install]
WantedBy=sockets.target

Now when I wrote the unit file for exim I got complaints in the logs for the database not being up2date to date which brings the question if packages should not depend on freshclam and freshclam be added to the service file with an ExecStartPre=-/usr/bin/freshclam line to ensure up2date the database be up2date before the service is started?

JBG
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging



[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux