(NOTE: I attempted to post this yesterday, however I was having e-mail problems and it looks like this message did not make it. I looked in the list archives and did not see this message so I am reposting it as I assume it did not get posted the first time. While I''m at it, I''ll edit what I said to make it clearer.) I can repeatably kernel panic my Cent OS 4.5 server running Shorewall version 4.0.5. I can accomplish this by connecting via NFS from another computer to this box, then as I start to browse around (NFS client is Mac OSX 10.5) Linux crashes with Caps Lock and Scroll Lock flashing. The log entry is included below. When I _stop_ shorewall (after a reboot), Linux does _not_ panic when the same above actions are performed (connecting/browsing via NFS). I''m not sure if the problem is with Shorewall or Linux. Thus my question: Do I report this issue here or to the CentOS people? Perhaps of note is that at each panic, Shorewall reports a different SPT and DPT. Below are the relevant messages from /var/log/messages (looks like they got line-wrapped, sorry): Nov 13 09:47:16 hydrogen kernel: Shorewall:fw2loc:REJECT:IN= OUT=eth0 SRC=192.168.0.1 DST=192.168.0.10 LEN=128 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=943 DPT=1007 LEN=108 Nov 13 09:47:16 hydrogen kernel: RPC: sendmsg returned error 1 Nov 13 09:47:16 hydrogen kernel: Shorewall:fw2loc:REJECT:IN= OUT=eth0 SRC=192.168.0.1 DST=192.168.0.10 LEN=148 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=943 DPT=1007 LEN=128 Nov 13 09:47:16 hydrogen kernel: RPC: sendmsg returned error 1 Nov 13 09:47:16 hydrogen kernel: ------------[ cut here ]------------ Nov 13 09:47:16 hydrogen kernel: kernel BUG at fs/lockd/host.c:252! Nov 13 09:47:16 hydrogen kernel: invalid operand: 0000 [#1] Nov 13 09:47:16 hydrogen kernel: SMP Nov 13 09:47:16 hydrogen kernel: Modules linked in: mga nfsd exportfs lockd nfs_acl parport_pc lp parport i2c_dev i2c_core iptable_raw ipt_ULOG ipt_ttl ipt_TOS ipt_tos ipt_TCPMSS ipt_tcpmss ipt_state ipt_sctp ipt_SAME ipt_REJECT ipt_REDIRECT ipt_recent ipt_realm ipt_pkttype ipt_physdev ipt_owner ipt_NOTRACK ipt_NETMAP ipt_multiport ipt_MASQUERADE ipt_MARK ipt_mark ipt_mac ipt_LOG ipt_limit ipt_length ipt_iprange ipt_helper ipt_esp ipt_ECN ipt_ecn ipt_DSCP ipt_dscp ipt_conntrack ipt_comment ipt_CLASSIFY ipt_ah ipt_addrtype ip_nat_tftp ip_nat_snmp_basic ip_nat_irc ip_nat_ftp ip_nat_amanda ip_conntrack_tftp ip_conntrack_irc ip_conntrack_ftp ip_conntrack_amanda iptable_nat ip_conntrack iptable_mangle sunrpc md5 ipv6 iptable_filter ip_tables loop button battery ac uhci_hcd hw_random tulip r8169 floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod ata_piix libata aic7xxx sd_mod scsi_mod Nov 13 09:47:16 hydrogen kernel: CPU: 1 Nov 13 09:47:16 hydrogen kernel: EIP: 0060:[<e0bd88f5>] Not tainted VLI Nov 13 09:47:16 hydrogen kernel: EFLAGS: 00010286 (2.6.9-55.0.12.ELsmp) Nov 13 09:47:16 hydrogen kernel: EIP is at nlm_release_host+0x2b/0x35 [lockd] Nov 13 09:47:16 hydrogen kernel: eax: ffffffff ebx: df96db80 ecx: dff76a80 edx: c1000000 Nov 13 09:47:16 hydrogen kernel: esi: d925af78 edi: d06c2524 ebp: d925ae5c esp: d925ae38 Nov 13 09:47:16 hydrogen kernel: ds: 007b es: 007b ss: 0068 Nov 13 09:47:16 hydrogen kernel: Process lockd (pid: 3552, threadinfo=d925a000 task=df6b4eb0) Nov 13 09:47:16 hydrogen kernel: Stack: d06c2400 e0bdedc2 df96db80 0000000c dff54200 dff54400 d925af78 dff54200 Nov 13 09:47:16 hydrogen kernel: e0bde928 73040000 0120709c 00000000 00000000 00000000 00000000 00000000 Nov 13 09:47:16 hydrogen kernel: 00000000 00000008 00000000 00000000 00000000 00000000 00000000 00000000 Nov 13 09:47:16 hydrogen kernel: Call Trace: Nov 13 09:47:16 hydrogen kernel: [<e0bdedc2>] nlm4svc_callback+0x7f/0x8d [lockd] Nov 13 09:47:16 hydrogen kernel: [<e0bde928>] nlm4svc_proc_lock_msg+0x4a/0x55 [lockd] Nov 13 09:47:16 hydrogen kernel: [<e0bddb41>] nlm4svc_decode_lockargs+0x7d/0x104 [lockd] Nov 13 09:47:16 hydrogen kernel: [<e0bddac4>] nlm4svc_decode_lockargs+0x0/0x104 [lockd] Nov 13 09:47:16 hydrogen kernel: [<e0bd8c6f>] nlmsvc_dispatch+0x7c/0x122 [lockd] Nov 13 09:47:16 hydrogen kernel: [<e0a9961b>] svc_process+0x432/0x6e3 [sunrpc] Nov 13 09:47:16 hydrogen kernel: [<e0bd8e98>] lockd+0x183/0x270 [lockd] Nov 13 09:47:16 hydrogen kernel: [<e0bd8d15>] lockd+0x0/0x270 [lockd] Nov 13 09:47:16 hydrogen kernel: [<c01041f5>] kernel_thread_helper +0x5/0xb Nov 13 09:47:16 hydrogen kernel: Code: 53 85 c0 89 c3 74 2c 80 3d dc 61 ab e0 00 79 10 8d 40 18 50 68 d4 f3 bd e0 e8 0a a0 54 df 59 58 f0 ff 4b 54 8b 43 54 85 c0 79 08 <0f> 0b fc 00 ec f3 bd e0 5b c3 80 3d dc 61 ab e0 00 57 56 53 79 Nov 13 09:47:16 hydrogen kernel: <0>Fatal exception: panic in 5 seconds Thanks, Eric This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. If you are not the intended recipient, please do not copy this message or attachment or disclose the contents to any other person. This e-mail and any attachments have been scanned for certain viruses prior to leaving Mercy Ships. However, Mercy Ships will not be liable for any losses as a result of any viruses being passed on. ------------------------------------------------------------------------- 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/
Kristopher Lalletti
2007-Nov-14 17:09 UTC
Re: Kernel Panic induced by NFS request via Shorewall
I''m not a kernel expert, but it looks like the NFS lockd component is the first-one to complain, after the first rejected packet. Looks more like an NFS related issue happening when there''s an irregular activity in the IP protocol (in this case, your shorewall/iptables blocking a port that should be left open), and somehow, the program never expected such a situation would happen, and it simply craps-out. I would first start by seeing if the problem can be reproduced once you allow that refused packet. I''m guessing that it won''t crash, which means that there''s a problem is really related to NFS. I''d report it to that linux group explaining the blockage in traffic that you provoked, make sure you include your kernel version along with the nfs-utils version. Kris On 11/14/07, Eric Swanson <swansone@mercyships.org> wrote:> > (NOTE: I attempted to post this yesterday, however I was having e-mail > problems and it looks like this message did not make it. I looked in > the > list archives and did not see this message so I am reposting it as I > assume it did not get posted the first time. While I''m at it, I''ll > edit what > I said to make it clearer.) > > I can repeatably kernel panic my Cent OS 4.5 server running Shorewall > version 4.0.5. I can accomplish this by connecting via NFS from another > computer to this box, then as I start to browse around (NFS client is > Mac > OSX 10.5) Linux crashes with Caps Lock and Scroll Lock flashing. The > log entry is included below. > > When I _stop_ shorewall (after a reboot), Linux does _not_ panic when > the > same above actions are performed (connecting/browsing via NFS). > > I''m not sure if the problem is with Shorewall or Linux. Thus my > question: > Do I report this issue here or to the CentOS people? > > Perhaps of note is that at each panic, Shorewall reports a different SPT > and DPT. > > Below are the relevant messages from /var/log/messages (looks like > they got > line-wrapped, sorry): > > Nov 13 09:47:16 hydrogen kernel: Shorewall:fw2loc:REJECT:IN= OUT=eth0 > SRC=192.168.0.1 DST=192.168.0.10 LEN=128 TOS=0x00 PREC=0x00 TTL=64 ID=0 > DF PROTO=UDP SPT=943 DPT=1007 LEN=108 > Nov 13 09:47:16 hydrogen kernel: RPC: sendmsg returned error 1 > Nov 13 09:47:16 hydrogen kernel: Shorewall:fw2loc:REJECT:IN= OUT=eth0 > SRC=192.168.0.1 DST=192.168.0.10 LEN=148 TOS=0x00 PREC=0x00 TTL=64 ID=0 > DF PROTO=UDP SPT=943 DPT=1007 LEN=128 > Nov 13 09:47:16 hydrogen kernel: RPC: sendmsg returned error 1 > Nov 13 09:47:16 hydrogen kernel: ------------[ cut here ]------------ > Nov 13 09:47:16 hydrogen kernel: kernel BUG at fs/lockd/host.c:252! > Nov 13 09:47:16 hydrogen kernel: invalid operand: 0000 [#1] > Nov 13 09:47:16 hydrogen kernel: SMP > Nov 13 09:47:16 hydrogen kernel: Modules linked in: mga nfsd exportfs > lockd nfs_acl parport_pc lp parport i2c_dev i2c_core iptable_raw > ipt_ULOG ipt_ttl ipt_TOS ipt_tos ipt_TCPMSS ipt_tcpmss ipt_state > ipt_sctp ipt_SAME ipt_REJECT ipt_REDIRECT ipt_recent ipt_realm > ipt_pkttype ipt_physdev ipt_owner ipt_NOTRACK ipt_NETMAP ipt_multiport > ipt_MASQUERADE ipt_MARK ipt_mark ipt_mac ipt_LOG ipt_limit ipt_length > ipt_iprange ipt_helper ipt_esp ipt_ECN ipt_ecn ipt_DSCP ipt_dscp > ipt_conntrack ipt_comment ipt_CLASSIFY ipt_ah ipt_addrtype ip_nat_tftp > ip_nat_snmp_basic ip_nat_irc ip_nat_ftp ip_nat_amanda ip_conntrack_tftp > ip_conntrack_irc ip_conntrack_ftp ip_conntrack_amanda iptable_nat > ip_conntrack iptable_mangle sunrpc md5 ipv6 iptable_filter ip_tables > loop button battery ac uhci_hcd hw_random tulip r8169 floppy dm_snapshot > dm_zero dm_mirror ext3 jbd dm_mod ata_piix libata aic7xxx sd_mod > scsi_mod > Nov 13 09:47:16 hydrogen kernel: CPU: 1 > Nov 13 09:47:16 hydrogen kernel: EIP: 0060:[<e0bd88f5>] Not > tainted VLI > Nov 13 09:47:16 hydrogen kernel: EFLAGS: 00010286 > (2.6.9-55.0.12.ELsmp) > Nov 13 09:47:16 hydrogen kernel: EIP is at nlm_release_host+0x2b/0x35 > [lockd] > Nov 13 09:47:16 hydrogen kernel: eax: ffffffff ebx: df96db80 ecx: > dff76a80 edx: c1000000 > Nov 13 09:47:16 hydrogen kernel: esi: d925af78 edi: d06c2524 ebp: > d925ae5c esp: d925ae38 > Nov 13 09:47:16 hydrogen kernel: ds: 007b es: 007b ss: 0068 > Nov 13 09:47:16 hydrogen kernel: Process lockd (pid: 3552, > threadinfo=d925a000 task=df6b4eb0) > Nov 13 09:47:16 hydrogen kernel: Stack: d06c2400 e0bdedc2 df96db80 > 0000000c dff54200 dff54400 d925af78 dff54200 > Nov 13 09:47:16 hydrogen kernel: e0bde928 73040000 0120709c > 00000000 00000000 00000000 00000000 00000000 > Nov 13 09:47:16 hydrogen kernel: 00000000 00000008 00000000 > 00000000 00000000 00000000 00000000 00000000 > Nov 13 09:47:16 hydrogen kernel: Call Trace: > Nov 13 09:47:16 hydrogen kernel: [<e0bdedc2>] > nlm4svc_callback+0x7f/0x8d [lockd] > Nov 13 09:47:16 hydrogen kernel: [<e0bde928>] > nlm4svc_proc_lock_msg+0x4a/0x55 [lockd] > Nov 13 09:47:16 hydrogen kernel: [<e0bddb41>] > nlm4svc_decode_lockargs+0x7d/0x104 [lockd] > Nov 13 09:47:16 hydrogen kernel: [<e0bddac4>] > nlm4svc_decode_lockargs+0x0/0x104 [lockd] > Nov 13 09:47:16 hydrogen kernel: [<e0bd8c6f>] > nlmsvc_dispatch+0x7c/0x122 [lockd] > Nov 13 09:47:16 hydrogen kernel: [<e0a9961b>] svc_process+0x432/0x6e3 > [sunrpc] > Nov 13 09:47:16 hydrogen kernel: [<e0bd8e98>] lockd+0x183/0x270 [lockd] > Nov 13 09:47:16 hydrogen kernel: [<e0bd8d15>] lockd+0x0/0x270 [lockd] > Nov 13 09:47:16 hydrogen kernel: [<c01041f5>] kernel_thread_helper > +0x5/0xb > Nov 13 09:47:16 hydrogen kernel: Code: 53 85 c0 89 c3 74 2c 80 3d dc 61 > ab e0 00 79 10 8d 40 18 50 68 d4 f3 bd e0 e8 0a a0 54 df 59 58 f0 ff 4b > 54 8b 43 54 85 c0 79 08 <0f> 0b fc 00 ec f3 bd e0 5b c3 80 3d dc 61 ab > e0 00 57 56 53 79 > Nov 13 09:47:16 hydrogen kernel: <0>Fatal exception: panic in 5 seconds > > > > > Thanks, > Eric > > This message and any attachment are confidential and may be privileged or > otherwise protected from disclosure. If you are not the intended > recipient, > please telephone or email the sender and delete this message and any > attachment from your system. If you are not the intended recipient, please > do not copy this message or attachment or disclose the contents to any > other person. This e-mail and any attachments have been scanned for > certain viruses prior to leaving Mercy Ships. However, Mercy Ships will > not be liable for any losses as a result of any viruses being passed on. > > ------------------------------------------------------------------------- > 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/
Eric Swanson wrote:> > I can repeatably kernel panic my Cent OS 4.5 server running Shorewall > version 4.0.5. I can accomplish this by connecting via NFS from another > computer to this box, then as I start to browse around (NFS client is > Mac > OSX 10.5) Linux crashes with Caps Lock and Scroll Lock flashing. The > log entry is included below. > > When I _stop_ shorewall (after a reboot), Linux does _not_ panic when > the > same above actions are performed (connecting/browsing via NFS). > > I''m not sure if the problem is with Shorewall or Linux. Thus my > question: > Do I report this issue here or to the CentOS people?You report it to the CentOS people. It is important in these cases to understand what Shorewall is (and isn''t). Shorewall is a tool for configuring certain networking aspects of your kernel. Although we speak of "starting" Shorewall, and say that "Shorewall is running" after a successful start, the fact is that once "shorewall start" (or "shorewall restart") finishes, there is no Shorewall code running in your system at all.> > Perhaps of note is that at each panic, Shorewall reports a different SPT > and DPT. >Again, it is not Shorewall that is generating those log messages -- Shorewall has configured Netfilter (part of your kernel) to generate those messages under certain conditions (the messages you are seeing are probably the result of a REJECT policy from fw->loc -- see Shorewall FAQ 17). When using NFS (or any portmapper-based application), it is the least painful strategy to simply allow all UDP traffic (in both directions) between the client(s) and the server. You might find that you can work around the problem if you do that. /etc/shorewall/rules: ACCEPT fw loc udp ACCEPT loc fw udp -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/
Thank you, Tom. Allowing all UDP traffic seems to be working as a work-around for me. I will report the issue to the Linux people. Eric Swanson On Nov 14, 2007, at 11:16 AM, Tom Eastep wrote:> Eric Swanson wrote: > >> >> I can repeatably kernel panic my Cent OS 4.5 server running Shorewall >> version 4.0.5. I can accomplish this by connecting via NFS from >> another >> computer to this box, then as I start to browse around (NFS client is >> Mac >> OSX 10.5) Linux crashes with Caps Lock and Scroll Lock flashing. The >> log entry is included below. >> >> When I _stop_ shorewall (after a reboot), Linux does _not_ panic when >> the >> same above actions are performed (connecting/browsing via NFS). >> >> I''m not sure if the problem is with Shorewall or Linux. Thus my >> question: >> Do I report this issue here or to the CentOS people? > > You report it to the CentOS people. It is important in these cases to > understand what Shorewall is (and isn''t). Shorewall is a tool for > configuring certain networking aspects of your kernel. Although we > speak of > "starting" Shorewall, and say that "Shorewall is running" after a > successful > start, the fact is that once "shorewall start" (or "shorewall > restart") > finishes, there is no Shorewall code running in your system at all. > >> >> Perhaps of note is that at each panic, Shorewall reports a >> different SPT >> and DPT. >> > > Again, it is not Shorewall that is generating those log messages -- > Shorewall has configured Netfilter (part of your kernel) to generate > those > messages under certain conditions (the messages you are seeing are > probably > the result of a REJECT policy from fw->loc -- see Shorewall FAQ 17). > When > using NFS (or any portmapper-based application), it is the least > painful > strategy to simply allow all UDP traffic (in both directions) > between the > client(s) and the server. You might find that you can work around the > problem if you do that. > > /etc/shorewall/rules: > > ACCEPT fw loc udp > ACCEPT loc fw udp > > -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/_______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-usersThis message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system. If you are not the intended recipient, please do not copy this message or attachment or disclose the contents to any other person. This e-mail and any attachments have been scanned for certain viruses prior to leaving Mercy Ships. However, Mercy Ships will not be liable for any losses as a result of any viruses being passed on. ------------------------------------------------------------------------- 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/
Karsten Bräckelmann
2007-Nov-14 18:14 UTC
Re: Kernel Panic induced by NFS request via Shorewall
On Wed, 2007-11-14 at 09:16 -0800, Tom Eastep wrote:> Eric Swanson wrote:> > Perhaps of note is that at each panic, Shorewall reports a different SPT > > and DPT.Probably NFS related traffic, which defaults to random ports...> Again, it is not Shorewall that is generating those log messages -- > Shorewall has configured Netfilter (part of your kernel) to generate those > messages under certain conditions (the messages you are seeing are probably > the result of a REJECT policy from fw->loc -- see Shorewall FAQ 17). When > using NFS (or any portmapper-based application), it is the least painful > strategy to simply allow all UDP traffic (in both directions) between theThat depends on your definition of "painful". For me, opening all UDP ports is more painful, than spending a couple minutes configuring the server. :)> client(s) and the server. You might find that you can work around the > problem if you do that. > > /etc/shorewall/rules: > > ACCEPT fw loc udp > ACCEPT loc fw udpSee http://shorewall.net/ports.htm#NFS , which hints to my documentation and rules for "pinning down NFS". That way, you can restrict NFS to a few fixed ports only, instead of opening everything. karsten -- [ESR] Eric S. Raymond: "How To Ask Questions The Smart Way" http://www.catb.org/~esr/faqs/smart-questions.html [SGT] Simon G. Tatham: "How to Report Bugs Effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html ------------------------------------------------------------------------- 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/
Karsten Bräckelmann wrote:> On Wed, 2007-11-14 at 09:16 -0800, Tom Eastep wrote: > it is the least painful >> strategy to simply allow all UDP traffic (in both directions) between the > > That depends on your definition of "painful". For me, opening all UDP > ports is more painful, than spending a couple minutes configuring the > server. :) > >> client(s) and the server. You might find that you can work around the >> problem if you do that. >> >> /etc/shorewall/rules: >> >> ACCEPT fw loc udp >> ACCEPT loc fw udp > > See http://shorewall.net/ports.htm#NFS , which hints to my documentation > and rules for "pinning down NFS". That way, you can restrict NFS to a > few fixed ports only, instead of opening everything.Just so we''re all on the same page -- Karsten''s documentation is specific to Redhat/Fedora so it will probably also work for CentOS. It is not directly applicable to other distributions. As a consequence, for me opening all UDP ports is less painful than spending the time necessary to translate Karsten''s instructions into something that will work on one of the distributions that I run. And, of course, using your firewall as a local NFS server is not the world''s best idea from the point of view of security but I confess that I do it myself. -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/
Andrew Suffield
2007-Nov-14 20:27 UTC
Re: Kernel Panic induced by NFS request via Shorewall
On Wed, Nov 14, 2007 at 11:52:31AM -0800, Tom Eastep wrote:> And, of course, using your firewall as a local NFS server is not the world''s > best idea from the point of view of securityUsing NFS for anything is not the world''s best idea from a security perspective (at least before version 4). It''s only really applicable to situations where security isn''t that important. ------------------------------------------------------------------------- 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/
Karsten Bräckelmann
2007-Nov-14 23:56 UTC
Re: Kernel Panic induced by NFS request via Shorewall
On Wed, 2007-11-14 at 11:52 -0800, Tom Eastep wrote:> Karsten Bräckelmann wrote: > > On Wed, 2007-11-14 at 09:16 -0800, Tom Eastep wrote: > > it is the least painful > > strategy to simply allow all UDP traffic (in both directions) between the > > > > That depends on your definition of "painful". For me, opening all UDP > > ports is more painful, than spending a couple minutes configuring the > > server. :)> > See http://shorewall.net/ports.htm#NFS , which hints to my documentation > > and rules for "pinning down NFS". That way, you can restrict NFS to a > > few fixed ports only, instead of opening everything. > > Just so we're all on the same page -- Karsten's documentation is specific to > Redhat/Fedora so it will probably also work for CentOS.And Mandriva. :)> It is not directly > applicable to other distributions. As a consequence, for me opening all UDP > ports is less painful than spending the time necessary to translate > Karsten's instructions into something that will work on one of the > distributions that I run.Out of curiosity, I just checked the relevant init files and had a quick look at a Debian powered server. It appears the necessary settings can be easily translated directly to Debian. For reference, see my previously mentioned rules and its documentation [1]. However, do note that I did NOT test the Debian specific instructions below. Setting specific ports for rpc.statd and rpc.mountd needs to be done when starting the daemons. The Debian way is to provide these along with the -p switch to $STATDOPTS and $RPCMOUNTDOPTS in the /etc/default conf files (nfs-common and nfs-kernel-server respectively). Pinning down rpc.lockd is being done using sysctl, and adding two lines like these to /etc/sysctl.conf does the trick: fs.nfs.nlm_tcpport = $LOCKD_TCPPORT fs.nfs.nlm_udpport = $LOCKD_UDPPORT The difference between the RH and Debian styles is, that Debian keeps these settings in separate files and specifically needs the switches, whereas in the RH style world the init script sources a single conf file holding fine grained variables and the init script itself cares about adding all the switches. Somewhere during my looking at init scripts and conf files I stumbled across a handy reference, that pretty much suggests the above, too. http://wiki.debian.org/?SecuringNFS It even starts with the topic of being firewall friendly, and specifically includes a Shorewall section for setting up the firewall rules. :)> And, of course, using your firewall as a local NFS server is not the world's > best idea from the point of view of security but I confess that I do it myself.Tom, unfortunately I do not have a SuSE server at hand to have a look at its specific flavor. ;) karsten [1] http://lists.shorewall.net/~kb/ -- [ESR] Eric S. Raymond: "How To Ask Questions The Smart Way" http://www.catb.org/~esr/faqs/smart-questions.html [SGT] Simon G. Tatham: "How to Report Bugs Effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html ------------------------------------------------------------------------- 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
Karsten Bräckelmann
2007-Nov-15 00:25 UTC
Re: Kernel Panic induced by NFS request via Shorewall
On Thu, 2007-11-15 at 00:56 +0100, Karsten Bräckelmann wrote:> Tom, unfortunately I do not have a SuSE server at hand to have a look at > its specific flavor. ;)Actually, this is not true. :) It appears that SuSE uses a mix of both already documented styles. Just like Mandriva and RH you can pin down rpc.mountd by setting the desired port $MOUNTD_PORT in /etc/sysconfig/nfs, and for rpc.lockd ports you can use /etc/sysctl.conf directly just like in Debian. However, the init script offers no way whatsoever to pass rpc.statd options... :( karsten -- [ESR] Eric S. Raymond: "How To Ask Questions The Smart Way" http://www.catb.org/~esr/faqs/smart-questions.html [SGT] Simon G. Tatham: "How to Report Bugs Effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html ------------------------------------------------------------------------- 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
Cristian Rodriguez
2007-Nov-16 11:46 UTC
Re: Kernel Panic induced by NFS request via Shorewall
Eric Swanson escribió:> Thank you, Tom. > > Allowing all UDP traffic seems to be working as a work-around for me. >I suggest you to evaluate use of CIFS/SMB as a good alternative as well. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Cristian Rodriguez
2007-Nov-16 11:49 UTC
Re: Kernel Panic induced by NFS request via Shorewall
Karsten Bräckelmann escribió:> However, the init script offers no way whatsoever to pass rpc.statd > options... :( >Which seems to be a bug / missing feature, please fill a bug report ;) ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users