Using Ubuntu Server 18.04 LTS
This article discusses topics related to configuring, managing and maintaining Ubuntu Server 18.04 LTS Bionic Beaver, a long-term release of the popular Debian-based Linux operating system with continued support until April, 2028. Although it can be used and configured countless other ways, the rest of the articles in this wiki assume it is configured per this article.
Packages
Update packages
Ubuntu uses a package (aka software) management feature that makes it easy to both install new packages and maintain installed packages. The aptitude and apt-get commands are used to update the server's database of available packages and their most recent versions, add new packages, and remove packages. For example, entering aptitude update with root privileges performs the update of the server's package database and aptitude upgrade will install all available updates. The update will usually take a minute or two to complete, and it is generally a good idea to upgrade available updates. This can conveniently be done with one simple entry using &&.
username@servername:~$ sudo aptitude update && sudo aptitude upgrade
Ubuntu will ask if available updates should be installed. Note the (Y/n) options stated permit pressing Enter with no entry to select the default Y response, or type yes, to confirm upgrading. Or, type n or no to prevent installing upgrades. All upper-case letters in command line questions will be the default action when pressing enter (e.g., (y/N) pressing enter selects no).
Ubuntu will automatically query daily for available updates and display them in the login message when logging in through SSH.
Fresh installs
There are nearly always important security updates available to a freshly installed OS, so running update and upgrade should generally be the first thing done after initializing a new server.
The aptitude package is no longer installed by default, but is available through the main repository. While the apt-get command (and newer apt command) can perform largely the same functions, there are still some elements of aptitude that make it a little easier to use, plus admins accustomed to using it may not see any benefit to learning the different options for apt-get.
For these reasons plus remaining consistent with the various articles already created in this wiki, install the aptitude package:
username@servername:~$ sudo apt-get install aptitude username@servername:~$ sudo aptitude update && sudo aptitude upgrade
Rebooting after upgrade
Some upgrades will require a reboot of the server. To determine this, after running an upgrade, check whether or not the file /run/reboot-required exists.
username@servername:~$ ll /run/reboot-required
If there is no reboot-required file, then no reboot is required for the upgrade Ubuntu just performed. However, sometimes services require restarting that were not restarted after a package was upgraded. This can cause issues with web related services, so be sure to verify that all web services are running correctly after an upgrade by visiting web pages that use all of the web services installed and make sure they load and behave as expected.
Upgrades may inform users that files to be installed are different from the current installation, and will then offer a number of options. Usually, the default will be to keep the installed file. However, in many cases this may not be optimal. Use the option to view the differences in files. The most common differences will be the new default portions of the new file and user customizations of the old file. Frequently the best way to handle this is to note the differences in the file, then select the option to install the new file and add the customizations to the new file after the upgrade has completed. Conveniently, the upgrade process should save the previous file in the same directory as the old file with the format filename.dpkg-old.
Package management
Ubuntu Server 18.04 LTS, launched in April of 2018, will be maintained by Canonical Ltd. until April of 2028, so admins running the software can feel confident that the core of Ubuntu will be secure for a reasonably long period without having to upgrade the distribution. However, many third-party software packages will never be updated within the 18.04 main repository.
It is important for admins to pay attention to the software versions being installed as security holes will get plugged in future releases of software, leaving the unmaintained versions as vulnerable vectors of attack to the servers running them. The reason a patched vulnerability is of greater concern is that it represents a public announcement that any server running old versions will have this vulnerability, so the maintainers of the world's underground webcrawlers will promptly add the vulnerability as an additional item to scan for.
Here are four popular ways to manage software packages: the official 18.04 repositories, back-ports, personal package archives, and git.
Official repositories
The 18.04 repositories should generally be looked at with a skeptical eye, as most of the packages have not been updated since the release of 18.04. The most popular packages are updated, such as PHP, OpenSSL, OpenSSH, etc, but other packages, such as nginx, phpMyAdmin, git, ImageMagick, and a litany of others remain stuck in time. Check the Ubuntu Package Search page to search for the package to be installed and compare the version listed in the repository with the latest stable version at the software developer's project page, though note that some developers may choose to host their project pages with third parties such as sourceforge or GitHub.
Using the official repositories is the easiest of all methods to install and maintain a package. Entering the aptitude (or apt-get) and install commands, followed by the package name, will install the package based on the most recent update of the repositories. Everything from the 18.04 repositories is available by default with this command.
username@servername:~$ sudo aptitude install packagename
Upgrading packages installed this way will be done via the normal update and upgrade commands.
Backports
Backports are a way to install a package that is in a newer Ubuntu release than the current release. The issue with backports is that the software may be configured in ways that are not compatible with the release being used (18.04, in this case). It is usually best to use backports only when the developer recommends it.
To install a backport version of a package, use the following command:
username@servername:~$ sudo aptitude install packagename/bionic-backports
Since backports use the official repository, the available packages are updated and upgrades are installed through the update and upgrade commands. Occasionally, a developer may update the original version of a package to a newer version than the backport, in which case Ubuntu will install this newer version.
Personal package archives
A personal package archive (PPA) is a tool for installing and maintaining packages not reviewed by the Ubuntu team but still using largely the same, convenient method for installing and upgrading as the official repositories use. PPAs are maintained through launchpad. There is an inherent security risk in using PPAs and they should be reviewed before being used. If the PPA is regularly updated, supports a large number of Ubuntu releases, has been around for a number of years and googling it does not reveal that anyone has had issues specifically related to the package, then there is a good chance that the package is a good one and is safe to use.
PPAs are not included as part of the default repositories, so each one will have to be added so that Ubuntu will check for packages in the PPA that are applicable to the release. While this can be done by editing text files, the add-apt-repository command, from the software-properties-common package, is commonly used to add packages to sources.list. It is generally a good idea to install add-apt-repository as part of setting up a server as inevitably at least one PPA will be used, and, indeed, several are used in the UNPM server configuration. Fortunately, the Ubuntu 18.04 build used by most ISPs already includes the add-apt-repository package.
Installing a PPA is done by getting the PPA's repository name, which is stated on the launchpad page for the PPA in the form of ppa:<repository name>. Adding the PPA adds a new source for updates to be pulled from, but the update command will need to be used for anything in the PPA to be installed.
Installing a PPA:
username@servername:~$ sudo add-apt-repository ppa:<repository name> username@servername:~$ sudo aptitude update username@servername:~$ sudo aptitude install packagename
Packages installed via PPA will be maintained through the aptitude update and aptitude upgrade commands.
Note that if the PPA offers a newer version of a package installed from some other source, such as the official Ubuntu repositories, then Ubuntu will upgrade to the newer version provided by the PPA, and vice-verse.
git
Git is a tool used widely by developers for version management. To understand git a little better, it may be worthwhile to read the Wikipedia git article. Although git is not a tool unique to Ubuntu, or Linux for that matter, it is important for admins to understand the basics of installing and maintaining software using git before using it to install a package. Note that since git is intended to be a tool for developers, it is not generally advised to use it for package installation and management unless no other option is offered by the developer of the package.
For the latest version of git, it is best to use a PPA:
username@servername:~$ sudo add-apt-repository ppa:git-core/ppa username@servername:~$ sudo aptitude update && sudo aptitude install git
/var/run/
Ubuntu 18.04 does not use the /var/run/ directory. Instead, it uses the /run/ directory, with a symlink from /var/run/ to /run/. This is useful to know as many sites may discuss entries in /var/run/ and new users may not realize this directory is no longer used. Similarly, many configuration files have not been updated and may still point to /var/run/, yet will still run properly because of the symlink.
Additional useful packages
Some additional, minor, yet convenient packages.
unzip & zip
Installing the unzip package creates the unzip command, which can extract .zip compressed files, and vice-versa for zip.
username@servername:~$ sudo aptitude install unzip zip
To decompress a .zip file to the current directory, use the unzip command followed by the file location. As with everything in Linux, sufficient privileges will be required.
username@servername:~$ unzip /path/to/filename.zip
The unzip command has several options for renaming and relocating decompressed data, instructions for which can be found in its man page, but most useful is the -d option.
username@servername:~$ unzip -d /target/decompress/directory/ /path/to/filename.zip
whois
Installing the whois package creates the whois command to conveniently and quickly retrieve a domain's whois record.
username@servername:~$ sudo aptitude install whois
To view the records in full, it is useful to run whois with the |less option (space bar or PageUp/PageDown to navigate and q to quit) and the -H option to remove legal disclaimers that some registrars display on all lookups.
username@servername:~$ whois -H example.com |less
The whois command can also be used on IP addresses.
New TLDs
It takes some time for whois to get updates for new TLDs, but there is a way to update the lookup data used by editing whois.conf. See the sample whois.conf file that is easily available via download by using the following command and then doing some small changes:
username@servername:~$ sudo wget -P /etc/ https://www.unpm.org/whois.conf username@servername:~$ sudo nano /etc/whois.conf
Use Ctrl+w to find the lines starting with \.com and \.net then add # (note the space after # is required) at the beginning of these lines to comment them out. This will force whois to use the default servers when performing commands on those lines, which allows for retrieving full record data from GoDaddy registered domains.
lynx
Lynx is a text-based HTML browser than can be used from the command line with the lynx command. It can be conveniently used to quickly verify a page is loading, but note that it has no javascript or image capabilities.
username@servername:~$ sudo aptitude install lynx
To browse a website:
username@servername:~$ lynx example.com
To exit, simply press q.
Session display name
Some admins may find they have many servers with the same prefix. For example, mail.example.com and mail.example2.com. Ubuntu will only include everything before . (but not the .), so in the example, .example.com and .example2.com will be removed at the command prompt and both sessions will be titled username@mail:~. This will also be communicated to SSH clients such as PuTTY. Making a change in the ~/.bashrc will change the display name in clients, making it easier to tell which session is which server with multiple sessions open.
username@servername:~$ nano .bashrc
Change:
# PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
Create a new line just below it, and add:
PS1='\[\e]0;\u@mail.example.com: \w\a\]${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '
From the above example, mail.example.com may be any text desired. To accomplish the same thing for the root user, perform the same edit to /root/.bashrc. Note the space between com: \: this is intentional so as to place a space between the command prompt and the cursor.
UFW
UFW, which stands for "Uncomplicated Firewall," is a service that makes it much easier to manage iptables. However, this service tends to generate a lot of noise in various logs even though it also logs to /var/logs/ufw.log. To prevent ufw from logging to other logs, make the following change:
username@servername:~$ sudo nano /etc/rsyslog.d/20-ufw.conf
Uncomment the last line:
& stop
username@servername:~$ sudo service rsyslog restart
Logging
The rsyslog service manages logging to /var/log/syslog, which can get really noisy, and elsewhere. Logging too much information to /var/log/syslog can make it difficult to diagnose problems. To reduce noise, some logs can be kept elsewhere:
username@servername:~$ sudo nano /etc/rsyslog.d/50-default.conf
Change:
cron.* /var/log/cron.log
*.*;auth,authpriv,cron.none -/var/log/syslog
username@servername:~$ sudo service rsyslog restart
There are additional options to change or add based on what kind of noise is observed in /var/log/syslog.
Fix resolv.conf symlink
The following message will appear in the syslog due to an incorrect symlink:
systemd-resolved[705]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
To fix this issue, replace the resolv.conf symlink with the correct one:
username@servername:~$ sudo rm /etc/resolv.conf username@servername:~$ sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
Reduce size of systemd journal
The systemd journal by default can grow to gigabytes in size. The maximum size can be reduced either by defining a maximum size or maximum time to store the journal.
This configuration reduces the maximum time to store a journal to two months:
useraname@servername:~$ sudo nano /etc/systemd/journald.conf
Change:
MaxRetentionSec=2months
Reload the configuration:
username@servername:~$ sudo systemctl restart systemd-journald
Next step
Now that Ubuntu is configured, it's time to install nginx.