> 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. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAE4bNT%3D3DJ66y7ok7VaXSRAgHiYOmw4ejAHBgAB4WB28%3DFyfYg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
