multiple puppet masters, multiple puppetdb's

[Chris]

Hi all,

I'm trying to set up something that will have multiple puppet masters
(with one as the CA) and multiple puppet db's (they will be
geographically dispersed).

The multi-masters stuff all works fine, but I'm struggling with multiple
puppet db's.

Ideally I'd like puppet db to live on the same server as the puppet
master for a particular region (so a master + puppetdb in US, one in UK,
one in AU for starters) but I'm not sure if that's supported at all.

I've got puppetdb on the master CA server and that works fine, but if I
point the other masters to 'localhost' (in puppetdb.conf) I get ssl
errors on the agent runs:

Error: Could not retrieve catalog from remote server: Error 400 on
SERVER: Failed to submit 'replace facts' command for client1.local to
PuppetDB at localhost:8081: SSL_connect returned=1 errno=0 state=SSLv3
read server certificate B: certificate verify failed: [certificate
revoked for /CN=puppetmaster1.local]

I saw in the puppetdb docs about using postgres replication to do things
but if an agent has to go back to the main server for every run to
report, I don't understand why you'd want to do that.

Any help or ideas would be great.

Cheers,
Chris.
--
Postgresql & php tutorials
http://www.designmagick.com/

[José Luis Ledesma]

The problem is that the puppetdb certificate is not for localhost, but for puppetdb hostname.

You have two options:
1. Set in /etc/hosts puppetdb as  alias of localhost
2. Generate a new certificate for the puppetdb with an alias for local host as valid hostname.

I would prefer option 1.

Regards,

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/539A45DF.2070100%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Ken Barber]

> I'm trying to set up something that will have multiple puppet masters (with
> one as the CA) and multiple puppet db's (they will be geographically
> dispersed).
>
> The multi-masters stuff all works fine, but I'm struggling with multiple
> puppet db's.
>
> Ideally I'd like puppet db to live on the same server as the puppet master
> for a particular region (so a master + puppetdb in US, one in UK, one in AU
> for starters) but I'm not sure if that's supported at all.

The design would be driven by your requirements. If you don't care
about having data visible across both DC's, then you can certainly
configure a puppetdb instance with its own database in each region.

However if you expect data visibility across both data centres you'll
need to setup some sort of data replication.

> I saw in the puppetdb docs about using postgres replication to do things but
> if an agent has to go back to the main server for every run to report, I
> don't understand why you'd want to do that.

At a higher level replication is going to give you:

* Ability to use exported resources across both DC's
* Ability to use puppetdbquery to generate data within your Puppet
manifests across both DC's
* Ability to simply have 1 console to view reports across all DC's

The key point here being the 'view across both DC's' from a data perspective.

Now the PuppetDB service can be configured to specify 1 database to be
used for reads, and another database for read/write functionality
(storage of reports/facts/catalogs basically). See this link for the
details on how to configure this:
http://docs.puppetlabs.com/puppetdb/2.0/configure.html#read-database-settings

This can allow the possibility to keep a read/write postgresql
instance in 1 DC, and a local read-only copy in the other, but yes -
this does mean that ultimately all writes go back to the 1 DC, so if
that DC or that DB is down remediation will be required for writes,
but reads should continue for the other DC. This is an okay setup, but
can get complex when you have multiple DC's. I certainly do know of a
few cases where users have configured 1 central database for writes,
and then multiple read-only db's in each DC, so its workable.

For PDB we deal with DB outages by queueing up any requests inside the
PDB instance for when the 'downed' database is returned to service.
This acts as a good buffer for faults or when you want to take
remediation (such as failing database functions perhaps).

I guess the problem then becomes one of general PostgreSQL
replication, which is a tricky topic but with PostgreSQL 9.3 and above
the process is much easier than in the past.

> I've got puppetdb on the master CA server and that works fine, but if I
> point the other masters to 'localhost' (in puppetdb.conf) I get ssl errors
> on the agent runs:
>
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Failed to submit 'replace facts' command for client1.local to PuppetDB at
> localhost:8081: SSL_connect returned=1 errno=0 state=SSLv3 read server
> certificate B: certificate verify failed: [certificate revoked for
> /CN=puppetmaster1.local]

Kind of a separate topic to replication ... SSL is its own kind of pain.

The error "certificate revoked for /CN=puppetmaster1.local" seems to
indicate that the SSL certificate you have configured on the PuppetDB
has been revoked according to the client. These are the certs
specified in your /etc/puppetdb/conf.d/jetty.ini file.

Now PuppetDB normally (with the use of puppetdb ssl-setup) just grabs
the SSL certs from the Puppet agent on the localhost to use. If you
have renewed these certificates yourself, then you should redo the
setup step (puppetdb ssl-setup -f for example).

I'd try running puppetdb ssl-setup and see what it gives you, if the
certs don't match then try it again with the -f switch. If neither of
this helps, provide the output to the list and we'll take a look.

ken.