Migration: importing an OU to a new instance

I've read this doc:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/ht...

The export from server A to an LDIF file works and I've done some testing but it seems like the import feature always deletes existing OUs on server B that aren't in the exported LDIF file. Am I missing something? I'd like to simply get an LDIF of all the entries in Server A and populate only that OU in server B.

Related, this bit is bewildering
Optional: By default, Directory Server sets the entry update sequence numbers (USNs) of all imported entries to 0. To set an alternative initial USN value, set the nsslapd-entryusn-import-initval parameter. For example, to set USN for all imported values to 12345, enter:

I don't understand what this means or the consequences of taking the default or not. Server B is already in multi-supplier replication with other servers, so I worry about screwing that up with any import choices I might make.

[Thierry Bordaz]

On 9/13/23 18:44, [e-mail] wrote:
> I've read this doc:
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/ht...
>
> The export from server A to an LDIF file works and I've done some testing but it seems like the import feature always deletes existing OUs on server B that aren't in the exported LDIF file. Am I missing something? I'd like to simply get an LDIF of all the entries in Server A and populate only that OU in server B.

THe export works at suffix (or backend) level, it exports (from db to 
ldif) all the entries of that suffix. The import works in the opposite 
way, it imports all the entries from the ldif. If you want only a subset 
of the entries you need to edit LDIF and remove the entries you do not want.
> Related, this bit is bewildering
> Optional: By default, Directory Server sets the entry update sequence numbers (USNs) of all imported entries to 0. To set an alternative initial USN value, set the nsslapd-entryusn-import-initval parameter. For example, to set USN for all imported values to 12345, enter:

You are correct [1]. if usn plugin is enabled, all the imported entry 
will get attribute 'entryusn: <value of nsslapd-entryusn-import-initval' 
(instead of '0')

[1] 
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/ht...

best regards
thierry
> I don't understand what this means or the consequences of taking the default or not. Server B is already in multi-supplier replication with other servers, so I worry about screwing that up with any import choices I might make.
> _______________________________________________
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]....
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Thanks for the quick reply. My issue is this:

Server A has two OUs, call them ou=A and ou=B. Server B has two OUs, ou=A (empty) and ou=C. I want to copy the data from ou=A on server A to ou=A on server B. There are no ou=B entries in the export file from server A and for the import task I add to server B, I set this attribute:
nsExcludeSuffix: ou=B

When this task runs, it populates ou=A on server B but also completely deletes OU=C
Any way around this?

Thanks for the additional info on the other question, I guess my problem is that I don't understand the significance of entry USNs at all in 389 server, so I'm not sure how to deal with them in general and especially when it comes to instance migration.

[Mark Reynolds]

On 9/13/23 1:57 PM, [e-mail] wrote:
> Thanks for the quick reply. My issue is this:
>
> Server A has two OUs, call them ou=A and ou=B. Server B has two OUs, ou=A (empty) and ou=C. I want to copy the data from ou=A on server A to ou=A on server B. There are no ou=B entries in the export file from server A and for the import task I add to server B, I set this attribute:
> nsExcludeSuffix: ou=B
>
> When this task runs, it populates ou=A on server B but also completely deletes OU=C
> Any way around this?

So an "import" overwrites the entire database with what is in the LDIF 
file.  What you want to do is to merge the data.  If there are not that 
many entries in the LDIF the easiest solution is to use ldapmodify to 
add each entry separately:

For example:

$ ldapmodify -D "cn=directory manager" -W -a -c -f <your LDIF file>

HTH,

Mark
> Thanks for the additional info on the other question, I guess my problem is that I don't understand the significance of entry USNs at all in 389 server, so I'm not sure how to deal with them in general and especially when it comes to instance migration.
> _______________________________________________
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]....
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Thanks, this was my backup plan if I couldn't find a backup/restore script that would do it. It's kind of a large set though, over 1M entries.

[Mark Reynolds]

The other option is yo export the local database to LDIF, then import 
two ldifs at the same time.  Something like:

# dsconf slapd-INSTANCE backend import userroot local_ldif other_ldif

HTH,

Mark

On 9/14/23 1:50 PM, [e-mail] wrote:
> Thanks, this was my backup plan if I couldn't find a backup/restore script that would do it. It's kind of a large set though, over 1M entries.
> _______________________________________________
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]....
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

That's a clever idea, thanks. That may be just what I need.

[Thierry Bordaz]

On 9/13/23 19:57, [e-mail] wrote:
> Thanks for the quick reply. My issue is this:
>
> Server A has two OUs, call them ou=A and ou=B. Server B has two OUs, ou=A (empty) and ou=C. I want to copy the data from ou=A on server A to ou=A on server B. There are no ou=B entries in the export file from server A and for the import task I add to server B, I set this attribute:
> nsExcludeSuffix: ou=B
>
> When this task runs, it populates ou=A on server B but also completely deletes OU=C
> Any way around this?

Except Mark's suggestion the only option I can think of would be to 
create dedicated backend/suffix for ou=A, ou=B and ou=C.

If you plan to do frequent export/import or even setup replication that 
could be an option.

regards
thierry
> Thanks for the additional info on the other question, I guess my problem is that I don't understand the significance of entry USNs at all in 389 server, so I'm not sure how to deal with them in general and especially when it comes to instance migration.
> _______________________________________________
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]....
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

An interesting suggestion, but part of my goal for the migration is to move to a simpler configuration and this will mostly likely be a one time import.