Virtual resources for a list of server ip addresses in Apache config

[Robert Rothenberg]

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

[Robert Rothenberg]

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.

[jcbollinger]

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