Darren Reed writes: > The "ipf" service must always be enabled for any of the others > to be active. The premise behind making this seperate from the > others was to put the check for pfil in one place, so that if this > check fails and causes "ipf" to go into maintainence mode, there > is only a single service that needs attention. Post pfhooks, it is > harder to justify this service existing - it'd just be causing the > ipf kernel module to load.
I see. But as long as pfhooks is imminent, why bother doing that? How are these two projects being coordinated? Even if this improvement goes first, I don't think it helps users much to give them a new administrative interface in one build, and then pull it away in another. > You might want to have "ipfnat" or "ipfconf" active, if you want > to do NAT without firewalling or firewalling without NAT. I'm not sure I understand that. Why wouldn't I use the existing IP Filter configuration files to control what IP Filter does? Does it make operational sense to enable and disable these large chunks separately -- in addition to setting up the configuration files? My concern is that with more moving parts, it's easier for users to misconfigure things. That's likely a bad thing with parts of the system that are intended to provide security. > The ippool service is an optional dependency for ipfconf/ipfnat, > where if it is enabled and there is an error, should cause those > coming after it to wait. At present only ipf rules can make a OK. I suppose the main issue here is that it looks like the breakup into services just reflects the commands and daemons that are run. I'm not sure that's always the right sort of factoring to do with SMF. > > - are all of them actually administrative interfaces, or are some of > > them implementation artifacts? (Should I be doing "-r" on the > > milestone alone?) > > > > Before SMF, it was possible to do "/etc/init.d/ipfboot <action>", > where "action" would do the reloading of one or the other > configuration files, in addition to the usual "start" and "stop". Does it help to be able to specify reloading of a particular configuration file, rather than just saying "refresh IP Filter from its current configuration files so that everything matches?" Why would a user pick just one file to refresh? > Whatever the path taken here, we need to change the administrative > interface - this is unavoidable. OK ... > > - what would be dependent on any of these and what do they each > > depend on? > > > > In addition to Zhijun's email, I hope the description above > has answered this? Yes. -- James Carlson, KISS Network <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
