Re: [Puppet Users] saz-ssh, hiera and options

[A Manzer]

You can easily do that with an Operating System-specific layer to your 
hiera.  Add something like `os/$facts['osfamily'].yaml` to your hiera.yaml. 
Then, you can have a FreeBSD.yaml, and a Debian.yaml in your hiera data. 
(Ubuntu is part of the Debian OS Family.)

Put the proper parameter block in each yaml file and the module will 
automatically pull them in on the right hosts.

(Make sure you double check my hiera string there. I'm on mobile and don't 
have access to my Puppet environment at the moment.)

On Sunday, May 7, 2023 at 7:33:38 PM UTC-4 lac...@gmail.com wrote:

> This works if I configure it for each individual server. Thank you!
>
> I was wondering if there is a way to have a different path for 
> *AuthorizedKeysCommand 
> *based on the operating system rather than every single server?
>
> I think an alternative could be in the manifest file something like:
>
>  case $::operatingsystem {
>   'freebsd': {
>  *somehow define AuthorizedKeysCommand: 
> ‘/path/to/freebsd-command’*
>  }
>  'ubuntu': {
>   *somehow define AuthorizedKeysCommand: 
> ‘/path/to/ubuntu-command’*
> }
>
> On Tuesday, May 2, 2023 at 2:04:16 PM UTC-4 Martin Alfke wrote:
>
>> The main ssh class has the parameter server_options:
>> # @param options
>> # Dynamic hash for openssh server option
>>
>> ssh::server_options:
>>   AuthorizedKeysCommand: ‘/path/to/command’
>>
>> If you are using ssh::server class, the parameter ssh::server::options 
>> must be used.
>>
>>
>> On 2. May 2023, at 17:29, Laci D  wrote:
>>
>> Thank you Martin, adding the following example to my 
>> *nodes/myserversfqdn.yaml* did it for me.
>>
>> ssh::server::match_block:
>>   '*,!that_other_group':
>> type: group
>> options:
>>   ForceCommand: '/usr/bin/kpasswd'
>>
>> I have another question, how can I specify different values in Hiera for 
>> different operating systems?
>>
>> For example *AuthorizedKeysCommand* needs a different value in Linux and 
>> FreeBSD?
>>   
>> On Tuesday, May 2, 2023 at 3:51:20 AM UTC-4 Martin Alfke wrote:
>>
>>> Hi,
>>>
>>> Ssh::server class has a parameter called “match_block” which calls a 
>>> defined type:
>>>
>>> https://github.com/saz/puppet-ssh/blob/master/manifests/server/match_block.pp
>>>
>>> The defined type uses a template:
>>>
>>> https://github.com/saz/puppet-ssh/blob/master/templates/sshd_match_block.erb
>>>
>>> A hiera example is in the docs:
>>> https://forge.puppet.com/modules/saz/ssh/readme#hiera-example
>>>
>>> Hth,
>>> Martin
>>>
>>>
>>> On 1. May 2023, at 23:08, Laci D  wrote:
>>>
>>> Hi,
>>>
>>> I'm using *saz-ssh* to configure sshd_config, options are stored in 
>>> Hiera. I didn't find the way how to implement "Match user/group", for 
>>> example:
>>>
>>> Match group *, !not_that_group
>>> 'ForceCommand' => 'internal-sftp',
>>>
>>> I did see the example  but 
>>> when I add that to my manifests/profiles/ssh.pp then Puppet is 
>>> complaining and I'm not seeing how to configure it using Hiera.
>>>
>>> Any ideas?
>>>  
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Puppet Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to puppet-users...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/puppet-users/0f953ebb-ee44-481b-81da-639ade904c8bn%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>>
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to puppet-users...@googlegroups.com.
>>
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/7ea988f3-c68d-45f7-a7f8-cf37929a09fcn%40googlegroups.com
>>  
>> 
>> .
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/cef01e39-ee6e-4dcf-8a5c-0175c2b1a104n%40googlegroups.com.

[Puppet Users] Re: Problems with Forge Module puppet-firewall on RHEL 8.5

[A Manzer]

I posted on the GitHub issue, but I'll TL;DR it here for future searchers:

I recommended setting the `module` parameter to `netbios-ns` which is in 
line with how RedHat recommended fixing the underlying firewall issue.  
It's probably just a case of differences between RHEL 7 and RHEL 8, and the 
documentation not perfectly reflecting that.

On Monday, March 14, 2022 at 2:20:56 PM UTC-4 nasa_dan wrote:

> I used this is a RHEL 7 PuppetServer without problem:
>
> firewalld::custom_services:
>   'pe-puppetserver':
> short: 'Puppet Enterprise Server'
> description: 'Puppet is a network tool for managing many disparate 
> systems. Puppet Master is a server which Puppet Agents pull their 
> configurations from.'
> port:
>   - port: 4433
> protocol: 'tcp'
>   - port: 5432
> protocol: 'tcp'
>   - port: 8081
> protocol: 'tcp'
>   - port: 8170
> protocol: 'tcp'
> module:
>   - 'nf_conntrack_netbios_ns'
>
> but on RHEL 8.5, it does this:
>
> [1] 2022-03-11 18:00:30 DEBUG1: Traceback (most recent call last):
>
>   File "/usr/lib/python3.6/site-packages/firewall/core/fwpolicy.py", 
> line 717, in get_helpers_for_service_modules
>
> helper = self.fw.helper.gethelper(module)
>
>   File "/usr/lib/python3.6/site-packages/firewall/core/fwhelper.py", 
> line 56, in get_helper
>
> self.checkhelper(name)
>
>   File "/usr/lib/python3.6/site-packages/firewall/core/fwhelper.py", 
> line 44, in check_helper
>
> raise FirewallError(errors.INVALIDHELPER, name)
>
> firewall.errors.FirewallError: INVALID_HELPER: netbios_ns
>
>  
>
> I filed an issue 
>  on GitHub.
>
> Removing the module parameter fixed the problem, however, I realized that 
> I just copied from the modules code samples.
>
> What does this parameter do ?
>
> If I need it, how do I use it in RHEL 8 ?
>
>
> *__*
>
>  
>
> *Daniel E. White*
> *daniel@nasa.gov*
>
>
>
>
> *NASCOM Linux Engineer NASA Goddard Space Flight Center Science 
> Applications International Corporation (SAIC) Office: (301) 286-6919 
> <(301)%20286-6919>*
>
> *Mobile: (240) 513-5290 <(240)%20513-5290>*
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/3aee7b0c-040b-400b-b0be-319d99139b39n%40googlegroups.com.

[Puppet Users] Re: Puppet Enterprise 2021.5 is now available!

[A Manzer]

Thanks for the new platform support.

Any idea on when we'll see Ubuntu 20.04 as a supported platform for the 
main PE server?

On Tuesday, February 15, 2022 at 6:58:50 PM UTC-5 Puppet Product Updates 
wrote:

> The latest release for the Puppet Enterprise release track, PE 2021.5, is 
> now available!
>
>  
>
> Enhancements in this release include:
>
>
>- 
>
>Bypass node verification failure when primary server certificates are 
>damaged. You can use --force to bypass node verification failure and 
>force certificate regeneration when your primary server certificates are 
>damaged.
>- 
>
>Improved disk usage when syncing certificate authority data. Disk 
>usage is better when syncing certificate authority data between the 
> primary 
>and replica.
>- 
>
>Primary server support for: 
>- 
>   
>   Amazon Linux 2
>   - 
>
>Agent support for: 
>- 
>   
>   Microsoft Windows Server 2022 x86_64
>   - 
>   
>   Red Hat Enterprise Linux 9 x86_64
>   - 
>
>Patch management:
>- 
>   
>   Amazon Linux 2
>   
>  
>
> Resolved in this release:
>
>- 
>
>Packages were not marked as automatically installed by APT if you set 
>security_only to true. When running the pe_patch::patch_server task 
>with the security_only parameter set to true, packages were not marked as 
>being automatically installed by APT. This caused problems if you rely on 
>this marking for APT autoremove to remove old packages. The patch_server 
>task now marks packages as automatically installed, regardless of the 
>security_only parameter.
>- 
>
>r10k can recover from typos in the config or Puppetfile. r10k now 
>updates its cache repos when the remote URL changes. This allows r10k to 
>recover from typos in the config or Puppetfile.
>- 
>
>Couldn't complete restoration if the r10k_remote parameter wasn't set. The 
>r10k_remote parameter wasn't set when restoring a backup with scope set to 
>certs, code, or puppetdb. This prevented you from finishing restoration 
>because the commands necessary to finish restoring your primary server did 
>not print.
>- 
>
>Schedule task button sometimes failed to redirect. When scheduling a 
>task to run at some later time or interval, under some circumstances, 
>clicking Schedule task did not redirect you to the Scheduled tasks page.
>- 
>
>The fail_plan function didn't show custom error information. The 
>fail_plan function ignored the kind and details parameters, which are used 
>to specify custom, machine-parseable information about an error.
>- 
>
>Scheduled jobs failed on FIPS installs. Scheduled jobs, including 
>tasks and plans, couldn't run or be listed on FIPS installs of PE and 
>resulted in the error javax.crypto.BadPaddingException.
>
>  
>
>  
>
> Check out the release notes: 
> https://puppet.com/docs/pe/2021.5/release_notes_pe_index.html
>
>  
>
> Important note: If you are using Continuous Delivery for PE, upgrade to 
> CD4PE 4.8.2 or a newer version prior to upgrading to Puppet Enterprise 
> 2021.5. We resolved a PuppetDB issue causing the generation of new fact 
> charts on the Nodes page to fail.
>
>  
>
> *Download PE 2021.5 here*: 
> https://puppet.com/try-puppet/puppet-enterprise/download/
>
>  
> As a current Puppet Enterprise user, you can update to this new version as 
> part of your annual subscription. When updating, you must update 
> infrastructure components first and then update agents. For detailed 
> instructions, see the documentation 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/454e6e7f-ce45-4e13-af70-d7515d8a5a9en%40googlegroups.com.

[Puppet Users] Re: Nonconformist Ubuntu based distro users

[A Manzer]

I'm currently using Puppet Enterprise (under 10 nodes) on my personal 
network.  I've run into some of the same issues that you have.

I run Kubuntu on my desktop, which works perfectly as an Ubuntu 
derivative.  I've used KDE Neon (another Ubuntu derivative) briefly in the 
past too, and from what I recall, it was fine.  

Pop!_OS was *not* fine, as even though most Puppet modules would have 
worked just fine, it identifies as Pop instead of Ubuntu, so most modules 
just bail.  I abandoned Pop!_OS partially because of that (along with other 
reasons).

I've also tried to use Puppet on Raspbian, using the Ruby agent, and it's 
got similar problems to what you describe.  The Facts OS hash just doesn't 
quite match what stock Debian does, so a few modules I've tried to use 
don't work right.

How do I fix all this?  Change my OS usually.  On my desktop, I stick to 
OSs that PE supports.  And I'm thinking of changing my RPIs to Ubuntu, 
rather than Raspbian.  And I run a couple VMs using CentOS.

I've also forked a module before and patched it for Raspbian compatibility 
for myself.  Another time, I just had to install the `lsb-release` package 
to get the OS facts hash to a place where the module could use it.

All in all, since this is my personal network, I'm pretty flexible with 
what I can do; changing an OS isn't a big deal.  I generally don't have 
hard requirements that I have to meet.

*At work*, where I also use PE, we stick to Ubuntu-proper, and CentOS, 
mostly as headless VMs (not desktops).  But that's for wider compatibility 
reasons that just PE.

On Thursday, March 4, 2021 at 2:22:40 PM UTC-5 Corey Osman wrote:

>
>
> Hi,
>
> Curious how many of you are using a Ubuntu derivative for specialized use 
> cases. There are many reasons to do so with use cases ranging from 
> cryptocurrency mining hardware to a government hardened distro.  Also 
> popular distros like Xubuntu, PopOS and LinuxMint have opinionated software 
> configurations that some of us prefer and fall into this unsupported grey 
> area as well.
>
> The problem with using a niche or custom distro is that puppet and other 
> tools do not officially support the distro.  However these tools are 
> completely capable of running on the distro with little issue. 
>
> One issue I found with facter regarding lsb-release file.  
> https://tickets.puppetlabs.com/browse/FACT-2953
>
> So my questions are:
>
> Are you using puppet on your special distro?
> Do you pay for open source puppet support or have PE ?
> What distro are you using?
> What use case do you have?
> What issues have you had with puppet and your special distro?
>
>
> Corey
>
> NWOPS, LLC
> @nwops on Puppet Slack
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/c0e81b4b-5007-469d-bcc8-ea89bb863b72n%40googlegroups.com.

Re: [Puppet Users] refactor use of ensure_packages to install new versions of php packages

[A Manzer]

Glad you managed to figure it out, and thanks for posting your solution for 
posterity!

On Tuesday, October 13, 2020 at 12:26:35 PM UTC-4 jochen@gmail.com 
wrote:

> Hi all,
>
> I solved this with the use of puppet iteration functions:
>
> class profile::software::apache (
>   $php_version= '7.4',
>   $php_remove = ['7.0‘, ‘7.3'],
>   #...
> ) {
>   # build a hash of PHP Versions with a value of either present or absent
>   # and iterate over it with each
>   $phpInstallHash = { $php_version => 'present' }
>   #notify { "Value of phpRemove: ${php_remove}": }
>   if $php_remove {
> # We have the array, use the map function to build remove hash
> $phpRemoveHash = $php_remove.map |$version| {
>   { $version => 'absent' }
> }
> $phpFullHash = $phpInstallHash + $phpRemoveHash
>   } else {
> $phpFullHash = $phpInstallHash
>   }
>   #notify { "phpHash to iterate over to install/uninstall: ${phpFullHash}": }
>
>   #iterate over the result installing/uninstalling
>   $phpFullHash.each | $php_version, $ensure_value | {
> ensure_packages([
>   "php$php_version-xml",
>   "php$php_version-zip",
>   "php$php_version-curl",
>   "php$php_version-mbstring",
>   "libapache2-mod-php$php_version",
> ],
>   {
> 'ensure' => $ensure_value,
> require  => [Class['apt::update'],
>   Apt::Source['source_php_sury'],
> ],
> notify   => Class['apache::service'],
>   }
> )
>
>   }
> }
>
>
> It works for me. I answered my StackOverflow question as well. Any 
> thoughts?
>
> As Garret pointed out, this for sure is not a recommended or usual way to 
> do things. The need for this stems from my use of the Sury PHP repository, 
> which offers several versions of PHP. I chose to use with 7.3 or 7.4 and 
> get all important and security related from that tree, so it’s not like 
> pinning a package to a fixed version.
>
> regards,
> Jochen
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/8824a2b2-fa3e-4a16-a99b-ad9026477204n%40googlegroups.com.

Re: [Puppet Users] refactor use of ensure_packages to install new versions of php packages

[A Manzer]

I don't know if it'll work, but you *might* be able to do something like 
this:

$php_package_1 = 'php${php_version}-xml'  #single quoted to prevent 
interpolation

$install_versions.each | String $php_version | {
$php_install_1 = "${php_package_1}"  #double quoted to now interpolate
ensure_packages($php_install_1, {ensure => present})
}

But this is a mess of reusing variables names.

Oh, you could also store the list of packages to be installed in Hiera, so 
that you have one list, but you can reference it in two different places 
(outside, and inside the loop).
On Monday, October 12, 2020 at 8:03:18 AM UTC-4 jochen@gmail.com wrote:

> I think you will get sort of „cannot redeclare“… otherwise I agree, it 
> would work like you suggest.
>
> But with the solution you propose, I guess I will have one structure for 
> the packages to be installed and another for the ones to be removed.
>
> But I want to manage only one list of packages… more save against errors 
> managing the list… I have those packages all over the place...
>
> I will have to think along the lines of single and double quoting… thx
>
> Am 12.10.2020 um 13:56 schrieb A Manzer :
>
> If you redeclare the list *outside* the .each block, you'll end up with 
> the same list.  Also if you redeclare it outside, against the $php_remove 
> array, you'll get something weird.
>
> If you redeclare it *inside* the .each block, it'll be local to that 
> block, get destroyed on the second run, and you'll end up with a fresh copy 
> for the next value of your $php_remove array.
>
> You need to make sure you don't reuse variable names so you don't get 
> confused, but it'll work.
>
>
> If you want to use the same package list in both places, you may be able 
> to play some games with single- and double-quoting, but I don't think I'd 
> recommend that.
>
> On Monday, October 12, 2020 at 7:51:12 AM UTC-4 jochen@gmail.com 
> wrote:
>
>> thx for the smart ;-)
>>
>> but when I redeclare the list, I end up keeping two lists of packages. 
>> The guy who I am, I will definitely fuck this up regularly… and that’s back 
>> to the root of my problem… I would like to somehow reuse the $myPackages 
>> structure with different values for $php_version. 
>>
>> Mhmm… as I write this this sounds like a use for a template…
>>
>> Regards
>> Jochen
>>
>> Am 12.10.2020 um 13:46 schrieb A Manzer :
>>
>> Seems pretty smart to me, tbh.
>>
>> The only problem is that $myPackages is constant, so already includes the 
>> "7.4" values from $php_version.  You'll need to declare a new list (because 
>> you can't change variables) inside your .each block.
>>
>> $php_remove.each | String $php_str_remove | { 
>>  $myRemovePackages = [
>>  "php${php_str_remove}-xml",
>>  "php${php_str_remove}-zip",
>>  "php${php_str_remove}-curl",
>>  "php${php_str_remove}-mbstring",
>>  "libapache2-mod-php${php_str_remove}",
>> ] 
>>  ensure_packages($myRemovePackages,
>>  { 
>>   'ensure' => 'absent', 
>>  }  )
>>  }
>>  }
>>
>> On Monday, October 12, 2020 at 5:10:34 AM UTC-4 jochen@gmail.com 
>> wrote:
>>
>>> Hi all,
>>>
>>> I posted a question on Stackoverflow before the weekend, but no 
>>> responses and not many views yet, unfortunately. So please forgive me 
>>> asking this again here. refactor ensure_packages to switch version of 
>>> installed packages https://stackoverflow.com/q/64284862/13088564?sem=2
>>>
>>>
>>> I am successfully installing several PHP modules by version with puppet 
>>> on Debian linux like this:
>>> $php_version = '7.3' 
>>> ensure_packages([ 
>>> "php$php_version-xml", 
>>>  "php$php_version-zip", 
>>>  "php$php_version-curl", 
>>>  "php$php_version-mbstring", 
>>>  "libapache2-mod-php$php_version",
>>>  ], 
>>>  { 'ensure' => 'present', } ) 
>>>
>>> now I want to prepare for an update from PHP 7.3 to 7.4. This basically 
>>> works, but the 7.3 packages stay installed. I would like to adapt the code 
>>> to remove the old packages. I am looking for a way to reuse the list of 
>>> packages of modules for uninstalling.
>>>
>>> I am thinking of a signature like this
>>> class profile::software::apache (
>>>  $php_version = '7.4',
>>>  $php_remo

Re: [Puppet Users] refactor use of ensure_packages to install new versions of php packages

[A Manzer]

If you redeclare the list *outside* the .each block, you'll end up with the 
same list.  Also if you redeclare it outside, against the $php_remove 
array, you'll get something weird.

If you redeclare it *inside* the .each block, it'll be local to that block, 
get destroyed on the second run, and you'll end up with a fresh copy for 
the next value of your $php_remove array.

You need to make sure you don't reuse variable names so you don't get 
confused, but it'll work.


If you want to use the same package list in both places, you may be able to 
play some games with single- and double-quoting, but I don't think I'd 
recommend that.

On Monday, October 12, 2020 at 7:51:12 AM UTC-4 jochen@gmail.com wrote:

> thx for the smart ;-)
>
> but when I redeclare the list, I end up keeping two lists of packages. The 
> guy who I am, I will definitely fuck this up regularly… and that’s back to 
> the root of my problem… I would like to somehow reuse the $myPackages 
> structure with different values for $php_version. 
>
> Mhmm… as I write this this sounds like a use for a template…
>
> Regards
> Jochen
>
> Am 12.10.2020 um 13:46 schrieb A Manzer :
>
> Seems pretty smart to me, tbh.
>
> The only problem is that $myPackages is constant, so already includes the 
> "7.4" values from $php_version.  You'll need to declare a new list (because 
> you can't change variables) inside your .each block.
>
> $php_remove.each | String $php_str_remove | { 
>  $myRemovePackages = [
>  "php${php_str_remove}-xml",
>  "php${php_str_remove}-zip",
>  "php${php_str_remove}-curl",
>  "php${php_str_remove}-mbstring",
>  "libapache2-mod-php${php_str_remove}",
> ] 
>  ensure_packages($myRemovePackages,
>  { 
>   'ensure' => 'absent', 
>  }  )
>  }
>  }
>
> On Monday, October 12, 2020 at 5:10:34 AM UTC-4 jochen@gmail.com 
> wrote:
>
>> Hi all,
>>
>> I posted a question on Stackoverflow before the weekend, but no responses 
>> and not many views yet, unfortunately. So please forgive me asking this 
>> again here. refactor ensure_packages to switch version of installed 
>> packages https://stackoverflow.com/q/64284862/13088564?sem=2
>>
>>
>> I am successfully installing several PHP modules by version with puppet 
>> on Debian linux like this:
>> $php_version = '7.3' 
>> ensure_packages([ 
>> "php$php_version-xml", 
>>  "php$php_version-zip", 
>>  "php$php_version-curl", 
>>  "php$php_version-mbstring", 
>>  "libapache2-mod-php$php_version",
>>  ], 
>>  { 'ensure' => 'present', } ) 
>>
>> now I want to prepare for an update from PHP 7.3 to 7.4. This basically 
>> works, but the 7.3 packages stay installed. I would like to adapt the code 
>> to remove the old packages. I am looking for a way to reuse the list of 
>> packages of modules for uninstalling.
>>
>> I am thinking of a signature like this
>> class profile::software::apache (
>>  $php_version = '7.4',
>>  $php_remove = ['7.0‘, ‘7.3']
>> , #... 
>> ) {
>>
>> $myPackages = [
>>  "php$php_version-xml",
>>  "php$php_version-zip",
>>  "php$php_version-curl",
>>  "php$php_version-mbstring",
>>  "libapache2-mod-php$php_version",
>>  ] 
>>  
>> ensure_packages($myPackages, {
>>  'ensure' => 'present', 
>>  } ) 
>>
>>  $php_remove.each | String $php_version | { 
>>  ensure_packages($myPackages,
>>  { 
>>   'ensure' => 'absent', 
>>  }  )
>>  }
>>  }
>>
>> Is there a way to solve this?
>>
>> thx
>>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/470cea3c-b64f-4666-827f-0bccfb101afcn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/puppet-users/470cea3c-b64f-4666-827f-0bccfb101afcn%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/16877536-fb28-4234-a5c6-712b087dfce3n%40googlegroups.com.

