Hello, With reference to the problems listed below. I too am having incredibly long start up times. I''m talking minutes here (around 5 minutes). My configuration is not complex I don''t think. We are you using ldap too and the settings are bellow. The network is up as I''m restarting shorewall whilst the machine is running. Any suggestions? Is there no way to build the settings offline then just apply them? The iptables created seems quite extensive. Anyway much simpler product to use than to had craft the start up script. Its just the start up times that are crippling. Cheers Martin Ritchie> Thanks gentlemen. We''ll give this a try and report back. > > > Cheers, > Matthew > > On May 2, 2005, at 1:05 PM, Tom Eastep wrote: > > > Gregory Pleau wrote: > > > >>> > >>> The problem that you had with LDAP causing long Shorewall > startup has > >>> resurfaced. In your mail to me, you mentioned that you had > found that > >>> the issue was a permissions problem but gave no details. > >>> > >>> Would you be so kind as to give me the details so I can pass > them on > >>> to > >>> the current sufferer? I notice that you are not subscribed to the > >>> User''s > >>> list so you won''t have seen his posts. > >>> > >>> Thanks, > >>> -Tom > >>> > >>> > >> Actually we didn''t fix it. We worked around it. > >> > >> What we did was change the shorewall script in the /etc/init.d/ to > >> start > >> after our network and VPN came up (so LDAP was available). We also > >> created a local root user on the machine and set /etc/nsswitch > to use > >> "files" before "ldap". > >> > > > > Thanks, Greg > > > > -Tom > > -- > > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > > Shoreline, \ http://shorewall.net > > Washington USA \ teastep at shorewall.net > > PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key-- Martin Ritchie the Kelvin Institute Ltd. City Park Alexandra Parade Glasgow Scotland, UK G31 3AU 0141 567 2010 www.kelvininstitute.com
Unfortunately, we never resolved the issue and removed shorewall for that machine. Cheers, Matthew --- Matthew E. Porter Contegix LLC matthew.porter@contegix.com "Beyond Managed Hosting For Your Enterprise" -----Original Message----- From: Martin Ritchie <martin.ritchie@kelvininstitute.com> Date: Thu, 30 Jun 2005 02:18:42 To:shorewall-users@lists.shorewall.net Subject: [Shorewall-users] Long Shorewall Startup Times Revisited Hello, With reference to the problems listed below. I too am having incredibly long start up times. I''m talking minutes here (around 5 minutes). My configuration is not complex I don''t think. We are you using ldap too and the settings are bellow. The network is up as I''m restarting shorewall whilst the machine is running. Any suggestions? Is there no way to build the settings offline then just apply them? The iptables created seems quite extensive. Anyway much simpler product to use than to had craft the start up script. Its just the start up times that are crippling. Cheers Martin Ritchie> Thanks gentlemen. We''ll give this a try and report back. > > > Cheers, > Matthew > > On May 2, 2005, at 1:05 PM, Tom Eastep wrote: > > > Gregory Pleau wrote: > > > >>> > >>> The problem that you had with LDAP causing long Shorewall > startup has > >>> resurfaced. In your mail to me, you mentioned that you had > found that > >>> the issue was a permissions problem but gave no details. > >>> > >>> Would you be so kind as to give me the details so I can pass > them on > >>> to > >>> the current sufferer? I notice that you are not subscribed to the > >>> User''s > >>> list so you won''t have seen his posts. > >>> > >>> Thanks, > >>> -Tom > >>> > >>> > >> Actually we didn''t fix it. We worked around it. > >> > >> What we did was change the shorewall script in the /etc/init.d/ to > >> start > >> after our network and VPN came up (so LDAP was available). We also > >> created a local root user on the machine and set /etc/nsswitch > to use > >> "files" before "ldap". > >> > > > > Thanks, Greg > > > > -Tom > > -- > > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > > Shoreline, \ http://shorewall.net > > Washington USA \ teastep at shorewall.net > > PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key-- Martin Ritchie the Kelvin Institute Ltd. City Park Alexandra Parade Glasgow Scotland, UK G31 3AU 0141 567 2010 www.kelvininstitute.com _______________________________________________ Shorewall-users mailing list Post: Shorewall-users@lists.shorewall.net Subscribe/Unsubscribe: https://lists.shorewall.net/mailman/listinfo/shorewall-users Support: http://www.shorewall.net/support.htm FAQ: http://www.shorewall.net/FAQ.htm
Martin Ritchie wrote:> Hello, > > With reference to the problems listed below. I too am having incredibly > long start up times. I''m talking minutes here (around 5 minutes).On what hardware and OS are you running?> My configuration is not complex I don''t think.How many non-comment lines are there in your rules, policy, and hosts files? Here''s a shell command to get that: grep -ve ''^[ \t]*#'' -e ''^[ \t]*$'' hosts policy rules|wc -l Or perhaps looking at the rules directly: shorewall status | wc -l> ... > The network is up as I''m restarting > shorewall whilst the machine is running.My main internal firewall cluster here at work gives 467 non-comment configuration lines in the above files, and 3742 lines in the output from shorewall status. Running ''time shorewall restart'' gives: real 0m25.221s user 0m9.891s sys 0m14.485s The hardware is P4 2.8, 1 Gb RAM, running SLES9 with kernel 2.6.5-7.155.29-default. If folks are interested, we could probably get a survey going at http://devel.shorewall.net so that we can try to track down where the problem areas are. I seem to recall Tom also saying that using ash or dash instead of bash resulted in big gains.> Any suggestions? Is there no way to build the settings offline then > just apply them?Yes, look into the save/restore options.> The iptables created seems quite extensive. Anyway > much simpler product to use than to had craft the start up script. Its > just the start up times that are crippling.Note that existing TCP connections are not affected by the shorewall restart. It''s only new connections that are initiated during the restart that have problems. (Not that this will help much on a busy network...) -- Paul Gear, Manager IT Operations, Redlands College 38 Anson Road, Wellington Point 4160, Australia (Please send attachments in portable formats such as PDF, HTML, or OpenOffice.) -- The information contained in this message is copyright by Redlands College. Any use for direct sales or marketing purposes is expressly forbidden. This message does not represent the views of Redlands College.
My statistics aren''t good. [root@helmsdale shorewall]# grep -ve ''^[ \t]*#'' -e ''^[ \t]*$'' hosts policy rules|wc -l 20 [root@helmsdale shorewall]# shorewall status | wc -l 614 [root@helmsdale shorewall]# time /etc/init.d/shorewall restart Restarting shorewall: [ OK ] real 6m4.743s user 0m1.366s sys 0m2.913s This is on a HP Proliant DL 380 dual xenon 3.02Ghz with 2Gig of RAM, running Fedora Core 3 kernel - 2.6.11-1.35_FC3smp #1 SMP. I do get a message: kernel: ipt_owner: pid, sid and command matching is broken on SMP. when loading modules. I must have something quite wrong in my configuration Any pointers on where to look to track this down greatly appreciated. Martin Ritchie On Jun 30, 2005, at 03:19, Paul Gear wrote:> Martin Ritchie wrote: > >> Hello, >> >> With reference to the problems listed below. I too am having >> incredibly >> long start up times. I''m talking minutes here (around 5 minutes). >> > > On what hardware and OS are you running? > > >> My configuration is not complex I don''t think. >> > > How many non-comment lines are there in your rules, policy, and hosts > files? Here''s a shell command to get that: > > grep -ve ''^[ \t]*#'' -e ''^[ \t]*$'' hosts policy rules|wc -l > > Or perhaps looking at the rules directly: > > shorewall status | wc -l > > >> ... >> The network is up as I''m restarting >> shorewall whilst the machine is running. >> > > My main internal firewall cluster here at work gives 467 non-comment > configuration lines in the above files, and 3742 lines in the output > from shorewall status. Running ''time shorewall restart'' gives: > > real 0m25.221s > user 0m9.891s > sys 0m14.485s > > The hardware is P4 2.8, 1 Gb RAM, running SLES9 with kernel > 2.6.5-7.155.29-default. > > If folks are interested, we could probably get a survey going at > http://devel.shorewall.net so that we can try to track down where the > problem areas are. I seem to recall Tom also saying that using ash or > dash instead of bash resulted in big gains. > > >> Any suggestions? Is there no way to build the settings offline then >> just apply them? >> > > Yes, look into the save/restore options. > > >> The iptables created seems quite extensive. Anyway >> much simpler product to use than to had craft the start up >> script. Its >> just the start up times that are crippling. >> > > Note that existing TCP connections are not affected by the shorewall > restart. It''s only new connections that are initiated during the > restart that have problems. (Not that this will help much on a busy > network...)-- Martin Ritchie the Kelvin Institute Ltd. City Park Alexandra Parade Glasgow Scotland, UK G31 3AU 0141 567 2010 www.kelvininstitute.com
<Snip>> > kernel: ipt_owner: pid, sid and command matching is broken on SMP. > > when loading modules. > > I must have something quite wrong in my configuration > > Any pointers on where to look to track this down greatly appreciated.Do you use a user/group entry in your rules or tcrules file? It looks like... Maybe a typo? Please check it, could explain your long startups. HTH, Alex
2005/6/30, Martin Ritchie <martin.ritchie@kelvininstitute.com>:> My statistics aren''t good. > > [root@helmsdale shorewall]# grep -ve ''^[ \t]*#'' -e ''^[ \t]*$'' hosts > policy rules|wc -l > 20 > [root@helmsdale shorewall]# shorewall status | wc -l > 614 > [root@helmsdale shorewall]# time /etc/init.d/shorewall restart > Restarting shorewall: [ OK ] > > real 6m4.743s > user 0m1.366s > sys 0m2.913s > > This is on a HP Proliant DL 380 dual xenon 3.02Ghz with 2Gig of RAM, > running Fedora Core 3 kernel - 2.6.11-1.35_FC3smp #1 SMP. >FYI : my box.. running SUSE 9.3 amd64 2800+ 512 MB RAM #time shorewall restart real 0m1.544s user 0m0.425s sys 0m0.803s my clients are running several shorewall boxes, none of the startups times are higher that 5 o 6 seconds.
Alexander Wilms wrote:> <Snip> > >>kernel: ipt_owner: pid, sid and command matching is broken on SMP. >> >>when loading modules. >> >>I must have something quite wrong in my configuration >> >>Any pointers on where to look to track this down greatly appreciated. > > > Do you use a user/group entry in your rules or tcrules file? It looks like... > Maybe a typo? Please check it, could explain your long startups.I''d also try turning off SMP initially to see if that changes the situation. -- Paul <http://paulgear.webhop.net> -- This message is signed with a GNU Privacy Guard cryptographic signature. If you are reading this message in a text attachment, it is because your email program does not support OpenPGP. Please consider upgrading to one of the secure alternatives at <http://mozilla.org/>.
FWIW, we do not use SMP or user/group entries and still experience this problem. The commonality between the 3 people reporting this issue seems to be LDAP for PAM authentication. Is something in shorewall doing a user lookup even when not using user/group entries? Cheers, Matthew --- Matthew E. Porter Contegix LLC matthew.porter@contegix.com "Beyond Managed Hosting For Your Enterprise" On Jul 1, 2005, at 9:09 AM, Paul Gear wrote:> Alexander Wilms wrote: > >> <Snip> >> >> >>> kernel: ipt_owner: pid, sid and command matching is broken on SMP. >>> >>> when loading modules. >>> >>> I must have something quite wrong in my configuration >>> >>> Any pointers on where to look to track this down greatly >>> appreciated. >>> >> >> >> Do you use a user/group entry in your rules or tcrules file? It >> looks like... >> Maybe a typo? Please check it, could explain your long startups. >> > > I''d also try turning off SMP initially to see if that changes the > situation. > > -- > Paul > <http://paulgear.webhop.net> > -- > This message is signed with a GNU Privacy Guard cryptographic > signature. > If you are reading this message in a text attachment, it is because > your > email program does not support OpenPGP. Please consider upgrading to > one of the secure alternatives at <http://mozilla.org/>. > _______________________________________________ > Shorewall-users mailing list > Post: Shorewall-users@lists.shorewall.net > Subscribe/Unsubscribe: https://lists.shorewall.net/mailman/listinfo/ > shorewall-users > Support: http://www.shorewall.net/support.htm > FAQ: http://www.shorewall.net/FAQ.htm
Matthew E. Porter wrote:> FWIW, we do not use SMP or user/group entries and still experience this > problem. The commonality between the 3 people reporting this issue > seems to be LDAP for PAM authentication. Is something in shorewall > doing a user lookup even when not using user/group entries?More likely something in the commands that shorewall relies upon triggering a user name lookup somewhere in their filesystem access. Try this: shorewall trace restart 2>&1 | perl -e ''use strict; my $starttime time; my $time; while (<>) { $time = time; printf "%04d $_", $time - $starttime; }'' | tee /tmp/log This will prefix the output of shorewall trace with a time stamp (in seconds) from the start of the run. Look in the log file and work out which steps (if any) take a long time. Then turn off pam_ldap and try it again. See which steps change in the amount of time they take and we might be able to narrow it down. It''s likely not a Shorewall problem, but a problem in your configuration. For reference, my Celeron 600 with 128 Mb RAM ran the above script in 44 seconds. A plain restart without tracing on the same machine takes 31 seconds. -- 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.
Cristian Rodriguez wrote:> ... > FYI : my box.. running SUSE 9.3 amd64 2800+ 512 MB RAM > #time shorewall restart > > real 0m1.544s > user 0m0.425s > sys 0m0.803s > > my clients are running several shorewall boxes, none of the startups > times are higher that 5 o 6 seconds.Those are pretty impressive stats - less than 2 seconds! Are you running the 64-bit version of SuSE 9.3? What sort of disks do you have in your machine? -- Paul <http://paulgear.webhop.net> -- Did you know? Most email-borne viruses use a false sender address, so you cannot track down the sender using that address. Instead, keep your virus scanning software up-to-date and just delete any suspicious emails you receive.
2005/7/2, Paul Gear <paul@gear.dyndns.org>:> Those are pretty impressive stats - less than 2 seconds! Are you > running the 64-bit version of SuSE 9.3?yes, 64 bits, but I have only a few rules.> What sort of disks do you have > in your machine?ReiserFS, ash shell. # hdparm -i /dev/hda /dev/hda: Model=Maxtor 6Y120L0, FwRev=YAR41BW0, SerialNo=Y3N1A88E Config={ Fixed } RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=240121728 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 AdvancedPM=yes: disabled (255) WriteCache=enabled Drive conforms to: (null): other machine,SUSE 9.2, 1GB RAM, 64bits , reiserfs ,ash shell,similar HD but 8MB buffer on a production enviroment: (more rules, running MTA,webserver,dansguardian-squid,mysql.-..etc...) #time shorewall restart real 0m1.656s user 0m0.592s sys 0m0.996s (SUSE has a nice general performance though...:-) ) -- Cristian Rodriguez. "for DVDs in Linux screw the MPAA and ; do dig $DVDs.z.zoy.org ; done | \ perl -ne ''s/\.//g; print pack("H224",$1) if(/^x([^z]*)/)'' | gunzip"