2007/663 Winchester directory-based name mapping [FastTrack timeout 11/30/2007]

Darren J Moffat Darren.Moffat at sun.com
Wed Nov 21 08:53:47 PST 2007


Nicolas Williams wrote:
> On Wed, Nov 21, 2007 at 10:52:03AM +0000, Darren J Moffat wrote:
>> If I'm understanding this case correctly there are NO new LDAP schema 
>> needed for any of the modes, but using one is allowed.
> 
> No, schema extensions are required for all modes.
> 
>> Will the LDIF files be shipped as part of Solaris if so where ? (Hint: 
>> /usr/share/lib/ldif would be a good place), even as examples it would be 
>> nice.
> 
> We certainly could.  Our intention had been to have them in the
> docs.sun.com guide book only.

We made that mistake with the RBAC Schema and avoided it in 
PSARC/2006/277 (Kerberos records in LDAP) that case also created 
/usr/share/lib/ldif/ and basically set precedence that that is where 
they go.

>> Is there a reason why default values for the {nldap,ad}_*_attr 
>> properties can't be defined ?  I would have thought there might be some 
>> reasonable default that could be selected based on the normal schema in 
>> use with AD or NLDAP is that not the case ?
> 
> We're following others' lead in the market.

Why can't we be better ?

>> What is the default value for config/ds_name_mapping_enabled ?  I think 
>> it is false but I couldn't find it explicitly mentioned in the proposal. 
> 
> It has to be false since values for some of the other properties have to
> be provided before idmapd can perform ds name mapping.

I thought so.

>> What is the behaiour if config/ds_name_mapping_enabled is set to true 
>> and none of the _attr properties have a value ?
> 
> A message will be logged to LOG_WARN and the feature will remain
> disabled.

But the service won't go into maintenance mode, even though it is 
clearly misconfigured ?

>> Isn't the _enabled suffix redundant since this property is of type boolean ?
> 
> Hmmm, I don't think so -- users looking at the property name alone
> wouldn't know its type.

How would you be looking at it and not see it's type ?
svcprop(1) shows you the property and so does the svccfg(1) listprop sub 
command.  It isn't a big issue it just looked redundant to me.


-- 
Darren J Moffat



More information about the opensolaris-arc mailing list