[Puppet Users] Re: refactor use of ensure_packages to install new versions of php packages

[A Manzer]

Seems pretty smart to me, tbh.

The only problem is that $myPackages is constant, so already includes the 
"7.4" values from $php_version.  You'll need to declare a new list (because 
you can't change variables) inside your .each block.

$php_remove.each | String $php_str_remove | { 
 $myRemovePackages = [
 "php${php_str_remove}-xml",
 "php${php_str_remove}-zip",
 "php${php_str_remove}-curl",
 "php${php_str_remove}-mbstring",
 "libapache2-mod-php${php_str_remove}",
] 
 ensure_packages($myRemovePackages,
 { 
  'ensure' => 'absent', 
 }  )
 }
 }

On Monday, October 12, 2020 at 5:10:34 AM UTC-4 jochen@gmail.com wrote:

> Hi all,
>
> I posted a question on Stackoverflow before the weekend, but no responses 
> and not many views yet, unfortunately. So please forgive me asking this 
> again here. refactor ensure_packages to switch version of installed 
> packages https://stackoverflow.com/q/64284862/13088564?sem=2
>
>
> I am successfully installing several PHP modules by version with puppet on 
> Debian linux like this:
> $php_version = '7.3' 
> ensure_packages([ 
> "php$php_version-xml", 
>  "php$php_version-zip", 
>  "php$php_version-curl", 
>  "php$php_version-mbstring", 
>  "libapache2-mod-php$php_version",
>  ], 
>  { 'ensure' => 'present', } ) 
>
> now I want to prepare for an update from PHP 7.3 to 7.4. This basically 
> works, but the 7.3 packages stay installed. I would like to adapt the code 
> to remove the old packages. I am looking for a way to reuse the list of 
> packages of modules for uninstalling.
>
> I am thinking of a signature like this
> class profile::software::apache (
>  $php_version = '7.4',
>  $php_remove = ['7.0‘, ‘7.3']
> , #... 
> ) {
>
> $myPackages = [
>  "php$php_version-xml",
>  "php$php_version-zip",
>  "php$php_version-curl",
>  "php$php_version-mbstring",
>  "libapache2-mod-php$php_version",
>  ] 
>  
> ensure_packages($myPackages, {
>  'ensure' => 'present', 
>  } ) 
>
>  $php_remove.each | String $php_version | { 
>  ensure_packages($myPackages,
>  { 
>   'ensure' => 'absent', 
>  }  )
>  }
>  }
>
> Is there a way to solve this?
>
> thx
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/470cea3c-b64f-4666-827f-0bccfb101afcn%40googlegroups.com.

