One of the potential pitfalls of being a technically oriented person is that every once in awhile you start to actually believe that you know exactly what you are doing.
Anecdotal reference material: I’ve spent the last few days setting up a FTP/web server using Fedora Core 5 (for better or worse… we’ll see). I’ve been configuring all sorts of things; disk quotas, Samba, FTP, user creation scripts, setting the static IP address… Then blam — I decided to reboot it to make sure everything was set up and working.
Well, it never did reboot.
Oh, it seemed to be working, and all. The trouble was, the boot process got to be taking about forty minutes. I, in my razor sharp technical analysis, concluded that something was wrong.
Now here’s the problem: laboring under the delusion that I could do no wrong, I had reset and reconfigured a half-dozen or more different things before the reboot. This makes it nigh impossible to determine which of those many changes was actually responsible for the failure on reboot.
As difficult as it may be… as much as we might feel like we know what we’re doing… the only way to make sure that we can trace a problem is to just do one thing at a time; then stop — test it — and go on.
This is a debugging technique in programming — if you have a program or a long-ish function that is not working, you can add some temporary “status” outputs after each action. That way, you can determine exactly where the program is failing. Unfortunately, when configuring a Linux server (or any similar activity), one can’t roll back time and add break-points and then fast-forward a dozen times to see where it broke down. You have to remember to do that as you go.
Do you have to stop and test what you’ve done after every step? No; of course not.
Just don’t go crying to anyone when your server won’t boot and you don’t know what you did to break it.
The ultimate tip. I do this when I’m at work but not at home. How funny is that?
I wonder how many people do the one-at-a-time method on their own time.