James Carlson wrote: >David Bustos writes: > >>>svc:/network/ipfilter (milestone) >>>svc:/network/ipfilter/ipf >>>svc:/network/ipfilter/ipmon >>>svc:/network/ipfilter/ippool >>>svc:/network/ipfilter/ipfnat >>>svc:/network/ipfilter/ipfconf >>> >>Can you give a brief description of what each of these services would >>do? >> > >Or perhaps some use-cases associated with them. Such as: > > - when would I disable one of these but leave the others enabled (or > vice-versa)? >
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. You might want to have "ipfnat" or "ipfconf" active, if you want to do NAT without firewalling or firewalling without NAT. 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 reference to a pool configured with ippool, but in the future NAT rules in ipnat.conf will also be able to do this. There are paths that could be taken here to allow ippool to be part of the other services that use it but this would be a different interface than is used elsewhere. The ipmon service is started to pickup log information generated as a result of ipf or ipnat rules. To minimise the risk of log data being lost, it is started before either of these to ensure collection can start immediately. > - when does it make sense to restart one? > It is expected that "refresh" will be the more commonly used interface, where you want to "refresh" the rules in the kernel with those on disk. A "restart" (to me), would imply flushing any kernel state in addition to reloading rules. > - 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". Today it is possible to continue doing this by invokding the shell script directly (/lib/svc/method/ipfilter <action>) but this is using a private interface... If I sit back and think about it, "svcadm enable -r ipfilter" is not the right thing to do - it could cause services to become enabled that are not supposed to be enabled and thus stop things from moving forward. Whatever the path taken here, we need to change the administrative interface - this is unavoidable. > - 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? Darren
