[rhelv6-list] LDAP without the cruft

[Bryan J Smith]

On Fri, Jul 19, 2013 at 10:43 AM, William Hopkins <we.hopkins at gmail.com>wrote:

> I pretty much discount anyone who uses "gasp" as a rhetorical device.


It's not rhetorical, it's literal.  ;)

I.e., I've heard a few when I showed people it at work (did a LUG
presentation a few months back to a not-so-Red-Hat-loving group).  That's
when and why I use the word "gasp" in a phrase.  It's when people have that
"epiphany" they didn't recognize before, until they saw it first-hand, and
then it clicked.  That usually changes their view rather quickly, and
better than anything I could say.

First-hand experience with someone familiar always change everything.

People can argue meta -- from not liking a saracasm to just disliking an
individual maintainer -- but that does nothing.  In fact, one of my
favorite, recent retorts to such was made by one of the Arch maintainers.
[1]  But until people actually get into the technical meat, and reflect on
actual history and not assumption, then we can move forward.

Technologists want to debate on technical merits, not meta-ones or
assumptions.  It's difficult to deal with assumptions and unfamiliarity.
 And the common complaints are they are for X and not Y as well as not
being UNIX/Linux-like.  But until people adopt them and understand the
improvements, they will never see this.

But at least the UNIX/Linux world changes on decades, instead of years
(Microsoft) and even sometimes just months (Google).  ;)

You're also pretty naïve if you think whatever you're talking about will be
> the silver
> bullet for standarization.
>

I never argued "standardization."

I only argued what customers have been asking for, first-hand, on-site ...
for servers, not desktops.  Arch, SuSE and many others are adopting the new
*d solutions as well.  There are technical reasons why, and not just
conformity.

This is a good point. Shame that things like nss-pam-ldapd will gain so much
> acceptance because they're fixing problems,  forcing others to live with
> the
> poor engineering decisions they've made.


Compliance and certification is a huge driver ... everything from
centralizing user/resource objects/attributes to signatures on DNS zones.
 Many legacy solutions are based on some of the exact same codebases, but
they are legacy.  And they have not adopted new interfaces that have been
in the system for years, so they are out-of-date.

A lot of times people complain about changing something, when it really
hasn't.  Some device control, message passing and other things might be
newer, but sockets, resources and others solutions are not, they *are* the
most legacy of UNIX/Linux.  We've just never implemented solutions over the
years to handle them proper ... until now.

I don't really enjoy the choice I'm presented with between outdated systems
> or new, poorly designed ones.
>

Again ... is "poorly designed" an argument made from usage?  Or
unfamiliarity?

I can understand the former, and completely respect it.  But if one has not
learned how to deploy the new solution, evaluated it fully, and seen what
happens when the older solutions don't address the needs of users, then it
makes a little more sense why the new solution came about.

Interesting community to highlight, given Ubuntu-ers are the laziest linux
> users anywhere. I don't begrudge them their pretty and automatic 'don't
> think
> about it' interfaces, but I will resist any efforts to bring them to the
> server
> world.
>

I won't argue with you about the typical "Ubuntu fanboy" that overstates
all sorts of "innovations" that were in Fedora first and (c) Red Hat.
 There's always going to be a backlash against such individuals because
their pulling over the "marketing trash" from the traditional, commercial
software world ... and I left for a reason.

However, commercial Canonical and Ubuntu LTS users and administrators are
some of the most capable sysadmins (and several know Red Hat too).
 Several, including one of my favorite colleagues works for Canonical, are
extremely knowledgeable, and recognize Fedora/Red Hat developments for
their merit.  So I was merely pointing out that the new stacks and modular
solutions -- which use some of the same codebase as old stuff, just with
more capability and newer libraries -- is being adopted out of merit.

Merit is what is the foundation of Fedora and Red Hat.  It always has been.
 It always will be.  And if anything, Red Hat has had a history of changing
things where everyone "rides the coattails" and forgets 3-5 years down the
road and
"conveniently forget" they were complaining in the first place.  E.g.,
GLibC (threading), ANSI C++ (long-term ABI), NPTL (Watson anyone?), etc...

"people complained before and were wrong.. they must be wrong now"
>

People have been complaining about a lot of Red Hat things, typically
several big ones per year.


> I'm not afraid of change. I am arguing that these systems are poorly
> designed
> and make system administration more difficult. I do not need to run SSSD,
> NSLCD, NSCD, D-BUS, upower, udisks, etc. etc. etc. just to have a vanilla
> system.


Again, unfamiliarity.

E.g., SSSD and NSCD do _not_ work together, and NSCD should _not_ be used
with SSSD.  ;)

SSSD's caching is designed to be a more deterministic superset of NSCD (and
even Winbindd caching for that matter).  It works extremely well and has
solved several problems at many sites I've been at.  SSSD itself is really
just a modular system with a superset of updated libraries and
capabilities, along with a single point of caching/control.

I've also deployed SSSD and when I had problems, it's only because the site
configuration was not compliant with their own security policies.

E.g., before, older solutions would blindly not do certificate checking and
various authentication, things required and poorly presumed to be working.
 With SSSD, you have to set flags not to, and it's very good at ensuring
compliance, while still being able to set an exception.

Once I document this at this one client, the IT department was ecstatic,
and loved SSSD from then on.  They learned the few option I taught them,
and never went back.


> Some systems are worse than others (gconf is especially a horror from
> the depths),


Again, many new solutions are not for desktop, but server.  The desktop
just ends up adopting some of the server components, with others that are
desktop-only (e.g., gconf).

but nonetheless the new method of running software to add layers

of abstraction that then become hard requirements because everyone assumes
> they'll be present is totally off base and disconnected from the open-world
> mentality of Linux.
>

I'm not going to convince you.  You're just going to have to learn and
evaluate the solutions and decide.  I know SSSD seems daunting, but it's
not.  And authconfig really does a great job.

I'm not surprised any longer that people in IT tend to be very bad at
> arguing;
> we all have big egos. But you should be aware that this sentence takes your
> conclusions as assumed fact, and paints anyone who disagrees as
> near-luddites
> afraid of change and unfamiliarity. It's pretty rude.
>

Well ... I apologize.  But I see a lot of meta-arguments combined with
unfamiliarity.

As I said, I think the Arch maintainer pegged it very well.  We no longer
focus on the technology, and real, customer and user needs why changes come
about.  We focus on the meta-arguments, alleged UNIX history, and even
demonization of individuals (not saying you did, but it's common in these
cases).

Best of luck, and if you ever need assistance with SSSD, IPA, the new *d
services, etc..., please feel free to ask.  Don't know if anyone will
convince you on the more "meta" arguments, but best of luck regardless of
what you deploy.

-- bjs

[1]
https://mailman.archlinux.org/pipermail/arch-dev-public/2012-August/023392.html

"we have a patch to make systemd optional at runtime, we request users to
test it, and instead of testing it we end up with a 300+ posts thread about
how bad Lennart is, with nearly no-one trying to investigate what is wrong
about the patch and in which situations it doesn't work."

Pretty much sums it up better than I ever could.

--
Bryan J Smith - Professional, Technical Annoyance
b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/rhelv6-list/attachments/20130719/1ccbfade/attachment.htm>