My coworkers have found a very annoying bug. Debian’s OpenVZ kernel superior to
2.6.32-squeeze5 have a regression that make NFS exclusive file locking mechanism broken.
Therefore concurrency problems could arise when several fronts try to write into the same file. To test your setup you can do this on an NFS client:
# strace flock -x -w10 "/NFS-MOUNTPOINT/myfile" -c "sleep 10&"
If it’s hang, you have a locking problem. For the moment the only solution is to downgrade your kernel. A ticket have been created on OpenVZ bugtracker.
Find a rule match
Let say you think a port is filtered by IP but it’s not. You have a somewhere a rule to open for your taste. How to find it ?
First establish a connection from a given IP:
test-host ~ $ nc -v 22.214.171.124 21
Then on the firewall list state connection from this IP:
fw5:~# pfctl -vvv -ss | grep -A3 126.96.36.199
all tcp 188.8.131.52:21 <- 184.108.40.206:56272 ESTABLISHED:ESTABLISHED
[899608849 + 29200] wscale 7 [1508798648 + 5889] wscale 4
age 00:00:41, expires in 04:59:19, 3:2 pkts, 164:164 bytes, rule 72
id: 5565c647ffd1505e creatorid: 410e4752
The matched rule has the number 72.
Find a rule by its number
When doing a
tcpdump on the pflog interface, matches are displayed using a number. To find the corresponding rule list them all and filter them:
fw3:~# pfctl -sr -g | grep '@72'
Purge a 'stuck' rule
When a relayd failover goes wrong, you can find yourself with a 'stuck' anchor rule. To list them all:
fw3:~# pfctl -a relayd/* -s rules
Find the outdated rule, then remove it manually:
fw3:~# pfctl -a relayd/foobar_https -F rules