[Freeipa-users] ipa sync agreement to AD DC is taking a very long time

Tue Oct 15 15:51:42 UTC 2013

Thanks for the replies.

I checked this morning and it was still hung up on "Update in progess"
so I killed it.

@Alexander: Yes, I had already established a trust with our AD DC.  I
was doing step " 9.4.2. Creating Synchronization Agreements"
(FreeIPA_Guide/managing-sync-agmt.html)    I've been following the
guide step-by-step.

Here is the slapd-REALM/errors log (I truncated most of the repeating
missing attribute errors, but the last line is really the last line in
the log).  I don't see any glaring errors:

# cat /var/log/dirsrv/slapd-IPANY/errors
        389-Directory/1.2.11.15 B2013.240.174
        nymipa.ipany.domain.com:636 (/etc/dirsrv/slapd-IPANY)

[14/Oct/2013:17:32:43 -0400] - 389-Directory/1.2.11.15 B2013.240.174 starting up
[14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no
entries set up under cn=computers, cn=compat,dc=ipany
[14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no
entries set up under cn=ng, cn=compat,dc=ipany
[14/Oct/2013:17:32:43 -0400] schema-compat-plugin - warning: no
entries set up under ou=sudoers,dc=ipany
[14/Oct/2013:17:32:44 -0400] - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be
added before the CoS Definition.
[14/Oct/2013:17:32:44 -0400] - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be
added before the CoS Definition.
[14/Oct/2013:17:32:44 -0400] - slapd started.  Listening on All
Interfaces port 389 for LDAP requests
[14/Oct/2013:17:32:44 -0400] - Listening on All Interfaces port 636
for LDAPS requests
[14/Oct/2013:17:32:44 -0400] - Listening on
/var/run/slapd-IPANY.socket for LDAPI requests
[14/Oct/2013:17:32:45 -0400] - Entry
"cn=meTodc02.domain.com,cn=replica,cn=dc\3Dipany,cn=mapping
tree,cn=config" -- attribute "nsDS5ReplicatedAttributeListTotal" not
allowed
[14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin -
agmt="cn=meTodc02.domain.com" (dc02:389): Replica has no update
vector. It has never been initialized.
[14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin -
agmt="cn=meTodc02.domain.com" (dc02:389): Replica has no update
vector. It has never been initialized.
[14/Oct/2013:17:32:45 -0400] NSMMReplicationPlugin -
agmt="cn=meTodc02.domain.com" (dc02:389): Replica has no update
vector. It has never been initialized.
[14/Oct/2013:17:32:47 -0400] NSMMReplicationPlugin - Beginning total
update of replica "agmt="cn=meTodc02.domain.com" (dc02:389)".
[14/Oct/2013:17:32:49 -0400] - Entry
"uid=nfsuser,cn=users,cn=accounts,dc=ipany" missing attribute "sn"
required by object class "person"
[14/Oct/2013:17:32:49 -0400] - Entry
"uid=tapeop,cn=users,cn=accounts,dc=ipany" missing attribute "sn"
required by object class "person"
[14/Oct/2013:17:33:14 -0400] - Entry
"uid=nfsuserevs,cn=users,cn=accounts,dc=ipany" missing attribute "sn"
required by object class "person"
[14/Oct/2013:17:33:14 -0400] - Entry
"uid=nfsuserbk01,cn=users,cn=accounts,dc=ipany" missing attribute "sn"
required by object class "person"

Should I go ahead and enable a more verbose log level (8192) and
re-run the ipa-replica-manage connect --winsync ....  again?  I killed
the process this morning so would I need to do any type of "clean up"
before re-running?

thanks,
-J.

On Tue, Oct 15, 2013 at 9:26 AM, Rich Megginson <rmeggins at redhat.com> wrote:
> On 10/15/2013 01:22 AM, Alexander Bokovoy wrote:
>>
>> On Mon, 14 Oct 2013, janice.psyop wrote:
>>
>>> Hi,
>>>
>>> I've been setting up an IPA server (centos 6.4) with AD trust (2008R2
>>> domain) following the FC18 freeipa guide.
>>
>> AD trusts is different from AD sync agreement.
>>
>> What you describe below is use of passsync/winsync (AD sync), not AD
>> trusts. Just to make sure we are on the same level here.
>>>
>>>
>>> Everything has gone smoothly until I ran the ipa-replica-manage connect
>>> command to the AD DC and it seems to be running (no errors on std out and
>>> ps says it is still running), but it has been running for six hours!  We
>>> do
>>> have ~2000 user entries,  but I didn't think it would take this long to
>>> sync up.
>>>
>>> The command I ran was this (see below) and the screen now just displays
>>> repeating "Update in progress".  I'm very tempted to kill it in case
>>> something is going horribly wrong (with the AD user accounts...)
>>>
>>> /usr/sbin/ipa-replica-manage connect --winsync
>>> --passsync=MySecretPass
>>> --binddn=CN=myipasyncuser,CN=Users,DC=domain,DC=com
>>> --bindpw=MySecretPass
>>> --cacert=/etc/openldap/cacerts/DC-CA.cer
>>> -v dc.domain.com
>>>
>>>
>>> Update in progress
>>> Update in progress
>>> Update in progress
>>> Update in progress
>>> Update in progress
>>> Update in progress
>>> Update in progress
>>>
>>>
>>> Is there any way to check the progress of this in case it is in fact hung
>>> up?  The last few entries in the ipa/default.log is from six hours ago:
>>>
>>>
>>> 2013-10-14T21:32:45Z    2706    MainThread      ipa     INFO Added new
>>> sync agreement, waiting for it to become ready . . .
>>> 2013-10-14T21:32:46Z    2706    MainThread      ipa     INFO Replication
>>> Update in progress: FALSE: status: 0 Replica acquired successfully:
>>> Incremental update started: start: 0: end: 0
>>> 2013-10-14T21:32:46Z    2706    MainThread      ipa     INFO Agreement
>>> is ready, starting replication . . .
>>
>> Try to change some user data on AD side, it would trigger update of the
>> IPA side.
>>
> Take a look at the 389 errors log - /var/log/dirsrv/slapd-YOUR-DOMAIN/errors
> - anything in there?
> If not, then you can turn on replication/sync error logging
> http://port389.org/wiki/FAQ#Troubleshooting