What Actually Changed in Ubuntu 18.04 LTS
Ubuntu 18.04 LTS arrived in April 2018 carrying significant changes to core system components. If you are administering servers running Ubuntu 16.04 and need to plan an upgrade, understanding these changes helps you avoid surprises during and after the migration.
Some modifications affect daily configuration tasks. Others only matter in specific scenarios such as cloud deployments or custom automation. This guide focuses on the changes that most commonly impact server administrators and developers moving to Ubuntu 18.04.
Netplan: A New Way to Configure Networking
The most disruptive change in Ubuntu 18.04 is the introduction of Netplan for network configuration. Previously, Ubuntu managed network interfaces through /etc/network/interfaces. Netplan instead uses YAML configuration files located in /etc/netplan/ and generates the appropriate configuration for either NetworkManager or systemd-networkd.
A typical Netplan configuration for a server using a static IP address looks like this:
network:
version: 2
renderer: networkd
ethernets:
eth0:
addresses:
- 192.168.1.100/24
gateway4: 192.168.1.1
nameservers:
addresses:
- 8.8.8.8
- 8.8.4.4
Write the configuration to /etc/netplan/01-netcfg.yaml and apply it with the following command:
sudo netplan apply
If you are connected to the server remotely, exercise caution. An incorrect configuration can terminate your connection immediately. Always ensure you have console access or an alternative way to connect before applying network changes.
To troubleshoot a failed connection, run netplan apply and check the systemd-networkd logs:
journalctl -u systemd-networkd
If the configuration is wrong, edit the YAML file and run netplan apply again. If you prefer a more familiar interface, you can install NetworkManager instead:
sudo apt install network-manager
sudo netplan apply
For servers running web applications behind a reverse proxy, understanding how network configuration interacts with services is important when configuring Nginx as a reverse proxy.
Snap Packages and the Snapd Daemon
Ubuntu 18.04 ships with snapd installed by default. Snaps are self-contained software packages that include their dependencies and update automatically in the background. Some packages are delivered exclusively as snaps, including the default Core images used for container workloads.
To list installed snaps:
snap list
To install a snap:
sudo snap install certbot
Snaps run in isolation from the rest of the system, which means they do not always see files in standard locations. For example, a snap-installed web server may not access /var/www by default. You need to connect appropriate interfaces to grant access:
sudo snap connections certbot
If you do not need snaps, you can remove the snapd daemon, though some Ubuntu features may depend on it:
sudo apt purge snapd
Python 3 as the Default and Python 2 Deprecation
Ubuntu 18.04 makes Python 3 the default Python installation. The python command no longer resolves to python2. Running python in the shell now gives you Python 3:
python --version
# Python 3.6.9
Python 2 is not installed by default. If you have scripts that require Python 2, you must install it explicitly:
sudo apt install python2
This change affects automation scripts, crontab entries, and any tooling that assumes python points to Python 2. Audit your scripts and update shebang lines where needed:
#!/usr/bin/env python3
Using python3 explicitly in shebangs is the safest approach going forward. If you are planning further upgrades beyond Ubuntu 18.04, it is worth reviewing how PHP and other runtime versions have also evolved, as documented in this PHP 8 upgrade guide that covers version migration patterns.
Systemd Service Management
Ubuntu 18.04 uses systemd as the init system, which was also the case in Ubuntu 16.04. However, certain service management commands and behaviours evolved between these releases. The systemctl command works largely the same way, but some service configurations changed.
If you are writing systemd unit files, note that the Type=oneshot behaviour changed slightly in how it interacts with remainAfterExit. Always test your service files with systemctl daemon-reload after editing them:
sudo systemctl daemon-reload
sudo systemctl restart your-service
The journalctl interface for reading logs matured further in Ubuntu 18.04. You can filter by time, service, and priority level:
journalctl -u nginx --since "1 hour ago"
journalctl -u mysql --since today --priority err
Database Change: MySQL Replaced by MariaDB
Ubuntu 18.04 ships MariaDB 10.1 in its repositories rather than MySQL. MariaDB is a community-driven fork of MySQL and is designed to be compatible with existing MySQL databases and queries. However, there are subtle differences in configuration defaults, storage engine availability, and performance characteristics.
If you need the official MySQL server from Oracle, add the MySQL APT repository before installing:
wget https://dev.mysql.com/get/mysql-apt-config_0.8.12-1_all.deb
sudo dpkg -i mysql-apt-config_0.8.12-1_all.deb
sudo apt update
sudo apt install mysql-server
The MySQL APT configuration tool lets you choose which version and components to install. For new projects, MariaDB is a solid choice and is the default in Ubuntu. For existing projects that require specific MySQL features or have been tested against a particular MySQL version, using the Oracle repository is the appropriate path.
If you are setting up database management tools on your server, installing phpMyAdmin on Ubuntu with proper security configuration can help you manage your database server through a web interface.
UFW Firewall Configuration
Ubuntu 18.04 continues to include UFW (Uncomplicated Firewall) as the default firewall configuration tool. The syntax is unchanged from Ubuntu 16.04, but the default ruleset now denies incoming traffic by default, which is the correct behaviour for a server.
sudo ufw status
sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https
sudo ufw enable
Before enabling UFW on a remote server, ensure you have allowed SSH access or you will lock yourself out. The ufw allow ssh command opens port 22, but if your SSH daemon runs on a different port, use that port number instead:
sudo ufw allow 2222/tcp
Cloud-Init and Automatic Networking on Cloud Instances
Ubuntu 18.04 AMIs on AWS and other cloud platforms use cloud-init to configure networking automatically on first boot. This can conflict with manual Netplan configurations if cloud-init has already applied network settings.
Cloud-init configuration lives in /etc/cloud/cloud.cfg and by default applies network settings that override manual configurations. To prevent this and gain full manual control, create a blacklist file:
sudo mkdir -p /etc/cloud/cloud.cfg.d
echo "network: {config: disabled}" | sudo tee /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
Only apply this on cloud instances where you want full manual control of networking. On managed cloud infrastructure, leaving cloud-init networking active is often the simpler approach.
Upgrading from Ubuntu 16.04
The recommended upgrade path from Ubuntu 16.04 to Ubuntu 18.04 goes through Ubuntu 18.04.4 as an intermediate point. Before starting the upgrade, update all packages on the current system:
sudo apt update
sudo apt upgrade
sudo apt dist-upgrade
sudo do-release-upgrade
Important: Back up your server before upgrading. Test the upgrade in a staging environment first. Some packages may have configuration file changes that require manual intervention during the upgrade process.
Key things to check and prepare before upgrading:
- Python scripts: Audit any scripts relying on Python 2 and either update them to Python 3 or ensure Python 2 is installed after the upgrade.
- Network configuration: Review your
/etc/network/interfacessettings and plan the Netplan equivalent YAML configuration. - Database choice: Decide whether you want MariaDB or MySQL and plan the migration if you need to switch database servers.
- Custom repositories: Remove or update third-party APT sources to avoid version conflicts during the upgrade.
- Running services: Document all running services and their expected configurations so you can reconfigure them after the upgrade completes.
Post-Upgrade Checklist
After upgrading, run through a verification checklist to confirm everything works correctly:
cat /etc/os-release
# Confirm the version shows Ubuntu 18.04
python3 --version
# Check Python 3 is available
systemctl status nginx mysql php-fpm
# Verify services are running
netplan apply && ip addr
# Confirm network configuration
df -h
# Check disk space and available storage
journalctl --since "2 hours ago" -p err
# Check for errors in recent logs
Update any cron jobs or scripts that reference Python 2. Test that automated backups still work. Verify that monitoring and alerting systems are functioning correctly. If you use configuration management tools like Ansible, update any playbooks that reference the old network configuration style.
Key Differences Between Ubuntu 16.04 and 18.04
The table below summarises the main changes that affect day-to-day administration when moving from Ubuntu 16.04 to Ubuntu 18.04.
- Network configuration: Changed from
/etc/network/*to/etc/netplan/*.yaml - Python default: Changed from Python 2 to Python 3
- Init system: Remained systemd in both versions
- Database default: Changed from MySQL 5.7 to MariaDB 10.1
- Firewall tool: UFW in both versions
- Snap support: Optional in 16.04, built-in and default in 18.04
Planning Your Upgrade
Upgrading from Ubuntu 16.04 to Ubuntu 18.04 involves real changes to how the system is configured. Netplan replaces the traditional interfaces file, Python 3 becomes the default, and MariaDB replaces MySQL in the default repositories. These changes are manageable with proper preparation.
Before upgrading, document your current configuration, back up your data, and test the process in a staging environment. If you encounter issues during the upgrade or need help reviewing your server configuration before or after the process, preparing a summary of your current setup, running services, and specific issues helps speed up the troubleshooting process.