[Logcheck-devel] moving rules out of logcheck-database into the packages

martin f krafft madduck at debian.org
Tue Jul 4 15:36:40 UTC 2006


also sprach Jamie L. Penman-Smithson <lists at silverdream.org> [2006.07.04.1652 +0200]:
> If you check the archives of logcheck-devel, you'll see that this
> has  already been discussed in the past.

Mh, I forgot to mention, but I was unable to access the list
archives yesterday, a problem that was later solved over IRC.

Looking now, I cannot find anything else than

  http://marc.theaimsgroup.com/?l=logcheck-devel&m=114076370027770&w=2

but that thread gave me a new idea... see below

> Moving logcheck rules into packages means that people get logcheck  
> rules whether they use logcheck or not..

This applies to other aspects of the system... PPP, resolvconf,
apache, etc.

> A possible solution to your gripe is a "which rules (do you|do you
> not) want installed" question in debconf.

Yes, and a split of rule files like postfix into postfix-2.1 throuh
postfix-2.3.

Also -- but it's probably way too late for that -- a common prefix
for all files installed by logcheck-database would be helpful, and
it would make it much easier for maintainers to start providing
their own rule files without a file conflict.

Finally -- and here's the idea I mentioned above --, we could do
without debconf because we *have* a database to query for which
rules to run: dpkg. So if we make logcheck only run rules for
packages that are installed and configured, I would be much happier.
And it would be preferable, because then I wouldn't e.g. configure
logcheck, disable foo, a year later, install foo, get swamped, then
reconfigure.

> Some maintainers don't want to have to maintain logcheck rules.
> Most  don't use logcheck. They forget to update the rules until
> a bug is  filed, this is essentially the same situation as we have
> now, except  that maintenance of logcheck rules is outsourced.

Then we help these maintainers. I agree this is a point, but the
question I am raising is more about the distribution channel, not
about the maintenance burden.

> Having logcheck rules moved out of logcheck breaks dedicated
> loghosts.

If the goal is to support logcheck on loghosts (which sounds weird
to me), then you should make it policy that *no* packages provide
rule files.

> It also makes it more difficult, or even impossible, for  people
> to use logcheck on a different OS, since they will no longer  have
> any logcheck rules to use.

Well, so far there are no rule files for other OS in the CVS, so
I don't see this argument.

> While I agree that Debian should be our primary focus, I don't
> think  we should just abandon everyone who does not use Debian
> without a  _very good_ reason for doing so.

Fundamentally agreed. I just very much dislike the current logcheck
situation. I find a bug in /etc/logcheck/*/* and I can't just infer
the name of the package from the file name; I look at rule files and
notice that they're basically append-and-error-correct-only and
hardly ever see lines removed because we have to support potentially
3-5 different versions from one package; I encounter rules that are
just plain annoying because they are either so inconsistent, or just
carelessly put together. I realise this will require manual work
(and I am willing to help out), but it's just a lot easier for me to
work on modules than it is to work on a large chunk like
logcheck-database is now.

Are there other voices?

-- 
 .''`.     martin f. krafft <madduck at debian.org>
: :'  :    proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"der glaube an den kausalnexus ist der aberglaube"
                                                       -- wittgenstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature (GPG/PGP)
Url : http://lists.alioth.debian.org/pipermail/logcheck-devel/attachments/20060704/6473dbd4/attachment.pgp 


More information about the Logcheck-devel mailing list