Unexpected administrator Linux management integration security

"Unexpected Administrator: Step by Step to Teach You to Configure Linux Server" was not originally written as a book. Author Don R. Crawley wrote a handout as a supplement to the Linux workshop he taught. In the end, the handout developed into a thick workbook and was eventually published in the form it sees now.

This book omits the hollow details that are rarely used by ordinary administrators. The goal is to become a simple and necessary Linux management basics. Chapter topics include an introduction to the Linux platform and its system management, followed by an in-depth explanation of the necessary Linux management tasks, including networking, security, integration, and learning to use some important commands, such as cron and grep.

You can try Chapter 4: File and Directory Management. In the book, Crawley also discussed some of the more important Linux configuration and management topics. In this article, Crawley will answer the questions raised by the website editor about the contents of this book.

Your book is called "Unexpected Administrator." Since the book itself is an unexpected product, can you explain how it turned into a book?

When I first wanted to turn a workbook for a seminar into a regular book, I thought it would be a fairly simple process. I quickly learned about Cisco's ASA (the first book in the "Unexpected Administrators" series) and found it to be not that simple. In the classroom, the student's practice assignments involve interaction with other students. During the hands-on training, I built a dedicated server on the private network to provide network services for students' computers, including DNS, DHCP, files and Web services. Readers of regular books may be read by one person alone, and there is no dedicated server. Therefore, these exercises must be rewritten in consideration of this point. In addition, the format of a book is completely different from the workbook. Of course, you must also have an attractive cover. People always judge books based on the cover!

There are two chapters in the book discussing Linux integration. Why is this an important topic for Linux administrators?

Scoot McNeally, former CEO of Sun Microsystems, once said: "The network is a computer." Today, each of us is connected to each other to varying degrees. As an IT professional, we often deal with a wide variety of systems, including Linux, Microsoft, Unix, Apple, mobile systems, and mainframe systems. Our users don't care which system they use, they are deeply concerned with the ability to easily access their data. This book deals with the integration between NFS's 'nix and Samba's 'nix/Windows systems. Of course, there are certainly other ways to integrate different systems and exchange data between them. The main thing is to ensure that users have easy access to the necessary data for their work, regardless of platform.

For this book, you focus on the most widely used command-line interpretation tool, Bash. In this interface, what are the most useful features or commands you've discovered over the years?

In addition to general scripts, more experienced commands commonly used by 'nix administrators include: using aliases for commands, searching for text strings with the "grep" command, and displaying the contents of text files with "less" ( Displaying a page at a time and flipping pages up and down, using the "find" positioning file, and the "awk" command, is a powerful filtering tool (you can use "awk" to find an account with no password set).

Can you name some of the outstanding Linux management tools and techniques described in Chapter 2, "Linux Management"?

This is a very difficult question to answer, because the second chapter is actually just a basic introduction to Linux management. Therefore, most of the tools and techniques mentioned in this chapter are not so outstanding, but they are very basic and important. I think that when using a Red Hat-based system, such as CentOs, RHEL, or Fedora, using the tools under the "service" and "system" columns is much easier than manually configuring, starting, monitoring, and stopping the daemon. It is also helpful to know where users and system profiles are saved.

"whereis" is a utility for finding executables and configuration files. Knowing how to use a text editor is very important for effective management of the 'nix system. I chose to introduce "vim" in the book because it is widely used. "grep" is also one of the basic 'nix tools, and it can make you work more efficiently. Knowing how to properly shut down the system can prevent data corruption, so I also wrote a section on this. While Google is a powerful tool for finding answers, the man and info pages are still the most reliable source of configuration and management information, so I joined a fairly long student exercise to practice how to use them. Archiving, compressing, extracting, and decompressing are common operations, so I introduced a series of tools that can do these tasks. The tools presented in Chapter 2 are not outstanding, but they are all very important and worth learning, especially for Linux novices.

The Ext4 file system has been around for more than two years, and its usage in the corporate world is steadily rising. You mentioned that ext3 is still the default file system in some distributions. Do you mean that ext4 will be used more and more widely, but it will take time to change people's inertia? Compared with the predecessor, what advantages and disadvantages does ext4 have in document management?

From a management perspective, ext4 has several advantages, including support for larger hard disk partitions and more subdirectories. Ext4 can support up to 16TB and is faster than its predecessor. Ext4 also uses log checking to verify the disk area. According to some tests, this method can bring considerable improvement to the operation of the file system.

In terms of shortcomings, I already know a problem. In the case of a system crash or sudden power outage, the ext4 file system may experience data loss, especially before the kernel version before 2.6.30. Although there is no perfect file system in the world, this problem is not as significant in the ext3 file system as in ext4. However, RHEL 6 still uses ext4 by default. This shows that Red Hat does not think that ext4 has serious problems, instead they see a significant improvement in performance of ext4. I like what Paul Ferrill said in an article about ext4: "If you need to support very large files (>2TB), very large filesystems (>16TB) or massive subdirectories (ext3 subdirectories are limited to 32000) ), then you will definitely want to upgrade ext3 to ext4. For new system installations, it makes sense to use ext4. As for some existing product systems, there is no danger of exceeding the limitations of the original file system in the short term. And thus may continue to use the original file system." He is right. If you don't break it, you won't stand.

What do Linux administrators need to know about setting permissions for files and directories? What information does this book provide?

The book covers the basics of setting file and directory permissions, including how to set readable, writable, and executable permissions for files and directories in alphanumeric and alphanumeric ways. You ask me what permissions Linux administrators need to know about setting up files and directories: I think for any administrator, whether Linux or another system, the most important thing is to understand the concept of least privilege. For a system, directory, or even a file, you only set the minimum level of permissions required for the user, and never exceed this permission.

The problem with file and directory permissions for Linux systems is that this permission setting is used in the 1970s and therefore does not work for today's advanced or complex needs. For example, you can only set permissions for one user, one group of users, and all other users. In future versions of this book, I will introduce an access-control list that allows you to set up permissions that are much more detailed than traditional ‘nix files and directory permissions. However, I once thought that access control lists (ACLs) are beyond the scope of this book.

You detailed Webmin, which simplifies the day-to-day management of Linux administrators. These day-to-day management tasks include account lockout and other tedious tasks. So, in your experience, where is the biggest use of Webmin in simplifying Linux management?

The use of Webmin can be viewed in two ways: first, non-technical administrators use Webmin, and second, technical administrators use Webmin. You mentioned unlocking accounts and resetting passwords. Come, such tasks should be handled by non-technical administrators such as employees in the human resources department. For non-technical administrators, Webmin is a godsend tool that avoids dealing with mysterious and daunting command lines. Webmin can be configured to display specific modules based on the logged-in account. It has powerful search capabilities and is easy to use, with just dragging and clicking the mouse, making it ideal for non-technical administrators.

For technology-born administrators, the benefits of Webmin are different. Like all GUIs, I found that Webmin's greatest use is when I need to do things that I rarely use. If I need to do something new, I usually use the GUI to do it on the test system. Once the operation is complete, the GUI will generate an available configuration. Then I can interpret these configuration files to better understand the configuration process. From this point you can see that the most common one I use is the command line (CLI). The GUI is now more reliable and flexible, and whether using the GUI or the CLI is purely a matter of personal preference. If you have a background with Windows or Mac, you might find it easier to use the GUI than to type the command, especially for simple configuration tasks. I believe that the most suitable tool is the best tool. For the same reason, I also think it is worthwhile to spend time and energy studying the complex operations of my most important systems. This means I need help from the command line.

In Chapter 16, you mentioned that "system security comes first and foremost in physical security." Have you discovered that many Linux administrators are overly focused on hardening the network so that they ignore the physical security threats of Linux systems? What do you think is the best way to protect the physical environment of Linux?

I won't say that Linux (or other system) administrators ignore the physical threats of the system. I just think that we are all human beings, people have weaknesses (can't be all-inclusive), but we can always use the "alarm clock" to remind ourselves. (You can ask my wife how many times I need to be reminded of the obvious things!) All system security begins with physical security. I recently heard a news story about the sale of discarded hard drives in Ghana, where the (purchasers) only get the data. This reminds me that I must run DBAN on the hard drive that is about to be scrapped - usually I will remember to do so, but it is better to have a reminder. As long as you have physical access to the system disk, anyone can boot Linux with Run Level 1 and automatically gain root privileges. The Windows system can be started with a Linux boot CD and the password for the administrator account will be modified. Cisco routers and firewalls can be powered-cycled and configuration registers are modified to allow unauthorized logins. Of course, even if we are physically exposed, there are still countless ways to protect the system, but there are also countless ways to crack our protection. The best way to do this is to place the system in a secure data center to limit physical contact, lock the equipment rack, or at least lock the server in the closet. Oh, if you don't open the door, it's useless to put the server in the closet, which I often see.

Author: Ryan Arsenault, Pat Ouellette translator: Dan