Unable to migrate winstations from 1.0.20 to 1.1
Unable to migrate winstations from 1.0.20 to 1.1
I updated FussionDirectory from 1.0.20 to 1.1 via apt on Debian jessie and follow instructions from site.
When I run "fusiondirectory-setup --migrate-winstations" a see list of all my users & winstations and question: "Migrate these entries to fdWorkstation objectClass?". Then I run "fusiondirectory-setup --migrate-users" I see only my winstations and question: "Add the inetOrgPerson objectClass to all these entries?".
I try to add fdWorkstation objectClass to my winstations by hand, but got error: "entry failed schema check: invalid structural object class chain (account/fdWorkstation)"
What am I doing wrong?
Output:
fusiondirectory-setup --migrate-winstations
Migrating your winstations from FD < 1.1 The following winstations are not using the new fdWorkstation objectClass: uid=xxx,ou=People,dc=int,dc=npk,dc=ru uid=yyy,ou=People,dc=int,dc=npk,dc=ru ... uid=xxx$,ou=Computers,dc=int,dc=npk,dc=ru uid=yyy$,ou=Computers,dc=int,dc=npk,dc=ru Migrate these entries to fdWorkstation objectClass? [Yes/No]? ^C
fusiondirectory-setup --migrate-users
Migrating your users The following users are missing objectClasses: uid=xxx$,ou=Computers,dc=int,dc=npk,dc=ru uid=yyy$,ou=Computers,dc=int,dc=npk,dc=ru ... Add the inetOrgPerson objectClass to all these entries? [Yes/No]? ^C
Objects examples:
dn: uid=xxx$,ou=Computers,dc=int,dc=npk,dc=ru cn: xxx$ uid: xxx$ ... sambaSID: S-1-5-21-xxx displayName: XXX$ ... objectClass: top objectClass: account objectClass: posixAccount objectClass: sambaSamAccount objectClass: ipHost objectClass: ieee802Device ...
dn: uid=xxx,ou=People,dc=int,dc=npk,dc=ru uid: xxx sambaSID: S-1-5-21-xxx-2144 ... gosaMailDeliveryMode: [] objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount objectClass: mozillaOrgPerson objectClass: sambaSamAccount objectClass: organizationalPerson objectClass: person objectClass: gosaMailAccount sambaPrimaryGroupSID: S-1-5-21-xxx ...
(from redmine: issue id 5538, created on 2017-05-22, closed on 2017-05-25)
- Changesets:
- Revision 5b559a84 by Côme Chilliet on 2017-05-22T15:24:49.000Z:
Fixes #5538 Fixed migration of winstations and samba users without confusion between those- Revision e6fc5db2 by Côme Chilliet on 2017-05-22T15:27:59.000Z:
Fixes #5538 Fixed migration of winstations and samba users without confusion between those- Revision 2caabff5 by Côme Chilliet on 2017-05-24T10:02:13.000Z:
Fixes #5538 Fixed parsing of winstation DN when it’s not in systems RDN- Revision 59c29815 by Côme Chilliet on 2017-05-24T10:03:41.000Z:
Fixes #5538 Fixed parsing of winstation DN when it’s not in systems RDN- Revision 6ffed51f by Côme Chilliet on 2017-05-24T13:44:15.000Z:
Fixes #5538 Fixed in-LDAP config reading by fusiondirectory-setup- Revision 13e876e0 by Côme Chilliet on 2017-05-24T13:58:51.000Z:
Fixes #5538 Fixed in-LDAP config reading by fusiondirectory-setup- Custom Fields:
- Support contract: None
Activity
Applied in changeset commit:fusiondirectory|5b559a84.
(from redmine: written on 2017-05-22)
By Côme Chilliet on 2017-09-02T15:37:35 (imported from GitLab)
Hello, indeed the filters do not take into account the fact that sambaSamAccount is used by both users and workstations.
I tried to fix the filters in 1.1-fixes version, could you try that? https://documentation.fusiondirectory.org/en/documentation_testing#testing-with-the-fixes-versions
(from redmine: written on 2017-05-22)
By Côme Chilliet on 2017-09-02T15:37:36 (imported from GitLab)
Now "fusiondirectory-setup --migrate-winstations" show correct winstations list, but migration failed:
fusiondirectory-setup --migrate-winstations
Migrating your winstations from FD < 1.1 The following winstations are not using the new fdWorkstation objectClass: uid=msts$,ou=Computers,dc=int,dc=npk,dc=ru uid=win10-stacevm$,ou=Computers,dc=int,dc=npk,dc=ru uid=stacexpvm$,ou=Computers,dc=int,dc=npk,dc=ru Migrate these entries to fdWorkstation objectClass? [Yes/No]? Y Could not parse dn uid=msts$,ou=Computers,dc=int,dc=npk,dc=ru
(from redmine: written on 2017-05-24)
By stace on 2017-09-02T15:37:36 (imported from GitLab)
Stace Zacharov wrote:
No changes ;( P.S. Installed version: 1.1-2~jenkinsbuild682
Did you edit the configuration since you updated? The new code I putted in expect to find fdSambaMachineAccountRDN in the configuration object in the LDAP which is no longer there is 1.1. (but right after you update it should still be there until you edit the configuration) If it was removed already you might need to edit fusiondirectory-setup and put "ou=Computers" as default value of $winstationrdn near the beginning of the file.
(from redmine: written on 2017-05-24)
By Côme Chilliet on 2017-09-02T15:37:37 (imported from GitLab)
Migration completed successful after I change default value of $winstationrdn variable in fusiondirectory-setup script. But fdSambaMachineAccountRDN exists in my LDAP tree:
ldapsearch -LLL cn=config fdSambaMachineAccountRDN
dn: cn=config,ou=fusiondirectory,dc=int,dc=npk,dc=ru fdSambaMachineAccountRDN: ou=Computers
(from redmine: written on 2017-05-24)
By stace on 2017-09-02T15:37:37 (imported from GitLab)
Stace Zacharov wrote:
Migration completed successful after I change default value of $winstationrdn variable in fusiondirectory-setup script. But fdSambaMachineAccountRDN exists in my LDAP tree:
ldapsearch -LLL cn=config fdSambaMachineAccountRDN
dn: cn=config,ou=fusiondirectory,dc=int,dc=npk,dc=ru fdSambaMachineAccountRDN: ou=Computers
That’s bad news, it means my code fails to read it, we’ll try to do some more test and fixes. Glad you were able to migrate after all.
(from redmine: written on 2017-05-24)
By Côme Chilliet on 2017-09-02T15:37:37 (imported from GitLab)
added Fixed label
By bmortier on 2018-09-24T13:43:07 (imported from GitLab)
