Re: hostname-mode=default and hostname set outside NM
On 4/27/20 7:54 PM, Thomas HUMMEL wrote: What do you think ? Hello, I thinks this is related to this https://github.com/systemd/systemd/pull/15624 prompted by the following thread I opened : https://lists.freedesktop.org/archives/systemd-devel/2020-April/044395.html Thanks for your help -- Thomas HUMMEL ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hostname-mode=default and hostname set outside NM
On 4/27/20 7:05 PM, Thomas HUMMEL wrote: hostname(1) change the transient/kernel hostname but as systemd-hostnamed does not poll /proc/sys/kernel/hostname (which was confirmed to my in the systemd-devel list) for a change, this out-of-NM set hostname is not seen by NM, which then restores the last outside one seen BY himself, which is the hostname-original read from dbus at its start ? I actually did the test changing *only* the presence or absence of systemd-hostnamed (brutally renaming to systemd-hostnamed.service.orig in /usr/lib/systemd/system for the test) : Each time withouth changing hostname-mode (directive was not there so its value is default) : a) without systemd-hostnamed : short hostname b) with systemd-hostnamed : fqdn [again with an external tool issuing hostname(1) between dhcp and manual profile] So it seems to me that, because of hostnamed lack of polling for transient hostname change, NetworkManager could behave differently according if this service it uses as a proxy is there or not (i.e. if NM reads directly using gethostname(3)) : the 'last hostname set outside of NetworkManager could vary. What do you think ? Note : this could be more complicated because, as systemd.hostnamed deactivates itsef when idle, I wonder if a fresh instance would not start by setting the transient hostname to the static hostname (which is quite the goal of the static hostname to me). So this would give another result if the get-hostname() waited a little more ? Thanks -- Thomas HUMMEL ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hostname-mode=default and hostname set outside NM
On 4/27/20 5:34 PM, Thomas HUMMEL wrote: On 4/27/20 5:20 PM, Beniamino Galvani wrote: It uses systemd-hostnamed, and falls back to gethostname() in case of failure [1]. I should then try to remove hostnamed just to figure out why in 1) hostname from initrd : fqdn 2) NM starts : hostname-originial == fqdn 3) dhcp : short name 4) an external tool issues hostname and creates another higher priority NM profile NM (hostname-mode=default) restores the fqdn (as seen in traces) instead of the short one in 3) which, according to what you just explained is the LAST externally set. I'll try to figure out this myself...Thanks for your help. Well, I was thinking about 4) : hostname(1) says that hostname is set via sethostname(2). This is outside of NetworkManager but as it may also be outside systemd-hostnamed (hostname(1) was used and not hostnamectl or dbus-send) could that explain what I see ? hostname(1) change the transient/kernel hostname but as systemd-hostnamed does not poll /proc/sys/kernel/hostname (which was confirmed to my in the systemd-devel list) for a change, this out-of-NM set hostname is not seen by NM, which then restores the last outside one seen BY himself, which is the hostname-original read from dbus at its start ? Thanks -- TH ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hostname-mode=default and hostname set outside NM
On 4/27/20 5:20 PM, Beniamino Galvani wrote: It uses systemd-hostnamed, and falls back to gethostname() in case of failure [1]. I should then try to remove hostnamed just to figure out why in 1) hostname from initrd : fqdn 2) NM starts : hostname-originial == fqdn 3) dhcp : short name 4) an external tool issues hostname and creates another higher priority NM profile NM (hostname-mode=default) restores the fqdn (as seen in traces) instead of the short one in 3) which, according to what you just explained is the LAST externally set. I'll try to figure out this myself...Thanks for your help. -- TH ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hostname-mode=default and hostname set outside NM
On 4/27/20 5:22 PM, Beniamino Galvani wrote: Still the hostnamectl delay is a thing unexplained to me. I don't know the cause of the delay, it didn't expect it. Ok. Thanks again. -- TH. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hostname-mode=default and hostname set outside NM
On 4/27/20 11:13 AM, Thomas HUMMEL wrote: I notices that hostnamectl --static set-hostname behavior was not the same according to the value of hostname-mode setting : - if set to 'none' : there's a delay for the transient hostname to be automatically set to the manually set static one - if set to 'dhcp' : the transient hostname is instantly aligned with the new static one. Is this expected ? Sorry, I cannot seem to reproduce this one I may have given you an incorrect hint. Still the hostnamectl delay is a thing unexplained to me. thanks -- TH ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hostname-mode=default and hostname set outside NM
On 4/22/20 8:18 PM, Thomas HUMMEL wrote: Hello, using NetworkManager-1.20.0-5.el8_1.x86_64 on CentOS 8.1 I tried to figure out the hostname-mode semantics beyond what the manual says (I've got another thread for this but somehow unrelated to the following question). What's not clear to me is : what if the transient hostname is changed outside NetworkManager after hostname-original gets read at NM start ? Let's say someone issues hostname foobar (instead of hostnamctl --transient set-hostname foobar) while the DHCP connection is still up : would that become the new set-out-of-NM hostname wich would be restored when the connection is deactivated ? Technically NM could notice it directly issuing gethostname(3) but my understanding is that it would rather rely on systemd-hostnamed/dbus for that. The latter seems to have in some cases some delay to catch up with transient hostanme. On a related subjet : I notices that hostnamectl --static set-hostname behavior was not the same according to the value of hostname-mode setting : - if set to 'none' : there's a delay for the transient hostname to be automatically set to the manually set static one - if set to 'dhcp' : the transient hostname is instantly aligned with the new static one. Is this expected ? Thanks -- TH ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
hostname-mode=default and hostname set outside NM
Hello,
using NetworkManager-1.20.0-5.el8_1.x86_64 on CentOS 8.1 I tried to
figure out the hostname-mode semantics beyond what the manual says (I've
got another thread for this but somehow unrelated to the following
question).
In this post, I'd like to clarify this NetworkManager.conf(5) quote for
default :
"If not present, the hostname will be updated to the last one set
outside NetworkManager."
For what I saw when tracing, nm-policy reads the hostname-original and
restores this hostname when the DHCP connection gets deactivated.
Looking at the source, it seems to match this part in
nm-policy.c:update_system_hostname() :
if (!priv->default_ac4 && !priv->default_ac6) {
/* No best device; fall back to the last hostname set
externally
* to NM or if there wasn't one, 'localhost.localdomain'
*/
_set_hostname (self, priv->orig_hostname, "no default
device");
return;
}
Same kind of mechanism without default fallbacks for hostname-mode=dhcp
What's not clear to me is : what if the transient hostname is changed
outside NetworkManager after hostname-original gets read at NM start ?
Let's say someone issues hostname foobar (instead of hostnamctl
--transient set-hostname foobar) while the DHCP connection is still up :
would that become the new set-out-of-NM hostname wich would be restored
when the connection is deactivated ?
Technically NM could notice it directly issuing gethostname(3) but my
understanding is that it would rather rely on systemd-hostnamed/dbus for
that. The latter seems to have in some cases some delay to catch up with
transient hostanme.
Thanks for your help
--
Thomas HUMMEL
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hostname-mode : short vs fqdn name
On 4/17/20 10:23 PM, Beniamino Galvani wrote: Hello Beniamino, No, I don't think it does. I think that DHCP is run before NM, probably in initrd or by other services. Indeed, in between I came to a similar conclusion. And tracing further (helping my with NM dans my initrd sources) I figured out: - the original hostname, which NM reads from dbus is indeed setup by dracut/initrd/dhclient-scripts a) when no postcsript adding a second NM manual profile is not run, results and reasons are, as expected : - hostname-mode == none : maestro-1000.maestro.pasteur.fr (original from initrd) - hostname-mode == dhcp : maestro-1000 (from dhcp) - hostname-mode == default : maestro-1000 (from dhcp) b) when postscript, which adds to the nic a higher autoconnect priority manual ip address profile is run : - hostname-mode == none : maestro-1000 (the postscript itself issues a hostname command - I missed that point initially) - hostname-mode == dhcp : maestro-1000.maestro.pasteur.fr (reset from dhcp) : I guess it's when the dhcp profile is disconnected, original hostname is reset by NM as the semantic of hostname-mode=dhcp implies) - hostname-mode == default : maestro-1000.maestro.pasteur.fr (fallback no default device) : again, semantics of hostname-mode As a matter of fact in this case I see in this trace http://dl.pasteur.fr/fop/JyY4sSwA/confignetwork-default.log.bz2 that default device setting occurs : policy: set 'xcat-enp33s0f0' (enp33s0f0) as default for IPv4 routing and DNS but *after*: policy: set-hostname: set hostname to 'maestro-1000.maestro.pasteur.fr' (no defaultdevice) I'm not really sure : is this is normal ? So, this aside everything is indeed fully explained. May I add 2 last questions though ? 1. as seen in this other trace http://dl.pasteur.fr/fop/wRQfXSQX/confignetwork-none.log.bz2 why are they many lines *long after the dhcp + static profile scenario is "finished"* we can still see many lines such as auth: call[XX]: CheckAuthorization or policy: set-hostname: hostname is unmanaged ? 2. this has nothing to do with NM and is not related to the initial thread (I just experienced it while debugging my case) but it seems that when, starting with no static hostname, we set one with hostnamectl --static set-hostname the transient hostname - is also set to that name (seems to contredict the man for --static) - *not immediatly* (I can still see for some time the original - different - transient name) Does it seem legit to you ? Thanks anyway for your help and time Best, -- TH ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hostname-mode : short vs fqdn name
On 4/9/20 10:59 AM, Beniamino Galvani wrote:
alking about D-Bus, I see this in the begining of all 3 (default, none,
dhcp) traces :
Apr 08 14:53:29 maestro-1000.maestro.pasteur.fr NetworkManager[25235]:
[1586350409.2521] policy: get-hostname:
"maestro-1000.maestro.pasteur.fr" (from dbus)
Apr 08 14:53:29 maestro-1000.maestro.pasteur.fr NetworkManager[25235]:
[1586350409.2521] policy: hostname-original: set to
"maestro-1000.maestro.pasteur.fr"
how is this hostname fully qualified who sets it ? The original hostname
always seems to be this one.
I don't know, it is set before NM starts.
Hello, again
I tried to figure out the simplier case : hostname-mode=none.
I guess the above fqdn hostname read from D-Bus is the transient
hostname, correct ? I don't think it can be set by dhcp if NM is the one
which starts dhclient.
As a matter of fact, I saw that dhconfig() from dhcpd-scripts
/usr/sbin/dhclient-script can indeed set the transient hostname.
The problem is that it sets the transient name only if hostname is
needed, which, looking at the script is if transient hostname is empty
or localhost :
need_hostname ()
{
CHECK_HOSTNAME=$(hostnamectl --transient)
if [[ "${CHECK_HOSTNAME}" = "(none)" ]] ||
[[ "${CHECK_HOSTNAME}" = "localhost" ]] ||
[[ "${CHECK_HOSTNAME}" = "localhost.localdomain" ]]; then
return 0
else
return 1
fi
}
which must not be the case because of the fqdn hostname we see BEFORE NM
starts (I am assuming that dhclient is only started by NM of course here)...
Or could that initial fqdn hostname come from systemd-hostnamed at boot
which would fall back setting the transient hostname by reverse dns
lookup of the ip address ?
thanks
--
TH
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hostname-mode : short vs fqdn name
On 4/9/20 10:59 AM, Beniamino Galvani wrote: how is this hostname fully qualified who sets it ? The original hostname always seems to be this one. I don't know, it is set before NM starts. Ok, I'll look into this but this is not related to my initial problem indeed. In the 'none' log, the FQDN is set before NM starts Indeed (read from D-Bus by NM) . Around 14:53:41 someone adds a new connection and activates it, disconnecting the previous DHCP connection. This can only be the postscript I mentionned creating the xcat- NM profile At the same time the kernel hostname is changed externally to NM. I can't say who does this. Hmm this is odd. I may have missed something then. I'll look further into it. - dhcp (end up with fqdn). In this case the short hostname got via DHCP is set by NM at 15:05:49. But later, somebody adds and activates a new connection 'xcat-enp33s0f0' with static addresses The postscript. and so the DHCP hostname is removed, restoring the initial one. Ok but then you mean the one set BEFORE NM starts (again, the one read from D-Bus at the begining) you mentionned above ? Because man said for hostname-mode == dhcp that there is no fallback (like to reverse lookup the ip address). I was initially confused by this : it LOOKED LIKE even in dhcp mode, NM was performing a reverse lookup fallback as in fact it just reset to the one it saw initially, correct ? Thanks a lot for your help. -- Thomas HUMMEL ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hostname-mode : short vs fqdn name
On 4/8/20 4:18 PM, Thomas HUMMEL wrote: >> b) : NM just don't play with the transient name and sets a static hostname >> coming from /etc/sysconfig/network > > NM sets the transient host name. It doesn't know about > /etc/sysconfig/network. The hostname is determined in this way: But man says "none: NetworkManager will not manage the transient hostname and will never set it." Makes me wonder what exactly is the transient hostname. Besides, trace for 'none' confirms hostname is "unmanaged" So where does the short hostname I see in this case b) come from if not dhcp (none) neither the sysconfig/network file ? Or maybe for this case (hostname-mode=none) NM does not change the transient hostname but dhcp has initially changed it in step1 (dhcp NM profile), without NM being involed. So it is kept this way in step2 (manual profile activation) ? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: hostname-mode : short vs fqdn name
Hello, thanks for your answer On 4/8/20 10:25 AM, Beniamino Galvani wrote: >> - step2 (I guess) puts HOSTNAME=maestro-1000 in /etc/sysconfig/network > > AFAIK, NetworkManager doesn't do that. Although I saw that it was the postscript which wrote into this file, I thought NetworkManager was considering it because it is mentionned in man 5 nm-settings-ifcfg-rh > Yes, it uses the SetHostname D-Bus call of systemd-hostnamed, which > changes the transient (kernel) hostname. Talking about D-Bus, I see this in the begining of all 3 (default, none, dhcp) traces : Apr 08 14:53:29 maestro-1000.maestro.pasteur.fr NetworkManager[25235]: [1586350409.2521] policy: get-hostname: "maestro-1000.maestro.pasteur.fr" (from dbus) Apr 08 14:53:29 maestro-1000.maestro.pasteur.fr NetworkManager[25235]: [1586350409.2521] policy: hostname-original: set to "maestro-1000.maestro.pasteur.fr" how is this hostname fully qualified who sets it ? The original hostname always seems to be this one. >> a) default : what's described above (fqdn) >> b) none : hostname == short name >> c) dhcp : same as a) (fqdn) >> >> I can elaborate on that like this : >> >> a) as man said NM sets hostname "with the one provided via DHCP", which is >> first the short one (step1) then as a static profile is activated, it falls >> back to "hostname from the reverse lookup of the IP address" (which DNS >> resolves in the fqdn) > > Right. >> b) : NM just don't play with the transient name and sets a static hostname >> coming from /etc/sysconfig/network > > NM sets the transient host name. It doesn't know about > /etc/sysconfig/network. The hostname is determined in this way: But man says "none: NetworkManager will not manage the transient hostname and will never set it." Makes me wonder what exactly is the transient hostname. Besides, trace for 'none' confirms hostname is "unmanaged" So where does the short hostname I see in this case b) come from if not dhcp (none) neither the sysconfig/network file ? > > https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/1.20.0/src/nm-policy.c#L744 ok. But what does exactly "set outside of NetworkManager" mean ? > No, it only takes the short hostname from DHCP. ok, makes sens as this is what's sent > I don't know why it is setting the FQDN in your case. Could you please > put level=trace in the [logging] section of > /etc/NetworkManager/NetworkManager.conf, disabled journald > ratelimiting, reproduce the issue and attach the journal log of a boot > with hostname-mode=dhcp? Please find the 3 traces here: http://dl.pasteur.fr/fop/P3H6bSGV/NM-hostname-mode.tar.gz So basically, I still don't understand the 2 following cases - none (end up with short name) : if dhcp, NM seems to still manage the hostname despite none - dhcp (end up with fqdn). Thanks for your help. -- Thomas HUMMEL ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
hostname-mode : short vs fqdn name
Hello, I'm trying to figure out how exactly my stateless HPC nodes (CentOS 8.1/NetworkManager-1.20.0) get their hostnames. As a matter of fact, they can either get a "short" (non fqdn - something like 'maestro-1000') hostname or a fqdn hostname (maestro-1000.maestro.pasteur.fr). This is related to the process network is configured according to the following procedure : 1. node PXE boots the stateless osimage and ends up having a dhcp NM profile 2. a postscript is run on the node which uses NM to create an additional profile with higher autoconnect priority which main goal is to statically set the ip address retrieved in step 1. - if only step 1. is performed hostname == short name - if step 1 + 2. are performed, hostname == fqdn Note : - DNS is configured on each node, both for forward and reverse zone - I checked with tcpdump that DHCP option 12 "Host-Name" always stores the short name (and of course the domain 'maestro.pasteur.fr' in option 15) - step2 (I guess) puts HOSTNAME=maestro-1000 in /etc/sysconfig/network - node never have a /etc/hostname file - no hostname-mode is specified in NetworkManager.conf - finally, when step 1+2 are performed, I can see: Apr 07 20:13:19 maestro-1000 systemd-hostnamed[14516]: Changed host name to 'maestro-1000' Apr 07 20:13:33 maestro-1000.maestro.pasteur.fr systemd-hostnamed[14516]: Changed host name to 'maestro-1000.maestro.pasteur.fr' which I reckon matches step1 then step2 Here are my questions : - I am assuming NetworkManager uses systemd-hostnamed when it is in charge to set the hostname : is this correct ? - I am assuming what I see is related to hostname-mode setting as I didn't see any hostname or hostnamectl et sethostname call in the postscript. Playing with its possible valued in NM config, I experienced the following after step 1+2 : a) default : what's described above (fqdn) b) none : hostname == short name c) dhcp : same as a) (fqdn) I can elaborate on that like this : a) as man said NM sets hostname "with the one provided via DHCP", which is first the short one (step1) then as a static profile is activated, it falls back to "hostname from the reverse lookup of the IP address" (which DNS resolves in the fqdn) b) : NM just don't play with the transient name and sets a static hostname coming from /etc/sysconfig/network c) confuses me as the manual says NM "will update the transient hostname only with information coming from DHCP" but with no fallback So I was expecting after step 2 to have localhost.localdomain or only the short name but not the fqdn Or maybe it builds a fqdn from host-name + domain coming from DHCP ? Can you help me figuring out my misunderstanding ? Thanks for your help -- Thomas HUMMEL ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager, dns= and resolv.conf override
Hello, I just experienced the situation described below again. Still don't know why NM would behave differently if resolv.conf first came via dhcp. Thanks for your help. -- TH On 3/23/20 10:59 AM, Thomas HUMMEL wrote: On 3/16/20 4:56 PM, Thomas HUMMEL wrote: Hello actually I was able to reproduce the thing in a simplier way: Hello, did you have the time to look into this ? thanks. -- TH. 0/ I'm starting from here ## - configuration : no 'dns=' directive : - an auto profile - a manual profile (active) - an empty /etc/resolv.conf # grep -i dns /etc/NetworkManager/NetworkManager.conf /etc/NetworkManager/conf.d/* /etc/NetworkManager/conf.d/pasteur.conf:#dns=none # cat /etc/sysconfig/network-scripts/ifcfg-enp33s0f0 DEVICE=enp33s0f0 BOOTPROTO=dhcp HWADDR=ac:1f:6b:c8:ee:16 ONBOOT=yes # cat /etc/sysconfig/network-scripts/ifcfg-xcat-enp33s0f0 TYPE=Ethernet PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=none IPADDR=192.168.152.3 PREFIX=20 DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=xcat-enp33s0f0 UUID=9b43d5ac-0c92-4dcf-b1b2-113ee146c052 DEVICE=enp33s0f0 ONBOOT=yes AUTOCONNECT_PRIORITY=9 MTU=1500 # nmcli con show NAME UUID TYPE DEVICE xcat-enp33s0f0 6830dc55-e121-4c10-8b64-cf692f063505 ethernet enp33s0f0 ib0 2ab4abde-b8a5-6cbc-19b1-2bfb193e4e89 infiniband ib0 System enp33s0f0 03a3d6a6-33d2-bba1-f78c-e1d7861520ba ethernet -- # cat /etc/resolv.conf # Generated by NetworkManager 1/ deactivate active connection - auto profile takes over, gets dns params via dhcp # nmcli con down xcat-enp33s0f0 Connection 'xcat-enp33s0f0' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3) # nmcli con show NAME UUID TYPE DEVICE System enp33s0f0 03a3d6a6-33d2-bba1-f78c-e1d7861520ba ethernet enp33s0f0 ib0 2ab4abde-b8a5-6cbc-19b1-2bfb193e4e89 infiniband ib0 xcat-enp33s0f0 9b43d5ac-0c92-4dcf-b1b2-113ee146c052 ethernet -- # cat /etc/resolv.conf # Generated by NetworkManager search maestro.pasteur.fr nameserver 192.168.149.101 nameserver 192.168.149.102 2/ reactivate manual connection empties /etc/resolv.conf # - manual profile takes over - /etc/resolv.conf is emptied # nmcli con up xcat-enp33s0f0 Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/7) # nmcli con show NAME UUID TYPE DEVICE xcat-enp33s0f0 9b43d5ac-0c92-4dcf-b1b2-113ee146c052 ethernet enp33s0f0 ib0 2ab4abde-b8a5-6cbc-19b1-2bfb193e4e89 infiniband ib0 System enp33s0f0 03a3d6a6-33d2-bba1-f78c-e1d7861520ba ethernet -- # cat /etc/resolv.conf # Generated by NetworkManager 3/ manually write /etc/resolv.conf and reactivate the manual connection # - manual connection is reactivated - leaves /etc/resolv.conf untouched # cat < /etc/resolv.conf > search maestro.pasteur.fr > nameserver 192.168.149.101 > nameserver 192.168.149.102 > EOF # cat /etc/resolv.conf search maestro.pasteur.fr nameserver 192.168.149.101 nameserver 192.168.149.102 # nmcli con show NAME UUID TYPE DEVICE xcat-enp33s0f0 9b43d5ac-0c92-4dcf-b1b2-113ee146c052 ethernet enp33s0f0 ib0 2ab4abde-b8a5-6cbc-19b1-2bfb193e4e89 infiniband ib0 System enp33s0f0 03a3d6a6-33d2-bba1-f78c-e1d7861520ba ethernet -- # nmcli con up xcat-enp33s0f0 Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/8) # cat /etc/resolv.conf search maestro.pasteur.fr nameserver 192.168.149.101 nameserver 192.168.149.102 Can you help me understand what seems to be an inconsistent behavior regarding override of /etc/resolv.conf ? Thanks -- Thomas HUMMEL ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager, dns= and resolv.conf override
On 3/16/20 4:56 PM, Thomas HUMMEL wrote: Hello actually I was able to reproduce the thing in a simplier way: Hello, did you have the time to look into this ? thanks. -- TH. 0/ I'm starting from here ## - configuration : no 'dns=' directive : - an auto profile - a manual profile (active) - an empty /etc/resolv.conf # grep -i dns /etc/NetworkManager/NetworkManager.conf /etc/NetworkManager/conf.d/* /etc/NetworkManager/conf.d/pasteur.conf:#dns=none # cat /etc/sysconfig/network-scripts/ifcfg-enp33s0f0 DEVICE=enp33s0f0 BOOTPROTO=dhcp HWADDR=ac:1f:6b:c8:ee:16 ONBOOT=yes # cat /etc/sysconfig/network-scripts/ifcfg-xcat-enp33s0f0 TYPE=Ethernet PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=none IPADDR=192.168.152.3 PREFIX=20 DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=xcat-enp33s0f0 UUID=9b43d5ac-0c92-4dcf-b1b2-113ee146c052 DEVICE=enp33s0f0 ONBOOT=yes AUTOCONNECT_PRIORITY=9 MTU=1500 # nmcli con show NAME UUID TYPE DEVICE xcat-enp33s0f0 6830dc55-e121-4c10-8b64-cf692f063505 ethernet enp33s0f0 ib0 2ab4abde-b8a5-6cbc-19b1-2bfb193e4e89 infiniband ib0 System enp33s0f0 03a3d6a6-33d2-bba1-f78c-e1d7861520ba ethernet -- # cat /etc/resolv.conf # Generated by NetworkManager 1/ deactivate active connection - auto profile takes over, gets dns params via dhcp # nmcli con down xcat-enp33s0f0 Connection 'xcat-enp33s0f0' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3) # nmcli con show NAME UUID TYPE DEVICE System enp33s0f0 03a3d6a6-33d2-bba1-f78c-e1d7861520ba ethernet enp33s0f0 ib0 2ab4abde-b8a5-6cbc-19b1-2bfb193e4e89 infiniband ib0 xcat-enp33s0f0 9b43d5ac-0c92-4dcf-b1b2-113ee146c052 ethernet -- # cat /etc/resolv.conf # Generated by NetworkManager search maestro.pasteur.fr nameserver 192.168.149.101 nameserver 192.168.149.102 2/ reactivate manual connection empties /etc/resolv.conf # - manual profile takes over - /etc/resolv.conf is emptied # nmcli con up xcat-enp33s0f0 Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/7) # nmcli con show NAME UUID TYPE DEVICE xcat-enp33s0f0 9b43d5ac-0c92-4dcf-b1b2-113ee146c052 ethernet enp33s0f0 ib0 2ab4abde-b8a5-6cbc-19b1-2bfb193e4e89 infiniband ib0 System enp33s0f0 03a3d6a6-33d2-bba1-f78c-e1d7861520ba ethernet -- # cat /etc/resolv.conf # Generated by NetworkManager 3/ manually write /etc/resolv.conf and reactivate the manual connection # - manual connection is reactivated - leaves /etc/resolv.conf untouched # cat < /etc/resolv.conf > search maestro.pasteur.fr > nameserver 192.168.149.101 > nameserver 192.168.149.102 > EOF # cat /etc/resolv.conf search maestro.pasteur.fr nameserver 192.168.149.101 nameserver 192.168.149.102 # nmcli con show NAME UUID TYPE DEVICE xcat-enp33s0f0 9b43d5ac-0c92-4dcf-b1b2-113ee146c052 ethernet enp33s0f0 ib0 2ab4abde-b8a5-6cbc-19b1-2bfb193e4e89 infiniband ib0 System enp33s0f0 03a3d6a6-33d2-bba1-f78c-e1d7861520ba ethernet -- # nmcli con up xcat-enp33s0f0 Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/8) # cat /etc/resolv.conf search maestro.pasteur.fr nameserver 192.168.149.101 nameserver 192.168.149.102 Can you help me understand what seems to be an inconsistent behavior regarding override of /etc/resolv.conf ? Thanks -- Thomas HUMMEL ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager, dns= and resolv.conf override
Hello Thomas, actually I was able to reproduce the thing in a simplier way: 0/ I'm starting from here ## - configuration : no 'dns=' directive : - an auto profile - a manual profile (active) - an empty /etc/resolv.conf # grep -i dns /etc/NetworkManager/NetworkManager.conf /etc/NetworkManager/conf.d/* /etc/NetworkManager/conf.d/pasteur.conf:#dns=none # cat /etc/sysconfig/network-scripts/ifcfg-enp33s0f0 DEVICE=enp33s0f0 BOOTPROTO=dhcp HWADDR=ac:1f:6b:c8:ee:16 ONBOOT=yes # cat /etc/sysconfig/network-scripts/ifcfg-xcat-enp33s0f0 TYPE=Ethernet PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=none IPADDR=192.168.152.3 PREFIX=20 DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=xcat-enp33s0f0 UUID=9b43d5ac-0c92-4dcf-b1b2-113ee146c052 DEVICE=enp33s0f0 ONBOOT=yes AUTOCONNECT_PRIORITY=9 MTU=1500 # nmcli con show NAME UUID TYPE DEVICE xcat-enp33s0f06830dc55-e121-4c10-8b64-cf692f063505 ethernet enp33s0f0 ib0 2ab4abde-b8a5-6cbc-19b1-2bfb193e4e89 infiniband ib0 System enp33s0f0 03a3d6a6-33d2-bba1-f78c-e1d7861520ba ethernet-- # cat /etc/resolv.conf # Generated by NetworkManager 1/ deactivate active connection - auto profile takes over, gets dns params via dhcp # nmcli con down xcat-enp33s0f0 Connection 'xcat-enp33s0f0' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3) # nmcli con show NAME UUID TYPE DEVICE System enp33s0f0 03a3d6a6-33d2-bba1-f78c-e1d7861520ba ethernet enp33s0f0 ib0 2ab4abde-b8a5-6cbc-19b1-2bfb193e4e89 infiniband ib0 xcat-enp33s0f09b43d5ac-0c92-4dcf-b1b2-113ee146c052 ethernet-- # cat /etc/resolv.conf # Generated by NetworkManager search maestro.pasteur.fr nameserver 192.168.149.101 nameserver 192.168.149.102 2/ reactivate manual connection empties /etc/resolv.conf # - manual profile takes over - /etc/resolv.conf is emptied # nmcli con up xcat-enp33s0f0 Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/7) # nmcli con show NAME UUID TYPE DEVICE xcat-enp33s0f09b43d5ac-0c92-4dcf-b1b2-113ee146c052 ethernet enp33s0f0 ib0 2ab4abde-b8a5-6cbc-19b1-2bfb193e4e89 infiniband ib0 System enp33s0f0 03a3d6a6-33d2-bba1-f78c-e1d7861520ba ethernet-- # cat /etc/resolv.conf # Generated by NetworkManager 3/ manually write /etc/resolv.conf and reactivate the manual connection # - manual connection is reactivated - leaves /etc/resolv.conf untouched # cat < /etc/resolv.conf > search maestro.pasteur.fr > nameserver 192.168.149.101 > nameserver 192.168.149.102 > EOF # cat /etc/resolv.conf search maestro.pasteur.fr nameserver 192.168.149.101 nameserver 192.168.149.102 # nmcli con show NAME UUID TYPE DEVICE xcat-enp33s0f09b43d5ac-0c92-4dcf-b1b2-113ee146c052 ethernet enp33s0f0 ib0 2ab4abde-b8a5-6cbc-19b1-2bfb193e4e89 infiniband ib0 System enp33s0f0 03a3d6a6-33d2-bba1-f78c-e1d7861520ba ethernet-- # nmcli con up xcat-enp33s0f0 Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/8) # cat /etc/resolv.conf search maestro.pasteur.fr nameserver 192.168.149.101 nameserver 192.168.149.102 Can you help me understand what seems to be an inconsistent behavior regarding override of /etc/resolv.conf ? Thanks -- Thomas HUMMEL ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager, dns= and resolv.conf override
On 3/16/20 1:30 PM, Thomas Haller wrote: I am not sure from the description. To be sure level=TRACE logging and check the logfile. But I think the reason is that NetworkManager doesn't want to write an empty /etc/resolv.conf file. If Networkmanager has no nameservers, it doesn't seem very useful to enforce that /etc/resolv.conf is empty. Granted but what I saw after the xCAT postscript run is an "empty" /etc/resolv.conf including however the first comment line "# Generated by NetworkManager". Thus my idea that it is indeed NM which wrote it. And I don't think the initial resolv.conf (coming from dhcp/pxe) isn't correct... I'll try to adapt the netboot image to include TRACE level. I'll keep you informed. Either, /etc/resolv.conf is already empty, then there is no effect. Or, /etc/resolv.conf happens to contain correct name servers, then clearing the file only breaks something that otherwise would work. That makes sense (and could fully explain what I'm experiencing afterwards which is event without none, nothing gets overriden)... Thanks -- Thomas Hummel ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager, dns= and resolv.conf override
On 3/12/20 2:05 PM, Thomas HUMMEL wrote: Hello Thomas, Hello everybody, In short : in a setup where I don't state any 'dns=' NM directive, I don't understand why /etc/resolv.conf (file, not symlink) is not overriden. Sorry to insist : any insight about this ? thanks for your help... I'm running CentOS-8.1 on HPC compute nodes provisionned by the xCAT software. Basically nodes PXE-boot and download a stateless CentOS-8.1 image. xCAT provides a so called 'postscript' mechanism (called confignetwork -s) to turn the dynamically (DHCP) assigned node's ip address into a static ip address. It does this by creating an additionnal NM profile with higher autoconnect priority. for instance : - profile initially retrieved by PXE/DHCP : # cat /etc/sysconfig/network-scripts/ifcfg-enp33s0f0 DEVICE=enp33s0f0 BOOTPROTO=dhcp HWADDR=ac:1f:6b:c8:ee:16 ONBOOT=yes - higher priority profile after xCAT 'confignetwork -s' script is run : # cat /etc/sysconfig/network-scripts/ifcfg-xcat-enp33s0f0 TYPE=Ethernet PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=none IPADDR=192.168.152.3 PREFIX=20 DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=xcat-enp33s0f0 UUID=9de3e814-a286-44e9-b66d-3cc14694d808 DEVICE=enp33s0f0 ONBOOT=yes AUTOCONNECT_PRIORITY=9 MTU=1500 # Expected and working behavios : What I experienced is that first the node gets via DHCP, as expected, a working /etc/resolv.conf file and then after xCAT confignetwork -s postscript is run, the new profile is loaded and up but /etc/resolv.conf is empty as, as can be seen above, the profile does not provide any dns properties. I worked around this by adding 'dns=none' in a NetworkManager .conf file. And it worked : the /etc/resolv.conf file initially written by DHCP was left untouched. # Unexpected and unexplained behavior : What I don't understand is that, then if I manually remove the 'dns=none' setting and either restart NM and/or reload+reactivate the profile, /etc/resolv.conf is not, as I was expecting, emptied by NM. Can you help me figure out what I am missing ? Thanks for your help -- Thomas HUMMEL ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager, dns= and resolv.conf override
On 3/12/20 2:05 PM, Thomas HUMMEL wrote: I forgot a silly question : is it legit to have in conf.d/foobar.conf another, let's say [main] section : will it be merged with the one in NetworkManager.conf ? Thanks -- TH ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager, dns= and resolv.conf override
Hello Thomas, Hello everybody, In short : in a setup where I don't state any 'dns=' NM directive, I don't understand why /etc/resolv.conf (file, not symlink) is not overriden. I'm running CentOS-8.1 on HPC compute nodes provisionned by the xCAT software. Basically nodes PXE-boot and download a stateless CentOS-8.1 image. xCAT provides a so called 'postscript' mechanism (called confignetwork -s) to turn the dynamically (DHCP) assigned node's ip address into a static ip address. It does this by creating an additionnal NM profile with higher autoconnect priority. for instance : - profile initially retrieved by PXE/DHCP : # cat /etc/sysconfig/network-scripts/ifcfg-enp33s0f0 DEVICE=enp33s0f0 BOOTPROTO=dhcp HWADDR=ac:1f:6b:c8:ee:16 ONBOOT=yes - higher priority profile after xCAT 'confignetwork -s' script is run : # cat /etc/sysconfig/network-scripts/ifcfg-xcat-enp33s0f0 TYPE=Ethernet PROXY_METHOD=none BROWSER_ONLY=no BOOTPROTO=none IPADDR=192.168.152.3 PREFIX=20 DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no IPV6_ADDR_GEN_MODE=stable-privacy NAME=xcat-enp33s0f0 UUID=9de3e814-a286-44e9-b66d-3cc14694d808 DEVICE=enp33s0f0 ONBOOT=yes AUTOCONNECT_PRIORITY=9 MTU=1500 # Expected and working behavios : What I experienced is that first the node gets via DHCP, as expected, a working /etc/resolv.conf file and then after xCAT confignetwork -s postscript is run, the new profile is loaded and up but /etc/resolv.conf is empty as, as can be seen above, the profile does not provide any dns properties. I worked around this by adding 'dns=none' in a NetworkManager .conf file. And it worked : the /etc/resolv.conf file initially written by DHCP was left untouched. # Unexpected and unexplained behavior : What I don't understand is that, then if I manually remove the 'dns=none' setting and either restart NM and/or reload+reactivate the profile, /etc/resolv.conf is not, as I was expecting, emptied by NM. Can you help me figure out what I am missing ? Thanks for your help -- Thomas HUMMEL ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nmcli connection down
On 11/13/18 4:13 PM, Thomas Haller wrote: Maybe. But the moment when you issue $ nmcli connection down "$PROFILE" the "$PROFILE" is in the process of deactivating. It's not yet fully deactivated. Hence, it is "the profile which is currently deactivating". Seems correct to me as-is, but no strong preference. WDYT? Ok. Me neither. I guess I said that because of the way the original sentence was written : " Thisincludes the just deactivated connection. So if the connection is set to auto-connect, it will be automatically started on the disconnected device again." I prefer your patch since it is technically accurate ;-) Talking about nmcli(1) man, I found this part unclear (to me at last) and only our previous discussions had me figure it out : "You can also specify particular fields. For static configuration, use setting and property names as described in nm-settings(5) manual page. For active data use GENERAL, IP4, DHCP4, IP6, DHCP6, VPN." To me, someone issuing 'nmcli device show' vs 'nmcli connection show' would deduce concerning properties that uppercase vs lowercase is a matter of device vs profile, not static vs active (the ambiguous term to me here is static). My understanding now is that device is just another way to say active or applied. However, even a disconnect device has got some GENERAL.* uppercase properties. To add to the confusion (mine at least), many nmcli connection add examples I saw, including nmcli-examples(7) use ip4, gw4 (not the same name as in nm-settings(5) and in lowercase) while to me using, ipv4.*, at least for nmcli connection add would do the same ? If you see what I mean. Keep in mind I might be mistaking and I might have missed a basic understanding ;-) For now in my mind is the following : upper case : applied profile, lowercase : profile (applied or not). Otherwise, I did write a quite long or not so short web page (markdown in our documentation software) doing a hopefully detailed and accurate reference about what we've talked together and more generally about the concepts we evoked. It was meant for myself and my team as a reference and holds the following sections : How to configure Network on a CentOS 7 system I. iproute2 - the manual method II. network scripts - the old method II.1 overview II.2 Details III. NetworkManager - the new method III.1 Service launch III.2 Concepts III.3 Devices : properties III.4 Profiles: properties III.5 Active connection creation III.7 Active connection modification III.7.1 "normal" profile modification III.7.2 applying changes III.7.3 volatile modifications III.7.4 Examples III.8 Persisting profiles / plugins III.8.1 keyfile plugin III.8.2 CentOS case III.8.3 Debian case III.9 Device discovery III.9.1 sysfs attributes III.9.2 udev(7) properties III.9.3 udev and NetworkManager III.10 management III.10.1 unmanaged III.10.2 managed III.10.3 externally managed III.11. profile autocreation III.10.1 execption 1 III.10.2.exception 2 III.10.3 exception 3 III.10.4 exception 4 IV. profile autoconnection IV.1 profile IV.2 device IV.3 autocreate/autoconnect IV.4 ethernet auto profile case V. return to the externally managed case (2 examples) VI dispatcher scripts X state directory It is quite informal and at the granularity level of what I asked here and almost wired ethernet only oriented. Would you be interested I translate it (from french to english) and send it to you in order for you to see if it can be of any help for anyone on any form (I don't have any blog myself) ? [don't look at the section numbering I just read I did not accurately copied it while writing this message, but you've got the idea ;-)] -- Thomas HUMMEL ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nmcli connection down
On 11/13/18 1:56 PM, Thomas Haller wrote: I think this is just a documentation bug. Fixed: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=17f9801e07df0c544e0416c65cedc28727476e55 Thanks for actually reading the documentation and pointing out confusing/wrong parts!! Thanks for your time. By the way : isn't there a typo in your path ? + Note that the deactivating connection profile is + internally blocked from autoconnecting again didn't you mean deactivatED ? -- TH ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
dns-search ordering on dual nic setup
Hello, [I'm talking only about ipv4.method=manual wired ethernet connections here] As far as I experience, the 'search' line in the NetworkManager resolv.conf file comes from the union of all the ipv4.dns-search properties of all the active profiles and the order of the domains it lists doesn't depend on the order of profile activation. - am I right ? - does the order then depend on the order of the underlying devices (i.e. dns-search of eth0 first, dns-search of eth1 second, ...) ? What would be the best way to enforce a particular order ? For instance let's say eth0 profile : ipv4.dns-search my.public.domain eth1 profile : ipv4.dns-search some.private.non-routed-domain By default, it seems that when the 2 profiles are connected, I've got search my.public.domain some.private.non-routed-domain in /etc/resolv.conf What if I want the opposite order ? Note : the idea here is to have the short non-qualified host name as the hostname and make hostname --fqdn return .some.private-non-routed.domain Thanks -- Thomas HUMMEL ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
nmcli connection down
Hello, nmcli(1) states about the connection down command : "Be aware that this command deactivates the specified active connection, but the device on which the connection was active, is still ready to connect and will perform auto-activation by looking for a suitable connection that has the 'autoconnect' flag set. This includes the just deactivated connection. So if the connection is set to auto-connect, it will be automatically started on the disconnected device again." In the following simple test : # ls -l /var/lib/NetworkManager/no-auto-default.state -rw-r--r-- 1 root root 0 Nov 8 16:25 /var/lib/NetworkManager/no-auto-default.state # nmcli connection delete foobar Connection 'foobar' (eedc4b58-5a81-45e9-9cac-586f9f25f61d) successfully deleted. # nmcli connection add type ethernet con-name foobar ifname eth1 Connection 'foobar' (1c34b34b-f3ab-4d7d-8a19-3fdf618a16f3) successfully added. # nmcli -f connection.autoconnect connection show foobar connection.autoconnect: yes # nmcli -f GENERAL.AUTOCONNECT device show eth1 GENERAL.AUTOCONNECT:yes # nmcli connection down foobar Connection 'foobar' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2) # nmcli connection show NAMEUUID TYPE DEVICE foobar 1c34b34b-f3ab-4d7d-8a19-3fdf618a16f3 ethernet -- # ip address show dev eth1 3: eth1: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:50:56:8a:42:bf brd ff:ff:ff:ff:ff:ff it seems to me I'd qualified to the "This includes the just deactivated connection." case ? So why doesn't the device auto-reconnects ? Thanks -- Thomas HUMMEL ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
Hello, I was playing with the externally managed concept and I experienced the following : modifying an autocreated/autoconnected profile corresponding to an externally managed device seems to be (silently) auto-reapplied. Afterward, once NetworkManager takes over (and really manages the device), everything is back to normal. Is this a legit/normal situation ? Ex : # ip address add 192.168.10.200/24 dev eth1 # nmcli connexion modify eth1 802-3-ethernet.mtu 9000 # ip addr shows eth1 has changed its mtu for 9000, no device reapplied or connexion up has been needed and no message (as in nmcli device modify) telling anything has been reapplied. My guess is that's normal since telling a profile has been reapplied would imply that de device is (normally) managed...Since behavior surprised me. Thanks -- TH ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On 10/26/18 12:55 PM, Thomas HUMMEL wrote: Generally, there are the device states "unmanaged" -> "unavailable" -> and "disconnected". For ethernet devices, a device is usually "unavailable" because it has no carrier. As a matter of fact, when no udev rules for NM_UNMANAGED, the device is in the disconnected state. As for the traces, here's what I've got : Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5859] ifcfg-rh: loading from file "/etc/sysconfig/network-scripts/ifcfg-eth0"... Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5861] settings-connection[0x7fbffc006890]: constructed (NMIfcfgConnection) Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5870] settings-connection[0x7fbffc006890,5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03]: update settings-connection flags to visible (was none) Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5875] settings-connection[0x7fbffc006890,5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03]: disposing Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5878] settings-connection[0x7fbffc006890,5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03]: update settings-connection flags to none (was visible) Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6729] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6752] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6771] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6790] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6809] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6827] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6845] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6865] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6883] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0031] device[0x55a73f560c80] (eth1): sys-iface-state: external -> assume Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0033] device[0x55a73f560c80] (eth1): unmanaged: flags set to [user-udev,!sleeping,!loopback,!platform-init,!user-explicit,!user-settings=0x400/0x479/managed], Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0033] device (eth1): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'assume') Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0034] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/accept_ra': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0035] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/accept_ra_defrtr': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0035] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/accept_ra_pinfo': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0035] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/accept_ra_rtr_pref': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0036] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/forwarding': '0' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0036] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/disable_ipv6': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0036] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/hop_limit': '64' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0037] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/use_tempaddr': '0' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0039] device[0x55a73f560c80] (eth1): device not yet available for transition to DISCONNECTED Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0041] create NMAuditManager singleton (0x7fbffc00d0f0) Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0042] audit: op="device-managed" arg="managed:1"
Re: NetworkManager behavior answers not found in docs
On 10/25/2018 03:47 PM, Thomas Haller wrote: For example, nmcli connection up "$PROFILE" ifname "$DEVICE" nmcli connection modify "$PROFILE" +ipv4.addresses 192.168.77.5/24 nmcli device reapply "$DEVICE" is basically the same as: nmcli connection up "$PROFILE" ifname "$DEVICE" nmcli connection modify "$PROFILE" +ipv4.addresses 192.168.77.5/24 nmcli device modify "$DEVICE" +ipv4.addresses 192.168.77.5/24 Got it. I guess that's what you meant by your cloned/invisible live-in-ram active profile previously. My understanding now is that device modify just modify an internal copy of the profile and then automatically calls apply on it, correct ? Thanks -- Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On 10/25/2018 03:47 PM, Thomas Haller wrote: Remember, that a modification of the profile (`nmcli connection modify`) does not take effect immeiately (except "connection.zone" and "connection.metered" properties). You usually need to do a full re- activation for the changes to take effect (`nmcli connection up`). Oh yes, I was confusing device and connection modify, sorry. Though what you said above just makes me think about the connection reload command. Granted you're not supposed to manually edit connection files but my understanding and experience is that if you do and then nmcli connection reload, you still have to reactivate the connection with nmcli connection up. So I don't quite understand the use of reloading ? Thanks -- Thomas. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
Generally, there are the device states "unmanaged" -> "unavailable" -> and "disconnected". For ethernet devices, a device is usually "unavailable" because it has no carrier. As a matter of fact, when no udev rules for NM_UNMANAGED, the device is in the disconnected state. As for the traces, here's what I've got : Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5859] ifcfg-rh: loading from file "/etc/sysconfig/network-scripts/ifcfg-eth0"... Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5861] settings-connection[0x7fbffc006890]: constructed (NMIfcfgConnection) Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5870] settings-connection[0x7fbffc006890,5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03]: update settings-connection flags to visible (was none) Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5875] settings-connection[0x7fbffc006890,5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03]: disposing Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.5878] settings-connection[0x7fbffc006890,5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03]: update settings-connection flags to none (was visible) Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6729] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6752] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6771] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6790] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6809] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6827] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6845] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6865] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:44:04 xcat-myriad NetworkManager[606]: [1540550644.6883] platform-linux: event-notification: RTM_NEWROUTE, flags 0, seq 1540550645: ignore Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0031] device[0x55a73f560c80] (eth1): sys-iface-state: external -> assume Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0033] device[0x55a73f560c80] (eth1): unmanaged: flags set to [user-udev,!sleeping,!loopback,!platform-init,!user-explicit,!user-settings=0x400/0x479/managed], Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0033] device (eth1): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'assume') Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0034] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/accept_ra': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0035] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/accept_ra_defrtr': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0035] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/accept_ra_pinfo': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0035] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/accept_ra_rtr_pref': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0036] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/forwarding': '0' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0036] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/disable_ipv6': '1' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0036] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/hop_limit': '64' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0037] platform-linux: sysctl: reading '/proc/sys/net/ipv6/conf/eth1/use_tempaddr': '0' Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0039] device[0x55a73f560c80] (eth1): device not yet available for transition to DISCONNECTED Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0041] create NMAuditManager singleton (0x7fbffc00d0f0) Oct 26 12:47:03 xcat-myriad NetworkManager[606]: [1540550823.0042] audit: op="device-managed" arg="managed:1" pid=1360 uid=0 result="success" corresponding to those actions : # ip link show eth1 3: eth1: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:50:56:8a:42:bf brd ff:ff:ff:ff:ff:ff # nmcli -f GENERAL.NM-MANAGED device show eth1 GENERAL.NM-MANAGED: no # nmcli -f
Re: NetworkManager behavior answers not found in docs
On 10/26/2018 10:05 AM, Thomas Haller wrote: The return value of the nmcli command is odd, maybe a bug. In any event, it may be confusing for the user or a script indeed which then could legitimely think the managed request succeeded. It returns success, because it successfully flagged the device that the user wishes to manage it. However, there may still be other (stronger) reasons, why the device stays unmanaged (NM_CONTROLLED=no). ok Ah, there is also `nmcli -f GENERAL.NM-MANAGED device show eth0 `, but this just returns (state != "unmanaged"). Wait : what's the diffence (if any) between GENERAL.NM-MANAGED == no and GENERAL.STATE == 10 (unmanaged) ? Optimally, there would be a nother flag which is the opposite of `nmcli device set $DEV managed $VALUE`. So, when you issue device-set, it would succeed and would toggle this flag, but that alone may not be sufficient to make the device (fully) GENERAL.NM-MANAGED yet. I don't see what you mean here by "the opposite" : maybe just a flag to reflect the request (and its ack) of the desire to manage the device ? # nmcli device set eth1 managed yes # echo $? 0 # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show GENERAL.DEVICE: eth1 GENERAL.STATE: 20 (unavailable) state "unavailable", looks like the device has no cable plugged in (no carrier). You'd also see that with `ip link show eth1` saying "NO- CARRIER". Well, it's a VMWare virtual interface but 'connected' in VMWare and iproute shows : 3: eth1: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:50:56:8a:42:bf brd ff:ff:ff:ff:ff:ff It seems normal to me the device is down since no one as configured it. But it seems I'm in a different case than no carrier'... Maybe I'm supposed to see a LOWER_DOWN ? Activation of the created profile then probably fails, because the device has no carrier (which is required for successful DHCP). Obviously the reason here is that the device is still unavailable but the question is why ? ;-) -> ok, seems normal to as well since auto profile creation must not work under NM_UNMANAGED conditions no, I think this part of the manual is misleading. A device is either "unmanaged" or not. Udev's NM_UNMANAGED is a way to configure the device as unmanaged, and `nmcli device set $DEV managed yes` can overrule that. Aterwards, there is no further difference between other managed devices. Ok, that's indeed what I understood first. Thanks -- Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On 10/18/2018 11:30 PM, Thomas Haller wrote: Btw, note that if you configure the device as unmanaged via NM_CONTROLLED=no in ifcfg, then the device cannot be set to managed. This way of unmanaging a device is definite, Hello again, another use case I'm still wrapping my head around (even with the precious knowledge acquired thanks to your help!) Let's say I've got this setup : - eth0 NM_CONTROLLED=no - eth1 NM_UNMANAGED=1 via udev (and suppose eth1 in no-auto-default.state) here's what I'm testing - about NM_CONTROLLED=no : # nmcli connection show NAME UUID TYPE DEVICE # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show GENERAL.DEVICE: eth0 GENERAL.STATE: 10 (unmanaged) GENERAL.DEVICE: eth1 GENERAL.STATE: 10 (unmanaged) GENERAL.DEVICE: lo GENERAL.STATE: 10 (unmanaged) # nmcli device set eth0 managed yes # echo $? 0 # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show GENERAL.DEVICE: eth0 GENERAL.STATE: 10 (unmanaged) -> as you explained, unmanaging a device this way is definite, but is the 0 return value legit here ? - about the following sentence in man regarding NM_UNMANAGED : "You will still be able to attach a connection to the device manually or observe externally added configuration such as addresses or routes." # nmcli device set eth1 managed yes # echo $? 0 # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show GENERAL.DEVICE: eth1 GENERAL.STATE: 20 (unavailable) -> it's not unmanaged anymore, so it's managed # nmcli connection show NAME UUID TYPE DEVICE -> still no connection, seems normal to me # nmcli device connect eth1 Error: Failed to add/activate new connection: Connection 'eth1' is not available on the device eth1 at this time. -> ok, seems normal to as well since auto profile creation must not work under NM_UNMANAGED conditions # nmcli connection add type ethernet con-name managed-eth1 ifname eth1 Connection 'managed-eth1' (41727fca-d424-40d9-91e7-55197ff9a962) successfully added. # nmcli connection show NAME UUID TYPE DEVICE managed-eth1 41727fca-d424-40d9-91e7-55197ff9a962 ethernet -- -> ok I managed to create a connection somehow linked to eth1 device. It's not active which also seems normal to me But then I cannon neither connect the eth1 device nor activate the newly created profile -> what's happening here ? Thanks -- Thomas H. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On 10/25/2018 03:05 PM, Thomas Haller wrote: On Thu, 2018-10-25 at 14:58 +0200, Thomas HUMMEL wrote: On 10/24/2018 01:19 PM, Thomas Haller wrote: Both the device and the profile must be willing to autoconnect for it to happen. It's both ways. That's why you can suppress autoconnect on both sides. Also, how can I check the status of a device autoconnect flag (as set by nmcli device set autoconnect) ? hi that would be: nmcli -f GENERAL.AUTOCONNECT device show "$DEVICE" Indeed. How is it that I don't see that property with a simple single nmcli device show ? Thanks -- Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On 10/24/2018 01:19 PM, Thomas Haller wrote: Both the device and the profile must be willing to autoconnect for it to happen. It's both ways. That's why you can suppress autoconnect on both sides. Also, how can I check the status of a device autoconnect flag (as set by nmcli device set autoconnect) ? Thanks -- Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On 10/24/2018 06:22 PM, Thomas Haller wrote: Let's call this "externally managed". Not sure that's helpful, but in NetworkManager source code it's called like that. In nmcli output, you cannot really distinguish a regular activated profile from such an externally managed one. Except, that in the latter case the profiles was autocreated and its name is the device name (eth1). Understood. Now if I edit this connection matching an externally managed device (for instance using nmcli connection edit), would that turn it into a normally managed one ? Thanks -- Thomas Hummel ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On 10/24/2018 04:11 PM, Thomas HUMMEL wrote: Reapply doesn't seem to have any relevance with modification or persistance. Yes so now my understanding of reapply is more like "restore" (to its original settings). Does this make sense even with non disk backed applied profiled (I guess that's what you tried to explain to me in a previous message where you were talking about a clone of the profile). In fact I don't understand reapply anymore : - it doesn't affect the profile - a nmcli device modify (802-3-ethernet.mtu for instance) seems to immediatly (re)apply the change I'm doing to the active profile. So, I don't understand anymore when I'm supposed to issue a nmcli device reapply ? Thank you -- TH ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On 10/24/2018 01:14 PM, Thomas Haller wrote: Hm, `nmcli device reapply` does not modify the profile at all, does it? Correct. Sorry, I did so many tests that I misinterpreted this one. Reapply doesn't seem to have any relevance with modification or persistance. Yes so now my understanding of reapply is more like "restore" (to its original settings). Does this make sense even with non disk backed applied profiled (I guess that's what you tried to explain to me in a previous message where you were talking about a clone of the profile). Thanks, -- Thomas H. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On 10/24/2018 01:23 PM, Thomas Haller wrote: Hi, An unmanaged device is in state "unmanaged". All other states (like "100 (connected)") are not-unmanaged, which means they are "managed". $ nmcli -f GENERAL.DEVICE,GENERAL.STATE device show $ nmcli -f GENERAL.DEVICE,GENERAL.STATE device show "$DEVICE" Hello, That's what I thought but on a previously discussed case of an externally configured device, here's what I'm experiencing : # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show eth1 GENERAL.DEVICE: eth1 GENERAL.STATE: 30 (disconnected) # ip addr show eth1 3: eth1: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:50:56:8a:42:bf brd ff:ff:ff:ff:ff:ff # ip addr add 192.168.10.200/24 dev eth1 # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show eth1 GENERAL.DEVICE: eth1 GENERAL.STATE: 100 (connected) But I thought we said that in such a case a profile would be autocreated (and autoconnected) but only to reflect that something is active but which is not going to be managed (like for dhcp requests...) by NM ? Did I misunderstood ? Thanks. -- Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On 10/17/2018 10:38 AM, Thomas Haller wrote: 3) if you do nmcli device disconnect eth0 ip addr add 192.168.7.5/24 dev eth0 NM now creates an in-memory connection "eth0". This means that NetworkManager*does not* manage this device. Among the things I forgot : I understand what you explained but I cannot figure out a way to make nmcli confirm that the device is not managed. For instance : # nmcli -f GENERAL.STATE device show eth1 GENERAL.STATE: 100 (connected) I guess the 'connected' hides the 10 (unmanaged) I can see in different situations ? # nmcli device show eth1 | grep -i managed # ? Thanks -- Thomas H. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On 10/18/2018 11:30 PM, Thomas Haller wrote: The profile has a "connection.autoconnect" property. If it's "no", the profile never autoconnects. Period. But there also needs to be a device which is currently in a state where it would like to autoconnect a profile. With `nmcli device set "$DEVICE" autoconnect no" you can set that. for example, `nmcli device disconnect "$DEVICE"` will block autoconnect on the device. It would be pretty annoying, if you disconnect the device and immediatley some profile autoconnects again. "Autoconnect" prefers profiles which were active last Same remark here When a device wants to autoconnect a profile, there might be multiple profiles which are compatible candidtes. Then, the one is chosen with the best "connection.autoconnect-priority" or as last, the timestamp when the profile was activate the last time. So, would that be correct to think about it this way : it is a device which, by defaults, "wants" to autoconnect and try to find a profile with connection.autoconnect property set to yes ? and device disconnect or device set autoconnect no inhibit this behavior ? I mean as opposed to a profile which would "want" to auto "connect" to a device ? thanks -- Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
Thanks again. Your info are precious ! Some of them should make their way into the official doc to me. Again, a lot to digest but it's getting pretty clear. Usually, NetworkManager (the daemon) does not automatically create connection profiles But when it does (as in your cases), is it always only in RAM (unless we then save the profile to disk of course) ? Yes. But when you modify this profile, it usually gets persisted to disk. I see in my tests that a profile modification is persisted even before the call to nmcli device reapply : am I right ? What's the link between persistence, modification and reapplication of a profile ? Maybe NM created such an "auto-default" (named "Wired Connection #"), but then you deleted it? It wouldn't create it again, see file /var/lib/NetworkManager/no-auto-default.state. The MAC is indeed in there although I don't remember deleting an auto created profile Thanks again! -- Thomas HUMMEL ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
NM have auto created a temp profile and auto connected it for my eth1 ? man nmcli: connect ifname Connect the device. NetworkManager will try to find a suitable connection that will be activated. It will also consider connections that are not set to auto connect. ok. It's not described. That's a documentation bug. So you confirm that unless a device in explictly unmanaged, a device connect would not only look for declared profiles but would also if no suitable profile is found create a temp profile creation and activate it ? test 2 under the same conditions : - reboot of the host - only one connection (eth0) as expected - create the foobar connection like this nmcli connection add type ethernet con-name foobar ifname eth1 -> as expected a ifcgh-rh format connection file has been created in /etc/sysconfig/network-scripts/ifcfg-foobar and nmcli shows 2 connections : eth0 and foobar - manually delete foobar connection file : rm /etc/sysconfig/network-scripts/ifcfg-foobar -> as expected nmcli still shows foobar connection - reload connection files via nmcli connection reload -> as expected nmcli only shows eth0 connection So far, everything seems to work as expected BUT : if instead of nmcli connection reload we RESTART (not reload, but restart) NetworkManager via systemctl restart NetworkManager, ANOTHER (different UUID and eth1 instead of foobar for the name) connection is auto created and auto activated Yes, that is case 3). NM (re) starts and sees the the device is already configured. you mean via the /run state dir we talked about ? It has no configuration for that device You mean no more persistent profile ? Those 2 above facts seems contradictory to me : if the device is "already configured" doesn't it mean that it has some in RAM profile applied ? Then NM hasn' "no configuration for that device" ? , so it assumes somebody else was configuring it and does not touch it. This eth0 device is no longer managed by NetworkManager. For example, it does no DHCP and your addresses will time out. Sorry for the confusion. I'm sure that when sorted out, those concepts are simple ;-) Thank you -- Thomas Hummel ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
I forgot : it seems to me that nmcli connection add also imply "managed" as in nmcli device set managed yes. Am I correct ? Then again when do we need those device commands manipulation ? thanks. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager behavior answers not found in docs
Hello, I'm considering migrating from a CentOS 6 HPC cluster to CentOS 7 one. For this purpose I've read quite a lot of doc (man, guides, ...) about systemctl and NetworkManager to be fluent in their use. Regarding NetworkManager, I've been at first confused by the induced complexity or number of possible mixed old way/native use cases brought by the "network-scripts" compatibility layer provided by the ifcfg-rh plugin. As a matter of fact, I experimented a lot to be sure of who did what and how or when between network-scripts and NetworkManager. Digging deeper, things got clearer. Still I'm not really sure about the points described below. Notes : - I'm running NetworkManager-1.10.2-16.el7_5.x86_64 on a CentOS Linux release 7.5.1804 (Core) - I'm using default settings, so this must be ifcfg-rh plugin first, then keyfile otherwise - I'm talking only about ethernet connections/devices here 1. /run/NetworkManager/devices directory I know NetworkManager exports connections as /org/freedesktop/NetworkManager/Settings/ D-Bus objets What exactly is under /run/NetworkManager/devices/ path ? UUID inside those files don't always match what nmcli shows me ? 2. device vs connection My understanding is that there's a clear distinction between a device and a connection. To be more precise, that an active connection is a set of settings (potentially persisted on disk on a connection file via some plugin) "applied" to a device. The applied part is not very clear to me : What's the difference between connecting a device (nmcli device connect) and activating a connection (nmcli connection up) ? Maybe my confusion comes from the fact that adding a connection automatically connects it to a device ? 3. connection autocreation in what circumstances exactly does NetworkManager autocreate connections ? a) What I found as well is that nmcli connection add...ifname=xxx seems to auto-connect the xxx device to the named interface thus voiding the need to connect the device. Is device connect needed only for special cases, like when we set the NM_UNMANAGED udev property to 1 or do I miss something (refer to question 2 above) Is there a distinction between autocreation vs autoactivation of a connection (if yes in what cases) ? b) auto create and connect when restarted I'm confused about a case where a connection is autocreated and activated at NetworkManager restart while not at boot (twisted case I must admit) : Let's take the following use case as an example : - a host with 2 ethernet devices : eth0 and eth1 - eth0 has a network-script like connection file (/etc/sysconfig/network-scripts/ifcfg-eth0) and is NetworkManager managed (either by default because no "NM_CONTROLLED=no" is stated or explicitly with "NM_CONTROLLED=yes") - eth1 has no connection file (neither ifcfg-rh style nor keyfile style, that is nothing for eth1 neither in /etc/sysconfig/network-scripts nor in /etc/NetworkManager/system-connections) - no NM_UNMANAGED=1 in udev test 1 : -> after boot, as expected eth0 is configured and up, nmcli shows a connection for it but eth1 has no connection. It has to be manually connected for that matter. If done, NetworkManager seems to auto magically CREATE the connection -> where is that magic described ? How does a simple connect CREATES a connection. Man states that connect looks for a matching EXISTING connection ? test 2 under the same conditions : - reboot of the host - only one connection (eth0) as expected - create the foobar connection like this nmcli connection add type ethernet con-name foobar ifname eth1 -> as expected a ifcgh-rh format connection file has been created in /etc/sysconfig/network-scripts/ifcfg-foobar and nmcli shows 2 connections : eth0 and foobar - manually delete foobar connection file : rm /etc/sysconfig/network-scripts/ifcfg-foobar -> as expected nmcli still shows foobar connection - reload connection files via nmcli connection reload -> as expected nmcli only shows eth0 connection So far, everything seems to work as expected BUT : if instead of nmcli connection reload we RESTART (not reload, but restart) NetworkManager via systemctl restart NetworkManager, ANOTHER (different UUID and eth1 instead of foobar for the name) connection is auto created and auto activated I cannot explain why and how this connection is created on restart since no connection is auto created at boot. Granted manually removing the connection file is tricky but even then... Can you help me figure out those points which would complete a bit further my understanding of NetworkManager ? Thanks -- Thomas H. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
