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

2013-10-17 Thread Martin Kosek
On 10/17/2013 04:59 AM, Dmitri Pal wrote:
 On 10/15/2013 04:23 PM, janice.psyop wrote:
 Ah, well that makes sense then!

 I couldn't understand why the freeipa.org doc
 (http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup)  ends at at
 cross realm trust -- plus everything was working fine at that point,
 but I thought the FC18 docs had further instructions for sync agreements -- 
 it
 was ID10T error on my part! -- just blindly clicking next...

 So I'm just going to disconnect and delete the agreement and
 certs.  Actually, I may just start from scratch.  It was easy
 enough to do up until the point I mixed up the instructions.

 thanks very much clearing up my misunderstanding / pointing out the 
 obvious!!!

 And thanks for the link -- probably should watch that first  LOL.

 -J.




 On Tue, Oct 15, 2013 at 4:01 PM, Alexander Bokovoy aboko...@redhat.com 
 wrote:

 - Original Message -
 From: janice.psyop janice.ps...@gmail.com
 To: freeipa-users@redhat.com
 Sent: Tuesday, October 15, 2013 6:51:42 PM
 Subject: Re: [Freeipa-users] ipa sync agreement to AD DC is taking a very  
long time

 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.
 What I was trying to say is that you have misunderstood instructions and
 are doing wrong configuration that is not supported and never was meant to 
 exist.

 AD trusts are configured with 'ipa-adtrust-install' tool and trust is 
 established with 'ipa trust-add' command.
 We don't replicate any user and group related information from AD to IPA 
 LDAP when using AD trusts.

 AD replication is a totally separate technique and should not be combined 
 with AD trusts.
 This combination makes no sense, was not designed to be used together, and 
 is not supported.

 Therefore, your attempt to add AD replication to already configured AD 
 trusts is wrong.
 You need to chose what approach to take: either trusts or replication.

 Dmitri Pal presented AD integration options at DevConf.cz this year. His 
 talk is recorded
 and available at youtube: http://www.youtube.com/watch?v=cS6EJ1L7fRI and 
 slides are here:
 http://www.devconf.cz/slides/Linux-AD-Integration-Options.odp

 I'd recommend to watch this talk as it is most detailed explanation of 
 various options
 how to integrate POSIX and AD environments.
 --
 / Alexander Bokovoy
 
 I do not think it is stupid.
 I think we need to make sure that winsync is no mixed with trusts.
 IMO we should open two tickets:
 a) Add a check to trust-add to see if there is a sync agreement with AD
 and not try to create trust when sync agreement exists
 b) Add a check to replica manage tool to prevent sync agreement creation
 when there is a trust.

One ticket is sufficient, IMO. I filed it:

https://fedorahosted.org/freeipa/ticket/3976

I am just thinking if we want to make the check per AD domain - like havinf
trusts established with one AD forrest, but allow having winsync for another
forrest. Probably not...

Martin

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


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

2013-10-16 Thread Dmitri Pal
On 10/15/2013 04:23 PM, janice.psyop wrote:
 Ah, well that makes sense then!

 I couldn't understand why the freeipa.org doc
 (http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup)  ends at at
 cross realm trust -- plus everything was working fine at that point,
 but I thought the FC18 docs had further instructions for sync agreements -- 
 it
 was ID10T error on my part! -- just blindly clicking next...

 So I'm just going to disconnect and delete the agreement and
 certs.  Actually, I may just start from scratch.  It was easy
 enough to do up until the point I mixed up the instructions.

 thanks very much clearing up my misunderstanding / pointing out the obvious!!!

 And thanks for the link -- probably should watch that first  LOL.

 -J.




 On Tue, Oct 15, 2013 at 4:01 PM, Alexander Bokovoy aboko...@redhat.com 
 wrote:

 - Original Message -
 From: janice.psyop janice.ps...@gmail.com
 To: freeipa-users@redhat.com
 Sent: Tuesday, October 15, 2013 6:51:42 PM
 Subject: Re: [Freeipa-users] ipa sync agreement to AD DC is taking a very   
   long time

 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.
 What I was trying to say is that you have misunderstood instructions and
 are doing wrong configuration that is not supported and never was meant to 
 exist.

 AD trusts are configured with 'ipa-adtrust-install' tool and trust is 
 established with 'ipa trust-add' command.
 We don't replicate any user and group related information from AD to IPA 
 LDAP when using AD trusts.

 AD replication is a totally separate technique and should not be combined 
 with AD trusts.
 This combination makes no sense, was not designed to be used together, and 
 is not supported.

 Therefore, your attempt to add AD replication to already configured AD 
 trusts is wrong.
 You need to chose what approach to take: either trusts or replication.

 Dmitri Pal presented AD integration options at DevConf.cz this year. His 
 talk is recorded
 and available at youtube: http://www.youtube.com/watch?v=cS6EJ1L7fRI and 
 slides are here:
 http://www.devconf.cz/slides/Linux-AD-Integration-Options.odp

 I'd recommend to watch this talk as it is most detailed explanation of 
 various options
 how to integrate POSIX and AD environments.
 --
 / Alexander Bokovoy

I do not think it is stupid.
I think we need to make sure that winsync is no mixed with trusts.
IMO we should open two tickets:
a) Add a check to trust-add to see if there is a sync agreement with AD
and not try to create trust when sync agreement exists
b) Add a check to replica manage tool to prevent sync agreement creation
when there is a trust.

We might in future have to support some interim state when we define a
migration procedure which we currently do not have.

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


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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


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

2013-10-15 Thread Alexander Bokovoy

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:45Z2706MainThread  ipa INFOAdded new
sync agreement, waiting for it to become ready . . .
2013-10-14T21:32:46Z2706MainThread  ipa INFOReplication
Update in progress: FALSE: status: 0 Replica acquired successfully:
Incremental update started: start: 0: end: 0
2013-10-14T21:32:46Z2706MainThread  ipa INFOAgreement
is ready, starting replication . . .

Try to change some user data on AD side, it would trigger update of the
IPA side.

--
/ Alexander Bokovoy

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


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

2013-10-15 Thread Rich Megginson

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:45Z2706MainThread  ipa INFO Added new
sync agreement, waiting for it to become ready . . .
2013-10-14T21:32:46Z2706MainThread  ipa INFO Replication
Update in progress: FALSE: status: 0 Replica acquired successfully:
Incremental update started: start: 0: end: 0
2013-10-14T21:32:46Z2706MainThread  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


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

2013-10-15 Thread janice.psyop
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 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:45Z2706MainThread  ipa INFO Added new
 sync agreement, waiting for it to become ready . . .
 2013-10-14T21:32:46Z2706MainThread  ipa INFO Replication
 Update in progress: FALSE: status: 0 Replica acquired successfully:
 

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

2013-10-15 Thread Rich Megginson

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 

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

2013-10-15 Thread janice.psyop
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.
[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?


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,
 

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

2013-10-15 Thread Rich Megginson

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

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

2013-10-15 Thread Alexander Bokovoy


- Original Message -
 From: janice.psyop janice.ps...@gmail.com
 To: freeipa-users@redhat.com
 Sent: Tuesday, October 15, 2013 6:51:42 PM
 Subject: Re: [Freeipa-users] ipa sync agreement to AD DC is taking a very 
 long time
 
 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.
What I was trying to say is that you have misunderstood instructions and 
are doing wrong configuration that is not supported and never was meant to 
exist.

AD trusts are configured with 'ipa-adtrust-install' tool and trust is 
established with 'ipa trust-add' command.
We don't replicate any user and group related information from AD to IPA LDAP 
when using AD trusts.

AD replication is a totally separate technique and should not be combined with 
AD trusts. 
This combination makes no sense, was not designed to be used together, and is 
not supported.

Therefore, your attempt to add AD replication to already configured AD trusts 
is wrong.
You need to chose what approach to take: either trusts or replication.

Dmitri Pal presented AD integration options at DevConf.cz this year. His talk 
is recorded
and available at youtube: http://www.youtube.com/watch?v=cS6EJ1L7fRI and slides 
are here: 
http://www.devconf.cz/slides/Linux-AD-Integration-Options.odp

I'd recommend to watch this talk as it is most detailed explanation of various 
options
how to integrate POSIX and AD environments.
-- 
/ Alexander Bokovoy

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


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

2013-10-14 Thread Nathan Kinder

On 10/14/2013 08:26 PM, 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.


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.

It's definitely hung up.  2k users should be very quick to sync.


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 http://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:
Is there anything of interest in the 389 DS errors log?  It's located at 
/var/log/dirsrv/slapd-realm/errors.


Thanks,
-NGK



2013-10-14T21:32:45Z2706MainThread  ipa INFOAdded new 
sync agreement, waiting for it to become ready . . .
2013-10-14T21:32:46Z2706MainThread  ipa INFO   
 Replication Update in progress: FALSE: status: 0 Replica acquired 
successfully: Incremental update started: start: 0: end: 0
2013-10-14T21:32:46Z2706MainThread  ipa INFOAgreement 
is ready, starting replication . . .



thanks much,
-J.


___
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