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.)