On Fri, Jul 17, 2009 at 09:58:19AM +0100, Darren J Moffat wrote: > Jordan Brown wrote: > > config/ds_name_mapping_enabled > > > > Enable/disable directory-based name mapping. Note that if > > this and config/idmu_enabled are both set to "true", this > > value is ignored. > > > > config/idmu_enabled > > > > Enables support for Microsoft Identity Management for UNIX > > (IDMU). This Windows component allows the administrator to > > specify a UNIX user ID for each Windows user, mapping the > > Windows identity to the corresponding UNIX identity. > > Only IDMU data from the domain the Solaris system is a member > > of is used. > > Seems perfectly reasonable to me. > > If condif/ds_name_mapping_enabled didn't already exist I would have > suggested a config options system that didn't allow the user to so > easily enable both options but given the existing precendent this case > is fine as specified.
Ideally we would have a way to validate this sort of rule (mutually exclusive properties) when configuration is edited. Right now that would be svccfg(1M), which, even with Extended SMF Templates, will not provide support for mutually exclusive props. We could, and should instead move all idmap configuration tasks from svccfg(1M) to idmap(1M). But that's not this case. Until a case comes along to move idmap configuration to idmap(1M) I believe that it would be best for the idmap service to go into maintenance in the face of incorrect configuration. This will allow configuration errors to be detected sooner (at service refresh time), and most likely by the administrator that made the config changes. What the i-team proposes (ignoring parts of conflicting configuration), seems to me like asking for trouble: when in a much later update the service adds support for up-till-then unsupported configuration, the system's behavior could change quite unexpectedly. Putting the service into maintenance instead is easy to implement, and, IMO more user friendly in the absence of the ideal solution (see above). Nico --
