Manage a specific users shadow file entry

[Jagga Soorma]

Hi Guys,

I am new to puppet and trying to figure out what is the best way to manage a password for a specific user in the /etc/shadow file.  Most of my users are being authenticated to kerberos but there is a need to set a local password for this one account.  What would be the best method to do this via puppet?  I have built my own rpm's in the past using the chpasswd command but that seems like a lot more work to build a rpm everytime the password changes.  Was hoping there was a easier/better way to do this via puppet.

Thanks,

-J

[Keiran Sweet]

Hi There,

The user provider allows you to manage the value of the password hash in the shadow file.

You can see all the options available for this provider via 'puppet describe user'.

An example would be something like:

user { username: 

          ensure      => present,

          password  => 'password_hash_here',

        }

To quote the puppet documentation: 

  **password** - The user's password, in whatever encrypted format the local system requires.

To get all this working as you want, you may need to ensure that your operating systems authentication configuration (ie, PAM) checks for authentication in the right order, ie, local passwords, then kerberos, and you should test this carefully to make sure you dont get undesired results.

Hope this helps,

K

[Jagga Soorma]

Thanks for your response Keiran.  I am trying to use just that resource but can't seem to get it to work.  Here is what my class looks like:

class oracle_password {

  user { 'oracle':

    ensure   => 'present',

    password => '$1$etSqP2ht$3sjFIsw7q7Vxs5qc5sju//'

  }

}

[root@testrhel home]# grep -i oracle /etc/shadow

[root@testrhel home]# 

Now once this resource is applied my assumption is there should be a /etc/shadow file entry for the oracle account but that never happens:

[root@testrhel home]# puppet agent -t

Info: Retrieving plugin

Info: Caching catalog for testrhel.gene.com

Info: Applying configuration version '1356045773'

/Stage[main]/Oracle_password/User[oracle]/password: created password

Finished catalog run in 0.99 seconds

[root@testrhel home]# 

[root@testrhel home]# grep -i oracle /etc/shadow

[root@testrhel home]# 

Sorry but you might receive a similar message twice.  Forgot to reply to this post.

Thanks,

-J

[Jagga Soorma]

Also, is there maybe a way to ensure a specific entry in a file.  In this case, can you ensure there is a entry for the oracle user in the /etc/shadow file with manually giving it all the entries including the password hash.

Thanks,

-J

[Jagga Soorma]

Just in case anyone is trying to do something similar.  I found this on the web and it seems to work for me.  

define line($file, $line, $ensure = 'present') {

    case $ensure {

        default : { err ( "unknown ensure value ${ensure}" ) }

        present: {

            exec { "/bin/echo '${line}' >> '${file}'":

                unless => "/bin/grep -qFx '${line}' '${file}'"

            }

        }

        absent: {

            exec { "/bin/grep -vFx '${line}' '${file}' | /usr/bin/tee '${file}' > /dev/null 2>&1":

              onlyif => "/bin/grep -qFx '${line}' '${file}'"

            }

            # Use this resource instead if your platform's grep doesn't support -vFx;

            # note that this command has been known to have problems with lines containing quotes.

            # exec { "/usr/bin/perl -ni -e 'print unless /^\\Q${line}\\E\$/' '${file}'":

            #     onlyif => "/bin/grep -qFx '${line}' '${file}'"

            # }

        }

    }

}

class oracle_password {

  file { "/etc/shadow":

    ensure => present,

  }

  line { oracle_passwd:

    file => "/etc/shadow",

    line => 'oracle:$1$aa8QIjTa$tu0gVzq94iPqdj1YMKMKu0:15695:0:99999:7:::',

 }

}

Regards,

-J

[Keiran Sweet]

All,

The root cause of this issue was that on RHEL the 'usermod -p "<string>" username' command returns zero in the event that a user exists in the passwd file even if they dont have a corresponding entry in the shadow file.  The knock on effect of this is that the user provider assumes that the update to the password hash has been actioned and reports accordingly, when in fact the usermod command does nothing and exits with zero.

This configuration may occur if a user is added to the passwd file outside of the usual user administration tools without running pwconv, or if the environment uses krb5 for authentication in which you may find users defined in the passwd file without shadow entries.

K

[Jagga S]

Keiran beat me to it :). My work around is to have our kickstart manually add a entry to the shadow file for the oracle user for new oracle servers and to manually update the existing servers shadow file and then manage the password via the user resource.  The other method I pointed out seems to have issues when you have to update the password more than once.  I would rather rely on usermod than the tee command to modify the shadow file.  Have been bitten by scripts destroying the root entry in the shadow file before so don't want to take any chances.

Thanks again to Keiran for helping me through this.

-J

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/cEnql0ha_WIJ.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.