but there is agmt_set_host_from_entry() which calls prot_notify_agmt_changed(), so it should be picked up
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 <mareynol@xxxxxxxxxx> wrote:
On 9/12/22 10:58 AM, Mihai Carabas wrote:
On Fri, Sep 9, 2022 at 10:31 PM Mihai Carabas <mihai.carabas@xxxxxxxxx> wrote:
On Wed, Aug 31, 2022 at 8:25 PM Mark Reynolds <mareynol@xxxxxxxxxx> 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?
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 -- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue-- 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, report it: https://pagure.io/fedora-infrastructure/new_issue
