Curator silently fails if one of client.certificate, client.client_cert and client.client_key is not accessible

[breml]

First of all, thank you very much for the continuation of curator and the release of 6.0.0, 7.0.0 and 8.0.0. Even though we miss the RPM packages, we are happy to continue with curator as a container.

Expected Behavior

If one of the files defined in the configuration settings client.certificate, client.client_cert or client.client_key is not found (or can not be accessed e.g. due to permission denied), curator should report a meaningful error indicating the problem.

Actual Behavior

curator fails silently (no output) with exit code 0.

Steps to Reproduce the Problem

1. Have an elasticsearch cluster with certificate based authentication.
2. Configure curator with the respective configuration settings in client.certificate, client.client_cert or client.client_key
3. Verify, that curator works
4. Change one of the above settings to an invalid path (or change the permissions of the file such that the user, curator is executed with, can no longer access the file)
5. Execut curator again, it fails silently without any output.

Specifications

Tested with:

• curator 5.8.1 installed from RPM on Alma Linux 8.7
• curator 7.0.0 executed as container (untergeek/curator from docker hub) in podman on Alma Linux 8.7 (the bug has been discovered using this setup, the reason has been SELinux permissions / wrong file label)

[untergeek]

Thanks for this. I'll see what I can find. I'm loathe to update the ancient code, tbh.

Would you be interested in a hypothetical Curator 7.16 release? I would update it to work more like Curator 8 and use a 7.11.x to 7.16.x compatible release of es_client. The reason for es_client is to simplify the connection code. It makes a huge difference as I can pinpoint things like this in that code separately from Curator.

[breml]

For me, the problem is solved, since I discovered the issue and I have been able to perform the necessary changes when I mount the volumes in podman. So for me, this is not urgent. For me, the update to the container based curator 7.0.0 is anyway only an intermediate step towards the migration to ES 8 and with this curator 8.x.
I don't know yet, if the 8.x version is affected by this problem as well. For the 8.x I think it would be good to have improved error handling for this case.

[untergeek]

It should be very different in 8.x as the handling for this is in es_client, but I'll double check.

[untergeek]

This is updated in es_client 8.7.0, as noted. The next release of Curator will have this fix.