Puppet Community

Hello, can this channel be used for simple questions? :slightly_smiling_face:  how I can use hiera variables in package resource title?

I have to define it on class? like 'String $etcd_package_name = $kubernetes::etcd_package_name'

Hiera data can be pulled into a manifest in two ways.  You can use the `lookup()` function, or you can have the compiler do it with automatic paramter lookup (APL).  The latter is the recommended way to do it.  So if you have a class foo defined like so:
```class foo(
  String $bar,
) {
  package { $bar: }
}```
You would set `foo::bar` in hiera, and then it would automatically be bound to the class parameter.

If you want to use `$foo::bar` in another classs, you have to make sure `foo` is loaded before hand:
```class baz {
  include foo
  notify { $foo::bar: }
}```

You should minimize those cross-class references, though

like defining all in init.pp like "String $bar" and adding variable to hiera, then use on all classes

is it best practice to use variables like module::class::variable,  module::class2::variable or module::variable is enough?

like defining a shared class of some sort:
```class shared(
  $var1,
  $var2,
) {
}```
and then adding to hieraa:
```shared::var1: 'val1'
shared::var2: 'val2'```
and then include shared in places where you need it?

If you use `lookup()` function, you have to provide the exact key that is used in the hiera yaml file.

If you use automatic parameter lookup, then the key is based on the class name.  So if you had a class `my_module::foo’ that was in `modules/my_module/manifests/foo.pp`, you would set its paramters in hiera. by using the key: `my_module::foo::parameter1`, `my_module::foo::parameter2`

Folks frequently trip over the fact that the only integration between the puppet language and hiera is the automatic parameter lookup.  That is kind of “magic” in that if you name your hiera keys appropriately, they will bind to class paramters.  Other than that, it’s a completely separate thing, and there is no way to access the values without doing an explicit `lookup()`

I see thank you, currently I add variable in hiera like "module::parameter" , and on init.pp add "String $parameter" and then I am able to use it in any  class. with "$module::parameter", should care about "module::class::parameter" for best practices?

it is like global and class level parameters? like in programming?

The reason you use `module::paramter` is because `init.pp` contains the class named `module`.  If you put a class in a file in the same directory as `init.pp` named `foo.pp`, you would need to define a class named `module::foo` and then hiera keys would need to be `module::foo::paramter`

When you do `include mmodule` in puppet, it looks in your modulepath for a directory called `module` and then iniside the `manifests` subdirectory for a filed called `init.pp` to load `module` class

ah, I see.  yeah, just add `include foo` at the bottom of `init.pp`

also please use a file resource or the archive module to download stuff, not an exec resource

I think so.  the pluginsync grabs everything, I think

if a module contains facts, yes they will plugin sync to all nodes, typically you would use confinement in the fact itself, to make sure it only executes on a valid node

so if your modules facts should only work on linux nodes and not windows, the fact would confine to the linux kernel

can you do confinement in external facts?  I guess you can just have them bail early and set an empty value

yeah so shebang lines  or known file extenstions is what limits those across platforms

<https://puppet.com/docs/puppet/7/external_facts.html#external_facts-executable-facts-unix>

if a module contains facts, yes they will plugin sync to all nodes, typically you would use confinement in the fact itself, to make sure it only executes on a valid nodes

I am not aware of a list, but certainly may exists. The tricky part is that puppet tends to be an infrastructure automation tool so a lot of open source projects don't dictate how you install or configure them, that part is left up to the user.

it looks like the provided parameters to rpm are not correct

is that an open source module? can you share the code?

# Uninstall package majix-centrify
  package { 'majix-centrify' :
    ensure            =&gt; absent,
    #provider          =&gt; rpm,
    alias             =&gt; 'CentrifyDC-5.8.1-371.x86_64',
    #name              =&gt; 'majix-centrify',
    uninstall_options =&gt; ['--nodeps --noscripts'],
  }

try `uninstall_options =&gt; ['--nodeps', '--noscripts',],`

I tried manualy the "rpm -e --nodeps --noscripts CentrifyDC-5.8.1-371.x86_64" and it worked well...

I'l try the  uninstall_options =&gt; ['--nodeps', '--noscripts',],  and let you know...

Error: /Service[centrifydc]: Failed to call refresh: Systemd restart for centrifydc failed!
journalctl log for centrifydc:
-- Logs begin at Fri 2022-04-08 11:26:18 CEST, end at Fri 2022-04-22 16:49:57 CEST. --
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local adclient[19922]: INFO  &lt;main&gt; daemon.main adclient terminating
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local systemd[1]: Stopping CentrifyDC adclient daemon for AD services...
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local adclient[19922]: INFO  &lt;main&gt; base.adagent agent shutting down
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local adclient[19922]: INFO  &lt;main&gt; base.adagent ===Agent shutting down===
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local adclient[19922]: INFO  &lt;main&gt; base.adagent ===Agent shut down===
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local adclient[19922]: INFO  &lt;main&gt; subsystem.health System health history cleared
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local systemd[1]: Stopped CentrifyDC adclient daemon for AD services.
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local systemd[1]: Starting CentrifyDC adclient daemon for AD services...
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local systemd[1]: centrifydc.service: control process exited, code=exited status=203
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local systemd[1]: Failed to start CentrifyDC adclient daemon for AD services.
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local systemd[1]: Unit centrifydc.service entered failed state.
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local systemd[1]: centrifydc.service failed.

Error: /Service[centrifydc]: Systemd restart for centrifydc failed!
journalctl log for centrifydc:
-- Logs begin at Fri 2022-04-08 11:26:18 CEST, end at Fri 2022-04-22 16:49:57 CEST. --
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local adclient[19922]: INFO  &lt;main&gt; daemon.main adclient terminating
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local systemd[1]: Stopping CentrifyDC adclient daemon for AD services...
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local adclient[19922]: INFO  &lt;main&gt; base.adagent agent shutting down
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local adclient[19922]: INFO  &lt;main&gt; base.adagent ===Agent shutting down===
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local adclient[19922]: INFO  &lt;main&gt; base.adagent ===Agent shut down===
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local adclient[19922]: INFO  &lt;main&gt; subsystem.health System health history cleared
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local systemd[1]: Stopped CentrifyDC adclient daemon for AD services.
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local systemd[1]: Starting CentrifyDC adclient daemon for AD services...
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local systemd[1]: centrifydc.service: control process exited, code=exited status=203
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local systemd[1]: Failed to start CentrifyDC adclient daemon for AD services.
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local systemd[1]: Unit centrifydc.service entered failed state.
Apr 22 16:49:57 opgspu-udovm041.main.glb.corp.local systemd[1]: centrifydc.service failed.

adinfo returns this: "adinfo
Local host name:   opgspu-udovm041
Joined to domain:  main.glb.corp.local
Joined as:         opgspu-udovm041.main.glb.corp.local
Pre-win2K name:    opgspu-udovm041
Current DC:        maifrpau01-dw02.main.glb.corp.local
Preferred site:    FRPAU01
Zone:              main.glb.corp.local/Shared/CENTRIFY/Zones/Unix-Servers
CentrifyDC mode:   down
Licensed Features: Enabled"

Instead of:
# adinfo
Not joined to any domain
Licensed Features: Enabled

I have to leave and I'll work on it next monday. Many thanks for your help and have a nice week-end.

From those logs, I’d guess your `rpm -e` was successful and removed the package. But, there’s still a `Service[centrifydc]` resource in that node’s configuration that failed because components are now removed.

Note, i'm new using puppet... :slightly_frowning_face:

“don’t use exec” is common advice you’ll see, but it is very over-simplified. `exec` has some trade-offs that should be considered carefully in order to get something reliable and predictable.

In this case, it depends on what the post installations commands do, what sort of state they leave behind, and if they only need to run after the first install, or need to run after every upgrade.

exactly, use an exec if there isnt any alternative. have a preference for more puppet like way of doings things, but sometimes exec is the only way

Its an one time command that I need to execute.

but using exec, my puppet code is always running the command for every run...

then just ensure you have a reliable way to limit the running of the command via `creates`, `unless` , `onlyif`

Eh. Use exec if there isn’t a _better_ alternative.

Sometimes there are alternatives that are worse/inefficient and people will spend a lot of time trying to make them work because they “heard exec was bad and a tool of last resort” :wink:

sweet, let me explore those options.  Thank you so much,

what kind of command is it? sometimes those create just a file or change permissions, thats stuff pupprt can do natively

ya, that is a better way to put it, would you look at that, the nuanced way of approching things is the correct way. it isnt always black or white

my rule for myself is that all execs must have 1 of
```creates
unless
onlyif```


now that works for me, but may not work for everyone

of course a type/provider is nice, or a proper deb/rpm package that does the command or software that doesnt need it nice. but implementing those takes a lot of time thats often not worth it

The main drawbacks of `exec` are:

• You have to bring your own logic for making the exec idempotent so that Puppet doesn’t execute it every 30 minutes when it doesn’t need to.
• Execs are fairly opaque. Puppet can only report whether the `exec` ran or was skipped and whether it exited with 0 or another status that is accepted as success.
Specialized types, like `file`, are usually better for specific tasks because they have standardized logic for idempotency and can tell you more about what changed (`owner` became `nfsnobody`, `mode` became `0600`, etc.)

this command connects the client to the centralized server. It comes part of the package

That could be something that a type+provider could manage. But, if noone has written a module that implements a type+provider for this particular software, then an `exec` is a perfectly reasonable starting point. As Jason noted, `creates`, `unless`, `onlyif` should be used to make sure the “connect” command doesn’t run if the client is already connected.

Thank you all for your responses. Much appreciated!

And, if “connected” just means “has a configuration file with connection details”, then this is something that `file` could manage unless there’s some unique state that the command has to negotiate.

its stored as a binary after the command is executed

Yeah. Something has to wrap that command then. `exec` with `creates =&gt;` pointing to the generated binary blob is pretty simple and might be enough.

cool. not sure if any of use crowdstrike, worst implementation I think :disappointed:

Don't know if it's relevant, but a quick Forge search does have a "falcon" module that's authored by crowdstrike.  Have you take a look at that to see if it fits the bill?

<https://forge.puppet.com/modules/crowdstrike/falcon>

Thank you all for your useful tips. 'unless' worked in my case.

your agent doesnt resolve the hostname `puppet`

use --server and provide the fqdn from the server

<https://puppet.com/docs/puppet/7/configuration.html#server|https://puppet.com/docs/puppet/7/configuration.html#server>

Yeah, `puppet` is the default hostname that the agent tries to find a server at. You’ll get that error if there’s nothing in local DNS to resolve `puppet` to an IP address (which is common). The `puppet config` subcommand is helpful for re-configuring that behavior in `puppet.conf`:

```puppet config set server &lt;hostname of your puppet server&gt;```

hey <@U11MDJNGZ> thank you for your answer. I am currently configuring it with <@U1PC2RAH0>. Again, thanks so much!

I will never be able to keep in my head which setting goes into which section in the config :D

did you already write some code we can help you with?

exec { "remove file":
        path    =&gt; ['/usr/bin','/usr/sbin','/bin','/sbin'],
        command =&gt; "rm /etc/securetty",
}

Is this the right way to delete file through puppet?

<https://puppet.com/docs/puppet/7/types/file.html#file-attribute-ensure>

the file resource type has the `ensure` atribute. that takes one of the following values `file`, `directory`, `absent`.

```file { '/etc/securetty':
  ensure =&gt; 'absent',
}```

that will ensure that the file doesn't exist

and if you want to only do that on red hat you can wrap a fact condition around it

```if $facts['os']['name'] == 'RedHat' and $facts['os']['release']['major'] == 7 {
  file { '/etc/securetty':
    ensure =&gt; 'absent',
  }
}```

Not sure whom should I mention to say that <https://pup.pt> is refusing connections:
```➜  ~ curl <https://pup.pt> 
curl: (7) Failed to connect to <http://pup.pt|pup.pt> port 443: Connection refused```

Most of `*blog.js` JS files returns 404...

Actually not pictures but source code blocks are missing it seems..

I feel like using global variables for all classes is way simple , does it have big disadvantages?

If data is needed by two classes, you should place the data in hiera.

Toi prevent duplicate data declaration you can then use the interpolated lookups in hiera <https://puppet.com/docs/puppet/7/hiera_merging.html#interpolation_functions>

I do, I use hieara. The question is about global and class level hiera variables.

so, I should place variables on class level as much as I can and if I need it in another class use lookups?

You can add parameters to a class. Puppet will query hiera for any class parameter.

```class foo (
  String $server,
){
  # ...
}

class bar (
  String $server,
) {
  # ...
}```

I believe I did explain my self well, let me explain in detail

```foo::server: "%{lookup('default_server')}"
bar::server: "%{lookup('default_server')}"
default_server: 'servername'```

well, the last shared snippet from hiera yaml? I mean like common.yaml?

the thing is this data going to be same all the time, is it best practice to have these multiple lines for just one parameter?

Yes. this allows you to be independent in terms of class foo and bar usage.

I usually try to prevent to combine two independent classes by referencing their data. This makes it super hard to debug.

Whenever we need the same data multiple times, we use the hiera interpolation

just keep in mind that lookup will return a string. if you need other data you should use alias instead.

A lot of it depends on what you're looking to use the data for, puppetdb's not extremely heavy on the db side unless you are doing a whole lot of querying (it's a few transactions a puppet run basically)

better than any tuning is probably running a modern postgresql version. the postgres people provide their own apt/rpm repos and I highly recommend using that. if you combine that with a host that has SSDs, the majority of your issues should fade away. if it's still slow, check out pg_tune. it can recommend tuning settings. if it's afterwards still slow please let us know because now it gets interesting :smile: