Mastering Ubuntu Server

Master the art of deploying, configuring, managing, and troubleshooting Ubuntu Server 18.04, 2nd Edition

Jay LaCroix

• Publisher: Packt Publishing
• Year: 2018
• ISBN:
  9781788997089
• Edition: 2
• Topic: Computer Science
• Subtopic: Operating Systems
• Index: Computer Science

Get up-to-date with the finer points of Ubuntu Server using this comprehensive guide

Key Features

• A practical easy-to-understand book that will teach you how to deploy, maintain and troubleshoot Ubuntu Server
• Get well-versed with newly-added features in Ubuntu 18.04.
• Learn to manage cutting-edge technologies such as virtualization, containers, Nextcloud and more

Book Description

Ubuntu Server has taken the data centers by storm. Whether you're deploying Ubuntu for a large-scale project or for a small office, it is a stable, customizable, and powerful Linux distribution that leads the way with innovative and cutting-edge features. For both simple and complex server deployments, Ubuntu's flexible nature can be easily adapted to meet to the needs of your organization. With this book as your guide, you will learn all about Ubuntu Server, from initial deployment to creating production-ready resources for your network. The book begins with the concept of user management, group management, and filesystem permissions. Continuing into managing storage volumes, you will learn how to format storage devices, utilize logical volume management, and monitor disk usage. Later, you will learn how to virtualize hosts and applications, which will cover setting up KVM/QEMU, as well as containerization with both Docker and LXD. As the book continues, you will learn how to automate configuration with Ansible, as well as take a look at writing scripts. Lastly, you will explore best practices and troubleshooting techniques when working with Ubuntu Server that are applicable to real-world scenarios.

By the end of the book, you will be an expert Ubuntu Server administrator who is well-versed in its advanced concepts.

What you will learn

• Manage users, groups, and permissions
• Encrypt and decrypt disks with Linux Unified Key Setup (LUKS)
• Set up SSH for remote access, and connect it to other nodes
• Add, remove, and search for packages
• Use NFS and Samba to share directories with other users
• Get to know techniques for managing Apache and MariaDB
• Explore best practices and troubleshooting techniques
• Get familiar with scripting
• Automate server deployments with Ansible

Who this book is for

This book is intended for readers with intermediate or advanced-beginner skills with Linux, who would like to learn all about setting up servers with Ubuntu Server. This book assumes that the reader knows the basics of Linux, such as editing configuration files and running basic commands.

Managing Storage Volumes

When it comes to storage on our servers, it seems as though we can never get enough. While hard disks are growing in capacity every year, and high capacity disks are cheaper than ever, our servers gobble up available space quickly. As administrators of servers, we always do our best to order servers with ample storage, but business needs evolve over time, and no matter how well we plan, a successful business will always need more. While managing your servers, you'll likely find yourself adding additional storage at some point. But managing storage is more than just adding new disks every time your current one gets full. Planning ahead is also important, and technologies such as Logical Volume Manager (LVM) will make your job much easier as long as you start using it as early as you possibly can.

In this chapter, I'll walk you through the concepts you'll need to know in order to manage storage and volumes on your server. This discussion will include:

• Understanding the Linux filesystem
• Using symbolic and hard links
• Viewing disk usage
• Adding additional storage volumes
• Mounting and unmounting volumes
• Partitioning and formatting volumes
• Understanding the /etc/fstab file
• Managing swap
• Utilizing LVM volumes
• Understanding RAID

Understanding the Linux filesystem

Before we get into the subject of managing storage volumes, we'll first need to have a better understanding of how the filesystem is laid out. The term filesystem itself can be somewhat confusing in the Linux world because it can refer to two different things, the default directory structure, as well as the actual filesystem we choose when formatting a volume (ext4, XFS, and so on). In this section, we're going to take a quick look at the default directory structure.

In Linux (Ubuntu uses the Linux kernel and related utilities) the filesystem begins with a single forward slash, /. This is considered the beginning of the filesystem, and directories and sub-directories branch out from there. For example, consider the /home directory. This directory exists at the root level of the filesystem, which you can see from the fact that it begins with a forward slash. My home directory on my system is /home/jay, which means that it's the directory jay, which is inside the directory home, and that directory is at the beginning of the filesystem. This is confusing at first, but becomes very logical once you become accustomed to it. To really bring this home, use the ls command against several directories on your server. If you execute ls / you will see all of the directories at the root of the filesystem. You'll see the directory home among the results, among many others.

This default directory structure is part of the Filesystem Hierarchy Standard (FHS), which is a set of guidelines that defines how the directory structure is laid out. This specification defines the names of the directories, where they are located, and what they are for. Distributions will sometimes go against some of the definitions here, but for the most part, follow it fairly closely. This is why you may see a very similar (if not the same) directory structure on distributions of Linux other than Ubuntu.

So why is this important relative to managing storage volumes? When you add a volume to your server (which can be a physical disk in the case of a physical server, or a virtual disk when it comes to virtual machines) you format that volume, and then mount (attach) the volume to a directory on the filesystem. The directory you attach the volume to can have any name and be located anywhere you wish. The FHS defines specific directories for this purpose, but whether or not you follow that is up to you. You could certainly mount an additional drive to a directory called kittens located at the root of the filesystem, there's nothing stopping you. The question is, should you? That's what the FHS was defined to address.

A full walkthrough of the FHS is beyond the scope of this book, but I have included a link to this specification at the end of the chapter should you decide to read more about it. There are some directories you definitely should know, however. Here are some of the more important ones.

