Thank you for your reply.
oneWaySync: fromWindowsnsDS5ReplicaUpdateSchedule: 1200-1210 4WinSyncInterval: 300 (default)
So what's the meaning of these attributes?
In my mind, if I set oneWaySync: fromWindows, the data flow will be from Windows to 389DS. no data from 389ds to Windows AD.
Why the data will be pushed from 389ds to Windows?
Since data will be pushed from 389ds to Windows(I don't want that), so I add one line:
nsDS5ReplicaUpdateSchedule: 1200-1210 4
to reduce the data from 389ds to Windows AD.
And last, the WinSyncinterval attribute is to control data interval from Windows to 389ds.
Is there a relationship between the two attributes? nsDS5ReplicaUpdateSchedule and WinSyncinterval.
Sincerely,
--
DaV
On Wed, Sep 4, 2019, at 15:15, Ludwig Krispenz wrote:
On 09/04/2019 08:21 AM, DaV wrote:Hi William,I set nsslapd-errorlog-level to 8192 and see one line:[04/Sep/2019:14:15:00.264779375 +0800] - DEBUG - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=ou1" (win2k16dc:389): State: wait_for_window_to_open -> wait_for_window_to_openthe window is the window of time configured in nsDS5ReplicaUpdateSchedule and you said you have "1200-1210 4" which means it will only open on thursday for 10 miutesSo I will check why win2k16 can't open.BTW, I have many windows sync agreements, but I only see one agmt debug log.Sincerely,--DaVOn Thu, Aug 29, 2019, at 07:23, William Brown wrote:>>> > On 27 Aug 2019, at 11:25, DaV <snowfrs@xxxxxxxxx> wrote:> >> > OK.> > 1. I have win2016 AD and 389ds 1.3.8.4 on CentOS 7.6> > 2. the data flow is from AD to 389ds, I don't want any data from 389ds to AD>> Great, this helps a lot.>> > 3. The time interval sync from 389ds to AD controlled by nsDS5ReplicaUpdateSchedule. This is why I set it as 1200-1210 4 (actually I want to disable it at all)>> Because replication is push based, you can just disable or remove the> agreements. Only the AD supplier needs agreements to connect to the> 389-ds side. Saying this Mark is more experienced here and may have> better insight as to what you should do here ...>> > 4. The time interval sync from AD to 389ds controlled by WinSyncInterval, it's 5 minutes default. But I can't find any error log on my 389ds server, the sync doesn't happen.>> You may need to enable replication logging (I think it's errorlog level> 8192). This will show you the incoming replication events.>> >> > Sincerely,> > --> > DaV> >> > On Tue, Aug 27, 2019, at 08:54, William Brown wrote:> >>> >>> >>> On 27 Aug 2019, at 10:44, DaV <snowfrs@xxxxxxxxx> wrote:> >>>> >>> Thanks for your reply.> >>> This is my configuration on 389ds server.> >>> Please tell me if the attribute of "oneWaySync: fromWindows" is correct.> >>>> >>> Now, the new users in AD can't be synced to 389ds every 5 minutes, I have to click "Initiate full Re-synchronized" manually. I'm stuck for days.> >>> >> I think they are *not* syncing because your schedule is:> >>> >>>>> >>>> nsDS5ReplicaUpdateSchedule: 1200-1210 4> >>>>> >>>> nsDS5ReplicaUpdateSchedule: 1211-1220 4> >>>>> >>> >> This translates to "between 12:00 and 12:10 on thursday" and "between> >> 12:11 and 12:20 on thursday.".> >>> >> IE you are syncing for a 10 minute window once a week, rather than> >> every five minutes all the time.> >>> >> You probably want something more like:> >>> >> nsDS5ReplicaUpdateSchedule : 0000-2359 0123456> >>> >> If you want to sync all the time.> >>> >> I think I'm a bit confused about the "bigger picture" of what you are> >> trying to achieve here. Can you please describe:> >>> >> * Your servers (AD, ldap etc)> >> * How you want the data to flow> >> * When you want the data to flow> >>> >> Just describe, we don't need to see configs. I think that is really> >> going to help us think through answers to your questions.> >>> >>> >>> >>>> >>> Sincerely,> >>> --> >>> DaV> >>>> >>>> >>>> >>>> >>> On Tue, Aug 27, 2019, at 02:18, Mark Reynolds wrote:> >>>>> >>>>> >>>> On 8/23/19 5:38 AM, DaV wrote:> >>>>> Hi all,> >>>>> For OneWaySync, AD to 389ds.> >>>>>> >>>>> I have read this guide> >>>>>> >>>>>> Synchronization works two ways. The Directory Server sends its updates to Active Directory on a configurable schedule, similar to replication, using the nsds5replicaupdatescheduleattribute. The Directory Server polls the Active Directory to check for changes; the frequency that it checks the Active Directory server is set in the winSyncInterval attribute.> >>>>>> By default, the Directory Server update schedule is to always be in sync. The Active Directory interval is to poll the Active Directory every five minutes.> >>>>>> To change the schedule the Directory Server uses to send its updates to the Active Directory, edit the nsds5replicaupdateschedule attribute. The schedule is set with start (SSSS) and end (EEEE) times in the form HHMM, using a 24-hour clock. The days to schedule sync updates are use ranging from 0 (Sunday) to 6 (Saturday).> >>>>>> >>>>> I want to know how to disable the nsds5replicaupdateschedule attribute. Because I just want sync from AD to 389ds.> >>>>> >>>> You can set it to "0000-0001 0" to disable synchronizing according to the link above> >>>>> >>>>> >>>>> >>>>> Thanks in advance!> >>>>>> >>>>> Sincerely,> >>>>> --> >>>>> DaV> >>>>>> >>>>> On Fri, Aug 23, 2019, at 08:18, DaV wrote:> >>>>>> Hi William,> >>>>>> Thanks for your reply.> >>>>>>> >>>>>> Sorry for incorrect message yesterday.> >>>>>> My windows sync agreement exactly is:> >>>>>>> >>>>>> agreement1:> >>>>>>>> DS Host: 389ds:389> >>>>>>>>> Windows Host: dc01.example.com:389> >>>>>>>>> DS Subtree: ou=Users,dc=example,dc=com> >>>>>>>>> Windows Subtree: ou=ou1,OU=Accounts, DC=example,DC=com> >>>>>>>>> Replicated subtree: dc=example,dc=com> >>>>>>> >>>>>> agreement2:> >>>>>>>> DS Host: 389ds:389> >>>>>>>>> Windows Host: dc01.example.com:389> >>>>>>>>> DS Subtree: ou=Users,dc=example,dc=com> >>>>>>>>> Windows Subtree: ou=ou2,OU=Accounts, DC=example,DC=com> >>>>>>>>> Replicated subtree: dc=example,dc=com> >>>>>>> >>>>>>> >>>>>> The windows AD has two OUs, and I want the two OUs are synced to the> >>>>>> same ou(ou=users,dc=example,dc=com) in 389ds server.> >>>>>> Maybe you would say I can create two same OUs in 389ds first and then> >>>>>> create the sync agreement. But I don't want this because I want all> >>>>>> accounts under the same ou in 389ds(no sub-ou).> >>>>>>> >>>>>>> >>>>>> I have another question about this issue.> >>>>>> After the two sync agreements created, I create a new user on AD side,> >>>>>> after 5 minutes(default), nothing happens, the account hasn't been> >>>>>> synced to 389ds correctly. I must click the "Initiate full> >>>>>> Re-syncronization" to sync the account info, and then change account> >>>>>> password on AD side manually so that the passsync can sync the> >>>>>> password.> >>>>>>> >>>>>>> My concern is moving an account from ou1 to ou2 and how> >>>>>>> that would work (or break).> >>>>>> Because the digestion is same OU in 389ds, so move an account from ou1> >>>>>> to ou2 on AD side, nothing happens .> >>>>>>> >>>>>>> >>>>>> Another issue is :> >>>>>> OnewaySync> >>>>>> I want all data flow is AD to 389ds.> >>>>>> I have configured the OnewaySync followed this link> >>>>>> https://directory.fedoraproject.org/docs/389ds/howto/howto-one-way-active-directory-sync.html> >>>>>> for every sync agreement, I add one line> >>>>>> oneWaySync: fromWindows> >>>>>>> >>>>>>> >>>>>> The error message /var/log/dirsrv/slapd-INSTANCE/errors like this:> >>>>>> [23/Aug/2019:08:14:58.033989856 +0800] - WARN - NSMMReplicationPlugin -> >>>>>> windows sync - windows_inc_run - agmt="cn=others" (tc-dc-2:389):> >>>>>> Replica has no update vector. It has never been initialized.> >>>>>> [23/Aug/2019:08:15:01.071494645 +0800] - WARN - NSMMReplicationPlugin -> >>>>>> windows sync - windows_inc_run - agmt="cn=others" (tc-dc-2:389):> >>>>>> Replica has no update vector. It has never been initialized.> >>>>>>> >>>>>> I don't want the sync agreement to be bi-directional. So how to resolve> >>>>>> this error message.> >>>>>> Thanks in advance!> >>>>>>> >>>>>>> >>>>>> Sincerely,> >>>>>> --> >>>>>> DaV> >>>>>>> >>>>>> On Fri, Aug 23, 2019, at 07:38, William Brown wrote:> >>>>>>>> >>>>>>>> >>>>>>>> On 21 Aug 2019, at 22:10, DaV <snowfrs@xxxxxxxxx> wrote:> >>>>>>>>> >>>>>>>> Hi guys,> >>>>>>>> Just update for this issue.> >>>>>>>>> >>>>>>>> Finally, I create multi windows sync agreement for each OU to sync the user account.> >>>>>>>> like this:> >>>>>>>>> >>>>>>>>> DS Host: 389ds:389> >>>>>>>>> Windows Host: dc01.example.com:389> >>>>>>>>> DS Subtree: ou=ou1,ou=Users,dc=example,dc=com> >>>>>>>>> Windows Subtree: OU=Accounts, DC=example,DC=com> >>>>>>>>> Replicated subtree: dc=example,dc=com> >>>>>>>>> >>>>>>>>> DS Host: 389ds:389> >>>>>>>>> Windows Host: dc01.example.com:389> >>>>>>>>> DS Subtree: ou=ou2,ou=Users,dc=example,dc=com> >>>>>>>>> Windows Subtree: OU=Accounts, DC=example,DC=com> >>>>>>>>> Replicated subtree: dc=example,dc=com> >>>>>>>> So the user account sync is done.> >>>>>>>>> >>>>>>>> For password sync, now I can't sync user's password with an " Initiate full Re-syncronization". I must reset all users one-by-one on AD server to sync the password. This is not convenient.> >>>>>>>>> >>>>>>>> Do you have any advice?> >>>>>>>>> >>>>>>>> >>>>>>> I think Mark is the person who knows the most about this. I agree your> >>>>>>> solution isn't really optimal here so I totally get you wanting to> >>>>>>> improve this. My concern is moving an account from ou1 to ou2 and how> >>>>>>> that would work (or break).> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>> This is the log info:> >>>>>>>>> [21/Aug/2019:08:56:57.876105371 +0800] - ERR - NSMMReplicationPlugin - windows sync - windows_tot_run - Beginning total update of replica "agmt="cn=chuxun" (tc-dc-2:389)".> >>>>>>>>> [21/Aug/2019:08:56:58.546297794 +0800] - ERR - NSMMReplicationPlugin - windows sync - windows_process_total_add - agmt="cn=chuxun" (tc-dc-2:389) - Cannot replay add operation.> >>>>>>>>> [21/Aug/2019:08:56:58.575112136 +0800] - ERR - NSMMReplicationPlugin - windows sync - bind_and_check_pwp - agmt="cn=chuxun" (tc-dc-2:389): Replication bind with SIMPLE auth resumed> >>>>>>>>> [21/Aug/2019:08:56:58.577280706 +0800] - WARN - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=chuxun" (tc-dc-2:389): Replica has no update vector. It has never been initialized.> >>>>>>>>> [21/Aug/2019:08:56:58.579569199 +0800] - WARN - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=chuxun" (tc-dc-2:389): Replica has no update vector. It has never been initialized.> >>>>>>>>> [21/Aug/2019:08:56:59.581808252 +0800] - WARN - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=wangxun" (tc-dc-2:389): Replica has no update vector. It has never been initialized.> >>>>>>>>> >>>>>>>> Sincerely,> >>>>>>>> --> >>>>>>>> DaV> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> On Tue, Aug 20, 2019, at 09:28, DaV wrote:> >>>>>>>>> Hi all,> >>>>>>>>> I'm using a new 389 directory server on CentOS 7.6 with 389-ds-base.x86_64 (1.3.8.4-15.el7), and I want to sync user and password from Windows 2016 to 389ds one way.> >>>>>>>>> The Synchronization Agreement like this:> >>>>>>>>> DS Host: 389ds:389> >>>>>>>>> Windows Host: dc01.example.com:389> >>>>>>>>> DS Subtree: ou=Users,dc=example,dc=com> >>>>>>>>> Windows Subtree: OU=Accounts, DC=example,DC=com> >>>>>>>>> Replicated subtree: dc=example,dc=com> >>>>>>>>>> >>>>>>>>> Here is my question:> >>>>>>>>> The sync agreement can only sync top-level OU=Accounts, DC=example, DC=com from Win2016 to 389ds server.> >>>>>>>>> In fact, I have> >>>>>>>>> ou=ou1,ou=accounts,dc=example,dc=com> >>>>>>>>> ou=ou2,ou=accounts,dc=example,dc=com> >>>>>>>>> on Win2016 server.> >>>>>>>>> I want the sync agreement can sync not only the top-level but also the child ou.> >>>>>>>>>> >>>>>>>>> This is the error log for your reference. Thanks!> >>>>>>>>>> [20/Aug/2019:07:58:40.307031692 +0800] - ERR - NSMMReplicationPlugin - windows sync - windows_tot_run - Beginning total update of replica "agmt="cn=389ds" (tc-dc-2:389)".> >>>>>>>>>> [20/Aug/2019:07:58:40.309113230 +0800] - INFO - slapd_daemon - slapd started. Listening on All Interfaces port 389 for LDAP requests> >>>>>>>>>> [20/Aug/2019:08:34:21.730939271 +0800] - WARN - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=389ds" (tc-dc-2:389): Replica has no update vector. It has never been initialized.> >>>>>>>>>> [20/Aug/2019:08:34:21.733526550 +0800] - WARN - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=389ds" (tc-dc-2:389): Replica has no update vector. It has never been initialized.> >>>>>>>>>> [20/Aug/2019:08:34:24.735819391 +0800] - WARN - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=389ds" (tc-dc-2:389): Replica has no update vector. It has never been initialized.> >>>>>>>>>> [20/Aug/2019:08:34:27.738228528 +0800] - WARN - NSMMReplicationPlugin - windows sync - windows_inc_run - agmt="cn=389ds" (tc-dc-2:389): Replica has no update vector. It has never been initialized.> >>>>>>>>>> [20/Aug/2019:08:34:30.873896680 +0800] - ERR - NSMMReplicationPlugin - windows sync - windows_tot_run - Beginning total update of replica "agmt="cn=389ds" (tc-dc-2:389)".> >>>>>>>>>> [20/Aug/2019:08:34:33.170822223 +0800] - ERR - NSMMReplicationPlugin - windows sync - windows_tot_run - Finished total update of replica "agmt="cn=389ds" (tc-dc-2:389)". Sent 5 entries.> >>>>>>>>>> [20/Aug/2019:08:34:33.186359842 +0800] - ERR - NSMMReplicationPlugin - windows sync - bind_and_check_pwp - agmt="cn=389ds" (tc-dc-2:389): Replication bind with SIMPLE auth resumed> >>>>>>>>>> [20/Aug/2019:08:47:30.032935119 +0800] - ERR - NSMMReplicationPlugin - windows sync - windows_tot_run - Beginning total update of replica "agmt="cn=389ds" (tc-dc-2:389)".> >>>>>>>>>> [20/Aug/2019:08:47:31.035850854 +0800] - ERR - NSMMReplicationPlugin - windows sync - windows_tot_run - Finished total update of replica "agmt="cn=389ds" (tc-dc-2:389)". Sent 5 entries.> >>>>>>>>>> [20/Aug/2019:08:47:31.051614890 +0800] - ERR - NSMMReplicationPlugin - windows sync - bind_and_check_pwp - agmt="cn=389ds" (tc-dc-2:389): Replication bind with SIMPLE auth resumed> >>>>>>>>>> [20/Aug/2019:08:50:59.533268105 +0800] - WARN - NSMMReplicationPlugin - prot_stop - Incremental protocol for replica "agmt="cn=389ds" (tc-dc-2:389)" did not shut down properly.> >>>>>>>>>> [20/Aug/2019:09:01:00.155477769 +0800] - WARN - NSMMReplicationPlugin - prot_stop - Total protocol for replica "agmt="cn=389ds" (tc-dc-2:389)" did not shut down properly.> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Sincerely,> >>>>>>>>> --> >>>>>>>>> DaV> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________> >>>>>>>> 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> >>>>>>>> >>>>>>> —> >>>>>>> Sincerely,> >>>>>>>> >>>>>>> William Brown> >>>>>>>> >>>>>>> Senior Software Engineer, 389 Directory Server> >>>>>>> SUSE Labs> >>>>>>> _______________________________________________> >>>>>>> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx> >>>>>>> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx> >>>>>>> Fedora Code of Conduct:> >>>>>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines> >>>>>>> List Archives:> >>>>>>>> >>>>>> _______________________________________________> >>>>>> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx> >>>>>> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx> >>>>>> Fedora Code of Conduct:> >>>>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines> >>>>>> List Archives:> >>>>>>> >>>>>> >>>>> _______________________________________________> >>>>> 389-users mailing list --> >>>>>> >>>>> To unsubscribe send an email to> >>>>>> >>>>> Fedora Code of Conduct:> >>>>>> >>>>> List Guidelines:> >>>>>> >>>>> List Archives:> >>>>>> >>>> --> >>>>> >>>> 389 Directory Server Development Team> >>>>> >>> >> —> >> Sincerely,> >>> >> William Brown> >>> >> Senior Software Engineer, 389 Directory Server> >> SUSE Labs> >>> >>>> —> Sincerely,>> William Brown>> Senior Software Engineer, 389 Directory Server> SUSE Labs>>_______________________________________________ 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-- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander_______________________________________________389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxxTo unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxxFedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ 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
