No way to set dhcp-send-hostname globally
I'm re-opening an issue from the old bugzilla, which is still present in NM.
Here's a relevant reply from @thaller:
The only problem is that "ipv4.dhcp-send-hostname" cannot be set by default. And the reason that is hard to extend is because the property is a boolean value.
Properties that allow for their default value to be overwritten all require that they have a special value which allows for the fallback to the default value. The boolean property ipv4.dhcp-send-hostname doesn't have a value to allow for such a default value. The goal of this rule is that the per-profile value always takes precedence.
there are some solutions, all ugly:
a) make an exception for ipv4.dhcp-send-hostname. The per-profile value YES would mean: "lookup globally configured value, and if unspecified, use YES". That is ugly, because now the global default takes precedence.
b) deprecate ipv4.dhcp-send-hostname and add a new property that can encode 3 values. I think this is the way to go.
I think, ipv4.dhcp-send-hostname should be deprecated and replaced by new NM_DHCP_HOSTNAME_FLAG_*. Patch welcome :)
It was discussed here: !198 (comment 328579) but not done (yet).
For example, there could be two new flags:
- NM_DHCP_HOSTNAME_FLAG_SEND_HOSTNAME
- NM_DHCP_HOSTNAME_FLAG_NO_SEND_HOSTNAME
if any of these two flags is set, then ipv4.dhcp-send-hostname gets ignored. Also,
nm_connection_normalize()should be extended to enforce that conflicting flags agree.
I don't have a good understanding of the code, so I probably have some misconceptions. Looking at the documentation for connection properties, I get the impression that the default value for a property is always static. However, I don't see why we couldn't have the default value for the ipv4.dhcp-send-hostname connection property be dependent on the value of a global ipv4.dhcp-send-hostname. In a connection profile setting ipv4.dhcp-send-hostname= or having no ipv4.dhcp-send-hostname should mean to use the default value.