On 9/13/07, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
On 9/13/07, Matthias Clasen <mclasen(a)redhat.com> wrote:
> That will probably need some work. I think you'd probably want to have a
> tab for these nm dispatcher services similar to the xined-based
> services. If you want to go wild, one could also imagine having a list
> of system bus dbus services there...
I think the control issue is probably the only note-worthy regression
that I see with this approach. I've no qualms with using Dispatcher
for network-related services, with a couple of caveats.
1) basic on/off control ..exactly on par with xinetd based services
as you suggest.
2) what to do we do when NM is turned off and the older sysconfig
based networking configuration is used. There should be a way to hold
the service configs for these network services so they are boot-time
operable (if turned on) in situations where NM isn't being run and the
legacy sysconfig based networking configs are being used.
I can think of two approaches.
a) Do this in system-config-services. Checking NetworkManager and
Dispatcher on makes the Network-Services tab active and disables
"known services" from the init list and enables them in the
Network-Services list. Disabling these does the reverse of course.
b) Only have these services in the Network-Services tab or run-level
N for chkconfig and extend /etc/init.d/network to run through the
/etc/NetworkManager/dispatcher.d/ directory and run the S* services.
This message is a little off because it basically puts partial init
functionality in the network script. The code should be trivial