It started with a single loud beep from my UPS. The thunderstorm outside had caused a short power fluctuation but I wasn’t really worried. After all the server is connected to the UPS so that I don’t have to worry about such things.
As my desktop was still happily running (without assistance from the UPS) I continued playing my computer game. But when I tried to save the score the next time the machine suddenly hung. I blamed the problem on the game itself and decided to login from another computer to kill the game’s process. Only when I took off my headphones I noticed something was wrong: I could no longer hear the humming of the server’s fans. 🙁
I remembered the beep and pressed the power button of the server which immediately sprung to life. I pulled the power cable of the UPS to confirm my findings, got another loud beep and the server powered down right away. It seems that the battery of the UPS had finally broken down which is no big surprise after roughly seven years of service. I only wish I had figured that out in a less inconvenient way.
I ordered a new battery in the meantime which will hopefully be delivered later this week. With the new battery the UPS should be good for a few more years.
A wish came true: NetBSD finally has a journaling file system. Simon Burge added support for WAPBL, Write Ahead Physical Block Logging file system journaling, to NetBSD-current’s main branch today.
The main purpose of a journaling file system is to avoid a time consuming file system checks after a power failure, system crash or similar problem. But it can also help to improve performance considerably depending on the design. As I was curious about WAPBL’s performance impact I ran my usual benchmark (extracting the NetBSD 4.0 source tar archives). And the result is very encouraging: FFS required 15:19 minutes to finish the benchmark without logging and only 3:24 minutes to finish it with logging. It seems that WAPBL provides similar speed improvements as soft dependencies and keeps your file system safe at the same time.
A big thank you to Wasabi Systems for donating the code and to Simon Burge and all the other developers for integrating WAPBL into NetBSD!
The latest DNS security issue (please read Hubert’s Blog entry) proves again that NAT is a bad idea. If you run a DNS server behind a NAT (which you really shouldn’t) you can pick one of two evils:
- You use a fixed query source port on your DNS server which makes it susceptible to DNS cache poisoning.
- You use random query source port which will create a lot of entries in the NAT mapping table of your NAT gateway. But as DNS mostly uses the connectionless UDP the NAT gateway can only rely on idle timeouts to delete those mappings. As a result the NAT mapping table will fill up quickly. This will cause problems especially on small router appliances.
Even if your NAT router can handle this gracefully there is a good chance that it will undo the randomisation of the source port by assigning sequential port numbers on NAT mappings.
The only solution I can think of are NAT implementations which recognize DNS traffic and use very short lived NAT mappings for it. But that will make NAT even more evil because it has to make more assumptions about that IP traffic to work properly.
What we really need is DNSSEC (to make DNS secure) and IPv6 (to get rid of NAT).