- Creation of a local directory containing self signed certificates
- In the vm template, Configure the puppet agent to expose a le_certs directory
- mount the local directory into the the vm via the vagrant configuration
- add a script to easily generate a self signed certificate as certbot would have done
Details
Details
- Reviewers
ardumont - Group Reviewers
Reviewers - Commits
- rSENVa2e6095f38b9: vagrant: simulate the behavior of the puppet master for the ssl certificates
Diff Detail
Diff Detail
- Repository
- rSENV Puppet Environment
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
| Vagrantfile | ||
|---|---|---|
| 15 | in another diff on vagrant, i renamed it explicitely local_debian... ;) | |
Comment Actions
Thanks.
Couple of questions below.
If i'm understanding this correctly, this will allow us to generate self-signed certificates when we want to create a service in our stack that needs a certificate.
Just generate it with the script within (generate-certificate) and commit into this repository.
Then trigger back the vagrant provisision <vm-with-desired-service>.
Then everything should run smoothly within that provision step.
correct?
Another question is i'm just wondering whether it should be named netbox-vagrant instead of netbox given what we have in the defaults.yaml [1]
Comment Actions
Yes exactly, it's correct. It remains only the icinga part to remove the last errors during the provisioning. I still haven't a simple way to do it as it uses a certificate named with the vm's fqdn and should be generated after the vm creation if we want it to be automatised.
Another question is i'm just wondering whether it should be named netbox-vagrant instead of netbox given what we have in the defaults.yaml [1]
good remark. There must be a mistake somewhere on this override of this property as when I provision the vm locally, it searches for netbox. I will remove this declaration because it's not necessary and it will allow to remove a property for vagrant on the defaults.yaml file.
| Vagrantfile | ||
|---|---|---|
| 15 | they can, the last one wins :). The goal is to be limit the changes when you want to test a fresh image. | |
Comment Actions
If i'm understanding this correctly, this will allow us to generate self-signed certificates when we want to create a service in our stack that needs a certificate.
Just generate it with the script within (generate-certificate) and commit into this repository.
Then trigger back the vagrant provisision <vm-with-desired-service>.
Then everything should run smoothly within that provision step.
correct?Yes exactly, it's correct.
great!
It remains only the icinga part to remove the last errors during the provisioning. I still haven't a simple way to do it as it uses a certificate named with the vm's fqdn and should be generated after the vm creation if we want it to be automatised.
beats me. But i'm not sure i understand the issue.
Maybe some paste could clarify this?
Another question is i'm just wondering whether it should be named netbox-vagrant instead of netbox given what we have in the defaults.yaml [1]
[1] https://forge.softwareheritage.org/source/puppet-swh-site/browse/production/data/defaults.yaml$820-822good remark. There must be a mistake somewhere on this override of this property as when I provision the vm locally, it searches for netbox. I will remove this declaration because it's not necessary and it will allow to remove a property for vagrant on the defaults.yaml file.
Well, I think this is within the scope of issues that will be solved with D4147 (providing the right configuration is declared within the environment "staging", location "vagrant").
Cheers,
Comment Actions
lgtm
I think the other problematic part with icinga can be dealt with in another diff.