openldap-technical

openldap-technical@openldap.org

9897 discussions

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

hdb_search: 163 does not match filter
by Bernard Fay 06 Sep '17

06 Sep '17

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? [root@ slapd]# slapd -V @(#) $OpenLDAP: slapd 2.4.40 (Mar 31 2016 15:24:52) $ mockbuild(a)worker1.bsys.centos.org: /builddir/build/BUILD/openldap-2.4.40/openldap-2.4.40/servers/slapd Thanks, Bernard

1 0

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

06 Sep '17

Hi, I have a ACL problem, I am not able to figure out what I am doing wrong. Or if there is something wrong in what I understood. 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. here is my initial ACL for it {0}to attrs=userPassword by dn.exact="uid=domain.admin,ou= Administrator,dc=example,dc=com" write by anonymous auth {1}to dn.subtree="ou=user,dc=example,dc=com" attrs=entry,children by dn.exact="uid=domain.admin,ou=Administrator,dc=example,dc=com" write by dn.exact="uid=domain.auth,ou=Administrator,dc=example,dc=com" read now using above acl none of the user domain.auth or domain.admin is able read/write/search in "user" ou. Only if I add the following ACL to it. {2} to * by dn.exact="uid=domain.admin,ou=Administrator,dc=example,dc=com" write by dn.exact="uid=domain.auth,ou=Administrator,dc=example,dc=com" read everything works as i want it to work. Mail: 8zero2.in(a)gmail.com Facebook: www.facebook.com/8zero2 Twitter: @8zero2_in Blog: blog.8zero2.in

1 0

Slapd.d configuration for write chaining
by Tim 06 Sep '17

06 Sep '17

Heya, In order to enable write chaining, I used the normal mechanism of using a slapd.conf file to generate the necessary slapd.d configuration that I'm now using to seed the servers that I'm building. Out of interest - why do I need the two separate overlays (shown bellow) in the final config? Trying to understand what's actually happening and can't quite make sense of why this is defined like this. dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbStartTLS: start starttls=yes olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {1}ldap olcDbURI: "ldap://*ldapserver*/" olcDbStartTLS: start starttls=yes olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindmethod=simple timeout=0 network-timeout=0 binddn="*binddn*" credentials="*cred*" keepalive=0:0:0 starttls=yes tls_cacert="/etc/openldap/certs/CA.crt" tls_reqcert=demand olcDbRebindAsUser: TRUE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 Thanks in advance, -- Tim tim(a)yetanother.net

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