The Accidental Administrator: Linux Server Step-by-Step Configuration Guide never actually intended to be a book. Author Don R. Crawley started it off as a handout that would supplement other learning materials in the Linux workshops he taught. Eventually, the handout turned into a large workbook that evolved into the published piece out there today.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
The book aims to be a straightforward, essential learning guide on the basics of Linux administration, without an overzealous attention to inane details that the average admin would never utilize. Chapter topics include an introduction to the Linux platform and its administration, and eventually dive deeper into essential Linux management tasks including networking, security, integration and working with important commands such as cron and grep.
You can sample Chapter Four: File and Directory Management. We also spoke with Crawley on some of the more important Linux configuration and management topics in his book.
Your book is called The Accidental Administrator. Since the book itself was an accident of sorts, could you explain how it turned into a book?
When I originally thought of converting seminar workbooks into conventional books, I thought it would be a fairly simple process. I quickly learned with the Cisco ASA book (the first book in the Accidental Administrator series) that it was not so simple. The student exercises in a classroom involve interaction with other students. When I conduct training, I use a dedicated server in a private network to provide network services to the student computers including DNS, DHCP, file and Web services. With a conventional book, the reader is probably working alone and without a dedicated, specially built server. The exercises, therefore, have to be re-written with that in mind. Additionally, the formatting of a book is completely different from a workbook. Oh, and you have to have a great cover. People DO judge books by their covers!
There are two chapters that discuss Linux integration. Why is it an important topic for Linux admins?
Scott McNeally, the former Sun Microsystems CEO, said, “The network is the computer.” Today, we’re all interconnected to varying degrees. As IT pros, we often deal with a diversity of systems including Linux, Microsoft, Unix, Apple, mobile systems and mainframes. Our users don’t care about the systems, but they do care deeply about being able to easily access their data. The book deals with integrating ‘nix systems using NFS and ‘nix/Windows systems with Samba. Obviously, there are other options for integrating disparate systems and exchanging data between them. The main thing is to ensure that the users can easily access the necessary data to do their jobs, regardless of the platform.
For this book, you focus on the most widely used shell, Bash. What are some of the functions or commands that you have discovered over the years that are most useful in this interface?
Aside from scripting in general, some of the more helpful commands that are used by experienced ‘nix admins include: aliasing commands, searching for text strings with grep, using “less” to display the contents of text files (which displays the contents one page at a time and allows scrolling up and down through the file), using “find” to locate files (a great example of using “find” is on page 114 in the book, where we used “find” to start the process of understanding the Red Hat “service” command), and “awk,” a filtering tool that is extremely powerful (on page 168, the book has an example of using “awk” to find user accounts with no password).
Can you name a few Linux administrative tools and techniques that you think stand out from Chapter 2, “Linux Administration”?
That’s kind of a tough question, because Chapter 2 is really about the basics of Linux administration. Most of the tools and techniques, therefore, are not particularly remarkable, but just very important, basic tools. I suppose, when working with Red Hat-based systems such as CentOS, RHEL, or Fedora, the “service” and “system” families of tools make things a lot easier than configuring, starting, monitoring and stopping daemons manually. Understanding where user and system profiles are located is also very helpful.
“Whereis” is a pretty helpful utility for finding executables and configuration files. Knowing how to use a text editor is paramount to effective ‘nix system management. I chose to include "vim" because of its ubiquity. “grep” is also one of those very basic ‘nix tools that makes you seem smarter when you use it. Understanding how to properly shut down your system can prevent data corruption, so I included a section on that. Even though Google is very helpful in providing answers, the man and info pages are still the most reliable source of configuration and management information, so I included a fairly lengthy student exercise on how to use them. Archiving, compressing, extracting and decompressing are very common procedures, so I included a lab on the various tools used to perform those tasks. None of the tools in Chapter 2 really stand out, but they’re all incredibly important to learn, especially for Linux newcomers.
The ext4 file system has been out for over two years now and is growing steadily in the enterprise. You mention that ext3 is still the default in some distros, but would you make the case for more adoption of ext4 given that it’s had some time to sink in? What are some advantages or disadvantages file management-wise of ext4 over its predecessor?
From a management standpoint, ext4 offers several benefits including support for larger partition sizes and a greater number of subdirectories. Ext4 can scale to 16TB and operates faster than its predecessor. Ext4 also uses journal checksumming to validate disk areas, a process which, according to some tests, produces a fairly significant improvement in filesystem operations.
In terms of disadvantages, I’ve read about a problem related to possible data loss with ext4 in the event of a system crash or power loss, especially in kernel versions prior to 2.6.30. Although there is no such thing as a perfect file system, the problem appears to be less pronounced in ext3 than ext4. Still, RHEL 6 uses ext4 by default. That suggests that Red Hat doesn’t see serious issues with ext4, and they do see significant performance improvements in it. I like what Paul Ferrill said in his article about ext4: “If you need the support for large files (> 2TB), filesystem (> 16 TB) or numbers of sub directories (ext3 is limited to 32000), you'll definitely want to upgrade. For new installations, it probably makes sense to go with ext4. Existing production systems that aren't in any danger of exceeding any of the size limits might want to hold off.” He’s right. If it ain’t broke, don’t fix it.
What do Linux admins need to know about setting permissions for files and directories and what type of information does this book provide on the subject?
The book covers the basics of setting permissions for files and directories, including how to set read, write, and execute permissions using both alphabetic permissions and numeric permissions. You asked what Linux admins need to know about setting permissions for files and directories: I think the most important thing any admin, Linux or otherwise, needs to understand is the concept of least privilege. You grant a user access to a system, directory, or file only to the level required and never beyond.
The problem with Linux file and directory permissions is that they trace their roots back to the 1970s. As such, they’re inadequate for many of today’s more advanced or sophisticated needs. For example, you’re limited to setting permissions for one user, one group and the world. In a more advanced edition of the book, I would cover access-control lists, which provide much greater granularity in setting permissions than tradition ‘nix file and directory permissions. I felt that ACLs, however, were beyond the scope of this book.
You detail Webmin, which simplifies everyday administration tasks for Linux admins, including fixing account lockout and other tasks that could get mundane. In your experience, though, what has Webmin been most useful with in simplifying Linux management?
There are two aspects of using Webmin: one is for non-technical administrators and the other is for technical administrators. You mentioned fixing account lockout and resetting passwords, tasks that, in my opinion, should be handled by non-technical administrators such as HR staff. For non-technical staff, Webmin is a godsend that eliminates the need for them to work in the arcane and intimidating command-line interface. The fact that it can be configured to display only certain modules based on logon name, its searching capability, combined with its point-and-click ease of use, makes it ideal for non-technical admins.
For technical administrators, it presents a different benefit. Like all GUIs, I find Webmin most helpful when I’m performing tasks that I don’t usually do. If I need to do something new, I’ll often start by performing that particular task in a GUI on a test system. That gives me a known working config. I can then dissect the configuration file(s) to better understand the configuration(s). From that point, I often choose to start doing things in the CLI. Increasingly, as GUIs have gotten more reliable and versatile, it’s just a matter of personal preference as to whether you use the GUI or the CLI. If you’re coming from a Windows or Mac background, you may find it a lot easier to use a GUI than to type commands, especially for simpler configuration tasks. I believe in choosing whichever tools work best for you. By the same token, I’m also a huge believer in spending the time and effort to learn the intricacies of my most important systems. That means getting under the hood in the command line.
In Chapter 16, you mention that “security starts with physical security.” Do you find that a lot of Linux admins are so caught up in hardening Linux networks that they tend to overlook the importance of physical security threats to Linux? What are the best methods you have found in protecting Linux’s physical environment?
I wouldn’t describe Linux (or any other) admins as overlooking the importance of physical threats to their systems. I just think we’re all human, subject to human frailty, and we all can use reminders about things from time-to-time. (Ask my wife how many times I need to be reminded about things that seem obvious!) All system security starts with physical security. I recently heard a news story about discarded hard drives being sold from dumps in Ghana for their data. That reminded me to be sure to run DBAN on some drives I’m de-commissioning -- something I would normally do anyway, but it’s great to have a reminder. Linux systems can be booted into run Level 1 which automatically grants root access to anyone with physical access. Windows systems can be booted with a Linux boot CD and the admin password changed. Cisco routers and firewalls can be power-cycled and their configuration register changed to permit unauthorized logons. Certainly, there are myriad ways to protect systems even in the face of physical access, but there are also myriad ways of cracking such systems. Best practice is to limit physical access by securing systems in a secure data center, locking equipment racks, or, at the very least, a locked server closet. Oh, and keeping equipment in a server closet does no good if you leave the door open and unlocked, something I’ve seen occasionally on site visits.