Gary Winiger wrote:
>>> What requirements does this place on remote repositories? >> Since the interface between svc.configd and a remote backend is not > >> to do so on the affected hosts). This change requires the same >> capability with respect to reads. The most likely future networked >> backend, LDAP, already offers this capability. > > Greenline itself did lay out the intention for remotly served > repositories. > Is is really LDAP (which is a protocol), or is it the directory > server implementation(s) that provide for different access control > policies? > >>> Have the NSS2/Sparks folk been included in any new remote >>> repository requirement? >> I don't see anything in the Sparks (nor Duckwater) materials to >> suggest that they're considering implementing networked backends for >> SMF. If I've overlooked something here, please let me know. > > Right there may be nothing in the current materials. The broader > perspective is that the repository can be centrally served. NSS2 > is the umbrella that would likely provide that service. Until > this case, there were no requirements to protect anything beyond > update protections. IMO, that allows a lot of flexability in the > schema -- not being a directory server (or access protocol) expert, > it seems reasonable to me to suggest a discussion with NSS2 so > they can possibly provide input that is relevant to this case. > > Recall Greenline made such statements as, gww's paraphrase, > privacy of values was outside the scope, but could be done with > encryption if needed and it was incumbant on the service to provide > whatever was needed. This case changes that architecture. > Consulting with other project teams that might be affected seems > reasonable. There have been many discussions, and at one point during the greenline and DSS projects, there were even plans to have greenline depend on DSS for network based repository support as an option. Before greenline was delivered the dependency was removed and subsequently the DSS effort was abandoned being eventually replaced with the sparks effort. Since that time there still have been off and on discussions in both groups about the future possibility of putting some portion of the SMF repository in a network based repository but AFAIK there are no active projects at this time. My high level current opinion on doing this is that we should probably consider an effort that supports an LDAP based repository, but does not support NIS+ [because it's EOF'd] and probably will not support a NIS repository [because of the lack of security]. I also think that having network based SMF configuration would fit well into the current design of SMF profiles. Perhaps having a profile that is actually a pointer to a profile or profile stack in a networked repository. Perhaops this could be a local profile that contains the property/properties that translate into URIs that point the remote data in the network repository. IE: perhaps a SMF stack might someday look something like: +--------------------------+ | local profile | +--------------------------+ | profile ptr (ldap://...)--------->[profile data/stack in a LDAP repository] +--------------------------+ | generic_open profile | +--------------------------+ | base profile | +--------------------------+ or something similar. That idea tossed out, I have to re-state that as far as I know this is just an idea stewing in the back burner of different peoples minds, although we [sparks] are trying to keep the door open so we can do something like this in the future once the need an requirements become evident. Doug.
