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