-
-
Notifications
You must be signed in to change notification settings - Fork 15.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Partial revert of #76542's strict hostname checks #94022
Conversation
Some networks depend on the hostname being a FQDN, and migrating is not a trivial task. See the tracking issue in NixOS#94011, and the PR containing the reverted commit: NixOS#76542 This reverts commit 993baa5.
@@ -216,7 +216,7 @@ def __init__(self, args: Dict[str, Any]) -> None: | |||
if cmd: | |||
match = re.search("run-(.+)-vm$", cmd) | |||
if match: | |||
self.name = match.group(1) | |||
self.name = match.group(1).replace(".", "_") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is named after the hostname, but later on this Python code uses the machine.name
value as a Python variable name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the problem doesn't just apply to .
's but all kinds of allowed characters? e.g. -
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, though I wasn't sure just how far I should go. I could add -
too. Should I do more?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO this looks fine. I'd like to hear from @zimbatm (and other involved) parties what their thought on this is. As I outlined in the related issue I kinda gave up on the split of what a hostname is long ago for various reasons.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before we merge this we also need to update the release notes in nixos/doc/manual/release-notes/rl-2009.xml
.
Other than that I'm fine if we don't enforce the recommendations / best practices anymore (enforcing a recommended syntax was always critical and for that reason I guess I'd actually even prefer only documenting the recommendation in the option instead of enforcing it - but personally I'm fine with it either way and I'd prefer the current implementation if it where only enforced by Linux/systemd).
# reasons (as undocumented feature): | ||
type = types.strMatching | ||
"^$|^[[:alpha:]]([[:alnum:]_-]{0,61}[[:alnum:]])?$"; | ||
type = types.str; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be best if we'd still limit the maximum length to 63 characters as that is actually a strict limit.
contain the domain part. This means that the hostname must start with a | ||
letter, end with a letter or digit, and have as interior characters only | ||
letters, digits, and hyphen. The maximum length is 63 characters. | ||
Additionally it is recommended to only use lower-case characters. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would still keep that part or a similar version as a recommendation (or at least refer to hostname(5)
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really have an opinion on this. If it's not rare to break the previous strict check in practice, this PR's approach sounds right.
Docs in Linux and POSIX don't seem clear, with man hostname.5
just "recommending" it to be a single label. I agree with this PR still "enforcing" that
fqdn = hostName + (optionalString (domain != null) ".${domain}");
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still think most of the logic on why simply using the FQDN as hostname from systemd/systemd#15894 (comment) applies to us as well. Doing this is a bad idea, and works in some usecases "mostly by accident".
IMHO we should follow that logic, and keep the NixOS module code simple. Previously, we had some error-prone "if hostname is a fqdn, do this, else do that" logic in multiple places (and hadn't it in some others).
I was also guilty of using the FQDN as hostname, and it broke in other places (and required quirky workarounds).
Generally, I think people who still need to stick with the old behaviour, and can't switch, can maintain a revert of that functionality in a fork, as suggested by @primeos in #94011.
If that really is not an option, and for some reasons these "large corporate users" need some time to switch, I wouldn't object too much about adding a "footgun" with a heavy warning sign for one release to opt-out from the assertion failure (and without any additional logic inside the rest of the module system).
People should really fix their broken setups, instead of nixpkgs carrying workarounds.
I agree with @flokli. Having a warning for an extended period seems like a good middle ground between breaking users and having subtly b0rken setups. |
On Tue, Jul 28, 2020, 19:16 Florian Klink ***@***.***> wrote:
IMHO we should follow that logic, and keep the NixOS module code simple.
Previously, we had some error-prone "if hostname is a fqdn, do this, else
do that" logic in multiple places (and hadn't it in some others).
I was also using the FQDN as hostname, and it broke in other places (and
required quirky workarounds).
What did break and what were those workarounds? Having read the linked
systemd issue I am still not convinced of what you are arguing for.
… |
Avahi for example fails to run with an error message if In general, supporting both things increases complexity, having the FQDN is discouraged, and I don't see much reason to just revert this. |
Another place where this might be a problem is in
However since recently |
Depending on the outcome of this conversation
This default value should be updated to include the domain now as well. |
This breaks at least digitalocean and Packet.net too by the way; which include |
@arianvp can you elaborate how this breaks these machines? If we're just talking about hostnames being sent over DHCP, that should still work ( |
Also note the packet hostnames are only suggested, and probably are not intended to be used as FQDNs anyways: |
I'll go ahead and close this as we also have #94011 which seems more appropriate for the current discussion. We can of course re-open this PR if necessary. |
Since NixOS#76542 this workaround is required to use a FQDN as hostname. See NixOS#94011 and NixOS#94022 for the related discussion. Due to some potential/unresolved issues (legacy software, backward compatibility, etc.) we're documenting this workaround [0]. [0]: NixOS#94011 (comment)
Since #76542 this workaround is required to use a FQDN as hostname. See #94011 and #94022 for the related discussion. Due to some potential/unresolved issues (legacy software, backward compatibility, etc.) we're documenting this workaround [0]. [0]: #94011 (comment)
Since NixOS#76542 this workaround is required to use a FQDN as hostname. See NixOS#94011 and NixOS#94022 for the related discussion. Due to some potential/unresolved issues (legacy software, backward compatibility, etc.) we're documenting this workaround [0]. [0]: NixOS#94011 (comment) (cherry picked from commit 4a600af)
Motivation for this change
See #94011 for context, but in general this check is a bit too strict.
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)