You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following the process to import generated certs only works if migrating from a legacy puppet ca since all the certs live in /etc/puppetlabs/puppet/ssl/ca/. New puppetserver ca cert location is /etc/puppetlabs/puppetserver/ca with /etc/puppetlabs/puppet/ssl/ca being a symlink to the new location.
if you tar up /etc/puppetlabs/puppet/ssl/ on a "new style" puppetserver ca, it will either only include the ca symlink, or dereference it and include the ca folder with all it's contents, but that will cause the referenced script to fail: Running /docker-entrypoint.d/90-ca.sh Error: Existing file at '/etc/puppetlabs/puppetserver/ca' Migration will not overwrite the directory at /etc/puppetlabs/puppetserver/ca. Have you already run this migration tool? Is this a puppet 7 installation? It is likely that you have already successfully run the migration or do not need to run it.
This means that it is impossible to import modern ca via the helm chart.
Describe the Solution You Would Like
Adding another configuration option to import puppetserver ca style certs. This seems to the most straight forward solution and should be able to be implemented without breaking any existing functionality.
Describe Alternatives You've Considered
Possible alternatives to this solution could be:
Account for this somehow in the puppet-preinstall.job template, potentially trying to figure out if the ca directory is legacy or modern and move it/create symlinks if it is modern, if it's legacy the puppetserver container will handle the migration.
Account for this in the puppetserver container, but it feels more like it should be handled in the helm chart, since it is directly related.
Account for this in a custom docker entrypoint, but this will not work because the container will never reach them because the 90-ca.sh script will fail and exit the container before the custom entrypoints have a chance to finish running.
Fix by hand by mounting both ca and puppet PVC's and migrating the ca directory manually.
Fix puppetserver ca migrate to detect when modern ca structure exists and fix up the directories. This solution again doesn't seem appropriate for the scope of this.
Additional Context
Would love any other alternative solutions!
The text was updated successfully, but these errors were encountered:
i would also argue that given that Puppet 6 is now EOL we could likely drop support for legacy folder structures and just import with the proper structures in place which to me looks like
update the preinstall job to also mount the ca PVC in the correct place
Use Case
Following the process to import generated certs only works if migrating from a legacy puppet ca since all the certs live in
/etc/puppetlabs/puppet/ssl/ca/
. New puppetserver ca cert location is/etc/puppetlabs/puppetserver/ca
with/etc/puppetlabs/puppet/ssl/ca
being a symlink to the new location.The reason it works for the legacy ca is because of this: https://github.com/voxpupuli/container-puppetserver/blob/a84fc0c23e936febb184f9b5c94c2a194be78dd5/puppetserver/docker-entrypoint.d/90-ca.sh#L70
if you tar up
/etc/puppetlabs/puppet/ssl/
on a "new style" puppetserver ca, it will either only include theca
symlink, or dereference it and include theca
folder with all it's contents, but that will cause the referenced script to fail:Running /docker-entrypoint.d/90-ca.sh Error: Existing file at '/etc/puppetlabs/puppetserver/ca' Migration will not overwrite the directory at /etc/puppetlabs/puppetserver/ca. Have you already run this migration tool? Is this a puppet 7 installation? It is likely that you have already successfully run the migration or do not need to run it.
This means that it is impossible to import modern ca via the helm chart.
Describe the Solution You Would Like
Adding another configuration option to import puppetserver ca style certs. This seems to the most straight forward solution and should be able to be implemented without breaking any existing functionality.
Describe Alternatives You've Considered
Possible alternatives to this solution could be:
Additional Context
Would love any other alternative solutions!
The text was updated successfully, but these errors were encountered: