The GECOS fields we set as the default for `nobody` and `root` are quite arbitrary, and it stands to reason that users may wish to alter them without resorting to `mkForce`.
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
The linger-users systemd unit runs a Bash script. To allow this to be
avoided for the bashless profile, provide an option to have NixOS not
manage lingering for any users.
To make this feasible, add the possibility for each individual user
account to not have its lingering configuration managed by NixOS at all,
and make this the default from 26.05. In practice, this won't result in
a change of behaviour except for people who manually use `loginctl
enable-linger` commands to add lingering for some user accounts, then
rely on NixOS to disable lingering the next time the systemd units are
restarted.
If systemd has recorded that a user should be lingering despite them not
having an account on the system, that record is removed. When that
happens, log for the sake of future debugging and investigations.
Suggested-By: Grimmauld <grimmauld@grimmauld.de>
Using systemd properties avoids the need for manually running mkdir and
cd commands, and helps systemd clean up properly when appropriate.
Suggested-By: Grimmauld <grimmauld@grimmauld.de>
If a user has configured a different systemd package,
linger-users.service should respect that and use the provided loginctl
executable rather than the one from the default nixpkgs package.
Running with systemd.enableStrictShellChecks with lingering users causes
failures due to parsing the output from `ls`. Rewrite the script to
avoid parsing ls, and instead rely on loginctl enable-linger and
disable-linger commands being idempotent and run them unconditionally.
This also fixes a bug where the systemd unit for adding and removing
lingering user configuration is only enabled if there are users
configured with lingering in the NixOS configuration. This means that
if a NixOS system is built with some lingering users, then the linger
configuration is removed from all those users, the script to disable
lingering won't be run, and those users will incorrectly continue to
have lingering enabled.
Fixes#418101.
`chpasswd -e` accepts entries in the form of:
<user>:<hashed-password-etc>
However, using a value in the above format fails to set the password
hash. Using ONLY the <hashed-password> generated by `mkpasswd` works as
expected.
Format all Nix files using the officially approved formatter,
making the CI check introduced in the previous commit succeed:
nix-build ci -A fmt.check
This is the next step of the of the [implementation](https://github.com/NixOS/nixfmt/issues/153)
of the accepted [RFC 166](https://github.com/NixOS/rfcs/pull/166).
This commit will lead to merge conflicts for a number of PRs,
up to an estimated ~1100 (~33%) among the PRs with activity in the past 2
months, but that should be lower than what it would be without the previous
[partial treewide format](https://github.com/NixOS/nixpkgs/pull/322537).
Merge conflicts caused by this commit can now automatically be resolved while rebasing using the
[auto-rebase script](8616af08d9/maintainers/scripts/auto-rebase).
If you run into any problems regarding any of this, please reach out to the
[formatting team](https://nixos.org/community/teams/formatting/) by
pinging @NixOS/nix-formatting.
Testing showed that the existing documentation regarding password override
ordering was incorrect. This commit corrects the errors and refactors
the way the text is constructed to make updating future ordering
changes significantly easier.
Before the error message only mentioned isSystemUser/isNormalUser which
lead to a confusing situation when setting isNormalUser and an uid like
500 which would generate an error like:
error:
Failed assertions:
- Exactly one of users.users.other.isSystemUser and users.users.other.isNormalUser must be set.
from which you cannot know that setting the uid to 500 *and* setting
isNormalUser is the actual problem.
With this patch the error looks like:
error:
Failed assertions:
- A user cannot have a users.users.fixme.uid set below 1000 and set users.users.fixme.isNormalUser.
Either users.users.fixme.isSystemUser must be set to true instead of users.users.fixme.isNormalUser
or users.users.fixme.uid must be changed to 1000 or above.
This was suggested since it might make it a little easier to identify
the places where the definitions come from.
Retrieving the effective definitions from the module-system seems
non-trivial, especially for submodules though, hence only the values are
shown for now.
I'd argue that especially the `password` option are mostly a convenience
thing for test setups. If the password is an actual secret, it should be
treated as such, i.e. `hashedPasswordFile` should be used.
For the `shadow` VM test, the new section of the warning looks like
this:
The values of these options are:
* users.users."leo".hashedPassword: "$6$ymzs8WINZ5wGwQcV$VC2S0cQiX8NVukOLymysTPn4v1zJoJp3NGyhnqyv/dAf4NWZsBWYveQcj6gEJr4ZUjRBRjM0Pj1L8TCQ8hUUp0"
* users.users."leo".hashedPasswordFile: null
* users.users."leo".password: null
* users.users."leo".initialHashedPassword: "!"
* users.users."leo".initialPassword: null
these changes were generated with nixq 0.0.2, by running
nixq ">> lib.mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> mdDoc[remove] Argument[keep]" --batchmode nixos/**.nix
nixq ">> Inherit >> mdDoc[remove]" --batchmode nixos/**.nix
two mentions of the mdDoc function remain in nixos/, both of which
are inside of comments.
Since lib.mdDoc is already defined as just id, this commit is a no-op as
far as Nix (and the built manual) is concerned.
The update-lingering activation script currently fails during rebuilds.
This happens when removing a user with linger enabled.
The call to loginctl disable-linger runs for the non-existent user.
This returns an error code which causes the failure.
To mitigate this, this PR removes any residual linger files.
These are files named for the user in /var/lib/systemd/linger.
A simple check for user existence determines whether to delete the file.
This happens before the call to disable-linger to avoid any errors.
Fixes#283769.
After 4b128008c5 it took me a while in a
test setup to find out why `root` didn't have the password anymore I
declared in my config.
Because of that I got reminded how the order of preference works for the
password options:
hashedPassword > password > hashedPasswordFile
If the user is new, initialPassword & initialHashedPassword are also
relevant. Also, the override is silent in contrast to any other
conflicting definition in NixOS.
To make this less surprising I decided to warn in such a case -
assertions would probably break too much that technically works as
intended.
Also removed the `initialHashedPassword` for `root`. This would cause a
warning whenever you set something in your own config and a `!` is added
automatically by `users-groups.pl`.
`systemd-sysusers` also seems to implement these precedence rules, so
having the warning for that case also seems useful.
I recently set up a new machine with tmpfs-on-root
and switched to mutableUsers = false as part of that.
I missed that an existing user with `shell = null`
was no longer valid as part of this change.
(`shell = null` is still useful for `mutableUsers = true`.)
Add an assertion to prevent future issues.
Also fix a typo in an option name in a comment,
this confused me slightly
(I originally planned to extend that existing assertion.)
If we include users with unset groups, we get this very confusing
message, with invalid Nix code:
- The following users have a primary group that is undefined: qyliss
Hint: Add this to your NixOS configuration:
users.groups. = {};
We don't need to include such users in this check, since they'll be
caught anyway by this one:
- users.users.qyliss.group is unset. This used to default to
nogroup, but this is unsafe. For example you can create a group
for this user with:
users.users.qyliss.group = "qyliss";
users.groups.qyliss = {};
