Bug 234767 - Unmatched Entries in mails since sysklogd 1.4.2-3/#223573
Unmatched Entries in mails since sysklogd 1.4.2-3/#223573
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: logwatch (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ivana Varekova
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-01 14:22 EDT by Robert Scheck
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-13 09:55:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Parts from /var/log/secure (1.64 KB, text/plain)
2007-04-06 07:07 EDT, Robert Scheck
no flags Details

  None (edit)
Description Robert Scheck 2007-04-01 14:22:49 EDT
Description of problem:
Since "include priority/facility in message (#223573)" in sysklogd 1.4.2-3 was 
introduced, logwatch mails are broken, e.g.:

 --------------------- Connections (secure-log) Begin ------------------------


 **Unmatched Entries**
    Mar 31 08:58:50  tux sshd: Accepted password for robert from 192.168.0.29 
port 62620 ssh2: 1 Time(s)
    Mar 31 09:14:13  tux sshd: Accepted password for robert from 192.168.0.29 
port 62652 ssh2: 1 Time(s)
    Mar 31 09:47:37  tux sshd: Accepted password for robert from 192.168.0.29 
port 62673 ssh2: 1 Time(s)
    Mar 31 18:55:19  tux sshd: Accepted password for robert from 192.168.0.29 
port 61853 ssh2: 1 Time(s)
    Mar 31 20:04:13  tux sshd: Connection closed by 192.168.0.29: 1 Time(s)
    Mar 31 21:14:40  tux sshd: Accepted password for robert from 192.168.0.29 
port 63132 ssh2: 1 Time(s)

 ---------------------- Connections (secure-log) End -------------------------

Version-Release number of selected component (if applicable):
logwatch-7.3.4-2
sysklogd-1.4.2-3

How reproducible:
Everytime.

Actual results:
Unmatched Entries in mails since sysklogd 1.4.2-3/#223573

Expected results:
No unmatched entries.
Comment 1 Ivana Varekova 2007-04-02 10:07:48 EDT
Fixed in logwatch-7.3.4-3.fc7.
Comment 2 Robert Scheck 2007-04-05 09:24:23 EDT
Nope, not really, using logwatch-7.3.4-3 (installed on April 2nd), I got today 
this output within logwatch mail:

 --------------------- Connections (secure-log) Begin ------------------------


 **Unmatched Entries**
    Apr  4 08:11:00  tux sshd: Accepted password for robert from 192.168.0.29 
port 64128 ssh2: 1 Time(s)
    Apr  4 08:22:04  tux sshd: Accepted password for robert from 192.168.0.29 
port 64247 ssh2: 1 Time(s)
    Apr  4 08:36:35  tux sshd: Accepted password for robert from 192.168.0.29 
port 64500 ssh2: 1 Time(s)

 ---------------------- Connections (secure-log) End -------------------------
Comment 3 Robert Scheck 2007-04-05 09:27:36 EDT
Guessing the problem appears because of the two (!) spaces between time and the 
host name....
Comment 4 Ivana Varekova 2007-04-06 07:00:58 EDT
Please could you attach here the part of your /var/log/secure file which
contains the "accepted password" logs. Perhaps there is a problem with spaces
between the ip address and word port - but I'm not sure - there is a new line in
the comment so I'm not sure about the precise structure of these logs.  
Thanks.
Comment 5 Robert Scheck 2007-04-06 07:07:15 EDT
Created attachment 151867 [details]
Parts from /var/log/secure
Comment 6 Robert Scheck 2007-04-06 07:10:32 EDT
It's attached to this bug report now.
Comment 7 Ivana Varekova 2007-04-10 06:52:26 EDT
Thanks.
Fixed in logwatch-7.3.4-5.fc7.
Comment 8 Robert Scheck 2007-04-12 14:36:54 EDT
No, it is NOT fixed. I've no clue, what you did, but you didn't fix it correct 
- sorry.

 --------------------- Connections (secure-log) Begin ------------------------


 **Unmatched Entries**
    Apr 11 18:32:45  tux sshd: Failed password for robert from 192.168.0.29 
port 36689 ssh2: 1 Time(s)

 ---------------------- Connections (secure-log) End -------------------------

AND what is much more a problem, you are IGNORING the "useless" logs, which 
should be USED (instead of ignoring!) for the following section (SSHD) which
is MISSING since bug #223573 was built into Rawhide:

 --------------------- SSHD Begin ------------------------


 Users logging in through sshd:
    tux:
       192.168.0.1 (server.tux.netz): 1 time
    robert:
       192.168.0.1 (server.tux.netz): 4 times
       192.168.0.29 (robert.tux.netz): 3 times

 ---------------------- SSHD End -------------------------

I'll re-open this bug report until the SSHD section is brought back... ;-)
Comment 9 Robert Scheck 2007-04-12 14:42:37 EDT
I don't know what you tried to fix exactly, but I guess you didn't see the real 
problem, I tried to showed you, which unfortunately was introduced by sysklogd 
1.4.2-3/#223573:

Mar 29 07:04:04 tux sshd[19586]: ...
Mar 29 07:04:05 tux sshd[19586]: ...
Mar 29 07:13:57 tux su: ...
Mar 29 09:18:28  tux sshd[5069]: ...
Mar 29 09:18:28  tux sshd[5069]: ...
Mar 29 15:47:04  tux sshd[5069]: ...

Hey and today, sysklogd 1.4.2-4/#223573 was built in Rawhide and oho...the 
logging behaviour luckily was changed back:

Apr 12 20:19:37  tux su: ...
Apr 12 20:28:13  tux su: ...
Apr 12 20:28:15  tux su: ...
Apr 12 20:36:09 tux sshd[25708]: ...
Apr 12 20:36:09 tux sshd[25708]: ...
Apr 12 20:36:10 tux sshd[25708]: ...

Okay, so I'm expecting now, that you're reverting any fixes which were done to 
logrotate to solve this bug report...sorry ;-)
Comment 10 Robert Scheck 2007-04-12 14:47:23 EDT
Yepp, verified a few seconds ago. Dropping Patch4 (logwatch-7.3.4-secure.patch) 
will fix the stuff and bring back the SSHD section within logwatch mail.
Comment 11 Ivana Varekova 2007-04-13 09:55:34 EDT
Patch logwatch-7.3.4-secure.patch removes the unmatched entries from secure
service log - it is the right behavior- but you are right his logs should be
parsed in sshd service so the last version logwatch-7.3.4-6.fc7 parsed them too.
If there is any problem please reopen this bug.

Note You need to log in before you can comment on or make changes to this bug.