Re: [ldapext] RFC2307, netgroups, DBIS
Mark R Bannister <dbis@proseconsulting.co.uk> Wed, 04 February 2015 21:55 UTC
Return-Path: <dbis@proseconsulting.co.uk>
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 EE3191A89AC for <ldapext@ietfa.amsl.com>; Wed, 4 Feb 2015 13:55:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham
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 0ShSl7z53-Rf for <ldapext@ietfa.amsl.com>; Wed, 4 Feb 2015 13:55:50 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 398C81A8997 for <ldapext@ietf.org>; Wed, 4 Feb 2015 13:55:47 -0800 (PST)
Received: from host86-178-119-74.range86-178.btcentralplus.com ([86.178.119.74] helo=[192.168.1.67]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <dbis@proseconsulting.co.uk>) id 1YJ7vG-0006uJ-Dp; Wed, 04 Feb 2015 21:55:46 +0000
Message-ID: <54D2955E.3010608@proseconsulting.co.uk>
Date: Wed, 04 Feb 2015 21:55:42 +0000
From: Mark R Bannister <dbis@proseconsulting.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "michael-catchall@mail.stroeder.local (POP3)" <michael@stroeder.com>
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> <54CF5178.7040406@stroeder.com>
In-Reply-To: <54CF5178.7040406@stroeder.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailcore-Auth: 12040446
X-Mailcore-Domain: 1286164
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/yMpMuLnCSOixXuYnqfYpempDAZs>
Cc: ldapext@ietf.org
Subject: Re: [ldapext] RFC2307, netgroups, DBIS
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: Wed, 04 Feb 2015 21:55:52 -0000
On 02/02/2015 10:29, michael-catchall@mail.stroeder.local (POP3) wrote: > 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? Have at look at the abstract on page 2 of http://www.ietf.org/id/draft-bannister-dbis-mapping-06.txt. One of the first biggest requirements was reintroducing case sensitivity in a way that would be fully compatible with NIS, see the description of the en (4.2) and rn (4.3) attributes in particular. Also, another requirement was to fix the schema so that duplicate alias names could be easily detected and prevented (1.2). > >> 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. Ok, well I'm working on fixing that already. > >> 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. Legacy unices ... depends how old we're talking. I currently have something that works on RHEL4.8 and newer, and the large organisations I have spent most of my time with over the past 5 years are at a point where RHEL4.8 is their oldest legacy now. Strange appliances - not unless I can get the vendor to add support for DBIS. However, even the appliances I've worked with support local class & attribute remapping rules, so could be tuned to fit DBIS, or vice versa with the DBIS configuration maps (http://sourceforge.net/p/dbis/wiki/ConfigurationMaps-RFC2307/) > > 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. > > By filtering, you mean just removing entries from maps? But you still have an old schema to support that wasn't fully NIS compatible to begin with ... Mark.
- Re: [ldapext] LDAP work at IETF... Michael Ströder
- [ldapext] LDAP work at IETF... Ludovic Poitou
- Re: [ldapext] LDAP work at IETF... Gavin Henry
- Re: [ldapext] LDAP work at IETF... Michael Ströder
- Re: [ldapext] LDAP work at IETF... Clément OUDOT
- Re: [ldapext] LDAP work at IETF... Michael Ströder
- Re: [ldapext] LDAP work at IETF... Andrew Findlay
- Re: [ldapext] LDAP work at IETF... Michael Ströder
- Re: [ldapext] LDAP work at IETF... Mark R Bannister
- Re: [ldapext] LDAP work at IETF... Michael Ströder
- Re: [ldapext] LDAP work at IETF... Mark R Bannister
- Re: [ldapext] LDAP work at IETF... Michael Ströder
- Re: [ldapext] LDAP work at IETF... Mark R Bannister
- Re: [ldapext] LDAP work at IETF... Michael Ströder
- Re: [ldapext] LDAP work at IETF... Mark R Bannister
- Re: [ldapext] LDAP work at IETF... Mark R Bannister
- [ldapext] RFC2307, netgroups, DBIS (was: LDAP wor… michael-catchall@mail.stroeder.local (POP3)
- [ldapext] RFC2307, netgroups, DBIS (was: LDAP wor… michael-catchall@mail.stroeder.local (POP3)
- Re: [ldapext] RFC2307, netgroups, DBIS Mark R Bannister
- Re: [ldapext] RFC2307, netgroups, DBIS Mark R Bannister
- Re: [ldapext] RFC2307, netgroups, DBIS Michael Ströder
- Re: [ldapext] RFC2307, netgroups, DBIS Michael Ströder
- Re: [ldapext] LDAP work at IETF... Clément OUDOT
- Re: [ldapext] LDAP work at IETF... Ludovic Poitou
- Re: [ldapext] RFC2307, netgroups, DBIS Mark R Bannister
- Re: [ldapext] RFC2307, netgroups, DBIS Mark R Bannister
- Re: [ldapext] RFC2307, netgroups, DBIS Michael Ströder
- Re: [ldapext] RFC2307, netgroups, DBIS Michael Ströder
- Re: [ldapext] LDAP work at IETF... Barry Leiba
- Re: [ldapext] LDAP work at IETF... Barry Leiba
- Re: [ldapext] LDAP work at IETF... Michael Ströder
- Re: [ldapext] LDAP work at IETF... Ludovic Poitou