As is often the case with a new major release, we''ve accumulated a number of patches over the ten days that Shorewall 4.0.0 has been available. I''m releasing 4.0.1 to ease the patching/updating burden for people wishing to upgrade to Shorewall 4.0. Problems corrected in 4.0.1. 1) The Shorewall Lite installer was producing an empty shorewall-lite manpage. Since the installer runs as part of creating the RPM, the RPM also suffered from this problem. The 4.0.0 Shorewall-lite packages were re-uploaded with this problem corrected. 2) The Shorewall Lite uninstaller incorrectly removed /sbin/shorewall rather than /sbin/shorewall-lite. 3) Both the Shorewall and Shorewall Lite uninstallers did a "shorewall clear" if Shorewall [Lite] was running. Now, the Shorewall Lite uninstaller correctly does "shorewall-lite clear" and both uninstallers only perform the ''clear'' operation if the other product is not installed. This prevents the removal of one of the two products from clearing the firewall configuration established by the other one. 4) The ''ipsec'' OPTION in /etc/shorewall/hosts was mis-handled by Shorewall-perl. If the zone type was changed to ''ipsec'' or ''ipsec4'' and the ''ipsec'' option removed from the hosts file entry, the configuration worked properly. 5) If a CLASSID was specified in a tcrule and TC_ENABLED=No, then Shorewall-perl produced the following: Compiling... Use of uninitialized value in string ne at /usr/share/shorewall-perl/Shorewall/Tc.pm line 285, <$currentfile> line 18. ERROR: Class Id n:m is not associated with device eth0 : /etc/shorewall/tcrules (line 18) 6) If IPTABLES was not specified in shorewall.conf, Shorewall-perl was locating the binary using the PATH environmental variable rather than the PATH setting in shorewall.conf. If no PATH was available when Shorewall-perl was run and IPTABLES was not set in shorewall.conf, the following messages were issued: Use of uninitialized value in split at /usr/share/shorewall-perl/Shorewall/Config.pm line 1054. ERROR: Can''t find iptables executable ERROR: Shorewall restart failed 7) If the "Mangle FORWARD Chain" capability was supported, entries in the /etc/shorewall/ecn file would cause invalid iptables commands to be generated. This problem occurred with both compilers. 8) Shorewall now starts at reboot after an upgrade from shorewall < 4.0.0. Previously, Shorewall was not started automatically at reboot after an upgrade using the RPMs. 9) Shorewall-perl was generating invalid iptables-restore input when a log level was specified with the dropBcast and allowBcast builtin actions and when a log level followed by ''!'' was used with any builtin actions. 10) Shorewall-perl was incorrectly rejecting ''min'' as a valid unit of time in rate-limiting specifications. 11) Certain errors occurring during start/restart/safe-start/safe-restart/try processing could cause the lockfile to be left behind. This resulted in a 60-second delay the next time one of these commands was run. Other changes in Shorewall 4.0.1. 1) A new EXPAND_POLICIES option is added to shorewall.conf. The option is recognized by Shorewall-perl and is ignored by Shorewall-shell. Normally, when the SOURCE or DEST columns in shorewall-policy(5) contains ''all'', a single policy chain is created and the policy is inforced in that chain. For example, if the policy entry is #SOURCE DEST POLICY LOG # LEVEL net all DROP info then the chain name is ''net2all'' which is also the chain named in Shorewall log messages generated as a result of the policy. If EXPAND_POLICIES=Yes, then Shorewall-perl will create a separate chain for each pair of zones covered by the policy. This makes the resulting log messages easier to interpret since the chain in the messages will have a name of the form ''a2b'' where ''a'' is the SOURCE zone and ''b'' is the DEST zone. See http://linuxman.wikispaces.com/PPPPPPS for more information. 2) The Shorewall-perl dependency on the "Address Type Match" capability has been relaxed. This allows Shorewall 4.0.1 to be used on releases like RHEL4 that don''t support that capability. 3) Shorewall-perl now detects dead policy file entries that result when an entry is masked by an earlier entry. Example: all all REJECT info loc net ACCEPT 4) Recent kernels are apparently hard to configure and we have been seeing a lot of problem reports where the root cause is the lack of state match support in the kernel. This problem is difficult to diagnose when using Shorewall-perl so the generated shell program now checks specifically for this problem and terminates with an error if the capability doesn''t exist. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:>Other changes in Shorewall 4.0.1. > >1) A new EXPAND_POLICIES option is added to shorewall.conf. The > option is recognized by Shorewall-perl and is ignored by > Shorewall-shell. > > Normally, when the SOURCE or DEST columns in shorewall-policy(5) > contains ''all'', a single policy chain is created and the policy is > inforced in that chain. For example, if the policy entry is > > #SOURCE DEST POLICY LOG > # LEVEL > net all DROP info > > then the chain name is ''net2all'' which is also the chain named in > Shorewall log messages generated as a result of the policy. If > EXPAND_POLICIES=Yes, then Shorewall-perl will create a separate > chain for each pair of zones covered by the policy. This makes the > resulting log messages easier to interpret since the chain in the > messages will have a name of the form ''a2b'' where ''a'' is the SOURCE > zone and ''b'' is the DEST zone. See > http://linuxman.wikispaces.com/PPPPPPS for more information.Am I right in thinking that this means we can now leave out all those "x y drop" policies that are only in there for logging/debugging purposes ? Nice :-) ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Simon Hobson wrote:> Am I right in thinking that this means we can now leave out all those > "x y drop" policies that are only in there for logging/debugging > purposes ?Yes.> > Nice :-) >I thought so too. This was Paul''s idea. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
> > 2) The Shorewall-perl dependency on the "Address Type Match" > capability has been relaxed. This allows Shorewall 4.0.1 to be used > on releases like RHEL4 that don''t support that capability. >Hi, The problem with RHEL4 is that the iptables rpm build was broken when RedHat shipped the first RHEL4. I don''t know how they managed to break it that way but I guess RH has built the original iptables rpm on a buildhost which lacked the correct kernel module ipt_addrtype.ko and therefore the iptables rpm didn''t build the libipt_addrtype.so lib. For those who care, I have built fixed packages here (i386 only): http://www.invoca.ch/pub/packages/shorewall/iptables_for_rhel4/ Regards, Simon ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> Simon Hobson wrote: > >> Am I right in thinking that this means we can now leave out all those >> "x y drop" policies that are only in there for logging/debugging >> purposes ? > > Yes. > >> Nice :-) >> > > I thought so too. This was Paul''s idea.I suppose i had better change my PPPPPPS page now... -- Paul <http://paulgear.webhop.net> -- Did you know? Email viruses spread using addresses they find on the host computer. You can help to reduce the spread of these viruses by using Bcc: instead of To: on mass mailings, or using mailing list software such as mailman (http://www.list.org/) instead. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Using: shorewall-perl-4.0.1-2 shorewall-4.0.1-2 I have tried everything that I can think of to stop shorewall from puking to the console. I get dozens if not hundreds of these directed to the console: Aug 6 07:34:13 backup kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:30:48:2f:a5:ca:00:06:53:10:18:01:08:00 SRC=124.205.138.109 DST=xx.xx.xxx.46 LEN=404 TOS=0x00 PREC=0x20 TTL=108 ID=21755 PROTO=UDP SPT=1031 DPT=1434 LEN=384 Aug 6 07:47:48 backup kernel: Shorewall:net2all:DROP:IN=eth0 OUT= MAC=00:30:48:2f:a5:ca:00:06:53:10:18:01:08:00 SRC=193.251.8.253 DST=xx.xx.xxx.46 LEN=60 TOS=0x00 PREC=0x20 TTL=47 ID=416 DF PROTO=TCP SPT=38770 DPT=5901 WINDOW=5840 RES=0x00 SYN URGP=0 I''ve implemented everything here (CentOS-5): http://www.shorewall.net/FAQ.htm#faq16 Tip Under RedHat and Mandriva, the max log level that is sent to the console is specified in /etc/sysconfig/init in the LOGLEVEL variable. Set “LOGLEVEL=5” to suppress info (log level 6) messages on the console. /etc/sysconfig/init LOGLEVEL=5 /etc/rc.d/rc.sysinit # Fix console loglevel if [ -n "$LOGLEVEL" ]; then /bin/dmesg -n $LOGLEVEL fi I''ve rebooted, made sure all "*_LOGLEVEL=" in shorewall.conf are empty, LOG_MARTIANS=No and so on, but everything that is logged to kernel.log is echoed to the console. Obviously I must be doing something wrong, but for the life of me I can''t figure out what it would be. Thanks for any help, John _________________________________________________________________ Now you can see trouble…before he arrives http://newlivehotmail.com/?ocid=TXT_TAGHM_migration_HM_viral_protection_0507 --===============1193944474=Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ --===============1193944474=Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline
It''s what is defined as console at boot-up that got sent all debug message... This one is usually set by the kernel or ulog upon booting - and on the boot-prompt, you tell the kernel where to send the log-messages. By default it goes to "console". I''m using it actually quite heavily on my servers - to redirect output to a serial-device... In my grub boot-prompt, here is what I have: title Ubuntu, 2.6.15-28-686 (hd0,0) root (hd0,0) kernel /vmlinuz-2.6.15-28-686 root=/dev/md1 ro resume=/dev/md5\ console=tty0 console=ttyS0,115200n8 initrd /initrd.img-2.6.15-28-686 savedefault boot Here you can see that I have a console=ttyS0 and console=tty0 giving me the possibility upon boot to select the kernel to boot through serial console or console directly. Note that dmesg message will always be sent to the last entry in the line. Try playing with this a little ... Cheers Joerg J and T wrote:> Using: > > shorewall-perl-4.0.1-2 > shorewall-4.0.1-2 > > I have tried everything that I can think of to stop shorewall from > puking to the console. I get dozens if not hundreds of these directed to > the console: > > Aug 6 07:34:13 backup kernel: Shorewall:net2all:DROP:IN=eth0 OUT> MAC=00:30:48:2f:a5:ca:00:06:53:10:18:01:08:00 SRC=124.205.138.109 > DST=xx.xx.xxx.46 LEN=404 TOS=0x00 PREC=0x20 TTL=108 ID=21755 PROTO=UDP > SPT=1031 DPT=1434 LEN=384 > > Aug 6 07:47:48 backup kernel: Shorewall:net2all:DROP:IN=eth0 OUT> MAC=00:30:48:2f:a5:ca:00:06:53:10:18:01:08:00 SRC=193.251.8.253 > DST=xx.xx.xxx.46 LEN=60 TOS=0x00 PREC=0x20 TTL=47 ID=416 DF PROTO=TCP > SPT=38770 DPT=5901 WINDOW=5840 RES=0x00 SYN URGP=0 > > I''ve implemented everything here (CentOS-5): > http://www.shorewall.net/FAQ.htm#faq16 > > Tip > > Under RedHat and Mandriva, the max log level that is sent to the console > is specified in /etc/sysconfig/init in the LOGLEVEL variable. Set > “LOGLEVEL=5” to suppress info (log level 6) messages on the > console. > > /etc/sysconfig/init > LOGLEVEL=5 > > /etc/rc.d/rc.sysinit > # Fix console loglevel > if [ -n "$LOGLEVEL" ]; then > /bin/dmesg -n $LOGLEVEL > fi > > I''ve rebooted, made sure all "*_LOGLEVEL=" in shorewall.conf are empty, > LOG_MARTIANS=No and so on, but everything that is logged to kernel.log > is echoed to the console. > > Obviously I must be doing something wrong, but for the life of me I > can''t figure out what it would be. > > Thanks for any help, > John-- ------------------------------------------------------------------------ | Joerg Mertin : smurphy@solsys.org (Home)| | in Forchheim/Germany : smurphy@linux.de (Alt1)| | Stardust''s LiNUX System : | | Web: http://www.solsys.org | ------------------------------------------------------------------------ PGP Fingerprint: AF0F FB75 997B 025F 4538 5AD6 9888 5D97 170B 8B7A ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
J and T wrote:> Using: > > shorewall-perl-4.0.1-2 > shorewall-4.0.1-2 > > I have tried everything that I can think of to stop shorewall from > puking to the console.Shorewall is not writing anything to your console. It is klogd that is writing to your console. Shorewall has no control over where particular log messages are written. Shorewall itself only generates a log message during start, restart, stop, etc.> I get dozens if not hundreds of these directed to > the console: > > Aug 6 07:34:13 backup kernel: Shorewall:net2all:DROP:IN=eth0 OUT> MAC=00:30:48:2f:a5:ca:00:06:53:10:18:01:08:00 SRC=124.205.138.109 > DST=xx.xx.xxx.46 LEN=404 TOS=0x00 PREC=0x20 TTL=108 ID=21755 PROTO=UDP > SPT=1031 DPT=1434 LEN=384Shorewall FAQ 17 will tell you that this is a message generated by your net->all entry in /etc/shorewall/policy.> > I''ve implemented everything here (CentOS-5): > http://www.shorewall.net/FAQ.htm#faq16 > > Tip > > Under RedHat and Mandriva, the max log level that is sent to the console > is specified in /etc/sysconfig/init in the LOGLEVEL variable. Set > “LOGLEVEL=5” to suppress info (log level 6) messages on the > console. > > /etc/sysconfig/init > LOGLEVEL=5 > > /etc/rc.d/rc.sysinit > # Fix console loglevel > if [ -n "$LOGLEVEL" ]; then > /bin/dmesg -n $LOGLEVEL > fi > > I''ve rebooted, made sure all "*_LOGLEVEL=" in shorewall.conf are empty, > LOG_MARTIANS=No and so on, but everything that is logged to kernel.log > is echoed to the console.Again -- This is not a really a Shorewall issue. Furthermore, some of the LOGLEVEL= settings have a non-empty default so if you set them to empty, they will default to some non-empty level. So the only way that you will be able to suppress those messages using Shorewall configuration changes is to set them to ''debug''.> > Obviously I must be doing something wrong, but for the life of me I > can''t figure out what it would be. >Given that twiddling dmesg on your Distribution didn''t suppress log level 6 messages being written to the console, you will need to look at your klogd configuration. You have all of the initialization scripts there on your system so you will need to determine how they work. Then with the help of ''man klogd'' you should be able to determine how to change the klogd configuration appropriately. I suspect that the hints in FAQ 16 for the other distributions will be helpful. And when you solve the problem, please report back with the solution so we can update the Hints in the FAQ. Thanks, -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
I didn''t mean to offend you Tom by saying Shorewall was puking on my console. I realize it is klogd. But I''ve been using Shorewall for years and now after upgrading only shorewall messages are being sent to the console. No other system messages are being sent to the console so I was confused as to why only Shorewall. I still can''t figure it out. I thought that possibly Shorewall was sending this as "critical" and that''s why it was seen on the console. Anyway I''m sorry to have said something that I shouldn''t have. I''ll try to track down the problem myself. Regards, John>>J and T wrote: > > Using: > > > > shorewall-perl-4.0.1-2 > > shorewall-4.0.1-2 > > > > I have tried everything that I can think of to stop shorewall from > > puking to the console. > >Shorewall is not writing anything to your console. It is klogd that is >writing to your console. Shorewall has no control over where particular log >messages are written. Shorewall itself only generates a log message during >start, restart, stop, etc. > > > I get dozens if not hundreds of these directed to > > the console: > > > > Aug 6 07:34:13 backup kernel: Shorewall:net2all:DROP:IN=eth0 OUT> > MAC=00:30:48:2f:a5:ca:00:06:53:10:18:01:08:00 SRC=124.205.138.109 > > DST=xx.xx.xxx.46 LEN=404 TOS=0x00 PREC=0x20 TTL=108 ID=21755 PROTO=UDP > > SPT=1031 DPT=1434 LEN=384 > >Shorewall FAQ 17 will tell you that this is a message generated by your >net->all entry in /etc/shorewall/policy. > > > > > I''ve implemented everything here (CentOS-5): > > http://www.shorewall.net/FAQ.htm#faq16 > > > > Tip > > > > Under RedHat and Mandriva, the max log level that is sent to the console > > is specified in /etc/sysconfig/init in the LOGLEVEL variable. Set > > “LOGLEVEL=5” to suppress info (log level 6) messages on the > > console. > > > > /etc/sysconfig/init > > LOGLEVEL=5 > > > > /etc/rc.d/rc.sysinit > > # Fix console loglevel > > if [ -n "$LOGLEVEL" ]; then > > /bin/dmesg -n $LOGLEVEL > > fi > > > > I''ve rebooted, made sure all "*_LOGLEVEL=" in shorewall.conf are empty, > > LOG_MARTIANS=No and so on, but everything that is logged to kernel.log > > is echoed to the console. > >Again -- This is not a really a Shorewall issue. Furthermore, some of the >LOGLEVEL= settings have a non-empty default so if you set them to empty, >they will default to some non-empty level. So the only way that you will be >able to suppress those messages using Shorewall configuration changes is to >set them to ''debug''. > > > > > Obviously I must be doing something wrong, but for the life of me I > > can''t figure out what it would be. > > > >Given that twiddling dmesg on your Distribution didn''t suppress log level 6 >messages being written to the console, you will need to look at your klogd >configuration. You have all of the initialization scripts there on your >system so you will need to determine how they work. Then with the help of >''man klogd'' you should be able to determine how to change the klogd >configuration appropriately. I suspect that the hints in FAQ 16 for the >other distributions will be helpful. > >And when you solve the problem, please report back with the solution so we >can update the Hints in the FAQ. > >Thanks, >-Tom >-- >Tom Eastep \ Nothing is foolproof to a sufficiently talented fool >Shoreline, \ http://shorewall.net >Washington USA \ teastep@shorewall.net >PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key >><< signature.asc >>>------------------------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. >Still grepping through log files to find problems? Stop. >Now Search log events and configuration files using AJAX and a browser. >Download your FREE copy of Splunk now >> http://get.splunk.com/>_______________________________________________ >Shorewall-users mailing list >Shorewall-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/shorewall-users_________________________________________________________________ Find a local pizza place, movie theater, and more….then map the best route! http://maps.live.com/default.aspx?v=2&ss=yp.bars~yp.pizza~yp.movie%20theater&cp=42.358996~-71.056691&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=950607&encType=1&FORM=MGAC01 --===============1767230311=Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ --===============1767230311=Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline
J and T wrote:> I didn''t mean to offend you Tom by saying Shorewall was puking on my > console.John, No offense was taken. I just wanted it to be clear, both to you and to future readers of this thread, that control of logging is outside of Shorewall.> I realize it is klogd. But I''ve been using Shorewall for years > and now after upgrading only shorewall messages are being sent to the > console. No other system messages are being sent to the console so I was > confused as to why only Shorewall. I still can''t figure it out. I > thought that possibly Shorewall was sending this as "critical" and > that''s why it was seen on the console.You can check on what level Shorewall is setting in LOG messages by: shorewall dump | grep LOG Example: 0 0 LOG 0 -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:INPUT:REJECT:'' 0 0 LOG 0 -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:FORWARD:REJECT:'' ... The ''level 6'' in these messages means log level 6 which is ''info''.> > Anyway I''m sorry to have said something that I shouldn''t have. I''ll try > to track down the problem myself. >Not at all. I apologize if I gave that impression. In my own defense, I''ve been up for most of the last 30 hours; I had a house guest become violently ill last night and he ended up in the ICU at the local Hospital. So I''m a little grumpy today. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On 8/6/07, J and T <j_and_t@hotmail.com> wrote:> I didn''t mean to offend you Tom by saying Shorewall was puking on my > console. I realize it is klogd. But I''ve been using Shorewall for years and > now after upgrading only shorewall messages are being sent to the console. > No other system messages are being sent to the console so I was confused as > to why only Shorewall. I still can''t figure it out. I thought that possibly > Shorewall was sending this as "critical" and that''s why it was seen on the > console. > > Anyway I''m sorry to have said something that I shouldn''t have. I''ll try to > track down the problem myself.If you have syslog-ng installed, check that also. If I remember correctly, it even takes on the function of the klogd. Last time I had the problem it was overcome by setting the dmesg -n level, though I had some problems with that (unfortunately I don''t remember the details). ~David> >>J and T wrote: > > > Using: > > > > > > shorewall-perl-4.0.1-2 > > > shorewall-4.0.1-2 > > > > > > I have tried everything that I can think of to stop shorewall from > > > puking to the console. > > > >Shorewall is not writing anything to your console. It is klogd that is > >writing to your console. Shorewall has no control over where particular log > >messages are written. Shorewall itself only generates a log message during > >start, restart, stop, etc. > > > > > I get dozens if not hundreds of these directed to > > > the console: > > > > > > Aug 6 07:34:13 backup kernel: Shorewall:net2all:DROP:IN=eth0 OUT> > > MAC=00:30:48:2f:a5:ca:00:06:53:10:18:01:08:00 SRC=124.205.138.109 > > > DST=xx.xx.xxx.46 LEN=404 TOS=0x00 PREC=0x20 TTL=108 ID=21755 PROTO=UDP > > > SPT=1031 DPT=1434 LEN=384 > > > >Shorewall FAQ 17 will tell you that this is a message generated by your > >net->all entry in /etc/shorewall/policy. > > > > > > > > I''ve implemented everything here (CentOS-5): > > > http://www.shorewall.net/FAQ.htm#faq16 > > > > > > Tip > > > > > > Under RedHat and Mandriva, the max log level that is sent to the console > > > is specified in /etc/sysconfig/init in the LOGLEVEL variable. Set > > > "LOGLEVEL=5" to suppress info (log level 6) messages on the > > > console. > > > > > > /etc/sysconfig/init > > > LOGLEVEL=5 > > > > > > /etc/rc.d/rc.sysinit > > > # Fix console loglevel > > > if [ -n "$LOGLEVEL" ]; then > > > /bin/dmesg -n $LOGLEVEL > > > fi > > > > > > I''ve rebooted, made sure all "*_LOGLEVEL=" in shorewall.conf are empty, > > > LOG_MARTIANS=No and so on, but everything that is logged to kernel.log > > > is echoed to the console. > > > >Again -- This is not a really a Shorewall issue. Furthermore, some of the > >LOGLEVEL= settings have a non-empty default so if you set them to empty, > >they will default to some non-empty level. So the only way that you will be > >able to suppress those messages using Shorewall configuration changes is to > >set them to ''debug''. > > > > > > > > Obviously I must be doing something wrong, but for the life of me I > > > can''t figure out what it would be. > > > > > > >Given that twiddling dmesg on your Distribution didn''t suppress log level 6 > >messages being written to the console, you will need to look at your klogd > >configuration. You have all of the initialization scripts there on your > >system so you will need to determine how they work. Then with the help of > >''man klogd'' you should be able to determine how to change the klogd > >configuration appropriately. I suspect that the hints in FAQ 16 for the > >other distributions will be helpful. > > > >And when you solve the problem, please report back with the solution so we > >can update the Hints in the FAQ. > > > >Thanks, > >-Tom > >-- > >Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > >Shoreline, \ http://shorewall.net > >Washington USA \ teastep@shorewall.net > >PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key > > > > > ><< signature.asc >> > > > > > >------------------------------------------------------------------------- > >This SF.net email is sponsored by: Splunk Inc. > >Still grepping through log files to find problems? Stop. > >Now Search log events and configuration files using AJAX and a browser. > >Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > >_______________________________________________ > >Shorewall-users mailing list > >Shorewall-users@lists.sourceforge.net > >https://lists.sourceforge.net/lists/listinfo/shorewall-users > > _________________________________________________________________ > Find a local pizza place, movie theater, and more….then map the best route! > http://maps.live.com/default.aspx?v=2&ss=yp.bars~yp.pizza~yp.movie%20theater&cp=42.358996~-71.056691&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=950607&encType=1&FORM=MGAC01 > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Thanks for the reply Tom. All mine show log level 3 and I have kern.* sent to /var/log/kernel.log and nothing sent to console, but these are still sent to console which is strange. I''m sure I''ll figure it out somewhere down the road. It''s all about syslog.conf I know. Something must have changed from previous "old" RH versions (ie, RH 7.3) because syslog.conf in all machines here are identical. However the other machines don''t get hit on the console (except for *.emerg of course). Something''s different and I have yet to find what it is. I hope your house guest gets well. Thanks again for your time and wonderful firewall, John>J and T wrote: > > I didn''t mean to offend you Tom by saying Shorewall was puking on my > > console. > >John, > >No offense was taken. I just wanted it to be clear, both to you and to >future readers of this thread, that control of logging is outside of >Shorewall. > > > I realize it is klogd. But I''ve been using Shorewall for years > > and now after upgrading only shorewall messages are being sent to the > > console. No other system messages are being sent to the console so I was > > confused as to why only Shorewall. I still can''t figure it out. I > > thought that possibly Shorewall was sending this as "critical" and > > that''s why it was seen on the console. > >You can check on what level Shorewall is setting in LOG messages by: > > shorewall dump | grep LOG > >Example: > > 0 0 LOG 0 -- * * 0.0.0.0/0 >0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:INPUT:REJECT:'' > 0 0 LOG 0 -- * * 0.0.0.0/0 >0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:FORWARD:REJECT:'' >... > >The ''level 6'' in these messages means log level 6 which is ''info''. > > > > > Anyway I''m sorry to have said something that I shouldn''t have. I''ll try > > to track down the problem myself. > > > >Not at all. I apologize if I gave that impression. In my own defense, I''ve >been up for most of the last 30 hours; I had a house guest become violently >ill last night and he ended up in the ICU at the local Hospital. So I''m a >little grumpy today. > >-Tom >-- >Tom Eastep \ Nothing is foolproof to a sufficiently talented fool >Shoreline, \ http://shorewall.net >Washington USA \ teastep@shorewall.net >PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key >><< signature.asc >>>------------------------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. >Still grepping through log files to find problems? Stop. >Now Search log events and configuration files using AJAX and a browser. >Download your FREE copy of Splunk now >> http://get.splunk.com/>_______________________________________________ >Shorewall-users mailing list >Shorewall-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/shorewall-users_________________________________________________________________ Booking a flight? Know when to buy with airfare predictions on MSN Travel. http://travel.msn.com/Articles/aboutfarecast.aspx&ocid=T001MSN25A07001 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
J and T wrote:> Thanks for the reply Tom. All mine show log level 3 and I have kern.* sent > to /var/log/kernel.log and nothing sent to console, but these are still sent > to console which is strange. > > I''m sure I''ll figure it out somewhere down the road. It''s all about > syslog.conf I know.I disagree. I think it is /etc/init.d/klogd, /etc/sysconfig/klogd or something similar.> Something must have changed from previous "old" RH > versions (ie, RH 7.3) because syslog.conf in all machines here are > identical.And the Hint given in the FAQ seems to work on older releases as well.> I hope your house guest gets well.Thanks,> Thanks again for your time and wonderful firewall,You''re most welcome. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
J and T wrote:> Thanks for the reply Tom. All mine show log level 3Wait a minute -- if you have level 3 configured in Shorewall then you must set LOGLEVEL=2 in /etc/sysconfig/init in order to suppress the messages being written to the console. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Of course! ------ Tip Under RedHat and Mandriva, the max log level that is sent to the console is specified in /etc/sysconfig/init in the LOGLEVEL variable. Set “LOGLEVEL=5” to suppress info (log level 6) messages on the console. ------ It makes perfect sense now that I put two and two together! So if I configure Shorewall with level 6 (info) then setting LOGLEVEL=5 (notice in /etc/sysconfig/init) would suppress these to console. Your instructions state this clearly, but I just didn''t put the two together. So I changed /etc/sysconfig/init to LOGLEVEL=2 and even rebooted the machine. But these messages are still dumping to the console. I''ve been using Shorewall for many years. In the last couple of months I upgraded my desktop to Fedora 7. Installed Shorewall first thing. But since now everything is in graphic mode (run level 5), I never noticed anything on the console because I never see it. But now that I put together a new server with CentOS-5 and changed it to runlevel 3, all Shorewall messages are directed to console. No other messages are dumped there, just Shorewall. If I log in from another box using SSH, no shorewall messages are seen. But as soon as I go back to the server room, Shorewall messages are scattered on the server''s console (login prompt). It''s weired don''t you think? Since it''s a test box I''ll send everything to /dev/null and see what happens. Thanks again, John>J and T wrote: > > Thanks for the reply Tom. All mine show log level 3 > >Wait a minute -- if you have level 3 configured in Shorewall then you must >set LOGLEVEL=2 in /etc/sysconfig/init in order to suppress the messages >being written to the console. > >-Tom >-- >Tom Eastep \ Nothing is foolproof to a sufficiently talented fool >Shoreline, \ http://shorewall.net >Washington USA \ teastep@shorewall.net >PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key >><< signature.asc >>>------------------------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. >Still grepping through log files to find problems? Stop. >Now Search log events and configuration files using AJAX and a browser. >Download your FREE copy of Splunk now >> http://get.splunk.com/>_______________________________________________ >Shorewall-users mailing list >Shorewall-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/shorewall-users_________________________________________________________________ A new home for Mom, no cleanup required. All starts here. http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
J and T wrote:> No other messages are dumped there, just Shorewall. If > I log in from another box using SSH, no shorewall messages are seen. But as > soon as I go back to the server room, Shorewall messages are scattered on > the server''s console (login prompt). > > It''s weired don''t you think?Not especially, given that you are using such a high priority (level) for Netfilter messages. I imagine that those are the only messages being logged with priority 0-3. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/