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

design issues in debian packages



Hello,

I have noticed two common problems in packages that continue to catch
my completely by surprise, and sometimes which prevent other packages
from functioning properly.

I am not sure what can be done about these issues, but think it is important
that I raise them here:


1) packages that create a new userid and send mail to that userid
without the administrator realizing. One great offender I just noticed
recently (and still have to fix) is cricket.

squid wasn't working (it complained not enough disk space). Each time,
I freed up more diskspace, so each time I freed up more. Eventually, I
realized that my /var/lib/cricket/Maildir/new was approx 1 gig big!

I had thought that any errors were getting logged (and rotated), but I
never realized that they were getting E-Mailed to "cricket" (once
every 5 minutes in fact) as well!

Suggestion: Any package that sends email to a private user should add
an entry to /etc/aliases for that user, so that the administrator can
keep track of where E-Mail maybe coming from, with no surprises.

Even better: I have going to try and work out how to disable these
E-Mails from cricket - I don't wont them, as everything is logged
anyway.



2) I found msyslog to be unreliable with log file rotation, so have
gone back to syslog.

When you remove a package (as distinct from purging it) I expect that
the package is not going to have any more effect, just some useless
config files will be kept around that are no longer useful because the
binaries have been removed. Wrong! These config files, I think tell a
different story:

snoopy:unstable:~# dpkg -L syslog-common
/var/lib/syslog-common
/etc/logrotate.d/syslog-common
/etc/devfs/devices.d/syslog-common

actually msyslog has hacked around the problem of
/etc/logrotate.d/syslog-common by renaming it to
/etc/logrotate.d/syslog-common.disabled (isn't modifying conffiles
like this against debian policy?), but I think this is a general issue
with storing config files like this in directories.

Sorry, I don't have any real good solutions either :-(.



Anyway, just my comments for today...


Brian May.



Reply to: