Open ruriky opened 7 years ago
@ruriky Have you installed deric-gpasswd
module which is listed in dependencies?
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'
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.
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.
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.
@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.
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!
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)
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.
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.
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 namemygroup
which has the same gid as the user's uid. It fails with the error below: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 ?)I get the same error if I move the creation of
mygroup
underaccounts::groups
.Puppet version is 3.8.6 and OS is RHEL7.