If a primary group is set on the user, and a authorized_keys is provied in ssh_auth_file, the formula fails. This solves that by using the user_group set earlier in the formula
Unreasonable values for 'expire' (after 9999-12-31
on Linux, before 1975-01-01 on *BSD) get divided
by 86400 (number of seconds in a day) when too big
or multiplied by 86400 when too small.
Tested on CentOS 6 (Salt 2015.5.5) and FreeBSD 10.2
(Salt 2015.8.0) with following values:
- 24854 (2038-01-18 in days since epoch)
- 157766400 (1975-01-01 00:00:00 UTC in seconds since epoch)
- 3313526400 (2075-01-01 00:00:00 UTC in seconds since epoch)
- 16000 (2013-10-22 in days since epoch)
- 18000 (2019-04-14 in days since epoch)
(Sponsored by av.tu-berlin.de and fokus.fraunhofer.de)
This version complains that "argument port can not be used in
conjunction with argument hash_hostname", so add hash_hostname
to the fields we handle in the formula so we can override it
if needed.
This formula doesn't really require the sudo group (unless
there are actually users in that group). Moreover, on FreeBSD
the 'admin' group would be wheel and not sudo.
SSH key pairs deployed via the user's ssh_keys_pillar dict aren't
handled the same as the user's ssh_keys, e.g., file ownership and
permissions aren't specified, and the keying material gets copied
directly into the SLS file. This change rewrites the two templated
file.managed states to behave as follows:
- set the files' owner to be the user
- set the files' group to be the user's primary group
- for the public key, set the mode to 644 (u=rw,go=r)
- for the private key, set the mode to 600 (u=rw,g=)
- pull the files' contents directly from pillar
This will ensure that a given vimrc file in a users home dir is managed
Default it will search for a vimrc in salt://users/files/vimrc/{{ username
}}/vimrc
If this isn't found it will install salt://users/files/vimrc/vimrc
This will ensure a given bashrc file in a users home dir.
Default it will search for a bashrc in salt://users/files/bashrc/{{ username }}/bashrc
If no file is found it will install the default from
salt://users/files/bashrc/bashrc
https://github.com/saltstack/salt/issues/2142
This has been causing issues for many people, as the remove_groups options is undocumented. In the 2014.7 release this is changing, and remove_groups will default to false:
https://github.com/saltstack/salt/issues/13276
I'm going with false by default, as it's our use case and it will soon be the default. If people believe this module should default to true and remove groups not listed, I think that's open for discussion, but we should at least add the option.
This also made it necessary to introduce an additional entry 'shell' into the
users lookup table as the formula previously conflated the shell used for
running the visudo command and the default shell to be used for user accounts.
Fixes: #48
Since ebe5198f, if a user's pillar dict didn't contain sudo_rules, a broken
file.append state would be rendered (since some text is required). With
this patch, the file is still created/managed by the previous state, but
will be empty by default if created fresh. This seems a more sensible
default than assuming a default sudoer policy.
Further, since the first word on each rule line should be the user's
name, that is now assumed.
Changed Private keys to have content within pillar rather than the salt
file repository.
Changes sudoers entry to get values from pillar rather than assuming
all sudo users want root.
Ran into an error with Salt version 0.17.1:
Rendering SLS users failed, render error: Undefined jinja variable; line 32
After finding https://github.com/saltstack/salt/issues/8245, and working on
line 32, I surmised that line 28 might be the actual cause of the issue.
I just added a quick check to see if uid exists in user, just as the user uid
line does.
add support for sudouser being False.
change to adding sudoers config to /etc/sudoers.d/<user>
adding the removal of /etc/sudoers.d/<user> on user removal or switching to sudouser being removed or set to false
