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).
If an guideline does exist it would be good if someone could point me to it so I can review it and propose improvements to it if not I recommend that we come up with one and standardize how things are being done before things get more out of hand than they currently are ( we have low number of packages mostly with minor differences between them hence this situation can be dealt with ) and deliver to our user base an working out of the box solution.
Once an guideline has been written it should be a relatively easily for an proven packager to fix the current packages and at the same time ship the native unit file.
JBG
2011/12/22 "Jóhann B. Guðmundsson" johannbg@gmail.com:
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.
On Thu, 22 Dec 2011 11:52:58 -0700, SJS (Stephen) wrote:
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.
+1
Of key importance here is to understand that the Fedora community ought to decide on what they would like the Clamav packages to look like. That will require more than just posting complaints in several places of this world. It requires volunteers to work on creating add-on packages or on changing the packaging fundamentally. It's not as if the packaging were wrong. But it has turnt out that the user community simply doesn't get accustomed to the package design (and e.g. its special security considerations and setup procedure).
On 12/22/2011 06:52 PM, Stephen John Smoogen wrote:
2011/12/22 "Jóhann B. Guðmundsson"johannbg@gmail.com:
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
2011/12/22 "Jóhann B. Guðmundsson" johannbg@gmail.com:
On 12/22/2011 06:52 PM, Stephen John Smoogen wrote:
2011/12/22 "Jóhann B. Guðmundsson"johannbg@gmail.com:
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...
Policy is only useful if a) it is believed in b) it is followed.
That means finding people who use a package (or class of packages) to see what they are doing and why... and then you can figure out if you can articulate that into a policy first. Otherwise the policy ends up causing more headaches than fun. What level of communication have you had with Enrico or users of the package.
On 12/22/2011 09:34 PM, Stephen John Smoogen wrote:
2011/12/22 "Jóhann B. Guðmundsson"johannbg@gmail.com:
On 12/22/2011 06:52 PM, Stephen John Smoogen wrote:
2011/12/22 "Jóhann B. Guðmundsson"johannbg@gmail.com:
<snip>
Policy is only useful if a) it is believed in
As I see it policy's are something to be followed not put faith in so I fail to understand your point here or see the connection you make with it.
b) it is followed.
Agreed which begs the question what efforts does fpc make, to make sure policy's that are created are actually being followed?
That means finding people who use a package (or class of packages) to see what they are doing and why... and then you can figure out if you can articulate that into a policy first.
Hum failing to understand here as well all the 5 packages are essentially doing the same thing with regards to clamav av
Otherwise the policy ends up causing more headaches than fun.
From my point of view policy's are more about bringing consistency than fun into the distribution.
What level of communication have you had with Enrico or users of the package.
None what so ever
I personally dont care more for this proposal other than I already have submitted here atleast not to the extent of personally trying to dig up each maintainer and get his opinion on the matter and to be honest I assumed they would be subscribed to this list and would comment on this.
There has not been any movement on the unit files filed a while back for amavisd-new package so to me that maintainer is already unresponsive.
clamav-scanner already has been converted to systemd unit files so it was not on my radar per se but it's config file seem to require users to comment out an example line it and it's unit file differs from what I had already created so his unit file might be righter and should be used as a template for the other ones or is an specific exception thus should not be used also note that package is already part of the clamav suite while the other ones are not and but perhaps should be?
dansguardian seems to be abandon altogether ( clear indicator for that are things like this still open against a component "Please Update Spec File to use %ghost on files in /var/run and /var/lock" ) and does not work et all in it's current state ( all report seem to be related to the packaging of the component not the component it self ) and is the only package that does not use the default template as is, with related modification to it self.
clamsmtp seems to be more inline with the rest ( with the exception of dansguardian ) but contains "Please Update Spec File to use %ghost on files in /var/run and /var/lock" in reports against it which again indicates it lacks maintainer.
With regards to exim-clamav Jaroslav was going to take a look at it and I was waiting to see what came out of it and was going to base the unit files and (re)submit it against the above components with the exception of clamav-scanner.
I simply just noticed a pattern and saw a room for improvements and things could be made consistent with each other ( one is making this a sub package of it's components other are not. clamd.d confs look more or less the same and so on ) now and in the future with proper policy/guidelines and when fixed to meet the policy from the looks of it, it would close more or less all bugs filed against those components in the process but if people dont want to do it and are generally are happy then things stay as they are, broken as they might be or seem to me.
JBG
packaging@lists.fedoraproject.org
-
Jóhann B. Guðmundsson -
Michael Schwendt -
Stephen John Smoogen