> >>> PHASED DELIVERY
> >>> ---------------
> >>> Due to time pressures we request to deliver in up to three phases:
> >>>
> >>> - AD-only mode (likely to integrate first)
> >>>
> >>> - Native LDAP-only and Mixed modes (because of required modifications
> >>> to libsldap)
> >>>
> >>> - Administrative idmap(1M) sub-commands (likely to integrate last; the
> >>> Sun internal consumer that requested directory-based mappings needs
> >>> the feature more than the new idmap(1M) sub-commands)
> >>>
> >>>
> >> In the OpenSolaris context, I wouldn't think that the community would
> >> be very empathetic to this rationale. Is this project complete?
> >>
> >
> > I don't follow this. How does OpenSolaris make any difference here vs.
> > pre-OpenSolaris days?
> >
> The proposed phasing is to accommodate Sun's internal
> needs/dependencies. Why
> should OpenSolaris be subject to a phased integration, particularly when
> the project
> doesn't seem to be complete in the initial phases.
Sun's internal issues are not architectural here. IMO,
the question is is the project complete with AD-only mode
and no idmap sub-commands. If it's judged not to be complete,
then how do we make it complete? Is it sufficient to document
how to talk to AD with the local ldap client interfaces?
Afterall the AD admin needs to configure the AD Schema (if
not already present) and the Solaris admin has to configure
the the SMF properties. Would we really expect the Solaris
admin to then configure the mappings, or would we expect either
that the AD admin has a preexisting set of mappings or would
configure them on AD? It seems to me if the operational model
is that the configuration (except for the properties) is done
on AD, then documentation needs to be supplied by the project
team to accommodate that and the project is complete in phase
1. If on the other hadn the operational model is that the
Solaris admin does the mappings, then I'm concerned that
native ldap commands are sufficiently intuative to use.
Gary..
