389 DS 2.3.6 on RHEL 9 replication between 2.3.6 and 1.3.9 389DS

[Nazarenko, Alexander]

Hello colleagues,


We plan to move our LDAP service from 389DS 1.3.9 on RHEL7 to 389 DS 2.3.6 on RHEL 9
platform.

Question: is it possible to attach a 389 DS 2.3.6 consumer to 389DS 1.3.9 supplier for
seamless transition, and get the data replicated in real time?

My first attempt produced an error about different database versions.
Maybe it is not supposed to work?

Thank you,
- Alex

[Mark Reynolds]

Hi Alex,

It definitely works, and that error means you did not "initialize" your 
new server/replica.  Looks like you just setup a replication agreement, 
but not initialize the remote replica. Once initialized the new server 
will have the same database generation id and replication updates will flow.

HTH,
Mark

On 4/2/24 5:26 PM, Nazarenko, Alexander wrote:
>  Hello colleagues,
>
>  We plan to move our LDAP service from 389DS 1.3.9 on RHEL7 to 389 DS 
>  2.3.6 on RHEL 9 platform.
>
>  Question: is it possible to attach a 389 DS 2.3.6 consumer to 389DS 
>  1.3.9 supplier for seamless transition, and get the data replicated in 
>  real time?
>
>  My first attempt produced an error about different database versions.
>
>  Maybe it is not supposed to work?
>
>  Thank you,
>
>  - Alex
>
>
>  --
>  _______________________________________________
>  389-users mailing list --389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to389-users-leave(a)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/[e-mail]...
>  Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue 
-- 
Identity Management Development Team

[Alex Nazarenko]

Thank you, Mark,

Is there a way to initialize an existing instance without rebuilding the
consumer instance from scratch?
I tried this:
- remove all *db files from the consumer
- remove existing agreement from the supplier (from cn=config)
- re-run creating the agreement on the supplier with "init":

*dsconf -D "***" -w *** ldap://supplier create --suffix
"dc=harvard,dc=edu"
--host "consumer" --port 636 --conn-protocol LDAPS --bind-dn
"cn=replication manager,cn=config" --bind-passwd "***" --bind-method
SIMPLE  --init consumer-RO*Still got the same error.

Thank you again,
- Alex

On Tue, Apr 2, 2024 at 5:35 PM Mark Reynolds <mareynol(a)redhat.com&gt; wrote:

>  Hi Alex,
>
>  It definitely works, and that error means you did not "initialize" your
>  new server/replica.  Looks like you just setup a replication agreement, but
>  not initialize the remote replica.  Once initialized the new server will
>  have the same database generation id and replication updates will flow.
>
>  HTH,
>  Mark
>  On 4/2/24 5:26 PM, Nazarenko, Alexander wrote:
>
>  Hello colleagues,
>
>
>
>
>
>  We plan to move our LDAP service from 389DS 1.3.9 on RHEL7 to 389 DS 2.3.6
>  on RHEL 9 platform.
>
>
>
>  Question: is it possible to attach a 389 DS 2.3.6 consumer to 389DS 1.3.9
>  supplier for seamless transition, and get the data replicated in real time?
>
>
>
>  My first attempt produced an error about different database versions.
>
>  Maybe it is not supposed to work?
>
>
>
>  Thank you,
>
>  - Alex
>
>
>
>
>
>
>
>  --
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>
>  --
>  Identity Management Development Team
>
>  --
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)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/[e-mail]...
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>

[Mark Reynolds]

On 4/2/24 6:09 PM, Alex Nazarenko wrote:
>  Thank you, Mark,
>
>  Is there a way to initialize an existing instance without rebuilding 
>  the consumer instance from scratch?
>  I tried this:
>  - remove all *db files from the consumer 
this is never needed ^^^
>  - remove existing agreement from the supplier (from cn=config)
You could reuse the same agreement
>  - re-run creating the agreement on the supplier with
> "init":*
>
>  dsconf -D "***" -w *** ldap://supplier create --suffix 
>  "dc=harvard,dc=edu" --host "consumer" --port 636 --conn-protocol
> LDAPS 
>  --bind-dn "cn=replication manager,cn=config" --bind-passwd "***" 
>  --bind-method SIMPLE  --init consumer-RO
>
>  * 
Hmm that does not look like the correct syntax to create and init an 
agreement.  Maybe you left something out when you sent this email?   You 
need "repl-agmt":

     # dsconf *-D "***" -w *** ldap://supplier repl-agmt create 
**--suffix "dc=harvard,dc=edu" --host CONSUMER_FQDN--port 636 
--conn-protocol LDAPS --bind-dn "cn=replication manager,cn=config" 
--bind-passwd "***" --bind-method SIMPLE  --init consumer-RO*

Anyway that should have initialized the remote replica.  Perhaps this is 
failing somehow.  Please check the access/errors log on the remote replica.

If you already have an agreement you can just try a reinit at any 
point.  No need to remove the agreement before trying to reinit it:

     # dsconf *-D "***" -w *** l**dap://supplier**repl-agmt init 
--suffix **"dc=harvard,dc=edu" **consumer-RO*

Anyway check the logs on the remote server, perhaps replication is not 
enabled on that server?  TLS could be an issue, BIND DN, repl config, 
etc.  The logs will tell us more.


On a side note, if you run the CLI as root locally, you don't need to 
set the the ldap url or bind credentials.  We use LDAPI to map "root" to 
"cn=directory manager'.  You do this by simply specifying the instance name:

     # dsconf slapd-YOUR_INSTANCE *repl-agmt create **--suffix ... ....*

*You can even shortcut this even more by removing "slapd-"*

     # dsconf YOUR_INSTANCE *repl-agmt create **--suffix ... ...***

*There is also bash completion on the instance name as well:*

*# dsconf YOUR_IN <hit tab> *

*And, you can also pre-set values by updating the ~/.dsrc That should be 
documented in the official Red Hat docs/389 wiki ... *

HTH,

Mark

>  Still got the same error.
>
>  Thank you again,
>  - Alex
>
>  On Tue, Apr 2, 2024 at 5:35 PM Mark Reynolds <mareynol(a)redhat.com&gt; wrote:
>
>      Hi Alex,
>
>      It definitely works, and that error means you did not "initialize"
>      your new server/replica.  Looks like you just setup a replication
>      agreement, but not initialize the remote replica.  Once
>      initialized the new server will have the same database generation
>      id and replication updates will flow.
>
>      HTH,
>      Mark
>
>      On 4/2/24 5:26 PM, Nazarenko, Alexander wrote:
> >
> >     Hello colleagues,
> >
> >     We plan to move our LDAP service from 389DS 1.3.9 on RHEL7 to 389
> >     DS 2.3.6 on RHEL 9 platform.
> >
> >     Question: is it possible to attach a 389 DS 2.3.6 consumer to
> >     389DS 1.3.9 supplier for seamless transition, and get the data
> >     replicated in real time?
> >
> >     My first attempt produced an error about different database
> >     versions.
> >
> >     Maybe it is not supposed to work?
> >
> >     Thank you,
> >
> >     - Alex
> >
> >
> >     --
> >     _______________________________________________
> >     389-users mailing list --389-users(a)lists.fedoraproject.org
> >     To unsubscribe send an email to389-users-leave(a)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/[e-mail]...
> >     Do not reply to spam, report
> it:https://pagure.io/fedora-infrastructure/new_issue
>
>      -- 
>      Identity Management Development Team
>
>      --
>      _______________________________________________
>      389-users mailing list -- 389-users(a)lists.fedoraproject.org
>      To unsubscribe send an email to
>      389-users-leave(a)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/[e-mail]...
>      Do not reply to spam, report it:
>      https://pagure.io/fedora-infrastructure/new_issue
>
>
>  --
>  _______________________________________________
>  389-users mailing list --389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to389-users-leave(a)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/[e-mail]...
>  Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue 
-- 
Identity Management Development Team