Re: Procedure to change the AD used to sync users

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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 <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? 

but there is agmt_set_host_from_entry() which calls prot_notify_agmt_changed(), so it should be picked up

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

[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux