RedHat /Implicit/default connection(s)

Thomas HUMMEL thomas.hummel at pasteur.fr
Fri Apr 26 10:12:55 UTC 2024



On 4/26/24 10:14, Thomas Haller wrote:

> Profiles always exist on disk. See `nmcli -f all connections`. See also
> /{usr/lib,run}/NetworkManager/system-connections

Hello, thanks for your reply. I didn't know that I (wrongfully) thought 
some connections could be transient in ram only (until one decide to 
save them on disk).

You're correct: Wired comes from initrd and System enp33s0f0 comes from 
network-scripts/ifcfg-enp33s0f0. And I indeed confued Wired with Wired #n.

Now I have to understand what created this file as I don't see it 
neither in the image I boot.

Could it be the following scenario :

NM manages anything that is not explicitly set unmanaged and without any 
initial profile (neither in network-scripts nor system-connections) uses 
its internal dhclient-like component and creates this ifcf-enp33s0f0 ?

Sorry for those naive basic questions I just never asked myself although 
I did dig deep into some other sides of NetworkManager...

Note than at this stage I'm not 100% sure my provisionning software 
don't create this in some postbootscript but I doubt it

Thanks for your help

-- 
Thomas HUMMEL

 > enp33s0f0.
> 
>>
>> ifcfg-plugin is commented out in conf but it may be the default for
>> this
>> version as obviously ifcfg-* files are read when set up
> 
> The commented out part informs you about the default.
> 
>>
>> My question is quite naive: I cannot be sure of where those 2
>> profiles
>> come from :
>>
>> 1. Wired Connection: shouldn't no-auto-default=* prevent it to be
>> created ?
> 
> no-auto-default prevents to automatically generate profiles for
> ethernet. Those are always called "Wired connection $NUMBER".
> 
> A profile "Wired Connection" most likely was generated by nm-initrd-
> generator, depending on the kernel command line /proc/cmdline.
> 
> If you don't want that, the simplest way is to adjust your boot command
> line. I guess, you could also generate a initrd that does what you
> want. See also `keep-configuration` and `allowed-connections` setting
> in `man NetworkManager.conf`, which could be used to prevent activating
> those profiles in real-root. It depends on what you want to happen...
> 
> 
>>
>> 2. System enp33s0f0: I'm not sure if this comes from some default
>> (for
>> instance built-in dhcp request) behavior of NM or if the
>> provisionning
>> software I'm using created it.
> 
> It comes probably from file /eyc/sysconfig/network-scripts/ifcfg-
> enp33s0f0.
> 
> Or maybe it was migrated to keyfile. In any case, see `nmcli -f all
> connection` for the FILENAME.
> 
>>
>> Additionnal question:
>>
>> Does NM do anything about profiles set up by its counterpart (which
>> could be NM or not) in initialramfs ?
> 
> If the counter part is not NetworkManager, then somebody else
> configures those interfaces. NetworkManager likely sees that the
> interface is already configured, and generates an "external"
> connection. That is not very useful. NM won't do anything about that
> interface.
> 
> If the counter part is NetworkManager + nm-initrd-generator, then NM in
> initrd configures the interface and leaves suitable configuration
> behind, so that after switch root, NetworkManager takes over the
> configuration again.
> 
>> I guess it could see them as
>> external ?
> 
> External means that somebody else configured the interface. NM tries to
> detect that and not do anything with the interface. Since it's not
> generally possible to detect when somebody uses an interface without
> telling NetworkManager, that doesn't work overly well. If you don't
> want the interface managed by NetworkManager, configure it as
> unmanaged. If you want it managed by NetworkManager, don't configure it
> outside of NetworkManager's knowledge.
> 
>> Does it somehow inherit them making them "internal" ?
> 
> profiles generated by nm-initrd-generator are (usually) in
> /run/NetworkManager/system-connections. They are regular profiles.
> "external" is really the device: when NetworkManager sees that the
> device was already configured by somebody else.
> 
> 
> Thomas
> 


More information about the Networkmanager mailing list