What is Digg?Sponsored by Travelzoo
Take Advantage of Ridiculously Low Holiday Airfares view!
travelzoo.com - Flights $52 and up for Thanksgiving, Christmas & New Year. But move on it now.
165 Comments
- inactive, on 11/30/2008, -7/+78Beards.
- Stalks, on 11/30/2008, -0/+50rm -Rf / ... ****** ***** stop stop CTRL+C CTRL+C*
iptables -I INPUT -j DROP .... *ah *****, another trip to the datacenter*
shutdown -h now ... ****** *****, I meant -r .. -r!!!* - garths, on 11/30/2008, -16/+52#1 should be: Develop obnoxious pro-Linux anti-everything-else attitude.
You're paid to make things work, not to whine and moan. - sparcnut, on 11/30/2008, -0/+18What's up with #3? Their suggestion of putting a complicated root password on a usb stick is insane. To mount something you either have to be root, have an fstab entry (with user/users in the option field), or rely on a daemon to do it for you... sounds like a great way to lock yourself out of root if the system fails, which is probably why you'd need root in the first place.
Also #6. Why does xorg.conf need to be protected so that other users can't read
it? There's nothing secret in there! In fact, it takes away the convenience of being able to scp an existing xorg.conf from a working machine to set up another (you do have root logins over ssh disabled... right?) - lonewolfe, on 11/30/2008, -2/+20#9 applies to all types of computer users, IMHO
- scabbers, on 11/30/2008, -6/+20#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+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.
#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 - iamedward, on 11/30/2008, -1/+14Hmmm... I think i have made all of those mistakes at some point, my bad.
- iLemon, on 11/30/2008, -0/+12I have had to disable the GUI on servers and Cisco devices to discourage people higher on the totem pole from "fixing" or "tweaking" perfectly working configurations.
- inactive, on 11/30/2008, -10/+22Great article. that is really common mistakes...
- colinm, on 11/30/2008, -2/+14wrong:
"...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..." - dualcyclone, on 11/30/2008, -0/+111338 bitches!
Who avoids the command line? I can't avoid the command line even when I'm taking a piss!
cd bladder
rm -rf *
echo -n ahhhhh - Nicoon, on 11/30/2008, -0/+10@Blackb0x:
"Except when you have a vendor-supplied application that requires a GUI install. "
Like said, there's really no need for having X running when you don't use it. When you do need it, you simply start it by using the "startx" script. Don't leave it running all the time in a server environment. Launch it on-demand! - aflury, on 11/30/2008, -0/+10I've never heard of anyone accidentally doing "rm -rf /" unless maybe they were tricked into doing it. A lot more common though is doing something like "rm foo *" when they meant "rm foo*". I don't think changing the rm command is really the answer... the answer is to not use -f unless you're being very careful and know what you're doing, and maybe putting something like alias rm="rm -i" in your ~/.bashrc or whatever if you're prone to such mistakes.
I don't want Linux to turn into a Windows-like "Are you sure?", "Are you really sure?" type interface. - glitchbit, on 11/30/2008, -0/+9Actually I am wondering if this guy has ever worked as an administrator for any real company...
keep your linux OS and apps up to date? Yea while that is great and all there are a ton of applications out there and it is pie in the sky to say you should always keep them up to date as if updating them will never actually create problems.
There is always a trade off between security and usability and you will have to strike a balance between the two if you care about keeping your job.
imho you should keep things reasonably up to date and that is updating applications maybe every 6 months and at least once a year, and even then you should roll out the updates slowly depending on the size of the company. Last thing you want is to have updated 100 users to some pos update that is breaking everything and then you will get to experience the joy of 100 people breathing down your neck, including a boss who is contemplating firing you.
I hope no one takes this article too seriously... - aflury, on 11/30/2008, -0/+8Yeah I got the feeling that the author just spent a month with Ubuntu on his desktop before writing this. Really even a junior Linux sysadmin should be able to do everything his/her job requires without using X. X ideally shouldn't even be installed on servers, let alone be running, but the author keeps referring to it. And I have no idea why "Logging in as root user" would be mentioned without at least a basic description of the sudo command (far more configurable for tracking/limiting root access vs. letting people su directly to root).
- tk0680, on 11/30/2008, -0/+7#4: Avoiding the command line
Anyone doing this with a Linux system is not an administrator. Sorry. - starfishsystems, on 11/30/2008, -0/+7It's definitely an article for beginning Linux sysadmins. Fair enough; we all pass through that stage. But the article consequently stumbles on some of its points, mostly by implying that professional system administration is just more of what you would do on your home PC.
No, the main characteristic of professional system administration, mentioned nowhere in the article, is that you are building systems to be managed scalably. In a professional setting, there is an ongoing need to set up new servers and workstations. Therefore, your main job is to maintain a factory for building systems. From the perspective of this essential responsibility, the ten points cited in the article become almost trivial.
There are a couple of points which reveal strange misunderstandings:
* "Booting a server to X Windows"
The correct use of X is that applications which run on some application server are made to display on your desktop. The application server does not need to run X, so naturally you don't run it there, because that would be stupid. End of story.
* "Logging in as root user"
The rationale presented for this point has something vaguely to do with X Windows. But that makes no sense. No, the reason you would login as an ordinary user and then su to root is for tracking purposes. At a site with several sysadmin staff, it can be very helpful to know who was running as root at a given time. If staff login directly as root, that information is never captured.
* "Not understanding permissions"
The author seems to have a dim understanding of permissions. Hint: ignore the author, read the man page. - aflury, on 11/30/2008, -0/+7More important than how often you update packages is knowing what changes exist in those updates and what parts of your infrastructure depend on those packages. If there are critical security flaws, do a quick test and update. If it's just a new version with lots of spiffy additional features, wait until you can do thorough testing and a widespread upgrade. There's also the issue of risk on a package-by-package basis. If you're installing a new version of vim or emacs, there's not much risk that it'll bring down your infrastructure, and you can always revert. If you're updating to the latest and greatest mysqld, you can ***** yourself over pretty fast.
- aflury, on 11/30/2008, -0/+7@stolemybike
The second command causes linux's firewall to drop all incoming packets.
The third shuts down the system and halts it, instead of rebooting (-h is halt, -r is reboot).
@wejmahtin
The old openfirmware stuff was great with serial console access. The only decent equivalents now are the ipmi/ilo add-on cards available with most servers. It was a lot more convenient with it built-in at the firmware level though. Serial console access doesn't get any love these days. :( - tvanwyk, on 11/30/2008, -0/+6The point is to log in as a normal user if at all possible, and if possible make your normal user account slightly more priveleged by adding it to groups with higher security clearances. Switch to root (su -) as needed. If I'm logging in to a server to do something that I know in advance requires root access, I still log in initially as a normal user and su to root. Force of habit, I guess. On the other hand, I usually SSH into my server boxes and I don't allow authentication as root over SSH (you can still su once the tunnel's up).
- Nicoon, on 11/30/2008, -3/+9Did even read the article? It did not say booting into X is bad for security, it said booting into X is a waste of memory and CPU cycles since you wouldn't have much use of it when it's acting as a server. There's really no need for having X running when you don't use it.
- grungegbunny, on 11/30/2008, -0/+6All your base are too much slow.
- weizbox, on 11/30/2008, -2/+8If I knew one of my Linux admins were doing any of these things, they would certainly be looked at for a demotion or possibly fired. As long as you have some sort of common sense, these things aren't an issue. Quite frankly I don't know how someone could get a Linux admin job if they made some of these mistakes... this is common sense stuff that most of the people I know learned before graduating high school.
It's simple: keep it safe/secure, keep backups, keep it clean/efficient and know what your doing before you do it. - daftman, on 11/30/2008, -2/+7> If your machine isn't powerful enough to run X and perform whatever else it has to do, then it shouldn't be a server in the first place.
X is insecure because you can remotely access an X session. A server should not have X. Booting into X is a big deal because it is a waste of memory, cpu cycles and if you are doing it remotely, bandwidth, especially when you have a heavy load web server or a database server.
Everything can be done in the CLI. - inactive, on 11/30/2008, -1/+6No, gonna leave it there so we all remember you...
- wejmahtin, on 11/30/2008, -0/+5potentially sends you on a trip to the datacenter.
that's what i hate about all this x86 hardware. in the old days, you had a serial console to your machine and you could do *everything* from it, including panic the system, manipulate firmware, specify boot devices etc. there's still no good equivalent to openboot for x86 crap. - magamiako, on 11/30/2008, -0/+5steviesteveo:
If SSH/SSL was insecure that you can't send your root password over the network connection, you're in some serious *****.
That said, you can use public and private keypairs to login remotely, never using a password, and disabling any password from ever logging into the machine. It's a basic for linux security IMO. - steviesteveo, on 11/30/2008, -1/+6When I log into a server it's usually to admin the thing, so I log in as my user which I've set up as a registered sudoer so I don't ever need to risk sending my root password over a network connection, even if it is encrypted by SSH.
- steviesteveo, on 11/30/2008, -1/+6@iLemon:
This is a very clever move. Rijnzael is lucky to work in an organisation where the argument where "well, this is my company" / "you work for me" doesn't ever come out when someone wants to mess with a piece of company computing equipment.
In a small business especially, it's very common for enthusiastic directors to "help out" their IT staff (who might not be employed full time) by changing settings themselves, on the reasoning that they can because it's company hardware and they're the company.
As I think anyone on digg who ever does IT support for friends/family or as a job knows merely owning the computer doesn't mean you're qualified to actually do anything more than write emails on it. - craterburnsu, on 11/30/2008, -1/+6@Hamletlere
Uhh, I am pretty sure saying Linux Administrators directed the entire focus of the article to servers. Hobbyist who run it at home are not Linux Administrators. - steviesteveo, on 11/30/2008, -1/+6Blackbox: I think that goes beyond a "beginner's mistake" - how often are newbie administrators left to deal with this scenario.
A headless server can generally be left without X running - but if it can't then clearly you'd discover this and just change your runlevel settings.
I'm not sure what "better system engineering" would be - if I was running a megasite that had to deal with millions of visitors a day, it would be supported by vast servers with many gigabytes of RAM, but if each of them gives up 100MB just to run a copy of Xserver that no one is getting value from then that's potentially tens of thousands of visitors that have to be served by another machine which drives up running and hardware costs.
100MB is a big deal if you think of it as a number of visitors served, and therefore advertising revenue. It's not a bad idea to run a server as light weight as possible, no matter what scale you work on. - steviesteveo, on 11/30/2008, -0/+4That's a shame, because they are belong to us. We'd like fast bases, please.
- wejmahtin, on 11/30/2008, -0/+4Number 8 should mention umask
- Rijnzael, on 11/30/2008, -0/+4The people higher up on the totem pole in my organization don't have access to mess with things they aren't qualified to understand. ;)
- Nicoon, on 11/30/2008, -3/+7nice edit of your comment, by the way.
- Vegiemaster, on 11/30/2008, -0/+4Neckbeards are a system requirement.
I proudly support them. - spyd3rweb, on 11/30/2008, -0/+4Ideally root login should be disabled because it opens it up for unauthorized access (every machine has a 'root' account, not too hard to guess the username) you should login as a user then sudo bash -l, or something. This is also good if you have multiple people with root access as you can remove them without having to change the password.
- tvanwyk, on 11/30/2008, -1/+5There are some terribly retarded and incompetent *nix admins out there. There are on the other hand a lot of very good Windows admins. You're damn close to saying "All Linux admins are smart. All Windows admins are dumb."
- rittz, on 11/30/2008, -0/+4A few years back I was installing an ftp daemon on Debian and I had to delete its lib folder, so me being a Linux noob did rm -rf /lib instead of rm -rf lib/ then restarted the box hoping the files would come back. They don't. Cost me $50 bucks for the OS reinstall, and from that day on I never logged in as root.
- Serphyas, on 11/30/2008, -0/+4*Those are
- purduecory, on 11/30/2008, -0/+3Your link still goes to the blogs.techrepublic.com.com URL...
so he was right - inactive, on 11/30/2008, -0/+3Rijnzael doth protest too much. The article states that something he does as a matter of course is a stupid mistake and he feels an overwhelming need to justify it. One man's mistake is another's necessity. No one thinks less of you for running your server with your GUI showing. Calm down, relax, we all know you are an expert. Jeez.
- falcon707, on 11/30/2008, -1/+4@wejmahtin
Even though I have no clue what you just said... I Dugg you up because it sounded really cool. - steviesteveo, on 11/30/2008, -0/+3Exactly what it says on the tin. I'd quite like to see if they have a follow up article for slightly more advanced mistakes.
- iota, on 11/30/2008, -0/+3So many errors in this article, brain hurts... please, if you ever want to work as a sysadmin (may god have mercy on your soul), don't read this article.
- steviesteveo, on 11/30/2008, -0/+3Yes, that is indeed the linked article copied and pasted into a comment.
- padraic2112, on 11/30/2008, -1/+4Do not use a package manager if you install things from source. Do not use multiple repositories that aren't consistent (e.g., Dag and FreshRPMs).
If you use a package manager, ROLL YOUR OWN PACKAGE from source and use the package manager to install it. - irisblaze, on 11/30/2008, -2/+5Ubuntu being the most popular choice for Linux newcomers especially for desktop use, doesn't make it less powerful than any other distro as a server OS, or wikipedia wouldn't choose it... for example
- Surferess, on 11/30/2008, -1/+4#6: Not backing up critical configuration files. Also - for every computer. IMO
- CrushThemTorg, on 11/30/2008, -0/+3I've seen www.com, but not com.com.
-
Show 51 - 100 of 167 discussions
© Digg Inc. 2009
— Content created and posted by Digg users is