Is it normal for puppet to fail on the first run?

Icinga 2 Automation & Infrastructure
,
1

Hi everyone,

Everytime I run puppet I get the following error for invalid key:

Notice: /Stage[main]/Icinga2::Feature::Api/Exec[icinga2 pki request]/returns: critical/cli: !!! Invalid ticket for CN 'agentl3.cern.ch'.
Error: '"/sbin/icinga2" pki request --host winmonit-m01.cern.ch --port 5665 --ca /var/lib/icinga2/certs/ca.crt --key /var/lib/icinga2/certs/agentl3.cern.ch.key --cert /var/lib/icinga2/certs/agentl3.cern.ch.crt --trustedcert /var/lib/icinga2/certs/trusted-cert.crt --ticket d996d52d07052ec697a63ad51ed27604411efc53' returned 1 instead of one of [0]

Way I run it again it completes with no errors.
I can’t find any option in the icinga puppet documentation to pass the ticket,
is this how it’s supposed to run? Maybe I am missing something in the error message

Thanks,
Mike

2

The ticket is created based on the name of the host and the ticketsalt, so I guess you did not provide the ticketsalt or an incorrect one. I think because of this it has an invalid ticket on the first run. Following runs will be fine as they probably check for something that now exists because of the failed command or because it then uses or expects a different signing mechanism.

And Puppet should be never supposed to run multiple times to work correctly. If this is the case in most cases there is an error in the Puppet code and in the others you are hitting a Puppet bug.

3

How can I troubleshoot this?
The salt in the manifest is the same as the masters

class { 'icinga2::feature::api':
    pki             => 'icinga2',
    ca_host         => $master1_hostname,
    ticket_salt     => 'TestSalt',
    ensure          => 'present',
    accept_config   => true,
    accept_commands => true,
    endpoints       => $declared_endpoints,
    zones           => $declared_zones,
    }

The ticketSalt in the constant.conf:

const TicketSalt = "TestSalt"
4

Aha ok I think I know what’s the problem. As you said the ticket salt isn’t correct.
It is managed by another file.
Thanks for the info and sorry for the post! :grin:

5

No problem, you are welcome, and yes, it is very likely that one puppet manifests manages the constant at the master and another one needs to utilize it to register agents. Glad you found both locations, always a bit of guessing involved! :wink:

Just as an recommendation only set the salt on the master and not on the agents. The algorithm to calculate the ticket is public, so the salt and the hostname are enough to get valid tickets, register hosts and be part of the cluster to get information like configuration out of it. So the salt should be treated as a secret and only stored where necessary (and I hope it is not TestSalt :wink: ).

1 Like