Hi Jeff,
Yes, I agree this is very nasty:( You will be pleased to hear that a
new version of the BDII that does not do this. It is nearly ready and
should be out in the next release. :)
Laurence
Jeff Templon wrote:
> 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
>
|