Alan Maguire wrote: > hi Dan > > looks great! > > a few thoughts: > > - i wonder if network/name is the right name for this service, i notice we've > already got: > > svc:/system/name-service-cache:default > svc:/milestone/name-services:default > svc:/network/tname:default > > ..all related to name services. how about network/link-name or something? >
OK, we'll call it network/link-name. > - by naming the property groups by the vanity link name, does that > mean if i change a vanity name, we'd have to delete the link property > group and copy across all the data to the new vanity-name-based property > group? would the linkids be more stable property group names perhaps? > Yes, you're correct. Using linkids would be more stable. I saw meem's response to your comment, and that was why I picked using the vanity name. I'd want the administrator to use dladm to access the vanity naming SMF respository. dladm would do the work to present the information in a meaningful way. dladm would handle storing information correctly and keeping the <linkid, name> mappings unique and correct. I don't think there is currently a way to prevent the administrator from using svcs, svccfg, svcadm, etc., to access the SMF repository. The administrator could use these commands to view how we store data, or even modify things. Even if there was a way, I'm not sure it would be wise, except for the case of modifying the <linkid, name> mapping. It would be much easier to write things the way you suggest, and I'd like to do it that way, but I don't think it would the best way to go given how SMF currently works. > - given that this service is so important, i suspect it might have to > be part of the seed repository, might be worth checking with the SMF > folks about this. > OK, thanks! > - i notice we've also got a devices/local service for configuring devices. > i'm guessing that it's not the right place to do the work of this service, > but i thought i'd better check. thanks! > I see Cathy already responded to this. thanks! Dan
