Puppetrun failures when default 01_users is in place

[a-dekker]

I noticed that the puppetrun fails when /etc/grub.d/01_users (part of grub2-tools-2.02-0.64.0.1.el7.x86_64 on redhat 7) is present:

Notice: /Stage[main]/Linuxbase::Grub/Grub_user[root]/password: password changed '${GRUB2_PASSWORD}' to 'grub.pbkdf2.sha512.10000.<long_string>'
Error: Grub_user[root](provider=grub2): Please ensure that your *active* GRUB2 configuration is correct. Puppet::Type::Grub_user::ProviderGrub2 thinks that you need an update, but your file content did not change

01_users includes /boot/grub2/user.cfg for the password hash if found, but we do not make use of a user.cfg file, so this code does nothing.
It seems a bit strange that I have to remove the 01_users file in order to make the puppetrun succeed?

[wiad]

Setting superuser with augeasproviders_grub does not work for me either, probably since the before mentioned update of grub2-tools in RHEL. I don't get any warnings though, but edit access to the grub menu is open for anyone even though i configured 'superuser' with grub_user.

This is the content of /etc/grub.d/01_users:

#!/bin/sh -e
cat << EOF
if [ -f \${prefix}/user.cfg ]; then
  source \${prefix}/user.cfg
  if [ -n "\${GRUB2_PASSWORD}" ]; then
    set superusers="root"
    export superusers
    password_pbkdf2 root \${GRUB2_PASSWORD}
  fi
fi
EOF

So the 'set superusers' is only set if the ${prefix}/user.cfg file exists with a GRUB2_PASSWORD var in it.

If I create that file, with a dummy password, everything works as expected. The password I specify with grub_user overrides the dummy password i input in user.cfg. So thats my workaround right now, creating a user.cfg with a dummy grub password, but it sure would be nice if it worked without that hack.

[trevor-vaughan]

@wiad Is this still the case with the latest 3.0.1 release? A new file, /etc/grub.d/02_puppet_managed_users should now be created that takes precedence over the system defaults.

[wiad]

hm, I tried it with the latest release from puppet forge (i.e. 'puppet module install'), not sure what version that was. I will check it out.

[a-dekker]

Having noticed that superusers has not been set on multiple servers (although defined), I upgraded to version 3.0.1 to see how things worked out.

The absence of superusers was still an issue. It did no longer give me puppetrun failures when /etc/grub.d/01_users was present, so I also created a user.cfg with dummy password as @wiad suggested.
This way superusers was added via /boot/grub2/grub.cfg.

[jeannegreulich]

There is still a problem with this. Using version 3.1.0 with a system that has 01_users in place, if grub_user is used to build a new user say 'admin', root will no longer be part of the superuser. It creates a new line and does not add root (probably because it exists in the line from 01_users). Even if root is also added with grub_user, it never adds root to the correct superuser line. It appears the superuser line is last one wins out. Somehow it has to include all the users on the superuser line.

[trevor-vaughan]

@jeannegreulich I think you may have hit on the key there that all of the users have to end up on the superuser line.

I can't find any documentation on this so I don't know if you can even have more than one (even though the word is plural).

Also, there is guidance that root should not be used as the superuser identity in various security guides so we can't just drop it in there by default. If you want a user named root, you'll need to add it.

Can someone add multiple superusers and mod the single line and let me know what actually works?