FAQ
I have an internal web site that can only be accessed from other servers.

It seems to me that I should pass an array of the addresses to the class
that instantiates the template for the Apache configuration. That seems
easy.

The hard part is getting every node to "register" itself so that it's IP
address is added to the array.

I imagine using virtual resources, e.g. something like

define website::client {
$website::clients += [ $title ]
}

and in each node definition (specifically outside the node { ... }
declaration)

@website::client{ $ip_address_of_node: }

and somewhere else

Website::Client <| |>

I would expect that for every node, it's ip address would be added to the
array. But this doesn't seem to work. In the "website" class, the $clients
array is never changed from what it is initialized to.

What are the best practices for doing something like this?

Thanks,
Robert


--
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/-/9xKEBi6ZyTcJ.
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.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

  • Robert Rothenberg at Apr 18, 2012 at 12:09 pm
    I should add that I am using a masterless puppet environment, so a global
    list of all nodes is not available.

    Some Googling suggested the use of multiple files that are concatenated,
    but I think that's a messy kluge, and would like to avoid doing that.
    On Wednesday, April 18, 2012 12:38:08 PM UTC+1, Robert Rothenberg wrote:

    I have an internal web site that can only be accessed from other servers.

    It seems to me that I should pass an array of the addresses to the class
    that instantiates the template for the Apache configuration. That seems
    easy.

    The hard part is getting every node to "register" itself so that it's IP
    address is added to the array.

    I imagine using virtual resources, e.g. something like

    define website::client {
    $website::clients += [ $title ]
    }

    and in each node definition (specifically outside the node { ... }
    declaration)

    @website::client{ $ip_address_of_node: }

    and somewhere else

    Website::Client <| |>

    I would expect that for every node, it's ip address would be added to the
    array. But this doesn't seem to work. In the "website" class, the $clients
    array is never changed from what it is initialized to.

    What are the best practices for doing something like this?

    Thanks,
    Robert

    --
    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/-/tP9dLmF-A74J.
    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.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jcbollinger at Apr 19, 2012 at 1:19 pm

    On Apr 18, 7:09 am, Robert Rothenberg wrote:
    I should add that I am using a masterless puppet environment, so a global
    list of all nodes is not available.

    As far as I am aware, there is no solution available entirely Puppet
    that would work in masterless mode.

    Some Googling suggested the use of multiple files that are concatenated,
    but I think that's a messy kluge, and would like to avoid doing that.

    If a puppetmaster were involved then you could look at either exported
    resources or a shared central data source to approach this problem.
    There are viable solutions along each path.

    Without a master, the issue of clients registering themselves is hard,
    especially if you require any kind of trust management. With no
    master to mediate data transfer (or trust), you'll need to come up
    with something custom. Here are some possible alternatives:

    * You could build a Puppet-aware registration service on the web
    server. It could control an actual Puppet manifest defining your
    array of client IPs, or else a data file that one of your manifests
    relies upon.

    * You could have clients manage registration files in some shared
    network filesystem, and have the server collect them and extract the
    pertinent data.

    * You could create a registration database to which clients would
    write and from which the master would read. The read / write
    interfaces might be implementable via templates, but it would be
    cleaner to build custom types (and providers) for that.

    * You could give up on self-registration, and manage the client list
    on the server separately from the clients themselves. That would be
    the least up-front work and the most secure approach, but slightly
    more ongoing work as clients are added and removed.


    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.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedApr 18, '12 at 11:38a
activeApr 19, '12 at 1:19p
posts3
users2
websitepuppetlabs.com

2 users in discussion

Robert Rothenberg: 2 posts Jcbollinger: 1 post

People

Translate

site design / logo © 2022 Grokbase