Just a few quick observations:
I am trying to use clamd with amavis and Postfix. Amavis is supposed to pass the attachments to clamd via a Unix socket. That's how it worked for a while with the clamav packages made by Dag Wieers, no problems at all.
Today I uninstalled Dag's packages and installed the EPEL ones instead. Big mistake.
The /etc/init.d stuff is badly broken. There isn't even a script proper, there's just a symlink to a wrapper. The wrapper file is not in the recognized init.d scripts style.
There's a clamd.init file somewhere in /usr/share, but there's a <SERVICE> tag in it that needs to be adjusted. That same tag is somehow propagated in the clamd.sysconfig file and possibly in a buch of other places. No explanation for its purpose. The way it currently is, the scripts just fail.
Why is the package failing to work after install? Why it doesn't just work? Why the over-engineered customization with <SERVICE>?
There's a bunch of CLAMD_SERVICE variables sprinkled all over the place in the wrapper script, that appears to be related to the <SERVICE> tag. Holy freaking bejesus. Why should I care about that? If I wanted to care about that, I would install clamav from source, thank you very much.
After installing clamav-server and the related packages, the stuff should Just Work (TM). It should not require dozens of obscure tweaks. What's the point in having a package otherwise?
The Dag packages simply worked, as they always do, perhaps with some small adjustments in the .conf file. I uninstalled them today, due to a conflict with EPEL and thought I could use the EPEL packages instead. How silly of me. If I can't figure out how to make the EPEL stuff work, I'll have to go back to Dag's packages and set up all kinds of exceptions in yum, to work around the broken EPEL packages.
How did these packages go through the verifications before being made public?
Meanwhile my mail server can either be offline, or without an antivirus. Merry Christmas. :-(
Hi,
On Fri, 2007-12-28 at 13:47 -0800, Florin Andrei wrote:
Today I uninstalled Dag's packages and installed the EPEL ones instead. Big mistake.
<snip>
+1. I'm sure that the packager has something in mind, but configuring/starting clamd shouldn't take much time. I had the same problem on Monday, and then reinstalled Dag's packages.
If there is no strong need for current layout, I suggest to move to the old design.
Regards,
On Fri, 28 Dec 2007 13:47:31 -0800, Florin Andrei wrote:
Just a few quick observations:
Funny. The differerent design of the Fedora clamav packages has been a topic on various lists long ago. Actually, there's some rationale behind the complexity of the Fedora clamav packages: packager's decision based on security and versatility beyond basic clamav usage. The packages include %doc files. You can't avoid reading them. The packages are not compatible with Dag's packages. They have never been compatible with Dag's. This is no secret. They do work, albeit differently than Dag's.
Unfortunately, the clamav users within the Fedora community have not cared enough about clamav in Fedora as would be necessary to either a) reach a consensus on how to package them, b) work with the original Fedora packager on enhancing them with a more convenient setup procedure, or c) do sufficient lobbying in order to convince Fedora Project leadership that something is "wrong" with Fedora's clamav packages and may need decision-finding on a higher level.
On Fri, 28 Dec 2007 13:47:31 -0800, Florin Andrei wrote:
Just a few quick observations:
Funny. The differerent design of the Fedora clamav packages has been a topic on various lists long ago. Actually, there's some rationale behind the complexity of the Fedora clamav packages: packager's decision based on security and versatility beyond basic clamav usage. The packages include %doc files. You can't avoid reading them. The packages are not compatible with Dag's packages. They have never been compatible with Dag's. This is no secret. They do work, albeit differently than Dag's.
Unfortunately, the clamav users within the Fedora community have not cared enough about clamav in Fedora as would be necessary to either a) reach a consensus on how to package them, b) work with the original Fedora packager on enhancing them with a more convenient setup procedure, or c) do sufficient lobbying in order to convince Fedora Project leadership that something is "wrong" with Fedora's clamav packages and may need decision-finding on a higher level.
Incidentally, I use clamav in production on fedora with sendmail. No issues. Just had to make the socket paths in the config files match, and voila.
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Dec 28, 2007 5:10 PM, Michael Schwendt bugs.michael@gmx.net wrote:
On Fri, 28 Dec 2007 13:47:31 -0800, Florin Andrei wrote:
Just a few quick observations:
Funny. The differerent design of the Fedora clamav packages has been a topic on various lists long ago. Actually, there's some rationale behind the complexity of the Fedora clamav packages: packager's decision based on security and versatility beyond basic clamav usage. The packages include %doc files. You can't avoid reading them. The packages are not compatible with Dag's packages. They have never been compatible with Dag's. This is no secret. They do work, albeit differently than Dag's.
Unfortunately, the clamav users within the Fedora community have not cared enough about clamav in Fedora as would be necessary to either a) reach a consensus on how to package them, b) work with the original Fedora packager on enhancing them with a more convenient setup procedure, or c) do sufficient lobbying in order to convince Fedora Project leadership that something is "wrong" with Fedora's clamav packages and may need decision-finding on a higher level.
I had a couple of conversations along the above. Enrico's position was it worked for him and that other changes were not what he had in mind. While it could have been the time I asked about (during one of the flame wars), translation issues, or the reality of it.. it was pretty much either his way or someone else maintain it and all his other packages. Since that was not what I was looking for.. I decided to let it rest.
There has been a push to patch the EPEL packages to be more like the DAG clamav ones for 'various' reasons, but it has been held up in review for quite some time.
Stephen John Smoogen wrote:
flame wars), translation issues, or the reality of it.. it was pretty much either his way or someone else maintain it and all his other packages. Since that was not what I was looking for.. I decided to let it rest.
I don't know what are the approval criteria, but the following test must be passed by any package containing a daemon (service) before it's released:
A package containing a daemon (service) must successfully execute "service daemon-init-script start" after the package has been installed. This command must launch a working instance of the daemon, with at least the basic functions enabled, the definition of "basic" depending on the daemon. No configuration changes should be required for that. Examples: Apache, Sendmail, Postfix, Squid.
Florin Andrei píše v Pá 28. 12. 2007 v 19:20 -0800:
Stephen John Smoogen wrote:
flame wars), translation issues, or the reality of it.. it was pretty much either his way or someone else maintain it and all his other packages. Since that was not what I was looking for.. I decided to let it rest.
I don't know what are the approval criteria, but the following test must be passed by any package containing a daemon (service) before it's released:
A package containing a daemon (service) must successfully execute "service daemon-init-script start" after the package has been installed. This command must launch a working instance of the daemon, with at least the basic functions enabled, the definition of "basic" depending on the daemon. No configuration changes should be required for that. Examples: Apache, Sendmail, Postfix, Squid.
Sorry, but this is simply not true. I own 2 packages that will never work like that. They need a manual configuration before they can be started.
Dan
On Saturday 29 December 2007, Dan Horák wrote:
Florin Andrei píše v Pá 28. 12. 2007 v 19:20 -0800:
I don't know what are the approval criteria, but the following test must be passed by any package containing a daemon (service) before it's released:
A package containing a daemon (service) must successfully execute "service daemon-init-script start" after the package has been installed. This command must launch a working instance of the daemon, with at least the basic functions enabled, the definition of "basic" depending on the daemon. No configuration changes should be required for that. Examples: Apache, Sendmail, Postfix, Squid.
Sorry, but this is simply not true. I own 2 packages that will never work like that. They need a manual configuration before they can be started.
Agreed. If the service cannot be made to work out of the box without any manual configuration, so be it, but the init script should (must?) detect the "unconfigured" situation and output an understandable message what to do about it, possibly with a pointer to further documentation. One example of this approach is in the init script of the Fedora vdr package.
Hi,
On Sat, 2007-12-29 at 10:17 +0100, Dan Horák wrote:
A package containing a daemon (service) must successfully execute "service daemon-init-script start" after the package has been
installed.
This command must launch a working instance of the daemon, with at
least
the basic functions enabled, the definition of "basic" depending on
the
daemon. No configuration changes should be required for that.
Examples:
Apache, Sendmail, Postfix, Squid.
Sorry, but this is simply not true. I own 2 packages that will never work like that. They need a manual configuration before they can be started.
So your package must be fixed, too.
Regards, -- Devrim GÜNDÜZ , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/
On Fri, 28 Dec 2007 19:20:56 -0800, Florin Andrei wrote:
Stephen John Smoogen wrote:
flame wars), translation issues, or the reality of it.. it was pretty much either his way or someone else maintain it and all his other packages. Since that was not what I was looking for.. I decided to let it rest.
I don't know what are the approval criteria, but the following test must be passed by any package containing a daemon (service) before it's released:
A package containing a daemon (service) must successfully execute "service daemon-init-script start" after the package has been installed. This command must launch a working instance of the daemon, with at least the basic functions enabled, the definition of "basic" depending on the daemon. No configuration changes should be required for that. Examples: Apache, Sendmail, Postfix, Squid.
That's not a paragraph from the Fedora Review Guidelines [1]. Worded like that it doesn't make much sense. It cannot be a MUST item. There are daemon services, which do require configuration steps before they would no longer refuse to start. It wouldn't be of much value to just create a daemon for the fun of it, a dummy daemon (which does nothing or waits for configuration file changes), or a daemon that actually relies on defaults to start a very limited or even insecure service on localhost. Even with defaults, some types of services may be missing configuration values until they would do something useful. Not every value can be guessed (especially not services which must know remote server addresses), and not every default value is helpful either.
[1] http://fedoraproject.org/wiki/Packaging/ReviewGuidelines
On Fri, 28 Dec 2007 18:38:29 -0700, Stephen John Smoogen wrote:
I had a couple of conversations along the above. Enrico's position was it worked for him
If the documentation files are followed, it does work, doesn't it? And packages like exim-clamav do work, too?
Btw, I'm not sure that Enrico also maintains the packages in EPEL.
and that other changes were not what he had in mind. While it could have been the time I asked about (during one of the flame wars), translation issues, or the reality of it.. it was pretty much either his way or someone else maintain it and all his other packages.
That's news to me that he wanted to drop all his packages. It would have been even more reason to make it an important issue for one of the relevant committees.
Michael Schwendt wrote:
Funny. The differerent design of the Fedora clamav packages has been a topic on various lists long ago. Actually, there's some rationale behind the complexity of the Fedora clamav packages:
They're not "complex". They're broken.
I can come up with countless examples of applications much more complex than clamav - their packages just work when installed.
Apache - it can do virtual hosts, reverse proxy and all sorts of fancy things. But the RPM package, once installed, Simply Works with a minimal setup. "service httpd start" launches a valid, working instance of the Apache server. Want more than just the basics? Sure, knock yourself out, read the docs, change it.
Postfix - capable of doing virtual hosting, accounts via LDAP, the whole shebang. But the RPM package, once installed, launches an MTA with the basic functionality. You can surely tweak it to do a whole lot more. But initially it Simply Works: "service postfix start" and voila.
Clamav - install it, try to launch it, it fails. A lot of hacking is required to enable even the most basic functions. I cannot call that anything but broken.
The packages include %doc files. You can't avoid reading them.
Yes, I can, and I should - if all I want is the most basic functionality. An RPM package should just work, with the basic functions enabled, once it's installed. This is true for more than 99% of all the RPM packages out there. For some reason, clamav is deemed to be a very special case, although there's nothing so special about this software to justify releasing an RPM package that does not work out of the box.
The packages are not compatible with Dag's packages. They have never been compatible with Dag's. This is no secret.
Nobody asked for compatibility with Dag's, nor is that a reasonable request.
Asking for basic functionality to just work out of the box, though, is a reasonable request, which the current clamav packages in EPEL fail to meet.
They do work, albeit differently than Dag's.
Not the packages I installed today, they don't. Proof: install them, then run "service clamav-wrapper start" (or whatever is the name of that broken symlink). Anything happened at all?
Rex Dieter wrote:
Florin Andrei wrote:
Clamav - install it, try to launch it, it fails. A lot of hacking is required to enable even the most basic functions. I cannot call that anything but broken.
Bug filed?
Good point.
https://bugzilla.redhat.com/show_bug.cgi?id=426997
On Fri, 28 Dec 2007 19:16:27 -0800, Florin Andrei wrote:
Michael Schwendt wrote:
Funny. The differerent design of the Fedora clamav packages has been a topic on various lists long ago. Actually, there's some rationale behind the complexity of the Fedora clamav packages:
They're not "complex". They're broken.
Please don't just repeat complaints without substance.
The packages include %doc files. You can't avoid reading them.
Yes, I can, and I should - if all I want is the most basic functionality. An RPM package should just work, with the basic functions enabled, once it's installed.
Then be the volunteer to provide a package that includes the configuration files for such a "most basic" clamav daemon. AIUI, the Fedora clamav packager doesn't want to provide such defaults because he thinks it would be wrong to do that. The Fedora Package Collection is not closed, however, it is open to the community.
They do work, albeit differently than Dag's.
Not the packages I installed today, they don't. Proof: install them, then run "service clamav-wrapper start" (or whatever is the name of that broken symlink). Anything happened at all?
You are not supposed to run that. Read the documentation first.
On Dec 29, 2007 6:16 AM, Michael Schwendt bugs.michael@gmx.net wrote:
Then be the volunteer to provide a package that includes the configuration files for such a "most basic" clamav daemon. AIUI, the Fedora clamav packager doesn't want to provide such defaults because he thinks it would be wrong to do that. The Fedora Package Collection is not closed, however, it is open to the community.
I think the issue is that in the past, Enricho has come across as his way or someone maintains all of his packages. I am not sure if that was his intent, but the feeling came across. Adding in a package for basic configurations has been closed as a wontfix in the past.
https://bugzilla.redhat.com/show_bug.cgi?id=161953
They do work, albeit differently than Dag's.
Not the packages I installed today, they don't. Proof: install them, then run "service clamav-wrapper start" (or whatever is the name of that broken symlink). Anything happened at all?
You are not supposed to run that. Read the documentation first.
Why does every time this package come up we end up with the same comments... there seem to have been several more in the old bugzilla.us one that I cant get to.
https://bugzilla.redhat.com/show_bug.cgi?id=157528
https://bugzilla.redhat.com/show_bug.cgi?id=173221
It is a different packaging philosophy that Enricho has.. but it does seem to be different than most packages that Fedora ships. I am having a hard time coming up with a mainstream package that does it that way.. which I think is what causes the large amount of cognitive dissonance, and harsh opinions when they come up.
On Sat, 29 Dec 2007 10:34:29 -0700, Stephen John Smoogen wrote:
Adding in a package for basic configurations has been closed as a wontfix in the past.
Quote:
| 'clamav-milter' itself should work out-of-the-box (after | commenting out the 'Example' line in /etc/clamd.d/milter.conf);
Is that true? (I think requiring the admin to acknowledge an example config file is not asked too much)
But I referred to the case the Fedora packager doesn't like: a single system-wide clamd instance. Surely such a service can be provided in a separate package, building on top of the clamav base (like the exim-clamav package for Exim does it).
They do work, albeit differently than Dag's.
Not the packages I installed today, they don't. Proof: install them, then run "service clamav-wrapper start" (or whatever is the name of that broken symlink). Anything happened at all?
You are not supposed to run that. Read the documentation first.
Why does every time this package come up we end up with the same comments...
Because everytime it comes up, it's ignorance that leads to the initial complaints. Not all files in /etc/rc.d/init.d/ are service initscripts. None of the documentation claims that one should start clamav like that. Then, a person who complains is told about the need to complete configuration files first (which sounds like an interactive helper-script could aid with that), and the person still doesn't admit that the packages work. Instead, it is repeated that those configuration steps should not be necessary at all, and it is referred to a 3rd party package which starts a single preconfigured daemon. The Fedora packager points out what he thinks is wrong about starting a single clamd, and the discussion loops back to the beginning.
That's why I suggest this issue is taken in front of a relevant Fedora technical committee to decide on whether it is too complicated to set up the packages and whether the packages fit into the Fedora Packaging philosophy.
there seem to have been several more in the old bugzilla.us one that I cant get to.
The initial package reviews have not been straight-forward, especially not since they contained technical problems and typos, which caused them to malfunction and which lead to a series of questions and answers about several aspects of the package design. For example, the purpose of the sub-packages, "virtual packages" and "capabilities" was not obvious or lead to feedback.
At least one bigger thread should be on old fedora-extras-list.
It is a different packaging philosophy that Enricho has.. but it does seem to be different than most packages that Fedora ships. I am having a hard time coming up with a mainstream package that does it that way.. which I think is what causes the large amount of cognitive dissonance, and harsh opinions when they come up.
Is setting up Samba or ntpd so much easier?
Heavy usage of virtual packages/capabilities in the clamav packaging may be intimidating, but it boils down to a documentation issue (and the package %descriptions explain quite a bit already).
Michael Schwendt wrote:
Is setting up Samba or ntpd so much easier?
Are you living in the same universe like everyone else?
ntp can be launched immediately after it's installed. "service ntpd start" and it's working already.
Samba may require setting up the workgroup at least, a couple more config items at most, then it's good to go. Or you can simply launch it as is and it will still work, albeit using the default workgroup. This is acceptable. This is very different from the situation with the EPEL clamav packages.
On Sat, 29 Dec 2007 11:38:24 -0800, Florin Andrei wrote:
Michael Schwendt wrote:
Is setting up Samba or ntpd so much easier?
Are you living in the same universe like everyone else?
ntp can be launched immediately after it's installed. "service ntpd start" and it's working already.
Because these days a default setup is provided for it already at firstboot-time (and hence the same defaults can be provided in the package already, too). And it's a system-wide service.
# yum -y install openvpn [...] # service openvpn start Starting openvpn: [ OK ] # service openvpn start Starting openvpn: [ OK ] # service openvpn start Starting openvpn: [ OK ] [...] # service openvpn status openvpn: service not started [...] # service openvpn stop Shutting down openvpn: [ OK ] # service openvpn stop Shutting down openvpn: [ OK ] # service openvpn stop Shutting down openvpn: [ OK ]
Hint: Read the initscript header to find out what is missing.
# yum -y install hddtemp [...] # service hddtemp start Unconfigured: hddtemp, see /etc/sysconfig/hddtemp: [FAILED]
Samba may require setting up the workgroup at least, a couple more config items at most, then it's good to go. Or you can simply launch it as is and it will still work, albeit using the default workgroup. This is acceptable. This is very different from the situation with the EPEL clamav packages.
Ah, you would probably call the default openldap server setup "acceptable", too... truth is, these services require somebody to edit the config files if you want more than an "[ OK ]" to make you happy.
Michael Schwendt wrote:
You are not supposed to run that. Read the documentation first.
You are free to tell me what to do only _after_ you come up with a reasonable explanation as to why clamav is different from all other daemons out there and so it requires a different packaging philosophy. Until then, shut up.
On Sat, 29 Dec 2007 10:40:40 -0800, Florin Andrei wrote:
Michael Schwendt wrote:
You are not supposed to run that. Read the documentation first.
You are free to tell me what to do only _after_ you come up with a reasonable explanation as to why clamav is different from all other daemons out there and so it requires a different packaging philosophy. Until then, shut up.
"from all other daemons"? -> FUD.
On Dec 29, 2007 11:40 AM, Florin Andrei florin@andrei.myip.org wrote:
Michael Schwendt wrote:
You are not supposed to run that. Read the documentation first.
You are free to tell me what to do only _after_ you come up with a reasonable explanation as to why clamav is different from all other daemons out there and so it requires a different packaging philosophy. Until then, shut up.
Comments like this one and others do not help get a fix. They just stir emotional hot-buttons that make sure that fixes don't happen. Yes clamav in EPEL/Fedora is not packaged the way that other repositories do it. It causes conflicts and other issues and does not seem to be what people expect out of a system service. However, every thread that has started like this one has has just made the package more stuck in the way it is.
So while we work out human issues on our part (which will take as long as any EU debate..) how can we get your system working again. My first suggestion would be to back out the clamav from EPEL and also figure out what packages you are wanting from each repository.. and why. Second put in yum-priorities to put each repository at a level... its not a great fix.. having 'local' repos is a better fix but that is outside the scope of this email.
On Fri, 28 Dec 2007 13:47:31 -0800 florin@andrei.myip.org (Florin Andrei) wrote:
Just a few quick observations:
I am trying to use clamd with amavis and Postfix. Amavis is supposed to pass the attachments to clamd via a Unix socket. That's how it worked for a while with the clamav packages made by Dag Wieers, no problems at all.
Today I uninstalled Dag's packages and installed the EPEL ones instead. Big mistake.
Are you using amavis packages from dag? or amavisd-new from epel/fedora? The two versions are very tied to the clamav version from the same repo.
Why is the package failing to work after install? Why it doesn't just work? Why the over-engineered customization with <SERVICE>?
amavisd-new from fedora/epel should just work out of the box. It has the clamd start script in it due to the way the clamav package in fedora is setup.
After installing clamav-server and the related packages, the stuff should Just Work (TM). It should not require dozens of obscure tweaks. What's the point in having a package otherwise?
I would totally agree.
...snipp...
How did these packages go through the verifications before being made public?
These have been in fedora for ages...
Meanwhile my mail server can either be offline, or without an antivirus. Merry Christmas. :-(
:(
So, let me recap what I know and perhaps someone will think of a brilliant solution:
- The fedora clamav maintainer wants to do things the way the package is currently setup. They don't want to change it to be more simple/easy to understand, or fix it to be more usable. This package meets all the package guidelines.
- I attempted to setup a clamav for epel that was based on the dag rpms. However, amavisd-new, klamav, and other packages in fedora (and thus epel) depend on clamav being packaged in the way that it is. This would mean all those other packages would have to rework their specs for the clamav package.
- The amavisd-new maintainer in fedora/epel reluctantly agreed to maintain the fedora version in EPEL.
So, I don't see much way out... we go with the version currently in fedora/epel, unless someone can talk the maintainer (and the maintainers of all the dependent packages) into changing the package.
Any other ideas?
kevin
Kevin Fenzi wrote:
Are you using amavis packages from dag? or amavisd-new from epel/fedora? The two versions are very tied to the clamav version from the same repo.
Dag. IIRC, his repo provided clamav, amavisd-new and stuff like that before Fedora / EPEL, and his packages always worked correctly, so I haven't even bothered to verify if such packages are available outside of dag.wieers.com. Until a few days ago, "yum update" failed on el5 due to a clamav conflict.
To make it clear, I'm not a dag.wieers.com partisan, I just want to use whatever software works and is easiest to use.
amavisd-new from fedora/epel should just work out of the box. It has the clamd start script in it due to the way the clamav package in fedora is setup.
These have been in fedora for ages...
Oh great, that rot has been lingering there for ages and now other packages must work around the bug in the clamav packages. :-(
So, let me recap what I know and perhaps someone will think of a brilliant solution:
- The fedora clamav maintainer wants to do things the way the package
is currently setup. They don't want to change it to be more simple/easy to understand, or fix it to be more usable. This package meets all the package guidelines.
- I attempted to setup a clamav for epel that was based on the dag
rpms. However, amavisd-new, klamav, and other packages in fedora (and thus epel) depend on clamav being packaged in the way that it is. This
awful
It's not that other packages have just to work around the broken clamav packages, but they need to make the assumption that the bug is there in order to be able to use clamav.
would mean all those other packages would have to rework their specs for the clamav package.
- The amavisd-new maintainer in fedora/epel reluctantly agreed to
maintain the fedora version in EPEL.
So, I don't see much way out... we go with the version currently in fedora/epel, unless someone can talk the maintainer (and the maintainers of all the dependent packages) into changing the package.
Any other ideas?
Back to using Dag's repo - setup all sorts of yum exceptions, so that the broken EPEL packages do not interfere with the good packages provided by Dag. Welcome to the repo hell. :-(
On 12/29/2007 09:34 PM, Florin Andrei wrote:
Back to using Dag's repo - setup all sorts of yum exceptions, so that the broken EPEL packages do not interfere with the good packages provided by Dag. Welcome to the repo hell. :-(
That't exactly what yum-priorities has been written for. Just setup rpmforge with a bigger priority over epel and you are done.
On Sat, 29 Dec 2007, lonely wolf wrote:
On 12/29/2007 09:34 PM, Florin Andrei wrote:
Back to using Dag's repo - setup all sorts of yum exceptions, so that the broken EPEL packages do not interfere with the good packages provided by Dag. Welcome to the repo hell. :-(
That't exactly what yum-priorities has been written for. Just setup rpmforge with a bigger priority over epel and you are done.
Last time such a discussion popped up and I simply stated that RPMforge and EPEL are not compatible and you are better off using only one of both I was told to stop spreading FUD (by Rex Dieter).
Apparently it stopped being FUD today ?
On Sun, Dec 30, 2007 at 12:27:42AM +0100, Dag Wieers wrote:
On Sat, 29 Dec 2007, lonely wolf wrote:
On 12/29/2007 09:34 PM, Florin Andrei wrote:
Back to using Dag's repo - setup all sorts of yum exceptions, so that the broken EPEL packages do not interfere with the good packages provided by Dag. Welcome to the repo hell. :-(
That't exactly what yum-priorities has been written for. Just setup rpmforge with a bigger priority over epel and you are done.
Last time such a discussion popped up and I simply stated that RPMforge and EPEL are not compatible and you are better off using only one of both I was told to stop spreading FUD (by Rex Dieter).
Apparently it stopped being FUD today ?
I would say they most certainly are _not_ copmatible. :) I don't use EPEL's clam packages either and instead use exclude/includepkgs to pull them in from rpmforge explicitly.
Kind of a mess, but hey it works. :)
Ray
On Dec 29, 2007 4:27 PM, Dag Wieers dag@wieers.com wrote:
On Sat, 29 Dec 2007, lonely wolf wrote:
On 12/29/2007 09:34 PM, Florin Andrei wrote:
Back to using Dag's repo - setup all sorts of yum exceptions, so that the broken EPEL packages do not interfere with the good packages provided by Dag. Welcome to the repo hell. :-(
That't exactly what yum-priorities has been written for. Just setup rpmforge with a bigger priority over epel and you are done.
Last time such a discussion popped up and I simply stated that RPMforge and EPEL are not compatible and you are better off using only one of both I was told to stop spreading FUD (by Rex Dieter).
Apparently it stopped being FUD today ?
I do not know. FUD is an overused acronym and probably is a corollary to Godwin's law. It also depends on the tone and how it was said. Email is not a medium to give tone or meaning to statements.. it is a medium for partisan bickering. This is not an issue that can be solved in a one paragraph email. It is a problem that will take a multi-line sets of emails and people reasonably listening to each other, asking for clarifications, and working towards and accepting an 'imperfect' middle ground.
Dag Wieers wrote:
On Sat, 29 Dec 2007, lonely wolf wrote:
On 12/29/2007 09:34 PM, Florin Andrei wrote:
Back to using Dag's repo - setup all sorts of yum exceptions, so that the broken EPEL packages do not interfere with the good packages provided by Dag. Welcome to the repo hell. :-(
That't exactly what yum-priorities has been written for. Just setup rpmforge with a bigger priority over epel and you are done.
Last time such a discussion popped up and I simply stated that RPMforge and EPEL are not compatible and you are better off using only one of both I was told to stop spreading FUD (by Rex Dieter).
Apparently it stopped being FUD today ?
"FUD" is probably an exaggeration.
yum-priorities is pretty damn ugly, and probably requires constant fiddling. But it may just work. No, I don't like it at all. But when it's the only solution... (shrug)
On Sat, 29 Dec 2007 12:04:16 -0700, Kevin Fenzi wrote:
So, let me recap what I know and perhaps someone will think of a brilliant solution:
- The fedora clamav maintainer wants to do things the way the package
is currently setup. They don't want to change it to be more simple/easy to understand, or fix it to be more usable. This package meets all the package guidelines.
- I attempted to setup a clamav for epel that was based on the dag
rpms. However, amavisd-new, klamav, and other packages in fedora (and thus epel) depend on clamav being packaged in the way that it is. This would mean all those other packages would have to rework their specs for the clamav package.
- The amavisd-new maintainer in fedora/epel reluctantly agreed to
maintain the fedora version in EPEL.
So, I don't see much way out... we go with the version currently in fedora/epel, unless someone can talk the maintainer (and the maintainers of all the dependent packages) into changing the package.
Any other ideas?
What exactly would make the current packages "more usable"?
Why can't a volunteer create and maintain a clamav configuration add-on package, which offers a single system-wide clamav daemon if that is requested by the clamav user base in Fedora/EPEL?
On Sat, 29 Dec 2007 21:38:10 +0100 bugs.michael@gmx.net (Michael Schwendt) wrote:
On Sat, 29 Dec 2007 12:04:16 -0700, Kevin Fenzi wrote:
...snip..
Any other ideas?
What exactly would make the current packages "more usable"?
Well, here is my list:
- freshclam should work when the package is installed. Currently it requires you to comment a line in a script for no reason I can tell.
- freshclam should not mail "root,postmaster,webmaster,clamav" on any output.
- freshclam should be set to use your local country mirror for updates.
- The milter should work with postfix.
- The subpackages should be reduced and named in a way that an end user could possibly know what they need to install for the functionality they are looking for. For example, the upstream docs and every other package talks about the 'freshclam' update program, it's not easy to know that in fedora thats in the 'clamav-update' package.
- The useless 'sysv' subpackages should be folded into the other subpackages until such a time as fedora stops using sysvinit by default.
- clamscan looks for a /etc/clamd.conf file for config options, which is not in that place. If it was it wouldn't work because it needs a line commented before it's a valid config file.
- The package could not remove the clamav user on removal.
I'm sure I could look around for more issues.
Why can't a volunteer create and maintain a clamav configuration add-on package, which offers a single system-wide clamav daemon if that is requested by the clamav user base in Fedora/EPEL?
I suppose someone could... thats not my issue however. My issues are in the clamav package itself, not just not having a system wide clamd.
kevin
Kevin Fenzi wrote:
I suppose someone could... thats not my issue however. My issues are in the clamav package itself, not just not having a system wide clamd.
Shouldn't this be brought up to the level of FESCo? Solving it only for EPEL if that is even possible seems the wrong solution to me.
Rahul
On Dec 29, 2007 2:06 PM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Kevin Fenzi wrote:
I suppose someone could... thats not my issue however. My issues are in the clamav package itself, not just not having a system wide clamd.
Shouldn't this be brought up to the level of FESCo? Solving it only for EPEL if that is even possible seems the wrong solution to me.
It probably should, how does one do so.
On Sat, 29 Dec 2007 17:35:40 -0700 "Stephen John Smoogen" smooge@gmail.com wrote:
It probably should, how does one do so.
http://fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines
On Sat, 29 Dec 2007 14:06:13 -0700, Kevin Fenzi wrote:
- freshclam should work when the package is installed. Currently it
requires you to comment a line in a script for no reason I can tell.
Cannot find this in bugzilla. The /etc/sysconfig script disables the automatic update on purpose (to prevent unauthorized network access) and warns the user about that default. What is wrong with that?
- freshclam should not mail "root,postmaster,webmaster,clamav" on any
output.
Is this in bugzilla? It also mails warnings and errors.
- freshclam should be set to use your local country mirror for updates.
Is this in bugzilla?
- The milter should work with postfix.
https://bugzilla.redhat.com/239037
- The subpackages should be reduced and named in a way that an end user
could possibly know what they need to install for the functionality they are looking for. For example, the upstream docs and every other package talks about the 'freshclam' update program, it's not easy to know that in fedora thats in the 'clamav-update' package.
Just a %doc issue so far, IMO. Unless it is ruled that clamav must be in a single package.
- The useless 'sysv' subpackages should be folded into the other
subpackages until such a time as fedora stops using sysvinit by default.
https://bugzilla.redhat.com/322381 - WONTFIX
- clamscan looks for a /etc/clamd.conf file for config options, which
is not in that place. If it was it wouldn't work because it needs a line commented before it's a valid config file.
- The package could not remove the clamav user on removal.
I'm sure I could look around for more issues.
Why can't a volunteer create and maintain a clamav configuration add-on package, which offers a single system-wide clamav daemon if that is requested by the clamav user base in Fedora/EPEL?
I suppose someone could... thats not my issue however. My issues are in the clamav package itself, not just not having a system wide clamd.
The list is interesting, but it adds more than what I thought has been the primary (only?) issue with the Fedora clamav packages.
On Sat, 29 Dec 2007 22:40:22 +0100 bugs.michael@gmx.net (Michael Schwendt) wrote:
On Sat, 29 Dec 2007 14:06:13 -0700, Kevin Fenzi wrote:
- freshclam should work when the package is installed. Currently it
requires you to comment a line in a script for no reason I can tell.
Cannot find this in bugzilla. The /etc/sysconfig script disables the automatic update on purpose (to prevent unauthorized network access) and warns the user about that default. What is wrong with that?
Where is there a requirement that network access should require configuration changes? Should we modify any other network accessing services to require a config change before using the network?
What good would clamav be on a machine thats not on a network and what good is it with no up 2 date virus definitions?
- freshclam should not mail "root,postmaster,webmaster,clamav" on
any output.
Is this in bugzilla? It also mails warnings and errors.
No, I can file it I suppose.
- freshclam should be set to use your local country mirror for
updates.
Is this in bugzilla?
No. I can file it I suppose.
- The milter should work with postfix.
yeah.
- The subpackages should be reduced and named in a way that an end
user could possibly know what they need to install for the functionality they are looking for. For example, the upstream docs and every other package talks about the 'freshclam' update program, it's not easy to know that in fedora thats in the 'clamav-update' package.
Just a %doc issue so far, IMO. Unless it is ruled that clamav must be in a single package.
Well, I agree it's a matter of package maintainers desires, but I don't think all the docs in the world will help. This thread is proof of that.
- The useless 'sysv' subpackages should be folded into the other
subpackages until such a time as fedora stops using sysvinit by default.
https://bugzilla.redhat.com/322381 - WONTFIX
Yep.
- clamscan looks for a /etc/clamd.conf file for config options,
which is not in that place. If it was it wouldn't work because it needs a line commented before it's a valid config file.
I guess I should file this as well.
- The package could not remove the clamav user on removal.
This I guess is part of the fedora-usermanagement setup.
I'm sure I could look around for more issues.
Why can't a volunteer create and maintain a clamav configuration add-on package, which offers a single system-wide clamav daemon if that is requested by the clamav user base in Fedora/EPEL?
I suppose someone could... thats not my issue however. My issues are in the clamav package itself, not just not having a system wide clamd.
The list is interesting, but it adds more than what I thought has been the primary (only?) issue with the Fedora clamav packages.
Really? So the only real issue you see is that there is no system wide clamd setup?
kevin
On Mon, 31 Dec 2007 11:30:37 -0700, Kevin Fenzi wrote:
On Sat, 29 Dec 2007 22:40:22 +0100 bugs.michael@gmx.net (Michael Schwendt) wrote:
On Sat, 29 Dec 2007 14:06:13 -0700, Kevin Fenzi wrote:
- freshclam should work when the package is installed. Currently it
requires you to comment a line in a script for no reason I can tell.
Cannot find this in bugzilla. The /etc/sysconfig script disables the automatic update on purpose (to prevent unauthorized network access) and warns the user about that default. What is wrong with that?
Where is there a requirement that network access should require configuration changes?
It's not mandatory, but it's nice to the user.
Should we modify any other network accessing services to require a config change before using the network?
Installation of a package should not enable a network-using service automatically. Accessing the network to download data may be seen as a lesser problem than binding a service to a public port. But both are issues where the user/admin ought to opt-in rather than opt-out.
What good would clamav be on a machine thats not on a network and what good is it with no up 2 date virus definitions?
This question is biased. The update feature is not missing, it can be enabled for automated downloads if the software is told to do that.
- The package could not remove the clamav user on removal.
This I guess is part of the fedora-usermanagement setup.
uid/gid removal IMO is a "must not" unless all files with that uid/gid are removed as well.
I'm sure I could look around for more issues.
Why can't a volunteer create and maintain a clamav configuration add-on package, which offers a single system-wide clamav daemon if that is requested by the clamav user base in Fedora/EPEL?
I suppose someone could... thats not my issue however. My issues are in the clamav package itself, not just not having a system wide clamd.
The list is interesting, but it adds more than what I thought has been the primary (only?) issue with the Fedora clamav packages.
Really? So the only real issue you see is that there is no system wide clamd setup?
Yes, based on older [similar threads] that was my impression. The typical clamav-in-fedora critic complains that starting clamd takes more than installing the package and running a service script. It is certainly not the first time somebody tried to run the wrapper-script without even skimming over the readme file.
On Mon, Dec 31, 2007 at 08:07:27PM +0100, Michael Schwendt wrote:
Installation of a package should not enable a network-using service automatically.
Doesn't yum-updatesd?
Steve
On Jan 1, 2008 9:10 PM, Steven Pritchard steve@silug.org wrote:
On Mon, Dec 31, 2007 at 08:07:27PM +0100, Michael Schwendt wrote:
Installation of a package should not enable a network-using service automatically.
Doesn't yum-updatesd?
Yes and other packages (many more in the past)... it is a line that core packages seem to fall on both sides of. Do not turn on unless there is a network, do not run if there isn't a general configuration, do not have a configuration unless it is useful out-of-the-box for a large segment.
On Tue, 1 Jan 2008 21:13:49 -0700, Stephen John Smoogen wrote:
On Jan 1, 2008 9:10 PM, Steven Pritchard steve@silug.org wrote:
On Mon, Dec 31, 2007 at 08:07:27PM +0100, Michael Schwendt wrote:
Installation of a package should not enable a network-using service automatically.
Doesn't yum-updatesd?
And together with the implementation and the metadata problems, it causes quite some problems. I've seen many users who were annoyed when they found out that yum refuses to run because something in the background blocked it.
Fortunately, here I cannot get it to start anymore currently (F-8):
# yum -y install yum-updatesd # service yum-updatesd start Starting yum-updatesd: [ OK ] [...] # service yum-updatesd start Starting yum-updatesd: [ OK ] [...] # service yum-updatesd start Starting yum-updatesd: [ OK ] [...] # service yum-updatesd status yum-updatesd dead but subsys locked # # /usr/sbin/yum-updatesd -d #
Yes and other packages (many more in the past)...
There is absolutely no need to enable the service in the package already. It could also be enabled by the installer or in firstboot code. Currently, it's not that the service is started when the package is installed, it is started only after reboot.
Michael Schwendt wrote:
On Tue, 1 Jan 2008 21:13:49 -0700, Stephen John Smoogen wrote:
On Jan 1, 2008 9:10 PM, Steven Pritchard steve@silug.org wrote:
On Mon, Dec 31, 2007 at 08:07:27PM +0100, Michael Schwendt wrote:
Installation of a package should not enable a network-using service automatically.
Doesn't yum-updatesd?
And together with the implementation and the metadata problems, it causes quite some problems. I've seen many users who were annoyed when they found out that yum refuses to run because something in the background blocked it.
Fortunately, here I cannot get it to start anymore currently (F-8):
# yum -y install yum-updatesd # service yum-updatesd start Starting yum-updatesd: [ OK ] [...] # service yum-updatesd start Starting yum-updatesd: [ OK ] [...] # service yum-updatesd start Starting yum-updatesd: [ OK ] [...] # service yum-updatesd status yum-updatesd dead but subsys locked # # /usr/sbin/yum-updatesd -d #
Yes and other packages (many more in the past)...
There is absolutely no need to enable the service in the package already. It could also be enabled by the installer or in firstboot code. Currently, it's not that the service is started when the package is installed, it is started only after reboot.
OK ... people can argue about this until we are all blue in the face.
The real answer, however is what your customers want.
People who routinely do not give their customers what they want find themselves without any customers.
SO, I would think long and hard about such flaming comments as I have seen on this thread.
If you don't care much for/about your customers, eventually you won't have to.
Thanks, Johnny Hughes
On Wed, 02 Jan 2008 06:46:35 -0600, Johnny Hughes wrote:
OK ... people can argue about this until we are all blue in the face.
The real answer, however is what your customers want.
Fedora is not a product that is sold to customers, so by definition there are no Fedora customers.
There is only the relationship with RHEL in that Fedora is used as a testbed in order to find out how to develop RHEL further. But RHEL customers don't choose RHEL because they like Fedora.
For Clamav, the evaluation period is not over yet. Without a doubt, its setup can be made much more convenient with helper scripts and even a GUI for desktop users.
For services like yum-updated, it is possible to notify the user that the service is disabled. By default, the service does not apply any updates anyway, so further action from the user/admin is needed (such as configuring the system or clicking onto a desktop notification icon and enabling a service).
People who routinely do not give their customers what they want find themselves without any customers.
SO, I would think long and hard about such flaming comments as I have seen on this thread.
If you don't care much for/about your customers, eventually you won't have to.
On Wed, Jan 02, 2008 at 02:48:21PM +0100, Michael Schwendt wrote:
On Wed, 02 Jan 2008 06:46:35 -0600, Johnny Hughes wrote:
OK ... people can argue about this until we are all blue in the face.
The real answer, however is what your customers want.
Fedora is not a product that is sold to customers, so by definition there are no Fedora customers.
There are users however, and shouldn't it be your goal to make your package as useable as it can be by as many users as possible -- taking into account their feedback (no matter how combative it may seem to the maintainer)?
Even if you don't consider "users" customers, the effects are the same. People will go elsewhere to fufill their need. And a packager that says "whoop dee doo I don't care" maybe isn't the best maintainer for that package. :)
Just my $0.02 Ray
On Wed, 2 Jan 2008 06:23:22 -0800, Ray Van Dolson wrote:
On Wed, Jan 02, 2008 at 02:48:21PM +0100, Michael Schwendt wrote:
On Wed, 02 Jan 2008 06:46:35 -0600, Johnny Hughes wrote:
OK ... people can argue about this until we are all blue in the face.
The real answer, however is what your customers want.
Fedora is not a product that is sold to customers, so by definition there are no Fedora customers.
There are users however, and shouldn't it be your goal to make your package as useable as it can be by as many users as possible -- taking into account their feedback (no matter how combative it may seem to the maintainer)?
That's not a question that can be answered with "yes" or "no". First of all, it's the "as many users as possible" that is too vague and makes it difficult to answer. And secondly, if there are many users who are unhappy with the package (and I refer to clamav as it has been in Fedora for a long time, not specifically to EPEL, as EPEL has other requirements), why don't any volunteers work on improving the packages? E.g. with an add-on package for a system-wide daemon, helper scripts, patches and a task-force that works together with the packager?
Feedback like "the clamav pkg is broken", which does not even try to follow the short instructions in the package documentation, won't convince the package maintainer.
It's not that the packager doesn't admit the manual configuration steps are inconvenient. There may be other reasons (e.g. lack of time) why it is still like that, and clamav add-on packages demonstrate how to set up services on top of the base clamav packages. There is no bugzilla ticket which clearly makes it a primary goal to improve/enhance/change the packages in well-defined ways. User satisfaction is not tracked anywhere. Every few months somebody tries to execute a non-executable script or ignores the documentation. And meanwhile, nobody else contributes any patches or co-maintainership. The packager is a volunteer like lots of the other packagers. In case of severe disagreement between him and what some people claim is a large portion of the clamav users it really may need somebody from FESCo to look into it. So, please start filing tickets, point out your concerns, get status updates from the maintainer, ...
Even if you don't consider "users" customers, the effects are the same. People will go elsewhere to fufill their need. And a packager that says "whoop dee doo I don't care" maybe isn't the best maintainer for that package. :)
With all due respect, but that paragraph above is only cheap talk IMO, which isn't helpful at all.
On Wed, 2 Jan 2008 16:23:28 +0100 bugs.michael@gmx.net (Michael Schwendt) wrote:
...snipp... So, please start filing tickets, point out your concerns, get status updates from the maintainer, ...
An excellent plan. I filed:
https://bugzilla.redhat.com/show_bug.cgi?id=427103 https://bugzilla.redhat.com/show_bug.cgi?id=427104 https://bugzilla.redhat.com/show_bug.cgi?id=427105
To start with.
Will see what the maintainer says on those.
I think another thing that doesn't help here is that several of the CLOSED->WONTFIX bugs against clamav refer readers to the fedora.us bugzilla instance for reasoning, but that is no longer available.
There are 15 closed->NOTABUG and 6 closed->WONTFIX bugs against clamav, which I think is an indicator that users are confused by the packaging and/or find it non intuitive.
In any case, I think we should try and be constructive here. If anyone has other issues, please file them. If folks are seeing the same above issues I am seeing and would like them fixed, please add your comments to the above bugs.
kevin
Michael Schwendt wrote:
Fedora is not a product that is sold to customers, so by definition there are no Fedora customers.
Thank God for definitions - the perfect shelter against harsh, cold, inconvenient reality.
Michael Schwendt wrote:
Why can't a volunteer create and maintain a clamav configuration add-on package, which offers a single system-wide clamav daemon if that is requested by the clamav user base in Fedora/EPEL?
That sounds good enough. Still not perfect, but it's something that can be lived with.
Florin Andrei wrote:
Michael Schwendt wrote:
Why can't a volunteer create and maintain a clamav configuration add-on package, which offers a single system-wide clamav daemon if that is requested by the clamav user base in Fedora/EPEL?
That sounds good enough. Still not perfect, but it's something that can be lived with.
By the way, the _name_ of the package is important. I'm not picking nits (I hope), I'm just thinking of the poor souls who might get trapped by the existing clamav packages and break their systems. It should be something that is self-explanatory when looking at the list provided by "yum install clamav*"
"clamav-standalone-daemon" or something like that.
epel-devel@lists.fedoraproject.org
-
Dag Wieers -
Dan Horák -
Devrim GÜNDÜZ -
Florin Andrei -
Jesse Keating -
Johnny Hughes -
Jon Ciesla -
Kevin Fenzi -
Manuel Wolfshant -
Michael Schwendt -
Rahul Sundaram -
Ray Van Dolson -
Rex Dieter -
Stephen John Smoogen -
Steven Pritchard -
Ville Skyttä