Closed msgarbossa closed 6 years ago
Hi. I am an automated pull request bot named Curry. There are commits in this pull request whose authors are not yet authorized to contribute to Chef Software, Inc. projects or are using a non-GitHub verified email address. To become authorized to contribute, you will need to sign the Contributor License Agreement (CLA) as an individual or on behalf of your company. You can read more on Chef's blog.
There are 1 commit author(s) whose commits are authored by a non-GitHub verified email address. Chef will have to manually verify that they are authorized to contribute.
I'm going to close this PR out since we never got a CLA or DCO signoff and master has drifted significantly since this was created.
Description
Previously the user_manage resource would always create a group for each user where the groupname matches the username. This behavior is not always desirable when more control over the groups that get created is preferred. A workaround existed previously by creating the group in a separate resource before calling user_manage, reloading ohai with the etc plugin, and then calling user_manage with a group_id and referring to a data bag where every user has the gid key field populated with a non-numeric groupname. This update adds the use_usergroups attribute to streamline the process. The default for use_usergroups is set to True, preserving the previous functionality of the user_manage resource. Setting use_usergroups = false does 2 things.
If the group_id is specified, a check is done at the beginning to make sure the group exists. Previously, this was not necessary because the primary group would always be set to the username, ensuring useradd would succeed. Without this check at the beginning, useradd could fail if the primary group for the user did not exist first.
More information on the default behavior of useradd can be found in the man page for login.defs under the USERGROUPS_ENAB setting.
Issues Resolved
https://github.com/chef-cookbooks/users/issues/85