While at this point your goal is most likely to set up an Ubuntu Server installation for the purposes of practicing the concepts contained within this book, it's also important to understand how a typical server roll-out is performed. Every server must have a purpose, also known as its Role. This role could be that of a database server, web server, and so on. Basically, it's the value the server adds to your network or your organization. Sometimes, servers may be implemented solely for the purpose of testing experimental code. And this is important too—having a test environment is a very common (and worthwhile) practice.

Once you understand the role your server plays within your organization, you can plan for its importance. Is the system mission critical? How would it affect your organization if for some reason this server malfunctioned? Depending on the answer to this question, you may only need to set up a single server for this task, or you may wish to plan for redundancy such that the server doesn't become a central point of failure. An example of this may be a DNS server, which would affect your colleague's ability to resolve local host names and access required resources. It may make sense to add a second DNS server to take over in the event that the primary server becomes unavailable.

Another item to consider is how confidential the data residing on a server is going to be for your environment. This directly relates to the installation procedure we're about to perform, because you will be asked whether or not you'd like to utilize encryption. The encryption that Ubuntu Server offers during installation is known as encryption at rest, which refers to the data stored within the storage volumes on that server. If your server is destined to store confidential data (accounting information, credit card numbers, employee or client records, and so on), you may want to consider making use of this option. Encrypting your hard disks is a really good idea to prevent miscreants with local access from stealing data. As long as the miscreant doesn't have your encryption key, they cannot steal this confidential information. However, it's worth mentioning that anyone with physical access can easily destroy data (encrypted or not), so definitely keep your server room locked!

At this point in the book, I'm definitely not asking you to create a detailed flow chart or to maintain an IP roll-out spreadsheet, just to keep in mind some concepts that should always be part of the conversation when setting up a new server. It needs to have a reason to exist, it should be understood how critical and confidential the server's data will be, and the server should then be set up accordingly. Once you practice these concepts as well as the installation procedure, you can make up your own server roll-out plan to use within your organization going forward.

For starters, we'll need to get our hands on Ubuntu Server and then create bootable installation media in order to install it. How you do this largely depends on your hardware. Does your server have an optical drive? Is it able to boot from USB? Refer to the documentation for your server in order to find out. In most cases, it's a very good idea to create both a bootable CD and USB media of Ubuntu Server while you're at it. That way, regardless of how your server boots, you're most likely covered.

Unfortunately, the differing age of servers within a typical data center introduces some unpredictability when it comes to how to boot installation media. When I first started with servers, it was commonplace for all servers to contain a 3.5 inch floppy disk drive, and some of the better ones even contained a CD drive. Nowadays, servers typically contain neither and only ship with an optical drive if you ask for one nicely while placing your order. If a server does have an optical drive, it typically will go unused for an extended period of time and become faulty without anyone knowing until the next time someone goes to use it. Some servers boot from USB; others don't. In order to continue, check the documentation for your hardware and plan accordingly. Your server's capabilities will determine which kind of media you'll need to create.

Thankfully, we only need to download a single file in order to create our media, regardless of whether or not we plan on creating USB or CD media. To get started, navigate to http://www.ubuntu.com/ in your browser, which will bring you to the main site for Ubuntu. On the top right, there will be a download button, and if you hover your cursor over that, you'll see an option for the Server version. Alternatively, you can simply Google Ubuntu Server and it should be the first result, or close. Just make sure the URL in the search result has a domain of ubuntu.com before you click on it. The file that you download will be an ISO file, ending with a .iso file extension. This is an image file that we will later use to create bootable media.

When this book was written, Ubuntu Server 16.04 is the most recent version. Depending on when you're reading this, the next release, 16.10 (or newer) may also be available. So, on the Ubuntu website, you may have a choice between LTS and non-LTS. Ubuntu 16.04 is Long-Term Support (LTS) while 16.10 is not. What does this mean? Essentially, whether or not an Ubuntu release is an LTS release determines the length of time it will be supported with security updates. Non-LTS releases are supported with security updates for just nine months, while LTS releases are supported for five years. This makes LTS releases perfect for servers, since it's not typical for an administrator to upgrade the entire distribution frequently. Non-LTS releases can be very handy for testing code on a newer software stack, but that's the only reason I can think of to consider a non-LTS release on a server. When in doubt, stick with LTS.

If you're setting up a virtual machine, then the ISO file you download from the Ubuntu download site will be all you need. In that case, all you should need to do is create a VM, attach the ISO to the virtual optical drive, and boot it. From there, the installer should start, and you can proceed with the installation procedure contained within this chapter. Going over the process of booting an ISO image on a virtual machine differs from hypervisor to hypervisor, so going over the process on each would be beyond the scope of this book. Thankfully, the process is usually straight-forward and you can find the details within the documentation of your hypervisor or from performing a quick Google search.

As I mentioned before, I recommend creating both a bootable USB and bootable CD. This is due to the fact that you'll probably run into situations where you have a server that doesn't boot from USB, or perhaps your server doesn't have an optical drive and the USB key is your only option. In addition, the Ubuntu Server boot media also makes great recovery media if for some reason you need to rescue a server. To create a bootable CD, the process is typically just a matter of downloading the ISO file and then right-clicking on it. In the right-click menu, you should have an option to burn to disc or similar. This is true of Windows, as well as most graphical desktop environments of Linux when a disc burning application installed. If in doubt, Brasero is a good disc burning utility to download for Linux.

The exact procedure differs from system to system, mainly because there is a vast amount of software combinations at play here. For example, I've seen many Windows systems where the right-click option to burn a CD was removed by an installed CD/DVD burning application. In that case, you'd have to first open your CD/DVD burning application and find the option to create media from a downloaded ISO file. As much as I would love to outline the complete process here, no two Windows PCs typically ship with the same CD/DVD burning application. The best rule of thumb is to try right-clicking on the file to see if the option is there, and if not, refer to the documentation for your application. Keep in mind that a "Data Disc" is not what you want, so make sure to look for the option to create media from an ISO image or your disc will be useless.

Creating a bootable USB is a bit more involved but easier to outline in steps, since each platform has a generally agreed upon method of creating them. In Linux, we can use ddrescue, or simply dd, while in Windows we can use the Universal USB installer from http://www.pendrivelinux.com/. In later section in this chapter, I'll outline the procedure of creating a bootable USB in Windows, Linux, and Mac.

You might be wondering which version of Ubuntu Server (32-bit or 64-bit) you should download and install. After all, it does give you an option for both when you go to fetch the ISO image. So, which one should you go for? Nowadays, most (if not all) servers that are currently being sold are compatible with 64-bit operating systems. In fact, the majority of end-user PCs are also compatible with 64-bit operating systems. However, it's often the case that you may have older hardware lying around, so any existing servers you already have may or may not contain processors with 64-bit registers. Generally speaking, though, the 64-bit version is recommended, but the decision really comes down to whether or not you wish to run legacy 32-bit applications and what your hardware is able to support.

Is a legacy application causing you to consider going with a 32-bit installation? It's often the case that legacy applications remain in use for quite some time in the enterprise, but thankfully 32-bit applications will run just fine (most of the time) in a 64-bit Linux installation, providing that the libraries required for the application have 32-bit versions available in Ubuntu's software repositories. We'll discuss software repositories and installing applications in more detail in Chapter 5, Managing Software Packages.

Often, the decision between 32-bit and 64-bit may come down to the misconception that 32-bit operating systems are unable to utilize more than 4 GB of RAM. In the Microsoft world, it's common to install 32-bit Windows on computers with less than 4 GB of RAM, and 64-bit Windows on computers with 4 GB or more. This is due to 32-bit versions of Windows being unable to utilize an address space of more than 4 GB. What many aren't aware of, however, is that this limitation is exclusive to Windows. Many 32-bit Linux distributions can access much more than 4 GB of RAM, by way of utilizing a Physical Address Extension (PAE), which is compiled into the kernel of most Linux distributions nowadays. Since Ubuntu 16.04 is able to utilize PAE, it can access more than 4 GB of RAM. If you prefer to use a 32-bit operating system and are concerned whether or not Ubuntu will be able to utilize all of your memory, you can forget your worries. It can support up to 64 GB!

