Let's take a quick look at this from a more practical standpoint. As we have already said, an SOE is a concept, not an absolute. It is, at its simplest level, a common server image or build standard that is deployed across a large number of servers throughout a company. Here, all required tasks are completed in a known, documented manner.

To start with, there is the base operating system—and, as we have discussed, there are hundreds of Linux distributions to choose from. Some are quite similar from a system administration perspective (for example, Debian and Ubuntu), whilst some are markedly different (for example, Fedora and Manjaro). By way of a simple example, let's say you wanted to install the Apache Web Server on Ubuntu 18.04 LTS—you would enter the following commands:

# sudo apt-get update
# sudo apt-get install apache2

Now, if you wanted to do the same thing but on CentOS 7, you would enter the following:

# sudo yum install httpd

As you can see, there is nothing in common between these commands—not even the name of the package, even though the end result in both cases is an installation of Apache. On a small scale, this is not an issue, but when servers are numerous and as server count goes up, so does the complexity of managing such an environment. 

The base operating system is just the start. Our example above was installing Apache, yet we could also install nginx or even lighttpd. They are, after all, also web servers.

Then, there is configuration. Do you want users to be able to log in as root over SSH? Do you need a certain level of logging for audit or debug purposes? Do you need local or centralized authentication? The list is myriad, and as you can see, if left unchecked could grow into a massive headache.

This is where the SOE comes in. It is effectively a specification, and at a high level, it might say the following:

• Our standard base operating system is Ubuntu 18.04 LTS.
• Our standard web server will be Apache 2.4.
• SSH logins are enabled, but only for users with SSH keys and not root.
• All user logins must be logged and archived for audit purposes.
• Except for a few local break glass accounts, all accounts must be centrally managed (for example, by LDAP or Active Directory).
• Our corporate monitoring solution must be integrated (for example, the Nagios NCPA agent must be installed and configured to communicate with our Nagios server).
• All system logs must be sent to the corporate central log management system.
• Security hardening must be applied to the system.

The preceding is simply an example, and it is by no means complete; however, it should begin to give you an idea of what an SOE looks like at a high level. As we proceed through this chapter, we will delve deeper into this subject and give more examples to build up a clear definition.