On 10/15/2013 12:32 PM, janice.psyop wrote:
Found out that ns-slapd was not running/was dead ("No such process not
running, but pid file exists")  -- discovered that when I tried to do
the ldapmodify and got the "ldap_sasl_bind(SIMPLE): Can't contact LDAP
server (-1)" error.


Anyway, I started dirsrv and did the ldapmodify with more verbosity
and this is the error log:

[15/Oct/2013:14:04:12 -0400] - 389-Directory/1.2.11.15 B2013.240.174 starting up
[15/Oct/2013:14:04:12 -0400] - WARNING: userRoot: entry cache size
10485760B is less than db size 10706944B; We recommend to increase the
entry cache size nsslapd-cachememsize.
[15/Oct/2013:14:04:12 -0400] - Detected Disorderly Shutdown last time
Directory Server was running, recovering database.

Hmm - this usually happens after a crash.
Please read http://port389.org/wiki/FAQ#Debugging_Crashes to enable the system to produce core files, and to get a stack trace.

[15/Oct/2013:14:04:12 -0400] schema-compat-plugin - warning: no
entries set up under cn=computers, cn=compat,dc=ipany
[15/Oct/2013:14:04:13 -0400] schema-compat-plugin - warning: no
entries set up under cn=ng, cn=compat,dc=ipany
[15/Oct/2013:14:04:13 -0400] schema-compat-plugin - warning: no
entries set up under ou=sudoers,dc=ipany
[15/Oct/2013:14:04:13 -0400] - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be
added before the CoS Definition.
[15/Oct/2013:14:04:14 -0400] - Skipping CoS Definition cn=Password
Policy,cn=accounts,dc=ipany--no CoS Templates found, which should be
added before the CoS Definition.
[15/Oct/2013:14:04:14 -0400] - slapd started.  Listening on All
Interfaces port 389 for LDAP requests
[15/Oct/2013:14:04:14 -0400] - Listening on All Interfaces port 636
for LDAPS requests
[15/Oct/2013:14:04:14 -0400] - Listening on
/var/run/slapd-IPAPSYOP.socket for LDAPI requests
[15/Oct/2013:14:04:14 -0400] NSMMReplicationPlugin - Beginning total
update of replica "agmt="cn=meTodc02.domain.com" (dc02:389)".
[15/Oct/2013:14:04:30 -0400] - Entry
"uid=nfsusercrenshaw,cn=users,cn=accounts,dc=ipany" missing attribute
"sn" required by object class "person"
[snip]


this is a tail of the slapd-IPNY/access log:

[15/Oct/2013:14:24:08 -0400] conn=10 op=2 BIND dn="" method=sasl
version=3 mech=GSSAPI
[15/Oct/2013:14:24:08 -0400] conn=10 op=0 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[15/Oct/2013:14:24:08 -0400] conn=10 op=3 SRCH base="" scope=0
filter="(objectClass=*)" attrs="supportedControl"
[15/Oct/2013:14:24:08 -0400] conn=10 op=3 RESULT err=0 tag=101
nentries=1 etime=0
[15/Oct/2013:14:24:08 -0400] conn=10 op=4 SRCH
base="cn=ad,cn=trusts,dc=ipany" scope=2
filter="(objectClass=ipaNTTrustedDomain)" attrs=ALL
[15/Oct/2013:14:24:08 -0400] conn=10 op=4 RESULT err=0 tag=101
nentries=1 etime=0
[15/Oct/2013:14:24:08 -0400] conn=10 op=2 RESULT err=0 tag=97
nentries=0 etime=0
dn="krbprincipalname=cifs/nymipa.ipany.domain.com@ipany,cn=services,cn=accounts,dc=ipany"


How can I tell if the winsync update finished?  Is there a query
command or other log file?
If you use the repl (8192) log level, it should tell you.


Thanks very much for all the help!
-J.



On Tue, Oct 15, 2013 at 11:58 AM, Rich Megginson <rmegg...@redhat.com> wrote:
On 10/15/2013 09:51 AM, janice.psyop wrote:
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

This is odd.  Looks like fractional replication is not supported by winsync,
but ipa-replica-manage is trying to use it.  But this should not cause any
problems.


[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.

This is normal when you first create the winsync agreement but have not yet
initialized it.


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

I'm not sure if this winsync update finished - please turn on the 8192 log
level and see what it is doing.  If that shows nothing, then try
ipa-replica-manage re-initialize .... It looks like winsync is already
"connected".


thanks,
-J.

On Tue, Oct 15, 2013 at 9:26 AM, Rich Megginson <rmegg...@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
_______________________________________________

Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to