On Wed, Oct 31, 2007 at 03:33:32PM -0700, David Bustos wrote: > Quoth Nicolas Williams on Wed, Oct 31, 2007 at 09:11:23AM -0500: > > Gary suggests that we have a placeholder, transient service to hold > > these properties. That should be simple enough, but before we go down > > that road, are there other approaches that we should consider? > > I'm not fond of creating services only to hold configuration. Is there > a natural home for the variable? Do the services talk to each other so > they don't have to know where to read configuration from out of SCF?
svc:/network/smb/server is not the natural home for this because the system could be acting as a domain member but not serving SMB (e.g., it could be serving NFSv4 and using ID mapping). svc:/system/idmap pretty much has to be enabled in order to act as a domain member, so it's more of a natural home for this, but it wouldn't be obvious when looking at a list of services... > > Also, if we use a placeholder service then we'd like there to be a > > refresh_on dependency attribute, like restart_on. But there is no such > > attribute. I've filed: > > > > 6623159 refresh_on dependencies would help > > This seems more like an RFE than a bug, since configuration notification > propagation was not anticipated by the original design. I don't mind it being an RFE.
