Bug 211338 - Shorewall starts very slowly when LDAP is not running
Summary: Shorewall starts very slowly when LDAP is not running
Alias: None
Product: Fedora
Classification: Fedora
Component: shorewall   
(Show other bugs)
Version: 5
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Robert Marcano
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2006-10-18 18:49 UTC by John Holmstadt
Modified: 2007-12-08 14:31 UTC (History)
2 users (show)

Fixed In Version: 8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-08 14:31:22 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
My /etc/nsswitch.conf (before removing ldap entries) (1.68 KB, text/plain)
2006-10-18 20:56 UTC, John Holmstadt
no flags Details

Description John Holmstadt 2006-10-18 18:49:33 UTC
Description of problem:
Shorewall starts/stops very slowly when LDAP is not running. Startup of
shorewall alone takes over 10 minutes to complete (shutdown takes 2 minutes).
This is a problem since shorewall needs to (and does) start before LDAP does.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Stop services: shorewall, ldap, nscd.
2. Flush iptables (/etc/init.d/iptables stop)
3. Start shorewall
Actual results:
Shorewall chokes on starting for a sum of 10 minutes while processing rules such
as these...
/sbin/iptables -A fooX1234 -m owner --uid-owner 0 -j ACCEPT
/sbin/iptables -A Drop -p all -j dropBcast
/sbin/iptables -A Drop -p all -j dropInvalid
/sbin/iptables -A Reject -p all -j dropBcast
/sbin/iptables -A Reject -p all -j dropInvalid

Expected results:
Shorewall should start as quickly when LDAP is not running as when LDAP is running.

Additional info:
Running "ps -ef" while shorewall is starting up will reveal the rules that it
chokes on.

Comment 1 John Holmstadt 2006-10-18 20:53:08 UTC
I've narrowed this behavior down to two entries in /etc/nsswitch.conf:

passwd:     files ldap
protocols:  files ldap

If I remove ldap from these entries, shorewall starts up fine, of course that
would break my ldap setup. It seems odd to me that passwd would have any effect.
As far as I can tell it seems that all of these shorewall iptables processes are
being run as root.

Comment 2 John Holmstadt 2006-10-18 20:56:19 UTC
Created attachment 138832 [details]
My /etc/nsswitch.conf (before removing ldap entries)

Comment 3 John Holmstadt 2006-10-18 22:01:41 UTC
Just a quick FYI: A workaround to this is to add "bind_policy soft" to
/etc/ldap.conf so as to make LDAP fail after the first attempt instead of
exponentially waiting and retrying. This is not the default behavior of ldap as
installed and may not be desired behavior in production use. The real solution
may be finding out why shorewall or iptables is relying upon ldap.

Comment 4 Robert Marcano 2006-10-19 01:39:30 UTC
ummmm a workaround could be to make shorewall start after ldap, but i am not so
sure to want to start services before the appropiate firewall rules are applied.

The rule using --uid-owner is really the cause of the problem, the iptables
source says

if ((pwd = getpwnam(optarg)))
        ownerinfo->uid = pwd->pw_uid;
else {
        ownerinfo->uid = strtoul(optarg, &end, 0);
        if (*end != '\0' || end == optarg)
exit_error(PARAMETER_PROBLEM, "Bad OWNER UID value `%s'", optarg);

it is calling always "getpwnam" because it is expecting a username not an uid,
so if I am correct it is looking for an user named 0, not for root. do the
shorewall rule indicates root as the username?

Comment 5 John Holmstadt 2006-10-19 14:39:08 UTC
Actually that rule is built in to shorewall. See line 2053 in

 qt $IPTABLES -A fooX1234 -m owner --uid-owner 0 -j ACCEPT && OWNER_MATCH=Yes

I can see where the --uid-owner flag would create a problem, however the other 4
rules exhibit the same behavior. If you shut down ldap and run them alone, they
choke for a while then finally give an error...

 # /sbin/iptables -A Drop -p all -j dropBcast
 iptables v1.3.5: Couldn't load target
`dropBcast':/lib/iptables/libipt_dropBcast.so: cannot open shared object file:
No such file or directory
 Try `iptables -h' or 'iptables --help' for more information.

I see that this probably isn't so much a shorewall issue as it is an iptables 
or maybe even an nsswitch issue. It seems really odd to me that an operation
like getpwnam for uid 0 would even get to an ldap lookup. Shouldn't that root
lookup complete successfully using the local files /etc/passwd and such?

Where should I go from here?

Comment 6 Jonathan Underwood 2007-11-13 00:20:33 UTC
Does this problem still occur?

Comment 7 Jonathan Underwood 2007-12-08 14:31:22 UTC
OK closing this bug as CURRENTRELEASE, since we're now on Fedora 8, and
Shorewall is on version 4, and I can't reproduce the problem. Please re-open if
this problem still exists in the current release.

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