What issues are you seeing?

DSC logs filling up, Puppet runs taking forever. I have one last ditch effort thing to try but if it doesn't work, we'll probably have to move off of it

Pretty sure the DSC logs getting bigger and bigger are what are causing the DSC resources to take a long time.

Noticed that DSC's LCM has a configuration option called 'ConfigurationMode' which appears to be set to ApplyandMonitor by default, which according to Microsoft will cause it to log when its config drifts. Since we're using Puppet to apply DSC resources, seems dumb to let DSC also monitor config drift

shucks that didn't seem to help

@RyChannel just checking with DevX team Im sure there was some option around how DSC loggec

@David SandilandsClearing out those logs didn't seem to actually help the runtime at all either

@RyChannel I got an update from one of our SEs who knows Windows well "He was on the right track with ConfigurationMode option per Microsoft's documentation: https://learn.microsoft.com/en-us/powershell/dsc/managing-nodes/metaconfig?view=dsc-1.1 The slowness is normal unfortunately, I'm curious if their org has PowerShell Transcription enabled via Group Policy or something."

That would be a CIS control setting that 😄

I think some of our issue is PE reporting metrics that we don't understand, the other part being, that if an agent is ran from the PE console, it takes a lot longer than if puppet agent -t is run from the server. It doesn't make any sense to us.

Turning it off didn't help

It'd be really cool if we could export/import Custom Profiles in SCM

You can export them: https://help.puppet.com/scm/current/Content/UserGuide/SCM/custom_profiles_export.htm. Import is a different question...

Export doesn’t actually seem to work anyway. Page is just stuck at loading data…

Is there a target release for SCE support of RHEL9 DISA STIG?

Our STIG compliance is based on CIS STIG benchmark. There is not currently an available CIS benchmark for RHEL9 STIG. Last I heard, there was a draft benchmark in progress, but no release date established. Until they release a benchmark, we can't write an SCE enforcement.

CIS_Red_Hat_Enterprise_Linux_9_Benchmark_v2.0.0.pdf

I wouldn’t put it up here were it not free to dwnload. 🙂

This is weird. Seems the control for fixing log file perms just randomly stopped working

Oh dumb it was the name_filter. Apparently it’s excluding everything

Which is odd

It’s a fairly specific regex

Ugh forget what I said. It working fine. Puppet fixed it right after I audited it so when I ran puppet it didn’t appear to do anything

I am new to SCM/comply. I am trying to run puppet agent on some hosts I want to be scanned, but they are complaining about a checksum mismatch on Assessor-CLI-4.43.0.zip. Anybody have any thoughts on that? Notice: /Stage[main]/Comply:ScannersCiscat/Exec[Assessor CLI 4.43.0.zip]/returns executed successfully (corrective) Error: Download file checksum mismatch (expected: b165c4fda3bfa1dccd5d17016486f2207b5842c46aecbb8807b1a47552a5e229 actual: 9f88ff4faa3b9ae03a95c2dfb4d84ada7c8daf07f2622be1149d4447719c383d) Error: /Stage[main]/Comply:ScannersCiscat/Archive[Assessor CLI 4.43.0.zip]/ensure change from (sha256)9f88ff4faa3b9ae03a95c2dfb4d84ada7c8daf07f2622be1149d4447719c383d to (sha256)b165c4fda3bfa1dccd5d17016486f2207b5842c46aecbb8807b1a47552a5e229 failed: Download file checksum mismatch (expected: b165c4fda3bfa1dccd5d17016486f2207b5842c46aecbb8807b1a47552a5e229 actual: 9f88ff4faa3b9ae03a95c2dfb4d84ada7c8daf07f2622be1149d4447719c383d) N I am using version 3.3.0 of the comply module

Hi, I am installing SCM on a RHEL 8 server. I have installed bolt and run

bolt plan run complyadm::install

. The podman containers all look to be up, however I am unable to access the UI. Checking the network settings of the container, I see it is set to bridge mode. Am i missing some sort of configuration? Firewalld is disabled so I don't think its the firewall

Hey, @Chandler Hagan, have you opened a support ticket on this yet? They have the best tools and resources to help you troubleshoot your issue.

Are there any plans for implementing SAML SSO on SCM

Any SCM updates coming soon? Our vulnerability scanner is screaming about the old version of Java in the assessor on all nodes

We made a ticket (01380412) about a bug in

sce_linux::utils::packages::linux::auditd

but the response from support seems wrong. That class has an (undocumented) parameter

$manage_auditd_rulesd

which to me seems clearly intended to be used for enabling full management of the directory

/etc/audit/rules.d

, meaning that unmanaged files will be purged. That parameter defaults to

false

. The bug is that setting that parameter to

true

only sets

purge => true

on the

file

resource, and the

recurse

attribute is missing. From the docs,

purge

only makes sense when `recurse => true`: https://github.com/puppetlabs/puppet/blob/e227c27540975c25aa22d533a52424a9d2fc886a/references/types/file.md?plain=1#L492-L493 But the response from support was that this is intentional: "The

sce_linux

module is designed to manage only the files it creates and does not purge others to avoid accidentally removing any custom configurations you may have in the same directory. Our team has intentionally chosen not to remove unmanaged files to prevent potential issues." This response from support doesn't make sense because you can't accidentally remove custom configurations when the default value for the parameter is

false

, you have to intentionally set it to

true

. It is pretty clear that the parameter was intended to allow for purging unmanaged files, otherwise the parameter is useless. There is no other way to accomplish this, since the

file

resource in

sce_linux

is managing the directory, we can't also manage the directory in our own code. Can we get this ticket reevaluated?

I think we've made the call to stop using sce_windows, agent runs take too long to run because of the DSC slowness that we can't get any answers about