Chris’ Blog

I’m not sure what I can really say to that, other than n00b!

One of my NSLU2’s went up the swanny two weeks back. Typically it was the one 80 miles away at home, that not only is my primary mail exchanger but also the DHCP server for my home network, chances are somebody might notice. Thankfully I have the ability to fail over DHCP onto sandman with a one line configuration change and a restart of dnsmasq, which I did.

Whilst I was at home this past week I got to work trying to work out what was up. The documentation in Debian about the LED sequences told me that it was getting stuck at the initramfs stage of boot. Basically it couldn’t load the actual operating system off the discs. This meant I would have to delve deep and play with the contents of the flash memory.

I mounted the USB sticks that I use as its discs on my server and extracted a copy of the current kernels and initramfs images that were on it. I also found the Debian installation flash firmware and set about hacking the two. I found some instructions on how to modify an existing image which is what I did. I swapped out the kernel and initramfs in the firmware for the latest ones on my discs and flashed the NSLU2. Same thing happened! So I then set about using the previous kernel version which worked like a charm. For now I have removed the new kernel from it and forced it to keep the old version. I will look into updating it when I have a little more time.

After my recent break in I have looked into ways of protecting SSH and my server resources. I employ fail2ban on my main server, it has the resources to run such a programme - my Linksys NSLU2’s however do not. The solution is to use iptables to limit the number of connections any host can make in a given time frame. I wrote up a quick how to on this over at my wiki. Enjoy.

So today I come to you with a confession, I discovered one of my boxen had been successfully attacked and the attacker had by the looks of things used it for launching DDoS attacks. I feel particularly stupid because the entire thing was my fault, I left the root password as root. Although I must stress I didn’t set it to this, I was using a pre-build debian install because the d-i installer was broken under arm and forgot to change the root password to something a little more secure.

Ekiga is a VoIP client for GNOME. I recently registered with SIPGate.co.uk as I am planning to have a go at setting up Asterisk sometime in the near future. Sadly it wasn’t a well documented process and after searching Google, SIPGate’s website and Ubuntu Forums for help I found some tips on debugging Ekiga. Armed with this knowledge ekiga --debug=[1-6] I managed to discover the required ports for successful NAT traversal. They are as follows:

• 5060 - 5100/udp
• 8000 - 8012/udp
• 5004/udp
• 10000/udp
• 3478 - 3497/udp
• 3478 - 3497/tcp
• 1720/udp
• 30000 - 30010/tcp

I am sure they could be refined and there maybe some that are unnecessary but it Works or Me™, use them at your own risk.

So, this is the second time I have tried to address the problem I was getting with some Subversion repositories I was trying to configure to be served by Apache. I was trying to use the SVNPath directive to serve one repository but it was not having any of it, so instead I ended up serving them as a temporary measure using SVNParentPath in the format http://svn.example.com/~name/repos/ which is not what I wanted. I am using the Location container in Apache configuration to configure up my repositories, the path I had specified was /~name/. This is where the problem comes in, I would try to checkout the repository over the network and be greeted with a 405 Method Not Allowed error like so:

svn: PROPFIND request failed on '/~name'
svn: PROPFIND of '/~name': 405 Method Not Allowed (http://svn.example.com)

This stuck me as odd, it seemed the Apache was not serving the repository URI using the WebDAV module. When I gave up on an earlier attempt I reverted to using SVNParentPath and accessing the repository over the URI http://svn.example.com/~name/repos/ which worked perfectly and I couldn’t spot why. Turns out I made a single character mistake, my Apache configuration was set to use the path of /~name/ I should have used /~name because SVN truncates the trailing slash even if you specify it on the command line. Bugger!

Thunderbird’s default sorting is the wrong way around, IMHO. This has always annoyed me, I found out how to reverse it.

So for ages I have been using Thunderbird combined with server side mail sorting, what has been annoying me for a year or so is that Thunderbird only checks the Inbox folder. I had to manually check all the others and that got a little tedious, fortunately I discovered how to get around this.

The trick is to open the configuration editor (Edit -> Preferences -> Advanced) and set the mail.check_all_imap_folders_for_new preference to true. Bingo!

You can tell Linux to respond to broadcast pings by running this snippet from the console.

$ echo 0 | sudo tee /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Edit /etc/sysctl.conf to set the option permanently.

Turns out I had a computer on for even longer which I had forgotten about! benjamin, one of my Linksys WRT54-g’s. He doesn’t really do much apart from provide WiFi access for my PDA and networking for my room (two 100Mbps feeds are not enough). He will be moving back to Exeter with me later today, so beast will overtake him in terms of my record recorded uptime.

root@benjamin:~# uptime
 00:43:01 up 102 days, 43 min, load average: 0.00, 0.00, 0.00