Puppet users - Apr 2012 - Virtual resources for a list of server ip addresses in Apache config

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.

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.

On Apr 18, 7:09 am, Robert Rothenberg <rob...@gmail.com>
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.