[arch-general] netcl leaves network down until reenable performed - do we need note?

[Erich Eckner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi list,

I got hit by this, too.

On Mon, 17 Aug 2020, Eli Schwartz via arch-general wrote:
> On 8/17/20 5:25 PM, David C. Rankin wrote:

>
> By "subservice" I think you mean ".include" stanzas?
>
> Your analysis is correct, this got removed from systemd here:
> https://github.com/systemd/systemd/commit/7ade8982ca1969e251a29589ae918c3b5c595afb
>
> and systemd 246 is the first release with its removal.
>
> However, netctl migrated over to *.d dropins here:
> https://git.archlinux.org/netctl.git/commit/?id=04d39b2573bd34d4159837afdb4793a0990bd44a
>
> So I think you should be fine if you've re-enabled the netctl profile
> with 1.18 or higher (released on 2018-08-07). That's 2 years. Granted,
> if it's been working for years, why would anyone care about manually
> re-enabling their netctl profile... but...
>
> There should also probably have been a warning logged in journalctl for
> this, if your service was still using the old method.

That's true, however, when this warning first appeared, `netctl reenable 
my-profile` did not help - same was true several days later (probably also 
weeks/months). So I forgot about the warning (I'm not keen to put `for 
profile in $list; do netctl reenable $profile; done` into my common update 
routine for all my arch boxes).

>
>> netctl at rlf_network\x2dstatic.service.d/
>> └── profile.conf
>>
>> However, there is no note or warning during update that any manual
>> intervention will be needed. That will leave anyone adminning a remote arch
>> install with netctl with a box that is unreachable and has no network.
>>
>> Shouldn't there be a warning about this change generated on update? Arch is
>> always pretty good about warning when manual interaction is required -- and
>> this is a biggie.
>
> I'm not sure it merits a news post for something that old which is only
> now becoming fatal.

In my opinion, a news post would have been appropriate. But now it's "too 
late" (see below).

>
> Hopefully anyone with remotely adminned boxes caught this while
> monitoring journalctl logs.

Logs were unhelpful at that time, see above.

>
> But, thanks for posting this to the list -- at the very least, people in
> the same situation will be able to figure out what happened by reading
> here. And hopefully they will see this *before* upgrading.

Additionally, people on the list might catch this issue in advance (if 
they don't update too often and have not yet been hit by this issue). This 
makes a news post obsolete, now, I believe.

>
>> Couldn't there also be a post install that does a reenable for each netctl
>> profile found in /etc/systemd/system as another option to avoid this SNAFU?
> That might have been an interesting precautionary measure for netctl
> 1.18, at least for printing a message advising people to reenable the
> service.
>
> I'm not sure it makes sense to do that automatically, since disabling a
> profile removes customizations and the netctl manpage explicitly warns
> you to be careful about doing so.

I think, it's not arch's way to do such things. Arch rather says "your 
config is broken/old, run `xyz` to fix it" than simply running `xyz`.

>
> -- 
> Eli Schwartz
> Bug Wrangler and Trusted User
>

regards,
Erich

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl87ZzQACgkQCu7JB1Xa
e1qq7w/+KHd/vyL9AloIgirCeEcYf/+JxcCOngmROoxbM/Gs3rtxynewpwqV6iCi
VJGIlrH5Xl2/NasKONRQuzNyGD0qqIMMRbAiNOZq3r37RAb8vmWmRxJmY5rkymO7
yoG4ox4HSgfeTyCvQhUnMZWE8Qm7INjcI/nHvs//wIwqB5ppeLkkFLHK9LCWBpaF
+dkKP5vrsvjrD9785RjjMg46iHDCJ3AEAPuZmWes7IgUR161MD7Ujf07YMDfit8u
1SrdtxsncPSR0OX/m4DKC31tBP5WjS4kGL61NjUfQm354YtkjhyULQ7ecobRNBqA
xQ4i6nLpbbZJSx38S0jfOgsAqKxM5HV6pFXRUR1GTT6a0MTxXG9bERmVm6oaFQeN
9cm3b4MbeBDVXp5x7MI2VGlG2mmNaIxZWpMKtUufQwBOxSkDSp5rifqy+NUgPhLX
H/WcdK8pCQfIVfiopENVA9aNrb25/ST79io0KfUNmON3HHEnCWaJGHmCFMB/yOe7
2frLccn6TP17KkSSL5cJev5tpB+epH9k3BUxln7BT9ZDGVNJwbhlksaKXWncj8Hg
OEvt6vqHCuswwvcrAvTJwDeCVtQRU4dt3cqSqCHuJjKzNg6egE1gU9KOxvFkZE0T
5dNq9DrcixQoXbG59DhNsOkM8b186HvvXOxTVBJvsFwS46Nnn4g=
=/I9c
-----END PGP SIGNATURE-----