On Thu, Aug 03, 2006 at 10:47:17AM -0700, Alan Maguire wrote: > Now an alternative here would be not to use SMF services, but instead > have each routing daemon check the state of the routing/forwarding flags > before starting. The key question here is if we want to expose > the flags as services. Opinions on this would be greatly appreciated!
As long as sysadmins can't configure forwarding in any way that works around the state of these services this should be fine. But see below. Why have separate IPv4 vs. IPv6 services? > One additional detail: initially we thought that simply modeling the > global flags as services and having routing daemons depend on these > would be sufficient to ensure that global routing/forwarding settings > control routing daemon execution appropriately, however it was pointed > out that this would result in daemon services being offline if their > dependencies are disabled. Being offline in these circumstances is > suggestive of configuration errors where there are none it seems, so > we modified the design slightly to accomodate this (when the ipv4(6)-routing > service is disabled now, it disables the enabled routing daemon services, > noting them so they will be reenabled if/when ipv4(6)-routing is enabled > again). I think this may be a matter of improving the SMF UIs. SMF should distinguish a service is "enabled but offline due to administratively disabled required_all dependencies" from a service that is "enabled but offline due required_all dependencies in maintenance state." In any case, it seems to me that if forwarding is enabled then routing should be enabled and vice-versa, so the split into transient (right?) forwarding services and non-transient (right? what if only static routes are configured) routing services seems artificial. (BTW, ISTM that there should be a way for services to declare themselves transient/non-transient at start method runtime.) Nico --
