Fix uid and gid management

[johnzimm]

Custom UID and GID are able to be specified for each user, but if the group doesn't already exist the user's new group is not created before attempting to create the new user.

You would recieve a message similar to the following:

Error: Could not create user example: Execution of '/sbin/useradd -g 66666 -d /home/example -p * -u 66666 -m example' returned 6: useradd: group '66666' does not exist
Error: /Stage[main]/Profiles::Base/Accounts::Account[@herp]/Accounts::Account[example]/User[example]/ensure: change from absent to present failed: Could not create user example: Execution of '/sbin/useradd -g 66666 -d /home/example -p * -u 66666 -m example' returned 6: useradd: group '66666' does not exist

Without specifying a custom GID Puppet will autorequire the group for the user and select the next available GID

This commit modifies account.pp to create the new group with custom GID prior to creating the user.

Deletion of the group, regardless of the GID, will happen automatically when the user is purged using this module.

Another commit fixes problems with version pinning in the Gemfile that was causing builds to fail in travis-ci. All tests are now passing.

[johnzimm]

@mcanevet

Any comment for this pull request? Anything that needs / should be changed?

[johnzimm]

Curious if this module is still being maintained?

[raphink]

@johnzimm sorry, we've been really slow at reviewing PRs on this module… Honestly, I'm not sure we want to automate the creation of groups for users. Groups are usually linked to features and should be managed in component or profile modules imo.

[johnzimm]

@johnzimm sorry, we've been really slow at reviewing PRs on this module… Honestly, I'm not sure we want to automate the creation of groups for users. Groups are usually linked to features and should be managed in component or profile modules imo.

With this commit we are only trying to manage the group of the same name as the username being created and ensure that the UID and GID match. The feeling in the way we are currently using this module to manage accounts is that the UID and primary GID should match. All other groups are left untouched.

Our hieradata for a user looks like this...

profile::account_mgmt::users:
  user1:
    uid: 10001
    gid: 10001
    comment: 'User 1'
    password: '<hash>'
  user2:
    uid: 10002
    gid: 10002
    comment: 'User 2'
    password: '<hash>'

Our profile then essentially does this with that hash:

class { 'accounts':
  users => $users,
}

Prior to this PR the group would get created with whatever GID the system chose; which should still be the behavior if the GID is not specified.

We are looking at refactoring our user/group management in Puppet, but for the time being matching the uid and primary gid for users created with this module still makes sense to us.