So

in

wouldn't consider those as the same.

"micosoft-edge" in ["Opera Stable 93.0.4585.37", "Microsoft Edge"]

will never be true.

@Doug are you sure you don't need to do something like this? https://github.com/puppet-bootstrap/basic-aio/blob/production/site/profile/manifests/puppetdb.pp#L9-L18

This message was deleted.

Hi All, I need some help writing my first custom fact. I've tried reading the puppet manual, but I can't make head or tails of where it's supposed to go, let alone how to properly write it. The custom fact I need is for the puppet mysql module, it would be set for

mysqld_version,

which in my case is mysql-8.0.31. Here's a relevant quote from the modules documentation: "If you're working with a remote MySQL server, you may need to set a custom fact for

mysqld_version

to ensure correct behavior."

Hi All, I need some help writing my first custom fact. I've tried reading the puppet manual, but I can't make head or tails of where it's supposed to go, let alone how to properly write it. The custom fact I need is for the puppet mysql module, it would be set for

mysqld_version,

which in my case is mysql-8.0.31. Thank you , your help will be appreciated! Here's a relevant quote from the modules documentation: "If you're working with a remote MySQL server, you may need to set a custom fact for

mysqld_version

to ensure correct behavior."

Ever seen these errors with this module?

Lol, didnt realize

Here is that pic again.

This message was deleted.

See the

puppet-puppetserver

module at https://forge.puppet.com/puppet/puppetserver?src=slack&channel=puppet

This message was deleted.

we’re using (a somewhat improved internal fork of) jorritfolmer/splunk and I’ve been wanting to upgrade to puppet/splunk 😅

we’re using (a slightly improved internal fork of) jorritfolmer/splunk and I’ve been wanting to upgrade to puppet/splunk 😅

@kenyon yep, you're right. Thx!

@kenyon yep, you're right. Thx!

I saw lsb* facts missing on first puppet run while ago.. maybe you hit the same

It can be dangerous to use the global variable rather than the facts array, had a clash with a module once which overrode the global variable

This message was deleted.

Hey, just laying this out for everyone so there are no surprises.
As part of a larger discussion, we have decided that the Firewall module is in need of a major restructuring, with more and more issues arising from it and compile times that seem to regularly take upwards of thirty minutes.
In order to try and solve this issue the team is working to put together a plan on how the module should best be restructured to not only resolve the issues currently facing it but to help ensure that similar ones do not occur.
As part of this however we would like to hear the communities feedback and what ideas that they might have on the best way to accomplish this, so that we can reach our goal and provide the best quality module that we can.
As a start there are several questions that must be answered and choices to be made, these including:

* Should we keep to the current provider style module or convert it to run with templates?
Converting the module may take more time to accomplish but could help keep the modules run time down and make the module more easily modified and maintained.

* Should we refactor the current module or create a fresh one and leave the current one as is?
Depending on the size of the refactor it may be easier to simply start fresh, especially if we convert to a template style, as we can leave the old module as is for people to use until we get the new one fully fleshed out.
As a side note however, this could also be accomplished simply by cutting a major release and informing the community beforehand.

* In the event that we create a new module, should we split it into two separate ones, one for iptables and one for ip6tables?
Although there is overlap in how they are managed they are in fact separate and outright keeping them as such may be more convenient for people who simply use on or the other.

* Finally, should the module/modules be expanded to include nftables?
Although it has been around for some time now it is only recently that nftables seems to have gained traction, as such it may be best to add support for it to the firewall module/modules to ease people into converting over, as both it and iptables/ip6tables are both maintained by the same organisation, with the prior being actively developed as a successor and poised to take over.

Finally, to anyone worried about the changes coming to the module, know that this is merely an initial investigation and that the actual changes are still some time away. We are well aware of how important this module is and are committed to getting this right.

This message has also been posted in a github issue linked here: https://github.com/puppetlabs/puppetlabs-firewall/issues/1100 and on the puppet-users@ mailing list

Hey, just laying this out for everyone so there are no surprises.
As part of a larger discussion, we have decided that the Firewall module is in need of a major restructuring, with more and more issues arising from it and compile times that seem to regularly take upwards of thirty minutes.
In order to try and solve this issue the team is working to put together a plan on how the module should best be restructured to not only resolve the issues currently facing it but to help ensure that similar ones do not occur.
As part of this however we would like to hear the communities feedback and what ideas that they might have on the best way to accomplish this, so that we can reach our goal and provide the best quality module that we can.
As a start there are several questions that must be answered and choices to be made, these including:

* Should we keep to the current provider style module or convert it to run with templates?
Converting the module may take more time to accomplish but could help keep the modules run time down and make the module more easily modified and maintained.

* Should we refactor the current module or create a fresh one and leave the current one as is?
Depending on the size of the refactor it may be easier to simply start fresh, especially if we convert to a template style, as we can leave the old module as is for people to use until we get the new one fully fleshed out.
As a side note however, this could also be accomplished simply by cutting a major release and informing the community beforehand.

* In the event that we create a new module, should we split it into two separate ones, one for iptables and one for ip6tables?
Although there is overlap in how they are managed they are in fact separate and outright keeping them as such may be more convenient for people who simply use on or the other.

* Finally, should the module/modules be expanded to include nftables?
Although it has been around for some time now it is only recently that nftables seems to have gained traction, as such it may be best to add support for it to the firewall module/modules to ease people into converting over, as both it and iptables/ip6tables are both maintained by the same organisation, with the prior being actively developed as a successor and poised to take over.

Finally, to anyone worried about the changes coming to the module, know that this is merely an initial investigation and that the actual changes are still some time away. We are well aware of how important this module is and are committed to getting this right.

This message has also been posted in a github issue linked here: https://github.com/puppetlabs/puppetlabs-firewall/issues/1100 and on the puppet-users@ mailing list

@David 'The Anvil' thanks for bringing this up. Where do you prefer the feedback? GitHub?

I think that would be the best as it would make it easier to keep track

maybe Github discussions is a bit better place but nvm 🙂

message has been deleted

This message was deleted.

This message was deleted.

This message was deleted.

This message was deleted.

message has been deleted