Using resource collectors with variables from the collected resource?

[Richard Jacobsen]

Hi everyone.  An example is worth 1000 words, so here's one:

In this example I would like the home directory to be overridden to /testdir/me:

@user { 'me':

  ensure => present,

  home => '/home/$title',

  tag => 'userclass1'

}

User <| tag == 'userclass1' |> {

  home => "/testhome/$title"

}

It actually gets overriden to /testhome/main, 'main' being the class the collector is in, puppet apply tries to:

'/usr/sbin/useradd -d /testhome/main me'

I can sort of solve this problem by:

@fancyuser { 'me2':

  tag => 'userclass1',

}

define fancyuser($homedir_prefix='/home') {

  user { '$title':

    home => "$homedir_prefix/$title", }

}

Fancyuser <| tag == 'userclass1' |> {

  homedir_prefix => "/testhome"

}

This works as expected, as it doesn't rely on the '$title' of the collected virtual resource.  I'd rather just use the virtual resource's $title.  Is this possible, or am I asking too much from the resource collector?

Thanks!

Richard

[Peter Brown]

On 16 January 2013 04:12, Richard Jacobsen <zorgo...@gmail.com> wrote:

Hi everyone.  An example is worth 1000 words, so here's one:

In this example I would like the home directory to be overridden to /testdir/me:

@user { 'me':

  ensure => present,

  home => '/home/$title',

  tag => 'userclass1'

}

User <| tag == 'userclass1' |> {

  home => "/testhome/$title"

}

I would try using $name instead of $title in those.

It actually gets overriden to /testhome/main, 'main' being the class the collector is in, puppet apply tries to:

'/usr/sbin/useradd -d /testhome/main me'

I can sort of solve this problem by:

@fancyuser { 'me2':

  tag => 'userclass1',

}

define fancyuser($homedir_prefix='/home') {

  user { '$title':

    home => "$homedir_prefix/$title", }

}

Fancyuser <| tag == 'userclass1' |> {

  homedir_prefix => "/testhome"

}

This works as expected, as it doesn't rely on the '$title' of the collected virtual resource.  I'd rather just use the virtual resource's $title.  Is this possible, or am I asking too much from the resource collector?

Thanks!

Richard

--
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/-/DMBOqb9eIw4J.
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.

[Richard Jacobsen]

No, I tried that as well.  Still reports the class of the collector and not the $name of the virtual resource.

[Peter Brown]

Damn.

Sorry dude I am not sure what else else to suggest.

Your wrapper define may be the best way to go.

Unless you can configure the user adding functions to use different home prefixes for a user based on group or something like that.

The only other idea I can think of is setting up a symlink from the /home/$user directory to the other dir before you create the user.

--

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/-/7iVavMJx7f4J.

[jcbollinger]

On Tuesday, January 15, 2013 12:12:18 PM UTC-6, Richard Jacobsen wrote:

Hi everyone.  An example is worth 1000 words, so here's one:

In this example I would like the home directory to be overridden to /testdir/me:

@user { 'me':

  ensure => present,

  home => '/home/$title',

  tag => 'userclass1'

}

User <| tag == 'userclass1' |> {

  home => "/testhome/$title"

}

It actually gets overriden to /testhome/main, 'main' being the class the collector is in, puppet apply tries to:

'/usr/sbin/useradd -d /testhome/main me'

[...] I'd rather just use the virtual resource's $title.  Is this possible, or am I asking too much from the resource collector?

It is not possible.  Variable references are resolved in the scope in which they appear, which in this case is the one provided by the class or defined type instance in which the collection is declared.  The collection does not establish a new scope.


John