search

fervidus / secure_linux_cis

Apache License 2.0
16 stars 33 forks source link

Allow scheduling of agent run. #36

Open bryanjbelanger opened 4 years ago

bryanjbelanger commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.comhttp://www.azcender.com/

phone: +1 (248) 613-2538 | email: bbelanger@azcender.commailto:bbelanger@azcender.com

On Mar 4, 2020, at 3:24 AM, Bart-Jan Vrielink notifications@github.com 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 GitHubhttps://github.com/fervidus/secure_linux_cis/issues/36?email_source=notifications&email_token=ACBKLJCQ4K5UY5CMEKJQPUDRFYF2FA5CNFSM4KWGXIHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENW2ATQ#issuecomment-594387022, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACBKLJA6W3DX6HAXUI5BQO3RFYF2FANCNFSM4KWGXIHA.

bryanjbelanger commented 4 years ago

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.comhttp://www.azcender.com/

phone: +1 (248) 613-2538 | email: bbelanger@azcender.commailto:bbelanger@azcender.com

On Mar 4, 2020, at 10:52 AM, Bryan Belanger bbelanger@azcender.com<mailto:bbelanger@azcender.com> 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.comhttp://www.azcender.com/

phone: +1 (248) 613-2538 | email: bbelanger@azcender.commailto:bbelanger@azcender.com

On Mar 4, 2020, at 3:24 AM, Bart-Jan Vrielink notifications@github.com<mailto:notifications@github.com> 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 GitHubhttps://github.com/fervidus/secure_linux_cis/issues/36?email_source=notifications&email_token=ACBKLJCQ4K5UY5CMEKJQPUDRFYF2FA5CNFSM4KWGXIHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENW2ATQ#issuecomment-594387022, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACBKLJA6W3DX6HAXUI5BQO3RFYF2FANCNFSM4KWGXIHA.

bryanjbelanger commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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?