Your message dated Sat, 16 Aug 2025 12:19:18 +0100 with message-id <CAJ3BuoR=E7OqJGq=sxvsgc8nhe7_6any6ltuvz0pxfrh4id...@mail.gmail.com> and subject line Re: wontfix, but patches considered has caused the Debian Bug report #215640, regarding logcheck: documentation confusing/contradictory to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 215640: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=215640 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: logcheck Version: 1.2.15 Severity: minor Just in case you aren't already aware of this (I see the note about documentation being updated as time permits): I'm a bit puzzled after reading through the documentation on several points: 1) what is the order of loglevels from most to least output? 2) are ignore files from one level included in the ignore list for other levels? How? 3) What is the significance of the different types of security warnings and how do they interact (193485 already covers some of this)? /etc/logcheck has cracking, ignore, violations. logcheck.conf refers to ATTACKS, VIOLATIONS, and EVENTS. How are all these related? 4) How should Debian system administrators modify the rules for their own situation, to preserve maximum upgradeability? (Perhaps the information in README.Maintainer is relevant for this audience to, or could be made relevant)? 5) How can the set of logfiles that is scanned be expanded or controlled? (looks like logcheck.logfiles, but should be in the README or man page) The later items in the preceding list are just absent, but for the first two there is contradictory material. Here are some of the relevant statements: 1) README.Debian ------------------------ The reportlevel (that is, the degree of filtering applied to "routine" system events) can be reduced from the default by changing the line: REPORTLEVEL="server" to: REPORTLEVEL="workstation" or the more secure: REPORTLEVEL="paranoid" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This seems to say server has a fair amount of filtering, workstation less, and paranoid the least amount of filtering. So in terms of output: server < workstation < paranoid But README.logcheck says "paranoid" is "high verbosity," server intermediate, and workstation the least amount of output: workstation< server < paranoid A priori the order isn't clear to me: servers are more likely to be attacked, and have more routes open for attack, so you might want more logs with them. But they also have more routine activity that you wouldn't want to know about, so maybe their logs should have more filtered out. 2) README.logcheck says (in REPORTLEVEL section) that workstation applies all filters in workstation, server, and paranoid. It says server applies all in server and paranoid, and paranoid only does paranoid. That makes it sound as if the program automatically merges the different directories, as appropriate. README.Maintainer says "As the higher level ignore.d directories include the lower levels (i.e. server = server + paranoid) you should try to split your rulefile between the different ignore.d directories." That makes it sound as if the directories are somehow combined on the disk by the directory structure or symlinks. It's unclear whether "higher level" refers to higher level in directory structure, higher level of logging, or higher level of filtering. It adds "Packages should not install symlinks between the ignore.d directories but install separate files into each level; note that it is no longer necessary anyway for rules to be repeated in each ignore.d.* directory." That says it's not symlinks, and sort of sounds as if the 3 levels cumulate because the same files appear in each of the directories. In other words, they cumulate because of the way the files happen to be defined, and they might not cumulate if they were redefined. But then it says they don't need to be repeated, so it's uncertain what it means. Obviously these discussions also bear on which set of filters is most restrictive (question 1). Thanks for your work on the package. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux iron 2.4.20 #1 SMP Thu Jun 26 15:57:25 PDT 2003 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages logcheck depends on: ii cron 3.0pl1-81 management of regular background p ii debconf 1.3.14 Debian configuration management sy ii debianutils 2.5.5 Miscellaneous utilities specific t ii exim4-daemon-lig 4.22-5 Lightweight version of the Exim (v ii lockfile-progs 0.1.9 Programs for locking and unlocking ii logcheck-databas 1.2.15 A database of system log rules for ii logtail 1.2.15 Returns parts of logfiles that hav ii mailx 1:8.1.2-0.20030521cvs-1 A simple mail user agent ii sysklogd [system 1.4.1-10 System Logging Daemon -- debconf information: logcheck/changes: * logcheck/install-note:
--- End Message ---
--- Begin Message ---On Sun, 10 Nov 2024 18:51:15 +0000 Richard Lewis <[email protected]> wrote: > On Sat, 21 Oct 2006 18:26:44 +0200 martin f krafft <[email protected]> wrote: > > tags 215640 help wontfix > > thanks > > > > I won't fix this but will gladly consider patches. > > I think this should just be closed, the manpage has been amended in > the last 20 years > > closing on this basis. If there are other improvements to the documentation, please open a new bug with the details and i will gladly help
--- End Message ---
