Re: Problems with log entries order
by Dario Zanzico
On Mon, Jan 25, 2016, at 03:16 PM, Леонид Юрьев wrote:
> In general it is impossible, but only if build slapd without
> multithreading.
You mean an instance built with --without-threads?
> On the other hand, you can try ReOpenLDAP fork - it adds thread-id
> prefix for each log-record.
> Therefore is possible to filter/split syslog per thread-id, e.g. get
> an ordered log for the each slapd-thread.
I'll keep this in mind,
thanks again
> Leonid.
dario
7 years, 8 months
problems with acl
by BÖSCH Christian
Hi,
I want to hide an attribute to members of a group by each other but
allowing these members to see this attribute of all other users.
So I use this ACLs:
olcAccess: {0}to filter=(memberof=cn=group,ou=special,o=abc.net)
attrs=PrivateAttr by group.exact="cn=group,ou=special,o=abc.net" none
by * break
olcAccess: {1}to attrs=PrivateAttr
by group.exact="cn=group,ou=special,o=abc.net" ssf=128 read
olcAccess: {2}to attrs=userPassword by self write by anonymous auth by * none
olcAccess: {3}to * by * read
uid=user1,ou=people,o=abc.net <http://abc.net/> and uid=user2,ou=people,o=abc.net <http://abc.net/> are both members
of cn=group,ou=special,o=abc.net <http://abc.net/> and the memberOf overlay seems to work also the filter
in acl#0:
dn: uid=user1,ou=people,o=abc.net
memberOf: cn=group,ou=special,o=abc.net
dn: uid=user2,ou=people,o=abc.net
memberOf: cn=group,ou=special,o=abc.net
but if user2 searches for PrivateAttr of user1 it gets the attribute.
can anyone give me a hint what’s wrong?
many thanks,
christian
here the log:
Jan 25 09:16:56 openldap1 slapd[58851]: => mdb_entry_get: found entry: "uid=user2,ou=people,o=abc.net"
Jan 25 09:16:56 openldap1 slapd[58851]: => access_allowed: search access to "o=abc.net" "entry" requested
Jan 25 09:16:56 openldap1 slapd[58851]: => acl_get: [4] attr entry
Jan 25 09:16:56 openldap1 slapd[58851]: => acl_mask: access to entry "o=abc.net", attr "entry" requested
Jan 25 09:16:56 openldap1 slapd[58851]: => acl_mask: to all values by "uid=user2,ou=people,o=abc.net", (=0)
Jan 25 09:16:56 openldap1 slapd[58851]: <= check a_dn_pat: *
Jan 25 09:16:56 openldap1 slapd[58851]: <= acl_mask: [1] applying read(=rscxd) (stop)
Jan 25 09:16:56 openldap1 slapd[58851]: <= acl_mask: [1] mask: read(=rscxd)
Jan 25 09:16:56 openldap1 slapd[58851]: => slap_access_allowed: search access granted by read(=rscxd)
Jan 25 09:16:56 openldap1 slapd[58851]: => access_allowed: search access granted by read(=rscxd)
Jan 25 09:16:56 openldap1 slapd[58851]: => access_allowed: search access to "uid=user1,ou=people,o=abc.net" "uid" requested
Jan 25 09:16:56 openldap1 slapd[58851]: => acl_get: [4] attr uid
Jan 25 09:16:56 openldap1 slapd[58851]: => acl_mask: access to entry "uid=user1,ou=people,o=abc.net", attr "uid" requested
Jan 25 09:16:56 openldap1 slapd[58851]: => acl_mask: to value by "uid=user2,ou=people,o=abc.net", (=0)
Jan 25 09:16:56 openldap1 slapd[58851]: <= check a_dn_pat: *
Jan 25 09:16:56 openldap1 slapd[58851]: <= acl_mask: [1] applying read(=rscxd) (stop)
Jan 25 09:16:56 openldap1 slapd[58851]: <= acl_mask: [1] mask: read(=rscxd)
Jan 25 09:16:56 openldap1 slapd[58851]: => slap_access_allowed: search access granted by read(=rscxd)
Jan 25 09:16:56 openldap1 slapd[58851]: => access_allowed: search access granted by read(=rscxd)
Jan 25 09:16:56 openldap1 slapd[58851]: => access_allowed: read access to "uid=user1,ou=people,o=abc.net" "entry" requested
Jan 25 09:16:56 openldap1 slapd[58851]: => acl_get: [4] attr entry
Jan 25 09:16:56 openldap1 slapd[58851]: => acl_mask: access to entry "uid=user1,ou=people,o=abc.net", attr "entry" requested
Jan 25 09:16:56 openldap1 slapd[58851]: => acl_mask: to all values by "uid=user2,ou=people,o=abc.net", (=0)
Jan 25 09:16:56 openldap1 slapd[58851]: <= check a_dn_pat: *
Jan 25 09:16:56 openldap1 slapd[58851]: <= acl_mask: [1] applying read(=rscxd) (stop)
Jan 25 09:16:56 openldap1 slapd[58851]: <= acl_mask: [1] mask: read(=rscxd)
Jan 25 09:16:56 openldap1 slapd[58851]: => slap_access_allowed: read access granted by read(=rscxd)
Jan 25 09:16:56 openldap1 slapd[58851]: => access_allowed: read access granted by read(=rscxd)
Jan 25 09:16:56 openldap1 slapd[58851]: => access_allowed: result not in cache (PrivateAttr)
Jan 25 09:16:56 openldap1 slapd[58851]: => access_allowed: read access to "uid=user1,ou=people,o=abc.net" "PrivateAttr" requested
Jan 25 09:16:56 openldap1 slapd[58851]: => access_allowed: search access to "uid=user1,ou=people,o=abc.net" "memberOf" requested
Jan 25 09:16:56 openldap1 slapd[58851]: => acl_get: [2] attr PrivateAttr
Jan 25 09:16:56 openldap1 slapd[58851]: => acl_mask: access to entry "uid=user1,ou=people,o=abc.net", attr "PrivateAttr" requested
Jan 25 09:16:56 openldap1 slapd[58851]: => acl_mask: to value by "uid=user2,ou=people,o=abc.net", (=0)
Jan 25 09:16:56 openldap1 slapd[58851]: <= check a_group_pat: cn=group,ou=special,o=abc.net
Jan 25 09:16:56 openldap1 slapd[58851]: => mdb_entry_get: found entry: "cn=group,ou=special,o=abc.net"
Jan 25 09:16:56 openldap1 slapd[58851]: <= check a_authz.sai_ssf: ACL 128 > OP 256
Jan 25 09:16:56 openldap1 slapd[58851]: <= acl_mask: [1] applying read(=rscxd) (stop)
Jan 25 09:16:56 openldap1 slapd[58851]: <= acl_mask: [1] mask: read(=rscxd)
Jan 25 09:16:56 openldap1 slapd[58851]: => slap_access_allowed: read access granted by read(=rscxd)
Jan 25 09:16:56 openldap1 slapd[58851]: => access_allowed: read access granted by read(=rscxd)
Jan 25 09:16:56 openldap1 slapd[58851]: connection_read(35): no connection!
7 years, 8 months
Re: [OpenLDAP][Authentication] SASL
by Timothy Keith
The supported SASL mechanisms are CRAM-MD5 and DIGEST-MD5
[tkeith@kif ~]$ ldapsearch -x -H ldap://localhost -b "" -s base
supportedSASLMechanisms
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: supportedSASLMechanisms
#
#
dn:
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: DIGEST-MD5
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
But this returns : no mechanism available:
ldapwhoami -v -ZZZ -Y EXTERNAL -h localhost
ldap_initialize( ldap://localhost )
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
additional info: SASL(-4): no mechanism available:
Tim
On Fri, Jan 22, 2016 at 11:36 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
> Please keep replies to the list.
>
> --Quanah
>
>
> --On Friday, January 22, 2016 11:26 AM -0600 Timothy Keith
> <timothy.g.keith(a)gmail.com> wrote:
>
>> ldapwhoami -v -ZZ -Y EXTERNAL -h localhost
>> ldap_initialize( ldap://localhost )
>> SASL/EXTERNAL authentication started
>> ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
>> additional info: SASL(-4): no mechanism available:
>>
>>
>> ldapsearch -h localhost -LLL -Y EXTERNAL -b "" -s base +
>> SASL/EXTERNAL authentication started
>> ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
>> additional info: SASL(-4): no mechanism available:
>>
>>
>> Tim
>>
>> On Fri, Jan 22, 2016 at 10:10 AM, Quanah Gibson-Mount <quanah(a)zimbra.com>
>> wrote:
>>>
>>> --On Friday, January 22, 2016 9:38 AM -0600 Timothy Keith
>>> <timothy.g.keith(a)gmail.com> wrote:
>>>
>>>> The first attempt fails :
>>>>
>>>> ldapwhoami -v -ZZ -Y EXTERNAL
>>>> ldap_initialize( <DEFAULT> )
>>>> ldap_start_tls: Connect error (-11)
>>>> additional info: TLS: hostname does not match CN in peer
>>>> certificate
>>>
>>>
>>>
>>> Why do you expect this to work? You failed to supply -H with a valid
>>> ldap:// URI.
>>>
>>>> This also fails :
>>>>
>>>> ldapsearch -LLL -Y EXTERNAL -H ldaps:/// -b "" -s base +
>>>> ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
>>>
>>>
>>>
>>> Why do you expect this to work? You passed -H without providing a host.
>>>
>>> --Quanah
>>>
>>>
>>>>
>>>> Tim
>>>>
>>>>
>>>> On Thu, Jan 21, 2016 at 7:43 PM, Sergio NNX <sfhacker(a)hotmail.com>
>>>> wrote:
>>>>>>
>>>>>>
>>>>>> My scenario is relatively simple.
>>>>>
>>>>>
>>>>> Simple, but it doesn't work, right?
>>>>>
>>>>> Are you after something similar to the output below?
>>>>>
>>>>> ldapwhoami -v -ZZ -Y EXTERNAL
>>>>>
>>>>> SASL/EXTERNAL authentication started
>>>>> SASL username: 2.5.4.13=End User Certificate (OpenLDAP
>>>>> 2.4.43),2.5.4.5=1234-2015
>>>>> -UK,title=Mr,ou=Finance Department,o=MateAR.eu IT
>>>>> Solutions,l=Westminster,st=Lon
>>>>> don,c=GB,email=info(a)matear.eu,0.9.2342.19200300.100.1.1=Administrator,
>>>>> dc =EU,cn=A dministrator
>>>>> SASL SSF: 0
>>>>> dn:description=end user certificate (openldap
>>>>> 2.4.43),serialNumber=1234-2015-uk,
>>>>> title=mr,ou=finance department,o=matear.eu it
>>>>> solutions,l=westminster,st=london,
>>>>> c=gb,email=info(a)matear.eu,uid=administrator,dc=eu,cn=administrator
>>>>> Result: Success (0)
>>>>>
>>>>>
>>>>> ldapsearch -LLL -Y EXTERNAL -H ldaps:/// -b "" -s base +
>>>>>
>>>>> SASL/EXTERNAL authentication started
>>>>> SASL username: 2.5.4.13=End User Certificate (OpenLDAP
>>>>> 2.4.43),2.5.4.5=1234-2015
>>>>> -UK,title=Mr,ou=Finance Department,o=MateAR.eu IT
>>>>> Solutions,l=Westminster,st=Lon
>>>>> don,c=GB,email=info(a)matear.eu,0.9.2342.19200300.100.1.1=Administrator,
>>>>> dc =EU,cn=A dministrator
>>>>>
>>>>>
>>>>> SASL SSF: 0
>>>>> dn:
>>>>> structuralObjectClass: OpenLDAProotDSE
>>>>> configContext: cn=config
>>>>> monitorContext: cn=Monitor
>>>>> namingContexts: dc=my-domain,dc=com
>>>>> supportedControl: 1.3.6.1.4.1.4203.1.9.1.1
>>>>> supportedControl: 2.16.840.1.113730.3.4.18
>>>>> supportedControl: 2.16.840.1.113730.3.4.2
>>>>> supportedControl: 1.3.6.1.4.1.4203.1.10.1
>>>>> supportedControl: 1.3.6.1.1.22
>>>>> supportedControl: 1.2.840.113556.1.4.319
>>>>> supportedControl: 1.2.826.0.1.3344810.2.3
>>>>> supportedControl: 1.3.6.1.1.13.2
>>>>> supportedControl: 1.3.6.1.1.13.1
>>>>> supportedControl: 1.3.6.1.1.12
>>>>> supportedExtension: 1.3.6.1.4.1.1466.20037
>>>>> supportedExtension: 1.3.6.1.4.1.4203.1.11.1
>>>>> supportedExtension: 1.3.6.1.4.1.4203.1.11.3
>>>>> supportedExtension: 1.3.6.1.1.8
>>>>> supportedFeatures: 1.3.6.1.1.14
>>>>> supportedFeatures: 1.3.6.1.4.1.4203.1.5.1
>>>>> supportedFeatures: 1.3.6.1.4.1.4203.1.5.2
>>>>> supportedFeatures: 1.3.6.1.4.1.4203.1.5.3
>>>>> supportedFeatures: 1.3.6.1.4.1.4203.1.5.4
>>>>> supportedFeatures: 1.3.6.1.4.1.4203.1.5.5
>>>>> supportedLDAPVersion: 3
>>>>> supportedSASLMechanisms: SRP
>>>>> supportedSASLMechanisms: SCRAM-SHA-1
>>>>> supportedSASLMechanisms: GSSAPI
>>>>> supportedSASLMechanisms: GSS-SPNEGO
>>>>> supportedSASLMechanisms: DIGEST-MD5
>>>>> supportedSASLMechanisms: EXTERNAL
>>>>> supportedSASLMechanisms: OTP
>>>>> supportedSASLMechanisms: CRAM-MD5
>>>>> supportedSASLMechanisms: NTLM
>>>>> supportedSASLMechanisms: LOGIN
>>>>> supportedSASLMechanisms: PLAIN
>>>>> entryDN:
>>>>> subschemaSubentry: cn=Subschema
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Quanah Gibson-Mount
>>> Platform Architect
>>> Zimbra, Inc.
>>> --------------------
>>> Zimbra :: the leader in open source messaging and collaboration
>
>
>
>
> --
>
> Quanah Gibson-Mount
> Platform Architect
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
7 years, 8 months
LDAP with MySQL Support and Radius
by Alexandre Vilarinho
Hello all
I'm trying to install LDAP wirh mysql support to authenticate users radius account and I'm having problems finding documentation explaining how to do it. Does any implemented an environment link I'm willing to do? It is possible to share this documentation? Is there a step-by-step explaining how to do it?
Regards
Alex
7 years, 8 months
Using LMDB without memory mapped files
by José Felix Torre Santos
Hello.
I am using LMDB in an investigation project. It works perfectly with persistence and concurrent processes. But in some occasions I want to run an standalone process without persistence and as fast as possible. I could do it with other binary-tree libraries written in C, but I’d like not to rewrite mi code.
Is there any way to configure or modify LMDB code to work in main memory instead memory mapped files?
Thanks in advance.
[cid:image9234d9.PNG@cd3fba1a.44af0ea3]<http://www.semantic-systems.com>
José Felix Torre Santos
Responsable de Plataforma Repcon
jts(a)semantic-systems.com
T: +34 94 454 55 50
SOPORTE: +34 902 310 123
www.semantic-systems.com<http://www.semantic-systems.com>
[cid:imaged7b0f2.PNG@4b89a6f6.41bfb648]
________________________________
Este correo electrónico y en su caso cualquier fichero adjunto al mismo contienen información de carácter confidencial exclusivamente dirigida a sus destinatarios. Queda prohibida su divulgación, copia o distribución a terceros sin la previa autorización escrita de SEMANTIC SYSTEMS, S.L. En el caso de haber recibido este correo electrónico por error, rogamos nos notifique inmediatamente esta circunstancia mediante su reenvío a la dirección electrónica del remitente.
Los datos personales que Ud. nos haya facilitado y, especialmente su dirección de correo electrónico, figuran incorporados a un fichero con el fin de gestionar nuestras relaciones y cuya responsabilidad corresponde a SEMANTIC SYSTEMS, S.L., que garantiza el tratamiento de sus datos de carácter personal de conformidad con la Ley Orgánica 15/1999, de Protección de Datos de Carácter Personal. Ud. podrá ejercitar sus derechos de acceso, rectificación, cancelación y oposición ante SEMANTIC SYSTEMS, S.L., en la Avenida del Txoriherri nº 9 2º planta – Derio (48160) Vizcaya
The information contained in and/or attached to this e-mail message is intended solely for the use of the addressees. It is not to be disclosed, copied or distributed to any third party without the prior written permission of SEMANTIC SYSTEMS, S.L. If you have received this email in error, please immediately notify us by forwarding to the sender's email address.
Personal data provided to us and especially your email address, are stored in a file in order to manage our relationships and SEMANTIC SYSTEMS, S.L. is the responsible, ensuring the processing of your personal data in accordance with the Organic Law 15/1999 of 13 December on the Protection of Personal Data. You can exercise your rights of access, rectification, cancellation and opposition to SEMANTIC SYSTEMS, S.L., Avenida del Txoriherri nº 9 2º planta – Derio (48104) Vizcaya
7 years, 8 months
slapd dying with mdb databases
by Angel L. Mateo
Hello,
After changing my databases from hdb to mdb I'm having problems with it.
My problem is that after a few days of slapd running without any
problem (this time it has been more than a week), then it suddenly dies
and whenever I restart it, it dies immediately.
I have run slapd with -d 16000 and last debug message it shows is:
569decb8 <= root access granted
569decb8 => access_allowed: search access granted by manage(=mwrscxd)
../../../../../servers/slapd/back-mdb/../../../libraries/liblmdb/mdb.c:5276:
Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root()
In order to be able to run again, I have to delete the database and
start slapd with no db (so it reloads it completely with syncrepl).
I'm running openldap 2.4.43 (compiled by me) in a ubuntu 14.04 server.
Any help?
--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información
y las Comunicaciones Aplicadas (ATICA)
http://www.um.es/atica
Tfo: 868887590
Fax: 868888337
7 years, 8 months
Output differs when searching via translucent proxy
by M. P.
Hello all,
We have an installation of openldap like this: master <- slave <-
translucent proxy. All the installation is on debian Jessie 8.2 with
slapd version 2.4.40+dfsg-1+deb8u1.
When searching/binding with ldapsearch everything seems ok. I mean I
have the results I expect.
We have an application called CAS to authenticate users on web
appplications and there is where things start to be strange. When
configuring CAS to communicate with the slave, there is no problem,
users can authenticate without issue. But when CAS is configured to
communicate with the translucent proxy, there is not possible for users
to be authenticated.
I looked a different places, changed different parameters playing with
ldap protocol, search reference responses, automatic referral chasing,
... but can't make it work.
In the logs I have this:
ldapsearch request: the output is ok
from client to translucent proxy:
slapd[8845]: conn=1019 fd=13 ACCEPT from IP=10.93.64.180:57730
(IP=0.0.0.0:389)
slapd[8845]: conn=1019 op=0 BIND
dn="uid=cas-auth,ou=SI,ou=access,dc=domain,dc=com" method=128
slapd[8845]: conn=1019 op=0 BIND
dn="uid=cas-auth,ou=SI,ou=access,dc=domain,dc=com" mech=SIMPLE ssf=0
slapd[8845]: conn=1019 op=0 RESULT tag=97 err=0 text=
slapd[8845]: conn=1019 op=1 SRCH base="ou=people,dc=domain,dc=com"
scope=2 deref=3 filter="(uid=myuser)"
slapd[8845]: conn=1019 op=1 SRCH attr=1.1
slapd[8845]: conn=1019 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
slapd[8845]: conn=1019 op=2 UNBIND
slapd[8845]: conn=1019 fd=13 closed
from tranlucent proxy to slave:
slapd[6491]: conn=1759 fd=25 ACCEPT from IP=10.93.64.207:37513
(IP=0.0.0.0:389)
slapd[6491]: conn=1759 op=0 [IP=10.93.64.180
USERNAME=uid=cas-auth,ou=SI,ou=access,dc=domain,dc=com] BIND
dn="uid=cas-auth,ou=SI,ou=access,dc=domain,dc=com" method=128
slapd[6491]: conn=1759 op=0 [IP=10.93.64.180
USERNAME=uid=cas-auth,ou=SI,ou=access,dc=domain,dc=com] BIND
dn="uid=cas-auth,ou=SI,ou=Access,dc=domain,dc=com" mech=SIMPLE ssf=0
slapd[6491]: conn=1759 op=0 [IP=10.93.64.180
USERNAME=uid=cas-auth,ou=SI,ou=access,dc=domain,dc=com] RESULT tag=97
err=0 text=
slapd[6491]: conn=1759 op=1 [IP=10.93.64.180
USERNAME=uid=cas-auth,ou=SI,ou=access,dc=domain,dc=com] SRCH
base="ou=people,dc=domain,dc=com" scope=2 deref=3 filter="(uid=myuser)"
slapd[6491]: conn=1759 op=1 [IP=10.93.64.180
USERNAME=uid=cas-auth,ou=SI,ou=access,dc=domain,dc=com] SRCH attr=* +
slapd[6491]: conn=1759 op=1 [IP=10.93.64.180
USERNAME=uid=cas-auth,ou=SI,ou=access,dc=domain,dc=com] SEARCH RESULT
tag=101 err=0 nentries=1 text=
slapd[6491]: conn=1759 op=2 UNBIND
slapd[6491]: conn=1759 fd=25 closed
CAS request: I don't have the output I expect
from client to translucent proxy:
slapd[8845]: conn=1017 fd=13 ACCEPT from IP=10.93.64.180:57109
(IP=0.0.0.0:389)
slapd[8845]: conn=1017 op=0 BIND
dn="uid=cas-auth,ou=si,ou=access,dc=domain,dc=com" method=128
slapd[8845]: conn=1017 op=0 BIND
dn="uid=cas-auth,ou=si,ou=access,dc=domain,dc=com" mech=SIMPLE ssf=0
slapd[8845]: conn=1017 op=0 RESULT tag=97 err=0 text=
slapd[8845]: conn=1017 op=1 SRCH base="ou=People,dc=domain,dc=com"
scope=2 deref=3 filter="(uid=myuser)"
slapd[8845]: conn=1017 op=1 SRCH attr=1.1
slapd[8845]: conn=1017 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
slapd[8845]: conn=1017 fd=13 closed (connection lost)
from tranlucent proxy to slave:
slapd[6491]: conn=1747 fd=13 ACCEPT from IP=10.93.64.207:35881
(IP=0.0.0.0:389)
slapd[6491]: conn=1747 op=0 [IP=10.93.64.180
USERNAME=uid=cas-auth,ou=si,ou=access,dc=domain,dc=com] BIND
dn="uid=cas-auth,ou=si,ou=access,dc=domain,dc=com" method=128
slapd[6491]: conn=1747 op=0 [IP=10.93.64.180
USERNAME=uid=cas-auth,ou=si,ou=access,dc=domain,dc=com] BIND
dn="uid=cas-auth,ou=SI,ou=Access,dc=domain,dc=com" mech=SIMPLE ssf=0
slapd[6491]: conn=1747 op=0 [IP=10.93.64.180
USERNAME=uid=cas-auth,ou=si,ou=access,dc=domain,dc=com] RESULT tag=97
err=0 text=
slapd[6491]: conn=1747 op=1 UNBIND
slapd[6491]: conn=1747 fd=13 closed
The configuration part relative to translucent:
# Entry 1: olcOverlay={3}translucent,olcDatabase={2}mdb,cn=config
dn: olcOverlay={3}translucent,olcDatabase={2}mdb,cn=config
objectclass: olcConfig
objectclass: olcOverlayConfig
objectclass: olcTranslucentConfig
objectclass: top
olcoverlay: {3}translucent
olctranslucentbindlocal: TRUE
# Entry 2:
olcDatabase={0}ldap,olcOverlay={3}translucent,olcDatabase={2}m...
dn:
olcDatabase={0}ldap,olcOverlay={3}translucent,olcDatabase={2}mdb,cn=conf
ig
objectclass: olcConfig
objectclass: olcLDAPConfig
objectclass: olcTranslucentDatabase
objectclass: olcDatabaseConfig
olcdatabase: {0}ldap
olcdbchasereferrals: TRUE
olcdbidassertauthzfrom: {0}*
olcdbidassertbind: bindmethod="simple"
binddn="uid=roaccess,ou=access,dc=dom
ain,dc=com" credentials="hideme" mode="self"
olcdbsessiontrackingrequest: TRUE
olcdburi: ldap://ldap-data.domain.it
I do not really know where to look else. I'll continue to try different
things to make it work but any idea/suggestion/correction is welcome.
Thank you in advance for your time.
--
------------
M. P.
7 years, 8 months
Merging databases with translucent
by M. P.
Hi,
We are on a process of merging datas from a remote database to a local
database. The two databases have the same base dn. To ease this process,
I thought for a way to make a union of the remote database and the local
database until remote datas are merged to local database. From my
reading I found this thread
http://thread.gmane.org/gmane.network.openldap.technical/11893 that is
something that correspond I think to what I want.
The practical part is done on a debian jessie 8.2 with openldap
2.4.40+dfsg-1+deb8u1 version. The local database definition is like
this.
# Entry 1: olcDatabase={2}mdb,cn=config
dn: olcDatabase={2}mdb,cn=config
objectclass: olcDatabaseConfig
objectclass: olcMdbConfig
olcaccess: ...
olcdatabase: {2}mdb
olcdbdirectory: /var/lib/ldap/base_dn
olcdbindex: ...
olcdbmaxsize: 104857600
olclimits: ...
olcrootdn: cn=admin,dc=base,dc=dn
olcrootpw: {SSHA}.......
olcsuffix: dc=base,dc=dn
olcsyncrepl: ...
olcupdateref: ldap://master.ldap.server/
To this database definition I have added this part to make translucent
work.
# ldapadd -Y EXTERNAL -H ldapi:/// << EOF
dn: olcOverlay=translucent,olcDatabase={2}mdb,cn=config
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: olcTranslucentConfig
objectClass: top
olcOverlay: translucent
EOF
# ldapadd -Y EXTERNAL -H ldapi:/// << EOF
dn:
olcDatabase=ldap,olcOverlay={3}translucent,olcDatabase={2}mdb,cn=config
objectClass: olcConfig
objectClass: olcLDAPConfig
objectClass: olcTranslucentDatabase
objectClass: olcDatabaseConfig
olcDbURI: ldap://remote-ldap.server
olcDbIDAssertBind: bindmethod="simple" binddn="cn=binddn,dc=base,dc=dn"
credentials="onepassword" mode="self"
EOF
With this configuration, I can see on the local server, the entries that
are available on the remote server only, an ldapsearch does not return
entries available on the local server. Is this the normal behavior ?
Another problem is that when I restart slapd, I have an error like this
slapd[3440]: @(#) $OpenLDAP: slapd (Sep 11 2015 15:11:55)
$#012#011buildd@babin:/build/openldap-nFTO9j/openldap-2.4.40+dfsg/debian/build/servers/slapd
slapd[3441]: syncprov_db_open: invalid config, lastmod must be enabled
slapd[3441]: backend_startup_one (type=mdb, suffix="dc=linkeo,dc=com"):
bi_db_open failed! (-1)
slapd[3441]: DIGEST-MD5 common mech free
slapd[3441]: slapd stopped.
I have to reload config without dn:
olcOverlay=translucent,olcDatabase={2}mdb,cn=config and dn:
olcDatabase=ldap,olcOverlay={3}translucent,olcDatabase={2}mdb,cn=config
entries to make slapd start properly.
Can somebody tell me what I have done wrong ?
Thanks,
--
------------
M. P.
7 years, 8 months
LMBD questions (stat & copy)
by Bruno Freudensprung
Hi,
I am trying to detect MDB_MAP_FULL based on mdb_stat(txn, dbi, &stat) results and I am wondering if I am on the right track or doing things correctly.
I have a small and simple test program (http://pastebin.com/SPCYgWMC) exhibiting the following behavior (consistent between Windows 7 64-bit and Ubuntu 15.10 64-bit - latest version of lmdb cloned and recompiled on Linux):
* Inserting 20990 key value pairs in a database is OK when using one transaction. Just before commiting the write transaction, mdb_stat(txn, dbi, &stat) shows that the total number of pages (253) is very close the the number of pages of the map (256). Indeed, adding another entry leads to MDB_MAP_FULL. To put it shortly, this scenario looks OK (I am assuming there might be 3 "internal-purpose" pages not shown by mdb_stat) and can be tested by setting the stat_test variable to 0 at line 20 of the test program.
* Inserting same 20990 key value pairs in a database fails (MDB_MAP_FULL encountered at 19357) when using two consecutive write transactions. Just before MDB_MAP_FULL, mdb_stat(txn, dbi, &stat) shows that the total number of pages (232) is "quite far" from the the number of pages of the map (256), leading my MDB_MAP_FULL detection heuristic to fail. It means that only 92% of the total amount of data can be sucessfully added to the database. Other scenarii (with same key/value lengths though) stop at 85% only. This can be tested by setting the stat_test variable to 1 (line 20).
By "total number of pages" I mean ms_branch_pages + ms_leaf_pages + ms_overflow_pages.
Do you think I am on a wrong track? (maybe mdb_stat does not show 24 "internal-purpose" pages in the second case? or I am forgetting something?).
One last remark: it seems that mdb_env_copy(db, copy_dir) is possible during a write transaction on Windows (like stated in the documentation), but not on Linux (the test program seems to be stopped on a mutex at line 62). This can be tested by changing the copy_test variable to 1 at line 19. Is it expected given my program?
Best regards,
Bruno.
7 years, 8 months
