Bug#344553: [Logcheck-devel] Bug#344553: logcheck: Fails silently to read config file

[Markus Peuhkuri]

Maximilian Attems wrote:

>second you give _no_ argument why CONFFILE is so important.
>logcheck works fine without it.
>
>  
>
If config file is defined on command line argument, it should be read in
and an error given if it not readable.  If the config file exists, it
should be read.

>third the nacked change introduces potential break-ups on current
>working setups. we wont change semantics for $random_reasons.
>  
>
The case that gets broken is that if the /etc/logcheck/logcheck.conf is
not readable by logcheck user.  I do not know, if there is any setup
like that, but lets say it is a quite interesting setup.  I would value
clear error messages or at least warnings over that.

>we check about real reasons like not readable log files.
>thus are worth to alert the admin.
>  
>
I think that existing config file that is unreadable is something
abnormal,  but YMMV.

>fourth why is the debian userid managment fragile?
>works very nicely for me on lots of boxes.
>  
>
Maybe I just cannot do it, but as I had recently to do system reinstall
because of disk crash.  I recovered config files from backups but those
ended up with wrong ownerships and I had to fix them by hand.  The
system UIDs were different on different installations: the other was
installed, packages add, upgraded, and packages add while the later had
about all packages installed at once.

>fifth why did you change the ownerships of CONFFILE?
>there might be many cool reasons to think about,
>none was named.
>  
>
The problem was that I wanted to experiment with new config file.  It
was owned by my $LUSER UID, and then I ran "sudo -u logcheck logcheck -c
config -t ".  Unfortunatly, the config file was mode 600, and logcheck
did not provide any error, just used default settings and I was totaly
lost with that wondering why my changes were not visible.

One may change ownership of configuration file unintentionaly (pick you
$EDITOR right)

>first calm down your words.  :) 
>getting enerved is not a good way to push something.
>  
>
It was no intended such, more like emphasis what I value in building
robust systems (would *no* *case* been better?).  It is good that
package management makes sure that everything is ok, but each input must
be validated and checked for.