If the user does a POST query but forgets to add the
'X-HTTP-Method-Override: GET' HTP header, the error message was
misleading. This changes the error message to a more detailed message
which might give the user a better understanding what the problem
could be.
Fixes#7675.
This makes the SSL context in ApiListener::SpawnCoroutine non-const to
address an issue when an agent recieves an signed certificate from the
master and tries to update the SSL context. This also uses the class
member variable which is captured by `this` in the lamda expression.
fixes#7650
This functionality allows a stage to be uploaded and validated as
normal, but not activated. This is useful to pre-flight an Icinga config
package before it is applied to a monitoring cluster, for example in a
CI pipeline.
This is required to
- catch all exceptions and wrap them into Boost exceptions. They
are the only ones allowed with Boost.Coroutine.
- set a dedicated coroutine stack size for Windows.
refs #7431
Throwing local exceptions unnecessarily pollutes the exception
stack with immediate unwinding. Avoid this pattern at all cost within
Boost.Coroutines. MSVC may handle exceptions differently and cause
problems with stack unwinding.
refs #7431
refs #7351
Exceptions in Disconnect() might be thrown (this has been reworked
into error_code locally) which are swallowed inside the Destructor
for being dangerous. On the other hand, swallowing them may
corrupt the stack unwinding operation from the coroutine layer.
The best is to avoid Defer inside lib/remote and call Disconnect()
directly after breaking from other operations.
refs #7351
refs #7431
When run within a coroutine, exceptions on Windows may influence
bad behaviour here. Instead, we'll check for the error code
and extract the message from memory. In contrast to exceptions
which are stored on the stack frame and then return, this costs
a little more memory but simplifies the logic.
This doesn't fix the linked issue, but is related to the analysis.
refs #7431
config::UpdateObject would create a new object, but this may
have been silently ignored with 'ignore_on_error' - downtimes, etc.
Since we cannot simply fetch the error from inside the config compiler,
we'd just check whether there's a config object created at this stage.
This happens synchronously, and once there is, log something.
The previous code always logged the creation, even if the downtime
was ignored, e.g. when the first master sent one for local host objects.
This commit also adds more details: identity, endpoint, zone to extract
the MessageOrigin details into log messages for better troubleshooting
and debugging.
refs #7198
```
[2019-07-10 12:34:27 +0200] information/ApiListener: Received configuration updates (2) from endpoint 'master1' are equal to production, not triggering reload.
```