I’m trying to create a base server image and would prefer to use systemd-networkd but it appears to be harder than expected…
Even with a base + minimal_base image with recommends turned off, wicked seems to get installed regardless. That’s fine. I’d rather not blacklist it with remove-packages since zypper complains about those every time.
Usually masking a service is enough to nuke it from existence even if the package is installed. Not in this case.
If I disable or mask wicked and enable systemd-networkd during installation, when the system gets updated the first time, the wicked package has an installation script that enables it (unless masked, then it stays masked) and disables systemd-networkd.
So, how do you reliably use systemd-networkd instead? Having to manually keep re-enabling systemd-networkd is not really acceptable in the long term…
I’m automating the system installation of a base image with AutoYaST.
So I just disabled wicked and enabled systemd-networkd in the services section of an AutoYaST file. Masking wicked I had to do by actually using the scripting functionality and chroot-scripts.
Like I said, disabling/masking wicked is not the problem. Wicked is initially disabled/masked and systemd-networkd is enabled just fine.
The problem is, when “zypper dup” is first run in the installed system, the wicked package gets updated and the package has an installation script (or update or post-update or whatever) that enables wicked and disables systemd-networkd.
So clearly my approach is wrong or the wicked package has a “bad” configuration. But I can’t deploy an image where the networking manager suddenly gets disabled on the first system update and networking stops working. It’s not going to happen just once but every time wicked is updated.
wicked is main supported networking backend in openSUSE. You either have wicked or NetworkManager. So I won’t be surprised if wicked is enabled by YaST-network module. Show “ls -l /etc/systemd/system/network.service” immediately after installation.
I have no experience with AutoYaST, but assuming that it instalsl a functioning (in this case 15.2) system, why do you do then zypper dup? IMHO one never does a zypper dup (without further options e.g. for a vendor switch to Packman) in a LEAP version as long as one does not switch to a newer LEAP version.
I still do not see how this is related to the OPs problem, nor what the steps are he has to take to get rid of his problem. It is just some mysterious listings without any explanation. When you can’t do better, please refrain then from helping.
Preset files may be used to encode policy which units shall be enabled by default and which ones shall be disabled. They are read by systemctl preset (for more information see systemctl(1)) which uses this information to enable or disable a unit according to preset policy. systemctl preset is used by the post install scriptlets of RPM packages (or other OS package formats), to enable/disable specific units by default on package installation, enforcing distribution, spin or administrator preset policy. This allows choosing a certain set of units to be enabled/disabled even before installing the actual package.
That is some background. Now what is the particular place where something is configured that bars the OP from his intentions? What should he change into what on what place (taking into account that nowadays there are places for the default configuration as provided by the designers / by the distribution (somewhere in /usr/lib or /usr/share or so, can be re-installed when updated), to be overruled by the system manager (in /etc) and for end-user (when applicable)to be overruled in (/home/<user>/.conf or the like).
And please in a way that makes it clear to be understood without to much digging by the OP (and all reading the thread later) that this is the logical, safe way of doing.
Although I haven’t explored this,
I’d expect that if you open YaST > System > Network Settings > Global Settings tab
The dropdown selection “Network Disabled” likely disables both Wicked and Network Manager and should allow you to implement an alternative like systemd-netowrkd.
Would reuuire actual testing, though.
I’m not sure there is any benefit to using systemd-networkd over wicked.
Although editing the interface files directly is not usually recommended (Use YaST to ensure settings and syntax are correct), it’s usually possible to do so and doesn’t look to be much different than the three levels of configurations used by systemd-networkd.
According to the top post the user is aware of post install scripts being executed, but has no idea where to look at. I pointed out he might look for presets.
Going into more detail would require more detailed information about what happens on his install of a new version of wicked and on all configuration changes made to system defaults. I am sticking to system defaults whenever feasible and I am running networkd and resolved without experiencing any of the problems reported in the top post: Network Management With Systemd - openSUSE Wiki
I’m not sure there is any benefit to using systemd-networkd over wicked.
Sure, there are benefits. Experienced nasty spurious problems when using wicked upon running ‘zypper dup’, resuming from suspend to RAM and booting different operating systems installed on the same hardware. Problems now are gone since switching to networkd/resolved.
It all depends on personal needs. For me systemd-networkd does what is needed and no more. It starts network connectivity at boot and halts it at shutdown. I do not need more.
Wicked seems to have even daemons running all the time. No idea why, but for me they are superfluous.
But all this does not help the OP. He has already decided what he wants. The problem is that he looses it under certain circumstances.
After that, on the first “zypper update”, wicked no longer gets enabled and networkd disabled. I think the actual culprit is the updated wicked-service package that would cause it to happen.
TIL about systemd presets. Never encountered this with other distros I think. On RHEL for example, if you just mask firewalld during installation, it never gets re-enabled even if the package/service gets updated.
As for why networkd over wicked: if you just want to set up a (virtual) server with a single NIC and a static IP address, you really don’t need anything complex and a continuously running bloated daemon to manage it. You just configure it once and you’re done forever. NetworkManager is just pure insanity in that scenario. Wicked doesn’t seem that bad actually, but networkd is perfect. Networkd has the sanest configuration file format of them all. I never want to use legacy compatibility options so having to configure wicked with XML is pretty off-putting. With networkd it’s easy to build even a complex setup with bonded interfaces and VLANs or bridges. All you need to write is some INI files. Plus, networkd is distro agnostic, wicked is SUSE specific.
Now there is something to be said about sticking to defaults as much as possible so that other administrators can work on systems more easily without having to know all of the customizations that were done. Due to that this does feel a little too custom.
He often is, but I do not understand why he does only post some snippets of code without any explanation. When I would assume he is wrong, I would not try to get him into posting it in a helpful way. I also want to learn from his experiments.
OK, that is the result of Karl’s message, fine.
But now you talk about zypper up. In your earlier posts you talked about zypper dup and I think it is something that makes a difference here. I have done many zypper patch (same as zypper up, but only for the standard repos) since I went to systemd-networkd and never have run into this problem.
And I asked you about you doing zypper dup after the one you did to upgrade to 15.2, but I missed your answer (is that me not reading good enough?).
I can not say anything about other distros.
Same here. I do not really understand what those daemon(s) do all the time, but I do not miss them since I switched.
The trigger was that during boot the whole wicked starting took more then 10 secs of which at least 5 - 6 was just waiting for it to be finished. Not now anymore.
I agree here also. The fact that this preset also has to be changed shows that you are lured deeper and deeper into customizing.
Another con of not using wicked is that when I want to help people here on the forums, I can hardly use YaST > System > Network Devices to see what they see and describe where they should look and fill in, because in my case most is greyed out and locked.
I never experienced these issues with Tumbleweed. This could be feature of Leap. I learnt about presets when dealing with btrfsmaintenance: 1165780 – Reduce the number of PID1 reloading triggered by btrfsmaintenance I could convince them to fix the bogus values, but I never cared for details of changes made.
As for why networkd over wicked: if you just want to set up a (virtual) server with a single NIC and a static IP address, you really don’t need anything complex and a continuously running bloated daemon to manage it. You just configure it once and you’re done forever. NetworkManager is just pure insanity in that scenario. Wicked doesn’t seem that bad actually, but networkd is perfect. Networkd has the sanest configuration file format of them all. I never want to use legacy compatibility options so having to configure wicked with XML is pretty off-putting. With networkd it’s easy to build even a complex setup with bonded interfaces and VLANs or bridges. All you need to write is some INI files. Plus, networkd is distro agnostic, wicked is SUSE specific.
I fully agree. Just to summarize every aspect in one post as suggested by hcvv I want to add:
Now there is something to be said about sticking to defaults as much as possible so that other administrators can work on systems more easily without having to know all of the customizations that were done. Due to that this does feel a little too custom.
Agreed. To my knowledge it does not occur with Tumbleweed and I prefer it to stay this way: No changes through updates please!
I also want to learn from his experiments.