plan to push this upstream

[drzraf]

That would be helpful.
(See http://logcheck.org/git.html)

[ties]

This is something that I perhaps should have considered a long time ago. However I am not sure about some of these rules; they may no longer apply to current systems. That is why I did not seriously consider this before.

At least a first step is adding a license to this repository. Logcheck uses GPLv2. I personally think a more permissive license is a good pick for this repo (MIT), which should be compatible with GPLv2 (rules could be incorporated into GPLv2 project if i'm correct).

Do you agree?

[drzraf]

If rules are old then either: - they don't match which is already the case of many rules of upstream logcheck (I guess) and it's not grave - they match something which used to be ignorable but is now critical (I don't think there are such lines) About the licence it's all about your choice (although I personally prefer copyleft licences), but I guess "dual-licencing" (MIT/GPL) makes this more "mergeable". But those who want to keeps their changes private (but about these specific regexp only, not the other GPL-licenced lines) may do this under the MIT version. But don't quote me on this.

[skangas]

This is something that I perhaps should have considered a long time ago. However I am not sure about some of these rules; they may no longer apply to current systems. That is why I did not seriously consider this before.

Any progress on this? It would be nice to see.

At least a first step is adding a license to this repository. Logcheck uses GPLv2. I personally think a more permissive license is a good pick for this repo (MIT), which should be compatible with GPLv2 (rules could be incorporated into GPLv2 project if i'm correct).

Do you agree?

Yes, the MIT license is compatible with the GPL.

[ties]

This is something that I perhaps should have considered a long time ago. However I am not sure about some of these rules; they may no longer apply to current systems. That is why I did not seriously consider this before.

Any progress on this? It would be nice to see.

I completely forgot about this and I gave this a look just now. Unfortunately a lot of the reference urls for logcheck (e.g. from https://github.com/icyfork/logcheck/blob/master/debian/README.Debian) have rotted.

I think the current authoritative reference is https://salsa.debian.org/debian/logcheck & https://tracker.debian.org/pkg/logcheck which seem to have low activity. I'm watching the salsa.debian.org repo and will check it for activity. If it active I may clean up my rules and upstream them.

[skangas]

I think the current authoritative reference is https://salsa.debian.org/debian/logcheck & https://tracker.debian.org/pkg/logcheck which seem to have low activity. I'm watching the salsa.debian.org repo and will check it for activity. If it active I may clean up my rules and upstream them.

Thanks. But shouldn't there be even more incentive to upstream your rules if there's low activity? I notice that a lot of informational messages are slipping through in the default Debian set. A lot of users would benefit from the work of integrating this.

[ties]

I've sent an email.

But while I'm sure my rules significantly reduce the amount of noise that logcheck makes I'm not sure my rules are up to the standards for their repo.

Perhaps we could package it as an debian package that you could easily add and keep up to date?

[ties]

I go a quick reply from the maintainer of the project. The summary is that the rules in this repository do not fit the guidelines for the upstream project.

The idea for the upstream rules is that they should apply for all users. The example given was that some users may want to ignore restarts of the ssh daemon, yet for others this may indicate an issue. That is why the default rulesets do not ignore (most) restarts.

In my words, the defaults rule err on the side of caution, preferring false positives over false negatives. And they prefer not to add outdated rules.

Some of the guidelines for new rules for upstream are:

• rules must be as specific as possible (i.e. no .* matching)
• rules for debug messages are not added
• the ignored messages should be related to package versions in Debian unstable
• the ignored messages are not temporary (e.g. due to a but in the packages)
• the ignored messages are not related to startups/shutdowns/restarts
• error/warning/notice messages are usually not ignored
• the rule request should contain example messages and an explanation
  why the messages can be ignored in general

Unfortunately that is not the status of my repo right now. And it is almost impossible to refactor ten years of rules to match this requirement (especially since mine are partially for ubuntu instead of debian stable).

I think packaging this repo as a debian/ubuntu package would be a good step though.