David Bustos wrote: > Quoth Tony Nguyen on Mon, Oct 27, 2008 at 04:53:32PM -0700: > >> Yes, the graph engine can observe and request restarters to take >> appropriate actions. The restarters, currently, are typically >> responsible for invoking services' methods/actions. My point is changes >> in the graph engine would most likely require cooperating changes from >> all restarters. Moreover, we should probably figure out a more generic >> mechanism to observe services changes and invoke corresponding actions, >> not just for this host-based firewall daemon. >> > > I don't think restarters would need to be changed. svc.startd just has > to set up the filter rules before telling the restarter to start the > service, and tear them down when the restarter says it has stopped. > > For generic-ness, I suspect we could allow graph engine plug-ins. What > I'm not sure of is how such plug-ins would be added to the model in > a sensible way, and in particular, whether there is a sensible > explanation for the relationship between such plug-ins and restarters. > It seems that the plug-in represents alternate behaviors for the > interface the applications use (out-of-band configuration, if you will). > Now if we view the restarter as in charge of all behavior between the > service implementation and the hardware, then that points to putting > your firewall functionality into a library that restarters use. Except > restarters don't own the code between the socket interface and the > device driver interface -- that's the purview of the kernel. > > Maybe it is sensible to model the network/ipfilter service as the > operating system's behavior between the socket interface and the device > driver. I don't find that appealing, though, without more distinction > between such glue services and application services. Which is not to > say that we shouldn't do it, I suppose. > These are all worthwhile points. Another option is providing a mechanism for listening to service changes, service monitoring capability. Thus actions and state changes are monitored and appropriate behavior can be carried out (through configd and startd). For example, a firewall service can listen to state changes for network services and manipulate IPfilter configuration. Come to think of it, this is very similar to the graph engine plug-ins we discussed.
>>> I'm not sure the difference in functionality, susceptibility to bugs, or >>> amenability to future changes is small enough that it's ok to proceed >>> with the current architecture. What's your judgement? >>> >> The architecture is essentially made up of IPfilter rule generation and >> service observability to update the rules by invoking the rule >> generation engine. If a better observability mechanism exist, it can >> replace the current daemon and directly invoke the rule generation engine. >> >> I don't see any functional difference. However, susceptibility to bugs >> is certainly a valid concern as we're essentially intercept events to >> restarter and forming our own conclusions on how to affect firewall >> configuration. But then, even if we choose to make changes at the graph >> engine level specifically for firewall configuration, the logic to >> determine whether certain events affect firewall configuration is still >> similar to what we currently have in svc.ipfd. >> > > Sure, but it's not the logic, it's the stability of the input interfaces > for the logic and the precision afforded by the output interfaces for > the logic. As a svc.configd client, your logic infers decisions made by > svc.startd and takes actions in parallel with svc.startd and the > restarter, which results in a window where the service implementation > may execute before the firewall rules are in place, or even worse, if > there's an error in installing the firewall rules, with no rules at all. > > I suppose it's good enough for now, as long as there are change requests > filed so we can hash out the issues involved. > Yes, I'll file an rfe and we can take it from there. >>>>> 164: What should a user do if he sees this log message? >>>>> >>>> The problem is most likely in SMF and this daemon is another victim. I >>>> don't see what user can do. What do you suggest we can do here? >>>> >>> Well what is the impact of this error? If there is none, then you >>> should probably not log a message. >>> >> There's no user impact. It can probably be a debug rather than an error >> message. >> > > What if it failed because the repository connection was broken? Doesn't > that mean that the service might be running without the requested > filters? > You're quite correct. This function should return an int, 1 for true, 0 for false, and -1 for failure and the caller will communicate to users the possible impact. >>>>> 310: I presume you considered launching ipfilter in a separate process >>>>> contract? >>>>> >>>> That doesn't buy us much since network/ipfilter is a transient service. >>>> Do you see any benefit? >>>> >>> I don't recall whether when one child dies in a transient service, all >>> processes are killed. If so, then this would be even more important >>> because SMF won't restart you. But it should be pretty rare and can be >>> deferred if you want. >>> >> I believe events in orphan contracts are not processed since there's >> registered listener. Thus, died children should affect processes in an >> orphan contract. >> > > I presume you mean "dead children shouldn't affect processes in an > orphan contract". I did some checking, and indeed it seems that > svc.startd sets no fatal events for transient services. > Yes, there's no registered listener for orphan contracts thus events aren't notified. >>>>> 359: I didn't see this behavior of preferring inetd/isrpc over >>>>> firewall_context/isrpc in the ARC case. Did I miss it? Or does it >>>>> not matter? >>>>> >>>> An RPC service has either inetd or firewall_context pg but not both. >>>> There isn't a preference as order does not matter. >>>> >>> Oh, I missed that in the ARC case. Where is it explained? And will >>> this be enforced, or is it up to the service author? >>> >> See Firewall Static Configuration, Developer Information, and Exported >> Interfaces. >> > > Yes, but I still couldn't find the explanation that a service should > have either an inetd property group or a firewall_context property > group, but not both. I suspect you mean that if a service is an RPC > service and is assigned to inetd, then there's no need for the > firewall_context property group. I didn't see that explained in the ARC > case. Besides, if you're going to read the inetd/isprc property, > shouldn't that be listed as an imported interface? > Ah, my earlier statement was not accurate. "isrpc" and "name" properties should exist in either inetd or firewall_context but not both since they have equivalent semantics. Exclusive existence is not currently enforced as only inetd services has "inetd" pg. firewall_context pg can certainly exist for inetd service to specify a ipf_method, custom rule generation script. Do you feel more comfortable if we document the mentioned order in the case where service developer deliver the properties in both property groups? Yes, inetd/isrpc and inetd/name should be included in the list of imported interfaces. Thanks David! tony
