Re: [389-users] 389ds + modrdn + NSMMReplicationPlugin - Consumer failed to replay change

[Derek Belcher]

Here is the error message that I am receiving in
/var/log/dirsrv/slap-/errors :

[13/Nov/2012:20:13:27 -0600] NSMMReplicationPlugin - agmt="cn=sync001" (
AD1.company.net:636): Consumer failed to replay change (uniqueid
754ce981-e4d411e1-b828c127-7d7e145e, CSN 50a150a40002): Server is
unwilling to perform. Will retry later.

Thanks again for your time.


On Tue, Nov 13, 2012 at 5:38 PM, Derek Belcher wrote:

> Good evening,
>
> I am requesting some help from the community, I have an issue that I can
> not seem to resolve.
>
> Yesterday I committed a change on a users DN and today I noticed
> replication issues in my logs. The logs told me the uniqueid # and CSN #
>
> So I used cl-dump to dump the changelog into a file. Here are the results
> of what I grep'ed out:
>
>
> [root@ds]# grep "50a150a40002" -B2 -A13 /var/tmp/change.dump
> changetype: modrdn
> replgen: 4ff8a4c1
> csn: 50a150a40002
> nsuniqueid: 754ce981-e4d411e1-b828c127-7d7e145e
> dn: uid=auser,ou=threataa,ou=ops,ou=groups,dc=company,dc=net
> newrdn: uid=auser
> deleteoldrdn: false
> newsuperiordn: ou=threatbb,ou=ops,ou=groups,dc=company,dc=net
> change::
> replace: modifiersname
> modifiersname: cn=directory manager
> -
> replace: modifytimestamp
> modifytimestamp: 20121112194019Z
> -
>
> So now that I know what entry NSMReplicationPlugin is complaining about, I
> don't know what to do in order to fix it and get replication back on track.
>
> I really appreciate any help on this matter, Thank you
>
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Password + anything works ?

[Gordon Messmer]

On 11/13/2012 03:51 AM, Ali Jawad wrote:

*LDAP password information update failed: Confidentiality required*


PAM is attempting to use the password change extended operation.  I 
believe that only happens when /etc/ldap.conf contains "pam_password 
exop".  If you don't care at all about security, you can configure 
"pam_password clear", which should work.  You're a lot better off 
creating a certificate and adding it to the client as a CA, though.

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] 389ds + modrdn + NSMMReplicationPlugin - Consumer failed to replay change

[Derek Belcher]

Good evening,

I am requesting some help from the community, I have an issue that I can
not seem to resolve.

Yesterday I committed a change on a users DN and today I noticed
replication issues in my logs. The logs told me the uniqueid # and CSN #

So I used cl-dump to dump the changelog into a file. Here are the results
of what I grep'ed out:


[root@ds]# grep "50a150a40002" -B2 -A13 /var/tmp/change.dump
changetype: modrdn
replgen: 4ff8a4c1
csn: 50a150a40002
nsuniqueid: 754ce981-e4d411e1-b828c127-7d7e145e
dn: uid=auser,ou=threataa,ou=ops,ou=groups,dc=company,dc=net
newrdn: uid=auser
deleteoldrdn: false
newsuperiordn: ou=threatbb,ou=ops,ou=groups,dc=company,dc=net
change::
replace: modifiersname
modifiersname: cn=directory manager
-
replace: modifytimestamp
modifytimestamp: 20121112194019Z
-

So now that I know what entry NSMReplicationPlugin is complaining about, I
don't know what to do in order to fix it and get replication back on track.

I really appreciate any help on this matter, Thank you
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] MMR issue ...

[Rich Megginson]

On 11/13/2012 01:54 PM, Reinhard Nappert wrote:


There are a lot of RST for the time frame, especially on Server A.

I also see a lot TCP Retransmission for this particular replication 
session. I also see a couple of TCP Dup ACKs. Is this enough to cause 
the issue?


The RST would cause the connection to be closed.  Other than that, not 
sure what specifically would cause timeouts.


Of course, I don’t have an idea, what is the cause of that!

*From:*Rich Megginson [mailto:rmegg...@redhat.com]
*Sent:* Tuesday, November 13, 2012 1:57 PM
*To:* Reinhard Nappert
*Cc:* General discussion list for the 389 Directory server project.
*Subject:* Re: [389-users] MMR issue ...

On 11/13/2012 11:53 AM, Reinhard Nappert wrote:

How would you proceed to figure out what is going on there?


Since it doesn't appear that the replication logs are giving enough 
information, and you don't see any disconnects or TCP resets happening 
in the packet capture, then I guess you have no choice but to 
familiarize yourself with the source code and use gdb.



You see that I ran out of ideas!

Thanks

*From:*Rich Megginson [mailto:rmegg...@redhat.com]
*Sent:* Tuesday, November 13, 2012 1:32 PM
*To:* Reinhard Nappert
*Cc:* General discussion list for the 389 Directory server project.
*Subject:* Re: [389-users] MMR issue ...

On 11/13/2012 11:21 AM, Reinhard Nappert wrote:

The 3 servers do not crash.

I am not sure about the network, though. My first assumption was that 
the firewall (between A and B) might cause the issue. The latest 
occurrence (the one, I described) had the firewall removed. I see 
quite some TCP Retransmissions in the packet captures. Could that be 
the issue?



That could be, although that would mean there are so many tcp 
retransmissions that take such a long time to process that it causes 
the application to think the network connection has timed out.




-Reinhard

*From:*Rich Megginson [mailto:rmegg...@redhat.com]
*Sent:* Tuesday, November 13, 2012 1:15 PM
*To:* General discussion list for the 389 Directory server project.
*Cc:* Reinhard Nappert
*Subject:* Re: [389-users] MMR issue ...

On 11/13/2012 11:02 AM, Reinhard Nappert wrote:

Rich,

Do you know what the cause of this issue is?


No, I don't know.




You would expect that you saw this issue in different deployments, but 
I only saw it in one instance.


If it turns out that the issue I see is identical the issue, you 
mentioned, I’d like to know, when it was fixed.



Upon further investigation, this does not appear to be the same as 
https://fedorahosted.org/389/ticket/374


I'm not sure what the problem is.  I've seen timeouts when servers 
crash or there are network issues.





Thanks,

-Reinhard

*From:*389-users-boun...@lists.fedoraproject.org 
 
[mailto:389-users-boun...@lists.fedoraproject.org] *On Behalf Of 
*Reinhard Nappert

*Sent:* Tuesday, November 13, 2012 12:22 PM
*To:* Rich Megginson; General discussion list for the 389 Directory 
server project.

*Subject:* Re: [389-users] MMR issue ...

I use 1.2.8.2

*From:*Rich Megginson [mailto:rmegg...@redhat.com]
*Sent:* Tuesday, November 13, 2012 12:18 PM
*To:* General discussion list for the 389 Directory server project.
*Cc:* Reinhard Nappert
*Subject:* Re: [389-users] MMR issue ...

On 11/13/2012 09:24 AM, Reinhard Nappert wrote:

Hi,

I’ve encountered issues with a MMR setup, which looks like the following:

 A --- B

   \   /

 \   /

   \   /

 C

The replication works for approximately 24 hours. There are not many 
changes to the content anyway. After about 1 day, the attribute  value 
of the type “nsds5replicaLastUpdateStatus”  changes to “1 Can't 
acquire busy replica “ of the replication agreement object from type 
“nsDS5ReplicationAgreement”.  I see this message on C for the 
agreement “C-to-B”.  The start-time of the last update is 01:08:33. 
 When I check the status on B, it looks fine for “B-to-C” and 
“B-to-A”, however, the start-time of the last update is stuck at 
01:08:36 for “B-to-C”, whereas A gets updated afterwards as well. I 
don’t have the values for A!


When, I check errors and access on the boxes, I see the following:

Errors on A:

[10/Nov/2012:01:19:31 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Warning: unable to receive endReplication extended operation 
response (Timed out)


[10/Nov/2012:01:25:01 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Unable to receive the response for a startReplication 
extended operation to consumer (Can't contact LDAP server). Will retry 
later.


[10/Nov/2012:01:25:05 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Replication bind with SIMPLE auth resumed


[10/Nov/2012:02:26:29 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Unable to receive the response for a startReplication 
extended operation to consumer (Timed out). Will retry later.


[10/Nov/2012:02:31:55 -0300] NSMMReplica

Re: [389-users] MMR issue ...

[Rich Megginson]

On 11/13/2012 11:53 AM, Reinhard Nappert wrote:


How would you proceed to figure out what is going on there?



Since it doesn't appear that the replication logs are giving enough 
information, and you don't see any disconnects or TCP resets happening 
in the packet capture, then I guess you have no choice but to 
familiarize yourself with the source code and use gdb.



You see that I ran out of ideas!

Thanks

*From:*Rich Megginson [mailto:rmegg...@redhat.com]
*Sent:* Tuesday, November 13, 2012 1:32 PM
*To:* Reinhard Nappert
*Cc:* General discussion list for the 389 Directory server project.
*Subject:* Re: [389-users] MMR issue ...

On 11/13/2012 11:21 AM, Reinhard Nappert wrote:

The 3 servers do not crash.

I am not sure about the network, though. My first assumption was that 
the firewall (between A and B) might cause the issue. The latest 
occurrence (the one, I described) had the firewall removed. I see 
quite some TCP Retransmissions in the packet captures. Could that be 
the issue?



That could be, although that would mean there are so many tcp 
retransmissions that take such a long time to process that it causes 
the application to think the network connection has timed out.



-Reinhard

*From:*Rich Megginson [mailto:rmegg...@redhat.com]
*Sent:* Tuesday, November 13, 2012 1:15 PM
*To:* General discussion list for the 389 Directory server project.
*Cc:* Reinhard Nappert
*Subject:* Re: [389-users] MMR issue ...

On 11/13/2012 11:02 AM, Reinhard Nappert wrote:

Rich,

Do you know what the cause of this issue is?


No, I don't know.



You would expect that you saw this issue in different deployments, but 
I only saw it in one instance.


If it turns out that the issue I see is identical the issue, you 
mentioned, I’d like to know, when it was fixed.



Upon further investigation, this does not appear to be the same as 
https://fedorahosted.org/389/ticket/374


I'm not sure what the problem is.  I've seen timeouts when servers 
crash or there are network issues.




Thanks,

-Reinhard

*From:*389-users-boun...@lists.fedoraproject.org 
 
[mailto:389-users-boun...@lists.fedoraproject.org] *On Behalf Of 
*Reinhard Nappert

*Sent:* Tuesday, November 13, 2012 12:22 PM
*To:* Rich Megginson; General discussion list for the 389 Directory 
server project.

*Subject:* Re: [389-users] MMR issue ...

I use 1.2.8.2

*From:*Rich Megginson [mailto:rmegg...@redhat.com]
*Sent:* Tuesday, November 13, 2012 12:18 PM
*To:* General discussion list for the 389 Directory server project.
*Cc:* Reinhard Nappert
*Subject:* Re: [389-users] MMR issue ...

On 11/13/2012 09:24 AM, Reinhard Nappert wrote:

Hi,

I’ve encountered issues with a MMR setup, which looks like the following:

 A --- B

   \   /

 \   /

   \   /

 C

The replication works for approximately 24 hours. There are not many 
changes to the content anyway. After about 1 day, the attribute  value 
of the type “nsds5replicaLastUpdateStatus”  changes to “1 Can't 
acquire busy replica “ of the replication agreement object from type 
“nsDS5ReplicationAgreement”.  I see this message on C for the 
agreement “C-to-B”.  The start-time of the last update is 01:08:33. 
 When I check the status on B, it looks fine for “B-to-C” and 
“B-to-A”, however, the start-time of the last update is stuck at 
01:08:36 for “B-to-C”, whereas A gets updated afterwards as well. I 
don’t have the values for A!


When, I check errors and access on the boxes, I see the following:

Errors on A:

[10/Nov/2012:01:19:31 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Warning: unable to receive endReplication extended operation 
response (Timed out)


[10/Nov/2012:01:25:01 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Unable to receive the response for a startReplication 
extended operation to consumer (Can't contact LDAP server). Will retry 
later.


[10/Nov/2012:01:25:05 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Replication bind with SIMPLE auth resumed


[10/Nov/2012:02:26:29 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Unable to receive the response for a startReplication 
extended operation to consumer (Timed out). Will retry later.


[10/Nov/2012:02:31:55 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Unable to receive the response for a startReplication 
extended operation to consumer (Can't contact LDAP server). Will retry 
later.


[10/Nov/2012:02:31:59 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Replication bind with SIMPLE auth resumed


[10/Nov/2012:02:43:36 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Unable to receive the response for a startReplication 
extended operation to consumer (Timed out). Will retry later.


[10/Nov/2012:03:03:00 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Unable to receive the response for a startReplication 
extended operation to consumer (Timed out). W

Re: [389-users] MMR issue ...

[Rich Megginson]

On 11/13/2012 11:21 AM, Reinhard Nappert wrote:


The 3 servers do not crash.

I am not sure about the network, though. My first assumption was that 
the firewall (between A and B) might cause the issue. The latest 
occurrence (the one, I described) had the firewall removed. I see 
quite some TCP Retransmissions in the packet captures. Could that be 
the issue?




That could be, although that would mean there are so many tcp 
retransmissions that take such a long time to process that it causes the 
application to think the network connection has timed out.



-Reinhard

*From:*Rich Megginson [mailto:rmegg...@redhat.com]
*Sent:* Tuesday, November 13, 2012 1:15 PM
*To:* General discussion list for the 389 Directory server project.
*Cc:* Reinhard Nappert
*Subject:* Re: [389-users] MMR issue ...

On 11/13/2012 11:02 AM, Reinhard Nappert wrote:

Rich,

Do you know what the cause of this issue is?


No, I don't know.


You would expect that you saw this issue in different deployments, but 
I only saw it in one instance.


If it turns out that the issue I see is identical the issue, you 
mentioned, I’d like to know, when it was fixed.



Upon further investigation, this does not appear to be the same as 
https://fedorahosted.org/389/ticket/374


I'm not sure what the problem is.  I've seen timeouts when servers 
crash or there are network issues.



Thanks,

-Reinhard

*From:*389-users-boun...@lists.fedoraproject.org 
 
[mailto:389-users-boun...@lists.fedoraproject.org] *On Behalf Of 
*Reinhard Nappert

*Sent:* Tuesday, November 13, 2012 12:22 PM
*To:* Rich Megginson; General discussion list for the 389 Directory 
server project.

*Subject:* Re: [389-users] MMR issue ...

I use 1.2.8.2

*From:*Rich Megginson [mailto:rmegg...@redhat.com]
*Sent:* Tuesday, November 13, 2012 12:18 PM
*To:* General discussion list for the 389 Directory server project.
*Cc:* Reinhard Nappert
*Subject:* Re: [389-users] MMR issue ...

On 11/13/2012 09:24 AM, Reinhard Nappert wrote:

Hi,

I’ve encountered issues with a MMR setup, which looks like the following:

 A --- B

   \   /

 \   /

   \   /

 C

The replication works for approximately 24 hours. There are not many 
changes to the content anyway. After about 1 day, the attribute  value 
of the type “nsds5replicaLastUpdateStatus”  changes to “1 Can't 
acquire busy replica “ of the replication agreement object from type 
“nsDS5ReplicationAgreement”.  I see this message on C for the 
agreement “C-to-B”.  The start-time of the last update is 01:08:33. 
 When I check the status on B, it looks fine for “B-to-C” and 
“B-to-A”, however, the start-time of the last update is stuck at 
01:08:36 for “B-to-C”, whereas A gets updated afterwards as well. I 
don’t have the values for A!


When, I check errors and access on the boxes, I see the following:

Errors on A:

[10/Nov/2012:01:19:31 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Warning: unable to receive endReplication extended operation 
response (Timed out)


[10/Nov/2012:01:25:01 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Unable to receive the response for a startReplication 
extended operation to consumer (Can't contact LDAP server). Will retry 
later.


[10/Nov/2012:01:25:05 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Replication bind with SIMPLE auth resumed


[10/Nov/2012:02:26:29 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Unable to receive the response for a startReplication 
extended operation to consumer (Timed out). Will retry later.


[10/Nov/2012:02:31:55 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Unable to receive the response for a startReplication 
extended operation to consumer (Can't contact LDAP server). Will retry 
later.


[10/Nov/2012:02:31:59 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Replication bind with SIMPLE auth resumed


[10/Nov/2012:02:43:36 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Unable to receive the response for a startReplication 
extended operation to consumer (Timed out). Will retry later.


[10/Nov/2012:03:03:00 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Unable to receive the response for a startReplication 
extended operation to consumer (Timed out). Will retry later.


[10/Nov/2012:03:08:24 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Unable to receive the response for a startReplication 
extended operation to consumer (Can't contact LDAP server). Will retry 
later.


[10/Nov/2012:03:11:35 -0300] slapi_ldap_bind - Error: could not send 
bind request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 
(Can't connect to the LDAP server) -5961 (TCP connection reset by 
peer.) 115 (Operation now in progress)


[10/Nov/2012:03:11:35 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" 
(B:389): Replication bind with SIMPLE auth failed: LDAP error 91 
(Can't connect to the 

Re: [389-users] MMR issue ...

[David Boreham]

On 11/13/2012 11:15 AM, Rich Megginson wrote:



You would expect that you saw this issue in different deployments, 
but I only saw it in one instance.


If it turns out that the issue I see is identical the issue, you 
mentioned, I’d like to know, when it was fixed.




Upon further investigation, this does not appear to be the same as 
https://fedorahosted.org/389/ticket/374


I'm not sure what the problem is.  I've seen timeouts when servers 
crash or there are network issues.


That bug can be triggered by a "bogged down" server where one repl 
operation takes so long to execute that the supplier times out and sends 
another. Then if you're unlucky you can get the race condition between 
the two concurrently executing operations in the consumer.




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] MMR issue ...

[Reinhard Nappert]

Rich,

Do you know what the cause of this issue is? You would expect that you saw this 
issue in different deployments, but I only saw it in one instance.

If it turns out that the issue I see is identical the issue, you mentioned, I’d 
like to know, when it was fixed.

Thanks,
-Reinhard

From: 389-users-boun...@lists.fedoraproject.org 
[mailto:389-users-boun...@lists.fedoraproject.org] On Behalf Of Reinhard Nappert
Sent: Tuesday, November 13, 2012 12:22 PM
To: Rich Megginson; General discussion list for the 389 Directory server 
project.
Subject: Re: [389-users] MMR issue ...

I use 1.2.8.2

From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Tuesday, November 13, 2012 12:18 PM
To: General discussion list for the 389 Directory server project.
Cc: Reinhard Nappert
Subject: Re: [389-users] MMR issue ...

On 11/13/2012 09:24 AM, Reinhard Nappert wrote:
Hi,

I’ve encountered issues with a MMR setup, which looks like the following:

 A --- B
   \   /
 \   /
   \   /
 C

The replication works for approximately 24 hours. There are not many changes to 
the content anyway. After about 1 day, the attribute  value of the type 
“nsds5replicaLastUpdateStatus”  changes to “1 Can't acquire busy replica “ of 
the replication agreement object from type “nsDS5ReplicationAgreement”.  I see 
this message on C for the agreement “C-to-B”.  The start-time of the last 
update is 01:08:33.  When I check the status on B, it looks fine for “B-to-C” 
and “B-to-A”, however, the start-time of the last update is stuck at 01:08:36 
for “B-to-C”, whereas A gets updated afterwards as well. I don’t have the 
values for A!

When, I check errors and access on the boxes, I see the following:

Errors on A:
[10/Nov/2012:01:19:31 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Warning: unable to receive endReplication extended operation response (Timed 
out)
[10/Nov/2012:01:25:01 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Unable to receive the response for a startReplication extended operation to 
consumer (Can't contact LDAP server). Will retry later.
[10/Nov/2012:01:25:05 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Replication bind with SIMPLE auth resumed
[10/Nov/2012:02:26:29 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Unable to receive the response for a startReplication extended operation to 
consumer (Timed out). Will retry later.
[10/Nov/2012:02:31:55 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Unable to receive the response for a startReplication extended operation to 
consumer (Can't contact LDAP server). Will retry later.
[10/Nov/2012:02:31:59 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Replication bind with SIMPLE auth resumed
[10/Nov/2012:02:43:36 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Unable to receive the response for a startReplication extended operation to 
consumer (Timed out). Will retry later.
[10/Nov/2012:03:03:00 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Unable to receive the response for a startReplication extended operation to 
consumer (Timed out). Will retry later.
[10/Nov/2012:03:08:24 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Unable to receive the response for a startReplication extended operation to 
consumer (Can't contact LDAP server). Will retry later.
[10/Nov/2012:03:11:35 -0300] slapi_ldap_bind - Error: could not send bind 
request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't 
connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 
(Operation now in progress)
[10/Nov/2012:03:11:35 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Replication bind with SIMPLE auth failed: LDAP error 91 (Can't connect to the 
LDAP server) ((null))
[10/Nov/2012:03:14:45 -0300] slapi_ldap_bind - Error: could not send bind 
request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't 
connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 
(Operation now in progress)
[10/Nov/2012:03:14:52 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Replication bind with SIMPLE auth resumed
[10/Nov/2012:03:33:29 -0300] slapi_ldap_bind - Error: could not send bind 
request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't 
connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 
(Operation now in progress)
[10/Nov/2012:03:33:29 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Replication bind with SIMPLE auth failed: LDAP error 91 (Can't connect to the 
LDAP server) ((null))
[10/Nov/2012:03:43:29 -0300] slapi_ldap_bind - Error: timeout after [0.0] 
seconds reading bind response for [cn=replication,cn=config] mech [SIMPLE]
[10/Nov/2012:03:43:29 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Replication bind with SIMPLE auth failed: LDAP error 85 (Timed out) ((null))
[10/Nov/2012:03:46:39 -0300] slapi_ldap_bind - Error: could not send bind

[389-users] MMR issue ...

[Reinhard Nappert]

Hi,

I've encountered issues with a MMR setup, which looks like the following:

 A --- B
   \   /
 \   /
   \   /
 C

The replication works for approximately 24 hours. There are not many changes to 
the content anyway. After about 1 day, the attribute  value of the type 
"nsds5replicaLastUpdateStatus"  changes to "1 Can't acquire busy replica " of 
the replication agreement object from type "nsDS5ReplicationAgreement".  I see 
this message on C for the agreement "C-to-B".  The start-time of the last 
update is 01:08:33.  When I check the status on B, it looks fine for "B-to-C" 
and "B-to-A", however, the start-time of the last update is stuck at 01:08:36 
for "B-to-C", whereas A gets updated afterwards as well. I don't have the 
values for A!

When, I check errors and access on the boxes, I see the following:

Errors on A:
[10/Nov/2012:01:19:31 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Warning: unable to receive endReplication extended operation response (Timed 
out)
[10/Nov/2012:01:25:01 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Unable to receive the response for a startReplication extended operation to 
consumer (Can't contact LDAP server). Will retry later.
[10/Nov/2012:01:25:05 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Replication bind with SIMPLE auth resumed
[10/Nov/2012:02:26:29 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Unable to receive the response for a startReplication extended operation to 
consumer (Timed out). Will retry later.
[10/Nov/2012:02:31:55 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Unable to receive the response for a startReplication extended operation to 
consumer (Can't contact LDAP server). Will retry later.
[10/Nov/2012:02:31:59 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Replication bind with SIMPLE auth resumed
[10/Nov/2012:02:43:36 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Unable to receive the response for a startReplication extended operation to 
consumer (Timed out). Will retry later.
[10/Nov/2012:03:03:00 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Unable to receive the response for a startReplication extended operation to 
consumer (Timed out). Will retry later.
[10/Nov/2012:03:08:24 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Unable to receive the response for a startReplication extended operation to 
consumer (Can't contact LDAP server). Will retry later.
[10/Nov/2012:03:11:35 -0300] slapi_ldap_bind - Error: could not send bind 
request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't 
connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 
(Operation now in progress)
[10/Nov/2012:03:11:35 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Replication bind with SIMPLE auth failed: LDAP error 91 (Can't connect to the 
LDAP server) ((null))
[10/Nov/2012:03:14:45 -0300] slapi_ldap_bind - Error: could not send bind 
request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't 
connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 
(Operation now in progress)
[10/Nov/2012:03:14:52 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Replication bind with SIMPLE auth resumed
[10/Nov/2012:03:33:29 -0300] slapi_ldap_bind - Error: could not send bind 
request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't 
connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 
(Operation now in progress)
[10/Nov/2012:03:33:29 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Replication bind with SIMPLE auth failed: LDAP error 91 (Can't connect to the 
LDAP server) ((null))
[10/Nov/2012:03:43:29 -0300] slapi_ldap_bind - Error: timeout after [0.0] 
seconds reading bind response for [cn=replication,cn=config] mech [SIMPLE]
[10/Nov/2012:03:43:29 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Replication bind with SIMPLE auth failed: LDAP error 85 (Timed out) ((null))
[10/Nov/2012:03:46:39 -0300] slapi_ldap_bind - Error: could not send bind 
request for id [cn=replication,cn=config] mech [SIMPLE]: error 91 (Can't 
connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 
(Operation now in progress)
[10/Nov/2012:03:46:39 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Replication bind with SIMPLE auth failed: LDAP error 91 (Can't connect to the 
LDAP server) ((null))
[10/Nov/2012:03:46:42 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Replication bind with SIMPLE auth resumed
[10/Nov/2012:05:12:02 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Unable to receive the response for a startReplication extended operation to 
consumer (Timed out). Will retry later.
[10/Nov/2012:06:16:01 -0300] NSMMReplicationPlugin - agmt="cn=A-to-B" (B:389): 
Unable to receive the response for a startReplication extended operation to 
consumer (Timed out). Will retry la

Re: [389-users] segfault while moving entry to non-existent LDAP container

[Rich Megginson]

On 11/13/2012 03:30 AM, Vladimir Elisseev wrote:

Hello,

First of all I'd say that most likely this segfault is a result of
badly designed application and/or bad coding. The segfault occurs while
this application tries to move an entry to non-existing LDAP container.
Unfortunately I don't have access to the source code of this app. The
segfault is below with backtrace from dgb:

ns-slapd[4983]: segfault at 18 ip 7f2ed4a60759 sp 7f2e955e13e0 error 4 
in libback-ldbm.so[7f2ed4a34000+8f000]


#0  0x7f2ed4a60759 in id2entry_add_ext () from 
/usr/lib64/dirsrv/plugins/libback-ldbm.so
#1  0x7f2ed4a8a34c in modify_update_all () from 
/usr/lib64/dirsrv/plugins/libback-ldbm.so
#2  0x7f2ed4a8eb4f in ldbm_back_modrdn () from 
/usr/lib64/dirsrv/plugins/libback-ldbm.so
#3  0x7f2eddbecdaa in ?? () from /usr/lib64/dirsrv/libslapd.so.0
#4  0x7f2eddbed66c in do_modrdn () from /usr/lib64/dirsrv/libslapd.so.0
#5  0x00413904 in ?? ()
#6  0x7f2edc0369e3 in ?? () from /lib64/libnspr4.so
#7  0x7f2edb9d9851 in start_thread () from /lib64/libpthread.so.0
#8  0x7f2edb72711d in clone () from /lib64/libc.so.6

I'd appreciate any thoughts regarding what kind of (bad) things this
application is doing. Is it possible to have a kind of protection in
this case on directory server?

rpm -q 389-ds-base
Can you provide a full stack trace based on the instructions at 
http://port389.org/wiki/FAQ#Debugging_Crashes ?


Regards,
Vlad.




--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Password + anything works ?

[Ali Jawad]

Ho
Yes ldap.conf is only what is listed, yes you are right there are two
pam_password that is wrong, I prefer not to use crypt if possible as I do
not want to be limited to 8 char passwords, does that make sense ?
Regards

On Tue, Nov 13, 2012 at 2:38 PM, Grzegorz Dwornicki wrote:

> Sorry my bad i thinking about ldap.conf but said nss...
>
> Does ldap.conf contains only these lines? Why you use pam_password clear
> and then exop? try crypt.
>
> Greg.
> 13 lis 2012 13:18, "Ali Jawad"  napisał(a):
>
> Hi
>> nsswitch.conf contains the following relevant lines, the rest is
>> unchanged
>>
>>
>> passwd: ldap files
>> shadow: ldap files
>> group:  ldap files
>>
>> Maybe it is my ldap settings, please see /etc/ldap.conf below
>>
>> bind_policy soft
>> URI ldap://ldap.server.ip
>> BASE dc=domain,dc=local
>> TLS_CACERTDIR /etc/openldap/cacerts
>> pam_password clear
>> pam_lookup_policy yes
>> pam_password exop
>> # Idle timelimit; client will close connections
>> # (nss_ldap only) if the server has not been contacted
>> # for the number of seconds specified below.
>> #idle_timelimit 3600
>> idle_timelimit 900
>>
>>
>> On Tue, Nov 13, 2012 at 1:59 PM, Grzegorz Dwornicki wrote:
>>
>>> What about NSS configuration? Maybe there is configuration making ssl
>>> mandatory?
>>>
>>> Greg
>>> 13 lis 2012 12:51, "Ali Jawad"  napisał(a):
>>>
>>> Hi All
 I am trying to change the password using passwd, please see the below :

 [xyz@server ~]$ passwd
 Changing password for user xyz.
 Enter login(LDAP) password:
 New UNIX password:
 Retype new UNIX password:
 *LDAP password information update failed: Confidentiality required*
 *Operation requires a secure connection.*

  The error log shows
 Nov 13 11:47:17 HA-Dev-Nymgo-100-45 passwd: pam_unix(passwd:chauthtok):
 user "xyz" does not exist in /etc/passwd

 Pam config follows :

 /etc/pam.d/passwd
 #%PAM-1.0
 auth   include  system-auth
 accountinclude  system-auth
 password   include  system-auth
 ~

 /etc/pam.d/system-auth

 #/etc/pam.d/system-auth
 #%PAM-1.0

 authrequired  pam_env.so
 authsufficient  pam_unix.so
 authsufficient  pam_ldap.so  use_first_pass
 authrequired  pam_deny.so

 account  sufficient pam_unix.so
 account  sufficient pam_ldap.so use_first_pass
 account  required pam_deny.so

 passwordrequisite pam_cracklib.so try_first_pass retry=3
 passwordsufficientpam_unix.so md5 shadow nullok try_first_pass
 use_authtok
 passwordsufficientpam_ldap.so use_authtok
 passwordrequired  pam_deny.so


 #passwordrequiredpam_cracklib.so retry=3 minlen=2
  dcredit=0  ucredit=0
 #passwordsufficient  pam_unix.so nullok use_authtok md5
 shadow
 #passwordsufficient  pam_ldap.so
 #passwordrequired  pam_deny.so

 session  optional pam_mkhomedir.so skel=/etc/skel/ umask=0022
 session  required pam_limits.so
 session  required pam_unix.so
 session  optional pam_ldap.so
 ~
 ~



 On Tue, Nov 13, 2012 at 11:15 AM, Arpit Tolani 
 wrote:

> Hello
>
>
>
> On Tue, Nov 13, 2012 at 1:10 PM, Ali Jawad 
> wrote:
> > Hi Arpit
> > Actually I was attempting to change the password using command line
> >
> > passwd
> >
> > I.e. each user changes his own password, is passwd the right choice
> here ?
> >
>
> Yes, passwd is right choice, considering you have pam_ldap.so properly
> configured & yes passwd dont need ssl/tls to be configured.
>
>
> > Regards
> >
> > On Mon, Nov 12, 2012 at 11:27 PM, Arpit Tolani <
> arpittol...@gmail.com>
> > wrote:
> >>
> >> Hello
> >>
> >> On Tue, Nov 13, 2012 at 12:33 AM, Ali Jawad  >
> >> wrote:
> >> > In that case I have a major overhaul that I need to complete,
> change
> >> > password is not working for me, my assumption is that it only
> works with
> >> > TLS
> >> > enabled between the client and the server, I have tried to get
> TLS to
> >> > run a
> >> > few times but could not get it to run so far. Am I right about the
> >> > assumption that I need encryption between the server and the
> clients for
> >> > password change to work ?
> >> > Regards
> >> >
> >>
> >> When using ldappasswd command, Yes ssl/tls is mandatory, Try
> changing
> >> password using ldapmodify, it doesnt required ssl/tls connection.
> >>
> >> >
> >> > On Mon, Nov 12, 2012 at 8:56 PM, Mark Reynolds <
> marey...@redhat.com>
> >> > wrote:
> >> >>
> >> >> Only "crypt" uses the first 8 characters, so

Re: [389-users] Password + anything works ?

[Grzegorz Dwornicki]

Sorry my bad i thinking about ldap.conf but said nss...

Does ldap.conf contains only these lines? Why you use pam_password clear
and then exop? try crypt.

Greg.
13 lis 2012 13:18, "Ali Jawad"  napisał(a):

> Hi
> nsswitch.conf contains the following relevant lines, the rest is unchanged
>
>
> passwd: ldap files
> shadow: ldap files
> group:  ldap files
>
> Maybe it is my ldap settings, please see /etc/ldap.conf below
>
> bind_policy soft
> URI ldap://ldap.server.ip
> BASE dc=domain,dc=local
> TLS_CACERTDIR /etc/openldap/cacerts
> pam_password clear
> pam_lookup_policy yes
> pam_password exop
> # Idle timelimit; client will close connections
> # (nss_ldap only) if the server has not been contacted
> # for the number of seconds specified below.
> #idle_timelimit 3600
> idle_timelimit 900
>
>
> On Tue, Nov 13, 2012 at 1:59 PM, Grzegorz Dwornicki wrote:
>
>> What about NSS configuration? Maybe there is configuration making ssl
>> mandatory?
>>
>> Greg
>> 13 lis 2012 12:51, "Ali Jawad"  napisał(a):
>>
>> Hi All
>>> I am trying to change the password using passwd, please see the below :
>>>
>>> [xyz@server ~]$ passwd
>>> Changing password for user xyz.
>>> Enter login(LDAP) password:
>>> New UNIX password:
>>> Retype new UNIX password:
>>> *LDAP password information update failed: Confidentiality required*
>>> *Operation requires a secure connection.*
>>>
>>>  The error log shows
>>> Nov 13 11:47:17 HA-Dev-Nymgo-100-45 passwd: pam_unix(passwd:chauthtok):
>>> user "xyz" does not exist in /etc/passwd
>>>
>>> Pam config follows :
>>>
>>> /etc/pam.d/passwd
>>> #%PAM-1.0
>>> auth   include  system-auth
>>> accountinclude  system-auth
>>> password   include  system-auth
>>> ~
>>>
>>> /etc/pam.d/system-auth
>>>
>>> #/etc/pam.d/system-auth
>>> #%PAM-1.0
>>>
>>> authrequired  pam_env.so
>>> authsufficient  pam_unix.so
>>> authsufficient  pam_ldap.so  use_first_pass
>>> authrequired  pam_deny.so
>>>
>>> account  sufficient pam_unix.so
>>> account  sufficient pam_ldap.so use_first_pass
>>> account  required pam_deny.so
>>>
>>> passwordrequisite pam_cracklib.so try_first_pass retry=3
>>> passwordsufficientpam_unix.so md5 shadow nullok try_first_pass
>>> use_authtok
>>> passwordsufficientpam_ldap.so use_authtok
>>> passwordrequired  pam_deny.so
>>>
>>>
>>> #passwordrequiredpam_cracklib.so retry=3 minlen=2
>>>  dcredit=0  ucredit=0
>>> #passwordsufficient  pam_unix.so nullok use_authtok md5
>>> shadow
>>> #passwordsufficient  pam_ldap.so
>>> #passwordrequired  pam_deny.so
>>>
>>> session  optional pam_mkhomedir.so skel=/etc/skel/ umask=0022
>>> session  required pam_limits.so
>>> session  required pam_unix.so
>>> session  optional pam_ldap.so
>>> ~
>>> ~
>>>
>>>
>>>
>>> On Tue, Nov 13, 2012 at 11:15 AM, Arpit Tolani wrote:
>>>
 Hello



 On Tue, Nov 13, 2012 at 1:10 PM, Ali Jawad 
 wrote:
 > Hi Arpit
 > Actually I was attempting to change the password using command line
 >
 > passwd
 >
 > I.e. each user changes his own password, is passwd the right choice
 here ?
 >

 Yes, passwd is right choice, considering you have pam_ldap.so properly
 configured & yes passwd dont need ssl/tls to be configured.


 > Regards
 >
 > On Mon, Nov 12, 2012 at 11:27 PM, Arpit Tolani >>> >
 > wrote:
 >>
 >> Hello
 >>
 >> On Tue, Nov 13, 2012 at 12:33 AM, Ali Jawad 
 >> wrote:
 >> > In that case I have a major overhaul that I need to complete,
 change
 >> > password is not working for me, my assumption is that it only
 works with
 >> > TLS
 >> > enabled between the client and the server, I have tried to get TLS
 to
 >> > run a
 >> > few times but could not get it to run so far. Am I right about the
 >> > assumption that I need encryption between the server and the
 clients for
 >> > password change to work ?
 >> > Regards
 >> >
 >>
 >> When using ldappasswd command, Yes ssl/tls is mandatory, Try changing
 >> password using ldapmodify, it doesnt required ssl/tls connection.
 >>
 >> >
 >> > On Mon, Nov 12, 2012 at 8:56 PM, Mark Reynolds <
 marey...@redhat.com>
 >> > wrote:
 >> >>
 >> >> Only "crypt" uses the first 8 characters, so any other scheme
 would be
 >> >> fine.  After you change the scheme you will need to force all the
 users
 >> >> to
 >> >> change their passwords - otherwise their crypt passwords will
 still be
 >> >> present.
 >> >>
 >> >>
 >> >>
 >> >> On 11/12/2012 01:52 PM, Ali Jawad wrote:
 >> >>
 >> >> Hi All
 >> >> This is an all Linux environment with 389 being used as the sole
 >> >> authentication mechanism, I do believe I am us

Re: [389-users] Password + anything works ?

[Ali Jawad]

Hi
nsswitch.conf contains the following relevant lines, the rest is unchanged


passwd: ldap files
shadow: ldap files
group:  ldap files

Maybe it is my ldap settings, please see /etc/ldap.conf below

bind_policy soft
URI ldap://ldap.server.ip
BASE dc=domain,dc=local
TLS_CACERTDIR /etc/openldap/cacerts
pam_password clear
pam_lookup_policy yes
pam_password exop
# Idle timelimit; client will close connections
# (nss_ldap only) if the server has not been contacted
# for the number of seconds specified below.
#idle_timelimit 3600
idle_timelimit 900


On Tue, Nov 13, 2012 at 1:59 PM, Grzegorz Dwornicki wrote:

> What about NSS configuration? Maybe there is configuration making ssl
> mandatory?
>
> Greg
> 13 lis 2012 12:51, "Ali Jawad"  napisał(a):
>
> Hi All
>> I am trying to change the password using passwd, please see the below :
>>
>> [xyz@server ~]$ passwd
>> Changing password for user xyz.
>> Enter login(LDAP) password:
>> New UNIX password:
>> Retype new UNIX password:
>> *LDAP password information update failed: Confidentiality required*
>> *Operation requires a secure connection.*
>>
>>  The error log shows
>> Nov 13 11:47:17 HA-Dev-Nymgo-100-45 passwd: pam_unix(passwd:chauthtok):
>> user "xyz" does not exist in /etc/passwd
>>
>> Pam config follows :
>>
>> /etc/pam.d/passwd
>> #%PAM-1.0
>> auth   include  system-auth
>> accountinclude  system-auth
>> password   include  system-auth
>> ~
>>
>> /etc/pam.d/system-auth
>>
>> #/etc/pam.d/system-auth
>> #%PAM-1.0
>>
>> authrequired  pam_env.so
>> authsufficient  pam_unix.so
>> authsufficient  pam_ldap.so  use_first_pass
>> authrequired  pam_deny.so
>>
>> account  sufficient pam_unix.so
>> account  sufficient pam_ldap.so use_first_pass
>> account  required pam_deny.so
>>
>> passwordrequisite pam_cracklib.so try_first_pass retry=3
>> passwordsufficientpam_unix.so md5 shadow nullok try_first_pass
>> use_authtok
>> passwordsufficientpam_ldap.so use_authtok
>> passwordrequired  pam_deny.so
>>
>>
>> #passwordrequiredpam_cracklib.so retry=3 minlen=2
>>  dcredit=0  ucredit=0
>> #passwordsufficient  pam_unix.so nullok use_authtok md5 shadow
>> #passwordsufficient  pam_ldap.so
>> #passwordrequired  pam_deny.so
>>
>> session  optional pam_mkhomedir.so skel=/etc/skel/ umask=0022
>> session  required pam_limits.so
>> session  required pam_unix.so
>> session  optional pam_ldap.so
>> ~
>> ~
>>
>>
>>
>> On Tue, Nov 13, 2012 at 11:15 AM, Arpit Tolani wrote:
>>
>>> Hello
>>>
>>>
>>>
>>> On Tue, Nov 13, 2012 at 1:10 PM, Ali Jawad 
>>> wrote:
>>> > Hi Arpit
>>> > Actually I was attempting to change the password using command line
>>> >
>>> > passwd
>>> >
>>> > I.e. each user changes his own password, is passwd the right choice
>>> here ?
>>> >
>>>
>>> Yes, passwd is right choice, considering you have pam_ldap.so properly
>>> configured & yes passwd dont need ssl/tls to be configured.
>>>
>>>
>>> > Regards
>>> >
>>> > On Mon, Nov 12, 2012 at 11:27 PM, Arpit Tolani 
>>> > wrote:
>>> >>
>>> >> Hello
>>> >>
>>> >> On Tue, Nov 13, 2012 at 12:33 AM, Ali Jawad 
>>> >> wrote:
>>> >> > In that case I have a major overhaul that I need to complete, change
>>> >> > password is not working for me, my assumption is that it only works
>>> with
>>> >> > TLS
>>> >> > enabled between the client and the server, I have tried to get TLS
>>> to
>>> >> > run a
>>> >> > few times but could not get it to run so far. Am I right about the
>>> >> > assumption that I need encryption between the server and the
>>> clients for
>>> >> > password change to work ?
>>> >> > Regards
>>> >> >
>>> >>
>>> >> When using ldappasswd command, Yes ssl/tls is mandatory, Try changing
>>> >> password using ldapmodify, it doesnt required ssl/tls connection.
>>> >>
>>> >> >
>>> >> > On Mon, Nov 12, 2012 at 8:56 PM, Mark Reynolds >> >
>>> >> > wrote:
>>> >> >>
>>> >> >> Only "crypt" uses the first 8 characters, so any other scheme
>>> would be
>>> >> >> fine.  After you change the scheme you will need to force all the
>>> users
>>> >> >> to
>>> >> >> change their passwords - otherwise their crypt passwords will
>>> still be
>>> >> >> present.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> On 11/12/2012 01:52 PM, Ali Jawad wrote:
>>> >> >>
>>> >> >> Hi All
>>> >> >> This is an all Linux environment with 389 being used as the sole
>>> >> >> authentication mechanism, I do believe I am using crypt, I am out
>>> of
>>> >> >> office
>>> >> >> right now, what should I use instead of crypt to match more
>>> characters
>>> >> >> ?
>>> >> >> Regards
>>> >> >>
>>> >> >> On Mon, Nov 12, 2012 at 7:02 PM, Mark Reynolds <
>>> marey...@redhat.com>
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> Also what password storage scheme are you using?  For example
>>> "crypt"
>>> >> >>> only checks the first 8 characters of a passwo

Re: [389-users] Password + anything works ?

[Grzegorz Dwornicki]

What about NSS configuration? Maybe there is configuration making ssl
mandatory?

Greg
13 lis 2012 12:51, "Ali Jawad"  napisał(a):

> Hi All
> I am trying to change the password using passwd, please see the below :
>
> [xyz@server ~]$ passwd
> Changing password for user xyz.
> Enter login(LDAP) password:
> New UNIX password:
> Retype new UNIX password:
> *LDAP password information update failed: Confidentiality required*
> *Operation requires a secure connection.*
>
>  The error log shows
> Nov 13 11:47:17 HA-Dev-Nymgo-100-45 passwd: pam_unix(passwd:chauthtok):
> user "xyz" does not exist in /etc/passwd
>
> Pam config follows :
>
> /etc/pam.d/passwd
> #%PAM-1.0
> auth   include  system-auth
> accountinclude  system-auth
> password   include  system-auth
> ~
>
> /etc/pam.d/system-auth
>
> #/etc/pam.d/system-auth
> #%PAM-1.0
>
> authrequired  pam_env.so
> authsufficient  pam_unix.so
> authsufficient  pam_ldap.so  use_first_pass
> authrequired  pam_deny.so
>
> account  sufficient pam_unix.so
> account  sufficient pam_ldap.so use_first_pass
> account  required pam_deny.so
>
> passwordrequisite pam_cracklib.so try_first_pass retry=3
> passwordsufficientpam_unix.so md5 shadow nullok try_first_pass
> use_authtok
> passwordsufficientpam_ldap.so use_authtok
> passwordrequired  pam_deny.so
>
>
> #passwordrequiredpam_cracklib.so retry=3 minlen=2
>  dcredit=0  ucredit=0
> #passwordsufficient  pam_unix.so nullok use_authtok md5 shadow
> #passwordsufficient  pam_ldap.so
> #passwordrequired  pam_deny.so
>
> session  optional pam_mkhomedir.so skel=/etc/skel/ umask=0022
> session  required pam_limits.so
> session  required pam_unix.so
> session  optional pam_ldap.so
> ~
> ~
>
>
>
> On Tue, Nov 13, 2012 at 11:15 AM, Arpit Tolani wrote:
>
>> Hello
>>
>>
>>
>> On Tue, Nov 13, 2012 at 1:10 PM, Ali Jawad 
>> wrote:
>> > Hi Arpit
>> > Actually I was attempting to change the password using command line
>> >
>> > passwd
>> >
>> > I.e. each user changes his own password, is passwd the right choice
>> here ?
>> >
>>
>> Yes, passwd is right choice, considering you have pam_ldap.so properly
>> configured & yes passwd dont need ssl/tls to be configured.
>>
>>
>> > Regards
>> >
>> > On Mon, Nov 12, 2012 at 11:27 PM, Arpit Tolani 
>> > wrote:
>> >>
>> >> Hello
>> >>
>> >> On Tue, Nov 13, 2012 at 12:33 AM, Ali Jawad 
>> >> wrote:
>> >> > In that case I have a major overhaul that I need to complete, change
>> >> > password is not working for me, my assumption is that it only works
>> with
>> >> > TLS
>> >> > enabled between the client and the server, I have tried to get TLS to
>> >> > run a
>> >> > few times but could not get it to run so far. Am I right about the
>> >> > assumption that I need encryption between the server and the clients
>> for
>> >> > password change to work ?
>> >> > Regards
>> >> >
>> >>
>> >> When using ldappasswd command, Yes ssl/tls is mandatory, Try changing
>> >> password using ldapmodify, it doesnt required ssl/tls connection.
>> >>
>> >> >
>> >> > On Mon, Nov 12, 2012 at 8:56 PM, Mark Reynolds 
>> >> > wrote:
>> >> >>
>> >> >> Only "crypt" uses the first 8 characters, so any other scheme would
>> be
>> >> >> fine.  After you change the scheme you will need to force all the
>> users
>> >> >> to
>> >> >> change their passwords - otherwise their crypt passwords will still
>> be
>> >> >> present.
>> >> >>
>> >> >>
>> >> >>
>> >> >> On 11/12/2012 01:52 PM, Ali Jawad wrote:
>> >> >>
>> >> >> Hi All
>> >> >> This is an all Linux environment with 389 being used as the sole
>> >> >> authentication mechanism, I do believe I am using crypt, I am out of
>> >> >> office
>> >> >> right now, what should I use instead of crypt to match more
>> characters
>> >> >> ?
>> >> >> Regards
>> >> >>
>> >> >> On Mon, Nov 12, 2012 at 7:02 PM, Mark Reynolds > >
>> >> >> wrote:
>> >> >>>
>> >> >>> Also what password storage scheme are you using?  For example
>> "crypt"
>> >> >>> only checks the first 8 characters of a password.
>> >> >>>
>> >> >>>
>> >> >>> On 11/12/2012 11:18 AM, Dan Lavu wrote:
>> >> >>>
>> >> >>> In regards to a password policy? Just 389 or are you using winsync
>> >> >>> with
>> >> >>> AD? Because the password policy from AD does not transfer over.
>> Also
>> >> >>> they
>> >> >>> are some extra steps if you want to setup an OU based password
>> policy
>> >> >>> but if
>> >> >>> you just do it for the entire directory through 'configuration' it
>> >> >>> works
>> >> >>> with no issues.
>> >> >>>
>> >> >>> Dan
>> >> >>>
>> >> >>> From: Ali Jawad 
>> >> >>> Sent: November 12, 2012 6:00 AM
>> >> >>> To: General discussion list for the 389 Directory server project.
>> >> >>> Subject: [389-users] Password + anything works ?
>> >> >>>
>> >> >>> Hi
>> >> >>> I just noticed that you can use the password

Re: [389-users] Password + anything works ?

[Ali Jawad]

Hi All
I am trying to change the password using passwd, please see the below :

[xyz@server ~]$ passwd
Changing password for user xyz.
Enter login(LDAP) password:
New UNIX password:
Retype new UNIX password:
*LDAP password information update failed: Confidentiality required*
*Operation requires a secure connection.*

The error log shows
Nov 13 11:47:17 HA-Dev-Nymgo-100-45 passwd: pam_unix(passwd:chauthtok):
user "xyz" does not exist in /etc/passwd

Pam config follows :

/etc/pam.d/passwd
#%PAM-1.0
auth   include  system-auth
accountinclude  system-auth
password   include  system-auth
~

/etc/pam.d/system-auth

#/etc/pam.d/system-auth
#%PAM-1.0

authrequired  pam_env.so
authsufficient  pam_unix.so
authsufficient  pam_ldap.so  use_first_pass
authrequired  pam_deny.so

account  sufficient pam_unix.so
account  sufficient pam_ldap.so use_first_pass
account  required pam_deny.so

passwordrequisite pam_cracklib.so try_first_pass retry=3
passwordsufficientpam_unix.so md5 shadow nullok try_first_pass
use_authtok
passwordsufficientpam_ldap.so use_authtok
passwordrequired  pam_deny.so


#passwordrequiredpam_cracklib.so retry=3 minlen=2
 dcredit=0  ucredit=0
#passwordsufficient  pam_unix.so nullok use_authtok md5 shadow
#passwordsufficient  pam_ldap.so
#passwordrequired  pam_deny.so

session  optional pam_mkhomedir.so skel=/etc/skel/ umask=0022
session  required pam_limits.so
session  required pam_unix.so
session  optional pam_ldap.so
~
~



On Tue, Nov 13, 2012 at 11:15 AM, Arpit Tolani wrote:

> Hello
>
>
>
> On Tue, Nov 13, 2012 at 1:10 PM, Ali Jawad  wrote:
> > Hi Arpit
> > Actually I was attempting to change the password using command line
> >
> > passwd
> >
> > I.e. each user changes his own password, is passwd the right choice here
> ?
> >
>
> Yes, passwd is right choice, considering you have pam_ldap.so properly
> configured & yes passwd dont need ssl/tls to be configured.
>
>
> > Regards
> >
> > On Mon, Nov 12, 2012 at 11:27 PM, Arpit Tolani 
> > wrote:
> >>
> >> Hello
> >>
> >> On Tue, Nov 13, 2012 at 12:33 AM, Ali Jawad 
> >> wrote:
> >> > In that case I have a major overhaul that I need to complete, change
> >> > password is not working for me, my assumption is that it only works
> with
> >> > TLS
> >> > enabled between the client and the server, I have tried to get TLS to
> >> > run a
> >> > few times but could not get it to run so far. Am I right about the
> >> > assumption that I need encryption between the server and the clients
> for
> >> > password change to work ?
> >> > Regards
> >> >
> >>
> >> When using ldappasswd command, Yes ssl/tls is mandatory, Try changing
> >> password using ldapmodify, it doesnt required ssl/tls connection.
> >>
> >> >
> >> > On Mon, Nov 12, 2012 at 8:56 PM, Mark Reynolds 
> >> > wrote:
> >> >>
> >> >> Only "crypt" uses the first 8 characters, so any other scheme would
> be
> >> >> fine.  After you change the scheme you will need to force all the
> users
> >> >> to
> >> >> change their passwords - otherwise their crypt passwords will still
> be
> >> >> present.
> >> >>
> >> >>
> >> >>
> >> >> On 11/12/2012 01:52 PM, Ali Jawad wrote:
> >> >>
> >> >> Hi All
> >> >> This is an all Linux environment with 389 being used as the sole
> >> >> authentication mechanism, I do believe I am using crypt, I am out of
> >> >> office
> >> >> right now, what should I use instead of crypt to match more
> characters
> >> >> ?
> >> >> Regards
> >> >>
> >> >> On Mon, Nov 12, 2012 at 7:02 PM, Mark Reynolds 
> >> >> wrote:
> >> >>>
> >> >>> Also what password storage scheme are you using?  For example
> "crypt"
> >> >>> only checks the first 8 characters of a password.
> >> >>>
> >> >>>
> >> >>> On 11/12/2012 11:18 AM, Dan Lavu wrote:
> >> >>>
> >> >>> In regards to a password policy? Just 389 or are you using winsync
> >> >>> with
> >> >>> AD? Because the password policy from AD does not transfer over. Also
> >> >>> they
> >> >>> are some extra steps if you want to setup an OU based password
> policy
> >> >>> but if
> >> >>> you just do it for the entire directory through ‘configuration’ it
> >> >>> works
> >> >>> with no issues.
> >> >>>
> >> >>> Dan
> >> >>>
> >> >>> From: Ali Jawad 
> >> >>> Sent: November 12, 2012 6:00 AM
> >> >>> To: General discussion list for the 389 Directory server project.
> >> >>> Subject: [389-users] Password + anything works ?
> >> >>>
> >> >>> Hi
> >> >>> I just noticed that you can use the password+ANYLetters and it will
> >> >>> work,
> >> >>> I.e. if the password is xyz xyz99 or xyzABC will work as well, is
> this
> >> >>> a
> >> >>> misconfiguration on my part or a bug ?
> >> >>> Regards
> >> >>>
> >>
> >> Regards
> >> Arpit Tolani
> >> --
> >> 389 users mailing list
> >> 389-users@lists.fedoraproject.org
> >> https://admin.fedoraproject

[389-users] segfault while moving entry to non-existent LDAP container

[Vladimir Elisseev]

Hello,

First of all I'd say that most likely this segfault is a result of
badly designed application and/or bad coding. The segfault occurs while
this application tries to move an entry to non-existing LDAP container.
Unfortunately I don't have access to the source code of this app. The
segfault is below with backtrace from dgb:

ns-slapd[4983]: segfault at 18 ip 7f2ed4a60759 sp 7f2e955e13e0 error 4 
in libback-ldbm.so[7f2ed4a34000+8f000]


#0  0x7f2ed4a60759 in id2entry_add_ext () from 
/usr/lib64/dirsrv/plugins/libback-ldbm.so
#1  0x7f2ed4a8a34c in modify_update_all () from 
/usr/lib64/dirsrv/plugins/libback-ldbm.so
#2  0x7f2ed4a8eb4f in ldbm_back_modrdn () from 
/usr/lib64/dirsrv/plugins/libback-ldbm.so
#3  0x7f2eddbecdaa in ?? () from /usr/lib64/dirsrv/libslapd.so.0
#4  0x7f2eddbed66c in do_modrdn () from /usr/lib64/dirsrv/libslapd.so.0
#5  0x00413904 in ?? ()
#6  0x7f2edc0369e3 in ?? () from /lib64/libnspr4.so
#7  0x7f2edb9d9851 in start_thread () from /lib64/libpthread.so.0
#8  0x7f2edb72711d in clone () from /lib64/libc.so.6

I'd appreciate any thoughts regarding what kind of (bad) things this
application is doing. Is it possible to have a kind of protection in
this case on directory server?

Regards,
Vlad.


 

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Password + anything works ?

[Arpit Tolani]

Hello



On Tue, Nov 13, 2012 at 1:10 PM, Ali Jawad  wrote:
> Hi Arpit
> Actually I was attempting to change the password using command line
>
> passwd
>
> I.e. each user changes his own password, is passwd the right choice here ?
>

Yes, passwd is right choice, considering you have pam_ldap.so properly
configured & yes passwd dont need ssl/tls to be configured.


> Regards
>
> On Mon, Nov 12, 2012 at 11:27 PM, Arpit Tolani 
> wrote:
>>
>> Hello
>>
>> On Tue, Nov 13, 2012 at 12:33 AM, Ali Jawad 
>> wrote:
>> > In that case I have a major overhaul that I need to complete, change
>> > password is not working for me, my assumption is that it only works with
>> > TLS
>> > enabled between the client and the server, I have tried to get TLS to
>> > run a
>> > few times but could not get it to run so far. Am I right about the
>> > assumption that I need encryption between the server and the clients for
>> > password change to work ?
>> > Regards
>> >
>>
>> When using ldappasswd command, Yes ssl/tls is mandatory, Try changing
>> password using ldapmodify, it doesnt required ssl/tls connection.
>>
>> >
>> > On Mon, Nov 12, 2012 at 8:56 PM, Mark Reynolds 
>> > wrote:
>> >>
>> >> Only "crypt" uses the first 8 characters, so any other scheme would be
>> >> fine.  After you change the scheme you will need to force all the users
>> >> to
>> >> change their passwords - otherwise their crypt passwords will still be
>> >> present.
>> >>
>> >>
>> >>
>> >> On 11/12/2012 01:52 PM, Ali Jawad wrote:
>> >>
>> >> Hi All
>> >> This is an all Linux environment with 389 being used as the sole
>> >> authentication mechanism, I do believe I am using crypt, I am out of
>> >> office
>> >> right now, what should I use instead of crypt to match more characters
>> >> ?
>> >> Regards
>> >>
>> >> On Mon, Nov 12, 2012 at 7:02 PM, Mark Reynolds 
>> >> wrote:
>> >>>
>> >>> Also what password storage scheme are you using?  For example "crypt"
>> >>> only checks the first 8 characters of a password.
>> >>>
>> >>>
>> >>> On 11/12/2012 11:18 AM, Dan Lavu wrote:
>> >>>
>> >>> In regards to a password policy? Just 389 or are you using winsync
>> >>> with
>> >>> AD? Because the password policy from AD does not transfer over. Also
>> >>> they
>> >>> are some extra steps if you want to setup an OU based password policy
>> >>> but if
>> >>> you just do it for the entire directory through ‘configuration’ it
>> >>> works
>> >>> with no issues.
>> >>>
>> >>> Dan
>> >>>
>> >>> From: Ali Jawad 
>> >>> Sent: November 12, 2012 6:00 AM
>> >>> To: General discussion list for the 389 Directory server project.
>> >>> Subject: [389-users] Password + anything works ?
>> >>>
>> >>> Hi
>> >>> I just noticed that you can use the password+ANYLetters and it will
>> >>> work,
>> >>> I.e. if the password is xyz xyz99 or xyzABC will work as well, is this
>> >>> a
>> >>> misconfiguration on my part or a bug ?
>> >>> Regards
>> >>>
>>
>> Regards
>> Arpit Tolani
>> --
>> 389 users mailing list
>> 389-users@lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
>
>
>
> --
> Ali Jawad
> Information Systems Manager
> CISSP - PMP - ITIL V3 - RHCE - VCP - C|EH - CCNA - MCSA
> Splendor Telecom (www.splendor.net)
> Beirut, Lebanon
> Phone: +9611373725/ext 116
> FAX: +9611375554
>
>
>
> --
> 389 users mailing list
> 389-users@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users

-- 
Regards
Arpit Tolani
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users