Postgres Permission Issue

[boomam]

Creation of ddosify via helm prevents Postgres from being able to load properly due to permission issues with initdb.
 
I have other Postgres deployments on the same cluster/storage that do not have this issue, so this is certainly ddosify specific, not sure how yet though.
 
Error from log -

chmod: changing permissions of '/var/lib/postgresql/data': Operation not permitted
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

initdb: error: could not change permissions of directory "/var/lib/postgresql/data": Operation not permitted
fixing permissions on existing directory /var/lib/postgresql/data ...

If I get time this weekend, I'll create a Postgres instance on another system, use the alternative install settings for 'remote' Postgres & Influx to test if the Ddosify works correctly with those.

[fatihbaltaci]

Hi @boomam,

Thank you for providing detailed information about the issue you are experiencing. Based on our analysis, it seems that the permission settings for the persistent volume used by the PostgreSQL instance of the Ddosify Helm chart are causing the problem.

To help us reproduce this issue, could you please provide the following information:

1. Could you share the storage class configuration if you are using dynamic provisioning?
2. Which Kubernetes environment are you using? (EKS, AKS, Minikube, etc.)
3. Are you using the default values for the Helm chart, or have you made any changes? If so, please share the helm install commands and values.yaml.

Best.

[boomam]

Hi @fatihbaltaci - apologies for the delay in replying -

RE: 1
On this particular cluster I am using SMB CSI as my storage class for Ddosify.

RE: 2
K3s - v1.26.5+k3s1

RE: 3
Only three changes.

1. Storage Class = 'smb'.
2. Ingress = true
3. Hostname = ddosify.mydomain.com

Interesting to note, I did a second test deployment a few mins after posting this issue, this time changing the class to 'Longhorn', as I have multiple storage classes configured - appears to work perfectly fine with Longhorn.
 
One theory I have is that it's maybe to do with the account being used by the container vs what the storage class is logging into the SMB backend with/associated permissions.
It doesn't directly explain why other Postgres installs behave, but the one associated with ddosify doesn't, but when I get some time, I plan to do some testing around that, too.

[fatihbaltaci]

Hey @boomam, would you mind sharing your other postgres.yaml file if it's open-source? I'd like to compare it to Ddosify's configuration as I try using the SMB CSI storage class.

[boomam]

Morning @fatihbaltaci,
I was testing with the stock bitnami/postgresql helm chart, with the only changes being -

global:  
  storageClass: "smb"
  postgresql:
    auth:
      postgresPassword: "123abc"
      username: "testuser"
      password: "123abc"
      database: "testdb"

[fatihbaltaci]

Hey @boomam, we released a new version of Ddosify: https://github.com/ddosify/ddosify-helm-charts/releases/tag/ddosify-1.7.5

Can you try again? Do not forget to update the helm repo: helm repo update