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.
[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
Pierre
On Thu, Aug 29, 2024 at 3:48 PM Alessio <alciregi@xxxxxxxxxx> 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@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
--
389 Directory Server Development Team
389 Directory Server Development Team
-- _______________________________________________ 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
