Mihai Carabas
> On 16 Sep 2022, at 23:12, Ludwig Krispenz <[email protected]> wrote: > > > > >> On 16.09.22 20:12, Mark Reynolds wrote: >>> >>> On 9/16/22 1:40 PM, Ludwig Krispenz wrote: >>>> >>>> On 16.09.22 19:16, Mark Reynolds wrote: >>>>> >>>>> On 9/12/22 3:38 PM, Mihai Carabas wrote: >>>>>> >>>>>> >>>>>> On Mon, Sep 12, 2022 at 6:35 PM Mark Reynolds <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>>> On 9/12/22 10:58 AM, Mihai Carabas wrote: >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Sep 9, 2022 at 10:31 PM Mihai Carabas >>>>>>>> <[email protected]> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Aug 31, 2022 at 8:25 PM Mark Reynolds <[email protected]> >>>>>>>>> wrote: >>>>>>>>>> Mihai, >>>>>>>>>> >>>>>>>>>> Start with the docs: >>>>>>>>>> >>>>>>>>>> https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/setting_up_windows_synchronization_between_active_directory_and_directory_server#configuring_the_database_for_synchronization_and_creating_the_synchronization_agreement_using_the_command_line >>>>>>>>>> >>>>>>>>>> # dsconf slapd-INSTANCE repl-winsync-agmt list >>>>>>>>>> >>>>>>>>>> # dsconf slapd-INSTANCE repl-winsync-agmt set --help >>>>>>>>>> >>>>>>>>>> # dsconf slapd-INSTANCE repl-winsync-agmt set --host=<NEW HOSTNAME> >>>>>>>>>> <AGREEMENT NAME> >>>>>>>>>> >>>>>>>>>> # dsconf slapd-INSTANCE repl-winsync-agmt init <AGREEMENT NAME> >>>>>>>>> >>>>>>>>> I did this: >>>>>>>>> >>>>>>>>> [root@ldap ~]# dsconf slapd-ldap repl-winsync-agmt list --suffix >>>>>>>>> "dc=curs,dc=xxx,dc=yy" | grep Host >>>>>>>>> nsDS5ReplicaHost: ad-tttt-01.curs.xxx.yy >>>>>>>>> >>>>>>>>> But in the logs: >>>>>>>>> >>>>>>>>> [09/Sep/2022:22:23:43.366356845 +0300] - INFO - NSMMReplicationPlugin >>>>>>>>> - windows sync - windows_tot_run - Beginning total update of replica >>>>>>>>> "agmt="cn=ad.curs.xxx.yy" (ad:636)". >>>>>>>>> >>>>>>>>> And it connects to the old server (ad:636) [the old was >>>>>>>>> ad.curs.xxx.yy]. From where is getting that ad? >>>>>>>> >>>>>>>> Any input here? A reboot is needed? Dropping changelog? >>>>>>> Try a server restart "dsctl slapd-ldap restart". If it still pulling >>>>>>> in that old host then maybe you have an extra/conflicting agreement? >>>>>>> "cn=ad.curs.xxx.yy" refers the DN of the replication agreement. So >>>>>>> check if that is the same DN of the agreement you have been modifying. >>>>>>> >>>>>>>> >>>>>> restart worked like a charm. >>>>>> >>>>>> Is there a way to find out what config changes needs restart? (for >>>>>> future reasons) >>>>> Well in this case a replication agreement is processed at server startup >>>>> or when it is first created. The server will spawn a separate thread for >>>>> each replication agreement. Changes to things like port and hostname are >>>>> not picked up in this agreement thread. So all changes to a replication >>>>> agreement's configuration will require a server restart. >>>>> >>>> Are you sure ? >>>> >>> No :-) >>> >>> Well changing the host name is only picked up on new replication >>> connections. So if the connection is long lived it will not pick up on the >>> change. Maybe that's what was happening here? >>> >> but there is agmt_set_host_from_entry() which calls >> prot_notify_agmt_changed(), so it should be picked up The connection to the AD we should presume that was a long one. >>> We have/had a function "prot_notify_agmt_changed" which sets the state to >>> EVENT_AGMT_CHANGED and the state machin will capture this and restart the >>> incremantal protocol. >>> >>> Ludwig >>> >>>> Mark >>>> >>>> -- >>>> Directory Server Development Team >>>> >>>> >>>> _______________________________________________ >>>> 389-users mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> 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/[email protected] >>>> Do not reply to spam, report it: >>>> https://pagure.io/fedora-infrastructure/new_issue >>> >>> >>> _______________________________________________ >>> 389-users mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> 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/[email protected] >>> Do not reply to spam, report it: >>> https://pagure.io/fedora-infrastructure/new_issue >> -- >> Directory Server Development Team > _______________________________________________ > 389-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________ 389-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
