Lost network config on Linux image after deploying
-
@kafluke Search the web for static naming using udev rules. They are mapped to MAC address…
-
@Sebastian-Roth , are you saying that in my captured image I already have static naming setup or that I need to first have that setup before I capture? I’ve ready various articles and I’m not sure I follow the logic. This is the last piece that I need to get right before I can start imaging our PBX systems all over the country. Need to have network access after the deploy.
-
@kafluke Please tell us which kind of Linux system you capture/deploy so we can give specific instructions. In general most modern Linux systems use udev which has a concept of naming all kinds of devices, not just network cards. This is useful because the Linux kernel enumerates devices not in a strict order and so it can happen that you end up with eth0 and eth1 being reversed when rebooting the machine. So most systems generate a set of rules when detecting network cards on first boot and write those to a file - Debian that is
/etc/udev/rules.d/70-persistent-net.rules
, e.g.:... SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="f0:de:f1:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" ...
Now if you capture the machine including that generated rule file and deploy to a new machine with a different MAC address it generates new rules and names those eth2 and eth3 just as you described.
Solution number one would be to remove that generated rules file before capturing the image. Problem is that you have to remember doing this every time to boot up the master, e.g. to update system before capturing.
And second you could look into writing more general udev rules to match the network cards on all your systems. From my point of view this is possible only when the two network cards are different. You have the dilemma that you don’t want to have eth0/1 to be reversed by any chance but also you don’t want to identify those via MAC address as you want to deploy to different machines. I’ve done this at my old workplace where we had one Intel onboard NIC and a 3com PCI NIC.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="e1000", KERNEL=="eth*", NAME="eth0" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="3c59x", KERNEL=="eth*", NAME="eth1"
Take a look at the udev rules syntax. Maybe there are other IDs (vendor or whatever) that you could use.
-
I’d also like to know the target OS here. I can speak for Centos. In Centos 6.x here it is exactly as Sebastian says with udev rules and the network naming convention (eth0, eth1, etc). With Centos 7 and Linux Mint 18.x (which is based on Ubuntu 16.04) the kernel developers have switched from ethX naming convention to embedding the driver name into the network interface name. For example on my laptop the ethernet adapter is named eno1 and the wiifi adapter is named wlp2s0. It is my experience with at least Centos, it names the network adapters what the kernel calls them and then for the network config files in /etc/sysconfig/network-scripts the OS will rename eno1 as eno1.bak and creates a new eno1 config file if the mac addresses don’t match in the file.
If the udev rules are as Sebastian says with the older OS’ you can setup something similar to what I do for building a windows base image. I have a batch script that does some last minute clean up of the windows system then calls sysprep directly. This way I ensure all of the last minute stuff is done every time and then the computer is shutdown properly. You could do the same thing with a bash script to clean up any needed system settings and udev rules then shutdown the linux OS properly in preparation for image capture. This way you will have a consist image build if you need to reopen your golden image for any reason.
-
@sebastian-roth I believe that FreePBX is a version of CentOS which is Red Hat based. I try some of your suggestions and report back. Thanks.
-
@kafluke Yes, freepbx is centos based. Depending on what version of freebpx, you will have either centos 6 or centos 7. I can tell you Freepbx 14 is centos 7 based and Freepbx 12 is centos 6 based.
-
@george1421 FreePBX 13 is what we’re using. Here is a screenshot of the golden image that I want to capture and then deploy:
And here is the image deployed. Notice the missing IP’s. I need to be able to deploy this remotely to a site and then take over using SSH but they aren’t getting any DHCP IP’s:
I did try deleting the file “70-persistent-net.rules” and rebooting but it didn’t do anything
-
@kafluke Ok that image looks like its based on Centos 6 (maybe 6.6). There should be a file in /etc that will tell you what release but I’m pretty sure its Centos 6.
cat /etc/centos-release
So in this case Sebastian’s guidance is spot on. You need to modify the udev naming rules. Or just remove the reference to the golden image network adapters in the udev rules. For example here is my udev naming rules from /etc/udev/rules.d/70-persistent-net.rules on one of my old FreePBX servers.
# PCI device 0x8086:0x1076 (e1000) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:00:10:50:29", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2" # PCI device 0x8086:0x1076 (e1000) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:00:10:50:28", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" # PCI device 0x8086:0x1026 (e1000) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:00:83:27:aa", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
You need to remove these lines or just create a blank file.
Lastly in /etc/sysconfig/net-scripts you need to remove the mac address references (
HWADDR=00:00:00:83:27:aa
) from all of the ifcfg-ethX config files.This is not a fog thing, but more a centos 6 thing.
-
@george1421 I’m going to try and build a golden image using FreePBX 14 (the latest stable build) and see if the issue persists
-
@kafluke Good centos 7 will handle network interfaces a bit differently. So that is a good thing.
-
This has been resolved. I updated to FreePBX 14 (CentOS 7) on the golden image and it correctly sets up the NIC’s on the imaged machines. Thanks for the help