Before I make a fool of myself at Voxpupuli Chrony .... I'm doing security compliance (Qualys, CIS, etc) and I'm getting dinged on /etc/sysconfig/chrony not having OPTIONS='-u chrony' to ensure that the chrony daemon runs as the chrony user. Something in my brain tells me that /etc/sysconfig/chrony is deprecated (I'm on RHEL6 through 8 ). I have a need to manage the /etc/sysconfig/chrony file in order to pass compliance audits but before I do the work I wanted to know how/if you're meeting this compliance item (if at all) and if I should submit a change to the Voxpupuli project.

my puppet ca cert got expired and I was able to renew it successfully. We have lot of clients that needs a new cert using this CA. is there a way to force generate the certs on the clients ? Removing the contents from ssl folder and restarting the puppet agent worked, but wanted to know if there is a better procedure?

it's not deprecated, still used in RHEL9 as well

I'm wondering why /etc/sysconfig/chrony hasn't been implemented in the module...hence my trepidation of submitting such code.

that's a common trend in most of the modules, sysconfig is left alone

-u chrony

is compiled into daemon by default, by the way

use shellvar or just file if you must

Yeah, but my problem is that the vendor of the auditing/compliance software is very bad about how they do their scans.

They all are.

The crony daemon obviously runs as the chrony user but their code doesn't check that.

that sounds like you just need to tell qualys that they're wrong and give them ps -ef proof

so, if you set /etc/sysconfig/chronyd but alter service.d not to use it, everything is fine? 🙂

So what my company ends up doing is removing an audit rule so that we 'pass' the audit. I'm using Qualys and Rapid7 and both of them seem to use the same rules from CIS benchmarks.

Rapid7 is doing "egrep '^\s*OPTIONS\s*=\s*"([^"#]*\s+)*-u\schrony\b[^"#]*"\s*(?:#.*)?$' /etc/sysconfig/chronyd' and since '-u chrony' isn't there (which it doesn't need to be there) I fail the check.

So what I'm doing is putting in something redundant just to shut up the report.

at least for us

@Lumiere, the problem is that they're not good about changing their rules.

I have no idea if our scanning team or rapid7 is tweaking rules on our side

but we do a lot of stuff like "no that cve is fixed by version x of this package in el7"

@Lumiere God, yes. I'm constantly explaining why versions of PHP from php.net don't align with the PHP RPM from Red Hat to the Qualys guys.

and we pay money for these things!

You'd think Qualys (and Tenable and every other scanner) would know that RHEL packaged versions are != to vendor versions. I lost count how many times we've used the same excuse: Fixed in RHEL version x.

maybe we can convince Puppet to make a not dogs&#t version of all of this with their new bosses at perforce to put all these others out of business

CIS benchmarks, STIG, etc. == swamp/morass

all of the security standards are wishywashy

Since the /etc/sysconfig/chronyd file is only one line and there can be multiple entries in "OPTIONS='option1 option2'" etc, what would be the best practice to populate the options in the file? A single string? Any array of options and their values or maybe a hash with option,value key/vaules?

Most of my coding has not been writing from scratch and I want to ensure that whatever I submit to the voxpupuli/chrony project won't waste their time.

Also, I have to be cognizant of existing chronyd setting and not step on them if possible.

The last thing I want is to submit a breaking change.

Depends on if you want Puppet to own the entire file or if you want to allow some values to be Puppet-managed and others not. If you go the “own the entire file” route, I think a parameter that takes an array of strings makes sense. Then you can write the file with an epp template that iterates over each entry in the array.