Bug#939904: Temporary network disruption during upgrade

[Luca Boccassi]

On Thu, 2022-08-18 at 18:07 +0200, Raphaël Halimi wrote:
> 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.

The default supported network configuration managers on Debian are
NetworkManager for desktop environments (default brought in by Gnome,
the default desktop env), and ifupdown (which is priority: important)
for headless environments.

> > > 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.

NEWS files' main purpose is to communicate breaking changes, so I hope
the issue in apt-listchanges is fixed before the release. Feel free to
go bump the severity if you wish. I cannot do much about it.

> > > 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.

Staying with a distro's default means there's almost always a seamless
upgrade path when breaking changes happen, though not always.

Going for a custom setup means sometimes there is, sometimes there's
not. It's always a tradeoff. This breaking change means there's now a
supported way to run resolved, and it's the easiest possible way for
all those that weren't using it before, which is the majority given
there was no support and no integration before.

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20220818/421df76a/attachment.sig>