Linux

10 mistakes new Linux administrators make

If you're new to Linux, a few common mistakes are likely to get you into trouble. Learn about them up front so you can avoid major problems as you become increasingly Linux-savvy.

If you're new to Linux, a few common mistakes are likely to get you into trouble. Learn about them up front so you can avoid major problems as you become increasingly Linux-savvy.


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.

Note: This information is also available as a PDF download.

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

#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+r,u-wx 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.

#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 the pitfalls will take you through the Linux migration rite of passage faster, and you will come out on the other side a much better administrator.

About

Jack Wallen is an award-winning writer for TechRepublic and Linux.com. He’s an avid promoter of open source and the voice of The Android Expert. For more news about Jack Wallen, visit his website getjackd.net.

59 comments
boris b
boris b

Begginers mistake: 

1.thinking that reboot wil solve your problem! Depending of a problem it might but there are good chance that you wont be able to bring server up. 

2.unload network module on remote server

3.Changing conf files you do not understand. In Linux there is no back like in Windows.


m_pahlevanzadeh
m_pahlevanzadeh

you don't use history that with start with rm same: !rm

uiae
uiae

I totally agree with almost every part you said but the kernel-update-thing I can't understand. Why do admins have to update their kernel every once in awhile? I allways stick with the kernel my distro offers. I get regular security updates and bugfixes for it. Why should update my kernel just because there is a newer version? Bumbelbee

bcarpio
bcarpio

The Number One Mistake All New Linux Sytem Administrators Make Is Install Ubuntu

SilverBullet
SilverBullet

In 1981 I learned RPG-II at the same time I was learning COBOL, still see many mid-range shops with RPG of some version. Can't kill it.

jdclyde
jdclyde

I have installed software that would not install correctly if you SU'ed to root instead of logging in as root. That is a system shortcoming, not an admin problem, so just throwing it out there if you follow all documentation and an install/upgrade still won't work. The biggest problem I have seen from the human side is the pathetic amount of system documentation. (mind you, not exclusive to *nix by any means). Between the egos and the insecurities, losers try to keep things close to the chest so they can pretend to be more valuable than they are.

pjc007
pjc007

When talking about 'common mistakes', it helps to get your examples correct!! You state "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." This command sets the exact opposite permissions than those you wanted, setting (in fact) -w- for the user, when you wanted r--. In general, it is best to use = when setting u or g permissions rather than + or -, because then you know exactly what the result is. If you specify 'chmod u=rw', then you *know* the file's owner gets read + write (and not execute) access. On the other hand, if you specify 'chmod u+rw', then all you know is that rw is set, while x depends on whether it was set in the first place. Personally, I don't use rwx, but Always numbers, because it's a shorthand that lets me set User, Group and Other all at once. As long as you can remember that the 3-digit code is UGO; r=4, w=2, x=1; and you can add, then it's simple. -paul

custangrox
custangrox

#1 Mistake... Picking Ubuntu as a server....

explorehalkidiki
explorehalkidiki

"#5: Not keeping a working kernel installed" What? Why even bother to remove old kernels? You're just making work for yourself and creating the risk of removing the 'wrong' one.. #7: Booting a server to X: "This will waste precious memory and CPU cycles." Bullshit. If the server can't handle the fact that X is running whilst performing it's normal server functions then the server is under powered. The overhead of running X is simply not that big that it should make a difference to the server's ability to perform it's functions unless the hardware specifications are insufficient. Under normal operating load your server should have plenty of spare memory and cpu cycles so that it doesn't struggle when the load goes a bit higher than usual for some reason. "it will also keep prying eyes out of your machine " This should be irrelevant. Your server should be in a secure server room. If your server is in a location where 'prying eyes' are able to look at it then the owner of those 'prying eyes' will have physical access to your machine and that in turn means that they have total control over your machine should they want it. Seriosly, this article has some real nonsense in it.

bigbearomaha
bigbearomaha

Well, most are good suggestions. With the exception of making people paranoid of logging in as root. There are certain functions and apps that require logging in as root. Not that many and not that often, but ut does come up and people who are nervous or terrorized of doing so will be even more prone to making a mistake. It's like telling someone to stare at a big red button then telling them they must never push it. Eventually, it will get pushed. How will the user react, with fear and uncertainty or with as calm a mind as possible and deal with the situation. Building paranoia in Linux is not needed. Logging in as root can be done without killing your system or inviting trouble at the first keystroke. It simply requires people to be aware of the environment and doing only that which needed to be done while there. Being logged in a GUi session as root does mean a user needs to be much more careful, but still, we should be instilling confidence, not fear. If we're going to do that, we might as well work for MS. Big Bear

Neon Samurai
Neon Samurai

If you mean downloading the latest kernel.org source and compiling it then no, not something an admin should need to do. If you mean the newer kernels from your distribution, consider it a critical update. Your daily updates are good but they are for things outside the kernel and a reboot is rarely required for those. An updated firefox or apache is pretty important. Kernel's are not updated on a whim though. A distro like Debian is not going to give you a newer kernel for Lenny (stable) just to have the latest version number. Along with better hardware support, the newer kernel is going to include stability and security fixes. A kernel that crashes under some circumstance is a problem for your server's uptime and that fix will be important for those affected. A flaw that allows kernel hijacking or privileged escalation is a critical concern though. A buffer overflow in the browser may allow malicious access to the system as a regular user but a buffer overflow in the kernel opens the entire system up. Consider that the kernel type and version is part of data gathering and flaws in older kernel versions will be well known. If someone sees that you have a two year old kernel with five known exploitable vulnerabilities, they are going to try and hit that (hopefully, it's a contracted security auditor rather than motivated criminal). If your not updating your kernel from the repositories, you really should consider starting. At least check your distribution for what improvements are included in the new kernel. I know Mandriva gives security related reasons for the update and Debian will have similar.

Neon Samurai
Neon Samurai

Ubuntu is the popular pick for desktops these days but wouldn't be my first pick for a server install. Better to go Debian proper or a BSD for that.

raisputin
raisputin

Indeed installing Ubuntu is a n00b mistake. As for the installing everything from a damned .deb or .rpm, I can tell you that there are so many times that I have to compile from source as there is no .rpm, .deb, .whateverpackagemanageryouuserequires.something available that I don't even bother installing from anything other than source anymore. That was how I started, went to the package managers and am back to my roots. Works so much better...

pgit
pgit

[EDIT] D'oh! Crossed in the mail, ya beat me to it, Rick... There's a difference between root privileges and a root environment. Not sure how universal this is, but with my distro su gives the user root privileges on the command line. But if you add "-" to it, the result is a full root environment, all the extras behind the scenes will be called as root, not just whatever command you place on the command line. su -

Rick.Carter
Rick.Carter

It may well be that environment variables need to be set properly for the root account to install some software. Do keep in mind that: su - runs the entire login sequence for root whereas su doesn't. So if an install fails using "su" it may well work fine with "su -"

tech10171968
tech10171968

IMHO Linux, period, suffers from poor documentation. Yeah, yeah, I know all about the "man" pages but, sometimes, those things can get kind of cryptic to all but experienced users (which is why I've always held back from telling new users to "RTFM"). I really wish they were done more in the style of *BSD; their documentation is so clear that even a 10-year-old can understand what's going on there.

jlwallen
jlwallen

sorry about that. i believe it was fixed.

csmith.kaze
csmith.kaze

Haha. I use Debian at work, but now that I am an Archer, I can't think of any reason not to use Arch (maybe Gentoo)

williamjones
williamjones

...I just had to smack my forehead when it was reported that the Debian team had introduced a critical flaw to openssl earlier this year. http://www.neowin.net/news/main/08/05/13/debian-and-ubuntu-flaw-leaves-private-sslssh-keys-guessable and... http://www.internetnews.com/security/article.php/3747296 It's not realistic to expect Linux to never have security problems, but developers shouldn't fork to their own version of ssl/ssh without being very certain what they are doing. They are the foundation of remote security for most systems! Sacrosanct!

jlwallen
jlwallen

i have used many distributions as servers and have found Ubuntu server edition a fairly reliable server. what, in your opinion, makes ubuntu server edition so bad?

lightweight
lightweight

Interesting position you take... Ubuntu is Debian, and Debian is perhaps the best server platform available. Ubuntu offers regular update cycles and more up-to-date packages than stable Debian, but has more polish than most Linux distros. We've been using it on our own and our customers' server infrastructure since Hoary Hedgehog (left Red Hat), and haven't regretted the decision for a minute. Perhaps you could expand on your rather bold assertion with some actual reasons? Based on what you've written, it's quite easy to assume you haven't got a clue of what you're talking about...

jmgarvin
jmgarvin

Ubuntu is great for my dad, but pretty craptastic for a server...

Jaqui
Jaqui

I agree. picking Ubuntu for ANYTHING is a mistake, they butchered security with their configuration.

Neon Samurai
Neon Samurai

If you need GUI administration tools that badly then install Webmin and work through a browser. X and a full window manager is great on a desktop where you want that kind of interface but on a server it has no place. Installing the added software for X plus a window manager does not make apache serve websites any better. An install of X also increases complexity leading to higher risk of vulnerabilities. That additional software also slows down your boot time and consumes storage and ram. It's not just about giving up a hundred meg of storage because the hardware is powerful enough to manage, it's about not increasing the complexity of your server without any real added advantage. X on a server is like ordering ice-cream trucks and clown cars too use as police cruzers; it looks fun from the outside but does nothing to make the vehicle perform it's functions. For kernels; older kernels have flaws regularly patched in newer kernel releases. If your upgrading your kernel and you've confirmed that the new works, you don't need the old "just incase" one in place anymore; remove it. Remove all that old kernel cruft. This is good server house keeping; you won't accidentily boot the old kernel or waste storage space holding on too it. On a home machine or developer's desktop; sure, have every kernel version you've ever compiled and looked at. On a server; keep it clean. And last, physical security is very important but it shouldn't be the only security measure in place. Maybe the server room is shared and others have access too it but "hosting" lockers are not provided. Maybe you own the entire server room but what happens after that door gets opened? Maybe it's physically secure but with not upgrading your kernel regularly, you've left a nice big network exploitable bug in place..

Jaqui
Jaqui

why not FREE UP THE DRIVE SPACE? most *x admins have a /boot partition that is not large enough to store lots of not used kernels. also, the boot menu gets cleaned so only those kernels installed are listed, so you don't have 10 or 20 items listed when you do have to reboot the system.

Neon Samurai
Neon Samurai

I'm probably more comfortable working as Root than I should be and usually have a terminal open and rooted. I never log in as root though; always, always, log in as user then su too root if it's not a common enough task to justify a sudo configuration. If the user becomes to comfortable logging in as root then you end up with Windows security; always working under the administrator account instead of a proper user account. This has the added good habit of not transfering Root/Admin credentials until you have an established secure connection using a lower security level account. It also becomes very easy to make a mess of the system because you don't stumble over security precautions put in place. I work the same way on Windows machines too. A cmd box gets opened with Admin rights after logging in as a regular user. If it's something drastic or that can't be done easily started off an Administrator cli terminal then login fully as Administrator.

rob
rob

I see your point and I actually get a lot of stares when I tell people that I "su -" to perform work as needed. But I think the general fear is just the slip of the hand and human error. The old days it didn't take much to erase files on your Linux box, something as simple as rm -ra / did the trick, but thankfully we have come a long way and things like that just are not even plausible anymore. The advancement of the GUI has made administration "easier" than ever before and you see if more often now "admins" who can't get their job done because they are figuring out how to perform a task with the GUI when it could have been done hours ago via the command line. Logging in as root under the GUI is really a disaster waiting to happen. If you are the only person administering th network then you have no problem, but when you have 10 people using that machine, your chances are higher. I think the paranoia needs to go away and just preach "caution" and common sense to be aware of your power as root and second guess steps you don't normally do.

Neon Samurai
Neon Samurai

Serious question actually. I am curious to know what packages your running into that you have to compile. Base system, hardware support, Xwindows, KDE.. all there. Multimedia support also. Ruby, aircrack, sniffers and scanners.. there also. Heck, the venerable OPH is a packaged .deb. IDS, AV.. got it covered. Firefox? Thunderbird? replaced seamlessly with Iceweasel and Icedove. Enigmail compiled for 64bit with Icedove and the Firefox plugin site works perfectly with Iceweasel (so far). VMware has it's own installer so that is a third party to any distro really. Actually, the only thing I've run into yet is Hydra which does not seem to have a .deb available. For that work, I'm more likely to run the Backtrack boot but I'm seeing how much of my regular tool kit I can get native from the Debian repositories.

Jaqui
Jaqui

then using the tools of your distro, make one and install it. that gives you the benefits of the package manager's dependency checking. yup, it adds a bit of complexity to the install, but it can save you many headaches down the road.

jdclyde
jdclyde

Thanks for the answer/explanation.

jdclyde
jdclyde

Got my initial training in SCO OpenServer. Don't know if it was different, or I slept through that part, but that is new to me. :0 As they say on the big screen, "DOH!" ;\ Thanks

jdclyde
jdclyde

Most, written by developers for developers, not users. At least there are more support sites, so decent documentation CAN be found if you are willing to look.

rudymogavero
rudymogavero

Good point(s).... bold assertions without actual facts usually end up on the side of the road.

Jaqui
Jaqui

Ubuntu is debian BASED, but it most definitely is NOT debian. Ubuntu killed security with their sudo configuration. and then, they insult usability with the GNOME desktop.

jlwallen
jlwallen

i included this is because new Linux admins aren't nearly as adept at the command line as old-hat admins. add to this the fact that there are a number of decent GUI admin tools and you have an obvious reason to install the gui. but for anyone adept at the command line - X isn't not necessary.

edeloye
edeloye

use sudo as your first choice when running commands requiring root privilege. It provides an audit trail via the logging facility so you can go back and see what you have done. Also, you can forget to log out of the root account and run commands thinking you are logged into your user account. That is never a problem with sudo.

bigbearomaha
bigbearomaha

That is the biggest area of education needed. Who and what environment logging in as root is necessary. First off, no user, as in, a person who is NOT responsible for the maintenance of that machine or system, should be logging in as root and should not be given the root password to even SU. That's not a "users" place or responsibility. The only person, persons, who should be able to log in as root are the System admin, ( not all of the asst admins, techs, etc...) or, if it's a "Home" system, then whoever the responsible owner/parent/person-in-charge should even know the root password. By assuming that just anyone even has access to the root password shows a breakdown in security and protocol to begin with. On a production environment system, only the one admin needs to know the root password. everyone else who needs to do work on that system, the select few, that's what sudo is for. not only does sudo allow chosen users to have certain access, the access can be specified exactly to what their job/tasks entail AND, it logs the actions of those working, providing a trail for the admin to follow should something go wrong.

hackertarget
hackertarget

even if you recompile kernels in your sleep not using a package manager on production kit results in poor management. what happens when you leave and the newbie admin takes over.

kingttx
kingttx

If the sudoers file is kept clean with only the administrator's account allowed full sudo, why not? Make sure risk is mitigated with stuff like a complex password and there is little difference. Making the assumption that ALL end users have sudo access is short-sighted.

heres_johnny
heres_johnny

Yes, Ubuntu's sudo configuration makes it unsuitable as a server, for the reasons you mention. I would use Debian in that case. But the snarky quote about GNOME is rather pointless, as servers should be using command line most of the time. Of course, you could log in to play Solitaire on your server, suit yourself. Maybe then KDE would meet your needs better. ;-)

Jaqui
Jaqui

Ubuntu has 35% of GNU-Linux security. they do not have a system admin password that is different from the end user password, making system admin access via an EXPOSED on website end user login. effectively, Ubuntu is no more secure than windows xp. until they fix their screwup, anyone using it needs to have the insecurity pounded into their heads repeatedly.

lightweight
lightweight

Security has been dead since the dawn of Windows. Ubuntu security is Linux security which is as good as anything in the consumer space, and better than most, and can be made as sound (with SE Linux and other hardening approaches) as OpenBSD if that's a requirement. It isn't for most people. I think you're being a bit hyperbolic when you say sudo kills security. Use the "sudo" approach or not. Debian allows you to do it, so does any other Linux if you configure it that way. Frankly, for an end user machine it means that people aren't as tempted to log in as Root. On servers, we don't really use sudo. It does offer control and an audit trail. Ultimately, the only secure computer is one that's off... but it's also not very useful, eh. As for GNOME, I'd take it over Windows or OSX any day... The nice thing about Ubuntu is that you have XFCE, KDE, and any number of other desktops or non-desktops you might want. If you don't like GNOME, use something else, you're spoiled for choice. So, rather than slagging off Ubuntu with vague assertions, perhaps you can tell us what you think lives up to your high standards (if anything).

jlwallen
jlwallen

my intention was to focus on new admins where linux tools (especially command line tools) might be unfamiliar. X Windows should not be a default part of a server. and even if you have X installed you should always have servers boot to run level 3. if you need X, then startx.

Neon Samurai
Neon Samurai

The irony of course being the previous person to give me grief over grammer but for using "to" instead of "too" Look all, you'll just have to read my comments with more attention to context and less attention to specific characters used in my spelling. I'd just rather focus on the technology rather than "too" vs "to" or "their" vs "there". I believe strangled and strangle should be in your repository next to talkd and talk. ;)

kingttx
kingttx

Neon, if you use "too" instead of "to" one more time, I'm going to reach through this keyboard and strangle you! ;) Hey, I'm running Linux, too, so there has to be a strangle client and server somewhere around here... j/k

Neon Samurai
Neon Samurai

Too train the local admin (comfy with Windows but wanted a *nix server). Since the admin is local too the server, we started with an X install and introductions through the GUI tools. The admin is moving towards better cli based skills though. Personally, I don't want to give up my draketools for the desktop. On a server, Debian with webmin has been great though. That previously mentioned server's build version 2 will be a significant improvement. If there is a reason for X on a server then great but the post I responded too sounded like X should be a default part of any server which is just asking for issues.

Neon Samurai
Neon Samurai

If a regular user can do it then no worries. If a regular user needs it and can do it with sudo then that's plan B. If it really takes a root account then planC; su to root. If for some reason, it can only be done by Root logging into the terminal directly and "su -l" won't cut it for some reason that Root login is the final fallback. In some systems, the root account is actually restricted from logging in directly so you are forced to start with a regular user then su or sudo after that. My response was about using full Root access when required though so I didn't go into the details of lower levels.

Neon Samurai
Neon Samurai

You said "making people paranoid of logging in as root" where my point was that no one should log in as root in the first place. Regular users have no reason for Root as you point out in your second comment. Users who have a specific task that requires higher rights can use the properly restrictively configured sudo. Root, the person responsible for the machine, should still be logging into the system under a regular user account. Once logged in by keyboard or through a secure channel like SSH, then the admin should su to Root. I agree that people should not be made paranoid of using Root rights when required but becoming too comfortable being ?root? can easily break a system with even an experienced admin. Actually, I?m not sure how your response relates to your initial comment. It seems to indicate that I?m over reacting by listing the exact points I?m making.

Editor's Picks