Allow scheduling of agent run.

[bryanjbelanger]

This module is resource intensive.

Customers don't want this running every half hour or so.

A scheduler should be accepted that limits the time this can run.

[bjvrielink]

Good idea. But, not every class is resource intensive. Consider limiting the scheduler to only those that user facts that do filesystem scans.

N.B. On my TODO list (but, somewhere near the bottom) is to look at the facts this module uses and if there are any optimizations that are possible. Most of them use shell commands within Ruby, and perhaps some facts that scan the filesystem can be combined into one big fact that provides output for all related facts from 1 script.

[bjvrielink]

Note that the facts are resource intensive, and they are run every time Puppet runs (even on hosts where the secure_linux_cis class is not included). A scheduler that only conditionally includes this class will not reduce any resources.

I recently became aware of an hadoop cluster I need to harden...

[bryanjbelanger]

It looks like facts can be cached. I don’t believe we should put any engineering into the module to do this. It would be hard to implement/ Would a snippet of facts for the facter.conf file in the README make sense? https://puppet.com/docs/facter/3.9/configuring_facter.html Bryan Belanger | Principal Consultant Azcender: www.azcender.com<http://www.azcender.com/> phone: +1 (248) 613-2538 | email: [email protected]<mailto:[email protected]> On Mar 4, 2020, at 3:24 AM, Bart-Jan Vrielink <[email protected]> wrote: Note that the facts are resource intensive, and they are run every time Puppet runs (even on hosts where the secure_linux_cis class is not included). A scheduler that only conditionally includes this class will not reduce any resources. I recently became aware of an hadoop cluster I need to harden... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#36?email_source=notifications&email_token=ACBKLJCQ4K5UY5CMEKJQPUDRFYF2FA5CNFSM4KWGXIHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENW2ATQ#issuecomment-594387022>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACBKLJA6W3DX6HAXUI5BQO3RFYF2FANCNFSM4KWGXIHA>.

[bryanjbelanger]

Nope, This only works for build in facts. There is a solution on the forge that might work. Bryan Belanger | Principal Consultant Azcender: www.azcender.com<http://www.azcender.com/> phone: +1 (248) 613-2538 | email: [email protected]<mailto:[email protected]> On Mar 4, 2020, at 10:52 AM, Bryan Belanger <[email protected]<mailto:[email protected]>> wrote: It looks like facts can be cached. I don’t believe we should put any engineering into the module to do this. It would be hard to implement/ Would a snippet of facts for the facter.conf file in the README make sense? https://puppet.com/docs/facter/3.9/configuring_facter.html Bryan Belanger | Principal Consultant Azcender: www.azcender.com<http://www.azcender.com/> phone: +1 (248) 613-2538 | email: [email protected]<mailto:[email protected]> On Mar 4, 2020, at 3:24 AM, Bart-Jan Vrielink <[email protected]<mailto:[email protected]>> wrote: Note that the facts are resource intensive, and they are run every time Puppet runs (even on hosts where the secure_linux_cis class is not included). A scheduler that only conditionally includes this class will not reduce any resources. I recently became aware of an hadoop cluster I need to harden... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#36?email_source=notifications&email_token=ACBKLJCQ4K5UY5CMEKJQPUDRFYF2FA5CNFSM4KWGXIHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENW2ATQ#issuecomment-594387022>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACBKLJA6W3DX6HAXUI5BQO3RFYF2FANCNFSM4KWGXIHA>.

[bryanjbelanger]

It looks like the best way to do this is to move the executables into the facts.d directory.

The facts can be flagged there with a "TTL" file.

Many of the facts are already scripts and can easily be moved.

The rest might require a little more work.

[bryanjbelanger]

https://github.com/puppetlabs/puppetlabs-stdlib/blob/master/lib/facter/facter_dot_d.rb

# @summary
# A Facter plugin that loads facts from /etc/facter/facts.d
# and /etc/puppetlabs/facter/facts.d.
#
...
# In the case of scripts you can also create a file that
# contains a cache TTL. For foo.sh store the ttl as just
# a number in foo.sh.ttl
...

[bjvrielink]

Is there an easy way to disable the scheduler? When developing on this module, I do a lot of 'puppet agent --test' runs, and would expect Puppet then to apply all manifests, but it happily skips any resources where the schedule says "not yet".

[canihavethisone]

@bryanjbelanger I am seeking some clarification regarding the new schedule feature, particularly as it now uses the resources (firewall) block. My issue is that this block contains the purge resource, which I would otherwise use in a wrapping class. I setup a schedule however if my thinking is correct, the purging of undefined firewall rules will now happen independent of Puppet and not appear in logs?

Can you please clarify this? I prefer to have a purge occur on any given Puppet run and result in a change recorded in logs.

Also, I noticed that the version number in the changelog does not match the metadata. Currently one is 2.0.12 the other 2.1.12.

[bryanjbelanger]

@canihavethisone thanks for finding the metadata problem. Will address.

I am not sure what you mean by "purging of undefined firewall rules will now happen independent of Puppet and not appear in logs". Purged firewall rules should appear in the logs.

Is this what you mean?

[canihavethisone]

@bryanjbelanger I stand corrected, i now understand that the schedule feature coincides with a puppet run and the results appear in logs. However, binding the purge with a schedule (in my opinion) is not ideal. For example, a manual puppet run will not purge on demand. I guess I am trying to understand the reasoning behind using the resource (firewall) function (which prevents a wrapping module using it) and binding it with a requirement to use the schedule?