Configuring physical adapters - Linux Tutorial

- Do you need to configure network adapters under Linux? Let's talk. - [Announcer] You're watching ITProTV. (electronic music) - Hello, welcome back to LPIC-2. I am Zach, and this is Don and we're looking at the wonderful world of network adapters, aren't we? - That's right. You know, in Linux, a lot of times your network adapters are set up automatically, but as a Linux system engineer, you'll likely be expected to do static network configuration. So in this episode, we're going to learn about how that's done. Some of the different ways that your network adaptor might be configured, because unfortunately, it is very different as you move from distro to distro. So we'll take a look at that. We'll see some of the commands that can make it a little bit easier to manage our network adapter and see how we can verify the network configuration all right here in one action-packed episode. - Well, then how can we view our current network configuration? - So there's a handful of commands that are pretty consistent, that you can count on to look at your network configuration. And probably, you know, one of the older commands that a lot of people rely on is the ifconfig command. Let me show that one to you here. I'm going to drop into my terminal. Actually, hang on, I might not be able to show it to you. Ifconfig as an older command and it's being replaced by a new command I'll show in just a second. So let me see if ifconfig's even on here. It is not. So see how it's telling me I need to install net-tools, which is a package of older utilities? And I can do that real quick, it's not a big deal. But once we have that package installed, we can on ifconfig and we get a summary of our interfaces. Now, the way ifconfig worked is that command would go and pull from your network configurations and try and build this up and show you what the network configuration was. Well, that works, but it's not the most efficient way of doing things. And as the Linux kernel evolved, they added new API interfaces so that you can actually just talk to the kernel and the kernel will tell you the network configuration. It's already got it and you know that's the configuration that's actually running right now. So ifconfig was replaced by another tool called ip, and the ip utility actually reaches into the kernel to get its information. So if I were to type ip space addr, that's going to show me my IP addressing information. And you'll see it's basically the same information we saw with ifconfig, just formatted a little bit different, and like the extra error counters and things are missing. There's other ways to pull that data. But here I can see the configuration of my adapters. I can do an ip route and see my routing information if I've got a default route in place or something else. And so I can learn about it. It's always important to see what your configuration currently is to find out whether or not you actually need to change it. - Well, is there anything that we should do before we start fiddling around and changing things? - Yeah, you know, if we're trying to set a static IP, then we're going to have to change things. That's just how it is. But if we're trying to get our system working again, well, we're going to have an episode on network troubleshooting in a minute, but there are a few quick things you can try. For example, if you're using DHCP, maybe you just timed out reaching out to a DHCP server. So you can trigger DHCP to go and redo its job and get an address again. The way you would do that is by using dhclient. So that's the DHCP client. You can do a sudo dhclient -r, and that will release- Oh, I have to spell it right. There we go, sudo dhclient -r. That will release whatever IP address you're holding. And then you rerun sudo dhclient by itself, and that'll try and reacquire an address. So sometimes that's all we need if we're just trying to get on and get going. Or you might need to restart your entire networking stack. Especially if you've made a bunch of changes, the changes might not take effect right away. So you can restart that networking stack. On a sysvinit system, you would type, let's see, you would do sudo service network restart like that, and that would restart the networking stack. I'm on a systemd system though, so that doesn't work, so that this would be something I would do on like CentOS 6 or some older system. On a newer system, we would do sudo systemctl restart. And then most systemd systems are using what's called the NetworkManager. So I would say sudo systemctl restart network-manager. When you run that, that's going to cause it to reload the configuration and hopefully sort your problem out, right? So it may be as simple as doing one of those things, and I don't have to go into and change anything at all. - Well, where are the network interface configurations stored, though? - All right, so if we're just doing automatic configurations, they're probably not stored anywhere, right? It's just automatically configuring and that's that. But if we're going to do a static assignment or if a static assignment's already in place, then there's going to be configuration files. Unfortunately, I can't just tell you here's the one place you go, because there's actually several different places it could be. So let me give you a few examples. If I were on a Red Hat based system, so CentOS, RHEL, Fedora, even SUSE, if I go over to a Red Hat system, where I'll find the configuration files is in /etc/sysconfig/network-scripts/. So that folder right there, if I go into that folder and take a look, what I should see are files representing my interfaces. If I run ip addr, I can see I've got a interface right here, which is called ens160 and it's got the IP address, 10.0.222.52. And so looking in that folder, I see ifcfg-ens160, so that is my configuration. And if I were to edit that, so let me do a sudoedit of that file, and I look in here, here it is. Here's the configuration file that's defining this adapter, and I can see pretty clearly what I need to do. Ip addr equals 10.0.222.52. If I want to change that, I'd just go and I replace it. And the gateway DNS settings and so on, they're all easily defined right there inside of this configuration file. So on a Red Hat based system, that's where they'll be stored, right? On a Debian system, it's a little bit different. Instead of, oops, let me get out of this. Instead of /etc/sysconfig/, they're actually tucked away in a different spot. It's still in /etc/. It would be /etc/sys- Let's see, it would be- I got to remember. /etc/network, there we go. /etc/network/interfaces. That's where it is on a Debian system, so I'm not going to have that on this one. So let me just try and get to it. Yeah, so I don't even have that directory present, but it would have the text files there. And the text files are a slightly different format. Look at the show notes. I'll put examples of both sets of configuration files, but you just edit those files and change them, then the next time the network reloads, it's going to read those, process them, and now you've got those changes in place. So different places to go. It can be a little bit challenging. Making it even harder are automatic services like the NetworkManager or Netplan. The newest versions of a Ubuntu use Netplan. Let me show you on this Ubuntu server that I've got. If I go into /etc/netplan, and take a look in there, I've got this 00-installer file. Let's let's look at that file. And looking inside of it, I've got an ethernet network, an interface, ens32, here's the IP address assigned to it, the gateway and so on. Netplan is a service that's designed to do cloud deployments and pull IPs from different locations. So this is a whole separate service that's overriding the network configuration. So when we work on a Linux server, we've got to find out is it just using regular configuration scripts to configure the adapter? Or does it have Netplan? Does it have the NetworkManager? It it's really confusing, so we've got to figure that out before we can actually do the configuration. - Well, do the interface names mean something? What does ENS mean? - You know, so we've seen- Actually, I guess we've only seen ENS, right? So I got ens32 over here on my Red Hat system. I had, what did I have? Ens160, I got a virtual bridge, that doesn't count. Let me look on my laptop, what do I have here? See if I have anything really cool. Eh, ens33. All right, so these are boring. Well, when you look at these interface names, the names do mean something, right? The first two characters are telling you what type of adapter it is. So when I see EN, that's an ethernet network adapter, and that means a physical network jack. On the side of my laptop, I've got a copper RJ-45 jack. That's going to be an ethernet adapter, so it'll have an EN. If you see a WL, that's a wireless LAN, so I've got a wireless adapter. Those will show WL followed by something. Or if you see WW, WW means it's a cellular wireless card. So if you've got like a 5G card and you're on a cell network with it, it'll show as WW, all right? So those are the first two letters. Then the third letter is indicating the type of slot that it's in, okay? So it might be on board, in other words, built into the motherboard, and so you would see ENO, if it was an ethernet adapter soldered onto the motherboard. Or if it was in a PCI slot, like a PCI-U slot, it would show as ENP. Or like mine, where it says ENS, the S means it's a hot plug slot, right? Hot plug slot usually refers to USB. USB is the hot plug most people use, but there are some PCI slots that are hot plug, and so it'll show as ENS in that case as well. So those are kind of what those names mean. Udev is what assigns those. We don't normally change them. The only annoying part of the numbers at the end, when you're dealing with physical adapters, it'll normally start with a zero, so they're nice and small, but when you're on a virtual machine, like I am with my, my Ubuntu system here, you'll see some of the interface numbers, ens32. That doesn't mean I've got 32 network adapters. It just skipped to a high number to make sure it didn't conflict with anything physical. And on the Red Hat side, I had ens160. Like, I don't have 160. It just jumped that high to avoid conflict. - But what about global settings, like DNS servers? - Okay, so what I've shown so far has really been focused on individual adapter interfaces, right? So if I've got multiple interfaces, I'll have multiple configuration files, then that's where we'll have to set those. But I might just want to set DNS servers one time and that applies to my whole system. Those are global settings and those get set different places. Now you might set them on the adapter. In fact, on my Red Hat box, I did just that. So let me bring up the configuration here again, and you'll see on this interface, I've got DNS servers defined, right? Or if I was using DHCP, I'd automatically be getting the those, right? So for DHCO, up here where it says BOOTPROTO equals none, we would say BOOTPROTO equals auto, and that would tell, or DHCP, and that would tell it go and use DHCP to get that address, and it would get DNS services at that time. So the interfaces can have those settings, but if we want to set it globally, we're going to have to rely on something else. And it's going to depend on our system where that setting is going to come from. So we're going to have an episode on troubleshooting name lookups, because this is a challenge for a lot of people, but on older systems, what you'll find is the inside of /etc/, you'll find a file called resolv.conf. And so if I look, I should have it. Right there, resolv.conf, okay. And if I look inside of that file, what I see for mine is I have two name servers, nameserver 8.8.8.8, just like I saw on the interface. In fact, that's probably where it came from, right? But I didn't put them here. The very first line tells me generated by NetworkManager. I have the NetworkManager running on this system and it looked at the interfaces, figured out what the best candidate was for the name server and put it in here. If I edit this file, it's going to get overwritten the next time the NetworkManager processes configurations. So because I have NetworkManager in place, I can't edit this file. But on an older system, this file is where I would actually define those name servers and it would be globally defined, all right? Now I said I'm running the NetworkManager, which I am, but I'm also on a systemd system, and systemd may or may not, depending on your distro, be running a service called systemd resolved, and resolved is designed to handle name resolution for your system. So I can clearly see on my interface and right here that I've got 8.8.8.8 set as my DNS server, right? That's Google's DNS servers. But if I do a quick test, I'll just do nslookup www.google.com, okay? So I get an answer back and oh, it actually did use that server. It did use 8.8.8.8. Let me show you an example. Let me jump to maybe Ubuntu and see if it does different. Look up google.com here. And there we go, that's what I wanted. Look at the DNS server that I've got over here. 127.0.0.53. What the heck is that? Well, 127.0.0.1 is the loop back, that's yourself. But a lot of people don't realize that actually 127. anything is the loop back, the entire 127 range. And so here, 127.0.0.53, that 53 is a hint that this is DNS. If you're running systemd resolved, resolved acts as a proxy, it sits in between you and your DNS servers. So your name lookups actually go to resolved and then it goes out to look at the DNS servers out there on the internet. So if I want to change who my DNS servers are, I'm actually going to have to change that by using resolved, not by editing an interface script, not by editing /etc/resolv.conf. In fact, on this system, let me take a look at resolv.conf. And right here, I see a giant warning in the resolv.conf file. All this, whoops, all this stuff up here at the top is a big warning. This file is managed by systemd-resolved. And it just goes on to tell you, like, you really shouldn't edit this file because it gets overwritten all the time. And then the name server down here is just me anyway, right? So, this is kind of telling me that our settings are being set somewhere else. It kind of reminds me of, remember Super Mario Brothers, whenever you beat a level, it wasn't actually the princess, she would say, oh, the princess is in another castle? - [Zach] Exactly. - That's how resolved is, right? So the princess is in another castle. If you want to mess around with this and kind of see what it's actually using, you can run resolvectl status, and that'll show you what you're actually set up for. And so I can see I've got DNSSEC, and as I move down, here's my current DNS server, 8.8.8.8. So it is actually using the server I want. It's just sitting in between. And so if we want to manipulate that, we have to go into /etc/resolve- Ooh, do I not have it? I may not have this one. So let me go into /etc/. Do I have a resolv.conf folder? I might have to make it if it doesn't exist. It does not, so I'll have to make it myself. So if it doesn't exist, you can make the folder yourself, /etc/, and I'll do sudo mkdir -p. - p is parent, so I'm going to create sub folders and it'll create the parent folders for me. It's going to be /etc/resolvconf/resolvconf.d/. Actually, that's the folder I need, so I'll make that and I'll get into it. And then you just drop a folder in here. I'll do sudoedit, called head, and this is going to be the head of the configuration for resolved, and you can drop in settings in here. Like you can say nameserver 4.2.2.1 like that. And so now when resolved runs, it's going to see that and incorporate that, so I'm now kind of overriding that configuration. Otherwise it's going to look to the interfaces and pull it. That's where it got the values that it already had. So just know that global settings like DNS are even harder than network interfaces, because we have to figure out where it's being set from, and there's so many different places. - What about the host name? I didn't see that setting anywhere. - Oh yeah, yeah, so the host name. So like, if you look at mine, mine's called ubuntu-server, right? That's my host name. On a systemd system, it's not set from a configuration file. It's actually set by a service and you can run hostnamectl to be able to see what your current static host name is. There it is, right there. If I want to change what that host name is, I can just use hostnamectl to do it. So I would say sudo hostnamectl set-hostname followed by whatever I wanted that name to be. So, you know, maybe I want to call this one dons-server, all right? Now when you run it, don't expect to see that change right away, all right? Because when you log in and you go to a bash shell, it creates that prompt at login time. So I'll have to exit out and then reconnect before I actually see that change. But now I can see it right there. It's now called dons-server. So hostnamectl is how we would modify that one. - And what about the NetworkManager now? Is that easier than using the other tools? - So I'll have to say yes and no on that one, right? So the NetworkManager- - I love those answers. - It's harder to use, right? It's harder than editing a text file. However, the NetworkManager sorts everything on the backend for you. So if you've got a Debian system or a Red Hat system, if you've got systemd or sysvinit, if you use the NetworkManager, it figures everything out and it just takes care of it. And so the NetworkManager's kind of become the defacto way of configuring things. On Red Hat systems, it's installed by default. On Debian systems, you may have to install it yourself. It depends on the installation media you use. Some Ubuntu systems have it already, but with the NetworkManager, you have, what's called the nmcli and you can run nmcli status to get a list of what's going on on the system. So looking at this Ubuntu box, it actually doesn't have it. Let me jump over to my Red Hat one. And here I'll do nmcli status, and ooh, it doesn't know my status command. Oh shoot, I need to do device status, there we go. Nmcli device status, there. So I can see my network adapters. If they're green, that means NetworkManager knows about them, they're managed. I've got a couple others that aren't being touched by NetworkManager, so I see them. But I can go in and I can do configurations without having to hunt down files. I can, for example, like if I wanted to set DNS, I could do sudo nmcli connection edit, and then the name of the connection that I want to edit. So I'm going to edit ens160, so I'll edit that adapter, okay? I don't know where the configuration file is. I don't care where the configuration file is. NetworkManager will figure it out. And then once I'm in here, I can make changes. I can say set ipv4.dns, and I'll set it to 4.2.2.1. So I'll change that to something different. Again, I don't know which system is handling DNS for me. I'll let NetworkManager sort it out. And when I'm done, I can do a save, and I can say save temporary like that, which is going to save it to the running configuration. But if something goes wrong, I can just reboot, and it goes back to normal. Or I can do a save persistent, which will actually save it to disk. There it is, now that change is permanent and I can quit out and I'm good to go. So how did I know to type set ipv4.dns? Well, I had that one memorized, right? Or I end up going to the documentation to pull it up. So that makes NetworkManager a little harder to use, but the fact that I don't have to figure out where all the various configuration files are, that makes it a winner. So sometimes it's easier, sometimes it's harder. That's the long answer. - Fantastic. Well, thank you for the answer. Configuring physical adapters and anything else you'd like to add, Don? - You know, these things change all the time. Like Netplan was only recently rolled out in Ubuntu. So, you know, stay up to date on that. On the exam, they're going to focus on the Debian and Red Hat configuration files mostly, and you may see NetworkManager creep up on there. I've not heard of anyone seeing Netplan on the exam yet. So, you know, kind of focus on the ones that they're going to be testing you on, but in real life land, you're going to encounter them all. So be aware that you may have to hunt around a bit to find configurations. - Thank you, Don. Another great episode of LPIC-2. And thank you for joining us for this great episode. Make sure you watch every episode of LPIC-2. You're going to be very glad you did. We'll see you again next time, bye-bye. - [Announcer] Thank you for watching ITProTV.