Group with the same name as user is Always created.

[ruriky]

By default each user has a group with the same name. You can change this with manage_group parameter:

If I set manage_group = false, a group with the same name as the user is always created. I haven't been able to prevent that with any set of configuration.
For example, in my test case, where I want to create a new group with name mygroup which has the same gid as the user's uid. It fails with the error below:

accounts::users:
  testuser:
    ensure: 'present'
    home: "/home/testuser"
    shell: "/bin/bash"
    uid: 1141
    gid: 1141
    primary_group: 'mygroup'
    manage_group: true

Error: Could not create group mygroup: Execution of '/sbin/groupadd -g 1141 mygroup' returned 4: groupadd: GID '1141' already exists
Error: /Stage[main]/Accounts/Accounts::Group[mygroup]/Group[mygroup]/ensure: change from absent to present failed: Could not create group mygroup: Execution of '/sbin/groupadd -g 1141 mygroup' returned 4: groupadd: GID '1141' already exists

Greping /etc/group shows that there is a new group with same as the user and gid is set to users uid (this is the default behavior of puppets 'user' function when no gid is provided - am I correct ?)

$ grep 1141 /etc/group
testuser:x:1141:

I get the same error if I move the creation of mygroup under accounts::groups.

Puppet version is 3.8.6 and OS is RHEL7.

[deric]

@ruriky Have you installed deric-gpasswd module which is listed in dependencies?

[d-helios]

Have the same issude

here is my hiera:

accounts::groups:
  dba:
    gid: 31461
  asmdba:
    gid: 31462
  asmoper:
    gid: 31463
  asmadmin:
    gid: 31464
  oper:
    gid: 31465
  backupdba:
    gid: 31466
  dgdba:
    gid: 31467
  kmdba:
    gid: 31468
  oinstall:
    gid: 31460
accounts::users:
  oracle:
    uid: 31470
    primary_group: 'oinstall'
    manage_group: false
    comment: "oracle_user"
    groups:
      - dba
      - asmdba
      - asmoper
      - asmadmin
      - backupdba
      - dgdba
      - kmdba
  grid:
    uid: 31471
    primary_group: 'oinstall'
    manage_group: false
    comment: "grid_user"
    groups:
      - dba
      - asmdba
      - asmoper
      - asmadmin

result:
[root@srv5-romatsa ~]# puppet agent -t |grep Accounts
Notice: /Stage[main]/Accounts/Accounts::User[oracle]/User[oracle]/ensure: created
Notice: /Stage[main]/Accounts/Accounts::User[grid]/User[grid]/ensure: created
Notice: /Stage[main]/Accounts/Accounts::Group[dba]/Group[dba]/members: members changed '' to 'grid,oracle'
Notice: /Stage[main]/Accounts/Accounts::Group[asmdba]/Group[asmdba]/ensure: created
Notice: /Stage[main]/Accounts/Accounts::Group[asmoper]/Group[asmoper]/ensure: created
Notice: /Stage[main]/Accounts/Accounts::Group[asmadmin]/Group[asmadmin]/ensure: created
Notice: /Stage[main]/Accounts/Accounts::Group[oper]/Group[oper]/ensure: created
Notice: /Stage[main]/Accounts/Accounts::Group[backupdba]/Group[backupdba]/ensure: created
Notice: /Stage[main]/Accounts/Accounts::Group[dgdba]/Group[dgdba]/ensure: created
Notice: /Stage[main]/Accounts/Accounts::Group[kmdba]/Group[kmdba]/ensure: created

[root@srv5-romatsa ~]# id -a oracle
uid=31470(oracle) gid=31470(oracle) groups=31470(oracle),31461(dba),31462(asmdba),31463(asmoper),31464(asmadmin),31466(backupdba),31467(dgdba),31468(kmdba)
[root@srv5-romatsa ~]# id -a grid
uid=31471(grid) gid=31471(grid) groups=31471(grid),31461(dba),31462(asmdba),31463(asmoper),31464(asmadmin)

My PUppetfile

