[ale] Remove systemd network handling

[Solomon Peachy]

On Fri, Sep 24, 2021 at 10:22:43PM -0700, Alex Carver via Ale wrote:
> To get security fixes and some library bug fixes I had to update.  It
> was not possible to stay with Stretch and get all the fixes I would have
> needed hence the upgrade to Buster.  Nowhere in the notes did it
> indicate it was going to automatically add systemd timers to fire off
> apt and do background system updates.

To be fair, I recall Raspbian enabling automatic background apt metatada 
updates by default.  Whether that was implemented using cron or systemd 
timers is immaterial; the policy did not change, only the mechanism used 
to implement it.

Now Debian as a general rule tries very hard to respect user 
configuration across updates but nothing is infalliable, that's why I 
asked if you'd reported this bug.  Assuming it was due to a _Debian_ 
change as opposed to _Raspbian_ -- there are a bunch of subtle (and 
not-so-subtle) differencs between them, least of which including the 
core purpose of the distribution.

But no [mainstream] linux distro I'm aware of automatically _applies_ 
updates without the user/admin/operator explicitly enabling/approving 
it.  So again, if something automatically _updated_ in the background, 
that's *because the operator explicitly turned it on*.

Meanwhile, your primary gripe here is that Raspbian apparently changed 
how their network interfaces were enabled/started/whatever, and it seems 
systemd-network was implicated.  Yet systemd-networkd is _not_ enabled 
by default in Debian Bullseye (or Buster) so if it was being used on 
your unit, again, it's either due to a change that _Raspbian_ made or 
because someone with root access turned it on.

Or maybe Pottering did this in cahoots with Bill Gates using the 5G 
COVID microchip and a backdoor in all Broadcom SoCs. (In a rare example 
of the Illuminiati and Chinese Communist Party having aligned interests, 
because the severe cutback in international flights due to COVID meant 
they couldn't rely on the traditional chemtrail disperal methods)

> I'm disappointed in you Solomon. DO NOT PIN THIS ON ME.  I was not given
> the option to keep my settings as they were, I would have not approved
> them and gone a different route if it had been disclosed.  Flippant
> suggestions of "don't change it" don't support the case that this change
> should have not done harm since your case is that systemd is better and
> this is objectively not the case in this instance where removing a
> portion fixed a problem.

The Raspberry Pi folks have long recommended _against_ doing in-place 
major upgrades from one OS release to the next, and have _never_ 
provided a supported upgrade path.  While yes, it generally works thanks 
to the efforts of Debian, Raspbian-specific changes to Debian aren't 
checked, and won't block releases.  This might be an example of one of 
the consequences of undertaking this path.

So, yes, this _is_ on you -- You chose to undertake a path that was not 
supported by upstream, who made no particular promises that it could be 
expected to work, on a critical production system without first doing a 
shakedown run to make sure there weren't any issues.  Or maybe this was 
the shakedown run.  Either way, bugs are to be expected because only 
_you_ can test your own environment. You deal with them and move on.

A useful data point here would be to install a from-scratch default 
Raspbian loadout and see if it exhibited the same wonkiness.  If not, 
it's due to administrator/operator changes, most likely the unsuppported 
upgrade. If it _does_ show the same wonkiness, to me that still 
indicates some sort of physical hardware/connectivity issue that might 
not be handled properly, because the problem you're reporting is hardly 
widespread -- these days they're cranking out something like a million 
of these things every month.

> I've reported it, it falls on deaf ears so not much I can do beyond that.

Reporting it is the bare minimum.  But it's all Free Software, so you 
could have tried to root-cause and fix the problem yourself -- but I 
understand that's often (usually?) not practical for most folks.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (libra.chat)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://mail.ale.org/pipermail/ale/attachments/20211013/567f104a/attachment.sig>