Open Stack

On Tue, Mar 27, 2018, at 5:12 PM, Bernd Bausch wrote:
> Resending this message because it was too large for the distribution list.
> 
> -------
> 
> Clark,
> 
> My first test uses this local.pp. It's copied verbatim from [1]:
> ~~~~
> # local.pp
> class { 'openstack_project::etherpad':
>   ssl_cert_file_contents  => hiera('etherpad_ssl_cert_file_contents'),

This is the public portion of ssl certificate use to run an https server. It includes the BEGIN and END CERTIFICATE lines of the cert file contents and everything in between.

>   ssl_key_file_contents   => hiera('etherpad_ssl_key_file_contents'),

This is the portion portion of ssl certificate use to run an https server. It includes the BEGIN and END PRIVATE KEY lines of the cert file contents and everything in between.

>   ssl_chain_file_contents => hiera('etherpad_ssl_chain_file_contents'),

This is the chain of certificates needed to trust the certificate (if required, not all certs will have this).

>   mysql_host              => hiera('etherpad_db_host', 'localhost'),
>   mysql_user              => hiera('etherpad_db_user', 'etherpad'),
>   mysql_password          => hiera('etherpad_db_password','etherpad'),
> }

In the case of using built in snakeoil certs on ubuntu you can just provide the ssl_key_file and ssl_cert_file values and rely on the contents being already in those files to make this simpler rather than going and getting a certificate. However you could also use something like Let's Encrypt to get the certificates and set their content above.

Example of using snakeoil certs at https://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/etherpad_dev.pp#n12

> ~~~~
> The commands I run are also verbatim from the same page:
> ~~~~
> # ./install_puppet.sh
> # ./install_modules.sh
> # puppet apply -l /tmp/manifest.log --modulepath=modules:/etc/puppet/modules 
> manifests/local.pp
> ~~~~
> 
> My second test closely follows [2]. Here, I take the puppetmaster's original 
> site.pp, adapt the domain "openstack.org" to my domain at home and remove all 
> node definitions except puppetmaster and etherpad. My file is at the end of 
> this message[4].
> 
> The commands:
> ~~~~
> # ./install_puppet.sh
> # ./install_modules.sh
> # vi site.pp                                          # see [4]
> # puppet 
> apply --modulepath='/opt/system-config/production/modules:/etc/puppet/modules' 
>  -e 'include openstack_project::puppetmaster'
> ~~~~
> 
> > Generally though hiera is used for anything that will be secret or very site 
> > specific. So in this case the expectation is that you will set up a hiera 
> > file with the info specific for your deployment (because you shouldn't have 
> > the ssl cert private data for our deployment and we shouldn't have yours).
> > This is likely a missing set of info for our docs. We should add something 
> > with general hiera setup to get people going.
> 
> Yes. The documentation seems to treat the hiera as a given; it just exists, 
> and there doesn't seem to be any information about its content or even whether 
> it's really required.
> Once I know the issues and technology better (steep learning curve), I'd be 
> happy to write documentation from the perspective of a newbie.
> For now, let me do more testing with hardcoded values rather than hiera. I 
> certainly learn a lot doing this.
> 
> > Unfortunately I don't remember off the top of my head how to set up a hiera 
> > so I will have to dig into docs (or maybe someone else can chime in with 
> > that info).
> 
> In principle, I can do that (for Puppet 4 at least), but the question is what 
> goes into the OpenStack CI production hiera. I see a directory 
> /opt/system-config/production/hiera [3] - is that it? It doesn't contain 
> anything about Etherpad, though. I also did a codesearch for 
> "etherpad_ssl_cert_file_contents", no result (except for the site.pp).

This is the public hiera which lives in the system-config repo itself. We can put content in there that is safe to share publicly but may still need to be customized by downstream deployments. Unfortunately because we can't share our private hiera content that data remains harder to share and will in many cases be manifest dependent. Your private hiera should live elsewhere in the hiera lookup path. I believe ours lives in /etc/puppet/hieradata/production.

One approach we may want to take is go node by node in site.pp and try to provide descriptions for the content of each hiera lookup used (or when there are logical groups of hiera lookups descriptions for that group). That will hopefully make it more clear what the data is without needing to divulge the actual sensitive informtation.

I hope this helps. Sorry I didn't respond sooner, have been traveling and attending a conference.

> 
> Thanks much, Clark!
> 
> Bernd
> ---
> [1] 
> https://docs.openstack.org/infra/system-config/sysadmin.html#making-a-change-in-puppet
> [2] https://docs.openstack.org/infra/system-config/puppet.html
> [3] 
> https://git.openstack.org/cgit/openstack-infra/system-config/tree/hiera
> [4] My site.pp: