Il Sun, Dec 17, 2023 at 09:52:53PM +0000, Richard Lewis scrisse:

Apologise me....

During this morning, for every test logcheck sent me the email.

This times, also without the -l option, I saw the logs so I waited the cron
if something was changed.

The logs lines there are, but after the header I see many blank lines: I
use mutt in a full screen console (more than 50 lines) and I need to press
page down for 16 times before reach the first line of logs (in the last one
email).

So I suppose that in this days the logs there have been, but I never
thought to press page down :(

Now the question may be: why I have tens of blank lines? Is it mutt?

Down I leave anyway the answers I wrote before find the blank lines just to
completion your questions.

If you think, close the bug.

Sorry and thanks for your time.

Stefano

> On Sun, 17 Dec 2023 at 19:03, Stefano Callegari
> <ste.calleg...@tiscali.it> wrote:
> > Il Fri, Dec 15, 2023 at 11:31:18PM +0000, Richard Lewis scrisse:
> > > On Fri, 15 Dec 2023 at 16:06, Stefano Callegari
> > > <ste.calleg...@tiscali.it> wrote:
> > >
> > > > from few days the email from cron are empty, there is only the 
> > > > header.txt.
> > >
> > > > /etc/logcheck <-bash> # su -s /bin/bash -c "/usr/sbin/logcheck -l 
> > > > /var/log/syslog" logcheck
> > > >
> > > > the email has the log lines. Without the -l option, still empty.
> > >
> > > Seems like it isnt checking the syslog -- what is in the files in
> > > /etc/logcheck/logcheck.logfiles.d/  and logcheck.conf ?
> >
> 
> > ~ <-bash> # ls /etc/logcheck/logcheck.logfiles.d/
> > journal.logfiles  syslog.logfiles
> 
> [snip] -- everything you posted looked fine and standard to me: it
> should be checking both syslog and the journal as expected
> 
> The only other thing you didn't include is a check of the permissions:
> there was a change in bookworm - i doubt that
> this is the issue, but for completeness:
> 
> the directory /etc/logcheck should be owned by logcheck:logcheck and
> permissions: drwxr-x---
> the contents should all be root:root and usual permissions, ie
> -rw-r--r-- (with subdirectories drwxr-xr-x)
> 
> (as long permissions allow logcheck to read everything, it should all be fine)

The permissions are exactly like those.

> 
> > > I suggest also using the -d option -- should say what it is doing in
> > > great detail (pipe to file or through less)
> >
> > I've tried! Many and many of lines, never ending, it seems a loop. I had to 
> > do a ^C.
> 
> Interesting - that definitely shouldnt happen, and '-d' shouldn't be
> doing anything 'extra' to cause that (is it definitely a loop or just
> looking like one because if your log contains lines that dont match
> any rules (will be reported in the email), logcheck has to check every
> single rules file, and -d will tell you the results before and after
> each rule file it uses: so it should look like it's printing the same
> output many times. to minimise the output, you can run once without
> -d, then do a 'logger foo' to ensure there's at lease one new line in
> the log and then re-run with -d)

Ok...

I've tried with a "clean" logcheck, than 'logger foo' and logcheck with -d.

The time are faster, but no redirect ( ...  > file) nor less ( ... | less)
save the output of logcheck (that instead I see on console).

> 
> The only potential for a loop that i can immediately think of would be
> if you had some kind of symlink loop in the rules directory - do you
> have any symlinks in the ignore.d.server or similar dirs (check with
> ls -laR)
> 

'ls -laR ignore.d.*' don't show symlink.

> i didnt think that could happen, i've no idea if logcheck would cope
> with that or not
> 
> Can you provide the start of the -d output /enough to understand what
> the loop is?  Otherwise, the start of the output should say what files
> it was checking, unfortunately, if there's an issue sending the issue,
> it likely wont be obvious until the very end.

As wrote over I can't "save" the output, but ^S and ^Q give me an help...
(don't consider the date because I exec logcheck more times to save with
copy&paste)

/etc/logcheck <-bash> # su -s /bin/bash -c "/usr/sbin/logcheck -d" logcheck 
DEBUG: [lun 18 dic 2023, 12:42:31, CET] Turning debug mode on
DEBUG: [lun 18 dic 2023, 12:42:31, CET] Sourcing - /etc/logcheck/logcheck.conf
DEBUG: [lun 18 dic 2023, 12:42:31, CET] Finished getopts 
c:dhH:l:L:D:m:opr:RsS:tTuvw
DEBUG: [lun 18 dic 2023, 12:42:31, CET] Using rules from the following 
REPORTLEVELs: server paranoid
DEBUG: [lun 18 dic 2023, 12:42:31, CET] Setting lockfile: 
/run/lock/logcheck/logcheck.lock
DEBUG: [lun 18 dic 2023, 12:42:31, CET] Running lockfile-touch 
/run/lock/logcheck/logcheck.lock
DEBUG: [lun 18 dic 2023, 12:42:31, CET] Using working dir: /tmp/logcheck.OBHh22
DEBUG: [lun 18 dic 2023, 12:42:31, CET] cleanrules /etc/logcheck/cracking.d => 
/tmp/logcheck.OBHh22/cracking
DEBUG: [lun 18 dic 2023, 12:42:31, CET] cleanrules: 
/etc/logcheck/cracking.d/kernel -> /tmp/logcheck.OBHh22/cracking/kernel
DEBUG: [lun 18 dic 2023, 12:42:31, CET] cleanrules: 
/etc/logcheck/cracking.d/rlogind -> /tmp/logcheck.OBHh22/cracking/rlogind
[... a serie of cleanrules: ...]
DEBUG: [lun 18 dic 2023, 12:48:13, CET] cleanrules: 
/etc/logcheck/ignore.d.paranoid/usb -> /tmp/logcheck.TqlJ8Y/ignore/usb
DEBUG: [lun 18 dic 2023, 12:48:13, CET] logoutput called with file: journal
DEBUG: [lun 18 dic 2023, 12:48:13, CET] Running journalctl  -q 
--since=@1702899989
DEBUG: [lun 18 dic 2023, 12:48:13, CET] logoutput called with file: 
/var/log/syslog
DEBUG: [lun 18 dic 2023, 12:48:14, CET] Running /usr/sbin/logtail2 on 
/var/log/syslog
DEBUG: [lun 18 dic 2023, 12:48:14, CET] logoutput called with file: 
/var/log/auth.log
DEBUG: [lun 18 dic 2023, 12:48:14, CET] Running /usr/sbin/logtail2 on 
/var/log/auth.log
DEBUG: [lun 18 dic 2023, 12:48:14, CET] Sorting logs
DEBUG: [lun 18 dic 2023, 12:48:14, CET] After sorting, we have the following 
log entries to check
--- START [ /tmp/logcheck.TqlJ8Y/logoutput-sorted (LINES: 97) ] ---
[... log lines ...]
dic 18 12:48:10 G5045 irqbalance[5452]:
--- END [ /tmp/logcheck.TqlJ8Y/logoutput-sorted (LINES: 97) ] ---

DEBUG: [lun 18 dic 2023, 12:48:14, CET] Adding a header to the report
--- START [ /etc/logcheck/header.txt (LINES: 4) ] ---
This email is sent by logcheck. If you no longer wish to receive
such mail, you can either uninstall the logcheck package or modify
its configuration file (/etc/logcheck/logcheck.conf).

--- END [ /etc/logcheck/header.txt (LINES: 4) ] ---

DEBUG: [lun 18 dic 2023, 12:54:10, CET] Checking for cracking alerts (Security 
Alerts) using cracking.d
DEBUG: [lun 18 dic 2023, 12:54:10, CET] greplogoutput 
(/tmp/logcheck.TqlJ8Y/cracking Security Alerts): Starting
DEBUG: [lun 18 dic 2023, 12:54:10, CET] greplogoutput: Using 
/tmp/logcheck.TqlJ8Y/cracking/kernel to find entries to report
--- START [ /tmp/logcheck.TqlJ8Y/cracking/kernel (LINES: 1) ] ---
kernel: Oversized packet received from
--- END [ /tmp/logcheck.TqlJ8Y/cracking/kernel (LINES: 1) ] ---
[... cut here ...]

Unfortunately I tried many way to store the output, but notin to do. I hope
the few line over help you.
> 
> the only other thing i can think of is a disk space issue (i could
> imaging bad things happening if /tmp was full, or wherever the mta
> stores the email - /var or similar)

A full disk/partition was a doubt that I check immediately.

> 
> (you could email it to me if you want to avoid it appearing in the
> public bts - up to you: i wouldnt expect there to be anything too
> sensitive in the logs, but i suppose we cant rule that out).

Thanks
-- 
Stefano Callegari
GnuPG Public Key Server: pgp.mit.edu

Reply via email to