Hello. I was trying to migrate from bdb to mdb I use this command dsctl instanceName dblib bdb2mdb
What I get at the end is: ... WAR The "nsslapd-ldapimaprootdn" setting is obslolete ... For LDAPI configuration, "nsslapd-rootdn" is used instead ... Backends importation 100% Error: 97 - 1 - 53 - Server is unwilling to perform - [] - Unauthenticated binds are not allowed
And I don't understand if the operation was successful because dsctl -j instanceName healthcheck still report that "BDB is still used as backend"
Any hint would be appreciated. Thanks
Hi Alessio,
[1] About the warning, IMHO that is because an old attribute stayed in dse.ldif, (Probably after migrating from an older version.) Could be fixed by fixing the dse.ldif but anyway it should not be an issue.
[2] About the authentication error iI is displayed after "Backends importation 100%" message so at the very end. The code is: log.info("Backends importation 100%") inst.start() log.info("Migration from Berkeley database to lmdb is done.") So I think that the error is triggered by inst.start() which start the server, open a new connect and bind. IMHO there is a minor bug. We should start without trying to reopen the connection (as it is not used afterwards) but anyway at this point the migration is completed.
[3] Healthcheck reports '"BDB is still used as backend"' That one is worrisome and a bit surprising because the db type set set off line by writing directly in the dse.ldif after exporting the databases (and before importing them) 'dsconf supplier1 backend config get | grep -i nsslapd-backend-implement ' or 'grep -i nsslapd-backend-implement /etc/dirsrv/slapd-instanceName/dse.ldif' should tell you which database is really used.
Regards, Pierre
On Thu, Aug 29, 2024 at 3:48 PM Alessio alciregi@posteo.net wrote:
Hello. I was trying to migrate from bdb to mdb I use this command dsctl instanceName dblib bdb2mdb
What I get at the end is: ... WAR The "nsslapd-ldapimaprootdn" setting is obslolete ... For LDAPI configuration, "nsslapd-rootdn" is used instead ... Backends importation 100% Error: 97 - 1 - 53 - Server is unwilling to perform - [] - Unauthenticated binds are not allowed
And I don't understand if the operation was successful because dsctl -j instanceName healthcheck still report that "BDB is still used as backend"
Any hint would be appreciated. Thanks -- _______________________________________________ 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.... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 29.08.2024 18:15, Pierre Rogier wrote:
[3] Healthcheck reports '"BDB is still used as backend"' That one is worrisome and a bit surprising because the db type set set off line by writing directly in the dse.ldif after exporting the databases (and before importing them) 'dsconf supplier1 backend config get | grep -i nsslapd-backend-implement ' or 'grep -i nsslapd-backend-implement /etc/dirsrv/slapd-instanceName/dse.ldif' should tell you which database is really used.
Thank you very much for the prompt answer, Pierre. Yes, these two commands report that nsslapd-backend-implement is mdb. So I should be confident that the migration was successful. What about healthcheck stating otherwise?
Thanks, Alessio
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 ?
On Thu, Aug 29, 2024 at 7:24 PM Alessio alciregi@posteo.net wrote:
On 29.08.2024 18:15, Pierre Rogier wrote:
[3] Healthcheck reports '"BDB is still used as backend"' That one is worrisome and a bit surprising because the db type set set off line by writing directly in the dse.ldif after exporting the databases (and before importing them) 'dsconf supplier1 backend config get | grep -i nsslapd-backend-implement ' or 'grep -i nsslapd-backend-implement /etc/dirsrv/slapd-instanceName/dse.ldif' should tell you which database is really used.
Thank you very much for the prompt answer, Pierre. Yes, these two commands report that nsslapd-backend-implement is mdb. So I should be confident that the migration was successful. What about healthcheck stating otherwise?
Thanks, Alessio
-- _______________________________________________ 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.... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 30.08.2024 17:33, 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 ?
[1] NSSLAPD_DB_LIB doesn't seem to be here [2] 389-ds-base 2.5.2 on CentOS Stream 9
Thanks
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@lists.fedoraproject.org