Directory	Purpose
/	The beginning of the filesystem, all directories are underneath this
/home	User home directories
/root	The home directory for root (root doesn't have a directory underneath /home)
/media	For removable media, such as flash drives
/mnt	For volumes that are intended to stay mounted for a while
/opt	Additional software packages (some programs are installed here, not as common)
/bin	Essential user binaries (ls, cp, and so on)
/proc	Virtual filesystem for OS-level components
/usr/bin	A majority of user commands
/usr/lib	Libraries
/usr/lib	Libraries
/var/log	Log files

Don't worry if some of this doesn't make sense right now, it will come with time. The main point here is that there are many directories, each having their own purpose. If you want to know the purpose of a particular directory, consult the FHS. If you're curious where you should place something on a server, also consult the FHS. When we get to the section of mounting volumes later on in this chapter, we'll use the filesystem directly.

Using symbolic and hard links

With Linux, we can link files to other files, which gives us quite a bit of flexibility with how we can manage our data. Symbolic and hard links are very similar, but to explain them, you'll first need to understand the concept of inodes.

An inode is a data object that contains metadata regarding files within your filesystem. Although a full walkthrough of the concept of inodes are beyond the scope of this book, think of an inode as a type of database object, containing metadata for the actual items you're storing on your disk. Information stored in inodes are details such as the owner of the file, permissions, last modified date, and type (whether it is a directory or a file). But as a refresher, an inode is a data object that contains metadata regarding files within your filesystem. Inodes are represented by an integer number, which you can view with the -i option of the ls command. On my system, I created two files: file1 and file2. These files are inodes 4456458 and 4456459 respectively. You can see this output in the following screenshot where I run the ls -i command. This information will come in handy shortly:

Output of ls -i

There are two types of links in Linux: symbolic links and hard links. This concept is similar in purpose to shortcuts created in graphical user interfaces. Almost all graphical operating systems have a means of creating a shortcut icon that points to another file or application. I'm sure you've seen shortcut icons to applications on Windows or macOS systems. Even Linux has this same functionality in most desktop environments that are available. On a Linux server, you typically don't have a graphical environment, but you can still link files to one another using symbolic or hard links. And while links approach the concept of shortcuts differently, they pretty much serve the same purpose. Basically, a link allows us to reference a file somewhere else on our filesystem.

For a practical example, let's create a hard link. In my case, I have a couple of files in a test directory, so I can create a link to any of them. To create a link, we'll use the ln command:

ln file1 file3 

Here, I'm creating a hard link (file3) that is linked to file1. To play around with this, go ahead and create a link to a file on your system. If we use ls again with the -i option, we'll see something interesting:

Output of ls -i

If you look closely at the output, both file1 and file3 have the same inode number. Essentially, a hard link is a duplicate directory entry, where both entries point to the same data. In this case, we created a hard link that points to another file. With this hard link created, we can move file3 into another location on the filesystem and it will still be a link to file1. Hard links have a couple of limitations, however. First, you cannot create a hard link to a directory, only a file. Second, this link cannot be moved to a different filesystem. That makes sense, considering each filesystem has its own inodes. Inode 4456458 on my system would of course not point to the same file on another system, if this inode number even exists at all.

To overcome these limitations, we can consider using a symbolic link instead. A symbolic link (also known as soft links or symlinks) is an entry that points to another directory or file. This is different to a hard link, because a hard link is a duplicate entry that references an inode, while a symbolic link references a specific path. Symbolic links can not only be moved around between filesystems (as these do not share the same inode number as the original file), we can also create a symbolic link to a directory as well. To illustrate how a symbolic link works, let's create one. In my case, I'll delete file3 and recreate it as a symbolic link. We'll again use the ln command:

rm file3
ln -s file1 file3 

With the -s option of ln, I'm creating a symbolic link. First, I deleted the original hard link with the rm command (which doesn't disturb the original) and then created a symbolic link, also named file3. If we use ls -i again, we'll see that file3 does not have the same inode number as file1:

Output of ls -i after creating a symbolic link

That's not the only thing that's different in the output, though. Notice that the inode numbers of each file are all different. At this point, the main difference from a hard link should become apparent. A symbolic link is not a clone of the original file; it's simply a pointer to the original file's path. Any commands you execute against file3 are actually being run against the target that the link is pointing to.

In practice, symbolic links are incredibly useful when it comes to server administration. However, it's important not to go crazy and create a great number of symbolic links all over the filesystem. This certainly won't be a problem for you if you are the only administrator on the server, but if you resign and someone takes your place, it will be a headache for them to figure out all of your symbolic links and map where they lead to. You can certainly create documentation for your symbolic links, but then you'd have to keep track of them and constantly update documentation. My recommendation is to only create symbolic links when there are no other options, or if doing so benefits your organization and streamlines your file layout.

Getting back to the subject of symbolic links versus hard links, you're probably wondering which one you should use and when to use it. The main benefit of a hard link is that you can move either file (the link or the original) to anywhere on the same filesystem and the link will not break. This is not true of symbolic links; however, if you move the original file, the symbolic link will be pointing to a file that no longer exists at that location. Hard links are basically duplicate entries pointing to the same object, and thus have the same inode number, so both will have the same file size and content. A symbolic link is merely a pointer-nothing more, nothing less.

However, even though I just spoke about the several benefits of hard links, I actually recommend symbolic links for most use cases. They can cross filesystems, can be linked to directories, and are easier to determine from the output where they lead. If you move hard links around, you may forget wh...