Bug 476239

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?

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

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.

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

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

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.

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

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.

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

Created attachment 328291 [details]
shorewall.conf

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?

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

Created attachment 328625 [details]
The rsyslog.conf, as required

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

Closing as insufficent data - can't reproduce, no new info from reporter.