[389-users] Re: ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error

[Graham Leggett]

On 19 Nov 2020, at 10:34, Graham Leggett  wrote:

>> Raised the bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1771979
> 
> Coming back to this one - got to the bottom of this while investigating 
> something else that wasn’t working.
> 
> This wasn’t a regression in NSS, but rather a regression in the openldap 
> libraries shipped by RHEL7.5 and above.
> 
> For reasons that I haven’t found, there was an architecture change made half 
> way through the RHEL7 lifecycle where openldap was linked to openssl instead 
> of NSS.
> 
> Openldap's NSS support and openldap’s openssl support differ in a fundamental 
> way - with NSS, when openldap makes an SSL connection intermediate 
> certificates are filled in by the client side as normal. With openssl, when 
> openldap makes an SSL connection intermediate certificates are ignored, and 
> the connection breaks.
> 
> The hack workaround above fixes this because openldap’s openssl support 
> expects you to place intermediate certs in your trusted certificate store. As 
> soon as you mark the intermediates as trusted in NSS, the hack workaround in 
> 389ds that makes replication sort-of work bound to two different crypto 
> libraries exports trusted certs across into the ca certificate list passed to 
> openldap. Openldap then finds the intermediates and things work.
> 
> Fundamentally there are two bugs:
> 
> - https://bugzilla.redhat.com/show_bug.cgi?id=1898924
> 
> - An architectural change half way through the lifecycle of what is supposed 
> to be a stable OS.

End of 2023, the bug is still present in RHEL9:

[11/Dec/2023:23:02:09.510906411 +] - ERR - slapi_ldap_bind - Could not send 
bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 
(Can't contact LDAP server), system error -5987 (Invalid function argument.), 
network error 0 (Unknown error, host “ldap2.example.com:636")

This time, the workaround of forcing the intermediate certificates to be marked 
trusted no longer works. We now get a low level complaint about a certificate 
verification failure. The error message doesn’t tell us which certificate 
failed, but this message is an openssl message.

[11/Dec/2023:19:45:28.115134273 +] - ERR - NSMMReplicationPlugin - 
bind_and_check_pwp - agmt=“cn=ldap2" (thor:636) - Replication bind with 
EXTERNAL auth failed: LDAP error -1 (Can't contact LDAP server) 
(error:0A86:SSL routines::certificate verify failed (self-signed 
certificate in certificate chain))

There are no self-signed certificates being used, they are certs issued by 
public CAs, which like all public CAs, have intermediate certs.

The bugs I raised in 2020 were all abandoned and closed.

Regards,
Graham
—

--
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[389-users] 389ds and PKCS11 - how does 389ds read certificates/keys from p11kit?

[Graham Leggett]

Hi all,

389ds as shipped by RHEL9 is linked to NSS, which in theory supports PKCS11, 
but in practice I can't get to work.

Most specifically, when you display a 389ds NSS database using modutil, you see 
p11-kit-proxy (good), but it reports "There are no slots attached to this 
module” (bad).

Has anyone got an explanation as to why this might be?

[root@seawitch ~]# modutil -list -dbdir /etc/dirsrv/slapd-seawitch

Listing of PKCS #11 Modules
---
  1. NSS Internal PKCS #11 Module
   uri: 
pkcs11:library-manufacturer=Mozilla%20Foundation;library-description=NSS%20Internal%20Crypto%20Services;library-version=3.79
 slots: 2 slots attached
status: loaded

 slot: NSS Internal Cryptographic Services
token: NSS Generic Crypto Services
  uri: 
pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=;model=NSS%203

 slot: NSS User Private Key and Certificate Services
token: NSS Certificate DB
  uri: 
pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=;model=NSS%203

  2. p11-kit-proxy
library name: p11-kit-proxy.so
   uri: 
pkcs11:library-manufacturer=PKCS%2311%20Kit;library-description=PKCS%2311%20Kit%20Proxy%20Module;library-version=1.1
 slots: There are no slots attached to this module
status: loaded
—

At the very least the system and default CA databases should be visible, but 
alas no:

[root@seawitch ~]# p11-kit list-modules 
p11-kit-trust: p11-kit-trust.so
library-description: PKCS#11 Kit Trust Module
library-manufacturer: PKCS#11 Kit
library-version: 0.24
token: System Trust
manufacturer: PKCS#11 Kit
model: p11-kit-trust
serial-number: 1
hardware-version: 0.24
flags:
   token-initialized
token: Default Trust
manufacturer: PKCS#11 Kit
model: p11-kit-trust
serial-number: 1
hardware-version: 0.24
flags:
   write-protected
   token-initialized

Regards,
Graham
—
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[389-users] Search directory for userCertificate by fingerprint?

[Graham Leggett]

Hi all,

(This is very tricky to google)

Is there a mechanism by which it is possible, given the hash of a 
userCertificate, to search for userCertificates in a 389ds directory?

Something like this:

(userCertificate=sha256:0a:f0…)

Obviously I can preprocess the directory and store the hash beside the 
certificate, however there does not seem to be a sensible attribute for that.

Is this possible?

Regards,
Graham
—
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[389-users] Re: ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error

[Graham Leggett]

On 13 Nov 2019, at 12:29, Graham Leggett  wrote:

> On 13 Nov 2019, at 01:37, William Brown  wrote:
> 
>>> Does anyone know why 389ds would suddenly stop sending the full certificate 
>>> chain while replicating?
>>> 
>>> It also looks like the error handling in 389ds SSL is broken - if the slave 
>>> sent “unknown CA" to the master, the master needs to log that fact, and not 
>>> report the error as “success”.
>> 
>> We'll need to see the output of certutil -L -d /etc/dirsrv/slapd-/ 
>> from both the master and replica servers please.
>> 
>> In a TLS auth process the client doesn't send it's CA - if you get unknown 
>> CA it's most likely the replica has either had the CA and it's chain members 
>> expire, or they are not marked as trusted for client auth. So that's why I'd 
>> like to see the certutil output please. 
> 
> I discovered the same problem had been reported in OpenLDAP: 
> https://www.centos.org/forums/viewtopic.php?t=67042
> 
> This in turn is caused by a regression in NSS, where it is no longer 
> sufficient to have a trusted root certificate, you now need all intermediate 
> certificates marked as trusted as well.
> 
> Making the following change to the intermediate certs fixed the problem:
> 
> [root@ldap01 ~]# certutil -L -d /etc/dirsrv/slapd-hg
> 
> Certificate Nickname Trust Attributes
> SSL,S/MIME,JAR/XPI
> 
> intermediateB ,,   
> intermediateA   ,,   
> rootrootrootCT,C,C
> ldap01 u,u,u
> [root@ldap01 ~]# certutil -M -d /etc/dirsrv/slapd-hg -t "CT,C,C" -n 
> "intermediateA"
> [root@ldap01 ~]# certutil -M -d /etc/dirsrv/slapd-hg -t "CT,C,C" -n 
> "intermediateB"
> [root@ldap01 ~]# certutil -L -d /etc/dirsrv/slapd-hg
> 
> Certificate Nickname Trust Attributes
> SSL,S/MIME,JAR/XPI
> 
> intermediateA   CT,C,C
> intermediateB   CT,C,C
> rootrootrootCT,C,C
> ldap01  u,u,u
> 
> Raised the bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1771979 
> <https://bugzilla.redhat.com/show_bug.cgi?id=1771979>

Coming back to this one - got to the bottom of this while investigating 
something else that wasn’t working.

This wasn’t a regression in NSS, but rather a regression in the openldap 
libraries shipped by RHEL7.5 and above.

For reasons that I haven’t found, there was an architecture change made half 
way through the RHEL7 lifecycle where openldap was linked to openssl instead of 
NSS.

Openldap's NSS support and openldap’s openssl support differ in a fundamental 
way - with NSS, when openldap makes an SSL connection intermediate certificates 
are filled in by the client side as normal. With openssl, when openldap makes 
an SSL connection intermediate certificates are ignored, and the connection 
breaks.

The hack workaround above fixes this because openldap’s openssl support expects 
you to place intermediate certs in your trusted certificate store. As soon as 
you mark the intermediates as trusted in NSS, the hack workaround in 389ds that 
makes replication sort-of work bound to two different crypto libraries exports 
trusted certs across into the ca certificate list passed to openldap. Openldap 
then finds the intermediates and things work.

Fundamentally there are two bugs:

- https://bugzilla.redhat.com/show_bug.cgi?id=1898924 
<https://bugzilla.redhat.com/show_bug.cgi?id=1898924>

- An architectural change half way through the lifecycle of what is supposed to 
be a stable OS.

Regards,
Graham
—

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Clarification - is this certmap.conf file correct?

[Graham Leggett]

Hi all,

Having read all the manuals and snippets I can find, I have come up with the 
following certmap.conf file:

certmap default default
default:verifycert  on
default:CmapLdapAttrnsCertSubjectDN

What I want the above to do is this:

- Look up the subject of the client certificate as the DN in the 
nsCertSubjectDN attribute.
- Also do an exact match of the certificate in the userCertificate attribute 
(verifycert on).
- Do the search across all contexts.

Does the certmap above do this?

What is not working for me is the lookup:

[18/Nov/2020:00:10:33.787682853 +0200] conn=1269 TLS1.3 128-bit AES-GCM; client 
serialNumber=365[snip]a14,CN=host.example.com; issuer CN=X,O=Y,C=UK
[18/Nov/2020:00:10:33.888476161 +0200] conn=1269 TLS1.3 failed to map client 
certificate to LDAP DN (No such object)

Looking at the source code, the above message is logged if we have a 
certificate, but we didn’t manage to map a DN:

https://github.com/389ds/389-ds-base/blob/f9638bbd8739659057249ac43b914d18716996b5/ldap/servers/slapd/auth.c#L501

Something missing from the documentation is the DN format expected by the 
nsCertSubjectDN attribute.

Is the format CN=X,serialNumber=Y as reported by openssl x509, or is it 
serialNumber=Y,CN=X as reported by the log message above?

Regards,
Graham
—
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: Installing an instance of 389ds from scratch - how?

[Graham Leggett]

On 27 Aug 2020, at 15:32, Mark Reynolds  wrote:

> All of this works correctly for me:
> 
> 
> [general]
> config_version = 2
> full_machine_name = localhost.localdomain
> start = False
> 
> [slapd]
> instance_name = graham
> port = 389
> root_dn = cn=dm
> root_password = PASSWORD
> self_sign_cert = False
> 
> [backend-userroot]
> sample_entries = yes
> suffix = dc=example,dc=com
> 
> 
> Server is created, but not started, and TLS is disabled.  Did I miss a step?

No luck for me:

[root@gatekeeper dirsrv]# cat /etc/dirsrv/slapd-default.inf
[general]
config_version = 2
full_machine_name = localhost.localdomain
start = False

[slapd]
instance_name = default
port = 389
root_dn = cn=dm
root_password = PASSWORD
self_sign_cert = False

[backend-userroot]
sample_entries = yes
suffix = dc=example,dc=com
[root@gatekeeper dirsrv]# /usr/sbin/dscreate from-file 
/etc/dirsrv/slapd-default.inf
Starting installation...
Error: Can't contact LDAP server - 107 - Transport endpoint is not connected
[root@gatekeeper dirsrv]# ps -auxwww | grep slap
dirsrv 25283  1.6  2.4 971356 197544 ?   Ssl  16:55   0:02 
/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-default -i /run/dirsrv/slapd-default.pid
root   25360  0.0  0.0 221900  1092 pts/0S+   16:58   0:00 grep 
--color=auto slap

Running dscreate through strace shows that despite being told the name of the 
server is localhost.localdomain, and despite being told not to start the 
server, dscreate tries to connect to the server using the FQDN of the machine 
on port 389, and not localhost.localdomain.

Regards,
Graham
—

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: Installing an instance of 389ds from scratch - how?

[Graham Leggett]

On 27 Aug 2020, at 02:32, William Brown  wrote:

>> Is there a documented method of installing an instance from scratch without 
>> setup-ds.pl or dscreate?
> 
> look at "dscreate create-template" and "dscreate from-template". 

That’s what I've been working from.

> The options you want are likely:
> 
> self_sign_cert = False

This flag doesn’t work, as per 
https://bugzilla.redhat.com/show_bug.cgi?id=1872915.

> start = False

This flag doesn’t work, as per 
https://bugzilla.redhat.com/show_bug.cgi?id=1872910

> The template is extremely well documented and commented when generated. 

While it is true the template is well documented, all of the options in the 
template I’ve tried to date don’t work. Thus the question - is there a document 
anywhere that describes the steps needed to go from no instance to a running 
instance?

Regards,
Graham
—
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Installing an instance of 389ds from scratch - how?

[Graham Leggett]

Hi all,

I am struggling with automating the install of 389ds.

In the world of RHEL7 and below, there was a script called setup-ds.pl which 
did a bare bones configuration of a 389ds instance, allowing you to then 
connect to the instance and configure the instance appropriately. The script 
was painful to automate, but it was possible to work around most of the issues 
in it.

In the world of RHEL8 and above, there is a replacement tool called dscreate, 
which appears to try and configure more of the server. The dscreate tool 
however does not appear to be able to install a server without starting that 
server (https://bugzilla.redhat.com/show_bug.cgi?id=1872910) and cannot install 
a server without binding that server to all ports and enabling a self signed 
certificate nor can it configure a server to bind to localhost 
(https://bugzilla.redhat.com/show_bug.cgi?id=1872915), nor can dscreate make me 
a server bound to a unix domain socket 
(https://bugzilla.redhat.com/show_bug.cgi?id=1872930).

Is there a documented method of installing an instance from scratch without 
setup-ds.pl or dscreate?

In other words, create directory X, create config file from template in Y, etc? 
Obviously I can reverse engineer the process from first principles, but I would 
like some confirmation I am on the right track.

Regards,
Graham
—
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: Replication error: network error 0

[Graham Leggett]

On 07 May 2020, at 18:51, Graham Leggett  wrote:

> I have two servers, an older CentOS7 server running 
> 389-ds-base-1.3.10.1-5.el7, and a newer CentOS8 server running 
> 389-ds-base-1.4.1.3-7.module_el8.1.0+234+96aec258, and I want to set up 
> multi-master-replication between them.
> 
> The replication agreement for CentOS7-> CentOS8 works great, replication is 
> working fine.
> 
> The replication agreement for CentOS8 -> CentOS7 doesn’t work, giving the 
> following strange error:
> 
> [07/May/2020:18:42:59.201795217 +0200] - ERR - slapi_ldap_bind - Could not 
> send bind request for id [cn=Replication Manager,cn=config] authentication 
> mechanism [SIMPLE]: error -1 (Can't contact LDAP server), system error -5987 
> (Invalid function argument.), network error 0 (Unknown error, host 
> “x.x.x:636”)
> 
> At the core of the above message is "network error 0”, otherwise known as 
> “success”.
> 
> Does this ring a bell with anyone?

Some googling sees me unearth this worrying thread: 
https://pagure.io/389-ds-base/issue/47536

Quite a while back I spent an enormous amount of debugging time on an Ubuntu 
version of 389ds that refused point blank to replicate. We eventually 
discovered an awful bug where 389ds had been bound to two competing SSL 
libraries, GnuTLS and NSS, and 389ds was passing NSS parameters (directory 
paths) to GnuTLS, which was silently failing and then eating error messages. We 
concluded Ubuntu was too broken to fix in any reasonable time and moved all 
LDAP servers to CentOS7, which worked.

Doing an ldd /usr/sbin/ns-slapd shows that on CentOS8 389ds is linked to both 
NSS and OpenSSL, which looks worryingly like the same bug has crept into 
CentOS8.

Anyone have any details?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Replication error: network error 0

[Graham Leggett]

Hi all,

I have two servers, an older CentOS7 server running 389-ds-base-1.3.10.1-5.el7, 
and a newer CentOS8 server running 
389-ds-base-1.4.1.3-7.module_el8.1.0+234+96aec258, and I want to set up 
multi-master-replication between them.

The replication agreement for CentOS7-> CentOS8 works great, replication is 
working fine.

The replication agreement for CentOS8 -> CentOS7 doesn’t work, giving the 
following strange error:

[07/May/2020:18:42:59.201795217 +0200] - ERR - slapi_ldap_bind - Could not send 
bind request for id [cn=Replication Manager,cn=config] authentication mechanism 
[SIMPLE]: error -1 (Can't contact LDAP server), system error -5987 (Invalid 
function argument.), network error 0 (Unknown error, host “x.x.x:636”)

At the core of the above message is "network error 0”, otherwise known as 
“success”.

Does this ring a bell with anyone?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: 389ds and Get Effective Rights control: neither entryLevelRights nor attributeLevelRights returned

[Graham Leggett]

On 18 Nov 2019, at 03:05, William Brown  wrote:

>> I tried that, but it made no difference. I also noticed that despite asking 
>> for attributes “*” and “+”, the java code didn’t give me any operational 
>> attributes back at all.
>> 
>> I’m assuming that entryLevelRights/attributeLevelRights are operational 
>> attributes and 389ds won’t return them with a “*” attribute on it’s own?
> 
> The attributes you "request" are the attributes it will do an effective 
> rights check on, and the server just "puts" the *rights attributes in your 
> response without asking (well, you did ask because of the control)
> 
>> 
>> I’m trying to work out whether this is a java issue or a 389ds issue.
> 
> Why not both?

Possibly - I eventually found that elsewhere in my code I was silently 
stripping any attribute that came back that didn’t have a schema, and these 
explained why entryLevelRights/attributeLevelRights were missing, but not why 
operational attributes had no schemas.

This leads to the issue of how do we find the syntax OIDs for operational 
attributes? Are these made available by 389ds in some way, or does the calling 
code have to know how to handle each type of operational attribute?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: 389ds and Get Effective Rights control: neither entryLevelRights nor attributeLevelRights returned

[Graham Leggett]

On 18 Nov 2019, at 01:19, William Brown  wrote:

> As I'm sure you're aware, the docs are here:
> 
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/viewing_the_acis_for_an_entry-get_effective_rights_control
>  
> 
> 
> I think you don't need to request the entrylevelrights or 
> attributelevelrights on the search (the log looks like you're requesting 
> them). You probably just want * or + here instead.

I tried that, but it made no difference. I also noticed that despite asking for 
attributes “*” and “+”, the java code didn’t give me any operational attributes 
back at all.

I’m assuming that entryLevelRights/attributeLevelRights are operational 
attributes and 389ds won’t return them with a “*” attribute on it’s own?

I’m trying to work out whether this is a java issue or a 389ds issue.

Are there any known issues when trying to return operational attributes from 
389ds to java JNDI calls?

> Otherwise I'm not 100% sure here. Perhaps the best thing is actually to 
> attach gdb to the server and break on:
> 
> br _ger_parse_control 
> 
> And then step through with: "next" to see what logic paths are being taken on 
> the dn parser - or if you even reach that stage.
> 
> You could alternately break on acl_get_effective_rights to see the full 
> extended op processing logic too. 
> 
> Sorry I can't give a more concrete piece of advice here :( 

gdb stops on these breakpoints, so the logic is definitely triggered, although 
I don't have any debuginfos configured to step through the code. Let me dig 
further on this.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] 389ds and Get Effective Rights control: neither entryLevelRights nor attributeLevelRights returned

[Graham Leggett]

Hi all,

After adding the Get Effective Rights control to some java code as follows, 
everything is worked as before, except neither the entryLevelRights nor the 
attributeLevelRights attributes are returned to me.

389-ds-base-1.2.11.15-97.el6_10.x86_64 is logging the following, which looks 
hopeful:

[18/Nov/2019:00:41:16 +0200] conn=1567060 op=5 SRCH base="dc=x,dc=x,dc=x" 
scope=2 filter="(&(objectClass=mailRec
ipient)(mail=m...@example.com))" attrs="* entrylevelrights attributelevelrights 
aci" authzid="mail=minf...@example.com,ou=
external,dc=x,dc=x,dc=x"
[18/Nov/2019:00:41:16 +0200] conn=1567060 op=5 RESULT err=0 tag=101 nentries=1 
etime=0 - entryLevelRights: vadn

However neither the entrylevelrights nor the attributelevelrights attributes 
are being returned in the response, and I have run out of ideas - what am I 
missing?

The java code to add the control is as follows:

BerByteArrayOutputStream berStream = new 
BerByteArrayOutputStream(
dn.length() + 50, true);
BerOctetString berString = new BerOctetString(
("dn:" + dn).getBytes());
berString.encode(berStream, true);
berStream.close();

List controls = new 
ArrayList(Arrays.asList(ctx
.getRequestControls()));
controls.add(new 
BasicControl("1.3.6.1.4.1.42.2.27.9.5.2", true,
berStream.getArray()));
ctx.setRequestControls(controls.toArray(new 
Control[controls.size()]));

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error

[Graham Leggett]

On 13 Nov 2019, at 01:37, William Brown  wrote:

>> Does anyone know why 389ds would suddenly stop sending the full certificate 
>> chain while replicating?
>> 
>> It also looks like the error handling in 389ds SSL is broken - if the slave 
>> sent “unknown CA" to the master, the master needs to log that fact, and not 
>> report the error as “success”.
> 
> We'll need to see the output of certutil -L -d /etc/dirsrv/slapd-/ 
> from both the master and replica servers please.
> 
> In a TLS auth process the client doesn't send it's CA - if you get unknown CA 
> it's most likely the replica has either had the CA and it's chain members 
> expire, or they are not marked as trusted for client auth. So that's why I'd 
> like to see the certutil output please. 

I discovered the same problem had been reported in OpenLDAP: 
https://www.centos.org/forums/viewtopic.php?t=67042

This in turn is caused by a regression in NSS, where it is no longer sufficient 
to have a trusted root certificate, you now need all intermediate certificates 
marked as trusted as well.

Making the following change to the intermediate certs fixed the problem:

[root@ldap01 ~]# certutil -L -d /etc/dirsrv/slapd-hg

Certificate Nickname Trust Attributes
 SSL,S/MIME,JAR/XPI

intermediateB ,,   
intermediateA   ,,   
rootrootrootCT,C,C
ldap01 u,u,u
[root@ldap01 ~]# certutil -M -d /etc/dirsrv/slapd-hg -t "CT,C,C" -n 
"intermediateA"
[root@ldap01 ~]# certutil -M -d /etc/dirsrv/slapd-hg -t "CT,C,C" -n 
"intermediateB"
[root@ldap01 ~]# certutil -L -d /etc/dirsrv/slapd-hg

Certificate Nickname Trust Attributes
 SSL,S/MIME,JAR/XPI

intermediateA   CT,C,C
intermediateB   CT,C,C
rootrootrootCT,C,C
ldap01  u,u,u

Raised the bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1771979

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error

[Graham Leggett]

On 13 Nov 2019, at 00:13, Mark Reynolds  wrote:
>> We have a long standing 389ds master LDAP server that was found to be unable 
>> to contact it’s slaves. Most specifically, the slaves show nothing in their 
>> logs about any kind of connection, while the master is logging this:
>> 
>> [12/Nov/2019:21:39:47.212715697 +] - ERR - slapi_ldap_bind - Could not 
>> send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error 
>> -1 (Can't contact LDAP server), system error 0 (no error), network error 0 
>> (Unknown error, host “ldap01:636”)
> What is the bind method of the agreement?  SSLCLIENTAUTH?  The problem is 
> that the ID is anonymous (anon).  So it's not binding correctly to the 
> consumer.   What do you have for these attributes in the replication 
> agreement:
> 
More of the problem was picked up by wireshark - the 389ds LDAP slave is 
telling the 389ds LDAP master that the 389ds LDAP slave does not recognise the 
CA:

Transmission Control Protocol, Src Port: 636, Dst Port: 53994, Seq: 5462, Ack: 
2279, Len: 7
Transport Layer Security
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Unknown CA)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 2
Alert Message
Level: Fatal (2)
Description: Unknown CA (48)

(The certificates are privately generated, and have been in place since 2016, 
and are all still valid.)

This in in turn caused because the 389ds LDAP master has for some reason 
decided to not pass the full certificate chain across to the slave 
(intermediates are involved) and the slave is quite correctly saying unknown CA.

Does anyone know why 389ds would suddenly stop sending the full certificate 
chain while replicating?

It also looks like the error handling in 389ds SSL is broken - if the slave 
sent “unknown CA" to the master, the master needs to log that fact, and not 
report the error as “success”.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error 0

[Graham Leggett]

Hi all,

We have a long standing 389ds master LDAP server that was found to be unable to 
contact it’s slaves. Most specifically, the slaves show nothing in their logs 
about any kind of connection, while the master is logging this:

[12/Nov/2019:21:39:47.212715697 +] - ERR - slapi_ldap_bind - Could not send 
bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 
(Can't contact LDAP server), system error 0 (no error), network error 0 
(Unknown error, host “ldap01:636”)

Key is "system error 0 (no error)”, which leaves us stumped. The error is 
obviously “success”.

Has anyone seen this kind of thing before?

This is 389ds running on CentOS7 as follows:

389-ds-base-1.3.9.1-10.el7.x86_64

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] When binding non-anonymously, error code 48 - Anonymous access is not allowed

[Graham Leggett]

Hi all,

My Jira server just forgot all of it’s LDAP settings for no clear reason. While 
trying to put the settings back, Jira is logging into 389ds by binding as the 
user "cn=Atlassian,dc=x”.

389ds is in return responding as follows:

[LDAP: error code 48 - Anonymous access is not allowed]; nested exception is 
javax.naming.AuthenticationNotSupportedException: [LDAP: error code 48 - 
Anonymous access is not allowed]

[02/Nov/2018:17:11:23 +0200] conn=140630 op=0 BIND dn="cn=Atlassian,dc=x" 
method=128 version=3
[02/Nov/2018:17:11:23 +0200] conn=140630 op=0 RESULT err=48 tag=97 nentries=0 
etime=1
[02/Nov/2018:17:11:23 +0200] conn=140630 op=-1 fd=134 closed - B1

Why would 389ds complain that anonymous access is not allowed on a 
non-anonymous bind? What am I missing?

(389-ds-base-1.2.11.15-97.el6_10.x86_64 on RHEL6)

Regards,
Graham
—
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

[389-users] Re: [important] Removing i686 support

[Graham Leggett]

On 04 Jan 2018, at 2:09 AM, William Brown  wrote:

> We have begun the process to remove i686 support from the server. You
> should plan that all 1.4.x builds will support 64bit platforms only. 
> 
> https://pagure.io/389-ds-base/issue/49514
> 
> We recommend that you move to a 64bit platform (x86_64, aarch64,
> ppc64le) which we support.

Can you clarify the justification for this. What happens if you want to run 
389ds on an embedded low power 32 bit device?

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: rest389

[Graham Leggett]

On 27 Dec 2017, at 2:27 AM, carne_de_passaro  wrote:

> Oh, it's a shame, the REST interface would be very interesting and useful.

+1.

Admin dashboards are a huge attack surface, while they have their uses they 
aren’t universally a good idea in many cases. A simple rest API would be far 
better.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] 389ds refuses to start up after a reboot on CentOS7

[Graham Leggett]

Hi all,

I am having some unexpected behaviour from 389ds v1.3.4.0-32 on CentOS7 and I 
need to check if this looks familiar to anybody.

After installing 389ds and configuring it successfully, and proving 
successfully that I can connect to it and that it contains data, I restarted 
the machine to prove the server comes up on reboot. 389ds refused to come up.

Attempts to bring the server up manually using “systemctl start dirsrv.target” 
have no effect.

What eventually got the service to start was “systemctl restart 
dirsrv@instancename”, but this hasn’t solved the start-at-boot problem.

Does anyone have an accurate guide on 389ds and systemd?

Regards,
Graham
—
--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] SSL/TLS server side debugging howto?

[Graham Leggett]

Hi all,

I have a 389ds v1.3.4 server as deployed by CentOS7 configured with SSL/TLS to 
require client certificates.

Attempts to connect to this server using “openssl s_client” fail, and the 
failure is triggered by the 389ds server side as follows:

4 4  0.0079 (0.0009)  S>CV3.3(2)  Alert
level   fatal
value   bad_certificate
40.0080 (0.)  S>C  TCP FIN

Unfortunately the error log on the 389ds server is dead silent on this issue, 
and without a sensible error message it is making debugging this very difficult.

What mechanism must I use to enable any kind of logging inside 389ds that will 
indicate why a particular SSL/TLS connection is being rejected?

Regards,
Graham
—
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Replication + SSLCLIENTAUTH failure: setup_ol_tls_conn - failed: unable to create new TLS context

[Graham Leggett]

On 31 Mar 2016, at 12:25 AM, Graham Leggett  wrote:

>> [30/Mar/2016:17:19:19 +] setup_ol_tls_conn - failed: unable to create 
>> new TLS context
>> [30/Mar/2016:17:19:19 +] slapi_ldap_bind - Error: could not configure 
>> the server for cert auth - error -1 - make sure the server is correctly 
>> configured for SSL/TLS
>> [30/Mar/2016:17:19:19 +] NSMMReplicationPlugin - agmt="cn=Agreement 
>> ldap.example.com" (ldap:636): Replication bind with EXTERNAL auth failed: 
>> LDAP error 0 (Success) ()
> 
> The code looks broken, raised a bug with theoretical patch here:
> 
> https://fedorahosted.org/389/ticket/48782

Much stepping through code later.

It turns out that on Ubuntu Trusty, 389ds the server is backed with NSS as the 
security library, however 389ds’s replication plugin is backed with gnutls.

The NSS nicknames for certfile, keyfile and cacertdir are passed into gnutls, 
which then fails here as follows:

/* OpenSSL builds the cert chain for us, but GnuTLS
 * expects it to be present in the certfile. If it's
 * not, we have to build it ourselves. So we have to
 * do some special checks here...
 */
rc = tlsg_getfile( lt->lt_keyfile, &buf );
if ( rc ) return -1;


397 in tls_g.c
(gdb) print rc
$5 = 
(gdb) print *lt
$6 = {
  lt_certfile = 0x7f1f9801f3a0 "Internal (Software) Token:ldap.example.com", 
lt_keyfile = 0x7f1f980187b0 "Server-Key", lt_dhfile = 0x0, lt_cacertfile = 0x0, 
  lt_cacertdir = 0x7f1f98013960 "/etc/dirsrv/slapd-hg", lt_ciphersuite = 0x0, 
lt_crlfile = 0x0, lt_randfile = 0x0, 
  lt_protocol_min = 768}
(gdb) print buf
$7 = 0x0

The “return -1” above is the origin of the “-1” return code in the logged error 
message.

Running ldd against the ns-slapd binary shows this (snipped):

r...@ldap.example.com:~/src/openldap-2.4.31# ldd /usr/sbin/ns-slapd 
libnss3.so => /usr/lib/x86_64-linux-gnu/libnss3.so (0x7f0e14e6)
libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 
(0x7f0e12def000)

It looks like no kind of replication could ever work on Ubuntu Trusty, as NSS 
parameters are passed to gnutls, which can only fail.

Has anyone seen this kind of thing before?

Regards,
Graham
—
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Replication + SSLCLIENTAUTH failure: setup_ol_tls_conn - failed: unable to create new TLS context

[Graham Leggett]

On 30 Mar 2016, at 7:30 PM, Graham Leggett  wrote:

> I have tried to set up a replication agreement on a 389ds master to send 
> updates to a 389ds slave. The master is configure to use client certs for 
> authentication.
> 
> The 389ds master fails each time it attempts to contact the slave with the 
> following message, and tcpdump shows no traffic flowing over the wire:
> 
> [30/Mar/2016:17:19:19 +] setup_ol_tls_conn - failed: unable to create new 
> TLS context
> [30/Mar/2016:17:19:19 +] slapi_ldap_bind - Error: could not configure the 
> server for cert auth - error -1 - make sure the server is correctly 
> configured for SSL/TLS
> [30/Mar/2016:17:19:19 +] NSMMReplicationPlugin - agmt="cn=Agreement 
> ldap.example.com" (ldap:636): Replication bind with EXTERNAL auth failed: 
> LDAP error 0 (Success) ()

The code looks broken, raised a bug with theoretical patch here:

https://fedorahosted.org/389/ticket/48782

Regards,
Graham
—
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Re: Replication + SSLCLIENTAUTH failure: setup_ol_tls_conn - failed: unable to create new TLS context

[Graham Leggett]

On 30 Mar 2016, at 7:45 PM, Noriko Hosoi  wrote:

> How does your Replication Manager on the slave server look like?
> 
> ldapsearch -x -h  -p  [...] -b "cn=Replication 
> Manager,cn=config"
> 
> Also, could you share your certmap.conf on the slave server?  And the Subject 
> in the cert?

As I pointed out below, tcpdump shows no traffic flows at all.

As a result the config of the slave server won’t have any bearing on the 
problem - that server is never contacted.

Regards,
Graham
—
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

[389-users] Replication + SSLCLIENTAUTH failure: setup_ol_tls_conn - failed: unable to create new TLS context

[Graham Leggett]

Hi all,

I have tried to set up a replication agreement on a 389ds master to send 
updates to a 389ds slave. The master is configure to use client certs for 
authentication.

The 389ds master fails each time it attempts to contact the slave with the 
following message, and tcpdump shows no traffic flowing over the wire:

[30/Mar/2016:17:19:19 +] setup_ol_tls_conn - failed: unable to create new 
TLS context
[30/Mar/2016:17:19:19 +] slapi_ldap_bind - Error: could not configure the 
server for cert auth - error -1 - make sure the server is correctly configured 
for SSL/TLS
[30/Mar/2016:17:19:19 +] NSMMReplicationPlugin - agmt="cn=Agreement 
ldap.example.com" (ldap:636): Replication bind with EXTERNAL auth failed: LDAP 
error 0 (Success) ()

The server is correctly configured for SSL/TLS, and I am able to bind to both 
the master and the slave over SSL port 636.

The replication agreement looks as follows:

dn: cn=Agreement 
ldap.example.com,cn=replica,cn=dc\3Dexample\,dc\3Dcom,cn=mapping tree,cn=config
objectClass: nsds5replicationagreement
objectClass: top
cn: Agreement ldap.example.com
description: Replication agreement to ldap.example.com
nsDS5ReplicaBindDN: cn=Replication Manager,cn=config
nsDS5ReplicaBindMethod: SSLCLIENTAUTH
nsds5replicaChangesSentSinceStartup: 
nsDS5ReplicaHost: ldap.example.com
nsds5replicaLastInitEnd: 0
nsds5replicaLastInitStart: 20160330162755Z
nsds5replicaLastInitStatus: 255 Replication error acquiring replica: unknown
  error
nsds5replicaLastUpdateEnd: 0
nsds5replicaLastUpdateStart: 0
nsds5replicaLastUpdateStatus: 255 Replication error acquiring replica: unkno
 wn error - Unable to acquire replica
nsDS5ReplicaPort: 636
nsDS5ReplicaRoot: dc=example,dc=com
nsDS5ReplicaTransportInfo: SSL
nsds5replicaUpdateInProgress: FALSE

Is there anything I can do to coax a useful error message out of the master 
server? "LDAP error 0 (Success)” tells me this is a bug of some kind, as why 
would it fail saying success?

This is 389ds on Ubuntu 14.04:

ii  389-ds-base   1.3.2.16-0ubuntu1amd64
389 Directory Server suite - server

Regards,
Graham
—
--
389 users mailing list
389-users@%(host_name)s
http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org

Re: [389-users] 389ds and certificateExactMatch - is it supported?

[Graham Leggett]

On 28 Jan 2015, at 6:33 PM, Rich Megginson  wrote:

>> Does 389ds offer certificateExactMatch support as per the RFCs?
> 
> No, that's why it is commented out.  We do not have support for the 
> certificate* matching rules.  That's why we just use octetString i.e. it just 
> does a memcmp().

I’ve been trying the option of using octetStringMatch with a filter that looks 
like this:

(userCertificate=#308203aa3082[snip])

The error I get back is:

LDAP: error code 11 - Administrative Limit Exceeded

A number of questions:

- The encoding was obtained from the java javax.naming.ldap.Rdn class, which 
seems to want to encode the DER byte array of the certificate being searched 
for as a hash symbol followed by hex digits, as opposed to \00\11\22 (etc) as 
seen in many examples online. Is this encoding correct? (I assume it is).

- I noticed that no index existed for userCertificate, so I added an index on 
equality. The searches still take a very long time (with Directory Manager) and 
Administrative limit exceeded with normal users. Am I right in understanding 
that userCertificate searches are not filtered?

Regards,
Graham
—

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

[389-users] 389ds and certificateExactMatch - is it supported?

[Graham Leggett]

Hi all,

After struggling to get a certificateExactMatch query to work, I’ve discovered 
that in 389ds the certificateExactMatch rule in the schema has been marked as 
commented out like this:

# TODO - Add Certificate syntax
#attributeTypes: ( 2.5.4.36 NAME 'userCertificate'
#  DESC 'X.509 user certificate'
#  EQUALITY certificateExactMatch
#  SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
attributeTypes: ( 2.5.4.36 NAME 'userCertificate'
  DESC 'X.509 user certificate'
  EQUALITY octetStringMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
  X-ORIGIN 'RFC 4523’)

Does 389ds offer certificateExactMatch support as per the RFCs? Simply 
uncommenting out the above results in startup failure below:

[28/Jan/2015:15:55:53 +] dse_read_one_file - The entry cn=schema in file 
/etc/dirsrv/slapd-monica/schema/05rfc4523.ldif (lineno: 1) is invalid, error 
code 21 (Invalid syntax) - attribute type userCertificate: Unknown attribute 
syntax OID “1.3.6.1.4.1.1466.115.121.1.8"

Regards,
Graham
—

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

[389-users] Searching for userCertificate - what encoding is used in the query filter?

[Graham Leggett]

Hi all,

I have a query filter that looks like this: (userCertificate={0}${1})

I am trying to search for an explicit certificate in a directory, based on the 
serial number and the issuer DN. Can anyone confirm what encoding these values 
need to be in, and hat java library might help provide that encoding?

Regards,
Graham
—

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

[389-users] Searching for userCertificate

[Graham Leggett]

Hi all,

I am trying to research how it might be possible to do a directory search for 
an exact match on a digital certificate storing in userCertificate. Most 
specifically, I want to do a simple lookup based on a binary match of the cert, 
its not enough to do the combination of DN and serial number.

Does anyone know whether a simple search will work with 389ds or if there are 
any gotchas to look out for? Some googling would suggest that openldap can’t do 
it, I was wondering if 389ds had the same problem.

Regards,
Graham
—

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

[389-users] Sort control: can I sort by an attribute without a schema (using extensibleObject)

[Graham Leggett]

Hi all,

I am currently trying to add a sort control to an LDAP query, but the attribute 
I am trying to sort on isn't defined in the schema - the attribute exists as 
the object has extensibleObject.

I am getting a NamingException from our code, and the 389s log reports error 12 
as below. Is what I'm trying to do possible?

[20/May/2014:16:39:09 +] conn=70187 op=3 SORT status (52)
[20/May/2014:16:39:09 +] conn=70187 op=3 RESULT err=12 tag=101 nentries=0 
etime=0 notes=U

Regards,
Graham
--

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

Re: [389-users] Failed to send extended operation: LDAP error -1 (Can't contact LDAP server)

[Graham Leggett]

On 05 May 2014, at 6:24 PM, Rich Megginson  wrote:

> I think the problem is this:
> 
> [05/May/2014:17:34:41 +0200] - import userRoot: WARNING: Skipping entry 
> "nsuniqueid=---,o=Foo,c=ZA" which has no 
> parent, ending at line 18 of file "/tmp/replica.ldif"
> 
> Does the consumer have a suffix o=Foo,c=ZA, with its own database, and with 
> its own cn=replica entry?

It does, yes.

The first two entries seem to be in the wrong order, the second line creates 
the root, while the first line takes it for granted that the root is already 
there:

version: 1

# entry-id: 1
dn: nsuniqueid=---,o=Foo,c=ZA
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsUniqueId: ---
nsds50ruv: {replicageneration} 536731fb0001
nsds50ruv: {replica 1 ldap://servera.example.com:389} 536732320001 5367b
 a5800080001
nsds50ruv: {replica 5 ldap://serverb.example.com:389}
nsds50ruv: {replica 3 ldap://serverc.example.com:389}
o: wired
nsruvReplicaLastModified: {replica 1 ldap://servera.example.com:389} 
nsruvReplicaLastModified: {replica 5 ldap://serverb.example.com:389} 
nsruvReplicaLastModified: {replica 3 ldap://serverc.example.com:389} 

# entry-id: 2
dn: o=Foo,c=ZA
modifyTimestamp;adcsn-5367ba580001;vucsn-5367ba580001: 2014050
 5081952Z
modifiersName;adcsn-5367ba580001;vucsn-5367ba580001: cn=direct
 ory manager
aci;adcsn-5367ba580001;vucsn-5367ba580001: (targetattr="*")(ve
 rsion 3.0; acl "Configuration Administrators Group"; allow (all) groupdn="ld
 ap:///cn=Configuration Administrators, ou=Groups, ou=TopologyManagement, o=N
 etscapeRoot";)
aci;vucsn-5367ba580001: (targetattr="*")(version 3.0; acl "Configurati
 on Administrator"; allow (all) userdn="ldap:///uid=admin,ou=Administrators, 
 ou=TopologyManagement, o=NetscapeRoot";)
aci;vucsn-5367ba580001: (targetattr = "*")(version 3.0; acl "SIE Group
 "; allow (all) groupdn = "ldap:///cn=slapd-servera, cn=CentOs Directory Ser
 ver, cn=Server Group, cn=servera.example.com, ou=example.com, o=NetscapeRoot";)
objectClass;vucsn-536732320001: top
objectClass;vucsn-536732320001: organization
o;vucsn-536732320001;mdcsn-536732320001: Wired
creatorsName;vucsn-536732320001: cn=directory manager
createTimestamp;vucsn-536732320001: 20140504223858Z
nsUniqueId: c0abd788-d3dc11e3-a8fe9749-4cbd5e1c

Regards,
Graham
--

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

Re: [389-users] Failed to send extended operation: LDAP error -1 (Can't contact LDAP server)

[Graham Leggett]

On 05 May 2014, at 6:18 PM, Mark Reynolds  wrote:

>> nsslapd-maxbersize: 0
> 0 tells the server to use the default value of 2mb, you need to set it
> higher(5mb?).

You're kidding. Zero actually means 2MB. Intuitive.

I double checked servera and serverb, both have these set as follows:

nsslapd-maxbersize: 2147483647

Changing serverc from 0 to 2147483647 and reinitializing, and suddenly it 
replicates.

> https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnconfig
>  
> (search for maxber)

Had I got a clear error message pointing me at maxber I probably would have 
figured this out, but the silent failure with no explanation sent me on a 
two-and-a-half-day wild goose chase. :(

Regards,
Graham
--

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

Re: [389-users] Failed to send extended operation: LDAP error -1 (Can't contact LDAP server)

[Graham Leggett]

On 04 May 2014, at 10:18 PM, Graham Leggett  wrote:

> We got "ber_get_next failed for connection 2" without being told what exactly 
> failed. Will dig on the other side to see if there are any clues.

On the other side we see this:

[04/May/2014:21:29:10 +0100] NSMMReplicationPlugin - agmt_add: begin
[04/May/2014:21:29:10 +0100] NSMMReplicationPlugin - agmt="cn=Agreement 
serverc.example.com" (serverc:636): Trying secure slapi_ldap_init_ext
[04/May/2014:21:29:10 +0100] NSMMReplicationPlugin - agmt="cn=Agreement 
serverc.example.com" (serverc:636): binddn = cn=Replication Manager,c
n=config,  passwd = {DES}xxx
[04/May/2014:21:29:11 +0100] NSMMReplicationPlugin - agmt="cn=Agreement 
serverc.example.com" (serverc:636): No linger to cancel on the connec
tion
[04/May/2014:21:29:12 +0100] - _csngen_adjust_local_time: gen state before 
53670e7b0001:1399235244:0:27599
[04/May/2014:21:29:12 +0100] - _csngen_adjust_local_time: gen state after 
53670ee7:1399235352:0:27599
[04/May/2014:21:29:12 +0100] NSMMReplicationPlugin - agmt="cn=Agreement 
serverc.example.com" (serverc:636): Replica was successfully acquired
.
[04/May/2014:21:29:12 +0100] NSMMReplicationPlugin - Beginning total update of 
replica "agmt="cn=Agreement serverc.example.com" (serverc:636)
".
[04/May/2014:21:29:12 +0100] - conn 2 leaving turbo mode due to 4
[04/May/2014:21:29:12 +0100] - listener got signaled
[04/May/2014:21:29:19 +0100] NSMMReplicationPlugin - agmt="cn=Agreement 
serverc.example.com" (serverc:636): Failed to send extended operation: LDAP 
error -1 (Can't contact LDAP server)

The above message is printed by the following code:

slapi_log_error(SLAPI_LOG_FATAL, repl_plugin_name,
"%s: Failed to send %s operation: LDAP 
error %d (%s)\n",
agmt_get_long_name(conn->agmt),
op_string ? op_string : "NULL", rc, 
ldap_err2string(rc));

The above error is bogus - there is no such error as "error -1" in LDAP, it 
turns out that at the top of perform_operation() the rc variable is set as 
follows and appears to drop through to the error message without anything 
happening:

int rc = -1;

Looking at how rc could drop through this code untouched we see this below, 
there is no default section in the switch, and so it seems optype has a value 
other than those handled:

switch (optype)
{
case CONN_ADD:
conn->status = STATUS_PROCESSING_ADD;
op_string = "add";
rc = ldap_add_ext(conn->ld, dn, attrs, server_controls,
NULL /* clientctls */,  &msgid);
break;
case CONN_MODIFY:
conn->status = STATUS_PROCESSING_MODIFY;
op_string = "modify";
rc = ldap_modify_ext(conn->ld, dn, attrs, 
server_controls,
NULL /* clientctls */,  &msgid);
break;
case CONN_DELETE:
conn->status = STATUS_PROCESSING_DELETE;
op_string = "delete";
rc = ldap_delete_ext(conn->ld, dn, server_controls,
NULL /* clientctls */, &msgid);
break;
case CONN_RENAME:
conn->status = STATUS_PROCESSING_RENAME;
op_string = "rename";
rc = ldap_rename(conn->ld, dn, newrdn, newparent, 
deleteoldrdn,
server_controls, NULL /* clientctls */, &msgid);
break;
case CONN_EXTENDED_OPERATION:
conn->status = STATUS_PROCESSING_EXTENDED_OPERATION;
op_string = "extended";
rc = ldap_extended_operation(conn->ld, extop_oid, 
extop_payload,
server_controls, NULL /* clientctls */, &msgid);
}

Putting in a breakpoint at perform_operation() shows that optype each time is 
always CONN_EXTENDED_OPERATION, so it is looking like ldap_extended_operation() 
is returning -1. The code is optimised, so I can't be sure though.

The log continues:

[04/May/2014:21:29:19 +0100] NSMMReplicationPlugin - agmt="cn=Agreement 
serverc.example.com" (serverc:636): Disconnected from the consumer
[04/May/2014:21:29:19 +0100] NSMMReplicationPlugin - agmt="cn=Agreement 
serverc.example.com" (serverc:636): Connection disconnected by another thread
[04/May/2014:21:29:19 +0100] NSMMReplicationPlugin - agmt="cn=Agreement 

Re: [389-users] Failed to send extended operation: LDAP error -1 (Can't contact LDAP server)

[Graham Leggett]

On 05 May 2014, at 5:41 PM, Rich Megginson  wrote:

>>> See https://fedorahosted.org/389/ticket/47606
>> 
>> This bug looks quite consistent with the OP's symptoms and the presence of a 
>> large group entry, but he should be seeing "Incoming BER Element was too 
>> long" in the consumer log (don't think I saw that in any of the log snippets 
>> posted..).
> 
> The consumer access log should have a closed - B2 message if this is the 
> problem.

All three servers have what seems to be unlimited bersize values:

nsslapd-maxbersize: 0

I am at a loss as to what exactly is triggering this, what I do know is:

- Any attempt by the supplier servera to initialize the serverc supplier 
results in complete destruction of any existing data in serverc.
- The point at which the initilization dies is six seconds after an attempt is 
made to synchronize a group containing 21000 uniqueMembers over a slower link 
than servera and serverb.
- Attempts to synchronise serverc using a manual export of ldif from servera 
makes no difference, the servers refuse to sync with one another. Has this been 
recently confirmed to work?

Regards,
Graham
--

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

Re: [389-users] Failed to send extended operation: LDAP error -1 (Can't contact LDAP server)

[Graham Leggett]

On 05 May 2014, at 5:52 PM, David Boreham  wrote:

> Are you importing an ldif file with the right content for replica 
> initialization ? (the error message suggests not).

The command line I used on servera was this:

/usr/lib64/dirsrv/slapd-servera/db2ldif.pl -v -r -D "cn=Directory Manager" -w - 
-n userRoot -a /tmp/replica.ldif

The command line I used on serverc was this:

/usr/lib64/dirsrv/slapd-serverc/ldif2db.pl -v -D "cn=Directory Manager" -j 
/etc/dirsrv/slapd-serverc.secret -n userRoot -i /tmp/replica.ldif

The log on serverc looked like this:

[05/May/2014:17:34:41 +0200] - import userRoot: Beginning import job...
[05/May/2014:17:34:41 +0200] - import userRoot: Index buffering enabled with 
bucket size 19
[05/May/2014:17:34:41 +0200] - import userRoot: Processing file 
"/tmp/replica.ldif"
[05/May/2014:17:34:41 +0200] - import userRoot: WARNING: Skipping entry 
"nsuniqueid=---,o=Foo,c=ZA" which has no 
parent, ending at line 18 of file "/tmp/replica.ldif"
[05/May/2014:17:34:57 +0200] - import userRoot: Finished scanning file 
"/tmp/replica.ldif" (62931 entries)
[05/May/2014:17:34:58 +0200] - import userRoot: Workers finished; cleaning up...
[05/May/2014:17:34:58 +0200] - import userRoot: Workers cleaned up.
[05/May/2014:17:34:58 +0200] - import userRoot: Cleaning up producer thread...
[05/May/2014:17:34:58 +0200] - import userRoot: Indexing complete.  
Post-processing...
[05/May/2014:17:34:58 +0200] - import userRoot: Generating numSubordinates 
complete.
[05/May/2014:17:34:58 +0200] - import userRoot: Flushing caches...
[05/May/2014:17:34:58 +0200] - import userRoot: Closing files...
[05/May/2014:17:34:59 +0200] - import userRoot: Import complete.  Processed 
62931 entries (1 were skipped) in 18 seconds. (3496.17 entries/sec)

No idea why the "skipped entry", the root DSE existed at the time of the import 
and so there was a parent.

> The documentation on this page covers the initialization of a replica by ldif 
> :
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Initializing_Consumers.html

Those were the docs that I followed.

Regards,
Graham
--

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

Re: [389-users] Failed to send extended operation: LDAP error -1 (Can't contact LDAP server)

[Graham Leggett]

On 05 May 2014, at 5:39 PM, David Boreham  wrote:

>> See https://fedorahosted.org/389/ticket/47606
> 
> This bug looks quite consistent with the OP's symptoms and the presence of a 
> large group entry, but he should be seeing "Incoming BER Element was too 
> long" in the consumer log (don't think I saw that in any of the log snippets 
> posted..).

Everything I've encountered so far points at a timing issue, as servera and 
serverb communicate over a fast network (even though they're a quarter way 
round the world from each other) and serverc is on a slow network 
(comparatively speaking). servera/serverb are able to replicate fine, but 
serverc always fails, regardless of whether we try triggering the initialize 
from servera or serverb.

I was finally successful in exporting a replica ldif file from servera and 
importing it into serverc, but serverc still complains as follows:

[05/May/2014:17:36:04 +0200] NSMMReplicationPlugin - agmt="cn=Agreement 
servera.example.com" (servera:636): Replica has a different generation ID than 
the local data.

I haven't the faintest clue what a "generation ID" is, how you set it, or what 
the administrator is supposed to do should this be different.

Regards,
Graham
--

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

Re: [389-users] Failed to send extended operation: LDAP error -1 (Can't contact LDAP server)

[Graham Leggett]

On 05 May 2014, at 11:37 AM, Graham Leggett  wrote:

>> It should be possible to add an N+1th replica to an N-node deployment. 
>> Replication agreements are peer-to-peer, so you just add a new replication 
>> agreement from each of the servers you want to feed changes to the N+1th 
>> (typically all of them).
> 
> What I've learned so far:
> 
> - servera has "syntax checking" switched off, and contains data with syntax 
> errors. The data is 15 years old.
> - serverb has "syntax checking" switched on, but has successfully been able 
> to replicate in the past. Now replication is broken with serverb.
> - serverc has "syntax checking" switched on, and has never been able to 
> replicate. Serverc is brand new.
> 
> What appears to be happening is that during the replication process, an LDAP 
> operation that is accepted on servera is being rejected by serverc. The 
> replication process is brittle, and has not been coded to handle any kind of 
> error during the replication process, and so fails abruptly with "ERROR bulk 
> import abandoned" and no further explanation. The error that triggered the 
> abort is only visible by turning trace logging on.

With a higher level of trace logging I have learned some more.

One of the objects being replicated is a large group containing about 21000 
uniqueMembers. When it comes to replicate this object, the replication pauses 
for about 6 seconds or so, and at that point it times out, responding with the 
following misleading error message:

[05/May/2014:15:33:36 +0100] NSMMReplicationPlugin - agmt="cn=Agreement 
serverc.example.com" (serverc:636): Failed to send extended operation: LDAP 
error -1 (Can't contact LDAP server)

serverc is in Johannesburg, on a far slower connection than servera in DFW and 
serverb in London. It appears there is some kind of timeout that kicks in and 
causes the replication to suddenly be abandoned without warning.

Does anyone know what timeout is used during replication and how you set this 
timeout?

Regards,
Graham
--

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

[389-users] archive2db: Failed to read backup file set. Either the directory specified doesn't exist, or it exists but doesn't contain a valid backup set, or file permissions prevent the server readin

[Graham Leggett]

Hi all,

I am now trying to use the bak2db.pl script in an effort to restore a backup as 
follows, and receive the error below. Can anyone point out what I am doing 
wrong?

(I had to manually hack the bak2db.pl script to change the host to localhost, 
the script blindly assumes the box is accessible on port 389 when it is not)

[root@joey ~]# /usr/lib64/dirsrv/slapd-serverc/bak2db.pl -v -D "cn=Directory 
Manager" -j /etc/dirsrv/slapd-serverc.secret -a /tmp/replicate/userRoot/ -n 
userRoot
ldap_initialize( ldap://localhost:389 )
add objectclass:
top
extensibleObject
add cn:
restore_2014_5_5_15_14_40
add nsInstance:
userRoot
add nsArchiveDir:
/tmp/replicate/userRoot/
add nsDatabaseType:
ldbm database
adding new entry "cn=restore_2014_5_5_15_14_40, cn=restore, cn=tasks, cn=config"
modify complete

So far so good.

In the logfile:

[05/May/2014:15:14:39 +0200] - Beginning restore to 'ldbm database'
[05/May/2014:15:14:39 +0200] - Warning: Unable to read dbversion file in 
/tmp/replicate/userRoot
[05/May/2014:15:14:39 +0200] - Bringing userRoot offline...
[05/May/2014:15:14:39 +0200] NSMMReplicationPlugin - 
multimaster_be_state_change: replica o=wired,c=za is going offline; disabling 
replication
[05/May/2014:15:14:40 +0200] - Waiting for 4 database threads to stop
[05/May/2014:15:14:41 +0200] - All database threads now stopped
[05/May/2014:15:14:41 +0200] - Restore: backup directory 
/tmp/replicate/userRoot does not exist.
[05/May/2014:15:14:41 +0200] - archive2db: Failed to read backup file set. 
Either the directory specified doesn't exist, or it exists but doesn't contain 
a valid backup set, or file permissions prevent the server reading the backup 
set.  error=53 (Invalid request descriptor)
[05/May/2014:15:14:41 +0200] NSMMReplicationPlugin - 
multimaster_be_state_change: replica o=wired,c=za is coming online; enabling 
replication
[05/May/2014:15:14:41 +0200] - Restore finished.

Yes, the directory does exist:

[root@joey ~]# ls -al /tmp/replicate/userRoot
total 239624
drwx--. 2 nobody nobody  4096 May  5 12:08 .
drwx--. 4 nobody nobody  4096 May  5 12:08 ..
-rw---. 1 nobody nobody49 May  5 12:08 DBVERSION
-rw---. 1 nobody nobody 16384 May  5 12:08 aci.db4
-rw---. 1 nobody nobody   2482176 May  5 12:08 ancestorid.db4
-rw---. 1 nobody nobody 16384 May  5 12:08 associatedDomain.db4
-rw---. 1 nobody nobody 16384 May  5 12:08 certificateUUID.db4
-rw---. 1 nobody nobody  24117248 May  5 12:08 cn.db4
-rw---. 1 nobody nobody 16384 May  5 12:08 contractClass.db4
-rw---. 1 nobody nobody 16384 May  5 12:08 
contractCustomerCounterparty.db4
-rw---. 1 nobody nobody 16384 May  5 12:08 
contractRecipientCounterparty.db4
-rw---. 1 nobody nobody 16384 May  5 12:08 
contractVendorCounterparty.db4
-rw---. 1 nobody nobody  22487040 May  5 12:08 entryrdn.db4
-rw---. 1 nobody nobody   5316608 May  5 12:08 givenName.db4
-rw---. 1 nobody nobody 16384 May  5 12:08 hushkeyAddress.db4
-rw---. 1 nobody nobody 16384 May  5 12:08 hushkeyReference.db4
-rw---. 1 nobody nobody 159891456 May  5 12:08 id2entry.db4
-rw---. 1 nobody nobody 16384 May  5 12:08 ipHostNumber.db4
-rw---. 1 nobody nobody  11468800 May  5 12:08 mail.db4
-rw---. 1 nobody nobody 40960 May  5 12:08 mailAlternateAddress.db4
-rw---. 1 nobody nobody 24576 May  5 12:08 mailHost.db4
-rw---. 1 nobody nobody 16384 May  5 12:08 memberCertificateIssuerDN.db4
-rw---. 1 nobody nobody 16384 May  5 12:08 
memberCertificateSubjectDN.db4
-rw---. 1 nobody nobody 16384 May  5 12:08 nscpEntryDN.db4
-rw---. 1 nobody nobody   6430720 May  5 12:08 nsuniqueid.db4
-rw---. 1 nobody nobody 24576 May  5 12:08 numsubordinates.db4
-rw---. 1 nobody nobody   2473984 May  5 12:08 objectclass.db4
-rw---. 1 nobody nobody 16384 May  5 12:08 owner.db4
-rw---. 1 nobody nobody802816 May  5 12:08 parentid.db4
-rw---. 1 nobody nobody   5308416 May  5 12:08 sn.db4
-rw---. 1 nobody nobody 16384 May  5 12:08 uid.db4
-rw---. 1 nobody nobody   4243456 May  5 12:08 uniquemember.db4

Anyone see any reason why this wouldn't work?

Regards,
Graham
--

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

[389-users] bak2db script: how do you use it?

[Graham Leggett]

Hi all,

I am now trying to make the initial replication happen manually through the 
restoration of a backup. This is also turning out to be strangely difficult.

After backing up servera I have the following directory on serverc:

[root@serverc ~]# ls -al /tmp/replicate/
total 16
drwx--. 4 nobody nobody 4096 May  5 12:08 .
drwxrwxrwt. 6 root   root   4096 May  5 13:30 ..
drwx--. 2 nobody nobody 4096 May  5 12:08 NetscapeRoot
drwx--. 2 nobody nobody 4096 May  5 12:08 userRoot

I want to restore the contents of userRoot to serverc, which looks like this:

[root@serverc ~]# ls -al /var/lib/dirsrv/slapd-serverc/db/
total 20604
drwxrwx---. 3 nobody nobody 4096 May  5 13:31 .
drwxrwx---. 5 nobody nobody 4096 May  5 13:30 ..
-rw---. 1 nobody nobody   49 May  5 13:31 DBVERSION
-rw---. 1 nobody nobody24576 May  5 13:31 __db.001
-rw---. 1 nobody nobody  1736704 May  5 13:37 __db.002
-rw---. 1 nobody nobody 10002432 May  5 13:31 __db.003
-rw---. 1 nobody nobody  1081344 May  5 13:37 __db.004
-rw---. 1 nobody nobody  8134656 May  5 13:31 __db.005
-rw---. 1 nobody nobody90112 May  5 13:31 __db.006
-rw---. 1 nobody nobody 10485760 May  5 13:31 log.01
drwx--. 2 nobody nobody 4096 May  5 13:30 userRoot

I try and import the backup like so:

[root@serverc ~]# /usr/lib64/dirsrv/slapd-serverc/bak2db /tmp/replicate/ -n 
userRoot
[05/May/2014:13:49:53 +0200] 389-Directory/1.2.11.15 - debug level: backend 
(524288)
[05/May/2014:13:49:53 +0200] - Warning: Unable to read dbversion file in 
/tmp/replicate
[05/May/2014:13:49:53 +0200] - Restore: backup directory /tmp/replicate does 
not contain a complete backup
[05/May/2014:13:49:53 +0200] - archive2db: Failed to read backup file set. 
Either the directory specified doesn't exist, or it exists but doesn't contain 
a valid backup set, or file permissions prevent the server reading the backup 
set.  error=53 (Invalid request descriptor)

No luck. Let's guess again:

[root@serverc ~]# /usr/lib64/dirsrv/slapd-serverc/bak2db 
/tmp/replicate/userRoot/ -n userRoot

Lots of encouraging looking output, but the server is now completely empty - 
the root DSE is gone.

Looking at serverc, we see the userRoot directory has been ignored and we now 
have a totally different directory structure:

[root@joey ~]# ls -al /var/lib/dirsrv/slapd-joey/db/
total 260252
drwxrwx---. 3 nobody nobody  4096 May  5 13:43 .
drwxrwx---. 5 nobody nobody  4096 May  5 13:30 ..
-rw---. 1 nobody nobody49 May  5 13:43 DBVERSION
-rw---. 1 nobody nobody 24576 May  5 13:43 __db.001
-rw---. 1 nobody nobody   1736704 May  5 13:44 __db.002
-rw---. 1 nobody nobody  10002432 May  5 13:44 __db.003
-rw---. 1 nobody nobody   1081344 May  5 13:44 __db.004
-rw---. 1 nobody nobody   8134656 May  5 13:44 __db.005
-rw---. 1 nobody nobody 90112 May  5 13:44 __db.006
-rw---. 1 nobody nobody 16384 May  5 13:41 aci.db4
-rw---. 1 nobody nobody   2482176 May  5 13:41 ancestorid.db4
-rw---. 1 nobody nobody 16384 May  5 13:41 associatedDomain.db4
-rw---. 1 nobody nobody 16384 May  5 13:41 certificateUUID.db4
-rw---. 1 nobody nobody  24117248 May  5 13:41 cn.db4
-rw---. 1 nobody nobody 16384 May  5 13:41 contractClass.db4
-rw---. 1 nobody nobody 16384 May  5 13:41 
contractCustomerCounterparty.db4
-rw---. 1 nobody nobody 16384 May  5 13:41 
contractRecipientCounterparty.db4
-rw---. 1 nobody nobody 16384 May  5 13:41 
contractVendorCounterparty.db4
-rw---. 1 nobody nobody  22487040 May  5 13:41 entryrdn.db4
-rw---. 1 nobody nobody   5316608 May  5 13:41 givenName.db4
-rw---. 1 nobody nobody 159891456 May  5 13:41 id2entry.db4
-rw---. 1 nobody nobody 16384 May  5 13:41 ipHostNumber.db4
-rw---. 1 nobody nobody  10485760 May  5 13:44 log.01
-rw---. 1 nobody nobody  11468800 May  5 13:41 mail.db4
-rw---. 1 nobody nobody 40960 May  5 13:41 mailAlternateAddress.db4
-rw---. 1 nobody nobody 24576 May  5 13:41 mailHost.db4
-rw---. 1 nobody nobody 16384 May  5 13:41 memberCertificateIssuerDN.db4
-rw---. 1 nobody nobody 16384 May  5 13:41 
memberCertificateSubjectDN.db4
-rw---. 1 nobody nobody 16384 May  5 13:41 nscpEntryDN.db4
-rw---. 1 nobody nobody   6430720 May  5 13:41 nsuniqueid.db4
-rw---. 1 nobody nobody 24576 May  5 13:41 numsubordinates.db4
-rw---. 1 nobody nobody   2473984 May  5 13:41 objectclass.db4
-rw---. 1 nobody nobody 16384 May  5 13:41 owner.db4
-rw---. 1 nobody nobody802816 May  5 13:41 parentid.db4
-rw---. 1 nobody nobody   5308416 May  5 13:41 sn.db4
-rw---. 1 nobody nobody 16384 May  5 13:41 uid.db4
-rw---. 1 nobody nobody   4243456 May  5 13:41 uniquemember.db4

What is the secret to the bak2db? What command line should I use that is 
compatible with the server? How do you convince bak2db to restore into the 
userR

Re: [389-users] Failed to send extended operation: LDAP error -1 (Can't contact LDAP server)

[Graham Leggett]

On 04 May 2014, at 9:35 PM, David Boreham  wrote:

> It should be possible to add an N+1th replica to an N-node deployment. 
> Replication agreements are peer-to-peer, so you just add a new replication 
> agreement from each of the servers you want to feed changes to the N+1th 
> (typically all of them).

What I've learned so far:

- servera has "syntax checking" switched off, and contains data with syntax 
errors. The data is 15 years old.
- serverb has "syntax checking" switched on, but has successfully been able to 
replicate in the past. Now replication is broken with serverb.
- serverc has "syntax checking" switched on, and has never been able to 
replicate. Serverc is brand new.

What appears to be happening is that during the replication process, an LDAP 
operation that is accepted on servera is being rejected by serverc. The 
replication process is brittle, and has not been coded to handle any kind of 
error during the replication process, and so fails abruptly with "ERROR bulk 
import abandoned" and no further explanation. The error that triggered the 
abort is only visible by turning trace logging on.

This abrupt failure of replication is ignored by both servera and serverc, 
which goes into it's normal incremental update state. Because the initial 
initialize has failed, you get the following two messages:

[05/May/2014:11:19:01 +0200] NSMMReplicationPlugin - 
replica_replace_ruv_tombstone: failed to update replication update vector for 
replica o=Foo,c=ZA: LDAP error - 1

[05/May/2014:04:25:31 -0500] NSMMReplicationPlugin - agmt="cn=Agreement 
serverc.example.com" (serverc:636): Replica has a different generation ID than 
the local data.

When you google for the above messages (which is where I started) you get the 
advice "initialize the supplier/consumer/hub", which throws you because 
"initialize the supplier/consumer/hub" was the exact task you were trying to do.

I have still not been able to get serverc to initialize from servera, I will 
continue in the trace logging to see what the next error is. It would appear 
that 389ds replication has become more strict, and older versions of 389ds 
allowed things through that newer versions no longer do. As a result older 
directories are at risk of sudden failure as latent mistakes that weren't fatal 
now are.

Regards,
Graham
--

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

Re: [389-users] Failed to send extended operation: LDAP error -1 (Can't contact LDAP server)

[Graham Leggett]

On 04 May 2014, at 9:35 PM, David Boreham  wrote:

> ottomh I can't think what's up with your servers, but for sure there's 
> something very odd going on (beyond just "not configured correctly" I 
> suspect). The errors where the replica initialization reports that the 
> database index files have been deleted underneath it are particularly wacky.
> 
> Anyway, I'd recommend that you turn up the logging level on the servers. This 
> will hopefully reveal more about what's going wrong. Also look carefully in 
> the log for the _first_ sign of trouble. That will likely be the root cause. 
> I suspect you have a lot of fog of war showing up that's generated by some 
> underlying prime error, that aught to have appeared first in the timeline.
> 
> It should be possible to add an N+1th replica to an N-node deployment. 
> Replication agreements are peer-to-peer, so you just add a new replication 
> agreement from each of the servers you want to feed changes to the N+1th 
> (typically all of them).
> 
> In the log messages, where you were wondering which consumer server is 
> throwing the error, the name of the replication agreement is typically 
> printed. So the server it is trying to talk to is the one that's the target 
> for the replication agreement mentioned.

On the serverc machine, when serverb has been instructed to initialise serverc, 
we see the following with replication debugging enabled:

[04/May/2014:23:03:36 +0200] NSMMReplicationPlugin - conn=1 op=3 Acquired 
consumer connection extension
[04/May/2014:23:03:36 +0200] NSMMReplicationPlugin - conn=1 op=3 
repl="o=Foo,c=za": Begin total protocol
[04/May/2014:23:03:36 +0200] - csngen_adjust_time: gen state before 
5366aac20001:1399237314:0:0
[04/May/2014:23:03:36 +0200] - _csngen_adjust_local_time: gen state before 
5366aac20001:1399237314:0:0
[04/May/2014:23:03:36 +0200] - _csngen_adjust_local_time: gen state after 
5366ab28:1399237416:0:0
[04/May/2014:23:03:36 +0200] - csngen_adjust_time: gen state after 
536708fc0001:1399237416:0:24020
[04/May/2014:23:03:36 +0200] NSMMReplicationPlugin - conn=1 op=3 
repl="o=Foo,c=ZA": Acquired replica
[04/May/2014:23:03:36 +0200] NSMMReplicationPlugin - 
multimaster_be_state_change: replica o=Foo,c=za is going offline; disabling 
replication
[04/May/2014:23:03:36 +0200] NSMMReplicationPlugin - conn=0 op=0 
repl="o=Foo,c=ZA": Replica in use locking_purl=conn=1 id=3
[04/May/2014:23:03:36 +0200] NSMMReplicationPlugin - 
replica_disable_replication: replica o=Foo,c=za is acquired
[04/May/2014:23:03:36 +0200] - WARNING: Import is running with 
nsslapd-db-private-import-mem on; No other process is allowed to access the 
database
[04/May/2014:23:03:36 +0200] NSMMReplicationPlugin - conn=1 op=3 
repl="o=Foo,c=za": StartNSDS90ReplicationRequest: response=0 rc=0
[04/May/2014:23:03:36 +0200] NSMMReplicationPlugin - conn=1 op=3 Relinquishing 
consumer connection extension

Nothing in the above seems to indicate an error that I can see, but we now see 
this two seconds later:

[04/May/2014:23:03:38 +0200] - ERROR bulk import abandoned
[04/May/2014:23:03:38 +0200] - import userRoot: Aborting all Import threads...
[04/May/2014:23:03:43 +0200] - import userRoot: Import threads aborted.
[04/May/2014:23:03:43 +0200] - import userRoot: Closing files...
[04/May/2014:23:03:43 +0200] - libdb: userRoot/uid.db4: unable to flush: No 
such file or directory
[04/May/2014:23:03:43 +0200] - libdb: userRoot/mailAlternateAddress.db4: unable 
to flush: No such file or directory
[04/May/2014:23:03:43 +0200] - libdb: userRoot/cn.db4: unable to flush: No such 
file or directory
[04/May/2014:23:03:43 +0200] - libdb: userRoot/mail.db4: unable to flush: No 
such file or directory
[04/May/2014:23:03:43 +0200] - libdb: userRoot/givenName.db4: unable to flush: 
No such file or directory
[04/May/2014:23:03:43 +0200] - libdb: userRoot/aci.db4: unable to flush: No 
such file or directory
[04/May/2014:23:03:43 +0200] - libdb: userRoot/entryrdn.db4: unable to flush: 
No such file or directory
[04/May/2014:23:03:43 +0200] - libdb: userRoot/id2entry.db4: unable to flush: 
No such file or directory
[04/May/2014:23:03:43 +0200] - libdb: userRoot/sn.db4: unable to flush: No such 
file or directory
[04/May/2014:23:03:43 +0200] - libdb: userRoot/parentid.db4: unable to flush: 
No such file or directory
[04/May/2014:23:03:43 +0200] - libdb: userRoot/objectclass.db4: unable to 
flush: No such file or directory
[04/May/2014:23:03:43 +0200] - libdb: userRoot/nsuniqueid.db4: unable to flush: 
No such file or directory
[04/May/2014:23:03:43 +0200] - libdb: userRoot/mailHost.db4: unable to flush: 
No such file or directory
[04/May/2014:23:03:43 +0200] - libdb: userRoot/uniquemember.db4: unable to 
flush: No such file or directory
[04/May/2014:23:03:43 +0200] - import userRoot: Import failed.
[04/May/2014:23:03:43 +0200] NSMMReplicationPlugin - Aborting total update in 
progress for replicated area o=Foo,c=ZA connid=1
[04/May/2014:23:03:43 +0200] - process_bulk_import

Re: [389-users] Failed to send extended operation: LDAP error -1 (Can't contact LDAP server)

[Graham Leggett]

On 04 May 2014, at 9:04 PM, Graham Leggett  wrote:

> serverc insists the following over and over and over:
> 
> [04/May/2014:22:00:54 +0200] NSMMReplicationPlugin - 
> replica_replace_ruv_tombstone: failed to update replication update vector for 
> replica o=Foo,c=ZA: LDAP error - 1

Looking in the source, we find this message thrown as follows:

slapi_pblock_get(pb, SLAPI_PLUGIN_INTOP_RESULT, &rc);

if (rc != LDAP_SUCCESS)
{
if ((rc != LDAP_NO_SUCH_OBJECT && rc != LDAP_TYPE_OR_VALUE_EXISTS) || 
!replica_is_state_flag_set(r, REPLICA_IN_USE))
{
slapi_log_error(SLAPI_LOG_FATAL, repl_plugin_name, 
"replica_replace_ruv_tombstone: "
"failed to update replication update vector for replica %s: 
LDAP "
"error - %d\n", (char*)slapi_sdn_get_dn (r->repl_root), rc);
}
}

LDAP error "1" is LDAP_OPERATIONS_ERROR, which seems to be the ldap equivalent 
of "an error has occurred". There seems to be some kind of mechanism where a 
reason string is made available by the underlying code, but this is ignored by 
the above code, and the real reason for the error is lost.

Regards,
Graham
--

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

Re: [389-users] Failed to send extended operation: LDAP error -1 (Can't contact LDAP server)

[Graham Leggett]

On 04 May 2014, at 8:45 PM, Dustin Rice  wrote:

> Well, I wouldn't reccomend manually importing ldifs from one server to 
> another. So, you have servera (single master) -> serverb (consumer) and you 
> want to add serverc in as a multimaster correct?

Not correct, no. servera and serverb are both masters in a successful 
multimaster configuration. I want to add serverc. This is impossible to achieve.

> The way I would do that is make serverc a consumer off servera first and 
> initialize it servera to get your data over.

I've been trying that over and over, it doesn't work.

servera insists the following over and over and over:

[04/May/2014:20:00:27 +0100] NSMMReplicationPlugin - agmt="cn=Agreement 
serverc.example.com" (serverc:636): Replica has a different generation ID than 
the local data.

serverc insists the following over and over and over:

[04/May/2014:22:00:54 +0200] NSMMReplicationPlugin - 
replica_replace_ruv_tombstone: failed to update replication update vector for 
replica o=Foo,c=ZA: LDAP error - 1

Bizarrely is *does* work in the other direction. The newly installed empty 
serverc LDAP server will happily initialise the servera LDAP server, triggering 
all the data to be blown away and forcing a restore from backup. For obvious 
reasons this is of no help to me. :(

Regards,
Graham
--

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

Re: [389-users] Failed to send extended operation: LDAP error -1 (Can't contact LDAP server)

[Graham Leggett]

On 04 May 2014, at 7:57 PM, Dustin Rice  wrote:

> Oh sure, just the way it was worded I wasn't sure if you were seeing 
> successful SSL connections or just "lots of SSL traffic", which can still be 
> handshake failures. 
> 
> Can you successfully perform ldapsearches from serverb to serverc over 636?

Yes.

Weirdly, serverc returns a referral to serverb and servera, which is unexpected:

/usr/bin/ldapsearch -x -H ldaps://serverc.example.com:636 -D "cn=Directory 
Manager" -W -b "o=Foo,c=ZA" "(objectclass=*)"
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 10 Referral
matchedDN: o=Foo,c=za
ref: ldap://serverb.example.com:389/o%3DFoo%2Cc%3Dza
ref: ldap://servera.example.com:389/o%3DFoo%2Cc%3Dza

# numResponses: 1

serverc contains a manually imported copy of the ldif from servera.

Regards,
Graham
--

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

Re: [389-users] Failed to send extended operation: LDAP error -1 (Can't contact LDAP server)

[Graham Leggett]

On 04 May 2014, at 7:26 PM, Dustin Rice  wrote:

> My guess would be it's failing to validate the SSL certificate. Are you using 
> a self-signed cert? If so, you'll need to import that CA cert across all of 
> your servers.

As I said below, ssldump reveals that the servers are talking successfully to 
one another, revealing a completely successful SSL handshake. Self signed certs 
are not being used:

> At the same time, ssldump reveals that serverb.example.com and 
> serverc.example.com are successfully speaking to one another, and have a lot 
> to say - data seems to be constantly flowing between them, but not to any 
> successful end.

Regards,
Graham
--

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

[389-users] Failed to send extended operation: LDAP error -1 (Can't contact LDAP server)

[Graham Leggett]

Hi all,

Some more digging reveals that when an attempt is made for serverb to try and 
commence replication with serverc, I get the following in the error log:

[04/May/2014:17:46:55 +0100] NSMMReplicationPlugin - Beginning total update of 
replica "agmt="cn=Agreement serverc.example.com" (serverc:636)".
[04/May/2014:17:47:02 +0100] NSMMReplicationPlugin - agmt="cn=Agreement 
serverc.example.com" (serverc:636): Failed to send extended operation: LDAP 
error -1 (Can't contact LDAP server)
[04/May/2014:17:47:02 +0100] NSMMReplicationPlugin - agmt="cn=Agreement 
serverc.example.com" (serverc:636): Received error -1 (Can't contact LDAP 
server):  for total update operation
[04/May/2014:17:47:03 +0100] NSMMReplicationPlugin - agmt="cn=Agreement 
serverc.example.com" (serverc:636): Warning: unable to send endReplication 
extended operation (Can't contact LDAP server)
[04/May/2014:17:47:04 +0100] NSMMReplicationPlugin - agmt="cn=Agreement 
serverc.example.com" (serverc:636): Replication bind with SIMPLE auth resumed

Unfortunately the error message "Failed to send extended operation: LDAP error 
-1 (Can't contact LDAP server)" is too vague to be useful because there is no 
clear and unambiguous indication of *which* server it is unable to connect to 
and on what port. The "(serverc:636)" would imply that it is trying to connect 
to "serverc", but "serverc" is the name of the instance, it is not the name of 
the server, so any attempt to connect to this will fail. The server is called 
serverc.example.com, and this name appears exclusively in the replication 
agreement:

dn: cn=Agreement serverc.example.com,cn=replica,cn=o\3DFoo\,c\3Dza,cn=mapping tr
 ee,cn=config
objectClass: nsDS5ReplicationAgreement
objectClass: top
cn: Agreement serverc.example.com
description: Replication agreement between serverb.example.com and 
serverc.example.com
nsds5BeginReplicaRefresh: start
nsDS5ReplicaBindDN: cn=Replication Manager,cn=config
nsDS5ReplicaBindMethod: SIMPLE
nsds5replicaChangesSentSinceStartup: 
nsDS5ReplicaCredentials:: xxx
nsDS5ReplicaHost: serverc.example.com
nsds5replicaLastInitEnd: 0
nsds5replicaLastInitStart: 20140504164654Z
nsds5replicaLastInitStatus: 0
nsds5replicaLastUpdateEnd: 20140504164652Z
nsds5replicaLastUpdateStart: 20140504164652Z
nsds5replicaLastUpdateStatus: 0 Replica acquired successfully: Incremental u
 pdate started
nsDS5ReplicaPort: 636
nsDS5ReplicaRoot: o=Foo,c=ZA
nsDS5ReplicaTransportInfo: SSL
nsds5replicaUpdateInProgress: FALSE

At the same time, ssldump reveals that serverb.example.com and 
serverc.example.com are successfully speaking to one another, and have a lot to 
say - data seems to be constantly flowing between them, but not to any 
successful end.

Does any of this behaviour look familiar to anybody?

Regards,
Graham
--

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

Re: [389-users] Replication hell - picking apart info/warning/error messages

[Graham Leggett]

On 04 May 2014, at 3:16 PM, Graham Leggett  wrote:

> - "Replica has a different generation ID than the local data." - what does 
> this mean? Is it simply information to be ignored, a warning to be heeded (if 
> so, how?), or an error (if so, what action must be taken?).

Picking apart the source code, I find the following code implementing the above 
message, the code would suggest the message is an error, and that the error is 
"fatal":

  case EXAMINE_RUV_GENERATION_MISMATCH:
  slapi_log_error(SLAPI_LOG_FATAL, repl_plugin_name,
  "%s: Replica has a different generation ID than the local 
data.\n",
  agmt_get_long_name(prp->agmt));
  next_state = STATE_BACKOFF_START;
  break;

Does anyone know what a "generation ID" is in the context of two replicas, what 
it means, what it does? Is the admin in any way involved in the choosing of 
this "generation ID"?

Why would this "generation ID" be significant when nsds5BeginReplicaRefresh has 
been set to "start" and the expectation is that server C will be blown away 
anyway?

Regards,
Graham
--

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

Re: [389-users] Replication hell - picking apart info/warning/error messages

[Graham Leggett]

On 04 May 2014, at 4:00 PM, Justin Edmands  wrote:

> What versions of all packages are your ABC running?

servera:

389-ds-base-1.2.11.28-1.el5
389-ds-base-libs-1.2.11.28-1.el5
389-ds-base-debuginfo-1.2.11.28-1.el5

serverb:

389-ds-base-libs-1.2.11.15-32.el6_5.x86_64
389-ds-base-1.2.11.15-32.el6_5.x86_64

serverc:

389-ds-base-1.2.11.15-32.el6_5.x86_64
389-ds-base-libs-1.2.11.15-32.el6_5.x86_64

> Has this all worked in the past? If so, any changes to structure?

Yes, no.

> Have you been able to initialize consumers from C (and have data appear)?

Don't understand the question. I want to take the data that is on A, and make 
it appear on C. Ultimately, both A and C want to be multimaster replicated.

> Random thought about C...what happens if you ;
> - initialize C from B or A (blowing away and rebuilding all data on C)

Been trying to do that for two days, I get the info/warning/error messages I 
posted originally.

> - allow C to complete
> - setup a new host as D
> - initialize D from C
> - after above completes, initialize C from D

I don't follow, I cannot get server C to replicate with A, how will adding a 
4th server help?

> Are you attempting to restore the data from backup to C and then run throw C 
> back into the replication loop? The error below make me think that you are 
> leaving your replication agreements intact while you attempt to restore to C. 
> This would potentially make A or B attempt to sync updates to C while C is 
> restoring from backup. 

No. C is empty, I am trying to get C populated by replicating from A.

> "WARNING: Import is running with nsslapd-db-private-import-mem on; No other 
> process is allowed to access the database"
> 
> Are you deleting all replication agreements from A B and C before starting to 
> work with A --> C again?

No, and I'm terrified of breaking replication with B by fiddling.

Are you able to shed any light on the three questions I asked below?

>> I have a number of questions:
>> 
>> - "Replica has a different generation ID than the local data." - what does 
>> this mean? Is it simply information to be ignored, a warning to be heeded 
>> (if so, how?), or an error (if so, what action must be taken?).
>> 
>> - "ERROR bulk import abandoned". I am assuming this means that the 
>> replication failed, but it gives no indication as to *why* it failed. Anyone 
>> know of a way to coax a reason out of 389ds?
>> 
>> - "NSMMReplicationPlugin - replica_replace_ruv_tombstone: failed to update 
>> replication update vector for replica". Again, is this purely for 
>> information, is this a warning, is this an error, what should I do in 
>> response to this?

Regards,
Graham
--

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

[389-users] Replication hell - picking apart info/warning/error messages

[Graham Leggett]

Hi all,

I am into my second day of hell trying to get server C to replicate to servers 
B and A in a multimaster replication setup.

For reasons unknown it appears getting servers A and B to be blown away 
completely by the contents of (initially empty) server C is trivial in the 
extreme, cue two three hour outages and restores from backup. I cannot for the 
life of me get this to work the other way around.

After running the scripts to deploy server C from scratch, and adding the 
replication agreement to server A, I get the following in server C's log below.

I have a number of questions:

- "Replica has a different generation ID than the local data." - what does this 
mean? Is it simply information to be ignored, a warning to be heeded (if so, 
how?), or an error (if so, what action must be taken?).

- "ERROR bulk import abandoned". I am assuming this means that the replication 
failed, but it gives no indication as to *why* it failed. Anyone know of a way 
to coax a reason out of 389ds?

- "NSMMReplicationPlugin - replica_replace_ruv_tombstone: failed to update 
replication update vector for replica". Again, is this purely for information, 
is this a warning, is this an error, what should I do in response to this?

All I want to do is make serverc have the same data as servera. Does anyone 
have a clear and concise set of instructions for how this is to be achieved 
safely?

[04/May/2014:15:50:17 +0200] NSMMReplicationPlugin - agmt="cn=Agreement 
servera.example.com" (servera:636): Replica has a different generation ID than 
the local data.
[04/May/2014:15:50:21 +0200] NSMMReplicationPlugin - agmt="cn=Agreement 
serverb.example.com" (serverb:636): Replica has a different generation ID than 
the local data.
[04/May/2014:15:51:36 +0200] NSMMReplicationPlugin - 
multimaster_be_state_change: replica o=Foo,c=za is going offline; disabling 
replication
[04/May/2014:15:51:36 +0200] - WARNING: Import is running with 
nsslapd-db-private-import-mem on; No other process is allowed to access the 
database
[04/May/2014:15:51:40 +0200] - ERROR bulk import abandoned
[04/May/2014:15:51:40 +0200] - import userRoot: Aborting all Import threads...
[04/May/2014:15:51:45 +0200] - import userRoot: Import threads aborted.
[04/May/2014:15:51:45 +0200] - import userRoot: Closing files...
[04/May/2014:15:51:45 +0200] - libdb: userRoot/aci.db4: unable to flush: No 
such file or directory
[04/May/2014:15:51:45 +0200] - libdb: userRoot/cn.db4: unable to flush: No such 
file or directory
[04/May/2014:15:51:45 +0200] - libdb: userRoot/parentid.db4: unable to flush: 
No such file or directory
[04/May/2014:15:51:45 +0200] - libdb: userRoot/mailAlternateAddress.db4: unable 
to flush: No such file or directory
[04/May/2014:15:51:45 +0200] - libdb: userRoot/objectclass.db4: unable to 
flush: No such file or directory
[04/May/2014:15:51:45 +0200] - libdb: userRoot/entryrdn.db4: unable to flush: 
No such file or directory
[04/May/2014:15:51:45 +0200] - libdb: userRoot/givenName.db4: unable to flush: 
No such file or directory
[04/May/2014:15:51:45 +0200] - libdb: userRoot/uniquemember.db4: unable to 
flush: No such file or directory
[04/May/2014:15:51:45 +0200] - libdb: userRoot/nsuniqueid.db4: unable to flush: 
No such file or directory
[04/May/2014:15:51:45 +0200] - libdb: userRoot/mailHost.db4: unable to flush: 
No such file or directory
[04/May/2014:15:51:45 +0200] - libdb: userRoot/mail.db4: unable to flush: No 
such file or directory
[04/May/2014:15:51:45 +0200] - libdb: userRoot/id2entry.db4: unable to flush: 
No such file or directory
[04/May/2014:15:51:45 +0200] - libdb: userRoot/sn.db4: unable to flush: No such 
file or directory
[04/May/2014:15:51:45 +0200] - libdb: userRoot/uid.db4: unable to flush: No 
such file or directory
[04/May/2014:15:51:45 +0200] - import userRoot: Import failed.
[04/May/2014:15:51:45 +0200] - process_bulk_import_op: NULL target sdn
[04/May/2014:15:51:49 +0200] NSMMReplicationPlugin - 
replica_replace_ruv_tombstone: failed to update replication update vector for 
replica o=Foo,c=ZA: LDAP error - 1
[04/May/2014:15:51:53 +0200] NSMMReplicationPlugin - 
replica_replace_ruv_tombstone: failed to update replication update vector for 
replica o=Foo,c=ZA: LDAP error - 1
[04/May/2014:15:51:57 +0200] NSMMReplicationPlugin - 
replica_replace_ruv_tombstone: failed to update replication update vector for 
replica o=Foo,c=ZA: LDAP error - 1

Regards,
Graham
--

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

Re: [389-users] Indexes and "not" filters

[Graham Leggett]

On 25 May 2013, at 10:27 PM, Graham Leggett  wrote:

> It just gets weirder and weirder.
> 
> We start with no index on the associatedDomain attribute:
> 
> [root@monica slapd-monica]# ls -al 
> /var/lib/dirsrv/slapd-monica/db/userRoot/associatedDomain.db4
> ls: cannot access 
> /var/lib/dirsrv/slapd-monica/db/userRoot/associatedDomain.db4: No such file 
> or directory
> 
> I ask 389ds to create the index on associatedDomain:
> 
> [root@monica slapd-monica]# ./db2index.pl -D "cn=Directory Manager" -w - -n 
> userRoot -t associatedDomain
> Bind Password: 
> adding new entry "cn=db2index_2013_5_25_21_21_43, cn=index, cn=tasks, 
> cn=config"
> 
> I watch the log file, 389ds goes through the motions of creating an index on 
> associatedDomain:
> 
> [25/May/2013:21:21:42 +0100] - userRoot: Indexing attribute: associatedDomain
> [snip]
> [25/May/2013:21:22:11 +0100] - userRoot: Finished indexing.
> 
> We end with no index on the associatedDomain attribute, no error message, no 
> nothing:

Got to the bottom of this.

Should the two master servers not agree on the schema, most specifically schema 
elements on server A are missing from server B, the index generation process 
will fail silently, and return a message saying "Finished indexing" above.

This fools the admin into thinking the attribute has been successfully indexed 
when no indexing took place.

Hopefully this will help someone else.

Regards,
Graham
--



smime.p7s
Description: S/MIME cryptographic signature
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Indexes and "not" filters

[Graham Leggett]

On 25 May 2013, at 10:00 PM, Graham Leggett  wrote:

> I have indexed the associatedDomain attribute as follows:
> 
> dn: cn=associatedDomain,cn=default indexes,cn=config,cn=ldbm database,cn=plu
> gins,cn=config
> objectClass: nsIndex
> objectClass: top
> cn: associatedDomain
> nsSystemIndex: false
> nsIndexType: eq

It just gets weirder and weirder.

We start with no index on the associatedDomain attribute:

[root@monica slapd-monica]# ls -al 
/var/lib/dirsrv/slapd-monica/db/userRoot/associatedDomain.db4
ls: cannot access 
/var/lib/dirsrv/slapd-monica/db/userRoot/associatedDomain.db4: No such file or 
directory

I ask 389ds to create the index on associatedDomain:

[root@monica slapd-monica]# ./db2index.pl -D "cn=Directory Manager" -w - -n 
userRoot -t associatedDomain
Bind Password: 
adding new entry "cn=db2index_2013_5_25_21_21_43, cn=index, cn=tasks, cn=config"

I watch the log file, 389ds goes through the motions of creating an index on 
associatedDomain:

[25/May/2013:21:21:42 +0100] - userRoot: Indexing attribute: associatedDomain
[snip]
[25/May/2013:21:22:11 +0100] - userRoot: Finished indexing.

We end with no index on the associatedDomain attribute, no error message, no 
nothing:

[root@monica slapd-monica]# ls -al 
/var/lib/dirsrv/slapd-monica/db/userRoot/associatedDomain.db4
ls: cannot access 
/var/lib/dirsrv/slapd-monica/db/userRoot/associatedDomain.db4: No such file or 
directory

This is RHEL6 with 389-ds-base-1.2.11.15-14.el6_4.x86_64.

I am completely stuck, has anybody experienced weirdness like this before? Am I 
doing the right thing to create the index? Is there some way of coaxing an 
error of any kind out of 389ds?

Regards,
Graham
--



smime.p7s
Description: S/MIME cryptographic signature
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Indexes and "not" filters

[Graham Leggett]

Hi all,

I am still really struggling with something that should be a simple query, but 
isn't. I have a filter that returns just one single result, as follows:

[25/May/2013:20:54:16 +0100] conn=82 op=10 SRCH base="o=Foo,c=GB" scope=2 
filter="(&(associatedDomain=example.com)(!(associatedDomain=host.example.com)))"
 attrs="associatedDomain"
[25/May/2013:20:54:17 +0100] conn=82 op=10 RESULT err=4 tag=101 nentries=1 
etime=1 notes=U

This query however returns the following error:

Search error 4: Size limit exceeded 

The "notes=U" in the log gives an excessively cryptic clue - the query wasn't 
indexed, and the error message seems to be misleading, as it doesn't seem to be 
the size limit that is exceeded, but rather the time limit.

I have indexed the associatedDomain attribute as follows:

dn: cn=associatedDomain,cn=default indexes,cn=config,cn=ldbm database,cn=plu
 gins,cn=config
objectClass: nsIndex
objectClass: top
cn: associatedDomain
nsSystemIndex: false
nsIndexType: eq

Am I correct in understanding that a "eq" index is not enough to handle the 
"not" part of the filter above?

What do you have to do to index a "not" filter?

Regards,
Graham
--




smime.p7s
Description: S/MIME cryptographic signature
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] db2index.pl: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

[Graham Leggett]

Hi all,

Just to recount an experience in the hope that it saves someone else some 
trouble.

I was trying to use the ./db2index.pl script to regenerate my indexes, and the 
script point blank refused to work, telling me:

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

To debug this, hack the db2index.pl script to pass the "-d 1" parameter to 
ldapsearch, which tells ldapsearch to give debug messages instead of the 
cryptic failure message.

In my case it revealed that db2index.pl was trying to contact the externally 
accessible public IP of the box on port 389, instead of localhost as it should 
have in my case. To fix the problem I had to manually hack the script.

Ideally this script shouldn't make blind assumptions as to the name of the LDAP 
server, but leave it up to the caller.

Regards,
Graham
--



smime.p7s
Description: S/MIME cryptographic signature
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Importing certificates during setup-ds.pl - is this possible?

[Graham Leggett]

On 24 Dec 2012, at 12:52 PM, Vlad  wrote:

> I don't see the problem. Simply install DS without SSL and then:
> 1. use ldapmodify to import SSL settings (see the example below)
> 2. use pk12util tiu import certificate
> 3. use certutil to change trusts
> All the things above could be done completely unattended…

The problem is that the above shouldn't be necessary, because setup-ds.pl has 
the INF file and ConfigFile options to provide the config in one go. This 
ConfigFile mechanism is rendered useless, because there is no ability to 
configure the certificate database in advance.

Regards,
Graham
--



smime.p7s
Description: S/MIME cryptographic signature
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Bind localhost to 389, external IP to 636, fails with Local Network address is in use

[Graham Leggett]

Hi all,

After updating the directory as follows in order to make 389ds listen to 
localhost:389 and external.ip.address:636 (with SSL), the server refuses to 
start complaining as follows:

[22/Dec/2012:09:32:26 +] createprlistensockets - PR_Bind() on 172.20.10.6 
port 636 failed: Netscape Portable Runtime error -5982 (Local Network address 
is in use.)

I have checked, nothing is listening to port 636 before the server restart, so 
the most likely explanation is that 389ds is trying to bind to port 636 twice, 
and failing on the second go.

# set the IP address for unencrypted access
dn: cn=config
changetype: modify
replace: nsslapd-listenhost
nsslapd-listenhost: 127.0.0.1

# set the IP address for encrypted access
dn: cn=config
changetype: modify
replace: nsslapd-securelistenhost
nsslapd-securelistenhost: 172.20.10.6

Can anyone point out what I am doing wrong above?

Regards,
Graham
--



smime.p7s
Description: S/MIME cryptographic signature
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Importing certificates during setup-ds.pl - is this possible?

[Graham Leggett]

On 24 Dec 2012, at 09:18, Vlad  wrote:

> Obviously the setup-ds.pl script can be modified to import certificate, but 
> I'd prefer installing server without SSL firstly and then use additional 
> script to install certificate(s) and enable SSL for server/admin unattended.
> Let me know if you need any examples. 

This is a real pity.

The ConfigFile option is a clean and simple way to load ldif without messing 
about with trying to script an ldapmodify, which in turn means trying to script 
a secure way to pass the credentials.

It didn't make any sense that you could preconfigure the directory but not 
preconfigure the certs, which has to be done before you can preconfigure the 
ssl directory config. The error you get when trying to add the 
cn=RSA,cn=encryption,cn=config object when the corresponding cert doesn't exist 
is "No such object", which implies that cn=encryption,cn=config does not exist, 
which obviously it does.

Regards,
Graham
--

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

[389-users] Bind localhost to 389, external IP to 636, fails with Local Network address is in use

[Graham Leggett]

Hi all,

After updating the directory as follows in order to make 389ds listen to 
localhost:389 and external.ip.address:636 (with SSL), the server refuses to 
start complaining as follows:

[22/Dec/2012:09:32:26 +] createprlistensockets - PR_Bind() on 172.20.10.6 
port 636 failed: Netscape Portable Runtime error -5982 (Local Network address 
is in use.)

I have checked, nothing is listening to port 636 before the server restart, so 
the most likely explanation is that 389ds is trying to bind to port 636 twice, 
and failing on the second go.

# set the IP address for unencrypted access
dn: cn=config
changetype: modify
replace: nsslapd-listenhost
nsslapd-listenhost: 127.0.0.1

# set the IP address for encrypted access
dn: cn=config
changetype: modify
replace: nsslapd-securelistenhost
nsslapd-securelistenhost: 172.20.10.6

Can anyone point out what I am doing wrong above?

Regards,
Graham
--



smime.p7s
Description: S/MIME cryptographic signature
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Importing certificates during setup-ds.pl - is this possible?

[Graham Leggett]

Hi all,

I am currently trying to script the setup of a directory using the ConfigFile 
entry within an INF file, and so far I've hit a snag.

In order to enable SSL on the directory, first I must use certutil to import 
the certificate to be used, otherwise the attempt to add the 
cn=RSA,cn=encryption,cn=config entry fails saying "No such object". If I set up 
the directory, then manually add the certificates, then manually enable SSL by 
adding the cn=RSA,cn=encryption,cn=config entry (and various other SSL related 
configs), it seems to work fine.

Is there some way of getting setup-ds.pl to import a given certificate (p12 
file, whatever) when the server is set up, in addition to creating the initial 
certificate database within /etc/dirsrv/slapd-INSTANCE/?

Regards,
Graham
--



smime.p7s
Description: S/MIME cryptographic signature
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] LDAP URL extension to support the server side sort control?

[Graham Leggett]

Hi all,

I am currently trying to find out whether there is a standard way of adding the 
server side sort control described in RFC2891 to an LDAP URL.

LDAP URLs are described as having an "extensions" section, but I'm struggling 
to work out what the extensions should be that would add the sort control to a 
search URL. If a syntax already exists for this, I'm keen to use it rather than 
inventing my own.

Or to state it another way:

ldap://host.com:/o=University%20of%20Michigan,
c=US??sub?(cn=Babs%20Jensen)?[what-goes-here-to-support-sorting]

Is anyone able to confirm?

Regards,
Graham
--



smime.p7s
Description: S/MIME cryptographic signature
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Adding an index: how is this achieved?

[Graham Leggett]

Hi all,

I'm trying to add an index, and am currently epically failing at doing so.

The only documentation I can find is the obsolete Redhat Directory Server guide 
at 
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/applying-indexes.html,
 linked to from the 389-ds documentation website.

The docs recommend I use the db2index.pl script, which doesn't work for me:

/usr/lib64/dirsrv/slapd-myinstance/db2index.pl -D "cn=Directory Manager" -w 
`cat /etc/ldap.secret` -n myinstance -t myattribute
adding new entry cn=db2index_2011_12_28_14_49_34, cn=index, cn=tasks, cn=config
ldap_add: No such object

A look at the error log reveals this error:

[28/Dec/2011:14:50:35 -0600] - can't import to nonexistent backend myinstance

I am completely stumped. If my backend isn't called "myinstance" then I have no 
idea what it's referring to. Given there is only one instance on the server, I 
have no idea why 389ds can't figure this out for itself. In fact, I can't 
understand why 389ds didn't just handle indexes all on its own anyway.

The docs suggest doing this:

cd /etc/dirsrv/slapd-instance_name
db2index.pl-D "cn=Directory Manager" -w secret -n ExampleServer -t sn

No idea where "ExampleServer" comes from, and no idea why it's not the same as 
"instance_name".

I also find a shell script called db2index, as well as the perl script called 
db2index.pl. Any idea why there are two scripts that in theory do the same 
thing?

Is there an up to date recipe somewhere that explains how to add an index to 
389ds?

Regards,
Graham
--



smime.p7s
Description: S/MIME cryptographic signature
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users