Hey Christopher,
This is the default behavior of PuppetDB -- my guess is you can address
it by tuning your node-ttl and node-purge-ttl parameters, which are
described here:
https://docs.puppet.com/puppetdb/latest/configure.html#node-ttl
PuppetDB won't expire or delete node data unless those parameters are
set, and they aren't by default. The reports are deleted after 14 days
by default (report-ttl setting), which would explain why you can see
node data but no reports.
Wyatt
On 02/21/2017 11:05 AM, Christopher Wood wrote:
Our security department raised that point that some nodes present in puppetdb
are not for current or recently decommissioned servers.
Does anybody have a spare hint as to why these nodes haven't become expired
over the last few months of not being servers, or where I can look for more
information? (PuppetDB 3.2.4.)
More details:
On further investigation, I can retrieve old catalogs for these nodes. The catalogs are weeks or
months old, and I thought the nodes themselves might have been expired by now. Sure enough, there
is nothing in the "deactivated" or "expired" fields in the certnames table in
PostgreSQL for these nodes. The hosts are definitely gone as servers.
curl --data-urlencode 'query=["=", "certname", "myhost.mydomain.com"]' -v -s -S -X
GET --cacert $ca --cert $cert --key $key https://puppetdb2.mydomain.com:8081/pdb/query/v4/catalogs
>/tmp/myhost.json
I am unable to retrieve reports for these nodes (200 response from puppetdb but
no actual report, '[]'). Likewise they do not appear in Puppet Explorer as
nodes. (Same as above but /reports not /catalogs.)
When I deactivated one of these nodes (puppet node deactivate) I was still able to
retrieve the same old catalog that I was able to before, but this time the
"deactivated" field in the certnames table was filled in.
puppetdb=# select * from certnames where certname = 'myhost.mydomain.com';
-[ RECORD 1 ]----+---------------------------
id | 2035
certname | myhost.mydomain.com
latest_report_id |
deactivated | 2017-02-21 12:28:25.495-05
expired |
We're on a slightly older version of PuppetDB (3.2.4). That said, Puppetdb has
been ticking along just fine for months and this is the first problem I can
remember.
bash-4.1$ rpm -q postgresql95-server
postgresql95-server-9.5.0-2PGDG.rhel6.x86_64
bash-4.1$ rpm -q puppetdb
puppetdb-3.2.4-1.el6.noarch
(Also, I can't find any reference to this issue with google searches or looking
on tickets.puppetlabs.com, and this is as far as I can figure out this issue.)
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/709a1e9b-1a10-ef9c-2144-5728bf2527d5%40puppet.com.
For more options, visit https://groups.google.com/d/optout.
