Puppet Community

so I do a `if defined(User['some_user_name']`

however - in _that_ class - the users are _never_ defined.

why do you need to check if the user is defined?

defined() depends on the ordering in the catalog. rule of thumb: try to avoid it

Ah - well - I'm checking to see if the user exists because I want to apply an ssh_authorized_key resource, and I _DON'T_ want to do that if the user resource for that user doesn't exist.

because that would mean the user's _home_ directory would not exist.

I am totally open to doing this in another way

configure the keys where you create the user

I need to head out in a few minutes,if you can share the code I can give somr advise tomorrow

I’d say as long as you have list of users defined somewhere (hiera?) you can iterate over it and create resources you need

Or use a `require =&gt; User['whomever']` for your keys and puppet will make sure the user is created before the keys

Im sure that the classes are both included in the manifest

I want to say, "Add `recurse =&gt; true`" to your file resource

Be aware of the caveats. <https://www.puppet.com/docs/puppet/7/types/file.html#file-attribute-recurse>

Interesting - I was reading this: <https://www.puppetcookbook.com/posts/creating-a-directory-tree.html>

Perhaps they’ve added recurse since then

I just tried this (with a hard coded path):
```    file { '/some/long/path/with/parents/that/do/not/exist/on/disk/yet':
      ensure =&gt; 'directory',
      owner   =&gt; 'tomcat',
      group   =&gt; 'tomcat',
      recurse =&gt; true,
    }```

And the Puppet agent comes back with:
```Info: Applying configuration version 'rhs-dev-cf877fee152'
Error: Cannot create /some/long/path/with/parents/that/do/not/exist/on/disk/yet; parent directory /some/long/path/with/parents/that/do/not/exist/on/disk does not exist
Error: /Stage[main]/Dspace_modern/File[/some/long/path/with/parents/that/do/not/exist/on/disk/yet]/ensure: change from 'absent' to 'directory' failed: Cannot create /some/long/path/with/parents/that/do/not/exist/on/disk/yet; parent directory /some/long/path/with/parents/that/do/not/exist/on/disk does not exist```

We have a defined type `parent_dirs` that uses `reduce`, looking up parameters from Hiera so we can make sure that any common path elements get the same ownership/permissions regardless of where `parent_dirs` is called from.
```define parent_dirs (
  Hash $params = {
    'ensure' =&gt; 'directory',
    'owner'  =&gt; 'root',
    'group'  =&gt; 'root',
    'mode'   =&gt; '0755',
  },
) {
  $parent_dirs_params = lookup('parent_dirs::params',Hash[String,Hash],undef,{})
  $title.split('/').reduce([]) | $sub_path,$d | {
    $new_path = $sub_path + $d
    $new_path_join = $new_path.join('/')
    if $new_path_join =~ /^\// {
      # Use the params hash as defaults if any values aren't set in parent_dirs::params for a particular path
      ensure_resource('file',$new_path_join,($params + pick($parent_dirs_params[$new_path_join],{})))
    }
    $new_path
  }
}```

Thanks <@U01B7920SC9> - I take it that’s not in Puppet core or a module etc.  That’s something you’ve defined for your site ?

As an aside, I’m not sure that “recurse =&gt; true” actually creates missing parents.  It doesn’t seem to in my quick test

Basically, loop through the directory tree elements, split by `/` and `ensure =&gt; directory` on each element.

Thanks all for your help - does make it difficult though.  Wonder why they haven’t implemented the equivalent of “mkdir -p”

It does cut a bit against the roles&amp;profiles grain but OTOH is handy for a sysadmin

Right - yeah, very much approaching things from a sysadmin point of view - so there is likely things I’m not aware of :slightly_smiling_face:

there is this too <https://github.com/voxpupuli/puppet-extlib/blob/master/REFERENCE.md#extlibmkdir_p>

Thanks <@UEQ6B9JAH> - Looks useful, will look into this

I use <https://forge.puppet.com/modules/pltraining/dirtree> to create my parent directories.

<@U7CU2416H> there is no change to the operational status of PE on licence expiration, you will get banners in the console, and extra log lines in your log files, if you are engaged with your account team already, have them inform the support team about the delay so you have continued support

