I'm not very well versed in programming languages, but I did some
investigations.
It looks like
/usr/lib/python3.9/site-packages/lib389/backend.py
invokes self._instance.get_db_lib
get_db_lib is defined in
/usr/lib/python3.9/site-packages/lib389/__init__.py
Here, at line 873
def get_db_lib(self):
...
return get_default_db_lib()
get_default_db_lib is defined in
/usr/lib/python3.9/site-packages/lib389/utils.py
and it
return os.getenv('NSSLAPD_DB_LIB', default=DEFAULT_DB_LIB)
Since NSSLAPD_DB_LIB is not defined as an environment variable,
DEFAULT_DB_LIB i returned.
DEFAULT_DB_LIB is defined in
/usr/lib/python3.9/site-packages/lib389/_constants.py
and the value is DEFAULT_DB_LIB = 'bdb'
So in my case it looks like DEFAULT_DB_LIB is always used when I use
dsctl healthcheck
If I put DEFAULT_DB_LIB = 'mdb' in _constants.py, then healthcheck
stops complaining.
Thanks,
A.
On Fri, 2024-08-30 at 17:33 +0200, Pierre Rogier wrote:
> For healthcheck, I see 2 possibilities:
> [1] NSSLAPD_DB_LIB=bdb is set in your environment (saying lib389
> that bdb is used ...)
> [2] There is a bug somewhere. (which seems a bit weird since 'dsconf
> supplier1 backend config get' is working as expected ...)
> BTW, Which exact 389-ds-base version are you using ? and on
> which platform ?
>
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
No comments:
Post a Comment