2009-01-02 16:07:01 +00:00
|
|
|
{pkgs, config, ...}:
|
2007-06-08 15:41:12 +00:00
|
|
|
|
2009-09-02 17:35:24 +00:00
|
|
|
with pkgs.lib;
|
2009-01-02 16:07:01 +00:00
|
|
|
|
|
|
|
let
|
2009-09-02 17:35:24 +00:00
|
|
|
|
2009-05-29 14:25:56 +00:00
|
|
|
ids = config.ids;
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
cfg = config.users;
|
2007-06-08 15:41:12 +00:00
|
|
|
|
2014-02-05 14:07:20 +00:00
|
|
|
passwordDescription = ''
|
|
|
|
The options <literal>hashedPassword</literal>,
|
|
|
|
<literal>password</literal> and <literal>passwordFile</literal>
|
|
|
|
controls what password is set for the user.
|
|
|
|
<literal>hashedPassword</literal> overrides both
|
|
|
|
<literal>password</literal> and <literal>passwordFile</literal>.
|
|
|
|
<literal>password</literal> overrides <literal>passwordFile</literal>.
|
|
|
|
If none of these three options are set, no password is assigned to
|
|
|
|
the user, and the user will not be able to do password logins.
|
|
|
|
If the option <literal>users.mutableUsers</literal> is true, the
|
|
|
|
password defined in one of the three options will only be set when
|
|
|
|
the user is created for the first time. After that, you are free to
|
|
|
|
change the password with the ordinary user management commands. If
|
|
|
|
<literal>users.mutableUsers</literal> is false, you cannot change
|
|
|
|
user passwords, they will always be set according to the password
|
|
|
|
options.
|
|
|
|
'';
|
|
|
|
|
2012-04-20 12:55:09 +00:00
|
|
|
userOpts = { name, config, ... }: {
|
2012-10-23 11:35:06 +00:00
|
|
|
|
2011-11-29 06:08:55 +00:00
|
|
|
options = {
|
2012-10-23 11:35:06 +00:00
|
|
|
|
2011-11-29 06:08:55 +00:00
|
|
|
name = mkOption {
|
2013-10-30 10:02:04 +00:00
|
|
|
type = types.str;
|
2011-11-29 06:08:55 +00:00
|
|
|
description = "The name of the user account. If undefined, the name of the attribute set will be used.";
|
|
|
|
};
|
2012-10-23 11:35:06 +00:00
|
|
|
|
2011-11-29 06:08:55 +00:00
|
|
|
description = mkOption {
|
2013-10-30 10:02:04 +00:00
|
|
|
type = types.str;
|
2011-11-29 06:08:55 +00:00
|
|
|
default = "";
|
2013-10-31 07:41:51 +00:00
|
|
|
example = "Alice Q. User";
|
|
|
|
description = ''
|
|
|
|
A short description of the user account, typically the
|
|
|
|
user's full name. This is actually the “GECOS” or “comment”
|
|
|
|
field in <filename>/etc/passwd</filename>.
|
|
|
|
'';
|
2011-11-29 06:08:55 +00:00
|
|
|
};
|
2012-10-23 11:35:06 +00:00
|
|
|
|
2011-11-29 06:08:55 +00:00
|
|
|
uid = mkOption {
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
type = with types; uniq int;
|
|
|
|
description = "The account UID.";
|
2011-11-29 06:08:55 +00:00
|
|
|
};
|
2012-10-23 11:35:06 +00:00
|
|
|
|
2011-11-29 06:08:55 +00:00
|
|
|
group = mkOption {
|
2013-10-30 10:02:04 +00:00
|
|
|
type = types.str;
|
2011-11-29 06:08:55 +00:00
|
|
|
default = "nogroup";
|
|
|
|
description = "The user's primary group.";
|
|
|
|
};
|
2012-10-23 11:35:06 +00:00
|
|
|
|
2011-11-29 06:08:55 +00:00
|
|
|
extraGroups = mkOption {
|
2013-10-30 16:37:45 +00:00
|
|
|
type = types.listOf types.str;
|
2011-11-29 06:08:55 +00:00
|
|
|
default = [];
|
|
|
|
description = "The user's auxiliary groups.";
|
|
|
|
};
|
2012-10-23 11:35:06 +00:00
|
|
|
|
2011-11-29 06:08:55 +00:00
|
|
|
home = mkOption {
|
2013-10-30 10:02:04 +00:00
|
|
|
type = types.str;
|
2011-11-29 06:08:55 +00:00
|
|
|
default = "/var/empty";
|
|
|
|
description = "The user's home directory.";
|
|
|
|
};
|
2012-10-23 11:35:06 +00:00
|
|
|
|
2011-11-29 06:08:55 +00:00
|
|
|
shell = mkOption {
|
2013-10-30 10:02:04 +00:00
|
|
|
type = types.str;
|
2012-07-16 15:27:59 +00:00
|
|
|
default = "/run/current-system/sw/sbin/nologin";
|
2011-11-29 06:08:55 +00:00
|
|
|
description = "The path to the user's shell.";
|
|
|
|
};
|
2012-10-23 11:35:06 +00:00
|
|
|
|
2011-11-29 06:08:55 +00:00
|
|
|
createHome = mkOption {
|
|
|
|
type = types.bool;
|
|
|
|
default = false;
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
description = ''
|
|
|
|
If true, the home directory will be created automatically. If this
|
|
|
|
option is true and the home directory already exists but is not
|
|
|
|
owned by the user, directory owner and group will be changed to
|
|
|
|
match the user.
|
|
|
|
'';
|
2011-11-29 06:08:55 +00:00
|
|
|
};
|
2012-10-23 11:35:06 +00:00
|
|
|
|
2011-11-29 06:08:55 +00:00
|
|
|
useDefaultShell = mkOption {
|
|
|
|
type = types.bool;
|
|
|
|
default = false;
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
description = ''
|
|
|
|
If true, the user's shell will be set to
|
|
|
|
<literal>cfg.defaultUserShell</literal>.
|
|
|
|
'';
|
2011-11-29 06:08:55 +00:00
|
|
|
};
|
2012-10-23 11:35:06 +00:00
|
|
|
|
2014-02-05 14:07:20 +00:00
|
|
|
hashedPassword = mkOption {
|
|
|
|
type = with types; uniq (nullOr str);
|
|
|
|
default = null;
|
|
|
|
description = ''
|
|
|
|
Specifies the (hashed) password for the user.
|
|
|
|
${passwordDescription}
|
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
2011-11-29 06:08:55 +00:00
|
|
|
password = mkOption {
|
2013-10-30 16:37:45 +00:00
|
|
|
type = with types; uniq (nullOr str);
|
2011-11-29 06:08:55 +00:00
|
|
|
default = null;
|
2013-10-31 07:41:51 +00:00
|
|
|
description = ''
|
2014-02-05 14:07:20 +00:00
|
|
|
Specifies the (clear text) password for the user.
|
|
|
|
Warning: do not set confidential information here
|
|
|
|
because it is world-readable in the Nix store. This option
|
|
|
|
should only be used for public accounts.
|
|
|
|
${passwordDescription}
|
2013-10-31 07:41:51 +00:00
|
|
|
'';
|
2011-11-29 06:08:55 +00:00
|
|
|
};
|
2012-10-23 11:35:06 +00:00
|
|
|
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
passwordFile = mkOption {
|
|
|
|
type = with types; uniq (nullOr string);
|
|
|
|
default = null;
|
|
|
|
description = ''
|
|
|
|
The path to a file that contains the user's password. The password
|
|
|
|
file is read on each system activation. The file should contain
|
|
|
|
exactly one line, which should be the password in an encrypted form
|
|
|
|
that is suitable for the <literal>chpasswd -e</literal> command.
|
2014-02-05 14:07:20 +00:00
|
|
|
${passwordDescription}
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
'';
|
2011-11-29 06:08:55 +00:00
|
|
|
};
|
2012-10-23 11:35:06 +00:00
|
|
|
|
2011-11-29 06:08:55 +00:00
|
|
|
createUser = mkOption {
|
|
|
|
type = types.bool;
|
|
|
|
default = true;
|
2013-10-31 07:41:51 +00:00
|
|
|
description = ''
|
2011-11-29 06:08:55 +00:00
|
|
|
Indicates if the user should be created automatically as a local user.
|
|
|
|
Set this to false if the user for instance is an LDAP user. NixOS will
|
|
|
|
then not modify any of the basic properties for the user account.
|
2013-10-31 07:41:51 +00:00
|
|
|
'';
|
2011-11-29 06:08:55 +00:00
|
|
|
};
|
|
|
|
};
|
2007-06-08 15:41:12 +00:00
|
|
|
|
2011-11-29 06:08:55 +00:00
|
|
|
config = {
|
|
|
|
name = mkDefault name;
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
shell = mkIf config.useDefaultShell (mkDefault cfg.defaultUserShell);
|
2011-11-29 06:08:55 +00:00
|
|
|
};
|
2012-10-23 11:35:06 +00:00
|
|
|
|
2011-11-29 06:08:55 +00:00
|
|
|
};
|
2007-06-08 15:41:12 +00:00
|
|
|
|
2012-04-20 12:55:09 +00:00
|
|
|
groupOpts = { name, config, ... }: {
|
2012-10-23 11:35:06 +00:00
|
|
|
|
2012-04-20 12:55:09 +00:00
|
|
|
options = {
|
2012-10-23 11:35:06 +00:00
|
|
|
|
2012-04-20 12:55:09 +00:00
|
|
|
name = mkOption {
|
2013-10-30 10:02:04 +00:00
|
|
|
type = types.str;
|
2012-04-20 12:55:09 +00:00
|
|
|
description = "The name of the group. If undefined, the name of the attribute set will be used.";
|
|
|
|
};
|
2012-10-23 11:35:06 +00:00
|
|
|
|
2012-04-20 12:55:09 +00:00
|
|
|
gid = mkOption {
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
type = with types; uniq int;
|
|
|
|
description = "The GID of the group.";
|
|
|
|
};
|
|
|
|
|
|
|
|
members = mkOption {
|
|
|
|
type = with types; listOf string;
|
|
|
|
default = [];
|
|
|
|
description = ''
|
2014-02-05 14:24:05 +00:00
|
|
|
The user names of the group members, added to the
|
|
|
|
<literal>/etc/group</literal> file.
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
'';
|
2012-04-20 12:55:09 +00:00
|
|
|
};
|
2012-10-23 11:35:06 +00:00
|
|
|
|
2012-04-20 12:55:09 +00:00
|
|
|
};
|
2007-06-08 15:41:12 +00:00
|
|
|
|
2012-04-20 12:55:09 +00:00
|
|
|
config = {
|
|
|
|
name = mkDefault name;
|
|
|
|
};
|
2012-10-23 11:35:06 +00:00
|
|
|
|
2012-04-20 12:55:09 +00:00
|
|
|
};
|
2009-01-02 16:07:01 +00:00
|
|
|
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
getGroup = gname:
|
|
|
|
let
|
|
|
|
groups = mapAttrsToList (n: g: g) (
|
|
|
|
filterAttrs (n: g: g.name == gname) cfg.extraGroups
|
|
|
|
);
|
|
|
|
in
|
|
|
|
if length groups == 1 then head groups
|
|
|
|
else if groups == [] then throw "Group ${gname} not defined"
|
|
|
|
else throw "Group ${gname} has multiple definitions";
|
|
|
|
|
|
|
|
getUser = uname:
|
|
|
|
let
|
|
|
|
users = mapAttrsToList (n: u: u) (
|
|
|
|
filterAttrs (n: u: u.name == uname) cfg.extraUsers
|
|
|
|
);
|
|
|
|
in
|
|
|
|
if length users == 1 then head users
|
|
|
|
else if users == [] then throw "User ${uname} not defined"
|
|
|
|
else throw "User ${uname} has multiple definitions";
|
|
|
|
|
|
|
|
mkGroupEntry = gname:
|
2012-10-23 11:35:06 +00:00
|
|
|
let
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
g = getGroup gname;
|
|
|
|
users = mapAttrsToList (n: u: u.name) (
|
|
|
|
filterAttrs (n: u: elem g.name u.extraGroups) cfg.extraUsers
|
|
|
|
);
|
|
|
|
in concatStringsSep ":" [
|
|
|
|
g.name "x" (toString g.gid)
|
|
|
|
(concatStringsSep "," (users ++ (filter (u: !(elem u users)) g.members)))
|
|
|
|
];
|
|
|
|
|
|
|
|
mkPasswdEntry = uname: let u = getUser uname; in
|
|
|
|
concatStringsSep ":" [
|
|
|
|
u.name "x" (toString u.uid)
|
|
|
|
(toString (getGroup u.group).gid)
|
|
|
|
u.description u.home u.shell
|
|
|
|
];
|
|
|
|
|
|
|
|
sortOn = a: sort (as1: as2: lessThan (getAttr a as1) (getAttr a as2));
|
|
|
|
|
|
|
|
groupFile = pkgs.writeText "group" (
|
|
|
|
concatStringsSep "\n" (map (g: mkGroupEntry g.name) (
|
|
|
|
sortOn "gid" (attrValues cfg.extraGroups)
|
|
|
|
))
|
|
|
|
);
|
|
|
|
|
|
|
|
passwdFile = pkgs.writeText "passwd" (
|
|
|
|
concatStringsSep "\n" (map (u: mkPasswdEntry u.name) (
|
|
|
|
sortOn "uid" (filter (u: u.createUser) (attrValues cfg.extraUsers))
|
|
|
|
))
|
|
|
|
);
|
|
|
|
|
|
|
|
# If mutableUsers is true, this script adds all users/groups defined in
|
|
|
|
# users.extra{Users,Groups} to /etc/{passwd,group} iff there isn't any
|
|
|
|
# existing user/group with the same name in those files.
|
|
|
|
# If mutableUsers is false, the /etc/{passwd,group} files will simply be
|
|
|
|
# replaced with the users/groups defined in the NixOS configuration.
|
|
|
|
# The merging procedure could certainly be improved, and instead of just
|
|
|
|
# keeping the lines as-is from /etc/{passwd,group} they could be combined
|
|
|
|
# in some way with the generated content from the NixOS configuration.
|
|
|
|
merger = src: pkgs.writeScript "merger" ''
|
|
|
|
#!${pkgs.bash}/bin/bash
|
|
|
|
|
|
|
|
PATH=${pkgs.gawk}/bin:${pkgs.gnugrep}/bin:$PATH
|
|
|
|
|
|
|
|
${if !cfg.mutableUsers
|
|
|
|
then ''cp ${src} $1.tmp''
|
|
|
|
else ''awk -F: '{ print "^"$1":.*" }' $1 | egrep -vf - ${src} | cat $1 - > $1.tmp''
|
|
|
|
}
|
|
|
|
|
|
|
|
# set mtime to +1, otherwise change might go unnoticed (vipw/vigr only looks at mtime)
|
|
|
|
touch -m -t $(date -d @$(($(stat -c %Y $1)+1)) +%Y%m%d%H%M.%S) $1.tmp
|
|
|
|
|
|
|
|
mv -f $1.tmp $1
|
|
|
|
'';
|
2011-09-14 18:20:50 +00:00
|
|
|
|
2009-01-02 16:07:01 +00:00
|
|
|
in
|
|
|
|
|
|
|
|
{
|
|
|
|
|
2009-09-02 17:35:24 +00:00
|
|
|
###### interface
|
2009-01-02 16:07:01 +00:00
|
|
|
|
2009-09-02 17:35:24 +00:00
|
|
|
options = {
|
2011-09-14 18:20:50 +00:00
|
|
|
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
users.mutableUsers = mkOption {
|
|
|
|
type = types.bool;
|
|
|
|
default = true;
|
|
|
|
description = ''
|
|
|
|
If true, you are free to add new users and groups to the system
|
|
|
|
with the ordinary <literal>useradd</literal> and
|
|
|
|
<literal>groupadd</literal> commands. On system activation, the
|
|
|
|
existing contents of the <literal>/etc/passwd</literal> and
|
|
|
|
<literal>/etc/group</literal> files will be merged with the
|
|
|
|
contents generated from the <literal>users.extraUsers</literal> and
|
|
|
|
<literal>users.extraGroups</literal> options. If
|
|
|
|
<literal>mutableUsers</literal> is false, the contents of the user and
|
|
|
|
group files will simply be replaced on system activation. This also
|
|
|
|
holds for the user passwords; if this option is false, all changed
|
|
|
|
passwords will be reset according to the
|
|
|
|
<literal>users.extraUsers</literal> configuration on activation. If
|
|
|
|
this option is true, the initial password for a user will be set
|
|
|
|
according to <literal>users.extraUsers</literal>, but existing passwords
|
|
|
|
will not be changed.
|
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
2009-09-02 17:35:24 +00:00
|
|
|
users.extraUsers = mkOption {
|
2011-11-29 06:08:55 +00:00
|
|
|
default = {};
|
|
|
|
type = types.loaOf types.optionSet;
|
|
|
|
example = {
|
|
|
|
alice = {
|
|
|
|
uid = 1234;
|
2013-10-31 07:41:51 +00:00
|
|
|
description = "Alice Q. User";
|
2011-11-29 06:08:55 +00:00
|
|
|
home = "/home/alice";
|
|
|
|
createHome = true;
|
|
|
|
group = "users";
|
|
|
|
extraGroups = ["wheel"];
|
|
|
|
shell = "/bin/sh";
|
|
|
|
};
|
|
|
|
};
|
2009-09-02 17:35:24 +00:00
|
|
|
description = ''
|
|
|
|
Additional user accounts to be created automatically by the system.
|
2013-08-09 01:23:22 +00:00
|
|
|
This can also be used to set options for root.
|
2009-09-02 17:35:24 +00:00
|
|
|
'';
|
2011-11-29 06:08:55 +00:00
|
|
|
options = [ userOpts ];
|
2009-09-02 17:35:24 +00:00
|
|
|
};
|
2009-01-02 16:07:01 +00:00
|
|
|
|
2009-09-02 17:35:24 +00:00
|
|
|
users.extraGroups = mkOption {
|
2012-04-20 12:55:09 +00:00
|
|
|
default = {};
|
2009-09-02 17:35:24 +00:00
|
|
|
example =
|
2012-04-20 12:55:09 +00:00
|
|
|
{ students.gid = 1001;
|
|
|
|
hackers = { };
|
|
|
|
};
|
|
|
|
type = types.loaOf types.optionSet;
|
2009-09-02 17:35:24 +00:00
|
|
|
description = ''
|
|
|
|
Additional groups to be created automatically by the system.
|
|
|
|
'';
|
2012-04-20 12:55:09 +00:00
|
|
|
options = [ groupOpts ];
|
2009-09-02 17:35:24 +00:00
|
|
|
};
|
|
|
|
|
2014-02-05 14:07:20 +00:00
|
|
|
security.initialRootPassword = mkOption {
|
|
|
|
type = types.str;
|
|
|
|
default = "";
|
|
|
|
example = "!";
|
|
|
|
description = ''
|
|
|
|
The (hashed) password for the root account set on initial
|
|
|
|
installation. The empty string denotes that root can login
|
|
|
|
locally without a password (but not via remote services such
|
|
|
|
as SSH, or indirectly via <command>su</command> or
|
|
|
|
<command>sudo</command>). The string <literal>!</literal>
|
|
|
|
prevents root from logging in using a password.
|
|
|
|
Note, setting this option sets
|
|
|
|
<literal>users.extraUsers.root.hashedPassword</literal>.
|
|
|
|
Note, if <literal>users.mutableUsers</literal> is false
|
|
|
|
you cannot change the root password manually, so in that case
|
|
|
|
the name of this option is a bit misleading, since it will define
|
|
|
|
the root password beyond the user initialisation phase.
|
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
2009-09-02 17:35:24 +00:00
|
|
|
};
|
2011-09-14 18:20:50 +00:00
|
|
|
|
2009-09-02 17:35:24 +00:00
|
|
|
|
|
|
|
###### implementation
|
|
|
|
|
|
|
|
config = {
|
|
|
|
|
2011-11-29 06:08:55 +00:00
|
|
|
users.extraUsers = {
|
|
|
|
root = {
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
uid = ids.uids.root;
|
2011-11-29 06:08:55 +00:00
|
|
|
description = "System administrator";
|
|
|
|
home = "/root";
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
shell = cfg.defaultUserShell;
|
2011-11-29 06:08:55 +00:00
|
|
|
group = "root";
|
2014-02-05 14:07:20 +00:00
|
|
|
hashedPassword = config.security.initialRootPassword;
|
2011-11-29 06:08:55 +00:00
|
|
|
};
|
|
|
|
nobody = {
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
uid = ids.uids.nobody;
|
2011-11-29 06:08:55 +00:00
|
|
|
description = "Unprivileged account (don't use!)";
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
group = "nogroup";
|
2011-11-29 06:08:55 +00:00
|
|
|
};
|
|
|
|
};
|
|
|
|
|
2012-04-20 12:55:09 +00:00
|
|
|
users.extraGroups = {
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
root.gid = ids.gids.root;
|
|
|
|
wheel.gid = ids.gids.wheel;
|
|
|
|
disk.gid = ids.gids.disk;
|
|
|
|
kmem.gid = ids.gids.kmem;
|
|
|
|
tty.gid = ids.gids.tty;
|
|
|
|
floppy.gid = ids.gids.floppy;
|
|
|
|
uucp.gid = ids.gids.uucp;
|
|
|
|
lp.gid = ids.gids.lp;
|
|
|
|
cdrom.gid = ids.gids.cdrom;
|
|
|
|
tape.gid = ids.gids.tape;
|
|
|
|
audio.gid = ids.gids.audio;
|
|
|
|
video.gid = ids.gids.video;
|
|
|
|
dialout.gid = ids.gids.dialout;
|
|
|
|
nogroup.gid = ids.gids.nogroup;
|
|
|
|
users.gid = ids.gids.users;
|
|
|
|
nixbld.gid = ids.gids.nixbld;
|
|
|
|
utmp.gid = ids.gids.utmp;
|
|
|
|
adm.gid = ids.gids.adm;
|
2012-04-20 12:55:09 +00:00
|
|
|
};
|
|
|
|
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
system.activationScripts.users =
|
|
|
|
let
|
|
|
|
mkhomeUsers = filterAttrs (n: u: u.createHome) cfg.extraUsers;
|
|
|
|
setpwUsers = filterAttrs (n: u: u.createUser) cfg.extraUsers;
|
|
|
|
setpw = n: u: ''
|
|
|
|
setpw=yes
|
|
|
|
${optionalString cfg.mutableUsers ''
|
|
|
|
test "$(getent shadow '${u.name}' | cut -d: -f2)" != "x" && setpw=no
|
|
|
|
''}
|
|
|
|
if [ "$setpw" == "yes" ]; then
|
2014-02-05 14:07:20 +00:00
|
|
|
${if !(isNull u.hashedPassword)
|
|
|
|
then ''
|
|
|
|
echo "${u.name}:${u.hashedPassword}" | \
|
|
|
|
${pkgs.shadow}/sbin/chpasswd -e''
|
|
|
|
else if u.password == ""
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
then "passwd -d '${u.name}' &>/dev/null"
|
|
|
|
else if !(isNull u.password)
|
|
|
|
then ''
|
|
|
|
echo "${u.name}:${u.password}" | ${pkgs.shadow}/sbin/chpasswd''
|
2014-02-05 14:07:20 +00:00
|
|
|
else if !(isNull u.passwordFile)
|
|
|
|
then ''
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
echo -n "${u.name}:" | cat - "${u.passwordFile}" | \
|
|
|
|
${pkgs.shadow}/sbin/chpasswd -e
|
|
|
|
''
|
2014-02-05 14:07:20 +00:00
|
|
|
else "passwd -l '${u.name}' &>/dev/null"
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
}
|
|
|
|
fi
|
|
|
|
'';
|
|
|
|
mkhome = n: u:
|
|
|
|
let
|
|
|
|
uid = toString u.uid;
|
|
|
|
gid = toString ((getGroup u.group).gid);
|
|
|
|
h = u.home;
|
|
|
|
in ''
|
|
|
|
test -a "${h}" || mkdir -p "${h}" || true
|
|
|
|
test "$(stat -c %u "${h}")" = ${uid} || chown ${uid} "${h}" || true
|
|
|
|
test "$(stat -c %g "${h}")" = ${gid} || chgrp ${gid} "${h}" || true
|
|
|
|
'';
|
|
|
|
in stringAfter [ "etc" ] ''
|
|
|
|
touch /etc/group
|
|
|
|
touch /etc/passwd
|
|
|
|
VISUAL=${merger groupFile} ${pkgs.shadow}/sbin/vigr &>/dev/null
|
|
|
|
VISUAL=${merger passwdFile} ${pkgs.shadow}/sbin/vipw &>/dev/null
|
|
|
|
${pkgs.shadow}/sbin/grpconv
|
|
|
|
${pkgs.shadow}/sbin/pwconv
|
|
|
|
${concatStrings (mapAttrsToList mkhome mkhomeUsers)}
|
|
|
|
${concatStrings (mapAttrsToList setpw setpwUsers)}
|
2010-09-13 15:41:38 +00:00
|
|
|
'';
|
2009-01-02 16:07:01 +00:00
|
|
|
|
Generate /etc/passwd and /etc/group at build time
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
2013-05-17 15:08:32 +00:00
|
|
|
# for backwards compatibility
|
|
|
|
system.activationScripts.groups = stringAfter [ "users" ] "";
|
2007-06-08 15:41:12 +00:00
|
|
|
|
2009-01-02 16:07:01 +00:00
|
|
|
};
|
2009-09-02 17:35:24 +00:00
|
|
|
|
2007-11-09 18:49:45 +00:00
|
|
|
}
|