loading...

Ubuntu Server 18.04 – Assigning static IP addresses

How to turn off IE enhanced security on Windows Server 2019

With servers, it’s very important that your IP addresses remain fixed and do not change for any reason. If an IP address does change (such as a dynamic lease with no reservation), your users will experience an outage, services will fail, or entire sites may become unavailable. When you install Ubuntu Server, it will grab a dynamically assigned lease from your DHCP server, but after you configure the server the way you want it, it’s important to get a permanent IP address in place right away. One exception to this rule is an Ubuntu-based VPS. Cloud providers that bill you for these servers will have an automatic system in place to declare an IP address for your new VPS, and will already have it configured to stick. But in the case of virtual or physical servers you manage yourself; you’ll start off with a dynamic address.

In most cases, you’ll have an IP address scheme in place at your office or organization, which will outline a range of IP addresses that are available for use with static assignments. If you don’t have such a scheme, it’s important to create one, so you will have less work to do later when you bring more servers online. We’ll talk about setting up a DHCP server and IP address scheme in Chapter 7, Setting Up Network Services, but for now, I’ll give you a few quick tips. Your DHCP server will typically have a range of IP addresses that will be automatically assigned to any host that requests an assignment. When setting up a static IP on a server, you’ll want to make sure that the IP address is outside of the range that your DHCP server assigns. For example, if your DHCP server assigns IPs ranging from 10.10.10.100 through 10.10.10.150, you’ll want to use an IP address not included within that range for your servers.

There are two ways of assigning a fixed address to a network host, including your servers. The first is by using a static IP assignment, as I’ve already mentioned. With that method, you’ll arbitrarily grab an IP address that’s not being used by anything, and then configure your Ubuntu Server to use that address. In that case, your server is never requesting an IP address from your network’s DHCP server. It simply obeys you and uses whatever you assign it. This is the method I’ll be going over in this section.

The other way of assigning a fixed address to a server is by using a static lease. (This is also known as a DHCP reservation, but I like the former because it sounds cooler). With this method, you configure your DHCP server to assign a specific IP address to specific hosts. In other words, your server will request an IP address from your local DHCP server, and your DHCP server is instructed to give a specific address to your server each time it asks for one. This is the method I prefer, which I’ll go over in Chapter 7, Setting Up Network Services.

But you don’t always have a choice. It’s often the case, that as a Linux administrator, you may or may not be in charge of the DHCP server. At my organization, our DHCP server runs Windows, so I don’t touch it. I let the Windows administrators deal with it. Therefore, you may be given a free IP address from your network administrator, and then you’ll proceed to configure your Ubuntu Server to use it.

There are now multiple methods for setting an IP address manually on an Ubuntu Server, and which method you use depends on which version of Ubuntu you’re running. Since Ubuntu 17.10 (the version directly preceding Ubuntu 18.04) the way in which you set a manual IP has completely changed. First, I’ll go over the new method (using Netplan) and then I’ll go over the method we can use in legacy versions of Ubuntu, in case you end up managing such a server.

With Netplan, configuration files for your network interfaces now reside in the /etc/netplan directory, in YAML format. The YAML format itself is beyond the scope of this tutorial, but the syntax is very easy to follow so you don’t really need to thoroughly understand this format in order to configure your network interfaces. If you list the contents of the /etc/netplan directory on a server running Ubuntu 17.10 or newer, you should see at least one file there, 01-netcfg.yaml. It’s possible the file could be saved with a different name, such as 50-cloud-init.yaml. On my server, the file looks like this:

# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: yes

We can already glean some obvious information from this default file. First, we know that the interface will utilize DHCP in order to grab an IP address, which we can tell from the last line. We can also tell that this configuration file is related to interface enp0s3. One thing that may not be immediately obvious is the renderer line, which is set to networkd in this case. This tells us that the service that is managing this interface is systemd-networkd, part of the systemd suite of tools. Many things on the system are managed by systemd (which is pretty much taking over everything nowadays). An alternative to systemd-networkd is NetworkManager, but we’re not going to get into that just yet.

You can probably guess one edit to this file we need to make in order to assign an IP address manually. The last line, dhcp4: yes should be changed to dhcp4: no. Right underneath that, we’ll add a new line:

addresses: [192.168.0.101/24]

Of course, you’d add whatever IP address you want, I used a standard /24 address as an example. However, we’re also going to need a default gateway and DNS address, so we have more lines to add. Here is the complete file, with the new lines we need added to the end:

# This file describes the network interfaces available on your system 
# For more information, see netplan(5). 
network: 
  version: 2 
  renderer: networkd 
  ethernets: 
    enp0s3: 
      dhcp4: no 
     addresses: [192.168.0.101/24] 
     gateway4: 192.168.1.1 
     nameservers: 
       addresses: [192.168.1.1,8.8.8.8] 

In the sample file, I bolded configuration lines that were either changed or newly added. In a nutshell, I added an IP address of 192.168.0.101 with a CIDR mask of /24. (We’ll get into the specifics of how IP addresses work in a later chapter). Next, I set the default gateway to 192.168.1.1. Note that the option used was gateway4. If I was using a default gateway that had an IPv6 address, I would’ve needed to use the gateway6 option instead. In fact, I could’ve also set an IPv6 address by adding it to the same line where I declared the IPv4 address, making it look like this:

