In most cases, after you install your desired distribution of Linux, it receives an IP address via DHCP and away it goes. Whether you're using a graphical desktop environment or a shell environment with no GUI, the magic mostly happens in the background. While there are GUI tools to manage your network connections, anything you can do via a graphical tool, you can do via the shell. In the case of servers, there may not be a graphical environment at all, so learning how to manage your network connection via the shell is very important. In this section, we'll discuss the method for manually configuring an interface in Debian, and then discuss how to do the same thing with CentOS.

In the previous section, two methods were discussed for finding your current IP address. Depending on whether your distribution ships net-tools or iproute2, you can use one method or the other (or both). Of course, that's the first step. Do you have a connection? Checking to see whether or not you have an IP address is a logical place to start. You can also utilize a simple ping test:

ping www.yahoo.com

If you do get a response, chances are that you have a network connection. However, if you don't get a response, it doesn't necessarily mean that there's something wrong with your network. Some sites are configured to not respond to ping tests. Whenever possible, ping against local resources instead (such as your local DNS or DHCP server).

In Linux, ping works a bit differently than in Windows. For starters, the ping command in Linux will run virtually forever by default. To break out of it, press Ctrl + C on your keyboard. If you prefer to have ping stop after a certain number of tries, add the -c flag accompanied by the number of times you'd like it to attempt. In this case, our ping command will be like this:

ping -c 4 www.yahoo.com

In this case, ping will attempt four times, stop, and then report some basic statistics to you.

Knowing how to check whether or not you're connected is one thing, but what do you do when you're not? Or what if your network connection is active, but reports invalid information and you need to reconfigure it?

First, let's explore how to check our current configuration. In Debian, the file that controls the network devices by default is the following:

/etc/network/interfaces

Depending on several variables, which include how you configured your Debian installation, this file may be created differently. First, you may see several interfaces listed, such as your loopback adapter, wired Ethernet, and wireless. If you have more than one wired interface, you'll see any additional adapters here as well. This file is, simply put, a configuration file. It's a text file that contains information that the underlying Linux system understands, and causes a device to be configured as designated in the file.

To edit files such as these, there are many Linux text editors available, both GUI and terminal based. My personal favorite is vim, though many administrators typically start off with nano. The nano text editor is fairly easy to use, though very light on features. Alternatively, vim has many more features than nano but is a bit harder to get used to. Take your pick. To open a file in nano, all you need to do is type nano along with the name of a text file you would like to edit. If the file doesn't exist, the command will create it if you save the file. In the case of our /etc/network/interfaces file, the command will be similar to this:

# nano /etc/network/interfaces

Using nano is simply a matter of opening a file, using the arrow keys on your keyboard to move the insertion point to where you want to type, pressing Ctrl + O to save the file, and pressing Ctrl + X to exit. There are more features, but for the purposes of editing our configuration files, that's all we need for now. A tutorial for vim is beyond the scope of this book, but feel free to play around with it if you wish.

Now, back to the subject of our /etc/network/interfaces file. It's important to note that this file is not required for the purposes of ethernet and wireless adapters. If you see nothing in this file at all (other than the loopback device) it means that the network connections are being managed by Network Manager. Network Manager is a graphical tool for managing client-side network connections (which we'll discuss later in this chapter). For our purposes in this section, Network Manager is typically installed when you decide to include a graphical desktop environment when setting up Debian for the first time. If you did opt for a graphical environment (such as GNOME, Xfce, and so on), then Network Manager was more than likely set up for you and is handling the job of configuring your interfaces. If your interfaces file is blank other than the entry for the loopback adapter, then that means Network Manager is handling this task.

With Debian, it's extremely common to see installations in the wild with no graphical environment installed at all. A GUI is usually not necessary for the server to fulfill its purpose. A typical Linux administrator will configure a server with the minimum required packages for it to do its job, which often will not include a desktop environment. In this case, Network Manager may not be installed at all. If it's not, the /etc/network/interfaces file will then be responsible for setting up the connection. In other cases, perhaps Network Manager is installed, but was disabled by the administrator whom configured the network connections in this file instead.

So, when should you use Network Manager, and when should you just configure your connections in the interfaces file? In the case of end-user workstations (desktops and laptops), Network Manager is almost always preferred. In the case of servers, setting up the configuration in /etc/network/interfaces is preferred, especially when setting up a static IP address.

We've discussed what the interfaces file is, and when you'd want to use it. Now, let's take a look at some various types of configurations you can expect to see. First, let's gander at the interfaces file when only the local loopback adapter is listed:

cat /etc/network/interfaces

# The loopback network interface
auto lo
iface lo inet loopback

In this example, the machine most likely has Network Manager in use, as neither the wired (typically eth0) or wireless (typically wlan0) interfaces are shown. To verify this, we can check to see if Network Manager is running via the following command:

ps ax |grep NetworkManager

If Network Manager is running, you might see an output like this:

446 ?        Ssl    0:00 /usr/sbin/NetworkManager --no-daemon

That mystery is solved; the machine uses Network Manager, so there is no configuration for eth0 or wlan0 stored in /etc/network/interfaces. Now, let's take a look at an example from a machine where Network Manager is not being used. To configure eth0 in such an installation, the interfaces file would look similar to this:

# The loopback network interface
auto lo
iface lo inet loopback

# Wired connection eth0
auto eth0
iface eth0 inet dhcp

As we can see, we still have the loopback entry as we did before, but at the end of the file, configuration details were included for eth0. Just as in our loopback entry, we declare auto and then an interface name eth0, which means that we would like interface eth0 to automatically come up. In the next line, we clarify that we'd like to utilize dhcp for interface eth0 so that it will obtain an IP address automatically from a DHCP server.

In the real world, there's no good reason to abandon Network Manager in favor of manually configuring the connection when all we're going to do is use DHCP. However, this example was included here because it's actually fairly common in situations where a server receives a static lease from a DHCP server, rather than a dynamic one. With a static lease, the DHCP server will provide the same IP address for a particular MAC address each time. So in such a scenario, a server could have a designated IP address for it, but the IP address is still provided by a DHCP server. This is also known as a DHCP reservation.

Of course, it's also possible (and perhaps more common) to simply declare a static IP in the interfaces file. We'll even explore that method next. But a static lease is worth pointing out because it does carry with it an additional benefit. With a static lease, the node's IP configuration is not tied to its configuration with its installed distribution. If it's booted from live media, or even if the distribution is reinstalled, the node will still receive the same IP address each time its interface comes up. An additional benefit of a static lease is that you can configure the static IPs of all your nodes in one central place (on the DHCP server), rather than keep track of individual configuration files from machine to machine.

Now, let's look at an example interfaces file where a static IP has been manually configured:

# The loopback network interface
auto lo
iface lo inet loopback

# Wired connection eth0
auto eth0
iface eth0 inet static
    address 10.10.10.12
    netmask 255.255.248.0
    network 10.10.10.0
    broadcast 10.10.10.255
    gateway 10.10.10.1

First, notice the change in the following line:

iface eth0 inet static

At the end, we declare static instead of dhcp. If we had forgotten to change this, all the remaining lines of the configuration file would then be ignored.

Then, we declare the statistics for interface eth0. We set the IP address to 10.10.10.12, the subnet mask to 255.255.248.0, the network we're joining to 10.10.10.0, the broadcast ID as 10.10.10.255, and the gateway as 10.10.10.1. We'll discuss what each of these values actually mean later on in this book, but for now the important thing to note is the syntax for this file.

So now you may be wondering how we make these changes take effect, now that we went through the trouble of configuring our interface. To do so, you would use the following command:

# systemctl restart networking.service

With CentOS, the process of manually configuring network interfaces is a bit different to Debian systems. First, we'll need to know which interfaces are installed on our machine. Running the following command will list them, along with any IP addresses that are currently assigned:

ip addr show

In this section, I'll use enp0s3, which is the default on the test machine used for this book. If yours differs, change these example commands accordingly. Anyway, now that we know what interface we're working with, let's configure it. Next, navigate to the following directory:

cd /etc/sysconfig/network-scripts

If you list the storage for the files within that directory (the ls command), you should see a configuration file with a name that matches the name of your interface. In our example of enp0s3, you should see a file named ifcfg-enp0s3.

Open this file with your chosen text editor and you'll see the configuration looks similar to the following:

HWADDR="08:00:27:97:FE:8A"
TYPE="Ethernet"
BOOTPROTO="dhcp"
DEFROUTE="yes"
PEERDNS="yes"
PEERROUTES="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_PEERDNS="yes"
IPV6_PEERROUTES="yes"
IPV6_FAILURE_FATAL="no"
NAME="enp0s3"
UUID="a5e581c4-7843-46d3-b8d5-157dfb2e32a2"
ONBOOT="yes"

As you can see, this default file is using dhcp, which is listed on the third line. To configure this connection to utilize a static address, we'll need to change the file accordingly. Changes to the file are marked in bold:

HWADDR="08:00:27:97:FE:8A"
TYPE="Ethernet"
BOOTPROTO="static"
IPADDR=10.10.10.52
NETMASK=255.255.255.0
NM_CONTROLLED=no
DEFROUTE="yes"
PEERDNS="yes"
PEERROUTES="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_PEERDNS="yes"
IPV6_PEERROUTES="yes"
IPV6_FAILURE_FATAL="no"
NAME="enp0s3"
UUID="a5e581c4-7843-46d3-b8d5-157dfb2e32a2"
ONBOOT="yes"

Here, we made just four changes to the file. First, we changed BOOTPROTO to static. Then, we added the following brand new lines just underneath it:

IPADDR=10.10.10.52
NETMASK=255.255.255.0
NM_CONTROLLED=no

I'm sure you can gather what the first two lines are responsible for. The fourth line we added may be obvious too, but just in case it isn't, we're basically telling our system that we would rather not manage our connection via Network Manager, and would like to take care of that ourselves with this configuration file.

Of course, we need to restart networking in order for these changes to take effect. Since CentOS uses systemd (just like Debian 8), the command is very similar:

# systemctl restart network.service

And, there you have it. We took care of manually setting up our network interfaces in both Debian and CentOS.