Thanks, found the ticket here: <https://tickets.puppetlabs.com/browse/SERVER-3193>

Honestly, yes, it is embarrassing.  Unfortunately, our previous executive management team had priorities that were not aligned with our PE customers and OSP community.  Since being purchased by Perforce, our strategy has changed and our engineering teams are hard at work trying to repair the sins of the past.

Ubuntu 22.04 amd64 is on the roadmap for our q2 release

Interesting about Perforce, when I read the headline initially I thought the opposite direction would become the norm, so that's pretty cool

It has taken a little while (and there's still background stuff to happen), but you should start seeing many interesting and positive changes coming.

<@U428YSTUJ>: In my case, I manage the entire contents of `facter.conf` , YMMV.

```# @summary Puppet facter configuration to block facts at a granular level (to improve speed).
#
class profiles::facts::config () {
  $config_content = @(EOT)
    facts : {
      blocklist : [
        "file system",
        "load_averages",
        "identity",
        "memory.system.capacity",
        "memory.system.used",
        "memory.system.used_bytes",
        "memory.system.available",
        "memory.system.available_bytes",
        "memory.swap.capacity",
        "memory.swap.used",
        "memory.swap.used_bytes",
        "memory.swap.available",
        "memory.swap.available_bytes",
        "system_uptime",
      ]
    }
    |EOT

  file {
    # default attribute values
    default:
      ensure =&gt; directory,
      mode   =&gt; '0755',
      owner  =&gt; root,
      group  =&gt; root,
      ;

    '/etc/puppetlabs/facter':
      ensure =&gt; directory,
      ;
    '/etc/puppetlabs/facter/facter.conf':
      ensure  =&gt; file,
      mode    =&gt; '0644',
      content =&gt; $config_content,
      ;
  }
}```

nice. will probably just use a template for now. thanks!

Hello all - I have inherited a puppet 5.5 / foreman environment and the CA expired. WE created a new CA, but I am seeing this in the puppetserver logs
``` [p.t.a.rules] Forbidden request: &lt;ip address&gt; access to /puppet/v3/file_metadatas/modules/xxxx (method :get) (authenticated: false) denied by rule 'puppetlabs file metadata'.```

assuming puppet opensource, the following file:
```/etc/puppetlabs/puppetserver/conf.d/auth.conf```
contains the rules

although to be honest 5.5 might still use the old authentication method

looking at logs beofre the ca expired, get / puts look fine

```             # Allow nodes to access all file_metadata.  Note that access for the
            # 'delete' method is forbidden by Puppet regardless of the
            # configuration of this rule.
            match-request: {
                path: "/puppet/v3/file_metadata"
                type: path
                method: [get, post]
            }
            allow: "*"```

the haproxy LB is doing a puppet run when you get that error?

maybe we should manually copy certs to it?

only puppet nodes are allowed to fetch from the file_metadata route

actually - i think we did manually copy to them

so if something is independently (not as part of a puppet run) calling the puppet api, you may need to change the rules to allow it

``` allow-unauthenticated: true```
isnt present, so the
```(authenticated: false)```
makes me think that the node isnt authenticating and therefore failing to access the api endpoint

and given that a CA expired, makes me suspect that there is an issue with client certs

we are deleting the ssl dir and re running puppet...but the runs are itming out

and you have verified basic connectivity (assuming linux)
```nc -vz &lt;puppet url&gt; &lt;puppet port&gt;```

did you restart the puppetserver service post ca re creation?

anything in the puppetserver logs that might enlighten the situtation?

i think biggest tipoff is that initial log snippet

requesting a new node certificate is unauthenticated route

so the nodes should be able to generate new certs, and then retrived the signed certificate

typically always nuke the ssl dir on agent, cert clean,  and regen

on the agent running the regen, just hangs? and then timesout?

yeah everything is incredibly slow now i think due to stampeding herds

try with --debug, even though it probaably wont help

this actually turned out to be because we had not restarted the puppet agent service (doh)

stopping service deleting agent ssl certs and restarting solved the issue

glad you figured it out. Didn't think of the agent service, because I do not run the agent that way

I would assume it's in database index order, so not something that's externally observable but probably related to insertion order generally. There's an `order by` clause you can use to influence the order in the output though: <https://www.puppet.com/docs/puppetdb/7/api/query/v4/pql.html#order-by>

cool, thanks. Order by will suffice in ensure the output is always in lexographical order by certname

Hi Bruno! I'll pass this along to our LMS administrator. It would help if you could share your email address with me. Feel free to message me directly or reply in this thread. Thanks!

• I recommend to use a class parameter
• how do you check that it's false?

if $var { notify{’msg”:} }
not sure what you mean by a class param - something passed into the module ?  I’m just trying to fix some broken code at present so if I can fix it without adding a class param then I’d prefer to do so

style guide recommends to use class parameter with automatic hiera lookup instead of calling `lookup()` by hand, but that's just a cosmetic thing

try:
```notify { 'foo':
  message =&gt; "${var}",
}```

I guess you've that value in hiera :slightly_smiling_face:

did you try running `puppet lookup` to check if it's in hiera?

I’m pretty sure its not there - will try the lookup and see

Lookup shows it as false - strange thing is our hieradata repo doesnt have it set - so something has been changed ‘along the way’ to the puppet servers.   Something else to chase

Tanks for the help

with --explain and --compile and correct environment and fqdn?

Sorry for the late reply called with correct fqdn and environment and explain.   Found the file and it looks like it was modified on the puppet server but not the repo (which is where I searched originally)

Is it me or it's not possible to use a password hash for the MySQL root password, using the puppetlabs-mysql module?  I know it's probably not as secure as using eyaml but I was wondering why it couldn't be done for the mysql root account.

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

hmm :thinking_face:   wonder why I'm not seeing any change

```$ sudo cat local_modules/profile/manifests/nodejs/hello.pp                                                                                                                          class profile::nodejs::hello {                                                                                                                                                                 file { '/tmp/hello.txt':                                                                                                                                                                ensure  =&gt;  file,                                                                                                                                                                     content =&gt; "hello, world\n",                                                                                                                                                        }                                                                                                                                                                                   } ```

you define a class but you dont call the class

if it's meant to be part of the module, you would be better off setting a module path and `puppet apply -e 'include profile::nodejs::hello'`

And maybe you’d like to consider using Puppet Bolt instead :)

