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_open
So I will check why win2k16 can't open.
BTW, I have many windows sync agreements, but I only see one agmt debug log.
Sincerely,
--
DaV
On Thu, Aug 29, 2019, at 07:23, William Brown wrote:
>
>
> > On 27 Aug 2019, at 11:25, DaV <snow...@gmail.com> 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 <snow...@gmail.com> 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
> >>>>> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/using_windows_sync-modifying_the_sync_agreement
> >>>>>
> >>>>>> 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.
> >>>> https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/configuration_command_and_file_reference/core_server_configuration_reference#Replication_Attributes_under_cnReplicationAgreementName_cnreplica_cnsuffixName_cnmapping_tree_cnconfig-nsDS5ReplicaUpdateSchedule
> >>>>
> >>>> 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 <snow...@gmail.com> 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@lists.fedoraproject.org
> >>>>>>>> To unsubscribe send an email to
> >>>>>>>> 389-users-le...@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/389-users@lists.fedoraproject.org
> >>>>>>>
> >>>>>>> —
> >>>>>>> Sincerely,
> >>>>>>>
> >>>>>>> William Brown
> >>>>>>>
> >>>>>>> Senior Software Engineer, 389 Directory Server
> >>>>>>> SUSE Labs
> >>>>>>> _______________________________________________
> >>>>>>> 389-users mailing list -- 389-users@lists.fedoraproject.org
> >>>>>>> To unsubscribe send an email to
> >>>>>>> 389-users-le...@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/389-users@lists.fedoraproject.org
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> 389-users mailing list -- 389-users@lists.fedoraproject.org
> >>>>>> To unsubscribe send an email to 389-users-le...@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/389-users@lists.fedoraproject.org
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 389-users mailing list --
> >>>>> 389-users@lists.fedoraproject.org
> >>>>>
> >>>>> To unsubscribe send an email to
> >>>>> 389-users-le...@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/389-users@lists.fedoraproject.org
> >>>>>
> >>>> --
> >>>>
> >>>> 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@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@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/389-users@lists.fedoraproject.org
