Solaris useradd uses /export/home and not /home

[Andreas Dvorak]

Dear all

I have puppet 3.2 running and have a module to install user. On Linx user are created in /home but on Solaris it wants to create them in /export/home. I don't understand why.

class admin_user::group {
   group { "baaderadm":
      gid => "888",
      ensure => present,
   }
}

class admin_user::add {
   define useradd ( $name, $uid, $group, $gid, $password, $shell, $sshkeytype, $sshkey) {
      $homedir = "/home"
      $username = $title

      user { $username:
         ensure => present,
         comment => "$name",
         uid => "$uid",
         gid => "$gid",
         shell => "$shell",
         home => "/home/$username",
         managehome => true,
         password => "$password",
         require => Group["baaderadm"],
      }

      ssh_authorized_key { $username:
         user => "$username",
         type => "$sshkeytype",
         key => "$sshkey",
         require => user["$username"],
      }
   }
}

class admin_user {
   include admin_user::group, admin_user::list, admin_user::add
}

The error message:
Error: Could not create user user1: Execution of '/usr/sbin/useradd -u 1059 -s /bin/bash -g 888 -d /export/home/user1 -c user1 -m user1' returned 12: UX: /usr/sbin/useradd: ERROR: Unable to create the home directory: No such file or directory.

Error: /User[user1]/ensure: change from absent to present failed: Could not create user user1: Execution of '/usr/sbin/useradd -u 1059 -s /bin/bash -g 888 -d /export/home/user1 -c user1 -m user1' returned 12: UX: /usr/sbin/useradd: ERROR: Unable to create the home directory: No such file or directory.

If i execute:
/usr/sbin/useradd -u 1059 -s /bin/bash -g 888 -d /home/user1 -c user1 -m user1
it does work.

Does somebody have an idea?

Best regards,
Andreas

[Dick Davies]

/export/home and /home are odd on solarises.

what you could try is managehome => false and create the directory itself with puppet.

file { "/home/$username":

  ensure => directory,

....

}

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To post to this group, send email to puppet...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Andreas Dvorak]

Hi Dick,

thank you for the help, but it did not change anythink. The error mesage stays exactly the same.

Puppet ignores the setting of the home variable.

Now I have created the missing home directory in /export and the user is created, but in the wrong directory.

Best regards
Andreas

[jcbollinger]

Something is very screwy here.  Is your actual User resource is exactly as you present?  In particular, is the value of the 'home' parameter to your misbehaving User resource exactly as you present?  Because the simplest explanation would be that the base directory is really expressed in terms of a variable (e.g. "$home/$username"), and the base directory part has a different value than you expect.

If the exact declaration you presented in fact does produce the result you reported, then either the User type or the selected User provider is misbehaving.  The default provider for Solaris is normally "user_role_add", but if you have installed a custom User provider then is might be chosen instead.  If you run the agent with --debug logging enabled then it should warn you about any such conflict.  Also, you can ensure that the agent uses user_role_add on solaris clients by adding this to your user declaration:

  provider => $::osfamily ? { 'solaris' => 'user_role_add', default => undef }

If adding that changes the behavior, then you really ought to find the other User provider that was previously being chosen, and figure out what its purpose is supposed to be, as you would be circumventing it by using user_role_add.

You might also want to check the catalog delivered to the client.  It's in YAML format, so you can read it with ordinary text tools.  What you're looking for is whether the catalog specifies '/home/user1' or '/export/home/user1'.  If the former, then the problem resides on the client (and thus probably in the provider); if the latter, then it resides on the master, in the User type itself.


John

[Andreas Dvorak]

Hi John,

I can see that it does use the provider user_role_add, but there seems to be a problem.

Debug: /User[user1]: Provider user_role_add does not support features libuser; not managing attribute forcelocal

I get the same message when I run it on RedHat 6.

In the catalog file I find this
{"exported":false,"line":18,"title":"user1","parameters":{"uid":"2012","password":"$6$0vY.Ob.b$uOClxMYJohHBH46X/ESzliv.Jxt1XoWXjbLXtnf5JzqL5pP.caiF0JMxjptxEq9gj72KrU7CqB7ez0gCt6fAB1","shell":"/bin/bash","gid":"888","home":"/export/home/user1","managehome":true,"comment":"user1","ensure":"present"},"tags":["user","user1","useradd","class","admin_user::list","admin_user","list","node","base"],"type":"User"

It is already wrong in the catalog file.

Andreas

[Andreas Dvorak]

I forgot: Yes the init.pp file is the one I use.

[jcbollinger]

On Friday, September 13, 2013 3:10:10 AM UTC-5, Andreas Dvorak wrote:

Hi John,

I can see that it does use the provider user_role_add, but there seems to be a problem.

Debug: /User[user1]: Provider user_role_add does not support features libuser; not managing attribute forcelocal

That's not a problem unless you are trying to use the 'forcelocal' attribute for some of your users.  Otherwise it's just informational.  You are not declaring 'forcelocal' for your test user, so you can ignore it.

 

I get the same message when I run it on RedHat 6.

That's a bit strange, though, since RH 6 should be choosing the 'useradd' provider.  But you said user management is working on RH6, so I'm going to ignore that.
 

In the catalog file I find this
{"exported":false,"line":18,"title":"user1","parameters":{"uid":"2012","password":"$6$0vY.Ob.b$uOClxMYJohHBH46X/ESzliv.Jxt1XoWXjbLXtnf5JzqL5pP.caiF0JMxjptxEq9gj72KrU7CqB7ez0gCt6fAB1","shell":"/bin/bash","gid":"888","home":"/export/home/user1","managehome":true,"comment":"user1","ensure":"present"},"tags":["user","user1","useradd","class","admin_user::list","admin_user","list","node","base"],"type":"User"

Do you also see that in the catalogs on your RH6 machines?  If so, do new users' home directories in fact get created elsewhere than the catalog specifies?


John

[Andreas Dvorak]

Hi John,

the catalog file in RH6 is fine with "home":"/home/user1" and the user is created in /home/user1

That problem seems to be complicate.

Andreas

[jcbollinger]

On Friday, September 13, 2013 3:12:20 AM UTC-5, Andreas Dvorak wrote:

I forgot: Yes the init.pp file is the one I use.

And you can confirm that by changing that user declaration and seeing the corresponding change in the catalog delivered to the client?

If the User declaration you are looking at is the one that is actually being used, but the parameters included in the catalog are not exactly as declared, then I see only two possibilities:

1. Your master's Puppet code has been hacked to inject the modification.
2. The parameters are being overridden somewhere.

Since a hack seems rather unlikely, I would look for overrides.  Those could appear in direct or indirect subclasses of class admin_user::add, or in User collection expressions.  For example, the latter could look like this:

User<| title == 'user1' |> {
   home => '/export/home/user1'
}


This is really getting quite speculative, though.  Can you present a simple, complete example that demonstrates the problem?  What you presented above lacks any declaration of instances of your admin_user::add::useradd definition, and any indication of what else may be declared on the target node.  If you use a node declaration like the following for the test node then does it still behave as you observed?

node <testnode-certname> {
  include 'admin_user::group'

  notify { 'node verification':
    message => 'confirmed using the test node block'
  }

  addmin_user::add::adduser { 'user1":
    # all needed parameters
  }
}


John

[jcbollinger]

On Friday, September 6, 2013 6:43:27 AM UTC-5, Andreas Dvorak wrote:

class admin_user::add {
   define useradd ( $name, $uid, $group, $gid, $password, $shell, $sshkeytype, $sshkey) {
      $homedir = "/home"
      $username = $title

      user { $username:
         ensure => present,
         comment => "$name",
         uid => "$uid",
         gid => "$gid",
         shell => "$shell",
         home => "/home/$username",
         managehome => true,
         password => "$password",
         require => Group["baaderadm"],
      }

      ssh_authorized_key { $username:
         user => "$username",
         type => "$sshkeytype",
         key => "$sshkey",
         require => user["$username"],
      }
   }
}

Note also, by the way, that the version of class admin_user::add presented does nothing at all for you except provide a namespace for the definition inside.  In fact, could the problem be that its definition is not the one that you're actually using?  You should really put the definition in its own file.  For example,

modules/admin_user/manifests/useradd.pp:
----
# Promoted to the module's namespace
define admin_user::useradd ( $comment, $uid, $gid, $password, $shell, $sshkeytype, $sshkey) {
   # changed parameter $name to $comment to avoid
   #   colliding with the automatic variable $name
   # parameter $group was unused in the original
   # variable $homedir was unused in the original

   # This definition breaks if class admin_user::group
   # isn't declared *somewhere*.  It's not parameterized,
   # so it can safely be declared right here.
   include admin_user::group

   $username = $title

   user { $username:
      ensure => present,

      comment => "$comment",

      uid => "$uid",
      gid => "$gid",
      shell => "$shell",
      home => "/home/$username",
      managehome => true,
      password => "$password",
      require => Group["baaderadm"],
   }

   ssh_authorized_key { $username:
      user => "$username",
      type => "$sshkeytype",
      key => "$sshkey",

      # type 'User' not capitalized in the original:
      require => User["$username"],
   }
}


Also, always declare instances using the defined type's full name:

admin_user::useradd { 'user1':
  # ...
}


John

[Andreas Dvorak]

Many thanks John. Now it is solved.

Here is the solution.

init.pp

class admin_user::group {
   group { "baaderadm":
      gid => "888",
      ensure => present,
   }
}

class admin_user {
   include admin_user::group, admin_user::list
}

list.pp
class admin_user::list {
   admin_user::useradd { "user1":
      comment => "user1",
      uid => "1032",
      gid => "888",
      group => "baaderadm",
      shell => "/bin/bash",
      password => '$6$QMhC7iyQ$CeUQnyZR1/jkH61SaE7gz/',
      sshkeytype => "rsa",
      sshkey => "AAAAB3NzaC1yc2EAAAABIwAAAIEAs+EjM0/U4rGLe5OipRtqkwkfk93KX/i6N8=",
   }
 admin_user::useradd { "user2":
      comment => "user2",
      uid => "1033",
      gid => "888",
      group => "baaderadm",
      shell => "/bin/bash",
      password => '$6$QMhC7iyQ$CeUQnyZR1/jkH61SaE7gz/',
      sshkeytype => "rsa",
      sshkey => "AAAAB3NzaC1yc2EAAAABIwAAAIEAs+EjM0/U4rGLe5OipRtqkwkfk93KX/i6N8=",
   }
}

useradd.pp
define admin_user::useradd ( $comment, $uid, $group, $gid, $password, $shell, $sshkeytype, $sshkey) {

   include admin_user::group
   $username = $title

   user { $username:
      ensure => present,
      comment => "$comment",
      uid => "$uid",
      gid => "$gid",
      shell => "$shell",
      home => "/home/$username",
      managehome => true,

      forcelocal => true,

      password => "$password",
      require => Group["baaderadm"],
   }

   ssh_authorized_key { $username:
      user => "$username",
      type => "$sshkeytype",
      key => "$sshkey",

      require => User["$username"],
   }
}