Print

---

To our great mystery we found that our RB was no longer accepting
queries on its BDII, even though the thing was running.  Stranger and
stranger, at some point we saw mysterious iptables messages in the log
files.  To finally discover the following magic in /etc/init.d/lcg-bdii

     iptables -I INPUT --protocol tcp --destination-port $BDII_PORT_READ
--syn -j DROP
     iptables -I INPUT -s 127.0.0.1/32 --protocol tcp --destination-port
$BDII_PORT_READ --syn -j DROP

     for x in `seq 1 5`; do
         connections=`netstat --tcp --numeric  | grep -v TIME_WAIT | awk
'{print $4}' | grep :2170`
         if [ ! "x$connections" = "x" ]; then
             sleep 1
         fi
     done

     $0 stop
     mv $LDAP_DB_WRITE/* $LDAP_DB_READ
     $0 start
     iptables -D INPUT --protocol tcp --destination-port $BDII_PORT_READ
--syn -j DROP
     iptables -D INPUT -s 127.0.0.1/32 --protocol tcp --destination-port
$BDII_PORT_READ --syn -j DROP


Unfortunately, if something goes wrong enough in the middle part and
blows you out of the script, you get a blocked BDII port that never gets
unblocked.  We even had fun by attempting to start the BDII several
times -- the start failed, but the number of iptables rules continued to
decrease after each start, as the script doesn't check whether the rule
it's setting is already set.

Running the 'stop' method of the init.d script a sufficient number of
times managed to restore relative sanity.

Could the next implementation do something with the program itself and
whether it binds to a particular interface or not, rather than using
iptables?  I think that would be much less error prone.


Thanks,

        J "drop kick" T