Bug 476239 - Shorewall log is not directed to /var/log/messages
Shorewall log is not directed to /var/log/messages
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: rsyslog (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Jonathan Underwood
Fedora Extras Quality Assurance
http://www.shorewall.net
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-12 11:59 EST by Răzvan Sandu
Modified: 2009-11-18 08:47 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-18 08:47:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
shorewall.conf (4.03 KB, text/plain)
2009-01-06 11:06 EST, Răzvan Sandu
no flags Details
The rsyslog.conf, as required (2.68 KB, text/plain)
2009-01-10 09:57 EST, Răzvan Sandu
no flags Details

  None (edit)
Description Răzvan Sandu 2008-12-12 11:59:47 EST
Hello,


Description of problem:

After upgrading to latest shorewall (during F9 -> F10 update), shorewall log goes to the console instead of going into /var/log/message.

As a consequence, one cannot use console, because it is continously "garbled".


Version-Release number of selected component (if applicable):
shorewall-4.2.2-1.fc10.noarch


Actual results:
After upgrade, console screen is continuosly garbled by the output of the shorewall log, instead ob being redirected to /var/log/messages.

Expected results:
Shorewall log should go into /var/log/messages or in a specialised log, if so chosen.


Thanks a lot,
Răzvan
Comment 1 Jonathan Underwood 2008-12-13 06:24:53 EST
Hm, that's bizarre - I don't see that behaviour at all. Can you describe your set up - what exactly are you doing when you see this output to the terminal?
Comment 2 Răzvan Sandu 2008-12-13 06:51:50 EST
Hello and thanks,

I'm doing nothing special.

I've just upgraded the system from F9 to F10 (via official DVD).

Now the output of shorewall goes to the console instead of the /var/log/messages file (not on *all* machines, on *some* of them). The output consists, mainly, from packets logged by shorewall, accepted or rejected, as requested by /etc/shorewall/rules. Since the machine is a production one, exposed to net, this output means high volume, a continuous flow.

Is there any parameter (debugging, maybe) in /etc/shorewall/shorewall.conf that I should check ?

Thanks again,
Răzvan
Comment 3 Jonathan Underwood 2008-12-13 07:08:44 EST
Have a read of:

http://www.shorewall.net/FAQ.htm#faq16

that may be some help.

Another thing to check is that you've not misconfigured syslog. This is very unlikely to be a shorewall bug.
Comment 4 Răzvan Sandu 2008-12-16 19:01:04 EST
Hello,

Thanks for your information !

However, please note that I didn't perform *any* manual modification between Fedora 9 and Fedora 10. Just a normal upgrade, via official F10 DVD - that's all. In F9 I had no problem, in F10 yes.

Could you please suggest where to look ? Maybe a newer version of syslogd's configuration file is needed and this was not rewritten by rpm upgrade ?

Maybe some log is full and not cleared/rotated ? This machine has *a lot* of log entries, because it's a busy server...


Regards,
Răzvan
Comment 5 Jonathan Underwood 2008-12-17 19:21:09 EST
Well, without a lot more information on your configuration (eg shorewall dump), and how you've set rsyslog up, what the messages being logged are, it's a bit difficult to help you further. It's certainly something you've misconfigured though - shorewall itself just sends log messages to rsyslog, and then rsyslog decides what to do with them based on how they're characterized.

Have you changed any of the options in shorewall.conf referring to logging from their default values? If so, I recommend putting them back to their defaults for now and then changing each one until you work out the problem.

is rsyslogd running? (ps aux | grep rsyslogd)

Have you read this thread:

http://www.mail-archive.com/shorewall-users@lists.sourceforge.net/msg03001.html
Comment 6 Jonathan Underwood 2008-12-29 05:26:18 EST
Closing as NOTABU, but please feel free to re-open if you're able to provide more information and/or demonstrate this is a bug with shorewall.
Comment 7 Răzvan Sandu 2009-01-06 10:05:28 EST
Hello,


Please help me find a positive solution to this.

Probably it's a syslog matter, not shorewall, but the problem remains.

I did nothing more than upgrading a functional F9 to F10, via official DVD. Apparently, nothing went wrong during upgrade - then this phenomenon occured.

No configuration file from the logging system was manually edited - all eventual modifications went via rpm, during package upgrade.

Today I've hit this on a second machine, in same conditions.

If there is an issue in the logging system, I'll be happy to help debugging - only instruct me where to look, please.

Reopening this and reassigning to rsyslog...


Thanks a lot,
Răzvan
Comment 8 Jonathan Underwood 2009-01-06 10:25:05 EST
Note that if you haven't changed any of the LOG variables in shorewall.conf, then the logging messages generated by the kernel as priority level 6/info. The relevan t part of man shorewall.conf is:

       Many options have as their value a log-level. Log levels are a method
       of describing to syslog (8) the importance of a message and a number of
       parameters in this file have log levels as their value.

       These levels are defined by syslog and are used to determine the
       destination of the messages through entries in /etc/syslog.conf (5).
       The syslog documentation refers to these as "priorities"; Netfilter
       calls them "levels" and Shorewall also uses that term.

       Valid levels are:

                  7       debug
                  6       info
                  5       notice
                  4       warning
                  3       err
                  2       crit
                  1       alert
                  0       emerg

       For most Shorewall logging, a level of 6 (info) is appropriate.
       Shorewall log messages are generated by NetFilter and are logged using
       facility ´kern´ and the level that you specifify. If you are unsure of
       the level to choose, 6 (info) is a safe bet. You may specify levels by
       name or by number.
Comment 9 Răzvan Sandu 2009-01-06 11:05:26 EST
Thanks,

Please see attached the /etc/shorewall/shorewall.conf file - upon me, has nothing strange.

In /etc/shorewall/rules I have macros with ":info", such as:

POP3/ACCEPT:info     net                   $FW


Regards,
Răzvan
Comment 10 Răzvan Sandu 2009-01-06 11:06:08 EST
Created attachment 328291 [details]
shorewall.conf
Comment 11 Jonathan Underwood 2009-01-06 11:21:39 EST
Right, nothing unusual about the logging options in shorewall.conf. 

Next thing to look at is /etc/rsyslog.conf

Also, what happens if as root you do this command:

logger -p kern.info TESTKERNMESSAGE

Do you see TESTKERNMESSAGE on the console, or in /var/log/messages, or both?
Comment 12 Răzvan Sandu 2009-01-10 09:53:50 EST
Hello,

I'll attach below the actual /etc/rsyslog.conf.

The output of "logger -p kern.info TESTKERNMESSAGE" DOES show up in the log when I do a:

tail -f /var/log/messages

(via ssh, 'cause I cannot use the physical console), but it DOESN'T show up on the garbled physical screen.

Many thanks,
Răzvan
Comment 13 Răzvan Sandu 2009-01-10 09:57:25 EST
Created attachment 328625 [details]
The rsyslog.conf, as required
Comment 14 Bug Zapper 2009-11-18 05:27:22 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 15 Jonathan Underwood 2009-11-18 08:47:13 EST
Closing as insufficent data - can't reproduce, no new info from reporter.

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