Hide Forgot
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): shorewall-3.2.4-1.fc5 How reproducible: Always 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.
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 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?
Actually that rule is built in to shorewall. See line 2053 in /usr/share/shorewall/functions: 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.