Puppet Community

and “yes”…. I’m annoyed my own article is missing.

weird issue, never seen one before
```The current total number of facts: 2071 exceeds the number of facts limit: 2048```
There is not even close when I check facts
```# facter -p |grep -c ^[a-z] 
130```
What gives ?

Try `facter -p --show-legacy | grep -c '^[a-z]'`

```# facter -p --show-legacy | grep -c -i '^[a-z]'
231```

```# puppet facts --render-as json|jq 'keys[]'|wc -l
131```

This ticket seems to imply that facts that are hashes of hashes causes the count of total facts to include each sub-hash: <https://tickets.puppetlabs.com/browse/PUP-11685>

yeah, it happens only on nodes running docker, probably very nested fact no one uses :slightly_smiling_face:

It really is quite odd that you can't block individual facts, even though you can cache individual facts.

Someone in my company wrote a patch to do just that.

I think there's actually a ticket on it that's been sitting there for a few years.

I wish I could blocklist an arbitrary fact, instead of some limited list

Can i just clarify how this was done in facter 3 ?

My understanding is you can add your own fact-groups in facter.conf for facter 4 (assuming not external facts) and then block those groups. (A silly two step to block but still)

<https://www.puppet.com/docs/puppet/7/configuring_facter.html#configuring_facter-facter-conf-fact-groups>

has anyone ever mocked a fact with onceover?

we have a bunch of custom facts that i'd like to conditionally set the values for and i cannot figure out how to do that

I'd also like to know if this is possible

Are you referring to mocking facts using something _other_ than by providing a fact set?
<https://github.com/dylanratcliffe/onceover#factsets>

i want to be able to add a fact dynamically based on the role name essentially

Raised it here: <https://github.com/puppetlabs/pdk/discussions/1206> <@UDDJQQZ38> FYI

That won't work.

Resource defaults, which is what `File { backup =&gt; main }` is, only affect resources in the same scope or in lower scopes.

So if you have that in a class, then include the class, it won't affect files unless they're also in that class or are contained in classes declared from that class.

This behavior of resource defaults is exactly why that file backup default is usually defined in the global space of site.pp.

A global backup default tends to be a bad thing. Easy to forget about and then it ends up storing copies of something like a large binary package that is already versioned on a file server.

Backup is a risky feature because it can consume a lot of resources. If you do use it, use it judiciously, sparingly, and explicitly so that folks can see it happening right on the affected resources.

Action at a distance is bad combination with this feature.

Thanks all,
When you say it consumes a lot of resources, do you only mean space?
If we don't have a class for Filebucket, is there an easy way to turn this feature on/off at will or is it a code change each time?

I am also having trouble trying to explain how this works because we don't have `File { backup =&gt; main, }` at all but we do have a class which we include that has
```  filebucket { 'puppet':
    server =&gt; $filebucket,
    path   =&gt; false
  }```
So it would seem that we don't actually set a `File` backup attribute default but we are leveraging puppets default and that seems to work.

I am still planning the upgrade of our fleet to Puppet 7 and the whole change to Filebucket algorithm is currently my blocking point.

Disk space. Also RAM, which is also a concern server-sude if you're using the server setting.

My general advice is to turn it off, it has a bunch of nasty failure modes. Much better to use Puppet to configure a tool that focuses on backup.

Also, I'll have been working with Puppet for a decade come this February and I honestly can't remember a single story of someone pulling content back from Filebucket :wink:

Yeah, we have used it once since our initial deployment that I am aware of and we have been using Puppet since v3.x

we have it enabled because of convenience I guess, especially given that we have of recently been starting to enforce more standards and its useful if we want to recover something like an apache config that gets overridden if someone isn't cautious with it

It was listed down as one of the pros and a reason why we started with Puppet :slightly_smiling_face:

Is puppets official recommendation not to use it?

Puppet isn't a backup tool. If you need backups, use Puppet to configure a backup tool.

also, I believe this page is now slightly inaccurate
<https://www.puppet.com/docs/puppet/7/types/filebucket.html>
`A repository for storing and retrieving file content by MD5 checksum.`
given Puppet 7 defaults for filebucket are now Sha256

Is puppet likely to deprecate/remove filebucket functionality?

Deprecation is possible. The only significant developments on filebucket in the past two major releases have been to disable it by default on the server side and then the client side.

Is RAM affected only during the catalog compilation and agent run? or is it more a permanent thing?

During runs. Puppet `file` resources aren't great about streaming content -- they tend to read things into memory. The effect on the server side gets multiplied by the number of active agents.

That's one reason a global backup default is dangerous: if it picks up a large binary file, then your agents can end up triggering the oomkiller locally or DOSing the server.

so using Puppet as a file server is also not advisable? we currently store some files on the Puppet servers and leverage the `puppet::///` path to retrieve things

For large files, anything more than a dozen MB or so, use a dedicated file server.

thanks for your time and input. :slightly_smiling_face:
I have a bit to think about on how to proceed. I don't think management will want to turn off filebucket :disappointed:

Do you have any ideas why Filebucket might be working if there is no `File { backup =&gt; main, }` defined at all?

It's reasonably safe if you use it explicitly where it will do the most good. Apache config files are a good example as those tend to be reasonably sized.

I've seen the global default approach take down dozens of infrastructures over the years because folks didn't see it was there when they added a large file -- I can't recommend using that.

Prior to Puppet 7, there was a local filebucket defined by default. So, any backup parameter stored copies locally on the agent.

we do have
```  filebucket { 'puppet':
    server =&gt; $filebucket,
    path   =&gt; false
  }```
defined in a class right now but we don't have the `File { backup =&gt; main, }`

I certainly know that filebucket is working and storing replaced files on our compilers.

Any file resource with `backup =&gt; 'puppet'` set would end up using that `filebucket` definition.

reading docs
<https://www.puppet.com/docs/puppet/6/types/file.html#file-attribute-backup>
and comparing that to
<https://www.puppet.com/docs/puppet/7/types/file.html#file-attribute-backup>

I can see the default is now set to `false`

This behavior is resource defaults is exactly why that file backup is default is usually defined in the global space of site.pp.

This behavior is resource defaults is exactly why that file backup default is usually defined in the global space of site.pp.