Version 1.

0
10 mistakes new Linux administrators make November 29, 2008

By Jack Wallen
For many, migrating to Linux is a rite of passage that equates to a thing of joy. For others, it's a nightmare waiting
to happen. It's wonderful when it's the former; it's a real show stopper when it's the latter. But that nightmare
doesn't have to happen, especially when you know, first hand, the most common mistakes new Linux
administrators make. This article will help you avoid those mistakes by laying out the most typical Linux missteps.

1 Installing applications from various types

This might not seem like such a bad idea at first. You are running Ubuntu so you know the package management
system uses .deb packages. But there are a number of applications that you find only in source form. No big deal
right? They install, they work. Why shouldn't you? Simple, your package management system can't keep track of
what you have installed if it's installed from source. So what happens when package A (that you installed from
source) depends upon package B (that was installed from a .deb binary) and package B is upgraded from the
update manager? Package A might still work or it might not. But if both package A and B are installed from .debs,
the chances of them both working are far higher. Also, updating packages is much easier when all packages are
from the same binary type.

2 Neglecting updates
Okay, this one doesn't point out Linux as much as it does poor administration skills. But many admins get Linux
up and running and think they have to do nothing more. It's solid, it's secure, it works. Well, new updates can
patch new exploits. Keeping up with your updates can make the difference between a compromised system and a
secure one. And just because you can rest on the security of Linux doesn't mean you should. For security, for
new features, for stability -- the same reasons we have all grown accustomed to updating with Windows -- you
should always keep up with your Linux updates.

3 Poor root password choice

Okay, repeat after me: "The root password is the key to the kingdom." So why would you make the key to the
kingdom simple to crack? Sure, make your standard user password something you can easily remember and/or
type. But that root password -- you know, the one that's protecting your enterprise database server -- give that a
much higher difficulty level. Make that password one you might have to store, encrypted, on a USB key, requiring
you to slide that USB key into the machine, mount it, decrypt the password, and use it.

4 Avoiding the command line

No one wants to have to memorize a bunch of commands. And for the most part, the GUI takes care of a vast
majority of them. But there are times when the command line is easier, faster, more secure, and more reliable.
Avoiding the command line should be considered a cardinal sin of Linux administration. You should at least have
a solid understanding of how the command line works and a small arsenal of commands you can use without
having to RTFM. With a small selection of command-line tools on top of the GUI tools, you should be ready for
just about anything.

Page 1
Copyright © 2008 CNET Networks, Inc., a CBS Company. All rights reserved. TechRepublic is a registered trademark of CNET Networks, Inc
For more downloads and a free TechRepublic membership, please visit http://techrepublic.com.com/2001-6240-0.html
10 mistakes new Linux administrators make

5 Not keeping a working kernel installed

Let's face it, you don't need 12 kernels installed on one machine. But you do need to update your kernel, and the
update process doesn't delete previous kernels. What do you do? You keep at least the most recently working
kernel at all times. Let's say you have 2.6.22 as your current working kernel and 2.6.20 as your backup. If you
update to 2.6.26 and all is working well you can remove 2.6.20. If you use an rpm-based system, you can use this
method to remove the old kernels: rpm -qa | grep -i kernel followed by rpm-e kernel-{VERSION}.

6 Not backing up critical configuration files

How many times have you upgraded X11 only to find the new version fubar'd your xorg.conf file to the point where
you can no longer use X? It used to happen to me a lot when I was new to Linux. But now, anytime X is going to
be updated I always back up /etc/X11/xorg.conf in case the upgrade goes bad. Sure, an X update tries to back up
xorg.conf, but it does so within the /etc/X11 directory. And even though this often works seamlessly, you are
better off keeping that backup under your own control. I always back up xorg.conf to the /root directory so I know
only the root user can even access it. Better safe than sorry. This applies to other critical backups, such as
Samba, Apache, and MySQL, too.

7 Booting a server to X

When a machine is a dedicated server, you might want to have X installed so some administration tasks are
easier. But this doesn't mean you should have that server boot to X. This will waste precious memory and CPU
cycles. Instead, stop the boot process at runlevel 3 so you are left at the command line. Not only will this leave all
of your resources to the servers, it will also keep prying eyes out of your machine (unless they know the
command line and passwords to log in). To log into X, you will simply have to log in and run the command startx
to bring up your desktop.

8 Not understanding permissions

Permissions can make your life really easy, but if done poorly, can make life really easy for hackers. The simplest
way to handle permissions is using the rwx method. Here's what they mean: r=read, w=write, x=execute. Say you
want a user to be able to read a file but not write to a file. To do this, you would issue chmod u+w,u-rx filename.
What often happens is that a new user sees an error saying they do not have permission to use a file, so they hit
the file with something akin to chmod 777 filename to avoid the problem. But this can actually cause more
problems because it gives the file executable privileges. Remember this: 777 gives a file rwx permissions to all
users (root, group, and other), 666 gives the file rw privileges to all users, 555 gives the file rx permissions to all
users, 444 gives r privileges to all users, 333 gives wx privileges to all users, 222 gives w privileges to all users,
111 gives x privileges to all users, and 000 gives no privileges to all users.

Page 2
Copyright © 2008 CNET Networks, Inc., a CBS Company. All rights reserved. TechRepublic is a registered trademark of CNET Networks, Inc
For more downloads and a free TechRepublic membership, please visit http://techrepublic.com.com/2001-6240-0.html
10 mistakes new Linux administrators make

9 Logging in as root user

I can't stress this enough. Do NOT log in as root. If you need root privileges to execute or configure an
application, su to root in a standard user account. Why is logging in as root bad? Well, when you log on as a
standard user, all running X applications still have access only to the system limited to that user. If you log in as
root, X has all root permissions. This can cause two problems: 1) if you make a big mistake via a GUI, that
mistake can be catastrophic to the system and 2) with X running as root that makes your system more vulnerable.

10 Ignoring log files

There is a reason /var/log exists. It is a single location for all log files. This makes it simple to remember where
you first need to look when there is a problem. Possible security issue? Check /var/log/secure. One of the very
first places I look is /var/log/messages. This log file is the common log file where all generic errors and such are
logged to. In this file you will get messages about networking, media changes, etc. When administering a machine
you can always use a third-party application such as logwatch that can create various reports for you based on
your /var/log files.

Sidestep the problems

These 10 mistakes are pretty common among new Linux administrators. Avoiding these mistakes will take you
through the Linux migration rite of passage faster and you will come out on the other side a much better
administrator.

Additional resources

TechRepublic's Downloads RSS Feed

Sign up for the Downloads at TechRepublic newsletter
Sign up for our IT Leadership Newsletter
Check out all of TechRepublic's free newsletters
10 Linux desktops you shouldn't overlook
10 reasons for switching to a different Linux distribution
10 questions to ask before migrating to Linux

Version history
Version: 1.0
Published: November 29, 2008

Page 3
Copyright © 2008 CNET Networks, Inc., a CBS Company. All rights reserved. TechRepublic is a registered trademark of CNET Networks, Inc
For more downloads and a free TechRepublic membership, please visit http://techrepublic.com.com/2001-6240-0.html