command to variable

[Tamas Papp]

hi All,


I have a manifest with this (the module was downloaded from github for
generating known_hosts):
define ...{

[...things...]

## Ensure that all files and execs get the correct user/group
combinations.
Exec {
user => $user,
group => $user,
require => File[$root],
}
File {
ensure => $ensure ? { present => file, default => absent },
owner => $user,
group => $user,
}

}



My problem is that group -> $user does not true in all cases. Instead of
this I would like to use the true values of the user.

group should be something like

$group = `id -ng` user

group => $group,


This obviously doesn't work. But what is the right solution?
I am not master of puppets, but my guess is that I need a fact,
however, facts look good only for system wide settings.


Thank you,
tamas

[jcbollinger]

On Wednesday, September 3, 2014 4:30:57 AM UTC-5, Tamás PAPP wrote:

hi All,


I have a manifest with this (the module was downloaded from github for
generating known_hosts):
define ...{

[...things...]

     ## Ensure that all files and execs get the correct user/group
combinations.
     Exec {
         user => $user,
         group => $user,
         require => File[$root],
     }
     File {
         ensure => $ensure ? { present => file, default => absent },
         owner => $user,
         group => $user,
     }

}



My problem is that group -> $user does not true in all cases.

Indeed.  The code you downloaded is rather naive.

 

Instead of
this I would like to use the true values of the user.

group should be something like

$group = `id -ng` user

group => $group,


This obviously doesn't work. But what is the right solution?
I  am not master of puppets, but my guess is that I need a fact,
however, facts look good only for system wide settings.

There are several viable solutions.  I would favor putting your users and groups under management, and keeping (user, group) relationships in your external data.  Then you could choose the correct group for any given user by, say, looking up the username in a hash.  Strictly speaking, it is not mandatory in that case to put the users and groups under management, but doing so makes sense if you are relying on anything about them, including their existence.  You then don't need to worry about how users and groups initially are, which is comparatively hard to know, but rather on how they will be, which would be easy to know.


John

[Tamas Papp]

On 09/03/2014 08:20 PM, jcbollinger wrote:

There are several viable solutions.  I would favor putting your users and groups under management, and keeping (user, group) relationships in your external data.  Then you could choose the correct group for any given user by, say, looking up the username in a hash.  Strictly speaking, it is not mandatory in that case to put the users and groups under management, but doing so makes sense if you are relying on anything about them, including their existence.  You then don't need to worry about how users and groups initially are, which is comparatively hard to know, but rather on how they will be, which would be easy to know.

There are system and ldap users as well, I cannot manage all of them by puppet.
The users, their database is already there so I need to adapt the rest of the system.

t

[jcbollinger]

If you need to discover user -> group mappings for a small number of users whom the node you can identify in advance of catalog compilation, then you can write a custom fact by which to communicate that information to the master.  That does not seem to be your situation, however.

Where the agent needs to perform an evaluation such as you describe during catalog application, the canonical approach is to write a custom type and provider.  Since that's non-trivial, I think it's fairly common to use an Exec instead.  All resource properties recorded in the catalog are constants; you cannot embed a command as if catalogs were scripts.


John