On Mon, May 19, 2008 at 03:28:34PM -0700, Mark Fenwick wrote: > > If SMF_FMRI is set then maybe stunnel could get its config file from > > config/stunnel_config_file for the given service. That'd be very cool. > > You can run stunnel in two ways, as a normal user in which case you > would specify the config file as something you could modify, or you > could run it as a system service, in which case a SMF manifest would > be s usefull addition. I plan on creating a SMF manifest and you can > enable this service if needed, but the default value of > config/stunnel_config_file needs to be set to something, even if its > changed before the service is enabled.
Right, when running stunnel as a client it may not make sense to use a config file from /etc. Using $SMF_FMRI to decide that this must be a server is really a heuristic, possibly a bad one (since why shouldn't servers turn around and act as clients? but then, why not tell stunnel then what config file to use on its command line?). > > Alternatively, what's wrong with /etc? > > IMO, nothing, but SMF best practices generally steers you away from > creating new config in /etc *unless* there is a well known existing > interface, which in this case is in /usr/local/etc. > > This is the conundrum! It's no conundrum. Recent ARC happenings seem to indicate that you can ask for a waiver of the SMF BP for FOSS (the BP makes an exception for FOSS, but the ARC still has to consider the matter). Whatever you do, if it involves making changes to stunnel, do send them upstream if you can. Nico --
