When I taught Linux system administrators, I would go through a series of rules, and rule #1 was always:
Whenever you’re editing config files, and a tool exists to make the change, use the tool instead of editing the config by hand.
The logic is easy to follow. We as humans are capable of error. Unfortunately, error happens all too often. The more we rely on ourselves to make changes by hand, rather than use an automated system, we’ll be bound for mistakes. So, use the tools are the most appropriate means for making changes to your config file in Unix and Linux
For example, editing the /etc/sudoers file. Many will just use vim or emacs, edit away, save and quit, and call it good. This is unfortunate, as your editor probably doesn’t have a syntax checker for the /etc/sudoers file. As such, you should be using the ‘visudo’ binary which does ship with a syntax checker. What about editing the /etc/passwd file? ‘usermod’ is your tool. And for the /etc/shadow file? ‘chage’ my friend. You should even use ‘postconf’ for your /etc/postfix/main.cf file. Of course, there are config files that don’t ship with an appropriate tool to edit the config file correctly. Further, there are times when editing a config file by hand is called for. However, you should be reaching for the tool first.
Now with this in mind, let me tell you an experience I had breaking this rule.
At my current place of employment, I’m in charge of several HP-UX 11v1 servers. Being new to HP-UX, I’ve been spending many an hour reading the documentation off of HP’s site, and dorking around when I have the time. It’s been a fascinating experience. Recently, I discovered that HP-UX can access software from a software repository (they refer to them as “depots”). This was great news to me, as I was getting real tired of the Bourne shell. I miss my tab-completion, inline history editing, and other shortcuts I’ve grown accustomed to. So, I looked for BASH, and it was available. I installed it using ‘swinstall’, and I was up and running. Now all I needed to do was make BASH the default shell for my account and the root account, and I’d be in heaven.
It worked fine setting the shell for my unprivileged user, but not for root. Every time I ran ‘usermod -s /usr/bin/bash root’, it came back with an error saying that the root account was already logged in. Well, of course! How do you expect me to change root’s login shell? Well, rather than troubleshoot the issue, and learn if there was an appropriate way to accomplish this task, I jumped into the /etc/passwd file with vi, and edited root’s line. Except, apparently, unknown to me, I made a syntax error.
This was discovered when I wanted to login. Even after providing the password successfully, I was unable to reach a shell prompt. I tried everything I could think of to become root, but everything was failing. I thought further about single user login from a reboot. Could that even be possible? Will single user mode still process the /etc/passwd file? Frantic, I started thinking irrationally, thinking about sending a password file via SCP, FTP or NFS, logging in without creating a new login shell, and other craziness.
I was bothered the rest of the day, and through the night. I didn’t sleep well, and I was up very early before the day started to see if I could think of anything new. Thinking of sending the file via SCP, I wanted to check the permissions of /etc. I looked, and saw ‘r-xr-xr-x’. I thought this was odd, so I thought I’d look at the permissions of the passwd file itself: ‘rw-rw-rw-’. Yes, you read that correctly. Anyone and everyone on this system could edit the passwd file!!! Could this be true? I logged in as my unprivileged user, made the edit, saved the file, and exited. I still didn’t believe what just happened, so I had to cat the file out to the terminal to double-check: just in case. Sure enough, the edit stuck, and I could login as root. The unprivileged user saved the day, due to a horribly bad permission set on the /etc/passwd file.
Sometimes, it takes the worst of experiences to teach us lessons in life, and one such lesson was taught to me that I spent so much time teaching to my students. I should have spent the time learning why usermod would not let me change any login attributes for root. Rule #2 to my students was always:
If the tool doesn’t succeed, learn why.
Maybe editing the config file by hand was the appropriate solution. Maybe not. All that matters here, is I made a rash decision that could have had disastrous consequences, all because I didn’t want to use the appropriate tool or troubleshoot the problem.