DB2INST1 file permissions incorrect when deploying to RHOCP on IBM Cloud Private

[northfig]

When deploying this chart to a RHOCP (v3.11) cluster on IBM Cloud, the PVC is implemented as a NFS mount. This results in the files stored under the db2inst1 home directory that should be owned by root (e.g /mnt/blumeta0/home/db2inst1/sqllib/security/db2chpw) having an owner of nobody.

[db2inst1@spdb2-5-db2u-0 - Db2U security]$ ls -l total 3208 drwxr-sr-x. 2 db2inst1 db2iadm1 4096 Dec 19 16:26 auditdata -r-s--x--x. 1 db2inst1 db2iadm1 76456 Feb 19 08:22 db2aud -rw-r--r--. 1 db2inst1 db2iadm1 4096 Dec 19 16:26 db2audit.cfg lrwxrwxrwx. 1 nobody db2iadm1 42 Feb 19 08:22 db2chkau -> /opt/ibm/db2/V11.5.0.0/security64/db2chkau -r-s--x--x. 1 nobody db2iadm1 31904 Feb 19 08:22 db2chpw -r-s--x--x. 1 nobody db2iadm1 3020600 Feb 19 08:22 db2ckpw -r-x--s--x. 1 db2inst1 db2iadm1 115880 Feb 19 08:22 db2flacc

These instance files should not be located on the PVC mount, but should be part of the core container, with only dynamic data being stored on the PVC

[soumypau1]

db2chpw and db2ckpw files created by installer, They shouldnt be on PV. Why cant we mount only the data directory on PV ?

[adesilva74]

The problem is NFS export options (on NFS server side), need to use no_root_squash,no_all_squash options ... The user nobody ownership is a direct result of not using no_root_squash ...

There is nothing you can do from the NFS client side to resolve this.

[northfig]

@adesilva74 given that you need to provision a separate NFS server to manage this, does that mean that going forward DB2 will NEVER be able to use standard storage classes in the IBM cloud? IBM cloud only provisions storage based on NFS, so that means you always need to have a pre-provisioned NFS server.

[northfig]

db2chpw and db2ckpw files created by installer, They shouldnt be on PV. Why cant we mount only the data directory on PV ?

@soumypau1

Unfortunately as the instance is only configured at deploy time it must be persisted on the external volume. Otherwise each time the pod is restarted the instance information will be lost, or you will have a static instance and DB name which is not very useful

[irinadel]

@northfig For IBM Cloud pre-configured block storageclasses, you need to enable no_root_squash as described here - https://github.com/IBM-Cloud/kube-samples/tree/master/daemonset-sample Please close the issue if that works for you.

[saadlu]

@irinadel Is this relevant to having DB2U deployed to ROKS? (managed OpenShift 3.11 on IBM public cloud)

I tried following the instruction to install DB2U in ROKS. But I keep on getting errors. The db2u pod fails the readiness probe and log says:

Failed to realize cgroups for queued unit var-log-journal.mount: Permission denied Failed to create cgroup /kubepods.slice/kubepods-pod7f4affc1_73f1_11ea_8edf_526b135ea6d8.slice/crio-da918a866603d474b064721377970f9253fb918033e963c2da3a06d7b1dcb989.scope/system.slice/etc-hosts.mount: Permission denied Failed to realize cgroups for queued unit etc-hosts.mount: Permission denied db2u_root.service: main process exited, code=exited, status=219/CGROUP db2u_root.service: control process exited, code=exited status=219 Unit db2u_root.service entered failed state. db2u_root.service failed. start request repeated too quickly for systemd-journald.service Unit systemd-journald.socket entered failed state. systemd-journald.service failed.

[northfig]

@saadlu

I believe the error you are seeing is due to incorrect privileges for the container in ROKS.

I fixed this by issuing these commands to set the SCC for the service account.

oc adm policy remove-scc-from-user db2u-scc -z db2u oc adm policy add-scc-to-user privileged -z db2u oc adm policy remove-scc-from-user anyuid -z db2u

However ultimately you will need to ensure if your PVC is using NFS that you set the no_root_squash attribute as per the above

[northfig]

Closing ticket, as the no_root_squash attribute resolved the issue.