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

Re: packaging spambouncer - cronjob updates in /usr???



also sprach Carlos Laviola <claviola@debian.org> [2002.01.06.2034 +0100]:
> > if i package spambouncer so that a configurable cronjob obtains updates
> > on the anti-spam rules and databases from the spambouncer website, then
> > the files can't remain in /usr, right?
> 
> Are you sure you want to do this?  What about all those people who
> filter with spambouncer, but are dial-up users?  You need to either
> have your job run when a PPP link is up, or ask the user if he's on a
> LAN/has direct access to the Internet before doing this.

of course, sorry i excluded that. it'll be a setup similar to snort.

actually, what speaks against:

(1) ask user if cronjob should be installed.
    y --> ask for frequency
          install cronjob
(2) in addition, add some smart update script to ip-up.d. with smart i
    mean that it would only fetch once a week...

the standard dialup user won't be affected by the cronjob (that fails),
if it doesn't flood them with emails. the only people who should worry
about this are the ones that have pppd set to autodial, or the ones who
use diald or the like. they'll be specifically addressed by debconf and
can disable cronjob...

> > the primary candidate for installation of spambouncer is
> > /usr/share/spambouncer, but /usr/lib/spambouncer might be better. in any
> > case, since /usr should be ro-mountable, these files should really be
> > sitting in /var/lib, right? that would mean that the entire "program"
> > sits in /var. is this acceptable?
> 
> It isn't really a program, just a collection of filters, which are
> non-binary (thus, you'll only need to have a package which is
> Architecture: all).  I'd say that if you rely on a method to update
> your spambouncer definitions that ensures you that /usr is mounted,
> you'd have no problem putting it on /usr/share/spambouncer/ like
> procmail-lib does.

my problem with that is twofold: (a) /usr should be ro-mountable no
matter what, so /usr/share is not an option i feel. the second problem i
have is similar: tripwire, aide and co. - you'd have to explcitly
reconfigure tripwire if you allow periodic changes in /usr.

mh. it looks like there's no way around /var/lib since /usr/local is far
out of bounds.

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck
  
there's someone in my head but it's not me.
                        -- pink floyd, the dark side of the moon, 1972

Attachment: pgpDQQpScAQvN.pgp
Description: PGP signature


Reply to: