Packaging guidelines with regards to packages that use Clam Antivirus scanner
 

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

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

Packaging guidelines with regards to packages that use Clam Antivirus scanner
 

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.


--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." Â*—James Stewart as Elwood P. Dowd
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Packaging guidelines with regards to packages that use Clam Antivirus scanner
 

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).
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Packaging guidelines with regards to packages that use Clam Antivirus scanner
 

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
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Packaging guidelines with regards to packages that use Clam Antivirus scanner
 

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.



--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." Â*—James Stewart as Elwood P. Dowd
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging