How would I allow it to be supplied encrypted in the module level hiera?

By defining the key and its encrypted value in hieradata/secrets.eyaml at the environment layer

By defining the key and its encrypted value in secrets.yaml at the environment layer

By defining the key and its encrypted value in secrets.eyaml at the environment layer

Your encrypted secret has to exist in the environment-level

secrets.eyaml

file for it to be decrypted (based on your Hiera config)

Ah ok, it's not possible for the module to inherit the eyaml decryption keys then.

By defining the key and its encrypted value in hieradata/secrets.eyaml at the environment layer

Ah ok, it's not possible for the module to inherit the eyaml decryption keys then.

no… but it doesn’t need to. Also…. remember what I said earlier about where the encrypted data should live. The encrypted data should live at the environment layer. It will be looked up when your module’s class is declared. The data will come from the environment layer, be decrypted by the eyaml backend (assuming it exists in that hierarchy layer), then be sent to your module’s class parameter.

no… but it doesn’t need to. Also…. remember what I said earlier about where the encrypted data should live. The encrypted data should live at the environment layer. It will be looked up when your module’s class is declared. The data will come from the environment layer, be decrypted by the eyaml backend (assuming it exists in that hierarchy layer), then be sent to your module’s class parameter.

I think I had misunderstood, the password value should exist at the environment level rather then encrypted within the module directory.

Correct.

Your eyaml backend is configured at the environment layer. So that means the encrypted data must also exist within that layer.

Ah ok.

That worked, was able to get the encrypted string from the env level hiera, sorry for the misunderstanding and confusion.

That worked, was able to get the encrypted string from the env level hiera, sorry for the misunderstanding and confusion.

All good. Glad it’s working 🍻

Would best practice be to keep values like this in a top level file like common.yaml|common.eyaml or should it be given a more discrete entry to keep the password separate from other configuration files?

Since this password is encrypted, it really doesn’t matter where in the hierarchy it goes. You should put it wherever it makes sense for your hierarchy. If it really is a common value that is used and there isn’t an override, then common.yaml makes sense. What is a best practice is not embedding site-specific data into (what should be) a generic component module. So things like service account passwords should exist in the environment layer data folder. While things like the default name of a package on Ubuntu are more appropriate for the data folder of a module that manages that package.

Since this password is encrypted, it really doesn’t matter where in the hierarchy it goes. You should put it wherever it makes sense for your hierarchy. If it really is a common value that is used and there isn’t an override, then common.yaml makes sense. What is a best practice is not embedding site-specific data into (what should be) a generic component module. So things like service account passwords should exist in the environment layer data folder. While things like the default name of a package on Ubuntu are more appropriate for the data folder of a module that manages that package.

Gotcha! also makes it easier to pass the module off without having to sanitize it were there ever the need.

Exactly. You should be able to give your component module to another team, company, or put it on the internet without fear of exposing secrets. Secrets are for the environment layer.

Hi Puppeteers, When I run puppet agent on a windows server with puppet version 7.10. I get error facts.yaml as legacyFacter:utilparser:YamlParser facts: invalid byte sequence in UTF-8

I have same fact file running on a different server which have 6.19 puppet version

Does the yaml file pass as valid yaml in any sort of linter?

and if you where to get a checksum of the file on the two different platforms does it come back as the same?

Yeah yaml file is valid with right facts info

Hi, I don't find the correct way to do what I want. if someone has an idea, I will take it 🙂 So I have this class :

class { 'mysql::server':
    config_file             => $config_file,
  }

In most case, config_file is undef and must be undef. But, I want in my code to do something like :

if $version == '106' {
  $config_file = '/usr/local/etc/mysql/my.cnf'
}

The best way would be to do something like :

config_file = pick($config_file_override, undef)

but pick can't take undef as default value. If someone know a better method, I will be really happy to listen it

This message was deleted.

What type do you expect the “$config_file_override” to be? I assumed it was a String since it is used as a config file name. In that case (since you want to use selector: You can do like this

$config_file = $config_file_override ? {
  String[1] => £config_file_override,
  default.  => undef