Book Image

Mastering Ubuntu Server - Fourth Edition

By : Jay LaCroix
4.7 (7)
Book Image

Mastering Ubuntu Server - Fourth Edition

4.7 (7)
By: Jay LaCroix

Overview of this book

Ubuntu Server is taking the server world by storm - and for a good reason! The server-focused spin of Ubuntu is a stable, flexible, and powerful enterprise-class distribution of Linux with a focus on running servers both small and large. Mastering Ubuntu Server is a book that will teach you everything you need to know in order to manage real Ubuntu-based servers in actual production deployments. This book will take you from initial installation to deploying production-ready solutions to empower your small office network, or even a full data center. You'll see examples of running an Ubuntu Server in the cloud, be walked through set up popular applications (such as Nextcloud), host your own websites, and deploy network resources such as DHCP, DNS, and others. You’ll also see how to containerize applications via LXD to maximize efficiency and learn how to build Kubernetes clusters. This new fourth edition updates the popular book to cover Ubuntu 22.04 LTS, which takes advantage of the latest in Linux-based technologies. By the end of this Ubuntu book, you will have gained all the knowledge you need in order to work on real-life Ubuntu Server deployments and become an expert Ubuntu Server administrator who is well versed in its feature set.
Table of Contents (26 chapters)
24
Other Books You May Enjoy
25
Index

Understanding when to use root

In the last chapter, we set up our very own Ubuntu Server installation. During the installation process, we were instructed to create a user account to act as a system administrator. So, at this point, we should have at least two users on our server. We have the aforementioned administrative user, as well as root. We can certainly create additional user accounts with varying levels of access (and we will do so in this chapter), but before we get to that, some discussion is in order regarding the administrator account you created, as well as the root user that was created for you.

The root user account exists on all Linux distributions and is the most powerful user account on the planet. The root user account can be used to do anything within your server, and I do mean anything. Want to create files and directories virtually anywhere on the filesystem? Want to install software? These processes are easily performed with root. The root account can even be used to destroy your entire installation with one typo or ill-conceived command: if you instruct root to delete all the files on your entire hard disk, it won’t hesitate to do so. It’s always assumed on a Linux system that if you are using root, you are doing so because you know what you are doing. So, there’s often not so much as a confirmation prompt while executing any command as root. It will simply do as instructed, for better or worse.

It’s for this reason that every Linux distribution I’ve ever used has stated, or at least highly recommended, that you create a standard user during the installation process. It’s generally recommended in the Linux community for an administrator to have their own account and then switch to root whenever a task comes up that requires root privileges to complete. This approach is less likely to destroy your server with an accidental typo or bad command. Some administrators will strictly use root at all times without any issue, but again, it’s recommended to use root only when you have to.

Most distributions ask you to create a root password during installation in order to protect that account. Even Debian (on which Ubuntu is based) has you set a root password during installation. Ubuntu just decides to do things a little bit differently. The reason for this is that, unlike many other distributions, Ubuntu defaults to locking out the root account altogether. There’s nothing stopping you from enabling root, or switching to the root user after you log in. Being disabled by default just means the root account isn’t as easily accessible as it normally would be. I’ll cover how to enable this account later in this chapter, should you feel the need to do so.

An exception to this rule is that some VPS providers, such as Linode, will enable the root account even on their Ubuntu servers. Sometimes, the root password will be randomly generated and emailed to you. However, you should still create a user for yourself with administrative access regardless.

Instead of using root outright, Ubuntu (as well as its server version) recommends the use of sudo. Specifically, sudo enables you to run individual commands with elevated privileges instead of being logged in as root all the time.

Using sudo to run privileged commands

I’ll go over how to manage sudo later on in this chapter, but for now, just keep in mind that the purpose of sudo is to enable you to use your user account to do things that normally only root would be able to do. For example, as a normal user, you cannot issue a command such as the following to install a software package (don’t worry about the apt command for now, as we’ll cover that in Chapter 3, Managing Software Packages):

apt install tmux

Instead, you’ll receive an error:

E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root?

But if you prefix the command with sudo (assuming your user account has access to it), the command will work just fine:

sudo apt install tmux

When you use sudo, you’ll be asked for your user’s password for confirmation, and then the command will execute. Subsequent commands prefixed with sudo may not prompt for your password, as it will cache your password for a short period of time until it times out or the terminal is closed. Understanding this should clarify the usefulness of the user account you created during installation. I referred to this user as an administrative account earlier, but it’s really just a user account that is able to utilize sudo. Ubuntu Server automatically gives the first user account you create during installation access to sudo.

The intent is that you’ll use that account to administer the system, rather than root. When you create additional user accounts, they will not have access to sudo by default, unless you explicitly grant it to them.