Red Hat Bugzilla – Bug 211338
Shorewall starts very slowly when LDAP is not running
Last modified: 2007-12-08 09:31:22 EST
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):
Steps to Reproduce:
1. Stop services: shorewall, ldap, nscd.
2. Flush iptables (/etc/init.d/iptables stop)
3. Start shorewall
Shorewall chokes on starting for a sum of 10 minutes while processing rules such
/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
Shorewall should start as quickly when LDAP is not running as when LDAP is running.
Running "ps -ef" while shorewall is starting up will reveal the rules that it
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.
Created attachment 138832 [details]
My /etc/nsswitch.conf (before removing ldap entries)
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.
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
if ((pwd = getpwnam(optarg)))
ownerinfo->uid = pwd->pw_uid;
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?
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?
Does this problem still occur?
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.