If you're in doubt, choose the 64-bit version of Ubuntu on any computer or server you wish to install it on, unless you have a very specific use-case which makes the decision for you. You should consider the 32-bit version only when you need to run legacy applications or wish to install the distribution on a legacy server. With this discussion out of the way, we can move on to actually getting some Ubuntu Server installations going. Go ahead and download the Ubuntu Server ISO image from the Ubuntu website and then follow along with the relevant section for creating a bootable flash drive with your OS.

In this section, I'll walk you through the procedure for creating a bootable flash drive for Ubuntu Server for those of you currently running Windows on your workstation:

This process will take about 5 minutes or so to complete, depending on the speed of your flash drive and your computer. Once it's finished, remove the flash drive from your PC and you should be good to go.

On Linux systems, we can use either ddrescue or dd to create our bootable media. In the case of ddrescue, you'll first need to install the package on your system. If your distribution is Debian-based, you should be able to install it with the following command:

# apt-get install gddrescue

If your distribution is not Debian-based, use your distribution's package manager to install gddrescue. If this package is not available to you in your chosen platform, you can always fall back to the dd command, which I will also give you in this section.

With the gddrescue package installed, we can move on. Make sure the flash drive is inserted into your PC. Next, we'll need to run the following command in order to determine the name the system has provided for our flash drive:

# fdisk -l

From the output, you should be able to deduce which of the listed drives refers to your flash drive. In my case, /dev/sdc is mine. I know this because the partition /dev/sdc1 is formatted as FAT32, and I don't have any other partition formatted this way:

Output from the fdisk -l command

If you are at all unsure which drive is which, you may consider executing the fdisk -l command before and after inserting your flash drive and comparing the results. For the remaining examples in this section, I will use /dev/sdc for the commands. However, please make sure that you change this to match however your flash drive is named. If you format the wrong drive, you'll lose data (or worse, end up with a PC that won't start the next time you turn it on). Pay careful attention here!

Now that we know the device name for our flash drive, we can begin creating our media. If you have ddrescue available to you, use the following command:

# ddrescue -d -D --force <path and file name of the ISO> /dev/<device name>

For example, in my case, the command is the following:

# ddrescue -d -D --force /home/user/downloads/ubuntu-16.04-server-amd64.iso /dev/sdc

With the example ddrescue command I provided, pay special attention to the fact that I did not identify a partition for the dd command. For example, I didn't use /dev/sdc1, I used simply /dev/sdc. This is important—the flash drive will not be bootable if you targeted a specific partition. After all, the ISO image is an image of an entire disk, not just a single partition.

As for the options I chose, I'm choosing direct disk access for input and output (the -d and -D flags), forcing our device to be overwritten (the --force flag), and using the full path and file name of our downloaded ISO and directing the output to /dev/sdc. Once you start the process, it shouldn't take very long to complete. When it's finished, you're ready to begin using it to install Ubuntu Server:

ddrescue in the process of creating a bootable flash drive

For those of you without ddrescue available, you can use dd instead:

# dd if=/home/user/downloads/ubuntu-16.04-server-amd64.iso of=/dev/sdc bs=1M; sync

Similar to the ddrescue command, in the example for dd I'm using the path and filename of the Ubuntu Server ISO image as the input file (if=) and directing the output file (of=) to be that of my flash drive (/dev/sdc) and a block size of 1 MB (bs=1M). Unlike ddrescue, we won't see any fancy output with dd, but the process should work just fine. Once finished, we'll be ready to plan our partition layout and get our installation started.

The process for creating bootable USB media with Mac OS X is very similar to that of Linux, but there's a little preparation to do first. After you download the ISO, as mentioned earlier, we will need to convert the ISO file to the IMG format and then write the media.

First, let's convert the downloaded ISO image.

