Racker Hacker

I finally remembered this book when someone asked me about how to get started with PHP and MySQL development. If you get the chance, get a copy of this book:

PHP and MySQL Web Development by Luke Welling, Laura Thomson
Barnes & Noble: http://snurl.com/265xp

Why do I like this book so much?

• Teaching by application - The book teaches fundamentals by showing how to apply techniques to an active website. There’s not a ton of theory to wade through, and you feel like you’re learning the material faster.
• Intertwined strategies - You learn how to get PHP working with MySQL, and then you learn how to optimize your code. It’s important to know which work is best done by PHP and which is best done by MySQL. This book teaches both.
• Lots of examples - The CD-ROM comes with tons of code examples that actually relate to something you can use.

I’d be happy to loan my copy, but I’ve loaned it out and it never returned.

I’ve just upgraded RackerHacker to Wordpress 2.5.1. If you haven’t upgraded your own blog installation yet, I’d recommend doing so soon!

Download It
Upgrade It

I’ve been busy with work and I haven’t had time to add some posts. Rest assured, I am still here and working on new content for you.

Last week, I found myself with a server under low load, but it couldn’t make or receive network connections. When I ran dmesg, I found the following line repeating over and over:

ip_conntrack: table full, dropping packet

I’d seen this message before, but I headed over to Red Hat’s site for more details. It turns out that the server was running iptables, but it was under a very heavy load and also handling a high volume of network connections. Generally, the ip_conntrack_max is set to the total MB of RAM installed multiplied by 16. However, this server had 4GB of RAM, but ip_conntrack_max was set to 65536:

# cat /proc/sys/net/ipv4/ip_conntrack_max
65536

I logged into another server with 1GB of RAM (RHES 5, 32-bit) and another with 2GB of RAM (RHES 4, 64-bit), and both had ip_conntrack_max set to 65536. I’m not sure if this is a known Red Hat issue, or if it’s just set to a standard value out of the box.

If you want to check your server’s current tracked connections, just run the following:

# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count

If you want to adjust it (as I did), just run the following as root:

# echo 131072 > /proc/sys/net/ipv4/ip_conntrack_max

I’ve been on a bit of a vacation lately, and that’s why there’s been a lack of updates. On October 20th, I married the best woman on the planet, and we we’ve been on our honeymoon since then.

New updates should start again this Monday!

Operating System:
Red Hat Enterprise Linux 4 Update 5

What happened:
The server was abruptly powered down, disassembled, and re-assembled.

Work done:
Ran a fsck from the rescue environment and it eventually completed (after much corruption was found), but the server would not boot properly.

End result:
The damage to the filesystem could not be adequately repaired as the errors were very extensive. The RAID array had to be rebuilt and a new OS was installed.