Even if opensuse targets the desktop we did use it for several server like install. We did use it even for firewall deployments (with a few customization of course).
So we ported a lots of script from one of our old install to a new 42.1 version but we had a lot of problems with wicked.
First of all interface (eth*) rename didn’t work as expected. It worked only if we adopted a new name schema (i.e. neth*) but we wanted to keep eth* and we wanted to name specific NIC to a specific eth name.
This didn’t work. Some interfaces did not get their routes. And some interface did not get their IP addresses. This was caused by wicked searching for duplicate ip addresses. It was discovering that another firewall had the same IPs on some interfaces (but not directly connected to our install). So wicked did not bind the address to the interface.
This can be nice with a desktop PC but totally wrong with server or network firewall deployment. We want a fast boot and fixed configuration and nothing must interfere with this.
We searched a lot to solve these problems with wicked but unsuccessfully.
We had to totally disable wicked and switch to NetworkManager. We are currently testing our procedures with NetworkManager, if this fails we should stop using opensuse after 15 years … a bit sad …
Anyone with similar experiences ?
Can you explain more explicitly what you tried here? Did you edit /etc/udev/rules.d/70-persistent-net.rules?
For reference, I was able to rename my network interface by changing
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:36:86:14", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*",
NAME="eth0"
to
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:36:86:14", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*",
NAME="eth2"
# ifconfig
eth2 Link encap:Ethernet HWaddr 08:00:27:36:86:14
inet addr:192.168.1.12 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe36:8614/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:423 errors:0 dropped:0 overruns:0 frame:0
TX packets:134 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:41686 (40.7 Kb) TX bytes:17672 (17.2 Kb)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Of course you may also need to make the associated changes to the /etc/sysconfig/network/ifcfg-eth* config files to match your specific network situation.
Correct.
I changed /etc/udev/rules.d/70-persistent-net.rules. But I have 10 nics (eth0 to eth9). Maybe a different situation from a single NIC. Anyway everything is fine changing the prefix from “eth” to anything else.
What I learned from logs is that wicked already bind eth names from the start and then there is the rename. Thus if you want to assign eth0 to a specific NIC that name has been already binded to another and wicked has to "“switch” eth names and this leads to a bad configuration on some nic (device-not-running error, the device had its IP address but was unable to route packets). Anyway I found an advice NOT to rename using the same eth prefix … and this is, according to my experience, correct.
Of course the ifcfg-eth* were correct and changing the prefix to “neth” and using ifcfg-neth* configuration file was working correctly.
I did not like renaming eth* to anything else but what forced me to drop wicked was the fact that wicked puts “too much intelligence” in handling the NIC … among other things, it tries to detect duplicate ip addresses and then drops it if found (but this is a firewall … network configuration has to be stable and solid … if there is a duplicate is the other end wrong …) everything seemed unstable and uncertain. Even documentation is very poor. From a server side view it is unusable.
I can only suggest a bug report then. It’s the only way it will get fixed.
In my experience, if you assign an address to an interface that already exists on the network,
Then your address will not work.
This has always existed and I’ve never seen differently even “before” Wicked.
So, IP address assignment on the network is a Systems Architect issue.
Good planning, and documented for everyone today and into the future is necessary to avoid problems.
Ample address spaces reserved for different uses is absolutely essential to avoid problems for the lifetime of the company.
And then, good use of name services and centralized management like DHCP in your network to avoid the necessity of using specific addresses is also necessary.
It’s an indication of poor design for any machine that <must> be assigned an address now and forever.
Exceptions can exist but must be only for exceptional reasons.
As for your “interface name already taken” problem,
I’d be surprised if that can’t be manged by script, and IMO that’s a function of device discovery.
I haven’t looked at this for a very, very long time but when I built my own boxes the order in which devices were discovered and configured was based on the hardware bus/slot they were installed. If things work differently today, I’d be surprised but even so I would expect that scripts should be easily able to re-assign logical names for devices with a specified device id.
Also, if all 10 NICs are exactly the same, then the path of least resistance might be to simply run your script, figure out which NIC does what and then configure your physical connections accordingly (Of course, this assumes that your original “old” script was written with enough flexibility to still work flawlessly).
But, before everything described above,
I’d first probably ask why I’d be running into these kinds of problems…
I assume that the only reason why someone would try to automate the configuration of network interfaces is to deploy a large number of same machines, but machines with 10 NICs each?! Wow, that’d be something if you’re trying to roll out and possibly maintain a very large number of 10 NIC machines. At this point, I’d possibly be considering using something like Puppet or Chef… Otherwise if it’s only maybe 3 machines, I’d probably opt for custom building each machine.
If this is also an approach which hasn’t been updated for 10 years,
I’d maybe also want to consider if some of the individual configurations should be updated… eg Is it still critical to use exactly the same interface names assigned to the exact same addresses? What about the hardware vendor of these machines, a lot of times they come with specialized “enterprise” software that solves these kinds of problems.
TSU