Open a terminal and then execute the following command:

hdiutil convert -format UDRW -o <path_to_save_IMG_file> <path_to_ISO_image>

In my case, the command is as follows:

hdiutil convert -format UDRW -o /Users/jay/ubuntu_server.img
/Users/jay/Downloads/ubuntu-16.04-server-amd64.iso

All you should need to do is change the paths accordingly. First, we're choosing the path we want the created IMG file to be saved to, followed by the path to the Ubuntu ISO. The following screenshot shows an example run of this process:

Converting the Ubuntu Server ISO to IMG format

With the conversion out of the way, we can run the following command to show information regarding the disks which are currently attached to the system. We need to do this so we know the device name OS X has given our USB drive, since we'll be referring to it later:

diskutil list

In the example screenshot, you can see what the process looks like on the system I was using. In my case, I know my USB media is /dev/disk2, as it's the only thing attached to the Mac, which is roughly 8 GB in size. In your case, double-check the output of the diskutil list command and make a note of which entry is referring to your USB media. If in doubt, run the command before and after inserting your flash drive and compare the results:

Listing attached disks on a Mac system

Now that we know the device name of your USB media, we can continue with the final command and perform the actual creation of our Ubuntu Server media. But first, we should make sure that the flash drive is not mounted:

diskutil unmountDisk /dev/disk2

Be sure to change the device name to match the one you saw in the results of the diskutil list command you performed earlier.

The following command will create our actual media:

# sudo dd if=<path_to_IMG_file> of=<device_node_of_usb_media> bs=1m

For example, using the paths and device name on my system, the command would become the following:

# sudo dd if=/Users/jay/ubuntu_server.img.dmg of=/dev/rdisk2 bs=1m

The next screenshot shows an example run of this dd command:

Writing the Ubuntu Server IMG file to a USB flash drive

Now that we have our media, you can remove it from your Mac and continue on and get some installations going. Before we get into that, though, we should have a quick discussion regarding partitioning.

One of the many joys of utilizing Linux for server platforms is how flexible the partitioning is. Partitioning your disk allows you to segregate your storage in order to dedicate specific storage allocations to individual applications. For example, you can dedicate a partition for the files that are shared by your Apache web server so changes to other partitions won't affect it. You can even dedicate a partition for your network file shares—the possibilities are endless. The names you create for the directories where your partitions are mounted are arbitrary; it really doesn't matter what you call them. The flexible nature of storage on Linux systems allows you to be creative with your partitioning as well as your directory naming.

With custom partitioning, you're able to do some very clever things. For example, with the right configuration you're able to wipe and reload your distribution while preserving user data, logs, and more. This works because Ubuntu Server allows you to carve up your storage any way you want during installation. If you already have a partition with data on it, you can choose to leave it as is so you can carry it forward into a new install. You simply set the directory path where it's mounted the same, restore your configuration files, and your apps will continue working as if nothing happened.

One very common example of custom partitioning in the real world is separating the /home directory into its own partition. Since this is where users typically store their files, you can set up your server such that a reload of the distribution won't disturb user files. When they log in after a server refresh, all their files will be right where they left them. You could even place the files shared by your Apache web server onto their own partition and preserve those too. The possibilities are endless.

Another reason to utilize separate partitions may be to simply create boundaries or restrictions. If you have an application running on your server that is prone to filling up large amounts of storage, you can point that application to its own partition, limited by size. An example of where this might be useful is an application's log files. Log files are the bane of any administrator when it comes to storage. While helpful if you're trying to figure out why something crashed, logs can fill up a hard disk if you're not careful. In my experience, I've seen servers come to a screeching halt due to log files filling up all the available free space on a server where everything was on a single partition. The only boundary the application had was the entirety of the disk.

While there are certainly better ways of handling excessive logging (log rotating, disk quotas, and so on), a separate partition also would have helped. If the application's log directory was on its own partition, it would be able to fill up that partition, but not the entire drive. A full log partition will certainly cause issues, but it wouldn't have been able to affect the entire server. As an administrator, it's up to you to weigh the pros and the cons and develop a partitioning scheme that will best serve the needs of your organization.

Running an efficient server is a matter of efficiently managing resources, users, and security—and a good partitioning scheme is certainly part of that. Sometimes it's just a matter of making things easier on yourself so that you have less work to do should you need to reload your operating system. For the sake of following along with this book, it really doesn't matter how you install or partition Ubuntu Server. The trick is simply to get it installed—you can always practice partitioning later. After all, part of learning is setting up a platform, figuring out how to break it in epic ways and then fixing it up.

When we perform our installation in the next section, you'll have an opportunity to partition your system any way you'd like. However, you don't have to—having everything in one partition is fine too, depending on your needs.

Now, regardless of your platform, we should be ready to get an installation or two of Ubuntu Server going. In the steps that follow, I'll walk you through the process.

At this point, your server will reboot and then Ubuntu Server should start right up. Although the installation process contained quite a few steps, it's really quick once you get used to it. To make things easier, later on in this book I'll go over the process of creating images you can use to deploy Ubuntu Server, so you'll be able to create your own pre-configured environments to simplify the process greatly.

The Raspberry Pi has become quite a valuable asset in the industry. These tiny computers, now with four cores and 1 GB of RAM, are extremely useful in running one-off tasks and even offering a great place to test code without disrupting existing infrastructure. In my lab, I have three Pis on my network, each one responsible for performing specific tasks or functions. It's a very useful platform.

Thankfully, Ubuntu Server is quite easy to install on a Raspberry Pi. In fact, it's installed in much the same way as Raspbian, which is the distribution most commonly used on the Pi. Ubuntu Server is available for Raspberry Pi models 2 and 3. All you'll need to do is download the SD card image and then copy it directly to your SD card. Once you've done that, you can boot the Pi and log in. The default username and password is ubuntu for both.

To install Ubuntu on the Pi, perform the following steps:

Depending on the speed of your card reader, this process will likely take at least 5 minutes to complete, if not longer. Once you're finished and you start up your Pi, you're likely to notice an issue straight away. If we execute:

df -h

We'll see that regardless of the size of our SD card, we'll have quite a bit of space that is not being utilized. This is because the SD card image will be the size of the SD card it was captured from, which will most likely not equal the size of yours. This will result in wasted space. What we'll need to do is resize the installation to match our SD card.

First, from the Pi after it's started up, enter fdisk by executing the following command:

# fdisk /dev/mmcblk0

Next, we'll need to delete the second partition, by pressing d + 2.

With the partition deleted (and while still within the fdisk console), we'll recreate the partition we deleted by pressing n + p + 2 and Enter (twice) +w.

With those commands executed, execute the reboot command to restart the Pi. However, we have one more command to execute. Once it starts backup, we can do the actual resizing with:

# resize2fs /dev/mmcblk0p2

After the resize procedure, you should be all set and able to utilize all the space of your SD card. You should also be able to use your Pi as a means of following along with the activities of this book. One last thing, though. If you execute this, you'll notice that your Pi doesn't have a swap partition:

free -m

This is normal, and while you can create a swap file to fill the role of a swap partition, I recommend you don't. SD cards are much too slow for swap, so you'd be better off without it. Since the Raspberry Pi 2 and Pi 3 only have about 1 GB of RAM, make sure whatever processes you plan on running fit within that restraint and you should be fine.

In this chapter, we covered the installation process in great detail. As with most Linux distributions, Ubuntu Server is scalable and able to be installed on a variety of server types. Physical servers, virtual machines, and even the Raspberry Pi have a version of Ubuntu Server available. The process of installation was covered step by step, and you should now have an Ubuntu Server of your own to configure as you wish. Also in this chapter, we covered partitioning, creating boot media, determining the role of your server, as well as some best practices.

In the next chapter, I'll show you how to manage users. You'll be able to create them, delete them, change them, and even manage password expiration and more. I'll also cover permissions so that you can determine what your users are allowed to do on your server. See you there!