Comment goes here
You should log in and post some comments! The link is up there in the toolbar. Go nuts!
 

System Administration - An Overview

« Back to Basics Articles

All the hoopla

As mentioned before, some people want you to believe that administering a Linux system is like arranging a peace settlement in the Middle East or understanding a Jackson Pollock painting. Some years ago when Linux was really a hobbyist's system it was considered difficult. Now Linux has gone mainstream and there's nothing taxing about running a Linux system. You do not have to be a computer "guru" to use it. Anybody can be a Linux "administrator".

Years back, if you had the title 'system administrator' it was comparable to the role of the arch-angel Michael. (Michael comes from the Hebrew words meaning He who is like God). That usually meant your own parking space at the company and a seat at the executive dining room. There are some system administrators for large corporations that run mainframes who enjoy these privileges (and rightly so). However, if you've successfully installed the Linux operating system then you too can now proudly wear the badge of 'system administrator'. It doesn't matter if you're setting up one computer running Linux or a bunch of computers in your small business or a computer room in your local community center or school, you've now signed on to become the 'big cheese'.


The role of root

Using the 'root' account is like being God on a Linux system. (Hence, my earlier reference to the archangel Michael). That means that you want to be extremely careful when working as root. With something as simple as a wrong keystroke you could do a great deal of damage. Before you actually sit down and work as root for the first time, I would recommend going into the file known as .bashrc (if you're using the bash shell, which is the most popular one) and adding a few aliases in there. An alias is nothing but an entry in that file that says that a certain command that you type can perform additional actions above and beyond its default behavior. For example, if I type:
rm unwanted.doc
 in a terminal, unwanted.doc is going to byte heaven (or hell).
rm
is for removing or deleting files. There is no undelete that is practical and easy when you're using a shell, so If you didn't want to delete that, you're pretty much out of luck. But if I add an entry in my .bashrc file like this one:
alias rm='rm -i'
 it makes sure that I get asked before the file actually gets deleted. You may want to do the same with other potentially dangerous commands.

alias cp='cp -iv'
 makes the copy command interactive (i) and verbose (v) so it will both ask you and then tell you what you did.

alias mv='mv -i'
 also makes the move command (used for moving and renaming files) interactive.

There are people who say that adding these to root's .bashrc is something that 'wussies' do. I always ask them: If a sailor tied a cable on to himself/herself before he/she went out on deck in thirty foot seas to fix something, would that be considered a 'wussie' move? Making a mistake is comparable to encountering a rogue wave on a calm sea. There really isn't anything comparable to being in rough seas sitting in front of your computer, but just as dangerous rogue waves have been known to appear on calm, sunny days and sink boats, silly mistakes have ruined projects. Better to keep a buffer zone between you and your mistakes.


Delegating authority

Back to the nautical motif for a moment; just as one ship generally doesn't have two captains, it is rare that a small organization would have two systems administrators. There's usually not too much benefit in delegating authority in this setting. People are prone to making mistakes. Even a seasoned systems administrator has sometimes deleted files that he/she shouldn't have or messes up the configuration of something. If two heads think better than one, then four hands also might make more mistakes than two.


The use of sudo as an alternative

If you're the head systems administrator (or the only one) you can "deputize" your co-workers by installing and configuring the program sudo. In Unix/Linux speak, the term 'su' means superuser - that is, root. Only root has true administration rights and privileges, so this program allows others to "do" su, hence the name, sudo. Ok, Sheriff, time to fight the bad guys. Let's see what your deputies can do.

su can also stand for switch user. For example, if you had two accounts on a machine - let's say bob and harry - you could log on as 'bob' and do: su harry and then work as harry.

Your distribution should have this very popular program among its packages. If it doesn't, you can go to:http://www.courtesan.com/sudo and get Todd Miller's great application. After you've installed it, you have to create what's called a sudoers file. You do this by typing:
visudo
 as root. This is essentially a special version of the text editor vi just for creating and editing the sudoers file.

Basic Vi commands
  • ESC+i = insert text
  • ESC+wq = save and quit
  • ESC+u = undo


Here is an example sudoers file I have for my home network. It is not really as complicated as most are, but it gives a good basic idea of what you need to do to let other users help you out with some administration tasks.
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the sudoers man page for the details on how to write a sudoers file.
#

# Host alias specification

# User alias specification

User_Alias TRUSTED = mike, maria

# Cmnd alias specification

Cmnd_Alias INTERNET = /usr/sbin/traceroute, /usr/sbin/ntpdate
Cmnd_Alias KILL = /bin/kill, /usr/bin/killall
Cmnd_Alias TOOLS = /bin/mount, /bin/umount

# User privilege specification
root    ALL=(ALL) ALL
TRUSTED ALL=INTERNET, KILL, TOOLS
Let's break this down. First of all, we add the line
User_Alias TRUSTED = mike, maria
 That means that the users mike and maria become the "trusted" users. And what are they trusted with? Jump down to the last line for a second. They are trusted with commands in the group INTERNET, KILL and TOOLS. What are those commands? Jump back up to the section
#Cmnd alias
specification
 These trusted users can use ntpdate, for example, to keep the computer's time correct. More information on that command later. (One of your duties as system administrator will be to make sure your machines keep accurate time and display the correct date. ntp is probably the best package to use to do this.)

I've created a KILL group (sounds like Mafia hit men!) so other users can kill runaway process that can only be shut off by root normally. Some server process may have a problem and you might have to shut down that process. Starting it again is something that's not included here however. It might be best for these deputized users call the "real" system administrator and if that's you, for example, you may want to check out the configuration files for certain servers before you start them again. You may have to mount floppies or other partitions to get data from them, and that's where the TOOLS section comes in handy.
When the user executes a command that's authorized in the sudoers file, he/she first needs to type
sudo
 and the command. For example, if you wanted to update the machines clock to the exact time, you would type:
sudo ntpdate atimeserver.nearyou.gov/edu
Then you need to type your user password. If you make a mistake, sudo will hurl insults at you (no kidding). Todd Miller has a good sense of humor and the results of botching a keystroke are sometimes hilarious!

You can add more commands and users to your own sudoers file. Whatever you think is prudent in your situation. There is some possibility for abuse. Use your best judgment.


Taking care when working as root

As I mentioned, there's a chance of doing some damage when you work as root. There are other ways to protect yourself besides putting aliases in your .bashrc file. One of them is using the program su.

su lets you work as root when you're logged in as another user. Good practice dictates that you disallow root logins from remote machines, so if you're performing administration tasks remotely, su is irreplaceable. The remote machine lets you log in as user fred, for example, and then you just type:
su
 and type the root password. For all intents and purposes you've got a root terminal open now. That means that you can do anything - just as if you had logged in as root in the first place. You're really running the same risks by working as root, but you've at least eliminated the risk of logging in as root. That's quite important from a security standpoint. The real advantage to using su is the possibility to carry out individual commands. Let's say you've downloaded an application and it's only available as source code in a tarball. You can download the source code to your user directory and as a user you can run the configure and make scripts provided with most tarballs. That way, you minimize the risks of compiling the software. If you're satisfied with the binary file (the application itself), then you can use 'su' to install the application and its accompanying documentation in the usual application and documentation directories. Here's what you'd do:
su -c "./make install"
 You need to add the -c (command) switch and put the actual command in quotes. Then type the root password.

As you see, you can run any command that root can. That, of course, means that you need to know the root password, so this is something that only the system administrator should do. It's not a good idea to be giving your password to other users so they can run commands. They can do that with sudo, as we mentioned earlier.
You can also use su to do things as other users. You're not just restricted to doing things as root. This might come in handy if you've got two accounts on a machine. Instead of having to log in as the other user, you could, for example, read a file that you've restricted permissions for. Let's say you've got a file called my_ideas and you've removed read permissions to it for your group and for others. Instead of logging in, you can type:
su fdavis -c "less /home/fdavis/my_ideas"
 and you will now be asked for fdavis' password. Now you can access files from your other user account without having to log in. Other users may also give you their passwords to access things in their account. I question the wisdom of doing that, but in an emergency it's an option. A co-worker who's ill may give you his/her password to access important files. That's acceptable in that kind of situation it seems, but the ill worker should promptly change his/her password as soon as he/she's back at work.

As you can see, if used correctly, su is a great tool for getting administration tasks done safely. It's also useful as a time and trouble saver. Just make sure you don't abuse it.

Article Details

  • Author: Linux.org Admin
  • Publish Date: 05/03/2012
  • Last Updated: 05/04/2012
  • Categories: Basics

    • Intermediate Level Course