networking: Update fqdnOrHostName logic to handle empty hostName

[oneingan]

Motivation for this change

The current logic for networking.fqdnOrHostName does not account for cases where hostName is an empty string. This can lead to unexpected behavior in configurations where hostName is not set. This change updates the logic to handle empty hostName values appropriately.

Things done

• Updated the logic in networking.fqdnOrHostName to check if hostName is an empty string.
• Adjusted the defaultText to reflect the new logic.
• Tested the changes to ensure correct behavior when hostName is empty or domain is unset.

Testing

• Built on platform(s):
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested compilation of all packages that depend on this change.
• Tested execution of all binary files (usually in ./result/bin/).
• Determined the impact on package closure size (by running nix path-info -S before and after).
• Ensured that relevant documentation is up to date.
• Fits CONTRIBUTING.md.

[roberth]

What is the expected use or scenario for an empty string hostname?
The default hostname is "nixos", not "", so that leaves me wondering.

[oneingan]

Delegate the hostname into cloud-init or dhcp. Default behavior in srvos server profile:

https://github.com/nix-community/srvos/blob/be4533b50ac69cd871ab73d4101c47b397b8c143/nixos/server/default.nix#L57

[oneingan]

What do you think @roberth ? maybe its prefered simply remove this line from os-release: https://github.com/jopejoe1/nixpkgs/blob/3dec4d4a9e42564a2f952c2899a1a81249587f6a/nixos/modules/misc/version.nix#L44

[SuperSandro2000]

Suggested change

	default = if (cfg.hostName == "" || cfg.domain == null)
	default = if (cfg.hostName != "" && cfg.domain == null)

shouldn't this be like this? otherwise we take an empty hostname as before.

[oneingan]

Not exactly, the regression occurs when hostName is empty and domain is defined. In that case, I want fqdnOrHostname to return "", not an error (as networking.fqdn does).

[SuperSandro2000]

I find the condition a bit hard to understand when we re-use the empty string hostname in that case.

Also I think this not really covers the original usecase anymore. Before you would always get either a hostname or a fqdn where as empty string probably breaks most usages of it.

[oneingan]

I understand your point, so the regression comes from os-release changes i pointed above, leveraging this function, as os-release MUST not depend on whether hostName is defined or not

[oneingan]

@SuperSandro2000 Can I help with this? I have a fleet of servers blocked for 24.11 update.

[oneingan]

A different path to solve this:

#359571

[oneingan]

Regardless of solving my issue with this PR #359571, it is inconsistent that the fqdnOrHostName function returns well the empty hostName when the domain is null, yet fails when the domain is defined.

It should either:

• If the hostName is empty, return an empty hostName regardless of the domain.

or

• If the hostName is empty, always fail with an error, regardless of the domain, since it cannot compose a valid FQDN or a valid hostname.