[ldapext] RFC2307, netgroups, DBIS (was: LDAP work at IETF...)

"michael-catchall@mail.stroeder.local (POP3)" <michael@stroeder.com> Mon, 02 February 2015 18:21 UTC

Return-Path: <michael@stroeder.com>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9461A8866 for <ldapext@ietfa.amsl.com>; Mon, 2 Feb 2015 10:21:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.631
X-Spam-Level: *
X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jqqsg18402jk for <ldapext@ietfa.amsl.com>; Mon, 2 Feb 2015 10:21:21 -0800 (PST)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657841A8859 for <ldapext@ietf.org>; Mon, 2 Feb 2015 10:21:21 -0800 (PST)
Received: from srv4.stroeder.local (srv4.stroeder.local [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (not verified)) by srv1.stroeder.com (Postfix) with ESMTPS id C39A31D343; Mon, 2 Feb 2015 19:21:19 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by srv4.stroeder.local (Postfix) with ESMTP id 71BE11CFBB; Mon, 2 Feb 2015 19:21:19 +0100 (CET)
X-Virus-Scanned: amavisd-new at stroeder.local
Received: from srv4.stroeder.local ([127.0.0.1]) by localhost (srv4.stroeder.local [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIwHjx16nBXD; Mon, 2 Feb 2015 19:21:16 +0100 (CET)
Received: from nb2.stroeder.local (nb2.stroeder.local [10.1.1.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 0AD611DFED; Mon, 2 Feb 2015 19:21:09 +0100 (CET)
Message-ID: <54CF5178.7040406@stroeder.com>
Date: Mon, 02 Feb 2015 11:29:12 +0100
From: "michael-catchall@mail.stroeder.local (POP3)" <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 SeaMonkey/2.32
MIME-Version: 1.0
To: Mark R Bannister <dbis@proseconsulting.co.uk>
References: <etPan.54c553b0.19e21bb2.1f2@lpm.local> <54C77E7A.6010506@proseconsulting.co.uk> <54C7B32A.7050709@stroeder.com> <54C7FA23.7000101@proseconsulting.co.uk> <1422454472.32747.38.camel@ssimo.org> <54CEA9A4.1020709@proseconsulting.co.uk>
In-Reply-To: <54CEA9A4.1020709@proseconsulting.co.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/esmLMorn9kgUGhU-iYd-V8nojbQ>
Cc: ldapext@ietf.org
Subject: [ldapext] RFC2307, netgroups, DBIS (was: LDAP work at IETF...)
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Feb 2015 18:21:22 -0000

Mark R Bannister wrote:
> On 28/01/2015 14:14, Simo wrote:
>> It hurts me to curb enthusiasm, but I think your drafts are not a step
>> forward, at most a step sideways, and ignore what's out there right now.
> 
> Given that they were written to fix specific deficiencies in RFC2307bis
> that were causing pain in a number of very large enterprises I have worked
> for, I don't see how they could be considered a step sideways.

Maybe I did not look closely enough. Could you please point me to some text
describing the specific deficiencies you solved in more detail?

> When you say my drafts ignore what's out there right now, what are they
> ignoring?
> [..]
>> The software out there and now expect either RFC2307 or at most
>> RFC2307bis (and then really they just test against Active Directory's
>> schema and things happen to mostly work). Any other schema would just
>> fail to be useful for a generic LDAP server.
>
> To what software do you refer specifically?

I think like me Simo also meant the client side.

> NSS is a big subscriber, and I've addressed that one.  Then there is the
> automounter, and sudo, and really only a handful of others all of which can
> be fixed to use a more modern schema.
> 
> I'm not going to spend 18 months developing DBIS to be turned away because
> software
> doesn't support it.  Of course software doesn't support it - yet - it's new!

But the question is whether there's a solution which is compatible to existing
client-side software. I know you're working on PAM/NSS clients but the
question is whether you can install that on legacy Unices or strange applicances.

My approach is to lower the configuration level the client has to support by
filtering what's delivered to the client at the LDAP server.

Ciao, Michael.