openldap-technical

openldap-technical@openldap.org

9790 discussions

Re: Antw: Re: Removing Berkeley DB Log Files
by Quanah Gibson-Mount 07 Sep '17

07 Sep '17

--On Thursday, September 07, 2017 8:45 AM -0400 Douglas Duckworth <dod2014(a)med.cornell.edu> wrote: > > Can't one dump the database to LDIF then make changes? That's probably > not going to work for Amazon or Facebook but we only have 4000 entries in > our database. That would be the only way to do a subtree rename with back-bdb, yes. Again, there's no reason to use back-bdb. back-bdb: Introduced in OpenLDAP 2.1 to replace back-ldbm back-hdb: Introduced in OpenLDAP 2.2 to replace back-bdb back-mdb: Introduced in OpenLDAP 2.4 to replace both back-bdb and back-hdb If you're using back-bdb, at least move to back-hdb. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

pcache overlay, caching DNs
by Roel van Meer 07 Sep '17

07 Sep '17

Hi list! I've been figuring out how to get the pcache overlay to work, but I'm stuck with one thing: caching of DNs. Take this example config: overlay pcache pcache bdb 10000 2 500 100 directory /var/lib/ldap/cache pcacheAttrset 0 * pcacheAttrset 1 uid pcacheTemplate (uid=) 0 300 pcacheTemplate (uid=) 1 300 This works for queries like: ldapsearch "uid=foo" '*' or ldapsearch "uid=foo" 'uid' but NOT for: ldapsearch "uid=foo" 'dn' Can anyone tell me if it is at all possible to use pcache for caching DNs? Things I have tried so far: - adding 'dn' as a pcacheAttrset, but then slapd fails to start with the error "line 63: attribute type undefined". - adding 'distinguishedName' as a pcacheAttrset, and then the result is cached when I request the distinguishedName attribute, but not when the dn is requested. I've tried openldap 2.4.40 and 2.4.44 (specifically, the version from Debian jessie and the version from jessie-backports). Thanks a lot, Roel

1 0

glibc 2.25 mutex bug
by Howard Chu 07 Sep '17

07 Sep '17

I spent the past few days trying to reproduce a deadlock in LMDB I've been seeing on a recently updated Arch Linux system. It turns out there's a bug in mutex locking in glibc 2.25. https://sourceware.org/bugzilla/show_bug.cgi?id=21778 Be aware, if your system has upgraded to glibc 2.25 you really need to get onto glib 2.26 otherwise you're going to run into a lot of mysterious hangs. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Antw: Re: Removing Berkeley DB Log Files
by Douglas Duckworth 07 Sep '17

07 Sep '17

Can't one dump the database to LDIF then make changes? That's probably not going to work for Amazon or Facebook but we only have 4000 entries in our database. On Sep 6, 2017 10:32 PM, "Quanah Gibson-Mount" <quanah(a)symas.com> wrote: --On Monday, September 04, 2017 11:33 AM +0200 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: >>>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am 01.09.2017 um 21:58 >>>> in > Nachricht <2032476F3CBBE8B34FB96BAD(a)[192.168.1.30]>: >> --On Friday, September 01, 2017 11:48 AM -0400 Douglas Duckworth >> <dod2014(a)med.cornell.edu> wrote: >> >>> >>> Vinyl records are back in style. So it seems slapd.conf and bdb. >> >> Yeah, I got to spend 2+ hours with a customer today because they chose >> to use back-bdb, and it lacks subtree rename... so something that >> should have been trivial to resolve was a long drawn out process. >> There are good reasons things have progressed beyond slapd.conf and >> back-bdb. > > I wonder: Aren't both mdb and bdb key-value databases? So if one backend > implements a subtree rename, the other could do it as well. I think it's > nor fair to blame BDB itself for that... back-hdb supports subtree rename. Pay attention to the difference between back-bdb and back-hdb, both which sit on top of BDB. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <https://urldefense.proofpoint.com/v2/url?u=http- 3A__www.symas.com&d=DwICAg&c=lb62iw4YL4RFalcE2hQUQealT9- RXrryqt9KZX2qu2s&r=2Fzhh_78OGspKQpl_e-CbhH6xUjnRkaqPFUS2wTJ2cw&m= WmwoyUOPXDE8GHw4h-NuBEidgQPN6jTRQs_xA0Fm-NM&s=c1SywnbtcEvvlu6yLxToeeC3Ckjr39 2inXrymwgMLBs&e=>

