On the host show page a user with the proper permissions sees a shell command that can be executed on the particular host to enroll the host with Foreman. The shell command is a curl http://foreman.example.com/template | bash style of command. The magic url contains a JWT so this process is pretty secure and we can safely verify the identity of the host.
The plugin registers a new template kind, the registration template which is supposed to be a shell script that does the heavy duty. This template is rendered when the magic url is accessed.
This can be used to
install puppet on a new host, setup puppetca certificates, run puppet so facts are uploaded
setup credentials so the host can be accessed by foreman for remote execution / ansible / a finish script
register the host for content stuff
The sky is the limit. Our powerful templating engine should support a lot more use cases. Any more ideas?
I was told that there is similar functionality in Katello that allows to add an existing host to Foreman. Can we combine these features?
I’ll file a PR to move the code to core so we can review & merge it using our standard workflow.
If the host is already “registered”. But how can we detect this? Can we assume this when the host was provisioned via foreman?
We could hide the tab if no registration template is assigned to the host.
Yes. The registration template is associated to the host like any other template and can be previed using the common functionality.
We don’t. The registration script could set this up. I believe katello provides the CA used by foreman as an rpm. We could just provide it at some URL and enhance the command to download it, verify it using a checksum and make curl use it to verify the https connection. But I think that’s something for a follow-up PR.
In downstream we could probably change the template to use bootstrap.py.
One interesting concern is situations where the clients can’t reach the Foreman instance itself. When the smart proxy templates feature is used then maybe that could be leveraged
Before host detail page tabs get crowded, does this make sense to move somewhere else on the page to save the tab for something other? Just an idea, overall I am pro.
We need to allow Katello to override this page so extension point would be probably a good idea.
We would need to add more extension points to the page. Personally, I‘d like to use the space currently allocated to the useless puppet charts. But that’s too much work for now, so I believe it won’t happen.
I was thinking something very similar, but different. If there’s no reports then we show the registration snippet. It may still make sense to always show the tab even after.
I had the same idea, but I’m wondering if this assumes too much. Can you think of cases where reports are present and a user wants to run the enrollment steps? If the host has puppet/ansible setup, a user will probably leverage these techniques to e.g. register the host to katello instead of copying some command manually to the host’s shell.
The template used for the registration can be anything. bootstrap.py looks quite powerful, but has a lot of options. I think we can help users here by creating a template in foreman, that sets up bootstrap.py and it’s prerequisites and then executes bootstrap.py with the correct parameters.
That should be doable. We could move the enrollment endpoint to be another action of the unattended controller and smart-proxy’s template feature should work out of the box.
