So this was driving me nuts, and was effectively stopping me from turning off GMail and using my own e-mail server with RoundCube/ZPush. Basically, I get a ton of spam. One of the reasons I’d been using GMail is because the spam detection is great.

To block spammers, there are RDNSBLs (Reverse DNS Black Lists) that when performing a reverse DNS lookup return something in the 127.0.0.0/8 range if someone is on the “bad list”, and your MTA can be configured to block senders based on these responses.

At home, I have Tomato installed on my wireless router. I’m all set to use that as a DNS server to speed up and cache DNS lookups, but there is one problem: when a response comes back as 127.0.0.x from a DNS lookup, DNSMasq doesn’t like this and simply drops it. This is very bad for a RDNSBL, as it relies on exactly those type of responses.

I’ve been tinkering with getting this working forever, and tcpdump again helped me debug an application that wasn’t giving me much info. On my web/e-mail server, I watched the output of tcpdump for port 53, and waited a while until a spam message came through. I saw that Sendmail was doing the lookup, however each time it was simply letting the “bigger boobs” or whatever spam message through. I couldn’t for the life of me figure out why even my manual lookups were failing:

[root@webl001t mail]# nslookup 45.83.75.187.zen.spamhaus.org.
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
*** Can't find 45.83.75.187.zen.spamhaus.org.: No answer

<<< Note >>>: Repeat the above ad nauseam for about a month, on and off of course

Finally, I decided it was Sendmail that was the pain in the ass, and had to be my router. Just as a hunch, I unchecked “Use internal DNS”, and after a “service network restart” on the server, now the same DNS lookups were working!

[root@webl001t mail]# nslookup 45.83.75.187.zen.spamhaus.org.
Server:
Address:

Non-authoritative answer:
Name: 45.83.75.187.zen.spamhaus.org
Address: 127.0.0.4
Name: 45.83.75.187.zen.spamhaus.org
Address: 127.0.0.11

This, however, wasn’t the best solution as I’d rather not use my ISPs DNS servers if possible. But, I was finally on to something. Googling “DNSMasq DNSBL” came up with a lot of hits, and this discussion finally got me the answer.

After I added the below to my Tomato configuration under Advanced -> DNS/DHCP, I was finally good to go, still using my own DNS and also able to lookup domains with 127.0.0.0/8s in the response.

rebind-domain-ok=/rfc-ignorant.org/
rebind-domain-ok=/sorbs.net/
rebind-domain-ok=/uribl.com/
rebind-domain-ok=/surbl.org/
rebind-domain-ok=/dnswl.org/
rebind-domain-ok=/njabl.org/

[root@webl001t log]# nslookup 45.83.75.187.zen.spamhaus.org.
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name: 45.83.75.187.zen.spamhaus.org
Address: 127.0.0.4
Name: 45.83.75.187.zen.spamhaus.org
Address: 127.0.0.11

Today we had a problem after enabling client certificate authentication in JBoss 4.2.3. At first, I googled the problem and found that a potential JBoss speedup was to specify a different SSLRandomSeed option to point to /dev/urandom instead of the default “builtin”. Basically since the SSL parts were using /dev/random, which depended on entropy to generate “uniquely random” output. By pointing to /dev/urandom, which weren’t blocked by a lack of entropy (such as mouse movement, keyboard input, etc), the thought was that the initial SSL client handshake would be quicker.

From WikiPedia:

When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.[3] The intent is to serve as a cryptographically secure pseudorandom number generator, delivering output with entropy as large as possible. This is suggested for use in generating cryptographic keys for high-value or long-term protection.

Slightly problematic was the fact that /dev/random should be used for more “secure” applications, as opposed to /dev/urandom.

Anyway, long story short, the /dev/random thing didn’t fix our issue. The actual problem was that DNS lookups from the server to the outside world were blocked (the server was probably trying to do name lookups for the FQDNs of the certs/etc), and this was causing the initial connection to go VERY slowly (8 seconds or so until the DNS lookup timed out).

The simple(r) fix was to open up the firewall from that server to the world, and all was right. In the end, I did end up learning a bit more about entropy and JBoss, so I consider it a win.

Use case: You’re writing a shell script to stop/start a system service, but only want to do so when there is no activity in the server log. Change the FILE variable below to point to that log file, and modify the actions below under DONE=1 to what is needed.

Of course this assumes there is a file called “test-file” in the same directory as the script, but that can be changed easily. The file could also be modified to accept parameters on how long to wait, but that’s left up to the reader if the functionality is required.

#!/bin/bash
FILE=test-file
if [ ! -f ${FILE} ]; then
	echo 'file dont be there'
	exit 1
fi
DONE=0
CHANGED=0
while [ "$DONE" != "1" ]; do
	THEN=`tail -1 $FILE`
	for i in `seq 1 10`; do
		NOW=`tail -1 $FILE`
		if [ "$NOW" == "$THEN" ]; then
			CHANGED="0"
			# DEBUGGING # echo 'no change'
		else
			CHANGED="1"
			break;
		fi
		sleep 1
	done
	# DEBUGGING # set -x
	if [ "$CHANGED" == "0" ]; then
		DONE="1"
	fi
	# DEBUGGING # echo "Done is $DONE"
	# DEBUGGING # echo "Changed is $CHANGED"
	sleep 1
	# DEBUGGING # set +x
done

Today we had a strange corrupted file end up on one of our backup servers, and was not allowing any kind of chown or rm operations. We couldn’t take ownership through a chown, could not do chmod, rm -f, etc. A stat of the directory (“tulip” in our case) showed some ridiculous timestamps (last accessed was 1988 and changed was 2040), a sign of an obviously corrupt file.

First, to view the file attributes, do the following:

lsattr

This will show you the file attributes on all files in the directory, look for anything without a bunch of dashes (most files will have a set of dashes like below).


-------------e- ./kb-logo.gif
-------------e- ./Firefox_wallpaper.png
----------I--e- ./Downloads
-------------e- ./navPrimeRight3.png
-------------e- ./3_sync_db.sh
-------------e- ./Desktop


To remove the attributes, try the following (of course replace filename with the filename or directory you’re having trouble with):


for i in a c d i t u A D S T; do chattr -${i} ; done


Later we searched for other files that might have the same issue with (replace “.” with your directory name). Note in my case I’m throwing out the error stream from the initial lsattr command…


find . -exec lsattr 2>/dev/null {} \; | awk '!/\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-/ {print $1 $NF}'


From the chattr man page:

The letters `acdeijstuADST' select the new attributes for the files:
append only (a), compressed (c), no dump (d), extent format (e),
immutable (i), data journalling (j), secure deletion (s), no tail-merg‐
ing (t), undeletable (u), no atime updates (A), synchronous directory
updates (D), synchronous updates (S), and top of directory hierarchy
(T).