DISCLAIMER: _Any posts by myself on lpi-examdev are as a peer among
peers, and are only designed to provoke considerations, and should not
be taken as an endorsement or anything other than simple, individual,
professional consideration for further discussion._
Alessandro Selli wrote:
> Simone Piccardi wrote:
>> I propose the removal of topic 105.3: "SQL data management" because it
>> has nothing to do with Linux.
>> It's true that knowing about SQL basis is needed for a sysadmin, like
>> knowing about switching loops. For both I just don't think they are
>> topics for a Linux specific certification.
>
> I agree. The response I get from people attending LPIC-2 related classes
> is regularly of surprise if not amazement when SQL is introduced.
> It is true that Apache (LPI-202) too is not specifically a Linux OS
> component, but it's relationship to Linux is stronger, and the main use of
> SQL engines is together with a web server and a dinamic http content
> generator language like PHP; why then not putting PHP too into the basket?
> Well, because LPI is an OS certification, not a webmaster certification.
In my view, when considering any revision of LPI objectives for
2018-2019, we need to be asking ourselves this question ...
"What is the sysadmin of the 2020s doing day-in, day-out?"
E.g., and this is purposely a bit argumentative, but I'll make it as a
good example ...
In the 2020s, is there really such a concept of a "webmaster" any more?
We're looking at an entire merger of many technologies, from Java and
Application Stacks, including vertically packaged applications in
things like Containers, to the end-game of full DevOps in total
deployment and life cycle.
E.g., an argument in favor of removing things like SQL would be ...
"A sysadmin needs to learn more about application services than
database services, in 2020."
And more 'gray" would be ...
"A sysadmin needs to learn more about supporting language and database
bindings and clients, than any language or database synatx."
If you're seeing a repeat theme here, it's the change we're in the
middle of. The definitions of technologies themselves, in what
sysadmins do and use, have changed in just a decade.
It's no longer about just SQL or PHP or other things. It's about
provisioning and deployment, scalability and sizing, platform life
cycle tied in with application life cycle, etc... The traditional
sysadmin has changed more in just the past 5 years than in 25 years
prior.
So maybe it starts by stepping back and saying, "After user-level and
OS-level, generic POSIX (UNIX/Linux) concepts, we're only going to
cover provisioning and deployment, but nothing beyond." After that,
we can start to look at how everything is changing.
E.g., at some point one has to start considering if Docker and
Kubernetes, even basic version control like Git and related support,
is as essential as, say, APT-DPKG and DNF/YUM-RPM.
Again ... in the 2020s.
> Then also email servers (LPI-202), LDAP (LPI-202) and proxy servers
> (LPI-202) are not Linux-specific, but they are more general tools than SQL
> engines and are more strongly related to the OS: sendmail and mail
> commands are almost as old tools as Unix, sendmail is a Unix
> requirement too, LDAP can be selected as a user authentication backend,
> perhaps proxy server are more like SQL: a useful tool indeed, but not
> strongly related to Linux.
Technical Nitpick: LDAP isn't primarily used for authentication.
Deeper Discussion ...
LDAP authentication is usually the far less used implementation, as
it's just centralized hashes. Kerberos or another, GSSAPI compatible
solution is preferred, if not integrated (e.g., IPA aka Enterprise
IdM), for authentication (and even authorization / Roles).
It's actually LDAP's centralized, network-wide authority of POSIX
(UNIX/Linux) attributes (typically IETF RFC2307) that is its primary
purpose.
I.e.., You're going to find a lot of sysadmins who have worked in an
enterprise environment that always setup systems to use some sort of
centralized, network-wide authority via LDAP -- a means to have
network wide-defined objects in a tree (or set of trees) that is the
authority.
Under some security standards (Financial, US Federal, etc...), it is a
security finding not to have a network-wide, authoritative,
centralized object store, instead of locally defined and/or
enumerated.
E.g., Common Security Finding ...
A locally enumerated UID/GID from, say, AD SIDs with Winbind (or SSSD
in a similar most), a lot of the 'free' tools (e.g., Centrify, Quest,
et al.), etc... is a security finding. There is a requirement that
those UIDs/GIDs, along with homedir, shell and other POSIX
(UNIX/Linux) attributes (e.g., IETF RFC2307) -- which cannot be
enumerated locally -- be defined and standardized in a centralized
repository.
Hence the common use of LDAP, whether ...
- AD w/Identity Management for UNIX (IDMU) -- thru 2012R2+ **
- LDAP: OpenLDAP, 389 (aka RHDS), et al.
or ...
- IPA (aka Enterprise IdM), although the services hasn't been well
ported (because most other platforms than Fedora-based are still
integrating the 389 stack, having ignored it for the past decade and
sticking with OpenLDAP)
Common Industry Standard: All other LInux and UNIX tests I've ever
take include a basic configuration of some tool that sets up NSS, PAM,
etc... so they can reference network objects via LDAP.
E.g., under Linux, replacing many of the legacy (and poorly
maintained) PAM and other components, the System Security Services
Daemon (SSSD) is a modular system of different providers for different
facilities (e.g., NSS, PAM, etc...), and is considered the equivalent
to Windows' Local Security Authority (LSA) and its modules equivalent
Security Service Providers (SSPs).
NOTE: A common misconception is that SSSD requires IPA. IPA requires
SSSD, but SSSD functions without IPA, and can connect to many things.
E.g., one of SSSD's first components was to support connecting to and
reading AD-IDMU's POSIX (UNIX/Linux) attributes (IETF RFC2307 support
in AD).
**AD-IDMU has been deprecated in 2012R2 and removed in 2016. The main
reason was because Microsoft found only 1-2% of Windows admins were
populating those POSIX attributes. Microsoft now recommends either
buying a proprietary connector (w/typically costly, CALs), or
implementing [open source] IPA with its AD-Forest Trust model (keeping
schema separate -- just like an External AD Forest), for AD
exchange/support.
> Maybe SQL too should be moved to LPI-202?
It really all depends what people define as "sysadmin" for the 2020s.
I have my views, but I won't share them. I'd rather point out the
change in the "sysadmin" role over the past 5 years, as well as other
things (e.g., LDAP usage), and let others decide.
--
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
