On Thu, Sep 1, 2022 at 2:05 PM Ronald Wimmer <ronaldw@xxxxxxxx> wrote:
On 01.09.22 13:41, Viktor Ashirov wrote:
> On Thu, Sep 1, 2022 at 1:24 PM Ronald Wimmer <ronaldw@xxxxxxxx> wrote:
>
>> We stuck to the guide on
>> https://directory.fedoraproject.org/docs/389ds/howto/howto-deploy-389ds-on-openshift.html
>> but tried to leave out LDAPs and all the certificate stuff for now. Pod is
>> starting but crashes immediately with the following error:
>>
>> kubectl logs dirsrv-0 dirsrv-container -n dirsrv-dev
>> INFO: The 389 Directory Server Container Bootstrap
>> INFO: Inspired by works of: ITS, The University of Adelaide
>> INFO: 389 Directory Server Version: 2.2.2
What is the image that you're using?
$ podman run -ti quay.io/389ds/dirsrv rpm -q 389-ds-base389-ds-base-2.0.16-1.fc35.x86_64
>> INFO: Initialising 389-ds-container due to empty volume ...
>> DEBUG: Running setup with verbose
>> DEBUG: START: Starting installation ...
>> DEBUG: READY: Preparing installation for localhost...
>> INFO: Validate installation settings ...
>> DEBUG: PASSED: using config settings 999999999
>> DEBUG: PASSED: user / group checking
>> DEBUG: PASSED: prefix checking
>> Traceback (most recent call last):
>> File "/usr/lib/dirsrv/dscontainer", line 467, in <module>
>> begin_magic()
>> File "/usr/lib/dirsrv/dscontainer", line 270, in begin_magic
>> if not sds.create_from_args(g2b.collect(), s2b.collect()):
>> File "/usr/lib/python3.10/site-packages/lib389/instance/setup.py", line
>> 685, in create_from_args
>> self._prepare_ds(general, slapd, backends)
>> File "/usr/lib/python3.10/site-packages/lib389/instance/setup.py", line
>> 612, in _prepare_ds
>> assert_c(len(insts) == 0, "Another instance named '%s' may already
>> exist" % slapd['instance_name'])
>> File "/usr/lib/python3.10/site-packages/lib389/utils.py", line 1274, in
>> assert_c
>> raise AssertionError(msg)
>> AssertionError: Another instance named 'localhost' may already exist
>>
>> Any idea why?
>>
> When persistent volume is mounted, dirsrv user doesn't have write access to
> it. In the guide there is a workaround to run an init container that would
> chown /data to dirsrv user. Do you have it in your config?
Yes. We are using an init container and it seems to be working:
ls -alh
total 0
drwxrwsr-x 9 389 389 88 Sep 1 12:28 .
drwxr-xr-x 3 root root 19 Aug 30 10:24 ..
drwxrwsr-x 2 389 389 6 Sep 1 12:28 bak
drwxrwsr-x 3 389 389 281 Sep 1 12:28 config
drwxrwsr-x 2 389 389 6 Sep 1 12:28 db
drwxrwsr-x 2 389 389 6 Sep 1 12:28 ldif
drwxrwsr-x 2 389 389 6 Sep 1 12:28 logs
drwxrwsr-x 4 389 389 32 Sep 1 12:28 run
drwxrwsr-x 2 389 389 156 Sep 1 12:28 ssca
Nevertheless, if I purge all the data in this directory dirsrv fails to
start with the error message above.
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Viktor
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
