I would like some advice/comments on technique/style design decisions that I'm facing with implementing Puppet. I'm using the roles/profiles methodology and I've got a hiera hierarchy that is: - nodes/%{trusted.certname}.yaml - applications/${application}.yaml - os/%{facts.os.family} - common.yaml I'm using the heck out of the hiera hierarchy and it's working well. For example, in the common.yaml file I have all of the RPM GPG keys that are needed for each server (such as my company's internal RPM GPG signing key) but in data/os/os.family I have two files, 'RedHat.yaml' and 'OracleLinux.yaml' that contain needed keys for the respective OS. Of course, I don't need Oracle GPG keys in the Red Hat servers and vice-versa. My design conundrum is with the application hierarchy. I have an in-house application called, 'Brooklyn' that requires additional parameters passed to the SSH, logrotate, file, etc. Those parameters are already in a data/application/brooklyn.yaml and are being applied as desired. The Brooklyn application requires that files and directories get created based on other facts. The files and directories need to be upper-cased versions of those facts such as /mnt/brooklyn/TOYOTA/111. Since there's not a way to apply 'upcase' to hiera values in the yaml files (or is there?) do I keep all non-edge case hiera parameters in the data/application/brooklyn.yaml file or do I move everything into a new module called 'puppet-brooklyn'? In addition, I've created some custom facts that will uppercase the customer (in this case 'toyota') so that I don't have to write a file resource:

$customer = $my_customer.upcase

file {"/mnt/${customer}":  ensure => directory}

vs:

$customer = $fact{'application.customer'}

file {"/mnt/${customer}": ensure => directory}

that upper-cases the customer name. That seems like I'm obfuscating things even more, however it does solve all of my issues. I keep going back and forth on the design of this module. About 95% of what's already in the data/application/brooklyn hierarchy works fine. It seems silly to me to move all of that stuff into the puppet-brooklyn module just to take care of the edge case (ie: upper-case naming) but it also seems silly to have my 'brooklyn' data in two places. Every time I start moving my hiera stuff to my brooklyn application I question why I'm doing so because 95% of the existing hierarchy is already working perfectly. Any comments or suggestions are highly appreciated!

Hi @vchepkov , if now my

testfile

in that example below is a F*function*. How should I formulate. I tried several ays and puppet-lint still complains about “Could not parse for environment root: Syntax error at ‘test’ should be something like this ?

content => testfile${test},

Hi @vchepkov , if now my

testfile

in that example below is a Function. How should I formulate. I tried several ays and puppet-lint still complains about “Could not parse for environment root: Syntax error at ‘test’ should be something like this ?

content => testfile${test},

Hi @vchepkov , if now my

testfile

in that example below is a Function. How should I formulate. I tried several ays and puppet-lint still complains about “Could not parse for environment root: Syntax error at ‘test’ It should be something like this ?

content => testfile${test},

Also for packaging look up FPM. It can turn a tarball into an RPM or DEB or whatever with just a few pieces of meta data.

This message was deleted.

This message was deleted.

Super simple question: Should you or should you not include hiera data within your puppet modules? Better yet should you leverage the global hiera data for all hiera lookups or leverage module hiera lookups

How to design a good module? assume you give me your modue. A) it has to work for me out of the box B) there should no business data from your comoany be hardcoded

Hi, I am wondering, is it possible to use TLS enabled proxy within puppet? I try to get a resource within a secured environment:

file { '/etc/pki/rpm-gpg/RPM-GPG-KEY-puppet' :
  ensure => file,
  source => '<https://yum.puppetlabs.com/RPM-GPG-KEY-puppet>',
}

Defining the environment variable

http_proxy=<https://PROXY>

works with

curl

, but I don’t have success using the proxy within puppet. It works as expected when I disable the TLS part (and variable

http_proxy=<http://PROXY>

) in my squid proxy, but no success with TLS... Is there something I must enable in the puppet config such as the path of the CA? (My CA is defined systemwide in /etc/pki/tls/cert.pem)

Hi, I am wondering, is it possible to use TLS enabled proxy within puppet? I try to get a resource within a secured environment:

file { '/etc/pki/rpm-gpg/RPM-GPG-KEY-puppet' :
  ensure => file,
  source => '<https://yum.puppetlabs.com/RPM-GPG-KEY-puppet>',
}

Defining the environment variable

http_proxy=<https://PROXY>

works with

curl

, but I don’t have success using the proxy within puppet. It works as expected when I disable the TLS part (and variable

http_proxy=<http://PROXY>

) in my squid proxy, but no success with TLS... Is there something I must enable in the puppet config such as the path of the CA? (My CA is defined systemwide in /etc/pki/tls/cert.pem)

I believe you need to turn a setting to tell puppet to look at the system CA rather then its internal one... and then you'd need to check the java and ruby libraries to see if they support encrypted http proxies (which I am not sure of)

Well, I’ve tried to make my squid proxy listen with the puppet signed certificate (

/etc/puppetlabs/puppet/ssl/certs/xxxx.pem

) without success either... So it does not seems to be a problem of certificate...

ok, thanks, i’ll try that

stupid idea: I think squid cannot listen on https?

the https_proxy env is used to tell thr system to tunnel https requests through the proxy, but the connecion to the proxy is plaintext?

how did you configure the proxy in puppet adn do you want to get only this file via the proxy, or should the agent push all http(s) requests through a proxy?

no, squid listens on 3219 for https if configured, but a LOT of stuff can't deal with talking https to a proxy

curl itself couldn't until quite recently

Yeah, squid can wrap the request over TLS. my squid config:

:~# grep https_port /etc/squid/squid.conf
# fragment for https_port 192.168.56.31:3128
https_port 192.168.56.31:3128 cert=/etc/pki/tls/certs/xxxx.crt key=/etc/pki/tls/private/xxxx.key

we do a LOT of stunnel on localhost to squad on 3129

ah maybe I only dealt with EOL squid in the past :D

I wish I didn't have to deal with squid at all

I wish every box gets a global ipv6 adress and I only need firewalling, no NAT/proxys

I'd be up for it at this point

double natting sucks

yep!

also legacy ip sucks

also I am out of cookies. sucks as well