Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use proper way to disable 75-persistent-net-generator.rules #1750

Open
jpbuecken opened this issue Jan 10, 2020 · 2 comments
Open

Use proper way to disable 75-persistent-net-generator.rules #1750

jpbuecken opened this issue Jan 10, 2020 · 2 comments

Comments

@jpbuecken
Copy link

jpbuecken commented Jan 10, 2020

The default for an SLES/RHEL server is to generate a file which hardcodes MAC to interface names.
This is bad if you want to use snapshots which get new MAC but config binds to old interface name.
To avoid this, the udev rules 75-persistent-net-generator.rules and 80-net-name-slot.rules needs to be disabled.

The WALinuxAgent does this already by deleting those files.
(see ./azurelinuxagent/common/osutil/default.py, ./bin/waagent2.0)
This is not the proper way because

  • An Update of the udev package will install the file again
  • The RPM database is inconsistent on SLES/RHEL

Example:

publisher = "SUSE"
offer = "SLES-BYOS"
sku = "12-SP4"
version = "2019.06.17"

Check that RPM database is incosistent:
:~> rpm -q udev -Vv | grep missing
missing /usr/lib/udev/rules.d/75-persistent-net-generator.rules

The proper way: Create symlinks to /dev/null in /etc/udev/rules.d/. See [1]
/etc/udev/rules.d/75-persistent-net-generator.rules -> /dev/null
/etc/udev/rules.d/80-net-name-slot.rules -> /dev/null

Additional information

  • 80-net-name-slot.rules does only exist on RHEL, 75-persistent-net-generator.rules only exist on SLES, but it does not matter to disable both on both operating systems)
  • If you boot an SLES12, you will see that /etc/udev/rules.d/75-persistent-net-generator.rules -> /dev/null will exist. This is because Suse netconfig creates it as well. It does not matter if the WALinuxAgent does it as well.

[1] man udev

RULES FILES
       The udev rules are read from the files located in the system rules directory /usr/lib/udev/rules.d,
       the volatile runtime directory /run/udev/rules.d and the local administration directory
       /etc/udev/rules.d. All rules files are collectively sorted and processed in lexical order,
       regardless of the directories in which they live. However, files with identical filenames replace
       each other. Files in /etc have the highest priority, files in /run take precedence over files with
       the same name in /usr/lib. This can be used to override a system-supplied rules file with a local
       file if needed; a symlink in /etc with the same name as a rules file in /usr/lib, pointing to
       /dev/null, disables the rules file entirely. Rule files must have the extension .rules; other
       extensions are ignored.
@narrieta
Copy link
Member

@trstringer Thomas, seems related to provisioning, could you take an initial look? thanks

@alv000h
Copy link

alv000h commented Apr 30, 2020

this problem is related to this issue:
#1877 consistent interface device naming

Disabling 75-persistent-net-generator.rules should be managed by optional configuration in waagent.conf, because if there are multiple interfaces in VM, legacy name (ethX) do not grant interface order anymore and eth interface number can be swaped randomly between reboots.

That is why Azure shoud comply with consistent interface device naming aka biosdevname as nowadays all major Linux distribution comply with that (Debian, Redhat, Suse, etc).

This system grant interface number order always in multi nic scenario, and not use ethX naming scheme anymore. For example in vmware, default names are ensX (ens0, ens1, etc) or you can use a total custom prefix for your interfaces (app1, app2, etc)

For additional info please refer above issue and optionally this document

Another one from redhat

Additional info on different schemas

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants