Ingo Wichmann <[email protected]> wrote:
> Am 10.11.2017 um 14:45 schrieb Bryan Smith:
>> Simply put, if i saw someone in 2017 using ifup/ifdown, I'd have to
>> warn them of the dangers of ever using those scripts.
>
> I'm with you here. But as log as Debian uses ifupdown in the default
> install, we can't remove it.
> We can point out ifupdowns shortcomings in trainings, but we have to
> cover it.
As a trainer, I utterly agree.
And beyond just being a trainer, when I was with "enablement" with a
major Linux vendor, I had to cover things ... saying ... "Never use
this any more. This is why ..." That wasn't just a suggestion, but
almost a requirement ...
To "de-program" people from old, but no longer useful, solutions they
knew or have heard of, or may even find in a Google search.**
But, for argument's sake, let's start there, as a very good
consideration for a 'reference baseline' ...
- Anything that is in a minimal install of Debian or Fedora may or
even should be covered
And definitely with ...
- Crucial subsystems ... like network
But even then there are still caveats ...
Does LPI cover everything that ships?
What if there are 2-3 options in a single distro's install, even a
minimal install?
Cover all of them?
Or just one?
What if one has deprecated another?
Replaced another?
This is the greatest difficulty LPI faces when it comes to objectives.
I, for one, am glad I'm not in the position of deciding this.
It's always easy to argue someone uses something, even legacy. You
can always find someone, even dozens of people in a sample of 100,
especially with older pages that Google still favors** -- who uses it.
But when that starts sprawling into dozens upon dozens of commands and
files and other support for a single objective? And some won't even
be available as they are deprecated ... today, even 5 years ago?
Inertia is difficult to fight. But that also begs the question ...
should LPI objectives cover what was used, and some still use ... or
what is being recommended by Upstream to replace things? Or both?
**SIDE NOTE: The #1 thing I recommend people supporting RHEL (or
Ubuntu LTS, not Ubuntu, for that matter) do is put in
"site:redhat.com" as Google answers not only lead people astray ...
but literally screw up Enterprise systems.
> Here is the difference to net-tools: net-tools has shortcomings and is
> no longer used in any relevant distribution during startup. So let's get
> rid of it.
That's one of the reasons why the ifup/ifdown scripts were segmented
from the net-tools package years ago, as it was originally included
with it in many distributions. But even as it's been hacked to
support "ip" and other developments, it still doesn't support a lot.
A good 5 years ago, even though Red Hat still shipped many things in
the legacy 'initscripts' package, and updated it to use various
subsystems. But it finally reached the point that Red Hat was hacking
in all sorts of support, and it's still a 'static' script that doesn't
handle most solutions. So it finally decided to remove it from the
minimal and even base installs. And 3.5 years ago, RHEL7 was released
with the same removal of them as Fedora in both the minimal and even
base installs.
And that's Red Hat, who has hacked up ifup/ifdown in initscripts, like
a lot of other things, to be as backward compatible as possible ...
far more than Debian. Red Hat deprecates and removes things when they
know things break other things. Other distros, even "Enterprise"
releases, aren't as anal. File systems are a perfect example where
Red Hat is extremely anal on support.
Debian has ifupdown2 trying to address various issues with ifupdown.
And even that has shortcomings.
My only concern -- and I'm not even thinking for LPI here -- is that
we -- collectively, as peers, as advocates, as trainers -- are setting
up new sysadmins up for failure.
> RHEL 5 is in "End of Production" since March 31, 2017, though it has
> "Extended Life-cycle Support" till 2020.
Yes, RHEL's standard 10 + 3 ELS years. Although for the "+3," Red Hat
also _drops_ support for about 1/3rd of the distribution during ELS.
A lot of legacy and desktop stuff is dropped.
But also keep in mind that Red Hat only supports enhancements the
first ~6 years. So RHEL5 stopped being developed in 2013, standard
earlier this year 2017, and ELS is through 2020.
RHEL6 is no longer developed after 2016 (already had 3 of my own RFEs
rejected), standard 2020, and ELS in 2023.
RHEL7 will be 2020, 2024 and 2027.
> General Support for SLES 11 ends in 31 Mar 2019,
> LTSS ends 2022.
I assume you mean LTS 16.04 there, which is actually 2021 (April, to
be specific), not quite 2022.
LTS 14.04 is 2019. LTS 12.04 was 2017 Spring ... although ESM is now
available for longer.
Canonical Advantage subscribers have access to an Extended Security
Maintenance (ESM).
> That's the oldest generation of supported linux distros today.
LPI had this same discussion regarding ReiserFS with SLES. ReiserFS
"support" (technically) is still in SLES 12 no less. But the
questions is always how well "maintained" it is, the userspace fsck as
much as the kernel implementation. And if you call SuSE AG for
support, will they?
> SLES 11 and CentOS both used ip instead of net-tools for startup.
Which CentOS? 5? 6? 7? Oh wait, it doesn't matter, even gone
CentOS 5 used "ip". ;)
> So there is no point in keeping net-tools. But one more reason to keep
> ifupdown for another 5 years.
So ... does LPI adopt this for everything?
- bjs
--
Bryan J Smith - http://www.linkedin.com/in/bjsmith
E-mail: b.j.smith at ieee.org or me at bjsmith.me
_______________________________________________
lpi-examdev mailing list
[email protected]
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
_______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