1 0

Re: Fwd: REG: I thought I got the ACLs, but......
by 8zero2 operations 06 Sep '17

06 Sep '17

Thanks man, was searching down the wrong subtree :/, These are the two things I was doing wrong. 1.) I thought i need explicit access to entry and children attributes. 2.) I was searching in root DN and was expecting the accessible DNs to come in result, whereas access(search/read/write access) will also be needed. finally pheww.. I spent one whole day trying to understand this :/ Regards, Mail: 8zero2.in(a)gmail.com Facebook: www.facebook.com/8zero2 Twitter: @8zero2_in Blog: blog.8zero2.in On Wed, Sep 6, 2017 at 8:30 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Wednesday, September 06, 2017 6:15 PM +0530 8zero2 operations < > 8zero2ops(a)gmail.com> wrote: > > So here is my scenario I have an ou of "user" and an ou of "Administrator" >> now one user from administrator branch should be able to edit anything in >> user branch and the other user should only be able to read the branch >> "user", also I want userPassword to be visible to only Administrator >> which has write permissions. >> > > I suggest reading up on the "entry" pseudo-attribute as documented in the > slapd.access(5) man page. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: Antw: Re: Removing Berkeley DB Log Files
by Quanah Gibson-Mount 06 Sep '17

06 Sep '17

--On Monday, September 04, 2017 11:33 AM +0200 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: >>>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am 01.09.2017 um 21:58 >>>> in > Nachricht <2032476F3CBBE8B34FB96BAD(a)[192.168.1.30]>: >> --On Friday, September 01, 2017 11:48 AM -0400 Douglas Duckworth >> <dod2014(a)med.cornell.edu> wrote: >> >>> >>> Vinyl records are back in style. So it seems slapd.conf and bdb. >> >> Yeah, I got to spend 2+ hours with a customer today because they chose >> to use back-bdb, and it lacks subtree rename... so something that >> should have been trivial to resolve was a long drawn out process. >> There are good reasons things have progressed beyond slapd.conf and >> back-bdb. > > I wonder: Aren't both mdb and bdb key-value databases? So if one backend > implements a subtree rename, the other could do it as well. I think it's > nor fair to blame BDB itself for that... back-hdb supports subtree rename. Pay attention to the difference between back-bdb and back-hdb, both which sit on top of BDB. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: BDB VS HDB for openldap2.4
by Quanah Gibson-Mount 06 Sep '17

06 Sep '17

--On Wednesday, September 06, 2017 8:20 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > What is the recommended backend db for openldap2.4 dbd or hdb? which > one give better performance? back-mdb is the recommended backend for OpenLDAP 2.4. back-bdb and back-hdb are both deprecated and will be removed from a future release. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: BDB VS HDB for openldap2.4
by rammohan ganapavarapu 06 Sep '17

06 Sep '17

What is the recommended backend db for openldap2.4 dbd or hdb? which one give better performance? Thanks, Ram

1 0

Re: hdb_search: 163 does not match filter
by Quanah Gibson-Mount 06 Sep '17

06 Sep '17

--On Wednesday, September 06, 2017 10:05 AM -0400 Bernard Fay <bernard.fay(a)gmail.com> wrote: > > Hello, > > > I see a lot of "hdb_search: x does not match filter" in the log file of > my openldap server. > > > Does someone know what it this about? Should I by worried about this? > How can I fix this if it need to be fixed? It looks like you have your log level set to "TRACE". Thus you are simply seeing hdb parse through every entry and whether or not it matches the supplied filter. It's generally a waste to have that high of a log level set unless you're tracking down a specific problem. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Fwd: REG: I thought I got the ACLs, but......
by Quanah Gibson-Mount 06 Sep '17

06 Sep '17

--On Wednesday, September 06, 2017 6:15 PM +0530 8zero2 operations <8zero2ops(a)gmail.com> wrote: > So here is my scenario I have an ou of "user" and an ou of "Administrator" > now one user from administrator branch should be able to edit anything in > user branch and the other user should only be able to read the branch > "user", also I want userPassword to be visible to only Administrator > which has write permissions. I suggest reading up on the "entry" pseudo-attribute as documented in the slapd.access(5) man page. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical