FAQ
I'm trying to extend the standard 'user' type to add maintenance of some of
the contents of a user's home directory, and I'm trying to avoid creating
an entirely new custom type if I can. The approach I'm taking is to create
a site::user defined type which in turns calls the standard user type. I'm
having a problem figuring out how to manage the optional parameters.

The most likely path seems to be something like this (simplified for
example):

define site::user (
$comment,
$ensure,
$home,
$name = $title,
$password,
) {

user { "$title":
comment => $comment,
ensure => $ensure,
home => $home,
name => $name,
password => $password,
}
}

The problem with this, of course, is that the parameters to site::user
aren't optional, and I'd like them to be. I've tried setting their
defaults to null strings, but I get errors about reassigning variables if I
do that.

Of course, this would be even better.. but doesn't appear to be a valid
syntax in puppet:

define site::user ( $**args ) {
user { "$title":
$args
}
}

This seems to me to be the sort of thing that'd be in a puppet cookbook,
but google hasn't shown me any useful docs or examples for what I'm trying
to do. Does this approach even make sense, or is there a better way?

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

Search Discussions

  • Jcbollinger at Jan 28, 2013 at 4:15 pm

    On Saturday, January 26, 2013 6:55:57 PM UTC-6, Matthew Pounsett wrote:
    I'm trying to extend the standard 'user' type to add maintenance of some
    of the contents of a user's home directory, and I'm trying to avoid
    creating an entirely new custom type if I can. The approach I'm taking is
    to create a site::user defined type which in turns calls the standard user
    type.


    That's a good and widely-used approach.


    I'm having a problem figuring out how to manage the optional parameters.

    The most likely path seems to be something like this (simplified for
    example):

    define site::user (
    $comment,
    $ensure,
    $home,
    $name = $title,

    Don't do that ($name = $title). Puppet provides it automatically (both the
    parameter and the default).

    Moreover, I am uncertain whether it is safe anyway to use $title as a
    resource default. It certainly *isn't* safe to use explicit resource
    properties, regardless of the order in which they are listed.


    $password,
    ) {

    user { "$title":
    comment => $comment,
    ensure => $ensure,
    home => $home,
    name => $name,
    password => $password,
    }
    }

    The problem with this, of course, is that the parameters to site::user
    aren't optional, and I'd like them to be. I've tried setting their
    defaults to null strings, but I get errors about reassigning variables if I
    do that.

    The usual paradigm is this:

    define mymodule::foo ( $param1 = 'NOTSET' ) {
    $real_param1 = $param1 ? {
    'NOTSET' => <some-appropriate-value-maybe-undef>,
    default => $param1
    }
    sometype { $name:
    param => $real_param1
    }
    }

    Yes, it's a bit clunky, but it works.


    Of course, this would be even better.. but doesn't appear to be a valid
    syntax in puppet:

    define site::user ( $**args ) {
    user { "$title":
    $args
    }
    }
    No, Puppet doesn't have anything like that. The closest would probably be
    the create_resources() function, which you can read about in the docs.


    This seems to me to be the sort of thing that'd be in a puppet cookbook,
    but google hasn't shown me any useful docs or examples for what I'm trying
    to do. Does this approach even make sense, or is there a better way?

    I'm surprised you didn't find an example like the one above. It appears
    all over the place, not least in the archives of this group.

    Also, have you read the official Puppet DSL docs (at
    http://docs.puppetlabs.com/puppet/3/reference/)? They don't answer your
    particular question, but they would have told you about $name, and they
    have a lot of other useful information.


    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Matthew Pounsett at Jan 28, 2013 at 5:07 pm

    On Monday, 28 January 2013 11:14:59 UTC-5, jcbollinger wrote:


    define site::user (
    $comment,
    $ensure,
    $home,
    $name = $title,

    Don't do that ($name = $title). Puppet provides it automatically (both
    the parameter and the default).
    In this case, $name is the login name of the user being created .. it's a
    valid parameter of the 'user' resource type. I'm not sure how I'm supposed
    to do not use it. I have read the Puppet reference manual.. but not for
    puppet 3, since I'm not using that.


    Moreover, I am uncertain whether it is safe anyway to use $title as a
    resource default. It certainly *isn't* safe to use explicit resource
    properties, regardless of the order in which they are listed.

    I'n not sure what you mean by that. Using $title as a default is widely
    used (see namevar) .. I'm not sure what you mean about explicit resource
    properties.

    The usual paradigm is this:
    define mymodule::foo ( $param1 = 'NOTSET' ) {
    $real_param1 = $param1 ? {
    'NOTSET' => <some-appropriate-value-maybe-undef>,
    default => $param1
    }
    sometype { $name:
    param => $real_param1
    }
    }
    Yes, it's a bit clunky, but it works.


    This is great if I want to set my own defaults, but I don't. The 'user'
    resource already has its own way of handling unspecified parameters, and I
    don't want to override those unless absolutely necessary. I think the
    above would require me to re-implement a bunch of its defaults logic, which
    would be especially problematic for things like 'gid'.


    No, Puppet doesn't have anything like that. The closest would probably be
    the create_resources() function, which you can read about in the docs.

    I'll have a look.. maybe there's some way I can make use of it.

    I'm surprised you didn't find an example like the one above. It appears
    all over the place, not least in the archives of this group.
    Also, have you read the official Puppet DSL docs (at
    http://docs.puppetlabs.com/puppet/3/reference/)? They don't answer your
    particular question, but they would have told you about $name, and they
    have a lot of other useful information.

    The only occurrence of the string "name" in the DSL doc at that location is
    as a placeholder... and it applies to ruby, not puppet manifests. I don't
    see anything there about use of $name inside a puppet class.


    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at Jan 29, 2013 at 3:24 pm

    On Monday, January 28, 2013 11:07:51 AM UTC-6, Matthew Pounsett wrote:


    On Monday, 28 January 2013 11:14:59 UTC-5, jcbollinger wrote:

    define site::user (
    $comment,
    $ensure,
    $home,
    $name = $title,

    Don't do that ($name = $title). Puppet provides it automatically (both
    the parameter and the default).
    In this case, $name is the login name of the user being created .. it's a
    valid parameter of the 'user' resource type. I'm not sure how I'm supposed
    to do not use it. I have read the Puppet reference manual.. but not for
    puppet 3, since I'm not using that.

    You are missing the point: Puppet automatically endows every defined type
    with a $name parameter, and automatically defaults its value to the
    $title. See
    http://docs.puppetlabs.com/puppet/3/reference/lang_defined_types.html#title-and-name.
    Though Puppet might not complain, it is at best poor form to declare the
    same thing explicitly.



    Moreover, I am uncertain whether it is safe anyway to use $title as a
    resource default. It certainly *isn't* safe to use explicit resource
    properties, regardless of the order in which they are listed.

    I'n not sure what you mean by that. Using $title as a default is widely
    used (see namevar) .. I'm not sure what you mean about explicit resource
    properties.

    I answer my own question: the automatic $title and $name parameters are
    documented safe to use as parameter defaults (but I'm not sure whether
    $name remains safe if you (re)declare it explicitly). No (other)
    parameters you explicitly define are safe for use as default values of
    other parameters. That is, you must not do this:

    site::user ( $uid, $gid = $uid ) {
    # ...
    }


    The usual paradigm is this:
    define mymodule::foo ( $param1 = 'NOTSET' ) {
    $real_param1 = $param1 ? {
    'NOTSET' => <some-appropriate-value-maybe-undef>,
    default => $param1
    }
    sometype { $name:
    param => $real_param1
    }
    }
    Yes, it's a bit clunky, but it works.


    This is great if I want to set my own defaults, but I don't. The 'user'
    resource already has its own way of handling unspecified parameters, and I
    don't want to override those unless absolutely necessary. I think the
    above would require me to re-implement a bunch of its defaults logic, which
    would be especially problematic for things like 'gid'.

    Note the "maybe-undef" in <some-appropriate-value-maybe-undef>. I'm
    referring there to the literal keyword 'undef', which should serve your
    needs. In this case you can also use 'undef' directly as the default, as
    Keith suggested, but that does not allow you to distinguish between the
    case where the user doesn't set a parameter and the one where he explicitly
    sets it to undef. You may not need that distinction now, but if you
    continue writing Puppet manifests then one day you will.



    No, Puppet doesn't have anything like that. The closest would probably
    be the create_resources() function, which you can read about in the docs.

    I'll have a look.. maybe there's some way I can make use of it.

    I'm surprised you didn't find an example like the one above. It appears
    all over the place, not least in the archives of this group.
    Also, have you read the official Puppet DSL docs (at
    http://docs.puppetlabs.com/puppet/3/reference/)? They don't answer your
    particular question, but they would have told you about $name, and they
    have a lot of other useful information.

    The only occurrence of the string "name" in the DSL doc at that location
    is as a placeholder... and it applies to ruby, not puppet manifests. I
    don't see anything there about use of $name inside a puppet class.
    You're not talking about a class, you're talking about a definition. The
    distinction is important. Anyway, I gave a direct link above to the docs
    for $name and $title in defined types.


    John

    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Keith Burdis at Jan 29, 2013 at 5:32 am
    You can set the default values to undef and then the standard user type
    will use its defaults (if any). It usually makes sense to default the
    ensure parameter to 'present' though because if it is undef then nothing
    will happen:

    define site::user (
    $ensure = 'present',
    $comment = undef,
    $home = undef,
    $password = undef,
    ) {
    user { $title:
    ensure => $ensure,
    comment => $comment,
    home => $home,
    password => $password,
    }
    ...
    }

    Note that $name and $title are the same thing so you probably shouldn't
    specify a value for $name.

    - Keith

    On 27 January 2013 00:55, Matthew Pounsett wrote:

    I'm trying to extend the standard 'user' type to add maintenance of some
    of the contents of a user's home directory, and I'm trying to avoid
    creating an entirely new custom type if I can. The approach I'm taking is
    to create a site::user defined type which in turns calls the standard user
    type. I'm having a problem figuring out how to manage the optional
    parameters.

    The most likely path seems to be something like this (simplified for
    example):

    define site::user (
    $comment,
    $ensure,
    $home,
    $name = $title,
    $password,
    ) {

    user { "$title":
    comment => $comment,
    ensure => $ensure,
    home => $home,
    name => $name,
    password => $password,
    }
    }

    The problem with this, of course, is that the parameters to site::user
    aren't optional, and I'd like them to be. I've tried setting their
    defaults to null strings, but I get errors about reassigning variables if I
    do that.

    Of course, this would be even better.. but doesn't appear to be a valid
    syntax in puppet:

    define site::user ( $**args ) {
    user { "$title":
    $args
    }
    }

    This seems to me to be the sort of thing that'd be in a puppet cookbook,
    but google hasn't shown me any useful docs or examples for what I'm trying
    to do. Does this approach even make sense, or is there a better way?

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

    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Matthew Pounsett at Jan 29, 2013 at 3:55 pm

    On Tuesday, 29 January 2013 00:29:43 UTC-5, Keith Burdis wrote:
    You can set the default values to undef and then the standard user type
    will use its defaults (if any). It usually makes sense to default the
    ensure parameter to 'present' though because if it is undef then nothing
    will happen:
    Ah, I see... I'd tried using empty strings, but for some reason undef never
    occurred to me. Thanks, it looks like this will work perfectly.


    >

    --
    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+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJan 27, '13 at 1:29a
activeJan 29, '13 at 3:55p
posts6
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase