Bug#939904: Temporary network disruption during upgrade

[Raphaël Halimi]

Le 18/08/2022 à 16:59, Luca Boccassi a écrit :
> No, custom and unsupported setups are unsupported. Compatibility is
> provided for default environments, anything outside of it can and will
> break at any given time, and it's not really feasible to do otherwise
> given the uncountable amount of possible permutations. This time
> there's a clear and unambiguos NEWS entry with a notification, which
> doesn't even always happen.

What I meant is that I thought systemd-networkd (which partly relies on 
systemd-resolved) was considered supported since it was shipped with 
systemd and thus installed by default (unlike, for example, netplan), 
albeit not enabled.

Should I understand that the only supported way to configure the network 
in Debian is ifupdown with a plain /etc/resolv.conf file, and everything 
outside of this scope is considered custom and thus, unsupported ? I'm 
not being ironical here, it's a legitimate question.

>> Wrong, I always receive e-mails with news as well as changelogs during
>> upgrades, with the more recent examples being on July 13, 22 and 25. I
>> don't know why it didn't work this time, but I can hardly believe that
>> it's apt-listchanges' fault.
> 
> And yet it is, and it's been a known issue for quite some time:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977422

OK, you're right on this point, I didn't know that. Apologies. But it 
also means that other sysadmins will be in the same case too when the 
upgrade will take place (when bookworm is released, or when systemd 
251.3-2 will be backported to bullseye) and will have their DNS 
resolution temporarily broken after the upgrade.

But I guess you'll probably argue that it's their fault for using 
systemd-resolved.

>> I think you don't understand my position: I don't care about resolvconf
>> or openresolv, I just want to use systemd-resolved (not the systemd
>> resolvconf interface, but the systemd-resolved service itself!) and
>> avoid breakage during upgrades for all users.
>>
>> Look, I'm just trying to help here. You made a change, it has serious
>> consequences for systemd-resolved users, and I hinted them to you,
>> that's all. I think this is a bad change, but that's another matter.
>> Being obtuse and condescending won't help.
> 
> Name-calling won't help either.

Right, but at least admit that you're being a bit harsh to me since the 
beginning of this thread, rejecting all my arguments and refusing to see 
the problem here, basically saying that the resulting breakage is not 
your fault and systemd-resolved users brought it on themselves by using 
it because it's "unsupported".

Again, I don't care about resolvconf or openresolv, I care about 
sysadmins who use systemd-networkd/resolved on their servers or 
containers, and I'm just trying to avoid problems for them as well as 
for myself in the future.

systemd brought a lot of controversy when it was adopted in Debian, and 
I myself was amongst the people who were quite unhappy when it happened 
(I still think that Jessie was too soon, it was not mature enough, but 
that's another story).

Now that we started to familiarize with its different parts and all in 
all find it very convenient that they're installed by default, you 
slowly remove them one by one (systemd-machined, systemd-timesyncd, 
systemd-boot, and now systemd-resolved... Which will be the next ?), 
forcing us sysadmins to constantly update our automated installation 
procedures (debian-installer hooks, ansible/puppet recipes, container 
images, etc etc), and defeating the very purpose of systemd to be "a 
suite of basic building blocks for a Linux system" that we finally embraced.

It's almost as if you want to discourage us to use the non-init-related 
parts of systemd.

Regards,

-- 
Raphaël Halimi