Puppet Community

:meeting: _:teacher: Bolt_ is about to start up in 15 minutes

:the_more_you_know: Next up is _:teacher:Puppet Forge_ in <https://www.timeanddate.com/worldclock/converter.html?iso=20230928T180000&amp;p1=202&amp;p2=179&amp;p3=919&amp;p4=307&amp;p5=3332&amp;p6=236&amp;p7=240|43 hours>

:meeting: _:teacher:Puppet Forge_ is about to start up in 15 minutes

<@U1PC2RAH0> do we have bodgit's approval to deprecate bodgit/sssd? Looks like that was released in the last couple years

See the `bodgit-sssd` module at <https://forge.puppet.com/bodgit/sssd?src=slack&amp;channel=office-hours>

yeah I guess that counts as approval :smile:

wait, no it doesn't. Dunno what my brain saw

I'd be a bit surprised if it did, they have a different interface

ah so the start was <https://github.com/bodgit/puppet-sssd/issues/38>

and because we didn't get a response we've now our own module

I'm inclined to think of it as abandoned, but maybe it is just working perfectly for bodgit.  I'd rather not de-list other folks work without they input.

no worries, I've pinged him and will follow up

yes I would also love some attention on my other tickets, I've a list!

<@U11HA7VJ7> <https://forge.puppet.com/modules?limit=25&amp;sort_by=rank&amp;module_groups=base%20pe_only&amp;q=node_encrypt&amp;show_deprecated=true> can you move the approved badge from your module to the new puppetlabs one?

:goodnews: Next up is _Content and Tooling_ in <https://www.timeanddate.com/worldclock/converter.html?iso=20231003T140000&amp;p1=202&amp;p2=179&amp;p3=919&amp;p4=307&amp;p5=3332&amp;p6=236&amp;p7=240|115 hours>

Hi Daniele, not a silly question. We’re working on a new public-facing ticketing system, unfortunately no ETA as of yet.

In the meantime, could you describe the issue here? I can log it within our internal ticketing system and we can triage the issue.

<@U05M4G4035Y> sure. thanks.
I'm sure you know Raspbian (now Raspberry OS), which is a Debian with some modified packages for Raspberry.
Some tickets were raised previously to declare Raspbian "as Debian" / of the Debian family.
Effectively, modules which rely on [os][name] are effectively compatibile with Raspbian.
But Raspbian itself push messages like:
`Warning: Found multiple default providers for service: init, systemd; using init`
Which is described also here:
<https://dangibbs.uk/blog/running-puppet-7-agent-on-arm/>
I'm unsure if this is really a change in puppet 7 (and therefore facter),
nevertheless Raspbian is not listed as OS itself in facter, nor is recognised as Debian.

See the details:
Debian 12 listed as Raspbian, with facter 4.3
```root@porthos:~# cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 12 (bookworm)"
NAME="Raspbian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=raspbian
ID_LIKE=debian
HOME_URL="<http://www.raspbian.org/>"
SUPPORT_URL="<http://www.raspbian.org/RaspbianForums>"
BUG_REPORT_URL="<http://www.raspbian.org/RaspbianBugs>"
root@porthos:~# facter operatingsystem
Raspbian
root@porthos:~# dpkg -l facter
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-==========================================
ii  facter         4.3.0-2      all          collect and display facts about the system
root@porthos:~#```
Debian 11 listed as Debian, facter 3.14
```root@sulu:~# cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
HOME_URL="<http://www.raspbian.org/>"
SUPPORT_URL="<http://www.raspbian.org/RaspbianForums>"
BUG_REPORT_URL="<http://www.raspbian.org/RaspbianBugs>"
root@sulu:~# facter operatingsystem
Debian
root@sulu:~# dpkg -l facter
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-==========================================
ii  facter         3.14.12-1+b2 armhf        collect and display facts about the system
root@sulu:~#```

Sorry, just to clarify: is the desired behavior here that running `facter operatingsystem` with Facter 4 return `Debian`, as it did with Facter 3?

yes :slightly_smiling_face:
(same with [os][name] of course)

The behavior in Facter 4 seems more correct to me, as we want the ability to distinguish between different distros. If someone wants to enable compatibility with Debian variants, they should be able to use the [os][family]/osfamily fact to do that.

Is there a certain module that seems to be failing because of this behavior? Where are you seeing this difference in behavior cause an issue?

in first instance:
`Warning: Found multiple default providers for service: init, systemd; using init`

i can lookup also for other modules, but that's happening when `Service` is called

Ah I see, yeah you mentioned that in your original comment. Hmm, I’ll look into this some more.  I think that, at least for `Service`, we would just need to set systemd as the default provider for  `'os.family' =&gt; :Debian`
<https://github.com/puppetlabs/puppet/blob/main/lib/puppet/provider/service/systemd.rb>

Is Puppet still able to manage that service even with the warning? It seems like it should still work.

• In my custom manifest it fails (running with --noop, but whatever). I have eventually to investigate it.
• as a reminder, `Devuan` (`Debian` family) does not make use of `systemd`. Ok to set it for the family if Devuan can override it.

i was finding also this interesting information,
```You shouldn't do this [call Raspbian and Raspberry Pi OS NDR] as they're not equivalent. Raspbian is only armhf. There is no 64-bit Raspbian. It is the main reason why the official images were renamed Raspberry Pi OS when the 64-bit images were introduced.```
<https://forums.raspberrypi.com/viewtopic.php?t=333285>
• armhf (32 bit) contains Raspbian in the os-release file
• arm64 (well... :D) contains Debian in os-release file
Personally, as Raspbian is effectively Debian with very minor changes related to the peculiarity of the hardware, i would still argue that Raspbian is not a different OS, and possibly qualify to be "name Debian, not only family Debian".
Still i see your point.
I would just say to keep an open mind while investigating it :slightly_smiling_face:
*Probably* the effort change in adding Raspbian is not worthing the benefit of it.

Thanks for that info. I’ll definitely open a ticket and can at least update the defaults for Service, it should be pretty negligible.

Also we are working on official ARM packages for Debian 11 and 12 in the next few quarters, so hopefully that will be helpful for Raspbian folks too

that's a good news too, will both armhf *and* arm64 will be released?

everything in the code of pwshlib let me assume it shouldn't do that :exploding_head: )

:indeed: The next Office Hour is _Content and Tooling_ in <https://www.timeanddate.com/worldclock/converter.html?iso=20231003T140000&amp;p1=202&amp;p2=179&amp;p3=919&amp;p4=307&amp;p5=3332&amp;p6=236&amp;p7=240|18 hours> in <#CFD8Z9A4T|>

:the_more_you_know: _Content and Tooling_ is about to start up in 15 minutes

hey everyone! The DevX team's (formerly the tools team) office hours starts now. Ask us any questions you have about our tools

we manage <https://github.com/puppetlabs/ruby-pwsh/tree/main|ruby-pwsh>

ok :+1: I'm really puzzled about the behaviour I should expect from Enum[] properties.
From what I can see in my env
```1. dsc_ensure =&gt; 'present' will constantly try to update to 'Present' (each run)
2. dsc_ensure =&gt; 'present' and validation_mode =&gt; 'resource' will work (but extremely slow)
3. dsc_ensure =&gt; 'Present' will work```
The first thing I wonder is if this is the "right behavior" or if it is due to my environment somehow.
The second thing is what would be the recommendation ?
Using validation_mode is really slowing the execution A LOT :sweat:
Having special casing where my end_users manage mostly linux environment would be very confusing :confused:

(I give an example with `Enum['Present', 'present', 'Absent', 'absent']` but I faced the issue with every Enum params on different resources)

The problem seems to be `Enum` is case sensitive:

<https://www.puppet.com/docs/puppet/8/lang_data_abstract#lang_data_abstract_flexible-enum-data-type>

But PowerShell generally is not. It will accept any amount of mixed-case.

Indeed it is. But I thought the canonicalize() function from dsc_base_provider would handle this

<https://github.com/puppetlabs/ruby-pwsh/blob/main/lib/puppet/provider/dsc_base_provider/dsc_base_provider.rb>

I am not sure to fully understand the code and can't really try it separately, I lack a lot of understanding on this.
To my understanding, canonicalize() function would put everything downcase for the comparison. But well, obviously I'm wrong given the issue I face :sweat:

would you be able to use a ruby method like <https://ruby-doc.org/3.2.2/String.html#method-i-downcase|downcase>?

How should I use it ? (I probably could somewhere)

let me better understand what you're doing with the `Enum`. How are you using it with `dsc_ensure` ?

Each resource from dsc modules has puppet type in `/lib/puppet/type/xxxxx.rb`
These type defines the parameters that comes from dsc resources
Here is an example
```dsc_overridemode: {
      type: "Enum['Allow', 'allow', 'Deny', 'deny']",
      desc: 'Determines whether to lock or unlock the specified section.',

      mandatory_for_get: true,
      mandatory_for_set: true,
      mof_type: 'String',
      mof_is_embedded: false,
    },```
The type of the param is defined as an Enum[] that accepts both PascalCased and downcase values.

This is the Enum I end up testing my resource against.
Though the type allow downcased value, the puppet comparison will somehow retry indefinetely to apply PascalCase

hey <@U024RRWLN8K> - i'm abit late to this party! But i think you may have found something here, like you say there is a method in the `dsc_baseprovider` that should convert the passed in `dsc_ensure` metaparameter to downcase (just from a quick glance), <https://github.com/puppetlabs/ruby-pwsh/blob/6c2a2861042edfd7b88323c93ae5c2f7b8dafd72/lib/puppet/provider/dsc_base_provider/dsc_base_provider.rb#L560|here>. So really `Present` or `present` or `PRESENT` should all be equal when returned from the base provider.
I'm going to spin up a windows env here and see if i can replicate it. If its the case, we can get this ticketed and added to our backlog

(I can't provide a link because dsc resources are dynamically generated and not hosted on git)

I think there is several steps in the value testing
```0. Say I have Enum['Present', 'present']
1a. Value = 'PRESENT' would throw  "expects a match for Enum['Present', 'present'], got 'PRESENT'" ==&gt; The casing does not exists in the Enum, so it throws
1b. Value = 'present'. Will not throw, value is accepted in the enum
2. Puppet tries to apply the value. It reads "Present". It applies 'present'. Somehow either 'Present' is written, or when puppet reads 'present' it converts it to 'Present'. ==&gt; This lead to a constant change```
The step 2. leads me to this PR : <https://github.com/puppetlabs/ruby-pwsh/pull/131/commits/0dd07145566f0c221c5cc462944e42d7ed5e51df>
Not sure if I'm right, but it may be a side effect of this PR.

could you share which dsc module you're running* (If its a forge one)

FYI, I opened this issue : <https://github.com/puppetlabs/ruby-pwsh/issues/254> (Though since then I have a better understanding on what is happing I guess)

any dsc module that have no x in it. I guess the simplest one would be psdscresources : <https://forge.puppet.com/modules/dsc/psdscresources/readme>

```dsc_windowsfeature { 'Web-Server':
    dsc_ensure =&gt; 'present',
    dsc_name   =&gt; 'Web-Server',
  }```
You would have this for instance

Interesting...
Both `Present` and `present` work for me.
```dsc_windowsfeature { 'Web-Server':
    dsc_ensure => 'present',
    dsc_name   => 'Web-Server',
  }
Notice: /Stage[main]/Main/Dsc_windowsfeature[Web-Server]/dsc_ensure: current_value 'Absent', should be 'present' (noop)


dsc_windowsfeature { 'Web-Server':
    dsc_ensure => 'Present',
    dsc_name   => 'Web-Server',
  }
Notice: /Stage[main]/Main/Dsc_windowsfeature[Web-Server]/dsc_ensure: current_value 'Absent', should be 'Present' (noop)```


They should both work. But if you run several time, 'present' should try to reapply

```dsc_windowsfeature { 'Web-Server':
    dsc_ensure =&gt; 'present',
    dsc_name   =&gt; 'Web-Server',
    validation_mode =&gt; 'resource',
  }```
This should prevent the reapply. But if you look at last_run_summary.yaml, you will see a drastic change in duration. And it stacks if you add more resources with validation_mode 'resources'

(For 30ish windows_feature that are already present, I go from 5 milliseconds to 27 seconds :exploding_head: with validation_mode)

Did you reproduce the problem with 'present' ?

so I ran this manifest the first time, took 60 seconds to compile and apply.
```dsc_windowsfeature { 'Web-Server':
    dsc_ensure =&gt; 'present',
    dsc_name   =&gt; 'Web-Server',
  }```
Re-ran it a few times and get this every time:
```Notice: Applied catalog in 1.42 seconds```
Also then ran
```dsc_windowsfeature { 'Web-Server':
    dsc_ensure =&gt; 'Present',
    dsc_name   =&gt; 'Web-Server',
  }```
which seems to apply much faster:
```Notice: Applied catalog in 0.04 seconds```

You're using pwshlib on the backend, not puppetlabs-dsc ?

See the `puppetlabs-dsc` module at <https://forge.puppet.com/puppetlabs/dsc?src=slack&amp;channel=office-hours>

Thats right, they all pull in pwshlib as a dependency :slightly_smiling_face:

I use it to day, but I'm trying to transition to the new supported version

```├── dsc-psdscresources (v2.12.0-0-6)
├── dsc-xwebadministration (v3.3.0-0-0)
├── puppetlabs-pwshlib (v1.0.0)```

See the `dsc-psdscresources` module at <https://forge.puppet.com/dsc/psdscresources?src=slack&amp;channel=office-hours>

so yeah PRESENT does throw.
```Error: Parameter dsc_ensure failed on Dsc_windowsfeature[Web-Server]: dsc_windowsfeature.dsc_ensure expects an undef value or a match for Enum['Absent', 'Pres
ent', 'absent', 'present'], got 'PRESENT'```
Think I was incorrect to say they should all work, as puppet still expects the metaparameter to match the specified Enums, which in this case is `Enum['Absent', 'Present', 'absent', 'present']`

could you try to enforce valide_mode =&gt; property ?

```dsc_windowsfeature { 'Web-Server':
    dsc_ensure =&gt; 'present',
    dsc_name   =&gt; 'Web-Server',
    valide_mode =&gt; 'property',
  }```


Your output with 'present' downcased is the same as mine when I used valide_mode =&gt; 'resource'

Same behaviour i'm afraid..
```Debug: dsc_windowsfeature: raw data received: {"rebootrequired"=&gt;false, "indesiredstate"=&gt;true, "errormessage"=&gt;""}
Debug: Finishing transaction 12520
Debug: Storing state
Debug: Pruned old state cache entries in 0.00 seconds
Debug: Stored state in 0.01 seconds
Notice: Applied catalog in 1.15 seconds```

ok so this gives me a few answers
```1. The problem with downcased 'present' being constantly applied is linked somehow to my environment. I will need to dig through this again :/
2. The gain of time from not using 'validation_mode =&gt; resource' is not really significant if I keep using downcased 'present'```


Its worth checking that you have the latest version of the dsc modules and pwhslib module installed :slightly_smiling_face:

Apologies couldnt have been of more help, environment specific problems are a pain so I sympathise with you there

Looking at metadata.json I have this
```  "name": "puppetlabs-pwshlib",
  "version": "1.0.0",```
```    "name":  "dsc-psdscresources",
    "version":  "2.12.0-0-6",```
Seems up to date to me

See the `puppetlabs-pwshlib` module at <https://forge.puppet.com/puppetlabs/pwshlib?src=slack&amp;channel=office-hours>

Yep, those were the versions I was using. So now its double weird

```puppet (7.23.0)
puppet-resource_api (1.8.16)
ruby-pwsh (1.0.0)```
have these gems also

thats quite an outdated version of the resource-api, looks like it may have even be yanked from ruby-gems

No problem! Hope you get to the bottom of it.

<@U024RRWLN8K> bit of an update.. I was actually able to reproduce the issue following your issue on GitHub. Just letting you know we've added it to the backlog and should be working to resolve it soon!

Hi <@U04K66LJZL5>, thanks. Just to be sure you reproduced the former issue I get on the issue ?
```# Basically this
'present' not in Enum['Present','Absent']```
If this is the problem you reproduced, the 'easy' answer is to use dsc module without the x (for instance `dsc_webadministrationdsc` instead of `dsc_xwebadministration`
I figured the Enum[] included both PascalCased and lowercase values in the recent versions without the x

Ah! there we go. its been deprecated in favour of and no longer maintained.
`**The module _xWebAdministration_ will be renamed to WebAdministrationDsc`

Let me work with the forge team to update the badges on these modules to show xWebAdministration as deprecated and the newer WebAdministrationDsc as approved.

I guess this applies to all dsc_x resources
`dsc_x[whatever]` to `dsc_[whatever]dsc` Most often this patten

Could well be the case. I'll create an action item to check this. Great spot, thanks for the pointer <@U024RRWLN8K>!

If you're happy, I can go ahead and close the issue on the repo

Yes given my issue was about first wrongly using dsc_x deprecated modules and then I continued on the issue we discussed yesterday. Both of these are somewhat on my side :slightly_smiling_face: So you can close :+1: Thanks again

Hey there I dug a little further into the ruby code and commented here : <https://github.com/puppetlabs/ruby-pwsh/pull/131#issuecomment-1852779233>
(Sorry if I don't answer immediatly, it's quite late in France, I shall see any answer tomorrow)

I opened 2 issues. One related to the subject we discussed here : <https://github.com/puppetlabs/ruby-pwsh/issues/265>
The other, I found while doing some testing about the subject.
<https://github.com/puppetlabs/ruby-pwsh/issues/264>

:indeed: Next up is _:teacher:PE Console_ in <https://www.timeanddate.com/worldclock/converter.html?iso=20231005T210000&amp;p1=202&amp;p2=179&amp;p3=919&amp;p4=307&amp;p5=3332&amp;p6=236&amp;p7=240|54 hours>

:kermit_typing: _:teacher:PE Console_ is about to start up in 15 minutes

\o Good day y’all - console office hour has begun!

If you have any questions/suggestions for anything related to the console, any of the console services (RBAC, Classifier, Activity Service) or the Orchestrator, ask away.

any plans to publish a roadmap? maybe only for partners?

\o I’ve passed that request along - not heard anything concrete yet

I do know that more forward looking OS platform support info is in the works

is there anything planned in the orchestrator/console for the upcoming PE release(s) you can talk about?

you saw the new, step-based puppet job interface?