gid_from_name fails to create and set group on SUSE Linux. #45345
Comments
|
ping @saltstack/team-suse any ideas here? |
Ch3LL
added
the
Pending-Discussion
|
Well, I've fixed this to prevent that error if an empty string is used as a group name, but the problem here is different. As I understand this, a new group shouldn't be created during the In your particular case, if there is no group with that name FMPOV a correct approach for the SLS would be: test_group:
group.present:
- name: test
test_user:
user.present:
- name: test
- gid_from_name: True
- require:
- group: test_group@Ch3LL - what do you think about this? I'm creating a PR about this in a minute. |
Ch3LL
added
State-Module
Bug
|
I appreciate your responses, but sorry, your "correct approach" seems like a workaround to me. We used to do that, but moved to the more concise form, as stated above: Which is also "correct" according to current documentation. But it fails on SLES, therefore this bug report. |
|
Hey @dumol , thanks for your response. I'm not sure, looking at the documentation [1] it's not clear to me whether a new group should be created or not if
More over, looking at
That's the reason why I think I would really appreciative others opinions here. Thanks! [1] - https://docs.saltstack.com/en/latest/ref/states/all/salt.states.user.html#salt.states.user.present |
|
Ah, I see, interesting… Perhaps the documentation should be improved to also say If a group specified here does not exist on the minion, the state will fail for Maybe with may instead of will? Because we use this for a number of OS'es and it only fails on SLES and MacOS (over there with a different error, see #45142). Possibly all the others (RHEL, Ubuntu, Debian, Arch, Alpine, FreeBSD and OpenBSD) automatically create the group with the user, and things just work… Still, there's room for improvement here. The state shouldn't apply silently on first run on SLES. And an improved error should be emitted. What do you think? Thanks! |
|
@dumol, I agree with you. I've created #45365 which addresses this issue by:
I think others OS'es probably creates a group with the same name as the user when the user is being created by "useradd" or similar. Then on a second run of the state, it applies successfully as the group exist now. But for SUSE and maybe others, a group with the same name is not actually created and that's why it passes the first time and then we get the error. With the PR I pointed here, we always check first if the group exist before creating the user so the state will fail even in other OS'es. What do you think? |
|
Fine by me. Thanks! |
Fixes saltstack#45345 Ensure empty string gid is set to None Make pylint happy Fix integration tests for 'user.present' state. Update documentation for 'gid_from_name' parameter Refactor to prevent logical bug when gid is 0
Fixes saltstack#45345 Ensure empty string gid is set to None Make pylint happy Update documentation for 'gid_from_name' parameter Refactor to prevent logical bug when gid is 0 Fix integration tests for 'user.present' state.
Most linux distros add this automatically, probably as a part of adduser, but this is not done on macOS and some other systems. Ref saltstack/salt#45345 (comment).
Fixes saltstack#45345 Ensure empty string gid is set to None Make pylint happy Update documentation for 'gid_from_name' parameter Refactor to prevent logical bug when gid is 0 Fix integration tests for 'user.present' state.
Fixes saltstack#45345 Ensure empty string gid is set to None Make pylint happy Update documentation for 'gid_from_name' parameter Refactor to prevent logical bug when gid is 0 Fix integration tests for 'user.present' state.
Description of Issue/Question
When trying to create a user through Salt with
gid_from_name: True, our SUSE minions silently fail to create needed group and to set it afterwards. On subsequent runs, an error is returned:These values could not be changed: {'gid': ''}.Setup
Master is Ubuntu 16.04 running 2017.7.1. The issue was observed with 2017.7.2 too.
State to reproduce the error:
Steps to Reproduce Issue
When applying above state multiple times, following two types of errors are returned on the SUSE minions after the first run (as detailed above):
Debug logs for the SLES 12 minion:
First run:
Second run:
Versions Report
On master:
On slaves:
The text was updated successfully, but these errors were encountered: