puppet ressources user and group not doing anything

[Hadmut Danisch]

Hi,

just ran my old puppet tree (working with each ubuntu-version since 12.04) under 18.04 and found, that puppet does not modify /etc/passwd and /etc/group, but does not issue any error messages either. I.e. it says

Notice: /Stage[main]/Hadmut::Params/Hadmut::User[danisch]/User[danisch]/comment: comment changed 'Hadmut Danisch,,,' to 'Hadmut Danisch'
Notice: /Stage[main]/Hadmut::Params/Hadmut::User[danisch]/User[danisch]/shell: shell changed '/bin/bash' to '/usr/bin/zsh'
Notice: /Stage[main]/Hadmut::Params/Hadmut::User[danisch]/User[danisch]/groups: groups changed adm,cdrom,sudo,dip,plugdev,lpadmin,sambashare,libvirt,lxd to ['adm', 'cdrom', 'crontab', 'dialout', 'dip', 'docker', 'libvirt', 'lpadmin', 'lxd', 'plugdev', 'puppet', 'sambashare', 'sudo', 'vboxusers', 'video']

but then the entry is still

danisch:x:1000:1000:Hadmut Danisch,,,:/home/danisch:/bin/bash

as before. Group changes also not happening. With every run it notices to change the entries, but does not do anything.

regards

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: puppet 5.4.0-2ubuntu3
ProcVersionSignature: Ubuntu 4.15.0-20.21-generic 4.15.17
Uname: Linux 4.15.0-20-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.9-0ubuntu7
Architecture: amd64
CurrentDesktop: LXDE
Date: Thu May 3 16:26:45 2018
InstallationDate: Installed on 2018-04-30 (3 days ago)
InstallationMedia: Lubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
PackageArchitecture: all
SourcePackage: puppet
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.puppet.auth.conf: [modified]
modified.conffile..etc.puppet.hiera.yaml: [modified]
modified.conffile..etc.puppet.puppet.conf: [modified]
mtime.conffile..etc.puppet.auth.conf: 2018-05-03T16:00:05.317438
mtime.conffile..etc.puppet.hiera.yaml: 2018-04-30T16:13:58.865333
mtime.conffile..etc.puppet.puppet.conf: 2018-04-30T16:13:13.467947

[Christian Ehrhardt  (paelzer)]

# id puppet
uid=112(puppet) gid=119(puppet) groups=119(puppet)

$ puppet resource -e user danisch

user { 'danisch':
  ensure => present,
  uid => '1015',
  gid => '119',
  comment => 'Hadmut Danisch',
  shell => '/bin/bash',
  home => '/home/danisch'
}

When saving that on a bionic tree I get:
# puppet resource -e user danisch
Notice: Compiled catalog for b.lxd in environment production in 0.03 seconds
Info: Applying configuration version '1525418020'
Notice: /Stage[main]/Main/User[danisch]/ensure: created
Notice: Applied catalog in 0.13 seconds

Entries in passwd is
danisch:x:1015:119:Hadmut Danisch:/home/danisch:/bin/bash

Shouldn't that run the same backend code, but it works just fine?

What kind of configuration do you use exactly, could it be that upstream changed to no more support an old format?

Can you reduce your config to try just the user management and then check what the differences are to my example above?

Ubuntu makes no delta to upstream puppet in regard to the functionality discussed here which is why I assume it is due to the newer version, but maybe we can find the difference and resolve this for you.

[Hadmut Danisch (hadmut)]

This is strange.

Using a separate class with just such a single user resource, it works. In a huge puppet setup with hundreds of resources (that was working under 14.04, 16.04, 16.10,17.04.17.10) it does not work.

I will do some debugging and try to find the reason for that.

[Hadmut Danisch (hadmut)]

Found the problem. Or came closer to it.

That's the part from the puppet class for user setup:

  user{
    $name:
      ensure => present,
      groups => $groups,
      shell => $shellpath,
      password => $password,
      gid => $groupname,
      uid => $uid,
      comment => $description,
      allowdupe => true, # Distributionen kommen oft mit eigenem Benutzer
      require => $shelldep;

  }

This issues log messages about success, but doesn't do anything. But it works when removing the allowdupe parameter.

allowdupe was set because otherwise a standard setup which comes with the user ubuntu with uid 1000 oder if older accounts exist, they would block creating new users. This way new users are created, possibly with same uids as existing users (such as ubuntu with 1000), which are cleaned up in a later step to avoid having no valid user at all.

For testing purposes I've created a class which just consists of
class tests::versuch {
user { 'danisch':
  ensure => present,
  comment => 'Hadmut Danisch',
  shell => '/usr/bin/zsh',
  allowdupe => true,
}
}

and call

usermod danisch -s /bin/bash ; puppet apply -e 'include tests::versuch'

to see whether it changes the passwd entry. It works without allowdupe, but doesn't work with allowdupe (i.e. issues positive log messages, but doesn't save them.

It was working until ubuntu 17.10.

regards

[Hadmut Danisch (hadmut)]

(it's not the regular ubuntu distribution, but images like lxc, lxd, docker, raspberry that come with a preset user ubuntu with uid 1000, which was one of the reasons to add allowdupe => true, and to remove accounts like ubuntu in a later step. it was furthermore required if older accounts exist and changes in uid/gids have to be enforced.)

[Christian Ehrhardt  (paelzer)]

So could that just have changed over the years upstream?
And if so can you now run your config against e.g. a Cloud image which has this use created on first boot and still succeed with a config that dropped allowdupe?

[Hadmut Danisch (hadmut)]

It was just working under 16.04 and 17.10.

And: How could it make sense and be an intended upstream change if puppet reports and confirms changes that it does not perform?

(I will test this soon.)

[Launchpad Janitor (janitor)]

[Expired for puppet (Ubuntu) because there has been no activity for 60 days.]