Re: [ldapext] RFC2307, netgroups, DBIS

Mark R Bannister <> Wed, 04 February 2015 21:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EE3191A89AC for <>; Wed, 4 Feb 2015 13:55:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0ShSl7z53-Rf for <>; Wed, 4 Feb 2015 13:55:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 398C81A8997 for <>; Wed, 4 Feb 2015 13:55:47 -0800 (PST)
Received: from ([] helo=[]) by with esmtpa (Exim 4.71) (envelope-from <>) id 1YJ7vG-0006uJ-Dp; Wed, 04 Feb 2015 21:55:46 +0000
Message-ID: <>
Date: Wed, 04 Feb 2015 21:55:42 +0000
From: Mark R Bannister <>
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)" <>
References: <etPan.54c553b0.19e21bb2.1f2@lpm.local> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailcore-Auth: 12040446
X-Mailcore-Domain: 1286164
Archived-At: <>
Subject: Re: [ldapext] RFC2307, netgroups, DBIS
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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  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 

> 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 ...