Bug 135595

Could we just ensure that we stop NFS before NM?

Or never stop ncnetworkmanager?

???

Stopping the networkmanager service is supposed to down the interfaces.  The two are connected.

So, I ask, can we ensure that we stop NFS before we stop NM?

rcnetwork is responsible for stopping the interfaces.

We've decided to make rcnetworkmanager and rcnetwork interchangable and (I think) mutually exclusive.

For example, rcnetwork is used if you are using the networking scripts; rcnetworkmanager is used if you are using NM.

Makes sense?

By and by, this means we need to introduce a meta-dependency for both rcnetwork and rcnetworkmanager.  I have brought this up but I don't think anyone has done it yet.

I see the nfs now relies on $network so is this cleared up?  Or does the networkmanager script need to add a provides still?

As long as only rcnetwork provides the "meta-dependency" it isn't clreaed up. NetworkManager needs to provide "network" in order to make things work.

Right now, /etc/init.d/network provides "network" (not "$network").

Are you saying /etc/init.d/networkmanager just needs to provide "network" ?

If I get it right, networkmanager and rcnetwork exclude eachother (i.e. can't be activated at the same time), this would be an option IMHO. Because nfs-server needs "network" and will be stopped before network (i.e. before networkmanager, if it is used). [I thought this is was Schwab was complaining about ;))]

Not sure exactly what I should do!

I tried providing "network" and "$network" (not at the same time) in the networkmanager initscript, but I still get insserv errors and am unable to delete the 'network' service.

Well, let's get zoz's opinion then ;)

After looking into this again I found

 /etc/insserv.conf:$network network +pcmcia +hotplug

So rcnetworkmanager should provide network (not $network). In addition we might need to change /etc/insserv.conf. Werner, could you please elaborate on that?

I had /etc/init.d/networkmanager provide network but I still see problems (cannot "chkconfig --del network" for example).

Zoz?  Werner?  ;)

*** Bug 141051 has been marked as a duplicate of this bug. ***

My opinion is that:
It makes no sense that nfs requires rcnetworkmanager, because rcnetworkmanager does only start NM and does not ensure that there is an active network connection.
It does not make sense to use NM and nfs together.

*** Bug 141579 has been marked as a duplicate of this bug. ***

All scripts nedding network connection should use the
system provides `$network'.  This system provide is
defined in /etc/insserv.conf (see manual page insserv).
Btw: `chkconfig' uses insserv.  That means that using
insserv in delete mode the program will not accept
removing a service if this service is required by other
services.  You can overwrite this by using the option
`-f' (-> man insserv).

To get both NM and the network script installed in parallel but exclusively
enabled we may use two different provides which may mapped both optional to
the system facility $network ... on the other hand we could also start NM
by the network script by controlling this with a sysconfig variable and
a lock in /var/lock/subsys/ to distinguish the current used mode.

Thanks Werner -- I guess that was the missing piece we needed to be able to fix this problem, Robert?

So I have networkmanager provide "network" and have all requiring initscripts require "$network" ?

Will do.

I also like Werner's second idea, though.  We could move the networkmanager initscript into the network script and have it instantiate the proper networking system (if* scripts or NM) based on a configuration option.

For the first approach you would just need to provide some string and Werner would fix /etc/insserv.conf accordingly.

But actually I thinks we should go for the second idea - Zoz, would you accept a patch to rcnetwork?

Yes.
We can use 
  /etc/sysconfig/network/config:NETWORKMANAGER=yes
as control variable. With this info also ifup can print informative messages if it is called while NM is running.

Alright, Robert, will you take care of patching rcnetwork? It's part of the package sysconfig. Who will add /etc/sysconfig/network/config:NETWORKMANAGER=yes?

*** Bug 139589 has been marked as a duplicate of this bug. ***

*** Bug 142829 has been marked as a duplicate of this bug. ***

Alright.  Find attached an updated rcnetwork that starts NetworkManager if (a) the config option is set to "yes" and (b) NetworkManager is installed.  Otherwise, it falls through and performs the usual rcnetwork steps.

The idea would be to (a) replace rcnetwork in sysconfig with this and (b) remove the networkmanager initscript from the NetworkManager package.

I think this is definitely the way to go.

Zoz:  If you like the changes, I can commit it if you want.

Created attachment 63179 [details]
updated rcnetwork that handles NM, too

Also, we will need the YaST changes in place, too.

Oh, nice to learn about this change one day before Beta1. Please next time cc me sooner.

No, I think that the single service model is wrong, at least in the proposed implementation. Keep in mind the scenario of switching between ifup and NM.
What should be the correct way of turning off a running NM and setting up the interfaces using ifup? You'd have to call the script twice anyway, so it's better to keep them separate.

I think that noone has yet presented arguments why the single service model would be better. I think that it is better to fix insserv to accept networkmanager providing network. It should be enough. I don't mind
insserv -r -f network; insserv networkmanager.

There is nothing to fix for insserv. Two scripts providing the
same service is what I call a BUG.  This because we run into
deep trouble if we would allow this.  Think about scripts from
customers and 3dr party vendors.

3rd party scripts must by LSB have unique script names. LSB says nothing about uniqueness of facility names.
But anyway, then make a special case so that $network is provided either by network or networkmanager.

Btw: using a specific lock for NM or ifup mode in /var/lock/subsys/
should help to avoid mixing up NM with ifup and vice versa.

I'm not willingly to add a bug.

I cannot see problems if both are one service. Just change the settings and restart the service. The same way as with every other service.

The propsed patch does not work if someone changed NETWORKMANAGER=yes/no and then simply restarts. I will change that.

I'd also second this approach, as it will be much easier for people to just use rcnetwork (which they are used to) than using rcnetwork sometimes and sometimes rcnetworkmanager... 

Thanks. Please keep in mind that yast uses reload instead of restart.

Yes, i already had it in mind. In case of a system change reload will do a restart.

I prefer the single script solution, too.

Note we need to coordinate the changes between YaST, sysconfig, and NetworkManager ... so let's make sure we commit the changes in unison.

So, I guess Zoz is working on getting the changes into the sysconfig package, right? In addition to that we only need to strip the rcnetworkmanager script from NetworkManager (Robert?) and make YaST aware of this change (Martin?). Do you guys think we can make this work for Beta1?

Correct.  I'll drop rcnetworkmanager from NetworkManager soon as the other bits are in place.

I'm just working on this (beside other changes) and will submit a changed package not later than tomorrow. The network script will warn you if the setting of NETWORKMANAGER and the current state do not match. Changing NETWORKMANAGER and calling rcnetwork restart or relaod will work.

Also ifup will check NETWORKMANAGER and send a dbus message to NM if needed. And will inform the user.

Martin, will YaST ever write STARTMODE=managed?
Robert, will NM check STARTMODE?

No, yast will not write STARTMODE=managed. I am just working on config:NWTWORKMANAGER.

No, NM does not check STARTMODE.

There is also service networkmanager-dispatcher. It requires networkmanager. Since we have no service networkmanager anymore it has to require network. Now when NETWORKMANAGER=no networkmanager-dispatcher will fail.
Therefore i integrated also start/stop of the dispatcher in service network. Controlled by another sysconfig variable NM_DISPATCHER, which will be 'yes' by default.

OK?

OK. Please do not forget to add "## Type: yesno" to the variables, YaST depends on it.
Christian can I submit the YaST changes for Beta 1?

Yes you can, i will submit sysconfig later __today__.

(((have a look at mobile@sue.de)))

Zoz: Alright, and I will submit the NM changes today, too.  For NM, I will remove both the networkmanager and networkmanager-dispatcher initscripts.

Robert, i'm just writing comments for the new sysconfig variables. I would like to point to some doc for the dispatcher. Will we have a manpage or a README?

I will be happy to write a manpage.  Not in time for beta 1, though!

Fine.

NM changes are checked in: We no longer install or insserv networkmanager and networkmanager-dispatcher initscripts.

submitted sysconfig package.

This still needs to be documented.

BTW:
I also changed ifup to send a dbus message to NM and inform the user. I introduced a variable NM_CONTROLLED that allos manual control of an interface while NM is running. Of course it would be nice if NM could also respect this variable and ignore this interface.

Let's see if our changes fit together

The sysconfig + NM bits work for me!  I have not tried the updated YaST to see if it writes out the right data, or what the UI looks like, but the new rcnetwork works great with NM.

Thanks.

I do see a lot of loops detected by insserv, such as

    insserv: There is a loop between service network and haldaemon

But that may be because I have not yet updated other packages.

That is not a bug of insserv but a feature ;)

Naturally.  Its a bug in the initscripts, though, if the problem persists.

And it were a much better feature of insserv if insserv -v would tell more about the loop. For example which other services are in the loop. Is that possible?

insserv told me about a loop between cron and syslog but i could not see it. I looked into .depend.start. 

Because of the editing mode of YaST2 for the runlevels and the service
links therein it can happen that if there are only a few scripts installed
insserv can not determine the correct star/stop number.  But insserv uses
the link scheme to overwrite the dependcies given by the LSB comments
(the only way to use the editing mode of YaST2 in all manners). I do not
like this.  Therefore I've enforced the `-d' option of insserv to resolve
such a loop.  See newest insserv package from today.