When a CRL is specified in the ApiListener configuration, Icinga 2 only
used it when connections were established so far, but not when a
certificate is requested. This allows a node to automatically renew a
revoked certificate if it meets the other conditions for auto-renewal
(issued before 2017 or expires in less than 30 days).
Merge AsyncTryActivateZonesStage and TryActivateZonesStageCallback and
name the result TryActivateZonesStage. The old split was a leftover from
the one being a callback function with no actual meaningful separation.
Anonymous connections are normally only used for requesting a
certificate and are closed after this request is received. However, the
request is only sent if the child has successfully verified the
certificate of its parent so that it is an authenticated connection from
its perspective. In case this verification fails, both ends view it as
an anonymous connection and never actually use it but attempt a
reconnect after 10 seconds leaking the connection. Therefore close it
after a timeout.
RelayMessageOne used to relay the message only to one other endpoint for
other zones, which is fine, as long as the target zone is a child/parent
zone but breaks if the target zone is a global one. In this case, the
message has to be forwarded within the local zone as well as to one node
in each child zone.
The initial config object sync for each new connection (in
`ApiListener::SendRuntimeConfigObjects()`) only considers currently
existing objects and has no way to pass the information that objects
were deleted in the meantime.
This commit logs config object deletions to the replay log if required
so that there is a chance that it will be propagated to nodes that were
offline when the deletion happened.
Note that this can only be considered a workaround as the replay log
might be pruned or could even be completely disabled. Also, there still
seems to be a race-condition between the config sync and replay log of
multiple new connections at the same time.
With dc3062a9b06fed69cdbb1508ace6eb2f77f87553, exceptions in this code
path were no longer caught properly. This commit restores exception
handling for this function.
until now, if the timeout is exceeded, the connection is immediately terminated.
But since we do not want to disconnect even if the timeout is exceeded, it is
better to send the messages without timeout and have deleted everything that
related to the heartbeat timeout. We also have another mechanism in
JRPC::CheckLiveness that does the disconnect.
