1. Introduction
In Linux system administration, understanding and managing network interfaces is a pivotal aspect. At the heart of this lies the /etc/udev/rules.d/70-persistent-net.rules file, a crucial component that plays a key role in the configuration and recognition of network interfaces on a Linux system. This file ensures that the system consistently names network interfaces across reboots, aiding in the maintenance of a stable network configuration.
In this tutorial, we’ll dive into several methods to regenerate the /etc/udev/rules.d/70-persistent-net.rules file without reboot, from using udevadm commands to manual recovery techniques. Let’s get started!
2. Understanding 70-persistent-net.rules
The /etc/udev/rules.d/70-persistent-net.rules file is more than just a configuration file; it’s a map that links our system’s network interfaces to their respective names.
Each time our Linux system boots, the device manager for the Linux kernel (udev) uses this file to determine how the system should name network interfaces. This consistency is crucial, especially for servers and systems with multiple network interfaces, ensuring that scripts and network configurations remain valid and functional across reboots.
However, as system administrators, there are instances when we need to regenerate the 70-persistent-net.rules file without undergoing the time-consuming process of rebooting the system. Whether it’s due to a hardware change or network reconfiguration, the ability to refresh this file on the fly can be immensely valuable.
Let’s imagine a scenario where we replace a network interface card (NIC) or add an additional NIC. The system might assign a new name to the NIC, potentially leading to network misconfigurations or even downtime. This is where the ability to regenerate the 70-persistent-net.rules file becomes essential. By doing so, we can ensure that the system correctly identifies network interfaces and names them consistently, thus maintaining the integrity of our network setup.
Moreover, there might be situations where rebooting the server to regenerate this file isn’t feasible. This is especially true in high-availability environments or when working with critical infrastructure. In such cases, knowing how to regenerate this file without rebooting can be a lifesaver, allowing for seamless hardware changes or network adjustments with minimal impact on the system’s availability.
3. Using udevadm
One of the primary tools at our disposal for managing udev rules is udevadm. This is the command-line tool for interacting with the udev device manager in Linux. It allows for direct interaction with the udev daemon, offering a way to control how it handles device events.
Also, udev dynamically manages device nodes in the /dev directory and handles all user-space events raised while we add or remove hardware devices and more. When it comes to regenerating 70-persistent-net.rules, udevadm can be particularly useful.
The process of regenerating rules with udevadm involves triggering udev to create or update the rules file.
3.1. Triggering udev to Recreate the Rules File
First, we use the udevadm trigger command with administrative privileges (sudo). This command allows us to simulate a change event for the network devices, prompting udev to regenerate the rules file:
$ sudo udevadm trigger --type=devices --action=add
Here, the trigger action requests the kernel to resend events for all devices that match the given conditions. We typically use this to reprocess the udev rules.
Then, the –type=devices option specifies the type of devices for which the events are to be triggered. In this case, it’s set to “devices“, which means the trigger will affect all the device events. Also, –action=add tells udevadm to simulate an “add” action for the devices. It’s as if the devices are being added to the system anew, which prompts udev to reprocess and regenerate the rules for these devices.
3.2. Confirming the Changes
After our previous interaction with udevadm, we can check if the 70-persistent-net.rules file has been updated by inspecting the file with the cat command:
$ cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:11:22:33:44:55", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="66:77:88:99:aa:bb", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
As we can see, our output displays the newly generated rules, each linking a network interface with its respective name. Each line in the file represents a udev rule.
These rules define actions that the udev system should take when we add a network device. The file contains entries that map MAC addresses to network interface names and ensure that each network interface gets the same name across system reboots. Notably, udev auto-generates and manages this file.
Let’s better understand our output:
- SUBSYSTEM== “net” – specifies that the rule applies to network devices
- ACTION== “add” – triggers the rule when a network device is added
- DRIVERS==”?*” – matches all drivers
- ATTR{address}== “00:11:22:33:44:55” – matches a device with a specific MAC address
- ATTR{dev_id}==”0x0″, ATTR{type}==”1″ – additional attributes to match specific types of devices
- KERNEL== “eth*” – matches devices whose kernel name starts with eth
- NAME=”eth0″ – assigns the name eth0 to the device matching the above criteria
By inspecting this file, we’re essentially confirming whether the udev rules have been successfully reapplied and whether any changes in the hardware configuration or udev rule definitions have been recognized and updated accordingly.
4. Creating Symbolic Links
In some situations, particularly in newer Linux distributions like Ubuntu 16.04 LTS or higher, we may find that the 70-persistent-net.rules file doesn’t exist. Here, the system uses a different mechanism for naming network interfaces. However, we can still manage network interface names by creating symbolic links (symlinks).
To do this, first, we create a symlink with ln to disable the default net-setup-link rules:
$ sudo ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rulesThis command prevents the system from applying default rules, giving us control over the naming. /dev/null is a special file that discards all data written to it (acts like a black hole). Linking to this file means any process trying to read the 80-net-setup-link.rules file will get nothing, effectively disabling these rules.
Next, we’ll create a custom network configuration file with a text editor like nano or vi using sudo:
$ sudo vi /etc/systemd/network/10-internet.link
In this file, we’ll add the following content (adjusting it for our network interface and MAC address). This file defines custom network interface configurations for systemd-networkd:
[Match]
Path=pci-0000:(our device mac address)
[Link]
Name=eth0Here, the [Match] section identifies the network device based on criteria like MAC address, driver, type, etc. Path matches a specific PCI device.
Also, the [Link] section is where we define the desired properties of the matched device, such as its name (Name=eth0).
Afterwards, we should save and exit the file. This configuration explicitly sets the name for our network interface.
By creating these custom configurations and symlinks, we’re effectively overriding the default network interface naming mechanism. This gives us greater control and flexibility, particularly in environments where consistent naming is vital.
5. Manual Recovery of 70-persistent-net.rules
In some cases, the more automated methods may not suit our specific situation, or we might prefer a more hands-on approach. In such cases, manual recovery of 70-persistent-net.rules can be our go-to solution. This method is especially useful when dealing with complex or non-standard configurations. Let’s see the steps to recover these rules manually.
5.1. Identifying Network Interfaces
First, we identify our network interfaces and their MAC addresses.
We can use the ip addr command to list all network interfaces:
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
...
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 12:34:56:78:9a:bc brd ff:ff:ff:ff:ff:ff
inet 192.168.1.2/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
...
This displays a list of all network interfaces along with their details, including MAC addresses, IP addresses, and the operational state (whether the interface is up or down).
Also, our output reveals the interface name (like lo for loopback and eth0 for the first Ethernet interface), the hardware link type (like ether for Ethernet), and addresses associated with each interface.
5.2. Setting Environment Variables
Once we’ve the MAC addresses, we can set the necessary environment variables for each interface.
For instance, let’s suppose we’re working with eth0:
export INTERFACE=eth0
export MATCHADDR="xx:xx:xx:xx:xx:xx" # Replace with the actual MAC addressHere, we set environment variables that the script will use. INTERFACE is set to the name we want to assign to the network interface (e.g., eth0), and MATCHADDR is set to the MAC address of the network interface.
5.3. Manually Running the write_net_rules Rules Script
With the environment variables set, we can now manually run the write_net_rules script:
$ /lib/udev/write_net_rules
This script generates the 70-persistent-net.rules file. It uses environment variables (INTERFACE, MATCHADDR) to create appropriate udev rules for network interfaces.
Notably, directly running system scripts like /lib/udev/write_net_rules is generally not recommended unless we’re fully aware of what the script does and how it interacts with our system configuration.
By following these steps, we can manually recreate the 70-persistent-net.rules file. This is a more advanced and manual approach, typically for cases where automated mechanisms fail or in special situations requiring fine-tuned control over network interface configuration.
However, if it’s critical, we should always proceed with caution and make sure we’ve backups of critical system files before modifying them.
6. Troubleshooting and Common Issues
Regenerating 70-persistent-net.rules without a reboot can sometimes lead to unexpected challenges or issues. Let’s address some common problems we might encounter and provide tips for troubleshooting them effectively.
6.1. 70-persistent-net.rules Not Being Generated
This can occur if udevadm doesn’t trigger the udev rules correctly or if manual settings are incorrect.
We should ensure we’re using the correct commands and environment variables. Also, we can check the udev version and documentation for our distribution.
Sometimes, restarting the udev service can help:
$ sudo systemctl restart udevWe should also verify the existence of /lib/udev/write_net_rules. If it’s not present, our distribution might use a different mechanism for network interface naming.
6.2. Incorrect Network Interface Names
This might happen if the MAC addresses in the 70-persistent-net.rules file doesn’t match the actual hardware addresses.
Thus, we should double-check the MAC addresses using ip addr and ensure they reflect correctly in the rules file. If we’re manually setting environment variables, it’s essential to verify their accuracy.
6.3. Conflicts With Network Manager
In some scenarios, the Network Manager, used in many Linux distributions, might override manual settings.
To fix this, we can temporarily disable the Network Manager before making changes:
$ sudo systemctl stop NetworkManagerAfter making our changes, we should remember to restart it:
$ sudo systemctl restart NetworkManagerThis successfully restarts the Network Manager.
Alternatively, to ensure seamless integration, we can configure Network Manager to ignore certain interfaces we’re manually configuring.
We do this by editing the Network Manager configuration file (/etc/NetworkManager/NetworkManager.conf) and adding an unmanaged-devices specification:
[keyfile]
unmanaged-devices=mac:00:22:68:1c:59:b1
This line instructs the Network Manager to ignore the network interface with the specified MAC address, allowing our udev rules to take precedence.
6.4. Changes Not Persisting After Reboot
This can occur if the rules file is not being read or is overwritten during boot.
We should check for other udev rules that might be conflicting with your settings. It’s important to ensure we correctly format our custom rules and we place them in the right directory (/etc/udev/rules.d/).
6.5. General Troubleshooting Tips
For logging and diagnostics, we can use the udevadm monitor and udevadm test to diagnose how udev is handling our devices and rules:
$ sudo udevadm monitorAlso, we can check the system logs for any udev-related errors or messages. These can often provide insights into what might be going wrong.
Lastly, it can be beneficial to back up the existing 70-persistent-net.rules file before making changes. This allows us to revert to a known good state if something goes wrong.
7. Advanced Customization of Network Interface Rules
In Linux system administration, the ability to customize network interface rules offers a powerful tool for managing how our system interacts with its network environment. This customization goes beyond the basic regeneration of 70-persistent-net.rules and ventures into the creation and modification of udev rules tailored to specific needs.
7.1. Writing Custom udev Rules
The art of writing custom udev rules involves understanding the syntax and parameters that dictate how these rules function.
Each udev rule is a line in a rules file, typically located in the /etc/udev/rules.d/ directory. The structure of a rule is a series of comma-separated key-value pairs, where each key represents an attribute of the device and each value represents a condition or an action.
For instance, a custom udev rule to rename a network interface based on its MAC address could look something like this:
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1A:2B:3C:4D:5E", NAME="net0"
This rule tells the system that, for devices under the ‘net‘ subsystem (network interfaces), when added (ACTION== “add”), if the MAC address (ATTR{address}) matches ‘00:1A:2B:3C:4D:5E‘, the device should be named ‘net0‘. This approach allows for precise control over device naming, making it possible to maintain consistent naming conventions even when hardware changes.
7.2. Integrating With systemd-networkd
For systems using systemd-networkd for network management, we can create specific .network files in /etc/systemd/network to match and manage devices based on our criteria. This way, systemd-networkd can coexist with udev rules, each managing different sets of interfaces or complementing each other.
Suppose we’ve a server with two network interfaces. We use udev rules to rename one interface to a specific name based on its MAC address.
At the same time, we want Network Manager to handle other network configurations dynamically.
In this case, setting the unmanaged device in Network Manager ensures that our udev rule is respected for the specified interface while Network Manager seamlessly manages other network aspects.
Ultimately, this advanced level of customization, while more complex, opens up a wealth of possibilities for finely tuned network interface management, ensuring that our system behaves exactly as we intend in its network interactions.
8. Conclusion
In this article, we explored the process of regenerating 70-persistent-net.rules without a reboot. We delved into a variety of methods, each catering to different scenarios and system requirements. From the straightforward use of udevadm to the more involved process of manual recovery and advanced customization of network interface rules, we covered a broad spectrum of strategies to manage network interfaces in a Linux environment.
Whether it’s maintaining consistent network interface names across reboots, adapting to hardware changes, or ensuring compatibility with various Linux distributions, the techniques discussed provide the foundation for robust network management.
Finally, by delving into advanced customization and best practices for network configuration management, we’ve seen how deeper knowledge and a meticulous approach can lead to more efficient, stable, and predictable network environments. The ability to write custom udev rules and integrate them with network management tools extends the control over our systems, ensuring that each component behaves as intended.