> On 1 Jun 2022, at 23:31, Mark Reynolds <mareynol@xxxxxxxxxx> wrote: > > Hi Alberto > > On 6/1/22 2:26 AM, Alberto Crescente wrote: >> Hello, I would like to migrate my old openldap server to 389-ds (CentOS 8). I tried to upload >> the old users from the openldap server into 389-ds, but if I then try to use the dsidm command I get the following >> error message: "Error: No object exists given the filter criteria ... " >> >> >> # john, people, example.com >> dn: uid=john,ou=people,dc=example,dc=com >> objectClass: top >> objectClass: person >> objectClass: posixAccount >> objectClass: shadowAccount >> uid: john >> cn: John >> uidNumber: 5000 >> gidNumber: 5000 >> homeDirectory: /home/john >> shadowLastChange: 18170 >> loginShell: /bin/bash >> gecos: John Brown >> shadowExpire: 24444 >> sn: Brown >> >> >> Is it a schema problem? >> > Sort of... dsidm is an opinionated tool, and it does expect certain schema to be place to work correctly. >> Does dsidm only work with accounts that have the schema of DS 1.4? >> In 389-ds there is an openldap_to_ds migration script, but it seems to me that it keeps the same >> schema for the account after migration, at this point it is better to recreate all the accounts with the new DS 1.4 schema >> starting from the openldap data? >> > So yes as you noted below if the migration tool also added these objectclasses it would probably work: > > objectClass: nsPerson (requires attributes: displayName and cn) > objectClass: nsAccount > objectClass: nsOrgPerson > > > > William did all the openldap migration work so I'd like to get his input on this, but to me it makes sense to have any "migration tool" we provide to be compatible with the CLI tools we ship. This should be a simple change to lib389 to get this working. Well, there are two sides to this. nsPerson/nsAccount are designed to fix a number of "unfixable" issues from the legacy schemas including names, ssh key storage and more. But when we import data from openldap, we import it to "respect the data as it was". It's one thing to migrate, it's another to "munge the data" as we import it. So I don't think we want to change openldap_to_ds to auto-add nsPerson/nsAccount, because that involves data transforms that the admin should be aware of. But we also want dsidm to represent "best practice" so using those objectClasses is the right thing to do. I think this is a case where we need a post-migrate tool that can do these transforms, in a way that the admin is comfortable with. > > Regards, > > Mark > >> >> >> >> >> # john, people, example.com >> dn: uid=john,ou=people,dc=example,dc=com >> objectClass: top >> objectClass: nsPerson >> >> objectClass: nsAccount >> >> objectClass: nsOrgPerson >> >> objectClass: posixAccount >> objectClass: shadowAccount >> uid: john >> cn: John Brown >> uidNumber: 5000 >> gidNumber: 5000 >> homeDirectory: /home/john >> shadowLastChange: 18170 >> loginShell: /bin/bash >> displayName: John Brown >> shadowExpire: 24444 >> >> >> >> Best regards, >> Alberto Crescente. >> >> >> >> _______________________________________________ >> 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 on the list, report it: >> https://pagure.io/fedora-infrastructure > -- > 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 on the list, report it: https://pagure.io/fedora-infrastructure -- Sincerely, William Brown Senior Software Engineer, Identity and Access Management SUSE Labs, Australia _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
