Bug#406576: (clamav-daemon: init script fails if /var/run/clamav doesn't exist)
On Sat, Jan 13, 2007 at 12:04:02AM +, Stephen Gran wrote:
eh, no RAMRUN/RAMLOCK anywhere but in /etc/init.d/{boot,mount}*. Totally
...
somewhere. Odd that you can't find it. Take a look at a couple of init
scripts - `grep -rl RAMRUN` /etc/init.d will give you an idea where it's
turned out that manpages from initscripts where 0 bytes - only reason
I can think of is, no space on /usr on a huge upgrade.
RAM* are documented in rcS.5.
Clearly the issue needs proper (policy?) addressing, and involves
initscripts,
as it is unacceptable that eg setting RAMRUN breaks many pkgs.
Agreed.
filed a bug against initscripts - hope an agreement is reached soon, on
who's supposed to do tmpfs houskeeping, or RAMRUN (at least) removed at all.
thanks
--
paolo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406576: (clamav-daemon: init script fails if /var/run/clamav doesn't exist)
On Fri, Jan 12, 2007 at 01:01:29AM +, Stephen Gran wrote: start) +mkdir -p /var/run/clamav +chmod 0775 /var/run/clamav +chown root:clamav /var/run/clamav OPTIND=1 I have so far stayed away from this issue, since it is quite possible to have clamd and freshclam run as seperate users, but they share both /var/log/clamav and /var/run/clamav. The packaging so far tries very hm, ok - right now both daemons run as clamav:clamav, so above just works - it might be needed to replicate them into freshclam's init script, as either may be disabled, so both need to refresh the volatile dir. But should they run as different users, there's still no problem with above as long as they are in same group. Else, either 1. both log/clamav and run/clamav are 777 2. use separate dirs, log/clamd run/clamd run/freshclam log/freshclam While I can see reasons to use different users, I see no point in *not* having both daemon members of group clamav, so above added line would still apply. BTW man clam(d)scan don't stress the point that such util run as user clamav, hence won't be able to access file/dirs not a+r/a+rx. hard to stay out of the way of local admin changes. Making this change reverses that, and I am not comfortable with it. If you can come up with a good way to reconcile this, I'm happy to merge same problem with other pkgs - on ML it's said that it's each pkgs' init / admin script responsability to check for and in case make/adjust its own admin stuf under /var, as that's undoable elsewhere. So afaikt other pkgs have been / are going to be adjusted to refresh their dir trees under /var on (re)start. So I see no problem to keep those lines in both init scripts. But likely should be moved up, @top of script after *.conf is read, which then should keep both uid gid of daemon. thanks -- paolo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406576: (clamav-daemon: init script fails if /var/run/clamav doesn't exist)
This one time, at band camp, Paolo said: On Fri, Jan 12, 2007 at 01:01:29AM +, Stephen Gran wrote: start) +mkdir -p /var/run/clamav +chmod 0775 /var/run/clamav +chown root:clamav /var/run/clamav OPTIND=1 I have so far stayed away from this issue, since it is quite possible to have clamd and freshclam run as seperate users, but they share both /var/log/clamav and /var/run/clamav. The packaging so far tries very hm, ok - right now both daemons run as clamav:clamav, so above just works - it might be needed to replicate them into freshclam's init script, as either may be disabled, so both need to refresh the volatile dir. And clamav-milter. Does this also need to be done for /var/log/clamav/ and /var/lib/clamav/ ? If not, why not? What benefits are you hoping for? But should they run as different users, there's still no problem with above as long as they are in same group. Else, either 1. both log/clamav and run/clamav are 777 That's clearly unacceptable. 2. use separate dirs, log/clamd run/clamd run/freshclam log/freshclam That is possible, but currently feels like overkill. While I can see reasons to use different users, I see no point in *not* having both daemon members of group clamav, so above added line would still apply. This should be doable, though. I'm not really all that sure that adding this feature buys us anything, though - see below for why. BTW man clam(d)scan don't stress the point that such util run as user clamav, hence won't be able to access file/dirs not a+r/a+rx. See README.Debian, section CLAMAV-DAEMON, subsection WARNINGS. hard to stay out of the way of local admin changes. Making this change reverses that, and I am not comfortable with it. If you can come up with a good way to reconcile this, I'm happy to merge same problem with other pkgs - on ML it's said that it's each pkgs' init / admin script responsability to check for and in case make/adjust its own admin stuf under /var, as that's undoable elsewhere. So afaikt other pkgs have been / are going to be adjusted to refresh their dir trees under /var on (re)start. To be pedantically clear, people have discussed this on mailing lists, but no consensus was formed that this is even the right thing to do, much less that we should really begin implementing it, as far as I know. The only reason for doing this is that you have a root disk that has limited writes, and you want to put /var/run on a tmpfs - all other situations bring a lot of work for no gain. clamav is probably not something you want to run on such a resource limited machine, so I'm not sure I see the gain. During normal operation, the various clamav processes will write to /tmp/, /var/run/clamav/, /var/lib/clamav/, and /var/log/clamav/ and /dev/log. Why are we special casing /var/run/clamav/ ? So I see no problem to keep those lines in both init scripts. But likely should be moved up, @top of script after *.conf is read, which then should keep both uid gid of daemon. The package already has a common-functions bit for things that all the init scripts need. It's easy enough to add the right logic there, but I am not convinced that the current logic is correct, or that this is something clamav should try to support. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#406576: (clamav-daemon: init script fails if /var/run/clamav doesn't exist)
On Fri, Jan 12, 2007 at 11:52:31AM +, Stephen Gran wrote: ... And clamav-milter. Does this also need to be done for /var/log/clamav/ and /var/lib/clamav/ ? If not, why not? What benefits are you hoping for? forgot about this ... never used clamav-milter myself, and on local .deb build I've disabled depned+build. So I have to clues here. -- paolo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406576: (clamav-daemon: init script fails if /var/run/clamav doesn't exist)
On Fri, Jan 12, 2007 at 11:52:31AM +, Stephen Gran wrote: This should be doable, though. I'm not really all that sure that adding this feature buys us anything, though - see below for why. well, at present it'd ensure clamd starts, which isn't a minor gain. BTW man clam(d)scan don't stress the point that such util run as user clamav, hence won't be able to access file/dirs not a+r/a+rx. See README.Debian, section CLAMAV-DAEMON, subsection WARNINGS. point is, imo, that that infos belong to both due error msg from program and manpage. Users try to figure out prg usage by doing 'man prog' - I've seen several people clueless on clam*scan failure when trying to implement a mail filter. The only way to use clam*scan in such situation (whitout playing with chmod) is to pipe the the doc to the scanner. Though this mode of operation isn't documented in clamdscan.1 (but there's a e.g. in clamscan.1). I'm fine with tem to run as uid clamav, and would rather keep'em that way even on 1.x, but that should be better documented in main info pages and prg error msg (see eg cdrecord(1) warnings about non suid root mode). So afaikt other pkgs have been / are going to be adjusted to refresh their dir trees under /var on (re)start. To be pedantically clear, people have discussed this on mailing lists, but no consensus was formed that this is even the right thing to do, much less that we should really begin implementing it, as far as I know. Well, I didn't follow each bit and threads, my point is, that Etch is currently broken. I see your point reg. each pkg redoing one or more FHS dirs on restart, but as things are shipped right, without doing so several prgs won't (re)start on (re)boot. Nor on upgrade. processes will write to /tmp/, /var/run/clamav/, /var/lib/clamav/, and /var/log/clamav/ and /dev/log. Why are we special casing /var/run/clamav/ ? here's what I have on a netinstalled and freshly apt-get updated Etch notebook: $ mount -t tmpfs tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /var/lock type tmpfs (rw,size=4m) tmpfs on /var/run type tmpfs (rw,size=4m) so everything under /var/run vanishes on reboot. am not convinced that the current logic is correct, or that this is something clamav should try to support. then the pkg responsible for setting up fstab/tmpfs should be sanitized, removing the insane - as it turns out - idea of putting any FSH leaf on a tmpfs. Or perhaps that pkg should take care to rebuild the tree under that leaf. Else each and every pkg that's supposed to find a dir there either fail solid or need redo the tree on start. I'm pretty fine with doing away with the tmpfs. thanks -- paolo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406576: (clamav-daemon: init script fails if /var/run/clamav doesn't exist)
This one time, at band camp, Paolo said: On Fri, Jan 12, 2007 at 11:52:31AM +, Stephen Gran wrote: here's what I have on a netinstalled and freshly apt-get updated Etch notebook: $ mount -t tmpfs tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /var/lock type tmpfs (rw,size=4m) tmpfs on /var/run type tmpfs (rw,size=4m) so everything under /var/run vanishes on reboot. Look for RAMRUN and RAMLOCK - probably in /etc/default somewhere. Comment or set the variable to something other than yes. I agree this is a bad default. am not convinced that the current logic is correct, or that this is something clamav should try to support. then the pkg responsible for setting up fstab/tmpfs should be sanitized, removing the insane - as it turns out - idea of putting any FSH leaf on a tmpfs. Or perhaps that pkg should take care to rebuild the tree under that leaf. Else each and every pkg that's supposed to find a dir there either fail solid or need redo the tree on start. I'm pretty fine with doing away with the tmpfs. As am I. I will raise it again on the mailing lists and see what is going on. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#406576: (clamav-daemon: init script fails if /var/run/clamav doesn't exist)
On Fri, Jan 12, 2007 at 06:05:47PM +, Stephen Gran wrote:
tmpfs on /var/lock type tmpfs (rw,size=4m)
tmpfs on /var/run type tmpfs (rw,size=4m)
so everything under /var/run vanishes on reboot.
Look for RAMRUN and RAMLOCK - probably in /etc/default somewhere.
Comment or set the variable to something other than yes. I agree this
is a bad default.
eh, no RAMRUN/RAMLOCK anywhere but in /etc/init.d/{boot,mount}*. Totally
undoc'd, tried to zgrep the whole /doc* and /man*.
I guess the tmpfs entries in fstab are done on system install, once for all.
I'm pretty fine with doing away with the tmpfs.
As am I. I will raise it again on the mailing lists and see what is
going on.
currently I see
/etc/init.d/alsa: if ! mkdir --mode=755 /var/run/alsa ; then
/etc/init.d/clamav-daemon: mkdir -p /var/run/clamav
/etc/init.d/clamav-freshclam:mkdir -p /var/run/clamav
/etc/init.d/clamav-freshclam:[ -d /var/lib/ucf/cache ] || mkdir -p
/var/lib/ucf/cache
/etc/init.d/dirmngr:mkdir -p /var/run/dirmngr || return 1
/etc/init.d/ipsec:mkdir -p /var/run/pluto
/etc/init.d/vsftpd:[ -d /var/run/vsftpd ] || mkdir -p /var/run/vsftpd
don't know whether other pkgs are doing mkdir to address same issue, but
note that clamav-freshclam already checks/makes /var/lib/ucf/cache, so doing
same for /var/run/clamav doesn't look too exotic, after all.
Clearly the issue needs proper (policy?) addressing, and involves initscripts,
as it is unacceptable that eg setting RAMRUN breaks many pkgs.
thanks
--
paolo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406576: (clamav-daemon: init script fails if /var/run/clamav doesn't exist)
This one time, at band camp, Paolo said:
On Fri, Jan 12, 2007 at 06:05:47PM +, Stephen Gran wrote:
tmpfs on /var/lock type tmpfs (rw,size=4m)
tmpfs on /var/run type tmpfs (rw,size=4m)
so everything under /var/run vanishes on reboot.
Look for RAMRUN and RAMLOCK - probably in /etc/default somewhere.
Comment or set the variable to something other than yes. I agree this
is a bad default.
eh, no RAMRUN/RAMLOCK anywhere but in /etc/init.d/{boot,mount}*. Totally
undoc'd, tried to zgrep the whole /doc* and /man*.
I guess the tmpfs entries in fstab are done on system install, once for all.
Hmm. Me either, but I don't have a tmpfs mounted on /var/run. Reading
the init scripts, it looks like it won't do it unless RAMRUN is defined
somewhere. Odd that you can't find it. Take a look at a couple of init
scripts - `grep -rl RAMRUN` /etc/init.d will give you an idea where it's
referenced, and then you can build a list of files that are sourced, and
grep them.
don't know whether other pkgs are doing mkdir to address same issue, but
note that clamav-freshclam already checks/makes /var/lib/ucf/cache, so doing
same for /var/run/clamav doesn't look too exotic, after all.
This is an artifact of my common-functions implementation - if I write
reusable code that is needed in several of the packages, they all get
all the reusable functions. Those mkdir calls are actually only ever
run from postinstall scripts - the init scripts carry them as cruft that
saves me hours of repetetive copy and paste.
Clearly the issue needs proper (policy?) addressing, and involves initscripts,
as it is unacceptable that eg setting RAMRUN breaks many pkgs.
Agreed.
--
-
| ,''`.Stephen Gran |
| : :' :[EMAIL PROTECTED] |
| `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
-
signature.asc
Description: Digital signature
Bug#406576: clamav-daemon: init script fails if /var/run/clamav doesn't exist
Package: clamav-daemon Version: 0.88.7-1 Severity: important hi, clamav-daemon shares the volatile tmpfs problem as may other pkgs, ie /var/run/clamav vanishes on reboot. Fix is straightforward, in init script: start) +mkdir -m 0755 -p /var/run/clamav OPTIND=1 -- paolo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406576: (clamav-daemon: init script fails if /var/run/clamav doesn't exist)
start) +mkdir -m 0755 -p /var/run/clamav OPTIND=1 sorry, that'd be: start) +mkdir -p /var/run/clamav +chmod 0775 /var/run/clamav +chown root:clamav /var/run/clamav OPTIND=1 -- paolo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406576: (clamav-daemon: init script fails if /var/run/clamav doesn't exist)
This one time, at band camp, Paolo said: start) +mkdir -m 0755 -p /var/run/clamav OPTIND=1 sorry, that'd be: start) +mkdir -p /var/run/clamav +chmod 0775 /var/run/clamav +chown root:clamav /var/run/clamav OPTIND=1 I have so far stayed away from this issue, since it is quite possible to have clamd and freshclam run as seperate users, but they share both /var/log/clamav and /var/run/clamav. The packaging so far tries very hard to stay out of the way of local admin changes. Making this change reverses that, and I am not comfortable with it. If you can come up with a good way to reconcile this, I'm happy to merge it. Thanks for the report, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
