PR - Issue 49731 - undo db_home_dir under /dev/shm/dirsrv for now

[389-ds-bot]

Cloned from Pagure Pull-Request: https://pagure.io/389-ds-base/pull-request/51038

• Created at 2020-04-21 20:56:44 by mreynolds (@mreynolds389)
• Merged at 2020-04-22 14:42:52

---

Bug Description:

There are several issues with using /dec/shm/disrv/ for the db home directory. Containers have issues, and system reboots can cause issues too.

Fix Description:

Using just /dev/shm/slapd-INST solves all the permission issues, but that requires a new selinux label, so for now we will just set the db home directory to the database directory (effectively disabling the change).

Resolves: #2790

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2020-04-22 01:25:14

Ack from me

[389-ds-bot]

Comment from tbordaz (@tbordaz) at 2020-04-22 10:49:35

congratulation @mreynolds389 for this tough investigations. Ack for me as well.

Just out of curiosity and for the recording. The problem being permission to access /dev/shm/dirsrv and /dev/shm/dirsrv/slapd-INST.
A discussed option were to create /dev/shm/dirsrv by systemd (solving reboot and selinux constraint) and /dev/shm/dirsrv/slapd-INST by the DS backend initialization.
Was this option failing as well or abandoned because of the urgency/risk to fix the issue or something else ?

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2020-04-22 14:09:07

congratulation @mreynolds389 for this tough investigations. Ack for me as well.
Just out of curiosity and for the recording. The problem being permission to access /dev/shm/dirsrv and /dev/shm/dirsrv/slapd-INST.
A discussed option were to create /dev/shm/dirsrv by systemd (solving reboot and selinux constraint) and /dev/shm/dirsrv/slapd-INST by the DS backend initialization.
Was this option failing as well or abandoned because of the urgency/risk to fix the issue or something else ?

No we just need to drop the entire /dev/shm/dirsrv/ approach. We should just allow the instance at start up to create /dev/shm/slapd-inst (once they make a new selinux rule for those directories). I had a community member on Debian also verify that this approach works correctly and doesn't cause anything strange to happen after reboots.

So once we get the new selinux labels created (bug is pending), then we can set the default to /dev/shm/slapd-inst in defaults.inf and we are done. No other changes will be needed.

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2020-04-22 14:40:04

congratulation @mreynolds389 for this tough investigations. Ack for me as well.
Just out of curiosity and for the recording. The problem being permission to access /dev/shm/dirsrv and /dev/shm/dirsrv/slapd-INST.
A discussed option were to create /dev/shm/dirsrv by systemd (solving reboot and selinux constraint) and /dev/shm/dirsrv/slapd-INST by the DS backend initialization.
Was this option failing as well or abandoned because of the urgency/risk to fix the issue or something else ?

No we just need to drop the entire /dev/shm/dirsrv/ approach. We should just allow the instance at start up to create /dev/shm/slapd-inst (once they make a new selinux rule for those directories). I had a community member on Debian also verify that this approach works correctly and doesn't cause anything strange to happen after reboots.
So once we get the new selinux labels created (bug is pending), then we can set the default to /dev/shm/slapd-inst in defaults.inf and we are done. No other changes will be needed.

Well we still need to do some container magic for cases where dscontainer is not used.

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2020-04-22 14:42:19

rebased onto 3ca89e3

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2020-04-22 14:42:52

Pull-Request has been merged by mreynolds389

[389-ds-bot]

Patch
51038.patch