Hi,
there's a problem I've been dealing with network manager running on the slaves.
Each time a new interface is hot-plugged to the machine, NM creates a default connection profile for it and executes it. It means, that it tries to run dhclient on that interface once in a while.
That's a problem, because we configure interfaces on slaves "manually" with ip command. This configuration is flushed when by NM when it tries to enforce the "Auto eth5" default profile on the interface. There's not even a DHCP server running in the environment I tested this in.
The thing is, that we need to have the network-manager running, because it starts dhclient when the controller interface is plugged in. I don't know whether the standard networking scripts can do this too. And if they can, we need a way to turn NM off somehow anyway (which is hard, because we don't have shell at that time yet).
NM has a D-Bus interface and a cli-wrapper around it called 'nmcli'. This utility is shipped along with the NM package. It can be used to exclude some interfaces from NM control by issuing
nmcli dev disconnect iface eth2
command without necessity to restart the whole service (which is something we cannot do, since we're connected through ssh).
Has this ever happened to you? It usually results a failure in the cleanup phase on
ip addr del ...
command saying that it cannot clear the address (because NM already flushed it). Or do you have NM off on slaves?
Radek :)
See some notes below ...
Mon, Aug 06, 2012 at 12:23:50PM CEST, rpazdera@redhat.com wrote:
Hi,
there's a problem I've been dealing with network manager running on the slaves.
Each time a new interface is hot-plugged to the machine, NM creates a default connection profile for it and executes it. It means, that it tries to run dhclient on that interface once in a while.
That's a problem, because we configure interfaces on slaves "manually" with ip command. This configuration is flushed when by NM when it tries to enforce the "Auto eth5" default profile on the interface. There's not even a DHCP server running in the environment I tested this in.
I'd get rid off NM completely. I think that the safest method is to disallow installation of NetworkManager package.
The thing is, that we need to have the network-manager running, because it starts dhclient when the controller interface is plugged in. I don't know whether the standard networking scripts can do this too. And if they can, we need a way to turn NM off somehow anyway (which is hard, because we don't have shell at that time yet).
Could we utilize the post-installation scripts? See anaconda documentation [1] for details.
[1] http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_5._Post-installatio...
NM has a D-Bus interface and a cli-wrapper around it called 'nmcli'. This utility is shipped along with the NM package. It can be used to exclude some interfaces from NM control by issuing
nmcli dev disconnect iface eth2
command without necessity to restart the whole service (which is something we cannot do, since we're connected through ssh).
Has this ever happened to you? It usually results a failure in the cleanup phase on
ip addr del ...
command saying that it cannot clear the address (because NM already flushed it). Or do you have NM off on slaves?
Yes, completely off :-)
Radek :) _______________________________________________ LNST-developers mailing list LNST-developers@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/lnst-developers
On 08/06/2012 01:24 PM, Jan Tluka wrote:
See some notes below ...
Mon, Aug 06, 2012 at 12:23:50PM CEST, rpazdera@redhat.com wrote:
Hi,
there's a problem I've been dealing with network manager running on the slaves.
Each time a new interface is hot-plugged to the machine, NM creates a default connection profile for it and executes it. It means, that it tries to run dhclient on that interface once in a while.
That's a problem, because we configure interfaces on slaves "manually" with ip command. This configuration is flushed when by NM when it tries to enforce the "Auto eth5" default profile on the interface. There's not even a DHCP server running in the environment I tested this in.
I'd get rid off NM completely. I think that the safest method is to disallow installation of NetworkManager package.
Disabling NM would probably save us a lot of trouble, that's for sure ...
In that case we could think about dropping the dynamic controller interface completely. As far as I know beaker set's up a working interface so it shouldn't be a problem. Even when machines are installed manually, there's always one NAT'ed interface present by default.
I'm going to do the virtual netdevices first. And then we'll see if the virtualization of controller interface is really necessary or useful at all.
The thing is, that we need to have the network-manager running, because it starts dhclient when the controller interface is plugged in. I don't know whether the standard networking scripts can do this too. And if they can, we need a way to turn NM off somehow anyway (which is hard, because we don't have shell at that time yet).
Could we utilize the post-installation scripts? See anaconda documentation [1] for details.
[1] http://fedoraproject.org/wiki/Anaconda/Kickstart#Chapter_5._Post-installatio...
NM has a D-Bus interface and a cli-wrapper around it called 'nmcli'. This utility is shipped along with the NM package. It can be used to exclude some interfaces from NM control by issuing nmcli dev disconnect iface eth2
command without necessity to restart the whole service (which is something we cannot do, since we're connected through ssh).
Has this ever happened to you? It usually results a failure in the cleanup phase on
ip addr del ...
command saying that it cannot clear the address (because NM already flushed it). Or do you have NM off on slaves?
Yes, completely off :-)
Radek :) _______________________________________________ LNST-developers mailing list LNST-developers@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/lnst-developers
lnst-developers@lists.fedorahosted.org