On Mon, Jun 30, 2008 at 11:46:57AM -0700, David Bustos wrote: > 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.
I have been reaching the same conclusion over the weekend. It's not so much that SMF isn't a good place to stoer information commong to disparate components, although I'm beginning to agree with that proposition, but also that SMF doesn't provide much in the way of referential integrity features for services' properties. Here we'd eventually have a need for referential integrity (uniqueness for some properties' values across multiple containers). And that should be enough of a clue to look elsewhere. > > 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? Correct. Correct. No. > > 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? No, maybe :) Depends on what you mean by acceptance. Developing our own service to store this common information might be seen as rejection of SMF. But I don't think that should have an impact on how others approach SMF, except as an example of a useful boundary around SMF's utility. > > 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? The problem here would be that SMF doesn't really do much in the way of codeset conversion to/from UTF-8, and also that the "string preparation" rules for IDNA could be different than for other things. This means SMF couldn't satisfy all projects that wish to store internationalized values in SMF but each with different stringprep rules. > > 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 AD = Active Directory. "Non-AD" here would mean "native LDAP" domains, as well as NIS domains. > 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 I hadn't thought of that, but now that I do I see your point. > 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. All this helps me conclude that we shouldn't use SMF for this. Therefore I won't file such an RFE. But it does seem like a worthwhile RFE. Thanks! Nico --
