Change:
index 21f6471495..8c5af7619f 100644 --- a/src/hostname/hostnamed.c +++ b/src/hostname/hostnamed.c <del> @@ -422,6 +422,9 @@ static int method_set_hostname(sd_bus_message *m, void *userdata, sd_bus_error * if (r < 0) return r; +        return sd_bus_error_setf(error, SD_BUS_ERROR_NOT_SUPPORTED, +            "Changing system settings via systemd is not supported on NixOS."); + if (isempty(name)) name = c->data[PROP_STATIC_HOSTNAME]; </del> @@ -478,6 +481,9 @@ static int method_set_static_hostname(sd_bus_message *m, void *userdata, sd_bus_ if (r < 0) return r;

Discussion:
Describe the bug From : So having empty hostname is supposed to work. However, this happens when setting and booting on a network where the DHCP server passes the hostname "clientA" to the NixOS machine: To Reproduce Steps to reproduce the behavior: network with DHCP server that gives hostname to client. NixOS client machine with the client. that client hostname is not what the DHCP server asked and the system journal includes warning that the hostname could not be set. Expected behavior I expect the hostname given by the DHCP server to be set as a "transient hostname". Additional context I'm runnign GNOME3 with NetworkManager. Perhaps non-NetworkManager setups work? Metadata NixOS 19.09.
This is because of , networkmanager probably uses systemd for this and it's patched out in our fork.
Perhaps we can update that patch to allow setting the transient hostname only? Simpler reproduce steps:
That sounds like it should be at least allowed. We should move this issue to the systemd nixos repo. (or at least open an issue there).
I cannot create issue in Either issues are disabled or I don't have rights. (It seems I can create a pull though.)
^
I don't have the power to enable issues up there, but I also don't, we really need a second issue tracker. It might just create confusion, where to open issues and people have to look in two places.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
cc
No need to create issues over there, uses vanilla systemd by now, and that behaviour is part of a downstream patch.
To add some additional information: This is broken due to one of our downstream systemd patches () that forbids setting the hostname via D-Bus (sd-bus).

I see the following possible fixes (though there might be better ways): Allow changing the hostname via systemd if is empty (but this might be a bit difficult to implement and maintain, depending on how we implement it) Always allow changing the hostname via systemd (easy to implement, but might not be desirable, especially with tools like NetworkManager) Patch NetworkManager (and other tools) to use a different mechanism to set the hostname (but this is probably a bad idea as that requires elevated privileges).
Update after having a quick look at (systemd): It would probably be best to allow and only deny . This would allow NetworkManager and other tools to change the transient hostname but the kernel hostname would only be updated if isn't empty (i.e. should work as expected). Additionally it might be nice if we could drop entirely and replace it with custom Polkit rules (I think that should be possible, but I know very little about Polkit). If that works we could also change the rules dynamically based on and without having to recompile systemd (or anything else). Update: Denying via Polkit should work as expected: (contains an example for ) (interface description) -I think using Polkit instead of the patch is the way to go
Being able to drop more of our patches sounds good, but can polkit be used to even disallow root to do these actions? What happens on systems with polkit disabled?
Idk, but probably not. I guess it's only intended to grant additional privileges (but it could be possible). But ideally no services should be running as root. This obviously has to be checked properly, but as long as it's implemented sane (I'd consider everything else as a critical security bug) it should obviously reject everything (of course limited to the Polkit authorization, not other mechanisms). seems to confirm this, but I wouldn't take it as proof as there are additional control-flow paths and I didn't check the whole function:
Hmm, I think remove a similar restriction in our downstream patch, by just not creating that file via NixOS. Looping in
that also seems like a nice and easy fix. The implementation is . This would be a viable alternative to using Polkit (though it might require a reboot after changing but I guess that wouldn't be a big problem).
cross-referencing for context:
do you want to give this a try?

You should be able to test this without rebuilding the world, by just passing that other systemd via .
I thought about it, but unfortunately I cannot easily test this currently due to some ongoing setup changes. Would be best if someone who uses NetworkManager could give it a shot (is anyone in this thread interested and has time?). If it would help I could create a PR, but testing is the actual work. As for the implementation: I think it would be best to drop entirely. I.e. always allow (unconditionally) and only deny . Then depending on if is empty or not it should only allow to set the transient hostname (vs. additionally the static hostname). From :
Happy to give this a spin, once there's a PR open :+1:
ok, I've opened ;) I've also had time to quickly test this manually, but not with NetworkManager.
Thanks for fixing this!