On Wed, Nov 21, 2007 at 04:53:47PM +0000, Darren J Moffat wrote:
> 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.
Then we'll ship them there.
> >>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 ?
Any default attribute names that we picked would be completely
arbitrary and are not likely to match usage on the field (about which we
do not have enough information, thus we don't know what attribute names
users use most commonly -- users have had to pick them arbitrarily
also).
> >>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 ?
It can still provide ephemeral mapping and name-based mapping rules.
Suppose there are no name-based mapping rules: idmapd can still map SIDs
to ephemeral UIDs and GIDs. Later, when the sysadmin notices the
problem they can fix ds-name mapping, refresh the service and now the
old ephemeral IDs will still map to the SIDs that were previously mapped
ephemerally but some or all of those SIDs may now map to non-ephemeral
UIDs and GIDs.
OTOH, putting the service in maintenance would be a much more obvious
indication of trouble. We'll make this change then.
> >>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 ?
If you delete the property then you won't be able to see it :)
> 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.
Right, it's just a property name. We'll take your advice if you insist,
but I don't agree that it's redundant.
Nico
--
