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
the 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 miutes
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 <snowfrs(a)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 <snowfrs(a)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...
> >>>>>
> >>>>>> 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...
> >>>>
> >>>> 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...
> >>>>>> 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(a)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(a)lists.fedoraproject.org
> >>>>>>>> To unsubscribe send an email to
389-users-leave(a)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.fedoraproje...
> >>>>>>>
> >>>>>>> —
> >>>>>>> Sincerely,
> >>>>>>>
> >>>>>>> William Brown
> >>>>>>>
> >>>>>>> Senior Software Engineer, 389 Directory Server
> >>>>>>> SUSE Labs
> >>>>>>> _______________________________________________
> >>>>>>> 389-users mailing list --
389-users(a)lists.fedoraproject.org
> >>>>>>> To unsubscribe send an email to
389-users-leave(a)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.fedoraproje...
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> 389-users mailing list --
389-users(a)lists.fedoraproject.org
> >>>>>> To unsubscribe send an email to
389-users-leave(a)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.fedoraproje...
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 389-users mailing list --
> >>>>> 389-users(a)lists.fedoraproject.org
> >>>>>
> >>>>> To unsubscribe send an email to
> >>>>> 389-users-leave(a)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.fedoraproje...
> >>>>>
> >>>> --
> >>>>
> >>>> 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(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)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.fedoraproje... , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric
Shander