Re: Permanent Use of IPv4
On Fri, Feb 15, 2019 at 11:17:06AM -0500, Felix Miata wrote:
> Reco composed on 2019-02-15 19:02 (UTC+0300):
> > On Fri, Feb 15, 2019 at 10:55:23AM -0500, Felix Miata wrote:
> >> To me, "on boot" implies something on the kernel cmdline, e.g.:
> >> ipv6.disable=1
> > And by doing *this* you're risking breaking systemd and the overall
> > boot process.
> > Yep, the thing's written that way - it *expects* (some can say 'forces')
> > you to have IPv6.
> I made ipv6.disable=1 a standard option here at least as far back as 2011. If it ever caused a
> problem I never found out about it.
That's a fine example of "works for me" approach.
And I've seen multiple cases where "disable IPv6" equaled "non-booting
> > Hence this BSD-style "safe hack". Do not touch "base system" (systemd in
> > this case), but implement assorted kludges around it.
> I don't understand this "BSD-style" or "safe hack" or the whole next sentence.
Why systemd was opposed by some? Because it utilizes BSD approach of
providing you with so-called "base system", every single component of
which is somewhat lacking, compared to specialized software.
To name a few systemd examples, automounting facility, journaling
facility, network configuration, console configuration, DNS resolution
facility, DHCP server, DHCP client, RA server, NTP client.
Oh, there's also a parody for HTTP server, but they disable *that* in
Debian by default.
In BSD world, you cannot exclude any component of a "base system" from
your OS, unless you resort to removing files or recompiling.
Likewise, you cannot remove certain components of systemd, see above for
the non-complete list (unless you remove certain files, that is).
You can install certain software which *can* make those tasks better,
and even use such software, but an appropriate component of "base
system" still will be there. Waiting.
A "safe hack" is a bypass of certain "base system" component (in this
case, IPv6 addresses assignment), which does not compromise the ability
of the OS to boot, but renders the desired outcome (in this case -
Why it is safe - because systemd configures NICs first, starts services
next, and then applies kernel knobs (aka sysctl).