Hi Jonas, Jonas Smedegaard <d...@jones.dk> writes: >> 1) If you install kanla, you will start configuring it. If you don’t >> intend to use it, why install it? Or at least why have it enabled? > > Debian daemons should be configured for normal working condition by > default. I believe that's a "should" in Debian Policy. I agree with that in principle, but how would it be applicable to kanla? The package cannot know which things to monitor and where to send alerts to. There just is no way to have it in “normal working condition” unless you configure it.
>> 2) When first configuring kanla, it is helpful to have a quick way of >> testing that messages successfully arrive at the destination address, >> which this default setting provides. > > If one wants debugging output, onewould enable optional features for > that, not expect it to be enabled by default. I disagree. It is tempting and likely that without this message, people would configure kanla, say “this looks about right” and never get any alerts. Having a sightly annoying default configuration to err on the side of caution is the right thing, IMO. >> 4) When using systemd (and journald with that), you have logrotation by >> default (well, in Debian that is no persistent logging at all, and a >> memory ringbuffer currently). The legacy init support is >> intentionally quite sparse, because it doesn’t make sense to spend >> time on re-implementing the wheel in that area in 2013 (well, soon >> 2014 :)). > > Last I checked, systemd wasn't default in Debian. Please include in the > kanla package a logrotate snippet and recommend logrotate. I don’t have any non-systemd machine. If you care about such a setup, please submit a patch. Thanks! -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
