Your points have not convinced about the level of deployment of the IPA
solution but your passions is undeniable. My opinions still stands the
exams objectives and weightings should reflect what administrators come
across in their day-to-day work. How this can be controversial I do not
understand.   I guess we will wait for others to give us their insights
and opinions on this matter and be guided by them.


On 22/09/2016 10:58, Bryan Smith wrote:
> On Thu, Sep 22, 2016 at 1:00 AM, Mark Clarke <m...@jumpingbean.co.za
> <mailto:m...@jumpingbean.co.za>> wrote:
>
>     I get it you think IPA is the best technology ever
>
>
> Thank you for justifying why someone like myself is around.  ;)
>
> Again, re-quoting myself ...
>
>     o  Short version ...
>
>   SSSD support of Policy Objects is well proliferated.
>
>     o  In bullets ...
>
>   _If_ we are going to include 'Policy Objects' ...
>    - Start with the IPA ones, specifically where ...
>    - SSSD**, w/o IPA, supports them so not only ...
>    - All Linux distros** support them, but ...
>    - Any LDAP server (OpenLDAP, 389, etc... ) does too
>
> The _context_ of my _entire_ response has been under "Policy Objects,"
> after someone suggested coverage of "GPO" (Group Policy Objects).
>
>     and everybody else is ignorant for not adopting it sooner
>
>
> No, again, re-quoting myself ...
>
>     o  Case-in-point ...
>
>   **This assumption is the the most frustrating reality I
>     deal with day-in, day out:
>      "the only distro that supports it is Fedora,
>       and is largely unsupported in the rest of them.
>       Seems like a distro specific feature?"
>
> I do a _lot_ of Debian and Ubuntu as well.  It has SSSD, so it can
> support Policy Objects as well.  Newer Debian builds even have IPA,
> including the Server portion, thanx to the hard work of one Canonical
> employee.  But he's not well served by even Ubuntu users because of
> things said ... exactly what you're saying here.
>
> Furthermore, you also said ...
>
>   "I wouldn't say NSS/389/Dogtag has
>    been widely adopted outside RedHat yet
>    it very well might be an emerging technology
>    but its not something every sys admin needs
>    to know. If its included  at an "awareness level"
>    then ok - but until it gets wide spread adoption,
>    and mind share, I can't agree that it should be
>    covered in any more details. To be frank I think
>    there the coverage in 303 is overboard."
>
> This ^^^ is an example of ignorance.
>
> It's like saying, _literally_, Mozilla Firefox is an "emerging
> technology" in browsers.  Because just like some of the NCSA team, a
> lot of the Michigan LDAP team directly created the code lineage!  It's
> not only in _major_ installations, but with Oracle dropping support
> this decade, it's become the defacto standard.
>
>     but I don't think the purpose of LPI is to push what we think 
>
>     is the next big thing but to see what is actually out there in use.
>
>
> You mean no one uses SSSD, 389/Dogtag, et al., and that lineage,
> right?  It's an "emerging technology" that no one uses, right?
>
> So those Policy Objects are useless.  No one uses them.  No one
> manages anything.  So we shouldn't look at what 389 does, and
> especially not IPA.
>
>     From you own anecdotal evidence
>
>
> Oooookkkkaaaaayyyy, my "ancedotal evidence."
>
>     of the use of IPA it is a technology that may be in the process of 
>
>     being slowly adopted.
>
>
> Again, I'll requote myself ...
>
>     o  Short version ...
>
>   SSSD support of Policy Objects is well proliferated.
>
>     o  In bullets ...
>
>   _If_ we are going to include 'Policy Objects' ...
>    - Start with the IPA ones, specifically where ...
>    - SSSD**, w/o IPA, supports them so not only ...
>    - All Linux distros** support them, but ...
>    - Any LDAP server (OpenLDAP, 389, etc... ) does too
>
> The _context_ of my _entire_ response has been under "Policy Objects,"
> after someone suggested coverage of "GPO" (Group Policy Objects).
>
>     So is BTRFS, ZFS,
>
>
> Well, ZFS, at least from Oracle.  It gets weird outside of Oracle. 
> But that's anoterhs tory.
>
>     Linux capabilities, name spaces etc.
>
>
> Nope.  I don't know anything about modern DevOps with CloudFoundry,
> OpenShift, et al.
>  
>
>     If it use continues to grow we have a process to review the level
>     of coverage - and if something else ends up replacing it then we
>     can swap it out.  
>
>     There are plenty of technologies people are passionate about but
>     have not yet been widely adopted
>
>
> Well, all I have is my "ancedotal evidence."  Not that I'm here to
> actually talk about what corporate are using.  I mean, I'm Mr.
> "ancedotal evidence."  I'm just passionate, and have no basis for what
> I say.  Yep.
>  
>
>     - I don't see people using LPI objectives to push these agendas.
>     Upstart/Systemd is a case in point.
>
>
> Nope.  Corporations don't use SMF under Solaris, and don't expect
> equivalent service management under Linux (e.g., Upstart), much more
> dynamic service, resource and system state capabilities (e.g., the
> *d/*ctl solutions).  The latter isn't required for dynamic, software
> defined networking (SDN) and storage (SDS) in things libvirt, such as
> for things like OpenStack.   Nope.
>
> I'm just a passionate guy.  Have nothing to do with leading any
> professional services or enablement at anyone pushing Debian and
> Fedora-based distros, integrating some of the first or largest
> installations int he past, or writing any of the first sets of
> documentation.
>
> Don't listen to me.  I'm a guy that is only passionate about
> Fedora-only stuff.  ;)
>
>
> -- 
> Bryan J Smith  -  http://www.linkedin.com/in/bjsmith
> E-mail:  b.j.smith at ieee.org <http://ieee.org>  or  me at bjsmith.me
> <http://bjsmith.me>
>
>
> _______________________________________________
> lpi-examdev mailing list
> lpi-examdev@lpi.org
> http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev

-- 



--
Mark Clarke
📱  +2711-781 8014
�  www.JumpingBean.co.za

_______________________________________________
lpi-examdev mailing list
lpi-examdev@lpi.org
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev

Reply via email to