Darren Reed wrote: > David Powell wrote: >> Darren Reed wrote: >>> To answer that concern, it might be appropriate for ipf_include.sh >>> to attempt to get all of the configuration filenames from service >>> properties and if they don't exist (or are NULL) then apply a >>> default name... that may also require an update of the PSARC >>> case to document new private properties...*may* >> >> Temporary configuration file names should be automatically generated >> by the framework, period. There's no benefit, and considerable >> burden, to requiring the service author to coordinate and define >> temporary configuration file names. > > I was referring to lines 27-35 and 39 of ipf_include.sh > > So..... > > If anyone ever created svc:/network/ipfilter:foo, it would be > impossible to tie that together with svc:/network/ssh:foo because > this script would never match the ipfilter FMRI in the ssh service > with the correct one... but that might be pointless because it is > not possible to use svc:/network/ipfilter with anything other than > the default paths, anyway. So I suspect my concern is not all > that important.
Ah, I think I see what you're getting at. First of all (I can't tell if you're suggesting this or not, but to be clear) the system doesn't associate like instance names of different services. A service's instances are service-dependent; from the perspective of the system or other services, they are arbitrary. e.g. the "foo" instance of ssh and the "foo" instance of ipfilter would be in no formal way related. They could be from the perspective of their creator, and their specific implementations may reference each other, but the system doesn't recognize an association between the two. Moreover, if the administrator did create an ipfilter:foo (or anything:foo, for that matter), it would be incumbent upon that person to *modify* that second instance to ensure that it didn't conflict with the first. One can certainly make the design decision to make it easy to clone an instance, but there is intentionally no requirement or even recommendation that all services be so designed. Case in point: the existing ipfilter method uses a single, hard-coded configuration file. Creating an ipfilter:foo today would require significant changes to the new instance to make it function reasonably. What seems to be at the core of your comment is how the system manages multiple sets of ipfilter configuration simultaneously. The short answer is that since the configuration language doesn't have any means of expressing that a service's ipfilter configuration is associated with one ipfilter instance or another, it is implicit to the design that there is only one ipfilter configuration. One could imagine a design that supported multiple ipfilters, but since it is sufficiently outside the mainstream that it hasn't come up yet, I'm unconvinced that it would be worth the engineering cost or (more importantly) increased interface complexity. Dave