mod 'puppetlabs-stdlib', '4.15.0'
mod 'puppetlabs-ntp', '6.0.0'
mod 'puppetlabs-concat', '2.2.0'
mod 'puppetlabs-firewall', '1.8.2'
mod 'puppetlabs-motd', '1.4.0'
mod 'puppetlabs-inifile', '1.6.0'
mod 'puppetlabs-reboot', '1.2.1'
mod 'puppetlabs-acl', '1.1.2'
mod 'puppetlabs-lvm', '0.9.0'
mod 'puppetlabs-git', '0.5.0'
mod 'puppet-autofs', '2.1.1'
#mod 'puppetlabs-limits', '0.1.0'
mod 'arnoudj/sudo', '1.3.0'
mod 'kemra102/auditd', '2.2.0'
mod 'saz-rsyslog', '5.0.0'
mod 'saz-resolv_conf', '3.1.0'
mod 'thias-sysctl', '1.0.6'
mod 'herculesteam-augeasproviders_core', '2.1.3'
mod 'deric-accounts', '1.5.2'
mod 'deric-gpasswd', '0.3.2'
mod 'ceritsc-yum', '0.9.8'
mod 'jake-resource_tree', '1.0.1'
mod 'gbrown-yumrepos', '0.0.3'
mod 'walkamongus-realmd', '0.1.3'
mod 'puppet-autofs', '2.1.1'
mod 'thias-tuned', '1.0.3'
mod 'tracywebtech-pip', '1.3.4'
mod 'puppetlabs-postgresql', '4.9.0'
mod 'erwbgy-limits', '0.3.1'
mod 'herculesteam-augeasproviders_grub', '2.4.0'
mod 'biemond-oradb', '3.0.4'

[guk2017]

I'm having the same issue here too, on 1.5.2... It seems as though primary_group is ignored - though it does seems to manage .ssh directory permissions correctly, effectively doing a chgrp $primary_group.

I have deric-gpasswd (0.3.2) installed.

[westbywest]

My setup under CentOS 6.9:

puppet agent v4.8.1
puppetserver v2.4.0 (running on another machine)
deric-gpasswd v0.3.2 (on the puppetserver)
deric-accounts v1.5.3 (16 Jan 2017 commit, on the puppetserver)

I also seem to be seeing the primary_group parameter ignored, despite setting default provider gpasswd for the group resource. Puppet agent debug shows useradd being called without any reference to the group named as primary_group. I.e. no -g option used.

[scottjl]

Same issue here with 7.x. This module is pretty much useless to me if I can't keep it from creating all these unwanted groups. deric-gpasswd is loaded.

[deric]

@ruriky Sorry for late reply. From Puppet's documentation:

gid: The user’s primary group. Can be specified numerically or by name.

It doesn't make much sense to set uid != primary_group. Currently what the module does is following:

/usr/sbin/useradd -d /home/testuser -s /bin/bash -u 1141 -m testuser
/usr/sbin/groupadd -g 1141 mygroup

The problem is in the first command. E.g. on Debian useradd creates by default group with the same name as username unless -N/--no-user-group is specified (not sure if other distributions behave the same). Probably creating an account without any primary group would solve that, as we assign the primary group later.

[scottjl]

I know it doesn't make sense, and that it's bad practice these days, but many years ago it wasn't common practice to set up a group for just one user. Unfortunately where I work at still has this legacy practice and all users are assigned into a common user group (users, consultants, security, etc.) as their primary group to share specific resources.

With CentOS 6 and OEL 6 at my location I can get the module to do this as I expect. But with CentOS & OEL 7 I can't. It insists on setting the primary group to the UID group even when specified otherwise.

And thanks, better late than never!

[deric]

Yeah, I understand your motivation. It sounds rather easy, but it's actually quite hard to implement.
The module currently creates user accounts first, then groups and assigns users into groups. The only exception are primary groups which are created with accounts.
An easy fix would be to create groups first. But then you'd have to remove all members of a group each puppet run if you want apply inclusive membership (only explicitly stated users are members of the group)

[scottjl]

Well I'm kind of confused why this works with 6 but not 7, but I don't understand the coding of the module, still too green with Puppet. I was able to get this working with Puppet's user module though it's lacking some of the features of yours. You might want to make note somewhere of this behavior so someone else doesn't spend the hours I did trying to figure out what was going wrong.

[deric]

I've managed to write a hacky way how to bypass commands executed by Puppet's providers. I'm not sure if this is the best way how to tackle this issue. But so far it's the only working solution. Following configuration works (with branch 1.6):

accounts::groups:
  mygroup:
    gid: 1141
accounts::users:
  testuser:
    ensure: 'present'
    home: "/home/testuser"
    shell: "/bin/bash"
    uid: 1141
    primary_group: 'mygroup'
    manage_group: true

The only exception are primary groups which are created with accounts.

This is not true anymore, User doesn't create groups anymore. It might bring many problems, that's why I try to keep this in an experimental branch. Any help with testing is welcomed!

The user & groups management in Puppet is not ideal, there's a huge epic for refactoring targeting Puppet 5. Hopefully this module won't be needed in future versions.

Btw. automated tests might be incomplete, but seems to pass on CentOS 7.