openldap-technical

openldap-technical@openldap.org

14 participants
9795 discussions

Client IP in Loadbalanced configuration
by Pascal kolijn 06 Jul '18

06 Jul '18

List, I have a haproxy loadbalanced ldap service. I would like to see the 'original' client IP in the openldapserver log files, because now I only see the haproxies IP addresses for all sessions. I understand that haproxy has a 'feature' called the PROXY protocol [https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt] that adds the original IP as metadata somewhere in the request, I had hopes that this would work with openldap >= 2.3, because they tested such a PROXY protocol signature packet. But it is not, yet(?), implemented in openldap. I also understand that the slapd-ldap backend has a option called session-tracking-request so some serverside/backend side stuff seems to be available somewhere in openldap.. So any pointers or tips to achieve this, or use a different setup? -- Pascal Kolijn Vrije Universiteit Amsterdam

2 1

time-base release schedule?
by David Magda 03 Jul '18

03 Jul '18

Hello, Would it be possible to moved to a timed release schedule? Looking at the ChangeLog, the current release 'schedule' seems to be a bit... non-deterministic: http://www.openldap.org/software/release/changes.html Moving towards a fixed-date schedule (once or twice a year?) would allow downstream maintainers to update things like Linux distributions in a more predictable fashion. The "maintenance releases" would be nothing more than tagging all of the patches since the last release and creating a tarball. If there are zero patches since the last releases, then a new tarball may not be needed (or a "NOP release" could be done just to keep people in-practice). Otherwise, regardless of whether is is one or one-dozen patches, a new version is revved. If there is a security issue, a release could be issued outside of the fixed schedule. Ideally (IMHO) security releases would only include the security fix so people can be confident that it is a low-risk change that won't change / break other behaviours. Given that most users of OpenLDAP "consume" it via their distribution-of-choice's package, this would (IMHO) increase the chances of more recent versions of OpenLDAP being used (especially in Debian and Ubuntu, but also Fedora). Recent Debian releases occur in Q2, and Ubuntu does April/October (LTSes are April), while Fedora (roughly) does May/November. Perhaps a February/September cycle? Not sure whether this is something for 2.4, or for 2.5 when it comes out. Any thoughts? Regards, David

5 8

LMDB docs
by KS Sreeram 03 Jul '18

03 Jul '18

Hello folks On this page: http://www.lmdb.tech/doc/starting.html The following passage occurs: > Because LMDB is very efficient (and usually zero-copy), the data returned in an MDB_val structure may be memory-mapped straight from disk. In other words look but do not touch (or free() for that matter). Once a transaction is closed, the values can no longer be used, so make a copy if you need to keep them after that. The second sentence above is a bit misleading. Returned data cannot be used after a subsequent update. Not mentioning that is misleading. Perhaps the second sentence can be replace with this: > The values can no longer be used after a subsequent update or after the transaction ends. Make a copy if you need to keep them after that. The documentation for `mdb_get` is correct and does mention the constraints. It’ll be nice to update this page too. Best KS Sreeram

1 0

test059-slave-config schema replication
by Richard Gray 03 Jul '18

03 Jul '18

