Being a Red Hat Enterprise Linux administrator is a lot more fun than being in charge of Microsoft Windows, according...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
to Mark Sobell, author of the new Prentice Hall PTR book, A Practical Guide to Red Hat Linux (Second Edition): Fedora Core and Red Hat Enterprise Linux. On the eve of LinuxWorld and the release of this book, Sobell answered our questions about some of the trickiest issues that Red Hat Linux administrators face. In the first part of the interview, he explained why it's easier to work with RHEL than Windows and offered tips on user administration and under-used tools. Look for the second tip -- on beating Trojan horses and doing great backups -- in this series next week, while LinuxWorld is in full swing. The third and final episode -- on avoiding common admin mistakes -- will appear the week after LinuxWorld.
What makes being an administrator for RHEL easier or more fun than working with Windows?
Sobell:There are under half a dozen known viruses for Linux, and none in the wild. There are several new ones per week for Windows. Working in a safer environment means you can dedicate more time to taking care of your user's needs and less time to protecting them from viruses and cleaning up the messes that come with an attack.
Most Windows configuration is done via a GUI, which can be painful on low-bandwidth links. It is possible to administer a Linux system remotely via ssh, which can comfortably be done in the park with a GPRS phone and PDA.
How can a Red Hat Linux admin reduce the chances that a user will use administrator/Superuser commands by mistake?
Sobell:The easiest way to prevent users from running Superuser commands is by not telling users the root password. It is that simple. You can use sudo selectively to give users Superuser privileges for a limited amount of time on a per-user and per-command basis.
In addition, because a root-owned setuid program allows someone who does not know the root password to have the powers of Superuser, you should limit the number of root-owned setuid programs on the system. Your site should have as few of these programs as necessary. You can disable setuid programs at the filesystem level by mounting a filesystem with the nosuid option.
Why should admins perform tasks using the least privilege possible?
Sobell: You should always run with the least privilege possible because you are human and humans make mistakes. Because you are more likely to make a mistake when you are rushing, this concept becomes more impor¬tant when you have less time to apply it. Performing a task with excess privilege will frequently cause more damage than running it with minimal privilege if…
- You provide the wrong input data,
- The program you are running contains an error, or
- The program you are running is compromised and used to attack the system.
When you are working on the computer, especially when you are working as the system adminis¬trator, perform any task by using the least privilege possible. When you can perform a task logged in as an ordinary user, do so. When you must be logged in as Superuser, do as much as you can as an ordinary user, use su so that you have root privileges, do as much of the task that has to be done as Superuser, and revert to being an ordinary user as soon as you can.
What handy user administration tools/utilities available in Red Hat Linux are underused, and why should admins use them more often?
Sobell: Here's a short list:
- sudo An admin rarely needs to do more than a few things in a row as Superuser, and it is a lot safer to explicitly run these with sudo than to leave yourself logged in as Superuser.
- chroot It is a good idea to set up a minimal chroot jail and then use it for testing programs acquired from the Internet where they cannot do much damage.
- vi(m) Using the graphical configuration tools can sometimes be faster than editing configuration files, but when things go wrong the graphical tools are rarely of any help. A text editor, such as vi or vim (or emacs for that matter) can help you find and fix problems with servers and environment settings.
- CVS Linux configuration files are mostly text files; they are well suited to storage in a CVS repository. Having a cron job that checks /etc into a CVS repository periodically, and checking it in manually before you make any big changes, can be a lifesaver when you realize that you have broken something, but cannot remember what you changed.
In my new book, A Practical Guide to Red Hat Linux, Second Edition, I discuss many tools you can use, including the Red Hat-specific system-config-* (Fedora Core 2) and redhat-config-* (Red Hat Enterprise Linux) graphical system admin tools.