Dependency cycle when creating group and user

[dimov-cz]

I just updated from 1.2 to 1.3.2, one problem disappered for me but one new comes.

class {'accounts':
    groups => {
      'testgroup' => {
        'gid' => 800,
        'members' => [ 'www-data' ]
      }
    },
    users => { 'testuser' => {
      'shell'   => '/bin/bash',
      'manage_group' => true,
      'gid'                    => 800,
    }}
}

Error: Could not apply complete catalog: Found 1 dependency cycle:
(File[/home/testuser/.ssh/authorized_keys] => Accounts::User[testuser] => Class[Accounts::Users] => Class[Accounts::Groups] => Accounts::Group[testgroup] => Group[testgroup] => User[testuser] => File[/home/testuser/.ssh/authorized_keys])

I tried another options with primary_group etc. without success. Is there another way or workaround how to create group with exact gid and another user in it?

[deric]

Not sure what you're trying to do. This configuration should throw an error, because you're defining two groups with same gid (currently there's no check for such situation).

'manage_group' => true, will create primary group for testuser called Group[testuser] with gid => 800 and afterwards it will try to create Group[testgroup] with the same gid which is kind of nonsense.

If you want a group with several member you can do this

class {'accounts':
    groups => {
      'testgroup' => {
        'gid' => 800,
        'members' => [ 'www-data', 'testuser']
      }
    },
    users => { 'testuser' => {
      'shell'   => '/bin/bash',
    }}
}

or

class {'accounts':
    groups => {
      'testgroup' => {
        'gid' => 800,
        'members' => [ 'www-data']
      }
    },
    users => { 'testuser' => {
      'shell'   => '/bin/bash',
      'groups' => [ 'testgroup']
    }}
}

These configurations should be equivalent.

[dimov-cz]

Your examples are working and are equivalent and to be specific - they produce this:

group:
testuser:x:10003:
testgroup:x:800:www-data,testuser

passwd:
testuser:x:10003:10003:testuser:/home/testuser:/bin/bash

I can't figure out how to be exactly this ``testuser:x:10003:800:....`

[deric]

What about?

class {'accounts':
    groups => {
      'testgroup' => {
        'gid' => 800,
        'members' => [ 'www-data', 'testuser' ]
      }
    },
    users => { 'testuser' => {
      'shell'   => '/bin/bash',
      'primary_group' => 'testgroup'
    }}
}

[dimov-cz]

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Duplicate declaration: Group[testgroup] is already declared; cannot redeclare

[deric]

Yeah, that's a problem 😟 The 1.3.x release went through quite significant refactoring. It's still a bit experimental release. We're able to add/remove members to groups, but primary groups are a bit tricky.

[deric]

I've managed to get rid of the dependency cycle (in dev branch). Right now the GID is setted up yet, it's just a proof-of-concept:

1. create primary groups
2. create user accounts
3. create groups and assign users to them
   But it has many problems, for example we can't modify GID of existing groups. Proper solution would override groupmod in Puppet.

[jordigg]

Got the same error as @dimov-cz on 1.2.1.
Duplicate declaration: Group[myname] is already declared
Happens when I create a group with the same name as a user, and then trying to add that user to that group. Example hiera here:

accounts::groups:
  myname:
    ensure: present
accounts::users:
  myname:
    comment: "myname myname2"
    ssh_key:
      type: "ssh-rsa"
      key: "AAAAB3NzaC1yc2EAAAADAQABAAABAQC+g9RlVRmA84VPH8+UIszzH6eyRftEBk6cs0YbHRIY9amcWtv41ziCu1shFLRyYdcHpVo0YIrJj+lstpqNVE1PSISc8xYpksKkT81PWH/41YtxXn2VFtNgXGx20ziMXtHQatrs3UlcUaW"
      comment: "myname@domain"
    groups: ['sudo', 'myname']
    shell: '/bin/bash'

Works if I use a different group name different to the user.

[deric]

Merged into master, feel free to test it.

• removed dependency cycle
• manage GID of primary group
• apply all changes during single puppet run Apply all changes during single Puppet run #60

Following code works (tested on Debian 7 and CentOS 6 image):

        class {'accounts':
            groups => {
              'testgroup' => {
                'gid' => 800,
                'members' => ['www-data', 'testuser']
              }
            },
            users => {
              'testuser' => {
                'shell'   => '/bin/bash',
                'primary_group' => 'testgroup'
              },
              'www-data' => {
                'manage_group' => false,
                'home' => '/var/www'
              }
            }
        }

It creates user account:

testuser:x:1002:800:testuser:/home/testuser:/bin/bash

The problem is, that we create a testgroup (which is needed for testaccount):

  Info: accounts: /usr/sbin/groupadd -g 800 testgroup

but at the same time users are assigned:

  Info: accounts: /usr/bin/gpasswd -a www-data testgroup
  Info: accounts: /usr/bin/gpasswd -a testuser testgroup

although the command returns 0, nothing happens because the accounts don't exist yet.

[jordigg]

Just tested and tried to create a group with the same name as a user. It didn't work returning duplicated declaration. Is it something that should be fixed with this new changes?

[deric]

@jordigg could you test v1.3.3 release?

[jordigg]

@deric same error.

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Evaluation Error: Error while evaluating a Function Call, Duplicate declaration: Accounts::Group[it] is already declared; cannot redeclare at /etc/puppetlabs/code/environments/test/modules/accounts/manifests/groups.pp:15:5

Here my config:

#Debian default settings
#basic groups and accounts for debian
accounts:
 user_defaults:
   authorized_keys_file: '/etc/ssh/%u/authorized_keys'
   manage_group: false
   shell: "/bin/bash"
accounts::groups:
  it:
    ensure: present
accounts::users:
  it:
    comment: "IT Admin"
    managehome: true
    pwhash: '$1$dn3lUNjy$i00w1UuAzN7M/yNtGX0a9/'
    groups: ['sudo', 'it']
  jordi:
    comment: "Jordi Garcia"
    groups: ['sudo', 'it']
    shell: '/bin/zsh'

Works when using as group name itadmins and as user a different name, for example it. I guess if I used manage_group: true without creating the group individually would also work work, haven't tried that yet.

[jordigg]

Maybe I should open another issue but I noticed that group members are randomly ordered every time puppet runs.
Is there any way to make the list consistent so Puppet doesn't apply a change that isn't needed?

[deric]

@jordigg It shouldn't be a problem, if you have the latest version and latest gpasswd. I tried to fix that issue here.

[deric]

A workaround seems to be setting it as primary_group.

accounts::groups:
  it:
    ensure: present
accounts::users:
  it:
    comment: "IT Admin"
    managehome: true
    primary_group: 'it'
    pwhash: '$1$dn3lUNjy$i00w1UuAzN7M/yNtGX0a9/'
    groups: ['sudo']

Here's an example that works for me:

root@debian-8-x64:/# puppet apply -e "class{'::accounts': }"
Notice: Compiled catalog for debian-8-x64 in environment production in 0.41 seconds
Notice: /Stage[main]/Accounts/Accounts::Group[jordi]/Group[jordi]/ensure: created
Notice: /Stage[main]/Accounts::Users/Accounts::User[jordi]/User[jordi]/ensure: created
Notice: /Stage[main]/Accounts::Users/Accounts::User[jordi]/Accounts::Authorized_keys[jordi]/File[/home/jordi/.ssh]/ensure: created
Notice: /Stage[main]/Accounts::Users/Accounts::User[jordi]/Accounts::Authorized_keys[jordi]/File[/home/jordi/.ssh/authorized_keys]/ensure: created
Notice: /Stage[main]/Accounts/Accounts::Group[it]/Group[it]/ensure: created
Notice: /Stage[main]/Accounts::Users/Accounts::User[it]/User[it]/ensure: created
Notice: /Stage[main]/Accounts::Groups/Accounts::Group[sudo]/Group[sudo]/members: members changed '' to 'it,jordi'
Notice: /Stage[main]/Accounts::Users/Accounts::User[it]/Accounts::Authorized_keys[it]/File[/home/it/.ssh]/ensure: created
Notice: /Stage[main]/Accounts::Users/Accounts::User[it]/Accounts::Authorized_keys[it]/File[/home/it/.ssh/authorized_keys]/ensure: created
Notice: Finished catalog run in 0.42 seconds

[jordigg]

Didn't know primary_group was a thing! thanks for that, I'll give it a go.

[deric]

Should be fixed in v1.5.0, please open new issue if you run into any problems.