I'm finding similar behaviour to the user in this post
https://groups.google.com/forum/#!topic/foreman-users/4BXH0rp3COc
However I am running foreman with the ':unattended: false' in settings.yaml
disabling unattended provisioning (i.e. just using foreman to manage
puppetmaster). Therefore I don't have any templates.
Firstly if I delete a host, the puppet certs stay around, so if the client
is still out there the next puppet run recreates the host in foreman.
Secondly if I also delete the certs using either the web GUI or 'puppet
cert clean fqdn' then the client can still connect. This means the host
gets recreated but now doesn't have a cert.
Subsequently restarting apache removes the cached certificate and the
revocation is honoured correctly.
My questions are:
How do I link the host and it's cert so deleting the host properly clears
the puppet cert?
How do I make the certificate revocation propagate correctly to foreman
without having to restart apache each time?
Cheers,
Matt
> Firstly if I delete a host, the puppet certs stay around, so if the client
> is still out there the next puppet run recreates the host in foreman.
>
This is odd, but it does depend on your Foreman configuration. Just for
sanity, can you confirm the host you're deleting has it's puppet CA proxy
set to the correct puppetmaster, and that the :manage_puppetca Setting is
set to true in the UI Settings? Both of those are required to trigger the
certificate orchestration.
> Secondly if I also delete the certs using either the web GUI or 'puppet
> cert clean fqdn' then the client can still connect. This means the host
> gets recreated but now doesn't have a cert.
>
> Subsequently restarting apache removes the cached certificate and the
> revocation is honoured correctly.
>
That sounds potentially buglike, although confirming your setup and
clearing up the first point will allow us to be sure.
···
On 24 February 2016 at 02:13, Matt Cahill wrote:
>
>
>> Firstly if I delete a host, the puppet certs stay around, so if the
>> client is still out there the next puppet run recreates the host in foreman.
>>
>
> This is odd, but it does depend on your Foreman configuration. Just for
> sanity, can you confirm the host you're deleting has it's puppet CA proxy
> set to the correct puppetmaster, and that the :manage_puppetca Setting is
> set to true in the UI Settings? Both of those are required to trigger the
> certificate orchestration.
>
Thanks Greg, I can confirm both the host configuration and the UI setting
are correct. I toggled the managed puppet ca setting in the UI just to be
sure. The host is inheriting it's config from a host group, but I get the
same result if I set it explicitly.
> Secondly if I also delete the certs using either the web GUI or 'puppet
>> cert clean fqdn' then the client can still connect. This means the host
>> gets recreated but now doesn't have a cert.
>>
>> Subsequently restarting apache removes the cached certificate and the
>> revocation is honoured correctly.
>>
>
> That sounds potentially buglike, although confirming your setup and
> clearing up the first point will allow us to be sure.
>
I'll turn on debug logging and see if anything interesting turns up during
the delete request and post it here.
cheers
Matt
···
On Thursday, 25 February 2016 06:19:51 UTC+13, Greg Sutcliffe wrote:
> On 24 February 2016 at 02:13, Matt Cahill > wrote:
OK so everything looked pretty normal with no errors.
I could see foreman hit the puppetca proxy and the proxy process the
certificate delete when I explicitly told foreman to from the certificates
page.
Nothing logged at all when deleting the host though. So it looks like
foreman isn't trying to do anything foreman-proxy related during that
process.
I did notice this in the production log though (this is the
default_host_group plugin checking if a host is new or not):
2016-02-25T15:56:41 [app] [D] not found: Couldn't find Host::Managed with
id=slimjim.wetafx.co.nz [WHERE "hosts"."type" IN ('Host::Managed')]
2016-02-25T15:56:41 [app] [I] Completed 404 Not Found in 14.6ms
(ActiveRecord: 2.5ms)
which got me thinking. What if the host needs to be of type 'Host::Managed'
for the puppetca management to work?
There is no way to set this for a host when :unattended: is false though so
I set it to true, restarted and set the host to managed.
Low and behold the cert now gets removed correctly.
I, [2016-02-25T16:52:11.596125 #270] INFO – : cleaned puppet certificate
for slimjim.wetafx.co.nz
I, [2016-02-25T16:52:11.596869 #270] INFO – : 172.17.0.1 - - [25/Feb/2016
16:52:11] "DELETE /puppet/ca/slimjim.wetafx.co.nz HTTP/1.1" 200 - 1.5531
I, [2016-02-25T16:52:11.799523 #270] INFO – : Attempt to remove
nonexistent client autosign for slimjim.wetafx.co.nz
E, [2016-02-25T16:52:11.799871 #270] ERROR – : Attempt to remove
nonexistent client autosign for slimjim.wetafx.co.nz
I, [2016-02-25T16:52:11.800246 #270] INFO – : 172.17.0.1 - - [25/Feb/2016
16:52:11] "DELETE /puppet/ca/autosign/slimjim.wetafx.co.nz HTTP/1.1" 404 70
0.0014
So I think this is probably a bug/deviation from expected behaviour.
This unfortunately did not affect the cert caching behaviour though.
additionally just setting managed = true for a host doesn't provide a work
around when unattended = false. I set that with the following api call:
curl -XPUT --basic -u "user:pass" -H "Content-Type: application/json" -d
'{"managed":true}' -k https://foreman.example.com/api/hosts/FQDN
cert removal only seems to happen when foreman is in unattended mode. A
diff of the host config between different modes shows only these attributes
are different
'{"managed":true,"build_status":0,"build_status_label":"Installed"}'
but the two build attributes refuse to be set in unattended mode.