[Puppet Users] Re: I'm struggling with some node specific heria

[A Manzer]

Did you update site.pp to use the include syntax?

I looked at the error again, because I'm really not sure why it's working 
(other than the fact that you've mixed patterns, and seriously 
over-complicated your code). So here's your error, right?
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: 
Server Error: Evaluation Error: Error while evaluating a Resource 
Statement, Class[Permitroot]: expects a value for parameter 
'permitroot_config' (file: 
/etc/puppetlabs/code/environments/production/manifests/site.pp, line: 49, 
column: 3) on node lhcsrvprdcms01.fixnetix.com

Is it still more or less that?
Notice that the error is in the site.pp file, not your init.pp or 
config.pp.  It could be that since you're using the resource-like syntax, 
Puppet is expecting you to set that parameter, and isn't using Hiera.  
According to the hiera docs 
<https://puppet.com/docs/puppet/6.17/hiera_automatic.html>, it looks like 
it should still be looking things up?  But I know that in my own code, I 
always use include, or specify all my parameters when I'm forced to use the 
resource-like syntax.

On Friday, July 31, 2020 at 1:09:30 PM UTC-4 djc...@gmail.com wrote:

> Don't think it's a hiera issue now:
>
> # puppet lookup permitroot::permitroot_config --node 
> lhcsrvprdcms01.fixnetix.com
> ---
> - Match Address xx.xx.xx.xx
> - PermitRootLogin without-password
>
> # pwd
> /etc/puppetlabs/code/environments/production/data/nodes
>
> # cat *
> permitroot::permitroot_config:
>   - 'Match Address 10.20.232.21'
>   - 'PermitRootLogin without-password'
>
> Still no joy though.
>
> On Friday, July 31, 2020 at 4:47:40 PM UTC+1, A Manzer wrote:
>>
>> puppet lookup is a good diagnostic tool.
>>
>> Now though, you have a naming issue.  You need the permitroot:: prefix if 
>> you want Puppet/Hiera to automatically fill in your parameter.
>>
>> So your puppet lookup debug command should be puppet lookup 
>> permitroot::permitroot_config --explain --node 
>> lhcsrvprdcms01.fixnetix.com
>>
>> Once *that* works, your module should work too.
>>
>> Does any of this work if you put it in common.yaml to start?
>> On Friday, July 31, 2020 at 11:42:27 AM UTC-4 djc...@gmail.com wrote:
>>
>>> Still no luck.  Hiera is now matching (it wasn't before):
>>>
>>> root@puppet:/# puppet lookup permitroot_config --node 
>>> lhcsrvprdcms01.fixnetix.com
>>> ---
>>> - Match Address xx.xx.xx.xx
>>> - PermitRootLogin without-password
>>>
>>> I had to change the YAML file slightly to:
>>>
>>> permitroot_config:
>>>   - 'Match Address xx.xx.xx.xx'
>>>   - 'PermitRootLogin without-password'
>>>
>>> From:
>>>
>>> permitroot:permitroot_config
>>>   - 'Match Address xx.xx.xx.xx'
>>>   - 'PermitRootLogin without-password'
>>>
>>> Thanks for the tip!  I have been using PDK.
>>>
>>> On Friday, July 31, 2020 at 4:25:13 PM UTC+1, A Manzer wrote:
>>>>
>>>> I've noticed two other things that may need fixing:
>>>>
>>>>  - It may be a copy and paste error, but you don't close your Match 
>>>> Address string in the pasted Hiera file above.  That would cause your Yaml 
>>>> to be incorrect, and probably ignored.
>>>>  - In site.pp, you use the resource-like syntax for including the 
>>>> class.  I'm not sure what this does for automatic hiera parameter lookup, 
>>>> but it's usually safer to use include syntax instead.  I'd change your 
>>>> entry in site.pp to be
>>>>
>>>>
>>>> node lhcsrvprdcms01.domain.com {
>>>>   include permitroot
>>>> }
>>>>
>>>> BTW, out of curiosity, are you using the Puppet PDK 
>>>> <https://puppet.com/docs/pdk/1.x/pdk.html> to develop this module?  It 
>>>> brings *a lot* of boilerplate, but it also brings things like Yaml 
>>>> syntax validating and syntax validating that might help you out while 
>>>> you're learning.
>>>>
>>>> On Friday, July 31, 2020 at 10:46:13 AM UTC-4, Dan Crisp wrote:
>>>>>
>>>>> Thanks for the reply.
>>>>>
>>>>>  Unfortunately although my YAML file didn't have the .yaml suffix and 
>>>>> I didn't have a data directory, after making the necessary changes, the 
>>>>> same problem persists:
>>>>>
>>>>> Error: Could not retrieve catalog from remote server: Error 500 on 
>>>>> SERVER: Server Error: Evaluation Error: Error whi

[Puppet Users] Re: I'm struggling with some node specific heria

[A Manzer]

puppet lookup is a good diagnostic tool.

Now though, you have a naming issue.  You need the permitroot:: prefix if 
you want Puppet/Hiera to automatically fill in your parameter.

So your puppet lookup debug command should be puppet lookup 
permitroot::permitroot_config --explain --node lhcsrvprdcms01.fixnetix.com

Once *that* works, your module should work too.

Does any of this work if you put it in common.yaml to start?
On Friday, July 31, 2020 at 11:42:27 AM UTC-4 djc...@gmail.com wrote:

> Still no luck.  Hiera is now matching (it wasn't before):
>
> root@puppet:/# puppet lookup permitroot_config --node 
> lhcsrvprdcms01.fixnetix.com
> ---
> - Match Address xx.xx.xx.xx
> - PermitRootLogin without-password
>
> I had to change the YAML file slightly to:
>
> permitroot_config:
>   - 'Match Address xx.xx.xx.xx'
>   - 'PermitRootLogin without-password'
>
> From:
>
> permitroot:permitroot_config
>   - 'Match Address xx.xx.xx.xx'
>   - 'PermitRootLogin without-password'
>
> Thanks for the tip!  I have been using PDK.
>
> On Friday, July 31, 2020 at 4:25:13 PM UTC+1, A Manzer wrote:
>>
>> I've noticed two other things that may need fixing:
>>
>>  - It may be a copy and paste error, but you don't close your Match 
>> Address string in the pasted Hiera file above.  That would cause your Yaml 
>> to be incorrect, and probably ignored.
>>  - In site.pp, you use the resource-like syntax for including the class.  
>> I'm not sure what this does for automatic hiera parameter lookup, but it's 
>> usually safer to use include syntax instead.  I'd change your entry in 
>> site.pp to be
>>
>>
>> node lhcsrvprdcms01.domain.com {
>>   include permitroot
>> }
>>
>> BTW, out of curiosity, are you using the Puppet PDK 
>> <https://puppet.com/docs/pdk/1.x/pdk.html> to develop this module?  It 
>> brings *a lot* of boilerplate, but it also brings things like Yaml 
>> syntax validating and syntax validating that might help you out while 
>> you're learning.
>>
>> On Friday, July 31, 2020 at 10:46:13 AM UTC-4, Dan Crisp wrote:
>>>
>>> Thanks for the reply.
>>>
>>>  Unfortunately although my YAML file didn't have the .yaml suffix and I 
>>> didn't have a data directory, after making the necessary changes, the same 
>>> problem persists:
>>>
>>> Error: Could not retrieve catalog from remote server: Error 500 on 
>>> SERVER: Server Error: Evaluation Error: Error while evaluating a Resource 
>>> Statement, Class[Permitroot]: expects a value for parameter 
>>> 'permitroot_config' (file: 
>>> /etc/puppetlabs/code/environments/production/manifests/site.pp, line: 49, 
>>> column: 3) on node lhcsrvprdcms01.fixnetix
>>>
>>> # pwd
>>> /etc/puppetlabs/code/environments/production
>>>
>>> # ll data/nodes/lhcsrvprdcms01.fixnetix.com.yaml
>>> -rw-r--r--. 1 root root 103 Jul 30 12:09 
>>> data/nodes/lhcsrvprdcms01.fixnetix.com.yaml
>>>
>>>
>>> On Friday, July 31, 2020 at 2:15:18 PM UTC+1, A Manzer wrote:
>>>>
>>>> You need to put your nodes hiera folder under a data folder.  (*All* 
>>>> your hiera data goes under a data folder.)
>>>>
>>>> Also, ensure that your yaml file is named 
>>>> lhcsrvprdcms01.domain.com.yaml.  You need the *full* node name, *and* 
>>>> the .yaml at the end for hiera to find it.  That's tripped me up a few 
>>>> times...
>>>>
>>>> On Thursday, July 30, 2020 at 10:43:13 AM UTC-4, Dan Crisp wrote:
>>>>>
>>>>> Hello experts,
>>>>>
>>>>> I'm struggling with some node specific heria.  I basically want to add 
>>>>> the following lines to a number of nodes:
>>>>>
>>>>> Match Address xx.xx.xx.xx
>>>>> PermitRootLogin without-password
>>>>>
>>>>> I have the following in place in an attempt to acheive this:
>>>>>
>>>>> # pwd
>>>>>
>>>>> /etc/puppetlabs/code/environments/production/modules/permitroot/manifests
>>>>>
>>>>> # more *
>>>>>
>>>>> ::
>>>>> config.pp
>>>>> ::
>>>>> class permitroot::config (
>>>>>   $config_path = $permitroot::params::config_path
>>>>> ) inherits permitroot::params {
>>>>>   if $facts['os']['release']['major'] =~ /7/ {
>>>>> file { 'Update SSHD 

[Puppet Users] Re: I'm struggling with some node specific heria

[A Manzer]

I've noticed two other things that may need fixing:

 - It may be a copy and paste error, but you don't close your Match Address 
string in the pasted Hiera file above.  That would cause your Yaml to be 
incorrect, and probably ignored.
 - In site.pp, you use the resource-like syntax for including the class.  
I'm not sure what this does for automatic hiera parameter lookup, but it's 
usually safer to use include syntax instead.  I'd change your entry in 
site.pp to be


node lhcsrvprdcms01.domain.com {
  include permitroot
}

BTW, out of curiosity, are you using the Puppet PDK 
<https://puppet.com/docs/pdk/1.x/pdk.html> to develop this module?  It 
brings *a lot* of boilerplate, but it also brings things like Yaml syntax 
validating and syntax validating that might help you out while you're 
learning.

On Friday, July 31, 2020 at 10:46:13 AM UTC-4, Dan Crisp wrote:
>
> Thanks for the reply.
>
>  Unfortunately although my YAML file didn't have the .yaml suffix and I 
> didn't have a data directory, after making the necessary changes, the same 
> problem persists:
>
> Error: Could not retrieve catalog from remote server: Error 500 on SERVER: 
> Server Error: Evaluation Error: Error while evaluating a Resource 
> Statement, Class[Permitroot]: expects a value for parameter 
> 'permitroot_config' (file: 
> /etc/puppetlabs/code/environments/production/manifests/site.pp, line: 49, 
> column: 3) on node lhcsrvprdcms01.fixnetix
>
> # pwd
> /etc/puppetlabs/code/environments/production
>
> # ll data/nodes/lhcsrvprdcms01.fixnetix.com.yaml
> -rw-r--r--. 1 root root 103 Jul 30 12:09 
> data/nodes/lhcsrvprdcms01.fixnetix.com.yaml
>
>
> On Friday, July 31, 2020 at 2:15:18 PM UTC+1, A Manzer wrote:
>>
>> You need to put your nodes hiera folder under a data folder.  (*All* 
>> your hiera data goes under a data folder.)
>>
>> Also, ensure that your yaml file is named lhcsrvprdcms01.domain.com.yaml.  
>> You need the *full* node name, *and* the .yaml at the end for hiera to 
>> find it.  That's tripped me up a few times...
>>
>> On Thursday, July 30, 2020 at 10:43:13 AM UTC-4, Dan Crisp wrote:
>>>
>>> Hello experts,
>>>
>>> I'm struggling with some node specific heria.  I basically want to add 
>>> the following lines to a number of nodes:
>>>
>>> Match Address xx.xx.xx.xx
>>> PermitRootLogin without-password
>>>
>>> I have the following in place in an attempt to acheive this:
>>>
>>> # pwd
>>> /etc/puppetlabs/code/environments/production/modules/permitroot/manifests
>>>
>>> # more *
>>>
>>> ::
>>> config.pp
>>> ::
>>> class permitroot::config (
>>>   $config_path = $permitroot::params::config_path
>>> ) inherits permitroot::params {
>>>   if $facts['os']['release']['major'] =~ /7/ {
>>> file { 'Update SSHD PermitRoot':
>>>   ensure=> $permitroot::config_present,
>>>   path  => $permitroot::config_path,
>>>   content   => $permitroot::permitroot_config.join("\n"),
>>>   owner  => root,
>>>   group  => root,
>>>   mode   => '0600'
>>> }
>>>   } else {
>>>   notice ('Assuming RHEL 6.x thus taking no action')
>>> }
>>> }
>>> ::
>>> init.pp
>>> ::
>>> class permitroot (
>>>   $service_name = $permitroot::params::service_name,
>>>   $config_path  = $permitroot::params::config_path,
>>>   Array[String] $permitroot_config,
>>>   String $service_ensure,
>>>   Boolean $service_enable,
>>>   Boolean $service_hasrestart,
>>> ) inherits permitroot::params {
>>>   contain permitroot::config
>>>   contain permitroot::service
>>>
>>>   Class['permitroot::config']
>>> -> Class['permitroot::service']
>>> }
>>> ::
>>> params.pp
>>> ::
>>> class permitroot::params {
>>>   $service_name = 'sshd'
>>>   $config_path = '/etc/ssh/sshd_config'
>>> }
>>> ::
>>> service.pp
>>> ::
>>> class permitroot::service (
>>>   $service_name = $permitroot::params::service_name,
>>> ) inherits permitroot::params {
>>>   service {'permitroot_service':
>>> name   => $service_name,
>>> ensure => $permitroot::service_ensure,
>>> enable => $permitroot::service_enable,
>>> hasrestart => $permitroot::service_

[Puppet Users] Re: I'm struggling with some node specific heria

[A Manzer]

You need to put your nodes hiera folder under a data folder.  (*All* your 
hiera data goes under a data folder.)

Also, ensure that your yaml file is named lhcsrvprdcms01.domain.com.yaml.  
You need the *full* node name, *and* the .yaml at the end for hiera to find 
it.  That's tripped me up a few times...

On Thursday, July 30, 2020 at 10:43:13 AM UTC-4, Dan Crisp wrote:
>
> Hello experts,
>
> I'm struggling with some node specific heria.  I basically want to add the 
> following lines to a number of nodes:
>
> Match Address xx.xx.xx.xx
> PermitRootLogin without-password
>
> I have the following in place in an attempt to acheive this:
>
> # pwd
> /etc/puppetlabs/code/environments/production/modules/permitroot/manifests
>
> # more *
>
> ::
> config.pp
> ::
> class permitroot::config (
>   $config_path = $permitroot::params::config_path
> ) inherits permitroot::params {
>   if $facts['os']['release']['major'] =~ /7/ {
> file { 'Update SSHD PermitRoot':
>   ensure=> $permitroot::config_present,
>   path  => $permitroot::config_path,
>   content   => $permitroot::permitroot_config.join("\n"),
>   owner  => root,
>   group  => root,
>   mode   => '0600'
> }
>   } else {
>   notice ('Assuming RHEL 6.x thus taking no action')
> }
> }
> ::
> init.pp
> ::
> class permitroot (
>   $service_name = $permitroot::params::service_name,
>   $config_path  = $permitroot::params::config_path,
>   Array[String] $permitroot_config,
>   String $service_ensure,
>   Boolean $service_enable,
>   Boolean $service_hasrestart,
> ) inherits permitroot::params {
>   contain permitroot::config
>   contain permitroot::service
>
>   Class['permitroot::config']
> -> Class['permitroot::service']
> }
> ::
> params.pp
> ::
> class permitroot::params {
>   $service_name = 'sshd'
>   $config_path = '/etc/ssh/sshd_config'
> }
> ::
> service.pp
> ::
> class permitroot::service (
>   $service_name = $permitroot::params::service_name,
> ) inherits permitroot::params {
>   service {'permitroot_service':
> name   => $service_name,
> ensure => $permitroot::service_ensure,
> enable => $permitroot::service_enable,
> hasrestart => $permitroot::service_hasrestart,
>   }
> }
>
> This is probably not the best method and I'm still learning and don't want 
> to use a module that has already been created by someone else at this point.
>
> Here is the node specific heria:
>
> # pwd
> /etc/puppetlabs/code/environments/production/nodes
>
> # more *
> permitroot::permitroot_config:
>   - 'Match Address xx.xx.xx.xx
>   - 'PermitRootLogin without-password'
>
> Hiera file:
>
> # pwd
> /etc/puppetlabs/code/environments/production
>
> # more hiera.yaml
> ---
> version: 5
> defaults:
>   # The default value for "datadir" is "data" under the same directory as 
> the hiera.yaml
>   # file (this file)
>   # When specifying a datadir, make sure the directory exists.
>   # See https://puppet.com/docs/puppet/latest/environments_about.html for 
> further details on environments.
>   #datadir: data
>   data_hash: yaml_data
> hierarchy:
>   - name: "Per-node data"   # Human-readable name.
> path: "nodes/%{trusted.certname}.yaml"  # File path, relative to 
> datadir.
>
>   - name: "Per-OS defaults"
> path: "os/%{facts.os.family}.yaml"
>
>   - name: "Common data"
> path: "common.yaml"
>
> Site.pp file:
>
> # more site.pp
> ...
> ...
> ...
> node lhcsrvprdcms01.domain.com {
>   class { 'permitroot': }
> }
>
> When I run the puppet agent on the server about were I want the new vaules 
> added, I see the see returned the following:
>
> # puppet agent --no-daemonize --onetime --verbose --noop
> Info: Using configured environment 'production'
> Info: Retrieving pluginfacts
> Info: Retrieving plugin
> Info: Retrieving locales
> Info: Loading facts
> Error: Could not retrieve catalog from remote server: Error 500 on SERVER: 
> Server Error: Evaluation Error: Error while evaluating a Resource 
> Statement, Class[Permitroot]: expects a value for parameter 
> 'permitroot_config' (file: 
> /etc/puppetlabs/code/environments/production/manifests/site.pp, line: 49, 
> column: 3) on node lhcsrvprdcms01.fixnetix.com
> Info: Using cached catalog from environment 'production'
> Info: Applying configuration version '1596101172'
> Notice: Applied catalog in 2.39 seconds
>
> Any help here would be appreciated.
>
> Thanks,
> Dan.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/00c7ca49-e568-4ca4-9d64-722ed6d2aee6o%40googlegroups.com.

[Puppet Users] Re: [Roles/Profiles] when a technology module doesn't already exist - seeking opinions

[A Manzer]

>
>
> I've done the same thing in the past, just use Hiera to provide params to 
> technology modules.  It feels a little off, it seems like the "right" way 
> is to wrap a technology module in a profile and then put the profile:: 
> params in Hiera.
>

Yeah, you're right that the "right" way is wrap it and to put profile:: 
keys in hiera.  But one of the first principals of the Puppet Style Guide 
is readability, and I think most of the time it's more readable without the 
"profile::" prefixes.


> Honestly I was just putting a few w things in my example class to flesh it 
> out but I used contain because I use the Puppetlabs NTP module 
> 
>  
> as my template or benchmark.  The subtleties of `include` vs `contain` 
> evade me.
>
>  
They do for me as well.  But, I think because you don't know why you need 
`contain`, that means you don't actually need it. ;-)

>From what I recall, it's from early Puppet days when resources somehow 
"leaked" out of their class?  And that was bad?  So the "anchor pattern" 
was invented, and then that was formalized into `contain`.  I think for 99% 
of cases, `include` is sufficient.  

You should also be able to replace your resource chaining arrows with 
proper use of `notify` and `subscribe` parameters in resources.

Happy Puppeting!

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/49b77955-03f5-4d52-aa41-a0aa203d879fo%40googlegroups.com.

[Puppet Users] Re: [Roles/Profiles] when a technology module doesn't already exist - seeking opinions

[A Manzer]

Option A, 100%.

Why change your coding pattern just because a module isn't from the Forge?  
Who knows, maybe one day you'll post it yourself on the Forge!

Sometimes I do the full parameter workup like in your example, and 
sometimes I just use `include` and let Hiera fill in the parameters, 
without having to add 'profile::' at the beginning of every parameter.


You seem to be making things more complicated by using `contains` and those 
Refresh arrows though.  Why not just use `include`?

On Monday, June 8, 2020 at 5:26:56 PM UTC-4, Alan Evans wrote:
>
> While _most_ things I want to manage via Puppet have modules on the forge 
> that are well maintained, tested and highly flexible.  Sometimes though, I 
> find that there is something that my organizations uses that is just not 
> common enough to have a module on the forge.
>
> In roles/profiles we consider things to be layered, with Roles at the top 
> and technology specific modules at the bottom.  Profiles are our place to 
> control the behavior of technology specific modules and add any missing 
> functionality or business logic.
>
> How do you deal with technologies that do not have corresponding modules 
> on the forge?
>
> *A) Write technology module and profile?*
> Pros:
>  - follows established practice
>  - most flexible
> Cons:
>  - extra work
>  - possible duplication of effort
>
> class foo ($param1, $param2, ... $paramN) {
>   contain foo::install
>   contain foo::config
>   contain foo::service
>   Class['foo::install'] -> Class['foo::config'] -> Class['foo::service']
>  }
>
>
> class profile::foo ($param1 = 'my_default', $param2 = 'other_default', ... 
> $paramN) {
>   foo {
> param1 => $param1,
> param2 => $param2,
> ...
> paramN = $paramN,
>   }
> }
>
>
> *B) Put it all in a profile?*
> Pros:
>  - less work
>  - probably still flexible since you control the whole thing
> Cons:
>  - does not match established practices
>
> class profile::foo ($param1 = 'my_default', $param2 = 'other_default', ... 
> $paramN) {
>   contain profile::foo::install
>   contain profile::foo::config
>   contain profile::foo::service
>   Class['profile::foo::install'] -> Class['profile::foo::config'] -> Class
> ['profile::foo::service']
> }
>
>
>
> How have you handled this scenario in the past?
>
> Thank you,
> -Alan
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/7181b554-99b5-4e64-80f2-90a7e1e12b76o%40googlegroups.com.

Re: [Puppet Users] PE 2019.2 with Puppet Agent 5.x (Turn off new Intermediate CA architecture)

[A Manzer]

Thanks Justin.

I think I was just Out Of Luck from the start, by starting with a PE 2019.2 
install, with only 5.x agents available.

For anyone who finds this in the future, what I ended up doing was using 
the Puppet *gem* on Raspbian.  I ended up essentially following this guide 
<https://gist.github.com/aaroncoffey/2459738bb9fb3d91f237455a4c577e9c>, 
which is a little wrong in the systemd section, but boils down to "Install 
`ruby-full`, `gem install puppet`, create systemd unit file to manage the 
puppet agent."  This got me Puppet Agent v6, so is able to communicate with 
my new PE installation.

On Tuesday, November 19, 2019 at 5:11:50 PM UTC-5, Justin Stoller wrote:
>
> sorry for the delay, kid got sick.
>
> On Sun, Nov 17, 2019 at 3:13 AM A Manzer > 
> wrote:
>
>> From what I saw, the new architecture is an Intermediate Signing Cert, 
>> signed by a bare *key*.  I'm not sure how I could copy that to an agent 
>> and have it trusted.
>>
>
> The $cadir/ca_crt.pem will contain both the intermediate and root cert. 
> The root's private key is also left in the cadir so you can put it in a 
> safe location. The intermediate's key is in the $cadir/ca_key.pem location.
>
> IIRC, for a 5.x agent connecting to a 6.x CA you'd need to move the 
> ca_crt.pem and signed agent cert to the agent out of band, while also 
> disabling crl checking. Kinda defeats the purpose of enabling intermediate 
> CAs if you have to disable the CRL though. But, the refactor to handle CRL 
> chains wasn't something we were comfortable putting into an LTS right away. 
> And most folks we've talked to have an older CA infrastructure w/ new 
> agents, so the backport hasn't been prioritized.
>
>>
>> turn off your master, delete your ssldir and restart it to have it create 
>>> a self signed root.
>>>
>> This is what I want to do!  But I'm not sure what options to set during 
>> installation/setup to turn that off.
>>
>
> If you have an existing ssldir I think PE will install w/o additional 
> configuration and just use the existing certs/keys. The installer mostly 
> runs Puppet and the code that bootstraps it is basically an `exec { 
> "puppetserver ca setup": creates => "/etc/puppetlabs/puppet/ssl/ca" }` .
>
> I *think* the master, if the service starts and there isn't an ssldir, 
> will re-create the keys/certs it needs, but as a 5.x compatible self signed 
> root - but don't try that unless you're prepared for everything to fail. I 
> think we left the old bootstrap code in there for demo purposes, but it's 
> not actively maintained.
>
> Again, there's probably a better way w/in PE to distribute the certs once 
> you've regen them for the CA/master to the console/pdb, but I don't know 
> it. You might want to try #puppet-enterprise in the community slack channel.
>
>
> hth,
> Justin
>
>>
>>  
>> On Saturday, November 16, 2019 at 4:46:01 PM UTC-5, Justin Stoller wrote:
>>>
>>> Depending on your security inclinations you might try turning crl 
>>> checking off on your 5.5 agent (iirc, that was the biggest issue - if not 
>>> the only issue). You might have to also copy the signed cert over to the 
>>> agent too).
>>>
>>> Otherwise, you may be able to turn off your master, delete your ssldir 
>>> and restart it to have it create a self signed root. Make sure the agent on 
>>> the master can then check in. I don't remember how that cert is then 
>>> propagated out to pdb and the console. You'll either need to hunt and 
>>> replace on disk (there's gotta be a task or `puppet infra` command though), 
>>> or uninstall/re-install pe (iirc, you can install a fresh pe onto an 
>>> existing ssldir).
>>>
>>> hth
>>>
>>> On Sat, Nov 16, 2019 at 4:33 AM A Manzer  wrote:
>>>
>>>> Using the LTS is one option.
>>>>
>>>> I disagree that it says that pre-6 agents won't play with a 6 server.  
>>>> On that page I linked, there's a compatibility matrix that shows 5.x 
>>>> agents 
>>>> are compatible with PE 2019.1.  Also, the first phrase of the quote says 
>>>> that I can use pre-6.x agents.
>>>>
>>>> I think I'm closer: I found a page on Puppet 6 Intermediate CA 
>>>> <https://puppet.com/docs/puppetserver/6.0/intermediate_ca.html>, but 
>>>> it only tells me how to convert *to* an intermediate CA architecture, 
>>>> not *from* an intermediate CA architecture.
>>>>
>>>> On Saturday, November 16, 2019 at 7:02:01 AM UTC-5, LinuxDan wrote:
>>>>>
>>&

Re: [Puppet Users] PE 2019.2 with Puppet Agent 5.x (Turn off new Intermediate CA architecture)

[A Manzer]

>From what I saw, the new architecture is an Intermediate Signing Cert, 
signed by a bare *key*.  I'm not sure how I could copy that to an agent and 
have it trusted.

turn off your master, delete your ssldir and restart it to have it create a 
> self signed root.
>
This is what I want to do!  But I'm not sure what options to set during 
installation/setup to turn that off.

 
On Saturday, November 16, 2019 at 4:46:01 PM UTC-5, Justin Stoller wrote:
>
> Depending on your security inclinations you might try turning crl checking 
> off on your 5.5 agent (iirc, that was the biggest issue - if not the only 
> issue). You might have to also copy the signed cert over to the agent too).
>
> Otherwise, you may be able to turn off your master, delete your ssldir and 
> restart it to have it create a self signed root. Make sure the agent on the 
> master can then check in. I don't remember how that cert is then propagated 
> out to pdb and the console. You'll either need to hunt and replace on disk 
> (there's gotta be a task or `puppet infra` command though), or 
> uninstall/re-install pe (iirc, you can install a fresh pe onto an existing 
> ssldir).
>
> hth
>
> On Sat, Nov 16, 2019 at 4:33 AM A Manzer > 
> wrote:
>
>> Using the LTS is one option.
>>
>> I disagree that it says that pre-6 agents won't play with a 6 server.  On 
>> that page I linked, there's a compatibility matrix that shows 5.x agents 
>> are compatible with PE 2019.1.  Also, the first phrase of the quote says 
>> that I can use pre-6.x agents.
>>
>> I think I'm closer: I found a page on Puppet 6 Intermediate CA 
>> <https://puppet.com/docs/puppetserver/6.0/intermediate_ca.html>, but it 
>> only tells me how to convert *to* an intermediate CA architecture, not 
>> *from* an intermediate CA architecture.
>>
>> On Saturday, November 16, 2019 at 7:02:01 AM UTC-5, LinuxDan wrote:
>>>
>>> Use 2018.1.11 (LTS)
>>>
>>> It clearly says that pre-6 agents won’t play with a 6 server.
>>>
>>> —-
>>>
>>> "Sometimes I think the surest sign that intelligent life exists 
>>> elsewhere in the universe is that none of it has tried to contact us."
>>>
>>> Bill Waterson (Calvin & Hobbes)
>>>
>>> On Nov 16, 2019, at 6:50 AM, A Manzer  wrote:
>>>
>>> 
>>> I've been using Puppet Enterprise at work quite successfully for a long 
>>> time.  So I finally decided to take advantage of the "Run 10 nodes for 
>>> free" offer and run PE at home.
>>>
>>> I've set up my PE server using the latest 2019.2.1.  My desktop computer 
>>> runs Ubuntu 18.04, and I was able to `curl | sudo bash` to install version 
>>> 6.10.1 of the agent.
>>>
>>> But I'm really interested in running Puppet on my other Raspberry Pi 
>>> servers around the house.  So I installed Puppet version 5.5.10 from the 
>>> Raspbian archive and pointed it at my PE server.
>>>
>>> I'm able to see an unsigned certificate in my PE console, and sign it, 
>>> but then when I run puppet on my node, I get "Error: Could not request 
>>> certificate: SSL_connect returned=1 errno=0 state=error: certificate verify 
>>> failed: [unable to get issuer certificate for /CN=Puppet Enterprise CA 
>>> generated at +2019-*MM-DD HH:MM:SS*]"
>>>
>>> I think this is due to the fact that Puppet Server 6 now generates an 
>>> Intermediate Cert to sign Agent certs, rather than the older self-signed 
>>> root style.  The Component versions in recent PE releases 
>>> <https://puppet.com/docs/pe/2019.2/component_versions_in_recent_pe_releases.html>
>>>  
>>> document says 
>>>
>>> You can use pre-6.x agents with a Puppet 6.x or PE 2019.0 or later 
>>>> master, but this combination doesn't take advantage of the new 
>>>> intermediate 
>>>> certificate authority architecture introduced in Puppet Server 6.0. To 
>>>> adopt the new CA architecture, both your master and agents must be 
>>>> upgraded 
>>>> to at least 6.x/2019.0, and you must regenerate certificates. If you don't 
>>>> upgrade *all *of your nodes to 6.x, do not regenerate your 
>>>> certificates, because pre-6.x agents won't work with the new CA 
>>>> architecture. 
>>>>
>>>
>>> I think this is exactly the case I'm in.  I think my PE 2019.2.1 
>>> installation generated an intermediate cert architecture and my Puppet 5.5 
>>> agents don't understand i

Re: [Puppet Users] Managing a local users password with puppet on EL7

[A Manzer]

It's probably ok to reuse the same salt; it's just to defeat 
pre-computation attacks.

But if you really don't want to, you could:

   - Use the username as the salt.  That'll be static, so idempotent, and 
   different for every user.  Not as great as random salt, but better than no 
   salt.
   - Use a secrets server like Vault, and use the Hiera-Vault plugin to 
   retrieve a password.  (Just make sure you test first.  I tested this about 
   a year ago, and at the time the Hiera Vault plugin had a bug that 
   eventually exhausted all the connections into Vault.)
   - Don't actually use Puppet to set a password.  If this is your own 
   user, just manage your password yourself with the `passwd` command.


On Friday, November 15, 2019 at 10:23:26 AM UTC-5, Bart-Jan Vrielink wrote:
>
> Of course this is not idempotent. Mmm, security is difficult.
>
>
> -Original message-
> *From:* Bart-Jan Vrielink >
> *Sent:* Friday 15th November 2019 16:18
> *To:* puppet...@googlegroups.com 
> *Subject:* RE: [Puppet Users] Managing a local users password with puppet 
> on EL7
>
> Hello,
>
>
> Glad to hear that you got it to work.
>
> Before you put this into production, please make sure you don't re-use the 
> same salt value. Try to randomize it. Something like 
> seeded_rand_string(16,strftime("%s%L")) may work.
>
>
> -Original message-
> *From:* jmp242 >
> *Sent:* Friday 15th November 2019 15:31
> *To:* Puppet Users >
> *Subject:* Re: [Puppet Users] Managing a local users password with puppet 
> on EL7
>
> I figured it out. Thanks for the help. It's because I wasn't doing I 
>
>  password   => pw_hash(*'password'*, 'SHA-512', 'mysalt'),
>
>  I was doing
>
> Sensitive(pw_hash(*'$password'*, 'SHA-512', 'oursalt')),
>
> And because I used single quotes, it wasn't actually getting the parameter 
> / variable, but the literal $password. Remove the quotes entirely because 
> it's just a variable, and it works!
>
> And this is why you can't always just copy -> paste -> edit your stuff in!.
>
> On Friday, November 15, 2019 at 8:55:57 AM UTC-5, Bart-Jan Vrielink wrote: 
>>
>> Hello,
>>
>>
>> I'm still puzzled by why this is not working on your system. The 
>> following works for me on a Centos7 machine:
>>
>>
>> user { 'testuser':
>>   ensure => 'present',
>>   password   => pw_hash('password', 'SHA-512', 'mysalt'),
>> }
>>
>>
>> -Original message-
>> *From:* jmp242 > <#zarafa.5dcec2e1.049b.5200bd245c927dad@anjie.dontpanic.nl_>>
>> *Sent:* Friday 15th November 2019 14:41
>> *To:* Puppet Users > <#zarafa.5dcec2e1.049b.5200bd245c927dad@anjie.dontpanic.nl_>>
>> *Subject:* Re: [Puppet Users] Managing a local users password with 
>> puppet on EL7
>>
>> So, I set the password manually with passwd and got an entirely different 
>> hash than when I use the pw_hash function. The salt is obviously different 
>> as well, but the rest of /etc/shadow entry is the same. ssh user@localhost 
>> works with the password when I set manually with passwd, and does not work 
>> with pw_hash - not surprisingly.
>>  
>> I tried lowercase sha-512, and got the same hash as with uppercase 
>> SHA-512. Both methods (working manual passwd, and non working pw_hash) 
>> start with $6$ which implies a sha-512 hash from the docs, so I think 
>> pw_hash is just broken for EL7. Which means the user resource is broken.
>>
>> I guess temporarily, I'll just set the hash as a string and generate it 
>> with passwd, and see if that works - but it's obviously not ideal.
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to puppet...@googlegroups.com 
>> <#zarafa.5dcec2e1.049b.5200bd245c927dad@anjie.dontpanic.nl_>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/64419ef7-6d5b-4028-8548-194ea8fae8c7%40googlegroups.com
>>  
>> 
>> .
>>
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/609eade7-8f51-4881-a7a5-9aaeda2571c3%40googlegroups.com
>  
> 
> .
>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet...@googlegroups.com .
> To view this discussion on the web visit 
> 

Re: [Puppet Users] PE 2019.2 with Puppet Agent 5.x (CA issue?)

[A Manzer]

Using the LTS is one option.

I disagree that it says that pre-6 agents won't play with a 6 server.  On 
that page I linked, there's a compatibility matrix that shows 5.x agents 
are compatible with PE 2019.1.  Also, the first phrase of the quote says 
that I can use pre-6.x agents.

I think I'm closer: I found a page on Puppet 6 Intermediate CA 
<https://puppet.com/docs/puppetserver/6.0/intermediate_ca.html>, but it 
only tells me how to convert *to* an intermediate CA architecture, not 
*from* an intermediate CA architecture.

On Saturday, November 16, 2019 at 7:02:01 AM UTC-5, LinuxDan wrote:
>
> Use 2018.1.11 (LTS)
>
> It clearly says that pre-6 agents won’t play with a 6 server.
>
> —-
>
> "Sometimes I think the surest sign that intelligent life exists elsewhere 
> in the universe is that none of it has tried to contact us."
>
> Bill Waterson (Calvin & Hobbes)
>
> On Nov 16, 2019, at 6:50 AM, A Manzer > 
> wrote:
>
> 
> I've been using Puppet Enterprise at work quite successfully for a long 
> time.  So I finally decided to take advantage of the "Run 10 nodes for 
> free" offer and run PE at home.
>
> I've set up my PE server using the latest 2019.2.1.  My desktop computer 
> runs Ubuntu 18.04, and I was able to `curl | sudo bash` to install version 
> 6.10.1 of the agent.
>
> But I'm really interested in running Puppet on my other Raspberry Pi 
> servers around the house.  So I installed Puppet version 5.5.10 from the 
> Raspbian archive and pointed it at my PE server.
>
> I'm able to see an unsigned certificate in my PE console, and sign it, but 
> then when I run puppet on my node, I get "Error: Could not request 
> certificate: SSL_connect returned=1 errno=0 state=error: certificate verify 
> failed: [unable to get issuer certificate for /CN=Puppet Enterprise CA 
> generated at +2019-*MM-DD HH:MM:SS*]"
>
> I think this is due to the fact that Puppet Server 6 now generates an 
> Intermediate Cert to sign Agent certs, rather than the older self-signed 
> root style.  The Component versions in recent PE releases 
> <https://puppet.com/docs/pe/2019.2/component_versions_in_recent_pe_releases.html>
>  
> document says 
>
> You can use pre-6.x agents with a Puppet 6.x or PE 2019.0 or later 
>> master, but this combination doesn't take advantage of the new intermediate 
>> certificate authority architecture introduced in Puppet Server 6.0. To 
>> adopt the new CA architecture, both your master and agents must be upgraded 
>> to at least 6.x/2019.0, and you must regenerate certificates. If you don't 
>> upgrade *all *of your nodes to 6.x, do not regenerate your certificates, 
>> because pre-6.x agents won't work with the new CA architecture. 
>>
>
> I think this is exactly the case I'm in.  I think my PE 2019.2.1 
> installation generated an intermediate cert architecture and my Puppet 5.5 
> agents don't understand it.
>
> My question is: *How do I turn this off?*  How do I revert to a 
> pre-puppet 6.0 self-signed root?  A pe.conf setting with a fresh install is 
> fine because I don't have anything yet configured in this installation.
>
> Thanks.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/2eb9336e-7f31-4917-9e7f-838e8739955d%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/puppet-users/2eb9336e-7f31-4917-9e7f-838e8739955d%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/d730edfc-9b11-4ae3-b4bd-66b59c76d66f%40googlegroups.com.

[Puppet Users] PE 2019.2 with Puppet Agent 5.x (CA issue?)

[A Manzer]

I've been using Puppet Enterprise at work quite successfully for a long 
time.  So I finally decided to take advantage of the "Run 10 nodes for 
free" offer and run PE at home.

I've set up my PE server using the latest 2019.2.1.  My desktop computer 
runs Ubuntu 18.04, and I was able to `curl | sudo bash` to install version 
6.10.1 of the agent.

But I'm really interested in running Puppet on my other Raspberry Pi 
servers around the house.  So I installed Puppet version 5.5.10 from the 
Raspbian archive and pointed it at my PE server.

I'm able to see an unsigned certificate in my PE console, and sign it, but 
then when I run puppet on my node, I get "Error: Could not request 
certificate: SSL_connect returned=1 errno=0 state=error: certificate verify 
failed: [unable to get issuer certificate for /CN=Puppet Enterprise CA 
generated at +2019-*MM-DD HH:MM:SS*]"

I think this is due to the fact that Puppet Server 6 now generates an 
Intermediate Cert to sign Agent certs, rather than the older self-signed 
root style.  The Component versions in recent PE releases 

 
document says 

You can use pre-6.x agents with a Puppet 6.x or PE 2019.0 or later master, 
> but this combination doesn't take advantage of the new intermediate 
> certificate authority architecture introduced in Puppet Server 6.0. To 
> adopt the new CA architecture, both your master and agents must be upgraded 
> to at least 6.x/2019.0, and you must regenerate certificates. If you don't 
> upgrade *all *of your nodes to 6.x, do not regenerate your certificates, 
> because pre-6.x agents won't work with the new CA architecture. 
>

I think this is exactly the case I'm in.  I think my PE 2019.2.1 
installation generated an intermediate cert architecture and my Puppet 5.5 
agents don't understand it.

My question is: *How do I turn this off?*  How do I revert to a pre-puppet 
6.0 self-signed root?  A pe.conf setting with a fresh install is fine 
because I don't have anything yet configured in this installation.

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/2eb9336e-7f31-4917-9e7f-838e8739955d%40googlegroups.com.

Re: [Puppet Users] Re: [RFC] Changes to open-source container versioning

[A Manzer]

On Thursday, October 17, 2019 at 3:10:36 PM UTC-4, Morgan Rhodes wrote:
>
> The "from source" builds aren't quite nightlies, since they get built on 
> every commit/PR into master, so depending on how much development is 
> happening it could end up built more often, and there's certainly more risk 
> of picking up bugs.
>
> In this model the source builds aren't built based on a tag. We use `git 
> describe` to come up with the tag for the container, but the code is from 
> head/master.
>

This makes sense, thanks. It's close-ish to a nightly. :-)

Do you have a feel for whether or not it would be valuable to have a 
> `6.7-edge` in addition to `edge`, where `6.7-edge` would be HEAD of master 
> from the time 6.7.0 is tagged until the last commit before 6.8.0 is pushed? 
> Thinking about it more it might make sense to just have `edge` as the 
> latest from-source build and save the more granular/versioned tags for 
> builds from packages.
>

Sure!  Tags are free right?  Maybe there's something in 6.8 that someone 
doesn't want so they'll stick to 6.7.  Or maybe someone wants to test the 
6.7 stream beginning to end, which might overlap with the 6.8 stream which 
they want to test too.  Or maybe there will be a security update to 6.7 
after you start work on 6.8, so both will be going at once.  I think 
there's value in:
`6`
`6-edge`
`6.7` (or maybe even `6.7-latest`)
`6.7-edge`
`6.7.2`
`latest`
`edge`

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/5e90fbe8-5d99-4aaa-8e8b-7af410d2a41c%40googlegroups.com.

Re: [Puppet Users] Re: [RFC] Changes to open-source container versioning

[A Manzer]

On Wednesday, October 16, 2019 at 5:44:27 PM UTC-4, Morgan Rhodes wrote:
>
>
> Is your confusion mostly around the fact that one of them is built from 
> source and one from package, or that 6.7 is more of a floating tag? I know 
> I've seen that pattern in some other upstream repos like centos, postgres, 
> mysql, etc, but for those it might be 6.7 points to the latest 6.7.x that 
> was shipped, rather than more like head/nightly.
>  
>
It's mostly the from source, from package distiction.  I'm not familiar 
enough with Puppet's release cycle to know the distinction between a from 
source build and a from package build.  Are "from source" builds 
essentially just nightlys? I think people are more familiar with keywords 
such as "head", "master", "edge", or "nightly" and the tag should include 
something like that.  If they're not exactly nightly, but based on a tag in 
the source, what differentiates a from source build and a from package 
build?

If I were to look at these tags on Docker Hub, I'd expect them to represent 
the following:
puppet/puppetserver:6.7 => The latest release in the 6.7 series, moving 
from 6.7.0, through 6.7.1, etc.
puppet/puppetserver:6.7.0  => Exactly the release 6.7.0 and never changing
puppet/puppetserver:latest => The latest release of Puppet Server, moving 
through minor *and* major versions.  (Perhaps there's room for a 
puppet/puppetserver:6 tag here)
puppet/puppetserver:edge  => This one's less immediately obvious to me, but 
after a moment I'd probably realize that it was some kind of nightly or 
pre-release beta, especially given the tag date would be after the :latest 
tag.


-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/a07de248-a5dd-4e95-a9ae-0798c2c8a8ce%40googlegroups.com.

[Puppet Users] Re: [RFC] Changes to open-source container versioning

[A Manzer]

I find this scheme confusing.  I would be hard pressed to explain the 
difference between :6.7, built from *source*, and :6.7.0, built from a 
*package*.  I also don't think it's clear that :6.7 would advance past 
:6.7.0 in time.

I like the :edge and :latest tags.

But I think I'd be happier with some kind of "nightly" specification on the 
source version (unless I've misunderstood).  Maybe :6.7-nightly.  That 
would make it more clear to me that it's a frequent build of the 6.7 
branch, while 6.7.0 is a pinned version.

On the whole though, I think it's a good change.  Thank you!


On Tuesday, October 15, 2019 at 2:56:49 PM UTC-4, Morgan Rhodes wrote:
>
> Hi all,
>
> *tl;dr* - We're trying to make the versioning scheme for our containers 
> more intuitive, changes summarized in the table below, see more details at 
> https://github.com/puppetlabs/puppetserver/pull/2188
>
> build typecurrent tagnew tag
> from source puppet/puppetserver:6.7.0 puppet/puppetserver:6.7
> from source (latest) puppet/puppetserver:latest puppet/puppetserver:edge
> from package n/a puppet/puppetserver:6.7.0
> from package (latest) n/a puppet/puppetserver:latest
> *Versioning*
>
> For a while now, our containers have included a package built from source 
> and versioned based on the most recent tag to the repo. While we still 
> think building from source provides value to our users, it's become clear 
> that they also need a way to pin to a specific, released version of 
> puppetserver and count on that container not being updated. To address 
> this, we're changing the versioning scheme for our container builds.
>
> When we build images from source, those images will be versioned with X.Y 
> versions based on the latest tag on master. So, for example, the current 
> image versioned puppet/puppetserver:6.6.0 would move to 
> puppet/puppetserver:6.6. This tag will continue to have rolling updates 
> until the next X or Y release. If you want to follow whatever the latest 
> version of the image from source is, you will want to pin to 
> puppet/puppetserver:edge.
>
> We will also start building and shipping images when puppetserver is 
> shipped publicly. These images will be tagged with an X.Y.Z version that 
> will match the version of puppetserver installed on that image. This tag 
> will not receive any updates. If you want to follow the latest released 
> version of puppetserver, you will want to pin to puppet/puppetserver:latest.
>
> *Other Changes for the puppetserver images*
>
> We are also looking into removing the puppetserver-standalone image. I've 
> added a `USE_PUPPETDB` environment variable that can be set to false when 
> running the puppetserver image to have the same behavior as the current 
> puppetserver-standalone image.
>
> *Questions / Comments / Concerns?*
>
> Please leave comments at 
> https://github.com/puppetlabs/puppetserver/pull/2188 or respond here.
>
> -- 
> Morgan Rhodes
> Release Engineering
> mor...@puppet.com 
> she/her/hers
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/3c910a1c-3e50-43ed-a554-57fceb48b7d1%40googlegroups.com.

[Puppet Users] Re: firewalld module configuration issue

[A Manzer]

Don't worry too much about the "Failed Dependency"; that's a red-herring in 
this case.  It's not saying that you missed some configuration, it's saying 
that firewalld::reload class failed because something it was dependent on 
(the port) failed.

Looks like the fix should be easy: your code has the port number quoted as 
a string.  The documentation says that it should be an integer.  Take the 
quotes off your port value, and give it another shot.

On Wednesday, August 28, 2019 at 4:34:45 PM UTC-4, Jean Berthold wrote:
>
> Hello everyone,
>
> ’m currently learning about Puppet and I can’t see where is the error in 
> my configuration…
>
>
> I tested The following module to manage the CentOS firewall, firewalld.
>
> I
>
>  
>
> Ok, following the instructions in the webpage: 
> https://forge.puppet.com/crayfishx/firewalld
>
>  
>
> I installed themodule on the server (without special configuration)
>
> I included the following configuration on my node :
>
>  
>
> *[root@srv-eldpupet-02 manifests]# cat site.pp*
>
> *node 'centos7-dev01..local' { # Applies only to mentioned node; if 
> nothing mentioned, applies to all.*
>
> *include snmp*
>
> *include firewalld*
>
>  
>
> *firewalld_service { 'Close dhcpv6-client':*
>
> *  ensure  => 'absent',*
>
> *  service => 'dhcpv6-client',*
>
> *  zone=> 'public',*
>
> *}*
>
> *[root@srv-eldpupet-02 manifests]#*
>
>  
>
> This configuration works correctly, the snmp service/package and the 
> firewalld service/package are installed.
>
> And the service « dhcpv6-client is deactivated correctly, so the 
> firewalld_service function correctly.
>
>  
>
> Now, following the documentation, if I try to use the « firewall_port » 
> instruction, I have the following error on the client and the configuration 
> defined for firewalld_port is not applied :
>
>  
>
> è *Don’t work !!!*
>
>  
>
> *firewalld_port { 'Open port 161 in the public zone':*
>
> *  ensure   => 'present',*
>
> *  zone => 'public',*
>
> *  port => '161',*
>
> *  protocol => 'tcp',*
>
> *}*
>
>  
>
> è (Ffor opening the port dedicated to snmp…)
>
>  
>
>  
>
> With this configuration, I have the following error on my client :
>
>  
>
> *[root@centos7-dev01 ~]# puppet agent -tv*
>
> *Info: Using configured environment 'production'*
>
> *Info: Retrieving pluginfacts*
>
> *Info: Retrieving plugin*
>
> *Info: Retrieving locales*
>
> *Info: Loading facts*
>
> *Info: Caching catalog for centos7-dev01.eldora.local*
>
> *Info: Applying configuration version '1566830315'*
>
> */opt/puppetlabs/puppet/cache/lib/puppet/type/firewalld_zone.rb:148: 
> warning: key :port is duplicated and overwritten on line 150*
>
> *Info: Redefining firewalld_service in Puppet::Type*
>
> *Info: Redefining firewalld_port in Puppet::Type*
>
> *Error: Execution of '/usr/bin/firewall-cmd --permanent --zone public 
> --add-port /' returned 102: Error: INVALID_PORT*
>
> *Error: 
> /Stage[main]/Main/Node[centos7-dev01.eldora.local]/Firewalld_port[Open port 
> 161 in the public zone]/ensure: change from 'absent' to 'present' failed: 
> Execution of '/usr/bin/firewall-cmd --permanent --zone public --add-port /' 
> returned 102: Error: INVALID_PORT*
>
> *Notice: /Stage[main]/Firewalld/Exec[firewalld::reload]: Dependency 
> Firewalld_port[Open port 161 in the public zone] has failures: true*
>
> *Warning: /Stage[main]/Firewalld/Exec[firewalld::reload]: Skipping because 
> of failed dependencies*
>
> *Notice: Applied catalog in 1.85 seconds*
>
> *[root@centos7-dev01 ~]#*
>
>  
>
>  
>
> When the « *firewalld_service »* instruction works without more 
> configuration, the « firewall_port » instruction fail due to « failed 
> dependencies »…
>
> I’m sure this is a newbie question… but I don’t find any documentation 
> about that error !
>
>  
>
> When I try to open the port by command line, no problem:
>
>  
>
> *[root@centos7-dev01 ~]# firewall-cmd --zone=public --add-port=161/udp 
> --permanent*
>
> *success*
>
> *[root@centos7-dev01 ~]# firewall-cmd --zone=public --add-port=161/tcp 
> --permanent*
>
> *success*
>
> *[root@centos7-dev01 ~]#*
>
>  
>
> Is there something to configure in the module itself before using 
> « firewalld_port » instruction ?
>
>  
>
> By advance, thanks for your help and have a nice day !
>
>  
>
> Jean
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/d5d23291-9b4f-46a7-add9-107cc79d12ef%40googlegroups.com.