On Mon, Nov 26, 2007 at 04:09:37PM -1000, Joseph Kowalski wrote: > Gary Winiger wrote: > >I'm sponsoring this fast track for Nico Williams and the Winchester > >project team. It adds another mapping style to the existing > >Winchester project. The added interfaces request a Uncommitted > >taxonomy which matches the existing Winchester taxonomy. > >The case requests a Patch release binding (though a backport is not > >currently planned). > > > Jim and Darren seem to have already expressed concern about "can't we do > better"? This does seem to follow some other vendor's half-baked > implementation.
I believe we've addressed Darren's issue to his satisfaction, I'll answer your and James' questions below. > This discussion seems to have been interrupted by the break - I hope the > discussion continues. Indeed, it has been. There are good reasons why we must allow the attribute names to be configurable and why we cannot provide default attribute names. Namely: - Consider a customer with multiple NIS domains with similar, but not quite the same content. This happens a lot in real life (we have one customer with some 30 such domains). Now, if you're mapping Windows users to Unix users, but the usernames for Joe Random are different in several NIS domains... well, then if we don't allow the attribute names to be configurable then such a customer could not cope. - We could pick default attribute names, but a) if our defaults are incorrect for some customer then enabling the feature would be sufficient to get the idmap service to come online, but insufficient to function correctly, and b) we're not likely to pick good defaults, both because of the user's potential need for multiple sets of attributes (see above) and because of the existing deployments where users had to pick arbitrary attribute names. To provide default attribute values would mean negating the value of the advice that Darren gave us (to put the service in maintenance if ds-based mapping is enabled but the necessary attribute names are not configured). > > - Mixed mode > > > > When mapping a Windows SID to a UID/GID idmapd will use the > > procedure described above for AD-only mode. > > > > When mapping a UID/GID to a SID, idmapd will use the procedure > > described above for Native-LDAP-only mode. > > > Just for my information, why would somebody used Mixed mode? Because it allows you to have asymetry in mapping. E.g., you can map multiple Windows users to one Unix user and vice versa. We already support this now via name-based mapping rules (see the -d option of the idmap(1M) add sub-command -- -d stands for 'directional'). > >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? > Specifically, it seems that any proposed phasing which implements a > feature without the fully supported administrative tools just seems > wrong. I don't see an issue with the ordering/separation of the > modes, but the tools must be there with the first integration. There exist tools already, namely ldapmodify(1) and a variety of directory browser applications. Nico --
