Re: [Puppet Users] Using the puppet gem on an unsupported platform

[Martin Alfke]

Hi Mark,

You can check if a type is available by running puppet describe -l
This will print out all available puppet custom types.

Best,
Martin


> On 11. Mar 2021, at 18:11, Mark Dixon  wrote:
> 
> Hi Martin,
> 
> Thanks - but that doesn't seem to be the problem, as it's already in the 
> modulepath. Just noticed something odd, will prod a bit more (unfortunately 
> next week now).
> 
> Best,
> 
> Mark
> 
> On Thursday, March 11, 2021 at 7:04:06 AM UTC Martin Alfke wrote:
> Hi Mark,
> 
> please check module path using 'puppet config print modulepath' and install 
> the required core modules into one of the mentioned folders:
> puppet module install puppetlabs-mount_core --target-dir 
> 
> This should make the mount resource type available.
> 
> Best,
> Martin
> 
> 
>> On 10. Mar 2021, at 16:22, Mark Dixon > > wrote:
>> 
> 
>> 
>> Hi there,
>> 
>> Following on from the conversation about the availability of a puppet agent 
>> RPM on el8 for the ppc64le architecture, I'm trying to use agent in the 
>> version of puppet made available as a ruby gem.
>> 
>> It largely works just by doing this, giving me puppet 7.4.1:
>> 
>>   yum install ruby
>>   gem install puppet
>> 
>> However, its "mount" resource provider doesn't appear to do anything. I 
>> tried reproducing this on el8 /x86_64: "mount" resources worked under the 
>> puppet agent rpm, but not under the puppet agent from the gem.
>> 
>> Is this related to the movement of "mount" into the "mount_core" module? 
>> There isn't an obvious extra gem to install, and I tried a "puppet module 
>> install puppetlabs-mount_core" on the client (but suspect that's only a 
>> useful command on the server!)
>> 
>> Any ideas on how to get the mount resource working for the puppet gem, 
>> please?
>> 
>> Thanks,
>> 
>> Mark
>> 
> 
>> -- 
>> 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/362ba8fc-9dc3-4929-a500-70123de399ecn%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/df95f59d-4d01-4695-8df7-bc7de943ad34n%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/3EE377C8-861A-4FE6-815F-9C471E6A3303%40gmail.com.

Re: [Puppet Users] [INFO, maybe ACTION] r10k Feature Proposal

[Ben Ford]

Hey Molly,

The PDK has already been ignoring the /spec directory for quite some time,
so I think this is totally appropriate. It won't even have any effect for
PDK enabled modules from the Forge. Those files are only used for
development purposes, and if you're doing that in your production codebase,
you should go slap yourself on the wrist! 

Honestly, I'm not even sure that r10k should offer an option to opt out. If
you want the specs to do dev work on the module, then you really ought to
just be cloning it into a workspace in the first place. Working directly in
a deployed control repo is a real good way to get yourself stuck. If you
make changes to files, accidentally or not, you can easily get yourself
into the state where r10k or Code Manager can't even deploy cleanly and
you'll have to either clean up the repo, or nuke it and redeploy. We've
recommended for ages that people just treat the deployed control repo as a
black box.

Cheers!

On Thu, Mar 11, 2021 at 4:07 PM  wrote:

> Molly,
>
>
>
> Should this be an all or nothing or off by default with the option to
> include them?
>
>
>
> Thanks,
>
> Steve
>
>
>
>
>
>
>
>
>
> *From:* puppet-users@googlegroups.com  *On
> Behalf Of *Molly Waggett
> *Sent:* Thursday, March 11, 2021 7:04 PM
> *To:* puppet-users@googlegroups.com
> *Cc:* Froyo Team 
> *Subject:* [Puppet Users] [INFO, maybe ACTION] r10k Feature Proposal
>
>
>
> Hey folks!
>
>
>
> We are planning an r10k feature to stop deploying module spec
> directories. This will lower disk usage, particularly for folks with a lot
> of modules and multiple compilers.
>
>
>
> Our hope is to enable this behavior by default, but leave the option to
> opt out (i.e. continue including spec directories when deploying
> modules). This is based on the assumption that most folks have no need for
> module spec directories in a production environment, since they typically
> just include testing materials for module development.
>
>
>
> If you think this assumption is inaccurate, or even if it’s just
> inaccurate for you, please let us know! If we don’t hear any objections by 
> *Tuesday,
> March 23*, we will proceed with the above plan to adopt this behavior but
> include a way to opt out.
>
>
>
> If you have any questions, please reply to this email or ping @r10k in the 
> Puppet
> Community Slack .
>
>
>
> Thanks!
>
>
>
> --
>
> *Molly Waggett*
>
> she/her
>
> Senior Software Engineer @ Puppet
>
> --
> 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/CAFOE68C%2BWNLmtfgJgCUkRkjX-rYqoAUAQvUApa-xp1_k7sp7vA%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/155101d716d3%24aa8c9750%24ffa5c5f0%24%40gmail.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/CACkW_L4cU8qUc5F%2BLPocg0oKogi9ce3C3vw98azGdHGwAqCg2g%40mail.gmail.com.

RE: [Puppet Users] [INFO, maybe ACTION] r10k Feature Proposal

[steverobillard]

Molly,

 

Should this be an all or nothing or off by default with the option to include 
them?

 

Thanks,

Steve

 

 

 

 

From: puppet-users@googlegroups.com  On Behalf 
Of Molly Waggett
Sent: Thursday, March 11, 2021 7:04 PM
To: puppet-users@googlegroups.com
Cc: Froyo Team 
Subject: [Puppet Users] [INFO, maybe ACTION] r10k Feature Proposal

 

Hey folks!

 

We are planning an r10k feature to stop deploying module spec directories. This 
will lower disk usage, particularly for folks with a lot of modules and 
multiple compilers.

 

Our hope is to enable this behavior by default, but leave the option to opt out 
(i.e. continue including spec directories when deploying modules). This is 
based on the assumption that most folks have no need for module spec 
directories in a production environment, since they typically just include 
testing materials for module development.

 

If you think this assumption is inaccurate, or even if it’s just inaccurate for 
you, please let us know! If we don’t hear any objections by Tuesday, March 23, 
we will proceed with the above plan to adopt this behavior but include a way to 
opt out. 

 

If you have any questions, please reply to this email or ping @r10k in the  
 Puppet Community Slack.

 

Thanks!

 

-- 

Molly Waggett

she/her

Senior Software Engineer @ Puppet

-- 
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/CAFOE68C%2BWNLmtfgJgCUkRkjX-rYqoAUAQvUApa-xp1_k7sp7vA%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/155101d716d3%24aa8c9750%24ffa5c5f0%24%40gmail.com.

[Puppet Users] [INFO, maybe ACTION] r10k Feature Proposal

[Molly Waggett]

Hey folks!

We are planning an r10k feature to stop deploying module spec directories.
This will lower disk usage, particularly for folks with a lot of modules
and multiple compilers.

Our hope is to enable this behavior by default, but leave the option to opt
out (i.e. continue including spec directories when deploying modules). This
is based on the assumption that most folks have no need for module spec
directories in a production environment, since they typically just include
testing materials for module development.

If you think this assumption is inaccurate, or even if it’s just inaccurate
for you, please let us know! If we don’t hear any objections by Tuesday,
March 23, we will proceed with the above plan to adopt this behavior but
include a way to opt out.

If you have any questions, please reply to this email or ping @r10k in
the Puppet
Community Slack .

Thanks!

-- 
*Molly Waggett*
she/her
Senior Software Engineer @ Puppet

-- 
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/CAFOE68C%2BWNLmtfgJgCUkRkjX-rYqoAUAQvUApa-xp1_k7sp7vA%40mail.gmail.com.

Re: [Puppet Users] Puppetserver ca migrate

[Justin Stoller]

On Sat, Mar 6, 2021 at 3:18 AM Bart-Jan Vrielink 
wrote:

> /etc/puppetlabs/puppetserver/ca is not a volume listed in the
> docker-compose file. Unless that directory is symlinked to somewhere under 
> /etc/puppetlabs/puppet/,
> that directory would get lost whenever the container gets updated. Not a
> good thing for certificates...
>

Yeah, that sounds terrible  I took that to the team that owns our
docker images. They seemed swamped but suggested a path forward, so I gave
it a shot in this PR: https://github.com/puppetlabs/puppetserver/pull/2505.
Feel free to contribute to the approach there if you want, otherwise I'll
reply to this thread when it's sorted out.



> -Original message-
> *From:* Justin Stoller 
> *Sent:* Friday 5th March 2021 20:35
> *To:* puppet-users@googlegroups.com
> *Subject:* Re: [Puppet Users] Puppetserver ca migrate
>
>
>
> 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 

Re: [Puppet Users] Using the puppet gem on an unsupported platform

[Mark Dixon]

Hi Martin,

Thanks - but that doesn't seem to be the problem, as it's already in the 
modulepath. Just noticed something odd, will prod a bit more (unfortunately 
next week now).

Best,

Mark

On Thursday, March 11, 2021 at 7:04:06 AM UTC Martin Alfke wrote:

> Hi Mark,
>
> please check module path using 'puppet config print modulepath' and 
> install the required core modules into one of the mentioned folders:
> puppet module install puppetlabs-mount_core --target-dir 
>
> This should make the mount resource type available.
>
> Best,
> Martin
>
> On 10. Mar 2021, at 16:22, Mark Dixon  wrote:
>
>
> Hi there,
>
> Following on from the conversation about the availability of a puppet 
> agent RPM on el8 for the ppc64le architecture, I'm trying to use agent in 
> the version of puppet made available as a ruby gem.
>
> It largely works just by doing this, giving me puppet 7.4.1:
>
>   yum install ruby
>   gem install puppet
>
> However, its "mount" resource provider doesn't appear to do anything. I 
> tried reproducing this on el8 /x86_64: "mount" resources worked under the 
> puppet agent rpm, but not under the puppet agent from the gem.
>
> Is this related to the movement of "mount" into the "mount_core" module? 
> There isn't an obvious extra gem to install, and I tried a "puppet module 
> install puppetlabs-mount_core" on the client (but suspect that's only a 
> useful command on the server!)
>
> Any ideas on how to get the mount resource working for the puppet gem, 
> please?
>
> Thanks,
>
> Mark
>
> -- 
> 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/362ba8fc-9dc3-4929-a500-70123de399ecn%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/df95f59d-4d01-4695-8df7-bc7de943ad34n%40googlegroups.com.

[Puppet Users] Re: Nonconformist Ubuntu based distro users

[Corey Osman]

I am thinking we can make a whole module out of this issue and fix the 
problem with puppet code. This problem appears in other tooling as well.  I 
have the following in my code now which patches the lsb-release file and 
appears to make things works.

https://gist.github.com/logicminds/0816ab9c3cd485a7270bc2795ec2b94f

Keeping track of all the flavors and codenames is annoying but can easily 
be done in hieradata with a giant hash.

I can start a module if anyone wants to contribute.   Other ideas 
welcomed.  I won't be conforming as I am not able to use Ubuntu on my 
specialized hardware.



On Friday, March 5, 2021 at 6:27:08 PM UTC-8 ama...@gmail.com wrote:

> 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/2b2e755e-1b30-4011-a405-4e5657598931n%40googlegroups.com.