[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] Puppetserver ca migrate

[Justin Stoller]

On Thu, Mar 4, 2021 at 11:44 PM Bart-Jan Vrielink 
wrote:

> Hello,
>
>
> It would be nice if Puppet's Pupperware is also updated for this new CA
> location...
>

Is it not? I don't actually work on that team, but I pulled the latest
puppet/puppetserver image and saw this in the log:
 pupperware (master<>) :: docker run -it puppet/puppetserver

Running /docker-entrypoint.d/10-analytics.sh

(/docker-entrypoint.d/10-analytics.sh) Pupperware analytics disabled;
skipping metric submission
Running /docker-entrypoint.d/20-use-templates-initially.sh

Upgrading /opt/puppetlabs/server/data/puppetserver/vendored-jruby-gems
Running /docker-entrypoint.d/30-set-permissions.sh
Running /docker-entrypoint.d/40-update-puppetdb-conf.sh
Running /docker-entrypoint.d/50-set-certname.sh
Running /docker-entrypoint.d/55-set-masterport.sh
Running /docker-entrypoint.d/60-setup-autosign.sh
Running /docker-entrypoint.d/70-set-dns-alt-names.sh
Running /docker-entrypoint.d/80-ca.sh
Generation succeeded. Find your files in /etc/puppetlabs/puppetserver/ca
Running /docker-entrypoint.d/85-setup-storeconfigs.sh
Running /docker-entrypoint.d/90-log-config.sh
System configuration values:


That "Generation succeeded. Find your files in
/etc/puppetlabs/puppetserver/ca" line should be coming from the
"puppetserver ca" cli generating the CA files in the new location


>
> -Original message-
> *From:* Justin Stoller 
> *Sent:* Thursday 4th March 2021 18:11
> *To:* puppet-users@googlegroups.com
> *Subject:* Re: [Puppet Users] Puppetserver ca migrate
>
> Hi!
>
> If you've mounted external volumes for your cadir like:
>
>   --mount source=ca-volume,destination=/etc/puppetlabs/puppet/ssl/ca
>
> You should instead mount the destination as
> /etc/puppetlabs/puppetserver/ca
>
> If you have a Dockerfile that pre-populates your cadir you'll need to
> update your script to the destination above.
>
> Also, make sure your build process is running puppetserver ca setup as
> part of the process (that should ensure new installs have the right
> directory structure).
>
> If you're using this container as a lightweight vm and you've upgraded
> your server inside it, you'll need to somehow override the entrypoint to be
> a shell for you to work in (but you should look into using the container as
> an ephemeral thing with persistent mounts to save data between containers).
>
> If you're using this in a dev setup and are fine with your certs not
> persisting outside the life of the container you can effectively ignore the
> warning for now (but hopefully one of the ideas above will help you find
> the root cause of it).
>
>
> Also, you're the second person to mention having to pass the --config
> flag. That should only be necessary if you have a custom puppet.conf for
> some advanced purposes. I'm wondering if it was the help output to the CA
> tool that led you in that direction? I could see the current text being
> confusing, just wondering if we should change:
>
> > Use the currently configured puppet.conf file in your installation, or
> supply one using the `--config` flag.
>
> to something like
>
> > Uses the default puppet.conf in your installation, override by supplying
> the --config flag.
>
> ?
>
>
> Hope that helps,
> Justin
>
>
>
>
> On Thu, Mar 4, 2021 at 8:05 AM Gwen Clayde  wrote:
>
>> Hi,
>>
>> I want to solve this issue " The cadir is currently configured to be
>> inside the /etc/puppetlabs/puppet/ssl directory"
>>
>> The first step is :
>> puppetserver ca migrate --config
>>
>> After this , I got this message : "Puppetserver service is running.
>> Please stop it before attempting to run this command"
>>
>> i use puppet inside a docker container, if i stop it , i couldn't execute
>> the command of the first step.
>>
>> Is there another way to solve this problem?
>>
>> 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/CACWwVtOMfy16NxMxZtNqLV1VR-ei6DaEihzF11M1v3ut9VbSJA%40mail.gmail.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/CA%2B%3DBEqUKBsBfQ1FQ5sP5n%2BsM9RBqW7uMkB_3f%2BhFVPi9J-72%3DQ%40mail.gmail.com
> 
> .
>
> --
> You received this message 

Re: [Puppet Users] "puppetserver ca migrate" error

[Molly Waggett]

On Thu, Mar 4, 2021 at 4:07 AM Erwin Bogaard 
wrote:

> Hi Molly,
>
> thanks for opening the ticket. No further info to add from my side.
> I just executed the manual migration. To me it seems that way is actually
> easier than the puppetserver migrate-way, where yhou have to look for the
> location of your config file  ;-)
>

For what it's worth, you shouldn't have to look for your config file. The
command will use your puppet.conf file by default, but you can use the
--config flag if you want to use a different config file.

>
> On Wednesday, 3 March 2021 at 22:39:08 UTC+1 Molly Waggett wrote:
>
>> Hi Erwin,
>>
>> I have opened SERVER-2979
>>  to investigate your
>> issue. Any additional info you can add to that ticket would be greatly
>> appreciated.
>>
>> In the meantime, you can manually migrate your CA directory:
>> 1. stop the puppetserver service:
>> systemctl stop puppetserver
>> 2. move your CA directory to the new location:
>> mv /etc/puppetlabs/puppet/ssl/ca /etc/puppetlabs/puppetserver/ca
>> 3. to maintain backwards compatibility, create a symlink from the new
>> location to the old location:
>> ln -sf /etc/puppetlabs/puppetserver/ca /etc/puppetlabs/puppet/ssl/ca
>> 4. restart the puppetserver service:
>> systemctl start puppetserver
>>
>> Let us know if you have any other issues.
>>
>> Thanks!
>>
>> On Fri, Feb 26, 2021 at 6:40 AM Erwin Bogaard 
>> wrote:
>>
>>> Hi Molly,
>>>
>>> We don't really run an unusual setup: just a regular machine with
>>> hostname in local DNS available, no IPv6.
>>> The installed Puppet component versions are as follows:
>>> puppet-agent-7.4.1-1.el7.x86_64
>>> puppet-client-tools-1.2.6-1.el7.x86_64
>>> puppetdb-7.2.0-1.el7.noarch
>>> puppetdb-termini-7.2.0-1.el7.noarch
>>> puppet-release-1.0.0-15.el7.noarch
>>> puppetserver-7.0.3-1.el7.noarch
>>>
>>> The requested configuration is as follows:
>>> networking => {
>>>   dhcp => "192.168.100.1",
>>>   domain => "kntr.xxx.loc",
>>>   fqdn => "puppet01.kntr.xxx.loc",
>>>   hostname => "puppet01",
>>> ...
>>> }
>>> os => {
>>>   architecture => "x86_64",
>>>   family => "RedHat",
>>>   hardware => "x86_64",
>>>   name => "CentOS",
>>>   release => {
>>> full => "7.9.2009",
>>> major => "7",
>>> minor => "9"
>>>   },
>>>   selinux => {
>>> enabled => false
>>>   }
>>> }
>>> ruby => {
>>>   platform => "x86_64-linux",
>>>   sitedir => "/opt/puppetlabs/puppet/lib/ruby/site_ruby/2.7.0",
>>>   version => "2.7.2"
>>> }
>>> On Thursday, 25 February 2021 at 19:52:23 UTC+1 Molly Waggett wrote:
>>>
 Hi Erwin,

 The puppetserver ca migrate command must be run while the puppetserver
 service is stopped, but it looks like we're not catching the particular
 connection error you're getting when we check to see whether the service is
 running.

 I'm wondering if you have an unusual networking setup, e.g. custom DNS
 config, IPv6, etc.
 I was not able to reproduce your issue on a first attempt, so it would
 also be helpful to know which version of puppetserver you're running, what
 OS platform you're running on, and which version of Ruby you're using.

 Thanks!

 On Thu, Feb 25, 2021 at 2:59 AM Erwin Bogaard 
 wrote:

>
> Hi,
>
> I'm trying to solve the notofocation about "The cadir is currently
> configured to be inside the /etc/puppetlabs/puppet/ssl directory".
> When I follow the steps, and run:
>
> #  puppetserver ca migrate --config /etc/puppetlabs/puppet/puppet.conf
>
> I get the message: "Puppetserver service is running. Please stop it
> before attempting to run this command."
>
> If I then stop the puppetserver service and run the command again, I
> get the following Error: "Fatal error when running action 'migrate'
>   Error: Failed connecting to https://xxx.loc:8140/status/v1/simple/ca
>   Root cause: Failed to open TCP connection to xxx.loc:8140 (Invalid
> argument - connect(2) for "xxx.loc" port 8140)"
>
> That no connection is possible seems logical, as I stopped the service
> prevously.
>
> If "puppetsever ca migrate" won't run when the service is running, but
> it needs to connect to the service, how is that ever going to work? I'm
> baffeled.
>
> As a work around: is there maybe a manual way to execute this
> migration?
>
> --
> 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/c4627ffb-887d-490e-9dc6-7b730cdf3622n%40googlegroups.com
> 

[Puppet Users] How to stub a custom puppet function in every spec test?

[Martin Alfke]

Hi,

we use a custom function (extlib::read_url) which we want to stub for every 
profile and role class unit test.

We tried using before within Spec.configure:

RSpec.configure do |c|
  c.before :each do
Puppet::Functions.create_function(:'profile::read_url') do
  dispatch :read_url do
param 'Stdlib::HTTPUrl', :url
return_type 'String'
  end
  def read_url(url)
'ssh-rsa Azuozgouzvouzvf== u...@domain.tld'
  end
end
  end
end

When stubbing the function in spec_helper_local.rb file, we must add the 
dispatch and the def.

But the test still use the original function.

I also tried “overloading” the function in a spec/fixtures/override_modules 
directory.
Unit tests still take the original function.

Even adding shared_context is not working.

Has anyone an idea, on how to solve this.
I don’t want to add the function stub (which works flawlessly) into every class 
unit test.

This is a working example where we stub inside the class unit test:
require 'spec_helper'

describe 'profile::base::user_accounts' do
  on_supported_os.each do |os, os_facts|
context "on #{os}" do
  let(:facts) { os_facts }
  Puppet::Functions.create_function(:'profile::read_url') do
return 'ssh-rsa Azuozgouzvouzvf== u...@domain.tld'
  end

  it { is_expected.to compile }
end
  end
end

Best,
Martin

-- 
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/422A162D-B1C9-48B1-902C-8E70F1D945A5%40gmail.com.