Quoth Nicolas Williams on Fri, Jun 27, 2008 at 12:02:33PM -0500: > Background: We have a need for common storage of various configuration > properties relating to Active Directory domains (but not > necessarily only AD domains). System components that need > to access this include: > > - the CIFS server > - the ID mapping service (svc:/system/idmap) > - nss_ad (AD name service backend for name service switch) > - possibly the CIFS client > - possibly other components in the future (imagine if we > had something like ADSI -AD scripting interface- for > Solaris)
I think the current model is ill suited to storing configuration which affects behavior of such disparate components. In particular, the model and the tools are oriented around a service instance representing the implementation of some set of input/output behavior, and that behavior being configured by the properties associated with the service instance. > One possibility that occurred to me: > > svc:/domain/<domain-type>/<leftmost-label>/../<rightmost-label>:default > > For example, properties for the AD domain 'foo.bar.example' would be > stored in 'svc:/domain/ad/foo/bar/example:default'. This service instance would have no implementation associated with it, correct? And the behavior its properties affect are represented by other services, right? Would the state of this service have any meaning? > Problems: > > 1) Wouldn't it be nice to be able to use actual domain names instead of > having to replace '.' with '/'? > > I.e., 'svc:/domain/ad/foo.bar.example:default' reads a lot better > than 'svc:/domain/ad/foo/bar/example:default'. I think this belies the fact that the SCF model is around objects which are already named (as in software products) and objects which implement a named standard. It's not clear to me that the naming rules should be changed to permit service & instance objects to be named after domains. Do you think this would have any impact on user acceptance or usability of SMF? > 2) What about internationalized domain names? Would internationalized domain names be a problem if they were included in property names? Or as the value of a property in a property group which represents the domain? > 3) Consider http://blogs.sun.com/nico/entry/can_we_map_ids_between > > We may someday want to assign locally-generated SID prefixes to > non-AD domains. Such SID prefixes would have to be unique. How can > we make SMF enforce this? And if we can't, can we live with that? What is a non-AD domain? By "mak[ing] SMF enforce this", do you mean that if a client attempts to create a service or instance with a particular name, SCF should use AD rules to permit or reject it? If so, it seems awfully specific to your application. I think you'd have to argue that this would benefit a large portion of services. > If we store them in the domain's svc FMRI then we can't enforce > uniqueness. Even if we store them in svc:/domain/<domain-type> in a > multi-valued property we still lack a way to enforce uniqueness. I think you're asking for hooks though which services can reject configuration changes. If so, please file an RFE. David
