Image of the glider from the Game of Life by John Conway
Skip to content

Use The Tools

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/ 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.

{ 6 } Comments

  1. Roland using Konqueror 3.5 on Kubuntu | March 13, 2009 at 9:30 pm | Permalink

    Why usermod? Why not 'chsh' ?

  2. Elizabeth Krumbach using Firefox 3.0.4 on Ubuntu | March 14, 2009 at 4:38 am | Permalink

    Similar to the above comment, I use "vipw" (vipw -s for shadow, and vigr is used similarly for group) for this. Not sure if it would avoid your issue above, but it is another tool that does some syntax checking.

  3. Michael using Firefox 3.0.7 on Ubuntu | March 14, 2009 at 7:29 am | Permalink

    I use sysv-rc-conf 'tool' for editing my startup (init.d) services:
    for example
    sudo sysv-rc-conf -s 2S

  4. Marcos Dione using Konqueror 4.2 on GNU/Linux | March 15, 2009 at 8:08 am | Permalink

    I think the problem is that the tool you expected to work, namely usermod, failed unexpectedly. I don't understand on which situation modifying a user's data would be wrong/misleading/catastrophic while the user is logged in. I guess that's why I try to install gnu tools everytime I get access to a closed-source *nix.

  5. Ryan using Firefox 3.0.6 on Windows XP | March 16, 2009 at 7:20 am | Permalink

    Why would you even consider changing root's shell? If your #1 rule is to use the tools given, the #2 rule is to never screw around with root's entries in passwd/shadow.

  6. Eric using Internet Explorer 7.0 on Windows XP | September 19, 2009 at 5:46 am | Permalink

    HP used to caution against changing root's shell to something not on the root disk - not sure where they put bash.

    When reading, I was conerned that you were going to suggest people use SAM!! Out of all the tools, I suggest people avoid that like the plague!

Post a Comment

Your email is never published nor shared.

Switch to our mobile site