I'm a puppet n00b, so learning Bolt right now might muddy the waters :wink:

<@U020LK7D0JU> that helped.  Thanks.  I needed to specify my module path and then that...and  it worked.

you need to add the class to the catalog, for example with include

yea, my puppet apply is literally just creating a catalog that only includes the class (and whatever it needs)

Now I'm getting this :slightly_frowning_face:

also, you should really use ubuntu's dpkg for nodejs if at all possible

you can't determine if that exec was idempotent

I'm trying to figure out how to deploy strapi and I believe it  needs  a particular version of nodejs, hence why I'm trying it this way.

you're going to need to deep dive how to do that, because exec is almost never the right choice

<https://forge.puppet.com/modules/puppet/nodejs/readme>

<https://www.digitalocean.com/community/tutorials/how-to-set-up-and-install-strapi-for-production-on-ubuntu-22-04>

the idea in puppet is to deterministically say what each managed resource is and let puppet figure out how to get there

<@U020LK7D0JU> I agree with non idempotent ways...but I'm just trying to get something to work for now..and can refactor later.  Both Puppet and Strapi are new to me :smile:  ( ansible background )

ok, so reading the script, all it really does is install a gpgkey and echo to a .d file

but that isn't the error  I'm getting though.  I thought the issue is on the nodejs class part?

so what I would do is review <https://deb.nodesource.com/setup_16.x> and just create an apt_source and give it the right url and gpgkey and then in the nodejs class, you may need to actually go and check if it actually works

I don;t know what nodejs class you are using

This is what I'm trying to use:
<https://forge.puppet.com/modules/puppet/nodejs/readme>

yea, looks like you need to make a patch / PR to that <https://github.com/voxpupuli/puppet-nodejs/blob/master/manifests/params.pp> and then ask <#C0W1Y5VL0|> to review it

you'll also want to run a --debug on that likely to try and figure out where it was actually trying to do that

&lt;- Puppet n00b remember?  Not sure what to do with the params.pp patch/PR you're talking about.

<https://github.com/voxpupuli/puppet-nodejs/blob/master/manifests/params.pp#L54-L76> the first section of that is the definitions for 20.04, the second is the fallbacks

as an alternative approach I recommend rolling out dns/ntp configs ans ssh keys. that is quite easy and helps you a lot to understand the Puppet DSL

every other task afterwards will be easier

yea, that would be a better starting point

and no matter how dump a question might look, ask it anyways

in your case, nodesource is already configured by the nodejs class, you just need to tell it what version you want

<https://github.com/voxpupuli/puppet-nodejs/blob/master/manifests/repo/nodesource/apt.pp>

puppet if flexible so it works in every environment. that means many solutions bring the same result. but learning to digferentiate between the easy and tricky solutions takes a but of time and feedback. so starz with the easy stuff to learn the basics

and understand that the learning curve is steep, so take your time and get your footing

Thanks for the suggestions <@U1PC2RAH0> I feel like I do understand some of the basics, but unfortunately I'm tasked with getting this app deployed and need to use Puppet. :confused:

<@U020LK7D0JU> I took the `exec` part out of the install.pp file and still get the same error

is there a reason for using puppet apply? is that usually used in that environment or do you just use it for tests?

for testing...so I don't have 1400 git commits in my branch to  push up and test :smile:   Was hoping to test some of this locally

if the puppet agent is usually used, stick to it

usually for testing you branch your control repo and use `puppet agent --environment` to run that branch's code

there is probably a bunch of stuff comfigured via puppet and during your tests your are only using a fraction of it, that can lead to side effects

yes, but I don't want a ton of commits for me learning this stuff.  I'd like to reduce the noise that others see on the repo.

is there anyone in your org with puppet experience that you could partner with for learning? (this seems like bad managerial practice to throw someone under the bus like this)

so, I recommend making a branch and then squashing the commits before PR

do you have your own test branch/environment?

<@U020LK7D0JU> yes I planned on doing that...but still didn't want to have all the commits out there for every little typo/thing I try

it's good to have the history of your attempts

people call me principal automation architect and I can probably produce 200 commits with typos a day, not on purpose

as long as the git server doesnt burn under the load thats totally fine :D

OK, I guess I can try this particular code via pushing it up to the branch and let Foreman do it's thing...but I will be back if I get the same error there too :wink:

when running apply locally you usually need to do something like this.

```# cwd should be your control repo
# populate upstream modules
r10k puppetfile install
# run puppet. You might need to specify something other than site.pp
# depending on how you're classifying nodes
sudo puppet apply manifests/site.pp --modulepath=modules/:site/ --hiera_config=hiera.yaml -tv```

big caveat on the above is that it almost never works in large environments with facts, ec2 tagging, ENC/foreman, etc. However you can make a test.pp in place of the site.pp to load just a module or two if you're still in the process of learning Puppet.

<@U12006DC1> That's what I did, but got the error I mentioned above.  What I'm trying to test now, shouldn't be pulling any custom vars from Foreman or anything...and I've already installed the modules via `r10k` and specified the `--modulepath` on the cli...as well as setting that in the `environment.conf` file

OK, well. it actually worked when I pushed it up to the branch and ran it via `agent/Foreman`   Thanks for all of your help! <@U020LK7D0JU> <@U1PC2RAH0>

Could a parameter that results in an array be used to create multiple hiera levels?

hiera interp has to return string or something that can be munged to string iirc

Wanted to do data overrides that could exist in something like `&lt;stage&gt;.yaml` when `stage`  is an array

We have something in our ENC generator that creates `class::params` parameters that differ on an internal named stage presently not exposed via name to puppet. There can be more than one of these things, though. I was hoping to move the stuff into hiera.

And the parent classes are often `include` d

is there a limit to the number of stages?