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 [email protected]. > 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 [email protected]. 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.
