Passing data between hosts

[Matthew Ceroni]

Scenario:

Managing DNS via Puppet. On the master I need to be aware of slave NS servers so that the NS record can be put into the zone file.

Creating a zone you supply an array with the name of all the name servers. Hard coding this into a hiera file (as an example) doesn't scale well as new servers come online.

Also, on the slaves I need to be aware of the masters to allow for zone transfer (again this is passed in via an array to the class that create the zone).

Is there a way I can pass, lets say a variable (ie: dns_slave = SLAVE-IP and dns_master = MASTER-IP) between slaves and masters? That way on the slaves I can compose my array of masters and pass that to the class and vice verse on the masters.

I know I can use exported resources but I am not really exporting a resource just some data? Or would I encapsulate this in some sort of resource and then export that?

Thanks

[Christopher Wood]

Rather than reimplement master/slave replication, why not use Puppet to configure one of the DNS servers that already do this?

This is along the lines of don't configure thousands of users in puppet, configure ldap authentication.

> --
> 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 [1]puppet-users...@googlegroups.com.
> To view this discussion on the web visit
> [2]https://groups.google.com/d/msgid/puppet-users/CA%2BNsY5iB2oP1ub_H7moRRBnLr_mW9bxFCEiumTMiYBJ_aH%3DwSQ%40mail.gmail.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:puppet-users...@googlegroups.com
> 2. https://groups.google.com/d/msgid/puppet-users/CA%2BNsY5iB2oP1ub_H7moRRBnLr_mW9bxFCEiumTMiYBJ_aH%3DwSQ%40mail.gmail.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout

[Matthew Ceroni]

Not sure what you mean?

Part of configuring DNS master is to list the slaves. Therefore I need a way on the master to determine the IPs of the slaves. Dynamically is what I am hoping to do. Instead of having to place data statically in a hiera file for example

[Daniel Dreier]

One option for doing this type of service discovery with puppetdb is puppetdbquery (https://github.com/dalen/puppet-puppetdbquery). For example, if your slave NS servers are configured using a profile called profile::nameserver::slave and the master is configured using a profile called profile::nameserver::master, the slave profile might query for something like:

$dns_masters = query_nodes("Class[Profile::Nameserver::Master]", ipaddress)

Conversely, the master profile might query for

$dns_slaves = query_nodes("Class[Profile::Nameserver::Slave]", ipaddress)

The $dns_masters variable would end up as an array of ipaddresses, listing all nodes which include the profile::nameserver::master profile. The $dns_slaves array would similarly contain a list of ipaddresses listing nodes which include profile::nameserver::slave.

There are two big caveats with this approach:

1) you have a circular dependency; when you boot new infrastructure, you'll need to run puppet a few times in order for all the nodes to discover each other.

2) if a node drops out of puppetdb, it will be removed from your configuration. For example, if you configure a puppetdb node ttl and then somebody disables puppet on one of the DNS servers, after the node ttl expires the node will disappear from puppetdb and will consequently be de-configured. If somebody assumes that puppetdb data is ephemeral and does a node deactivate on a bunch of nodes it will cause configuration changes. If you somehow generate empty catalogs, you will also have nodes drop out of configuration.

The only workaround I'm aware of is to explicitly check the results and either fail() if you get back an unexpectedly low number of results, or to make management of the config files in question conditional upon the size of the returned array. For example, you may decide that you do not wish to manage config files for DNS slaves when there are zero masters. The advantage of this approach is that you can still bootstrap, whereas if you fail you have a more complicated question around bootstrapping a cluster.

--

Daniel Dreier

Technical Operations Engineer

GPG: BA4379FD

[Peter Kristolaitis]

One possible solution is to have your ENC do a discovery for the slaves/masters and build the list dynamically.   There are a few possible ways that you could do that;  the 2 approaches I would look at first would be:

- Use 'mco find' to list all the currently-online nodes, or
- Examine the list of certs issued by Puppet and parse the certificate names

If you're running mcollective, the 'mco find' option might be preferable because it represents "current state" -- that is, "here is a list of nodes that are online right now that you can talk to".   If a node goes offline, it gets removed from the list for all the other nodes on their next agent run, and it would get re-added when it comes back online.   That may or may not be desired behaviour in your environment, however.

The main downside to examining the cert list is that unless you're conscientious about removing certs for decommissioned hosts, it may not be accurate.

- Peter

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CA%2BNsY5iB2oP1ub_H7moRRBnLr_mW9bxFCEiumTMiYBJ_aH%3DwSQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.