Hi, I am trying to get cn=config replication working as demonstrated by the test059-slave-config test script, but have run into a problem with schema replication. This is the same issue raised on the list previously by Christopher Strider Cook [1], but I thought I'd bring it up again as it's been seven years, so perhaps there are new ideas in this space. Furthermore, I can demonstrate how to reproduce the problem with a simpler configuration than that described by Christopher. [1]: https://www.openldap.org/lists/openldap-technical/201106/msg00157.html test059-slave-config describes two configuration trees, cn=config as used by a master server, and cn=config,cn=slave which is replicated to any number of replica servers. Furthermore, there is a syncrepl agreement defined on the cn=config,cn=slave database that replicates the master schema from cn=schema,cn=config into the replica configuration tree as cn=schema,cn=config,cn=slave. If you make any changes to the cn=config,cn=slave tree however, the next time the master is restarted, it will complain that the "consumer state is newer than provider". At this point, I'm considering ditching the schema replication, and maintaining it independently on the master and replica servers. It's probably not much of an imposition seeing as I will need to maintain the rest of the master and replica configuration independently anyway. Nevertheless, I thought I'd raise the issue here to see if anyone had any clever solutions to this problem. Here's how to reproduce the issue (OpenLDAP 2.4.46 on Linux 4.15.12): 1. Download and build OpenLDAP 2. Run test059-slave-config: ./run test059-slave-config 3. Start a slapd using the provider config created by the test script: /home/richard/working/openldap-2.4.46/tests/../servers/slapd/slapd -F /home/richard/working/openldap-2.4.46/tests/testrun/cfpro.d -h ldap://localhost:9011/ -d 0x4105 4. Make a change under cn=config,cn=slave: $ ldapadd -x -h localhost -p 9011 -D cn=config -w EMWRueBU dn: olcBackend=bdb,cn=config, cn=slave objectClass: olcBackendConfig olcBackend: bdb adding new entry "olcBackend=bdb,cn=config, cn=slave" ^C 5. Restart the slapd instance: ^C /home/richard/working/openldap-2.4.46/tests/../servers/slapd/slapd -F /home/richard/working/openldap-2.4.46/tests/testrun/cfpro.d -h ldap://localhost:9011/ -d 0x4105 ...SNIP... 5b3b0202 conn=1005 op=1 SRCH base="cn=schema,cn=config" scope=2 deref=0 filter="(objectClass=*)" 5b3b0202 conn=1005 op=1 SRCH attr=* + 5b3b0202 send_ldap_result: conn=1005 op=1 p=3 5b3b0202 send_ldap_result: err=0 matched="" text="" 5b3b0202 send_ldap_result: conn=1005 op=1 p=3 5b3b0202 send_ldap_result: err=53 matched="" text="consumer state is newer than provider!" 5b3b0202 send_ldap_response: msgid=2 tag=101 err=53 ber_flush2: 52 bytes to sd 16 read1msg: ld 0x7fd46c109ba0 msgid 2 all 0 ber_get_next 5b3b0202 conn=1005 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! ber_get_next: tag 0x30 len 50 contents: read1msg: ld 0x7fd46c109ba0 msgid 2 message type search-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x7fd46c109ba0 0 new referrals read1msg: mark request completed, ld 0x7fd46c109ba0 msgid 2 request done: ld 0x7fd46c109ba0 msgid 2 res_errno: 53, res_error: <consumer state is newer than provider!>, res_matched: <> ldap_free_request (origid 2, msgid 2) 5b3b0202 do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_err2string 5b3b0202 do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform ldap_err2string Any suggested workarounds would be appreciated. Regards, -- *Richard Gray* | Operations Technical Lead *DDI:* +64 9 950 2196 *Fax:* +64 9 302 0518 *Mobile:* +64 21 050 8178 *Freephone:*0800 SMX SMX (769 769) *SMX Limited:* Level 15, 19 Victoria Street West, Auckland, New Zealand *Web:* http://smxemail.com SMX | Cloud Email Hosting & Security _____________________________________________________________________________ This email has been filtered by SMX. For more info visit http://smxemail.com _____________________________________________________________________________

1 0

sql backend & upate data
by Arianna Milazzo 29 Jun '18

29 Jun '18

Hello! I use openLDAP with a sql backend. I use mySQL with InnoDB engine. Well, if I modify a data on db, I can't see the new value on openLDAP until I restart it. :O I can't restart openLDAP every time I modify something! Any solution? Thanks, Arianna

1 1

Performance problem with slapd instances.
by Saurabh Lahoti 28 Jun '18

28 Jun '18

Dear, We've started observing strange & peculiar performance behavior for slapd instances. While ldap bind response is more than 1.5 second on one server then on another it's just 0.006 seconds. Both the servers have similar OS, system resources & ldap version. OS: RHEL 6.9 LDAP: 2.4.44 Backend: bdb Could you please suggest some probable causes..? Thanks & Kind Regards, Saurabh Lahoti.

2 2

replicating memberOf attribute
by Chris 27 Jun '18

27 Jun '18

Hi, We are using a provider and three consumers that are not syncing the memberOf attributes of inetOrgPerson entries. memberof and refint modules are loaded on the provider and inetOrgPersons' memberOf attributes are correctly updated on the provider. How can I troubleshoot this? Thanks. Chris.

2 2

Debian getting rid of nis and adding rfc2307bis
by malcolm moore 27 Jun '18

27 Jun '18

Are there any instructions for this anywhere ? I've been seaching and struggling now for several days and I can't work out how to do it. It can't be as difficult as i am making it Ta Mal

2 1

Re: OPenLDAP instances frequently crashes
by Saurabh Lahoti 25 Jun '18

25 Jun '18

Dear, Just before crash below message logged into system logs of servers: Jun 11 23:01:37 musang kernel: Out of memory: Kill process 22184 (slapd) score 888 or sacrifice child Jun 11 23:01:37 musang kernel: Killed process 22184, UID 0, (slapd) total-vm:52226320kB, anon-rss:37170216kB, file-rss:1044kB Although, my physical RAM size is 38 GB & actual database size is 32 GB. Why is it not managing memory appropriately with the help from swap...? ---- *Thanks & Kind Regards,* Saurabh LAHOTI. On Wed, 13 Jun 2018 at 15:57, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Wednesday, June 13, 2018 8:56 AM +0200 Michael Ströder > <michael(a)stroeder.com> wrote: > > > On 06/12/2018 06:15 AM, Saurabh Lahoti wrote: > >> Frequently, our OpenLDAP instances crashes thereby leading us into > severe > >> disastrous results & outages for business. > >> > >> While going through slapd logs, it always says " bdb_db_open: database: > >> unclean shutdown detected; attempting recovery" > >> > >> What could possibly go wrong here..? > > > > Which OpenLDAP version are you using? Which OS? > > What does openldap log before it crashes? > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

3 2

Meta backend and attributes mapping
by ROY Grégory 22 Jun '18

22 Jun '18

Hello, I try somehow to do what I explain below. But without success... I think I'm doing badly for the attribute mapping, maybe it would be better with the rwm overlay? Could someone put me on the right track? -> I have this : ---------------------------------------------------------------------------------------------------------------------------------------------------- dc=domain1,dc=local dc=domain2, dc=local |__ou=users |__ou= apps |__ou=standard |__ou= app1 |__cn = JOHN DOE | |__cn = DOEJOHN |__ att: sAMAccountName= DOEJOHN | |__att: Appval=valuex |__att: phonenumber=0102030405 |__ou= app2 |__cn= DOEJOHN |__att: Appval=valuey ---------------------------------------------------------------------------------------------------------------------------------------------------- -> and i wan't to do this : ---------------------------------------------------------------------------------------------------------------------------------------------------- dc=meta,dc=local |_ou=users |_cn= DOEJOHN |_att: phonenumber=0102030405 |_att: App1val=valuex |_att: App2val=valuey ---------------------------------------------------------------------------------------------------------------------------------------------------- -> I do it this way, with the meta backend : ---------------------------------------------------------------------------------------------------------------------------------------------------- ######################################################################### defaultsearchbase dc=meta,dc=local ### database META ##################################################### database meta suffix dc=meta,dc=local rootdn "cn=admin,dc=meta,dc=local" rootpw secret ## AD1 USERS ### uri "ldap://ad.domain1.local:389/ou=users,dc=meta,dc=local" suffixmassage "ou=users,dc=meta,dc=local" "ou=users,ou=standard,dc=domain1,dc=local" idassert-bind bindmethod=simple binddn="CN=reader,DC=domain1,DC=local" credentials="password" mode=self idassert-authzFrom "dn.regex:.*" access to * by * read map attribute uid sAMAccountname ## AD2 APP 1 ############### uri "ldap://ad.domain2.local:389/ou=users,dc=meta,dc=local" suffixmassage "ou=users,dc=meta,dc=local" "ou=app1,ou=apps,dc=domain2,dc=local" idassert-bind bindmethod=simple binddn="CN=reader,DC=domain2,DC=local" credentials="password" mode=self idassert-authzFrom "dn.regex:.*" access to * by * read map attribute uid cn map attribute App1val Appval ## AD2 APP 2 ############### uri "ldap://ad.domain2.local:389/ou=users,dc=meta,dc=local" suffixmassage "ou=users,dc=meta,dc=local" "ou=app2,ou=apps,dc=domain2,dc=local" idassert-bind bindmethod=simple binddn="CN=reader,DC=domain2,DC=local" credentials="password" mode=self idassert-authzFrom "dn.regex:.*" access to * by * read map attribute uid cn map attribute App2val Appval lastmod off ---------------------------------------------------------------------------------------------------------------------------------------------------- I get this result, and it does not really correspond to what I want to get .... : ---------------------------------------------------------------------------------------------------------------------------------------------------- [root@server openldap]# ldapsearch -x "uid=DOEJOHN" -H 'ldap://localhost/' -b dc=meta,dc=local -LLL phonenumber App1val App2val dn: cn=JOHN DOE,ou=users,dc=meta,dc=local phonenumber: 0102030405 dn: cn=DOEJOHN,ou=users,dc=meta,dc=local App1val: valuex dn: cn=DOEJOHN,ou=users,dc=meta,dc=local App2val: valuey ---------------------------------------------------------------------------------------------------------------------------------------------------- Regards, -- Greg

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical