Closed szhang1 closed 3 years ago
Hm...I do see that the defaultMode
for the volume on that Secret is too permissive, even though the volume mount is set to readOnly
. I'm surprised this hasn't come up before, but it seems to hav "just worked" to date.
I will make a patch. Thanks for reporting.
This is fixed and being backpatched to all supported versions.
The only guess as to why this is occurring is that there is something in your version or distribution of Kubernetes that is not giving precedence to the fact that the volume mount of the Secret is using readOnly: true
. You can work around this by removing the defaultMode
value on the sshd
volumes on any configuration that has them. You can find those configuration files in the pgo-config
ConfigMap which is in the pgo
namespace, and edit it with kubectl edit
. Once that is fixed, you will have to restart the postgres-operator
Pod, and any newly created cluster will have the correct settings.
Thanks again for reporting.
Which example are you working with?
When I am following the
https://access.crunchydata.com/documentation/postgres-operator/latest/quickstart/
and start the first postgres cluster hippo, hippo cannot get up.What is the current behavior? When I started the first postgres cluster hippo by following the quickstart, the hippo cannot get up.
Current status:
What is the expected behavior?
It was supposed to get up. I guess that the permission should have been 400?
Other information (e.g. detailed explanation, related issues, etc)
Please tell us about your environment:
If possible please run the following on the kubernetes or OpenShift (oc) commands and provide the result: kubectl describe yourPodName kubectl describe pvc kubectl get nodes kubectl log yourPodName
Appreciate your help. Thank you very much again!