mirror of
https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git
synced 2026-01-01 14:10:12 +01:00
5b9bc174d1
The client-id is something that we want to determine top-down. Meaning, if the user specifies it via ipv4.dhcp-client-id, then it should be used. If the user leaves it unspecified, we choose a default stable client-id. For the internal DHCP plugin, this is a node specific client-id based on - the predictable interface name - and /etc/machine-id It's not clear, why we should allow specifying the client-id in the lease file as a third source of configuration. It really pushes the configuration first down (when we do DHCP without lease file), to store an additional bit of configuration for future DHCP attempts. If the machine-id or the interface-name changes, then so does the default client-id. In this case, also "ipv4.dhcp-client-id=stable" changes. It's fair to require that the user keeps the machine-id stable, if the machine identity doesn't change. Also, the lease files are stored in /var/lib/NetworkManager, which is more volatile than /etc/machine-id. So, if we think that machine-id and interface-name is not stable, why would we assume that we have a suitable lease file? Also, if you do: nmcli connection add con-name "$PROFILE" ... ipv4.dhcp-client-id '' nmcli connection up $PROFILE nmcli connection modify "$PROFILE" ipv4.dhcp-client-id mac nmcli connection up $PROFILE nmcli connection modify "$PROFILE" ipv4.dhcp-client-id '' nmcli connection up $PROFILE wouldn't you expect that the original (default) client-id is used again? Also, this works badly with global connection defaults in NetworkManager.conf. If you configure a connection default, previously already this would always force the client-id and overrule the lease. That is reasonable, but in which case would you ever want to use the client-id from the lease? |
||
|---|---|---|
| .. | ||
| cli | ||
| common | ||
| tests | ||
| tui | ||
| meson.build | ||
| nm-online.c | ||