Well that was daft of me, and you're exactly right. After applying this tuning older things are purged as expected. Thank you!
On Wed, Feb 22, 2017 at 01:26:45PM -0800, Wyatt Alt wrote: > 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. -- 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/20170222215336.GA18751%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/d/optout.
