Well said and I agree. When I suggested to Taki some years ago to add some basic SQL stuff to LPI1 it was because I think of LPI1 as a junior systems management role. More than only OS but also some basic knowledge of day to day operations. Definitely not a DBA role, but being able to install an application, LAMP or otherwise, should be one iof his day to day duties.
Kind regards, Jeroen Baten Op 12-10-17 om 05:55 schreef Bryan Smith: > 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 > lpi-examdev@lpi.org > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev > -- Jeroen Baten | EMAIL : jba...@i2rs.nl ____ _ __ | web : www.i2rs.nl | )|_)(_ | tel : +31 (0)345 - 75 26 28 _|_/_| \__) | Molenwindsingel 46, 4105 HK, Culemborg, the Netherlands _______________________________________________ lpi-examdev mailing list lpi-examdev@lpi.org http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