addresses: [192.168.0.101/24, '2002:2::4/64']

Finally, I set the DNS servers to 192.168.1.1 and 8.8.8.8. This is to simulate a situation in which the server would resolve names from a local DNS server and an external one (I used Google’s 8.8.8.8 as an example).

Next, we’ll need to apply and test these changes. This is something you probably don’t want to do over SSH, since as soon as you activate these changes your SSH connection will drop. If you are using a virtual machine, you may want to make the changes from the VM console. If you’re updating a physical machine, you may want to have a display attached. To actually make these changes take effect you can run the following command:

sudo netplan apply

When you run the previous command, it will let you know if there are any errors in the file or it will apply the changes if not. The new IP address will take effect immediately.

Next, let’s take a look at the procedure as it was in legacy versions of Ubuntu (basically, any version of Ubuntu older than 17.10). To set a manual IP on such a server, we will need to edit the /etc/network/interfaces file. This file is a single place for you to manage settings for each of your network interfaces on older systems. An example of this file follows. I’ve left out the output regarding the loopback adapter, and what you’ll see is the section relating to the primary network card on one of my older servers:

# The primary network interface 
auto enp0s3 
iface enp0s3 inet dhcp 

With this default file, we have a primary network interface (enp0s3), and we’re allowing this interface to receive a dynamic IP assignment from a DHCP server. You can see this on the third line, where dhcp is explicitly called. If you haven’t changed your /etc/network/interfaces file, and you’re not using a VPS, yours will look very similar to this, with the interface name being the main difference.

If we wanted to manually assign a static IP address, we would need to make some changes to this file. Here’s an example interfaces file, configured with a static address:

# The primary network interface 
auto enp0s3 
iface enp0s3 inet static 
    address 10.10.96.1 
    netmask 255.255.255.0 
    broadcast 10.10.96.255 
    dns-search local.lan 
    dns-nameservers 10.10.96.1 

I’ve bolded the sections of the output that I’ve changed. Essentially, I’ve changed dhcp to static and then added five additional lines. With this configuration, I’m assigning a static IP address to 10.10.96.1, setting the subnet mask to 255.255.255.0, and the broadcast address to 10.10.96.255. For name resolution, I’m setting the DNS search to local.lan (you can omit this line if you don’t have a domain), and the DNS server address to 10.10.10.96.1. If you wanted to configure a static IP address for your server, you would simply change this output to match your environment, making especially sure to change your interface name if it’s not the same as mine (enp0s3), as well as the values for your connection.

Now that we’ve edited our interfaces file, we’ll need to restart networking for the changes to take effect. Like I mentioned before, you would need to take some precautions here before you do so. The reason for this is, if you’re connected to the server via a remote connection (such as SSH), you will lose connection as soon as you restart networking. Even worse, the second half of the network restart (the part that actually brings your interfaces back online) won’t execute because the restart of networking will drop your remote connection before it would’ve completed. This, of course, isn’t an issue if you have physical access to your server. The restart command (which I’ll give you shortly), will complete just fine in that case. But with remote connections, your networking will go down if you restart it. The command to restart networking is the following:

sudo systemctl restart networking.service 

On older Ubuntu Servers (before systemd), you would use the following command instead:

sudo /etc/init.d/networking restart 

At this point, your new IP address configuration should take effect.

In the case of utilizing remote connections while configuring networking, you can alleviate the issue of being dropped before networking comes back up by using tmux, a popular Terminal multiplexer. A full run-through of tmux is beyond the scope of this tutorial, but it is helpful to us in this case because it keeps commands running in the background, even if our connection to the server gets dropped. This is useful regardless of whether or not your system has an interfaces file or uses Netplan. To use it, first install the package:

sudo apt install tmux 

Then, activate tmux by simply typing tmux in your shell prompt.

From this point on, tmux is now responsible for your session. If you run a command within tmux, it will continue to run, regardless of whether or not you’re attached to it. To see this in action, first enter tmux and then execute the top command. While top is running, disconnect from tmux. To do that, press Ctrl + B on your keyboard, release, and then press D. You’ll exit tmux, but if you enter the tmux a command to reattach your session, you’ll see that top was still running even though you disconnected. Following this same logic, you can enter tmux prior to executing one of the restart commands for your server. You’ll still (probably) get dropped from your shell, but the command will complete in the background, which means that networking will go down, and then come back up with your new configuration.

The tmux utility is extremely powerful, and when harnessed can really enhance your workflow when using the Linux shell. Although a complete tutorial is outside the scope of this tutorial, I highly recommend looking into using it. For a full walkthrough, check out the tutorial Getting Started with tmux by Victor Quinn, J.D at https://www.packtpub.com/hardware-and-creative/getting-started-tmux or check out some tutorial videos on YouTube.

With networking restarted, you should be able to immediately reconnect to the server and see that the new IP assignment has taken place by executing ip addr show or ifconfig. If, for some reason, you cannot reconnect to the server, you may have made a mistake while editing the /etc/network/interfaces file. In that case, you’ll have to walk over to the console (if it’s a physical server), or utilize your virtual machine manager to access the virtual console to log in and fix the problem. But as long as you’ve followed along and typed in the proper values for your interface and network, you should be up and running with a static IP assignment.

Comments are closed.

loading...