diff options
| author | Thomas Haller <thaller@redhat.com> | 2018-10-29 12:47:27 +0100 |
|---|---|---|
| committer | Thomas Haller <thaller@redhat.com> | 2018-11-13 19:09:34 +0100 |
| commit | 5b9bc174d1f53c51a5afabd862fe859a4b4bbe62 (patch) | |
| tree | 8d338f5283a60be4601e54682b7c74cc3c9c8a35 /libnm-core | |
| parent | c3e7e6170dae14d553e650d9bd1d8b449e936f90 (diff) | |
dhcp: don't load IPv4 client-id from lease file
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?
Diffstat (limited to 'libnm-core')
| -rw-r--r-- | libnm-core/nm-setting-ip4-config.c | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/libnm-core/nm-setting-ip4-config.c b/libnm-core/nm-setting-ip4-config.c index 19f1cc8d4..686a50b04 100644 --- a/libnm-core/nm-setting-ip4-config.c +++ b/libnm-core/nm-setting-ip4-config.c @@ -724,8 +724,8 @@ nm_setting_ip4_config_class_init (NMSettingIP4ConfigClass *klass) * The special value "stable" is supported to generate a type 0 client identifier based * on the stable-id (see connection.stable-id) and a per-host key. * - * If unset, a globally configured default is used. If still unset, the - * client-id from the last lease is reused. + * If unset, a globally configured default is used. If still unset, the default + * depends on the DHCP plugin. **/ /* ---ifcfg-rh--- * property: dhcp-client-id |