openldap-technical

openldap-technical@openldap.org

9 participants
9866 discussions

Q: Stable output of slapcat?
by Ulrich Windl 22 Jul '20

22 Jul '20

Hi! I wonder: Is the output of slapcat expected to be stable (assuming the database did not change)? I know that LDAP attributes are considered to be sets that have no implicit ordering, but diff-wise it would be rather nice to have a stable output ordering. Here is an example of non-stable output ordering (sdiff output, only first 18 columns for confidentiality): # sdiff b0 b1 dn: olcDatabase={1 dn: olcDatabase={1 objectClass: olcDa objectClass: olcDa objectClass: olcHd objectClass: olcHd olcDatabase: {1}hd olcDatabase: {1}hd olcDbDirectory: /v olcDbDirectory: /v olcSuffix: dc=sap, olcSuffix: dc=sap, olcAccess: {0}to * < olcAccess: {1}to d < olcAccess: {2}to a < olcAccess: {3}to a < olcAccess: {4}to a < olcAccess: {5}to * < olcLimits: {0}dn.e olcLimits: {0}dn.e olcRootDN: cn=Admi olcRootDN: cn=Admi olcRootPW: {SSHA}y olcRootPW: {SSHA}y olcSecurity: ssf=1 olcSecurity: ssf=1 olcSyncrepl: {0}ri olcSyncrepl: {0}ri olcSyncrepl: {1}ri olcSyncrepl: {1}ri olcSyncrepl: {2}ri olcSyncrepl: {2}ri olcUpdateRef: ldap olcUpdateRef: ldap olcUpdateRef: ldap olcUpdateRef: ldap olcUpdateRef: ldap olcUpdateRef: ldap olcMirrorMode: TRU olcMirrorMode: TRU olcDbCacheSize: 10 olcDbCacheSize: 10 olcDbCheckpoint: 1 olcDbCheckpoint: 1 olcDbConfig: {0}se olcDbConfig: {0}se olcDbConfig: {1}se olcDbConfig: {1}se olcDbConfig: {2}se olcDbConfig: {2}se olcDbConfig: {3}se olcDbConfig: {3}se olcDbConfig: {4}se olcDbConfig: {4}se olcDbConfig: {5}se olcDbConfig: {5}se olcDbIDLcacheSize: olcDbIDLcacheSize: olcDbIndex: object olcDbIndex: object olcDbIndex: uidNum olcDbIndex: uidNum olcDbIndex: gidNum olcDbIndex: gidNum olcDbIndex: member olcDbIndex: member olcDbIndex: member olcDbIndex: member olcDbIndex: cn eq, olcDbIndex: cn eq, olcDbIndex: uid eq olcDbIndex: uid eq olcDbIndex: sn eq, olcDbIndex: sn eq, olcDbIndex: givenN olcDbIndex: givenN olcDbIndex: entryU olcDbIndex: entryU olcDbIndex: entryC olcDbIndex: entryC olcDbIndex: ipServ olcDbIndex: ipServ olcDbIndex: ipServ olcDbIndex: ipServ olcDbIndex: roleOc olcDbIndex: roleOc olcDbIndex: mail e olcDbIndex: mail e olcDbIndex: displa olcDbIndex: displa olcDbIndex: modify olcDbIndex: modify structuralObjectCl structuralObjectCl entryUUID: db3ffe4 entryUUID: db3ffe4 creatorsName: cn=c creatorsName: cn=c createTimestamp: 2 createTimestamp: 2 entryCSN: 20170706 | olcAccess: {0}to * > olcAccess: {1}to d > olcAccess: {2}to a > olcAccess: {3}to a > olcAccess: {4}to a > olcAccess: {5}to * > entryCSN: 20200114 modifiersName: cn= modifiersName: cn= modifyTimestamp: 2 modifyTimestamp: 2 So is the order of output given by some hash functions in slapcat, or is it the order in which the database returns the attributes? What would I have to do to sort the attribute types in the same order as they are listed in the schema (one possible stable output)? Regards, Ulrich

3 5

anonymize data
by Olivier - 21 Jul '20

21 Jul '20

Hi all, I have a question anonymizing data. My openldap have some confidential data inside and I would like this : if a person has a flag confidentiality set to 1 (or is in a special ou), openldap will replace or answer a different data. For example : if we request "sn" on this record , it will reply "Smith" dn: cn=Smith,ou=public,c=com confidentiality: 0 sn: Smith if we request "sn" on this record , it will reply "XXX" dn: cn=Bond,ou=public,c=com confidentiality: 1 sn: Bond I'm not sur Openldap can offer this kind of functionnality. Thanks for your help !

5 6

Re: Upgrade from 2.4.44 to 2.4.45+
by Quanah Gibson-Mount 21 Jul '20

21 Jul '20

--On Monday, July 20, 2020 11:26 PM -0700 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > What is the upgrade process from 2.4.44 to 2.4.45 or above? Are there any > breaking changes that I need to take care before and/or after upgrading? a) You need to be upgrading to 2.4.50, 2.4.45 has a few CVEs. b) If you use ppolicy, you will want to reload your database after upgrading to 2.4.50 due to a database format change for the pwdChangedTime attribute (I.e., slapcat your db, then slapadd it back in after you're done with the upgrade). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: [EXT] Re: syncrepl does not work as expected
by kumar rahul 20 Jul '20

20 Jul '20

Hi Quanah Thank you for the response. If the consumer is several days behind and the accesslog does not have the data then fresh reload from the provider will happen automatically? Thanks Rahul On Tue, Jul 14, 2020 at 11:28 AM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Friday, July 10, 2020 11:04 AM -0400 kumar rahul > <rahul2002mit(a)gmail.com> wrote: > > > > 1) What is the recommended value for olcSpCheckpoint? > > As per your blog value is olcSpCheckpoint: 20 10 > > I prefer to have it checkpoint fairly frequently, which is why I chose > those values. > > > 2) What is the recommended value of olcAccessLogPurge? > > As per your blog value is olcAccessLogPurge: 01+00:00 00+04:00 > > So this depends specifically on the environment in question. The more > data > retained, the further back a replica can "catch up" to the provider(s) by > using delta-syncrepl. However, the more data retained, the larger the > database will be. Whether or not one wants a replica to be able to "catch > up" to a provider if it is several days behind vs reloading it with a > fresh > copy of the db from the provider is the real question. > > Regardless of the data retention period, I always suggest a frequent purge > interval. This is because slapd essentially pauses while a purge is > ongoing. For most environments, a 4 hour purge interval is not noticable. > I've gone to as frequent as every 2 hours for extremely active sites. > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

4 5

what does "mp->mp_pgno != pgno" indicate?
by James Anderson 19 Jul '20

19 Jul '20

good afternoon; i understand from https://www.openldap.org/lists/openldap-devel/201410/msg00004.html that one should not expect this to happen, but we observed it today. mdb.c:2427: Assertion 'mp->mp_pgno != pgno' failed in mdb_page_touch() Stack trace (most recent call last): … #10 Source "../../lib/lmdbxx.h", line 597, in put<dydra::sha1, unsigned int> [0x7f29dcc68690] #9 Source "../../lib/lmdbxx.h", line 569, in put [0x7f29dcc6856d] #8 Source "/usr/local/include/lmdb++.h", line 779, in dbi_put [0x7f29dcc5ed42] #7 Source "/development/source/library/com/github/LMDB/lmdb/libraries/liblmdb/mdb.c", line 8985, in mdb_put [0x7f29dcff1b8f] #6 Source "/development/source/library/com/github/LMDB/lmdb/libraries/liblmdb/mdb.c", line 6615, in mdb_cursor_put [0x7f29dcfeef81] #5 Source "/development/source/library/com/github/LMDB/lmdb/libraries/liblmdb/mdb.c", line 6473, in mdb_cursor_touch [0x7f29dcfebd05] #4 Source "/development/source/library/com/github/LMDB/lmdb/libraries/liblmdb/mdb.c", line 5620, in mdb_page_search [0x7f29dcfea70f] #3 Source "/development/source/library/com/github/LMDB/lmdb/libraries/liblmdb/mdb.c", line 2427, in mdb_page_touch [0x7f29dcfea241] #2 Source "/development/source/library/com/github/LMDB/lmdb/libraries/liblmdb/mdb.c", line 1536, in mdb_assert_fail [0x7f29dcff3ac1] #1 Source "/build/glibc-e6zv40/glibc-2.23/stdlib/abort.c", line 89, in abort [0x7f29daaec039] #0 Source "../sysdeps/unix/sysv/linux/raise.c", line 54, in raise [0x7f29daaea438] an attempt to copy with compression fails: mdb_copy -c /srv/dydra/storage/strings.mdb/ /srv/dydra/backups/strings.bak/ mdb.c:5609: Assertion 'IS_BRANCH(mc->mc_pg[mc->mc_top])' failed in mdb_cursor_sibling() Aborted an attempt to dump the problematic sub-database fails: mdb_dump -s u32:sha1 /srv/dydra/storage/strings.mdb/ > strings-u32:sha1.txt mdb.c:5685: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next() Aborted has there been any further insight since 2014 into causes? is there an alternative to restoring the database from a backup? best regards, from berlin,

1 0

invalid credentials when userPassword hash in SSHA-512
by Jehan PROCACCIA 17 Jul '20

17 Jul '20

Hello I realized that userPassword in my openldap directory cannot be validated when hashed in SSHA-512 ldapsearch binds fails (err 49) , shibboleth SSO binding against ldap userPassword also fails I tried to check the cleartext password against the userPassword field with ApacheDirectoryStudio , here it works . I changed the password (reseeting the same cleartext one) using SSHA-256 (again in ApacheDirectoryStudio interface) , then ldapsearch bind works ! Is there a problem with SSHA-512 hashed userPassword ? Maybe something one the client or server side must be set to use SSHA-512 ? Thanks for your advices .

2 3

Documentation: mapping from slapd.conf to slapd database
by Norman Gray 16 Jul '20

16 Jul '20

Greetings. Documentation such as [1] notes that there is a one-to-one correspondence between slapd.conf directives and slapd-config database attributes. However it's not always completely clear just what the mapping is. For example, both [2] and slapo-syncprov(5) describe syncprov-checkpoint. This corresponds to the attribute olcSpCheckpoint, but I can't find where it is I learned that mapping (I probably stumbled across it via [3]), so can't point to chapter and verse in my own documentation and notes. I would have thought the documentation for the olcSyncProvConfig objectClass would explain this, but I can't find any such documentation, nor even a schema for that objectClass [4]. The problem (and my puzzlement) is not unique to the syncprov overlay. Best wishes, Norman [1] https://www.openldap.org/doc/admin24/slapdconf2.html [2] https://openldap.org/doc/admin24/overlays.html [3] https://mishikal.wordpress.com/2019/04/23/configuring-mmr-using-delta-syncr… [4] Ie, grep -i syncprov /usr/local/etc/openldap/schema/* (and similar) produces nothing. -- Norman Gray : https://nxg.me.uk

3 4

Re: [EXT] Re: syncrepl does not work as expected
by kumar rahul 16 Jul '20

16 Jul '20

Thank you Quanah. This helps a lot. Let me make the changes. Thanks Rahul On Mon, Jul 6, 2020 at 5:34 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Monday, July 6, 2020 6:21 PM -0400 kumar rahul > <rahul2002mit(a)gmail.com> wrote: > > > > > > > Hi Quanah > > > > > > I have some questions from update_config.ldif file > > Please don't attach screenshots of text. If you have questions, use text > email. > > In general, however: > > One database is used as the main database for the system. Lets call this > database A. > One database is used to store the accesslog data (the change deltas). Lets > call this database B. > There may be other databases on the system (such as the monitor database). > Lets call this database C. > > Both the syncprov and accesslog *overlays* must be configured on database > A > with the appropriate configuration options. > > The syncprov overlay must *also* be configured on database B with the > appropriate (but different) configuration options to indicate it's an > accesslog DB. > > In cn=config, every database has a weight that indicates the order in > which > it loads. So: > > olcDatabase={1}... is the first DB to get loaded by slapd (Ignoring {-1} > and {0} which always exist, and are the frontend and config DBs > respectively). > > olcDatabase={2}... would be the second DB to get loaded by slapd > > olcDatabase={3}... would be the third DB to get loaded by slapd > > Additionally, overlays have weights associated with them to indicate the > order in which they get loaded. So: > > olcOverlay={1}...,olcDatabase={2}... means that this overlay is the first > one that gets loaded for database #2. > > In the EXAMPLE I provided on my blog: > > olcDatabase={1} is the monitoring database (database C above) > > olcDatabase={2} is the ACCESSLOG database (database B above) > > olcDatabase={3} is the MAIN database (database A above) > > So which overlays need to apply to which databases depends ENTIRELY ON THE > ORDER in which they are defined in *YOUR* configuration. You need to make > adjustments accordingly. > > Regards, > Quanah > > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

3 5

Re: [EXT] Re: syncrepl does not work as expected
by kumar rahul 15 Jul '20

15 Jul '20

Thank you. On Wed, Jul 15, 2020 at 11:33 AM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Wednesday, July 15, 2020 12:31 PM -0400 kumar rahul > <rahul2002mit(a)gmail.com> wrote: > > > Can you please provide the details on slapcat and import steps? > > There are man pages for both slapcat and slapadd, I suggest reading them. > > man slapcat > man slapadd > > You may also want to read the admin guide: > > > https://www.openldap.org/doc/admin24/dbtools.html#The%20{{EX:slapadd}}%20pr… > <https://www.openldap.org/doc/admin24/dbtools.html#The%20%7B%7BEX:slapadd%7D…> > > https://www.openldap.org/doc/admin24/dbtools.html#The%20{{EX:slapcat}}%20pr… > <https://www.openldap.org/doc/admin24/dbtools.html#The%20%7B%7BEX:slapcat%7D…> > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Q: Added pwdMaxRecordedFailure in pwdPolicy schema
by Ulrich Windl 15 Jul '20

15 Jul '20

Hi! It seems objectclass "pwdPolicy" (1.3.6.1.4.1.42.2.27.8.2.1) got attributetype "pwdMaxRecordedFailure" (1.3.6.1.4.1.42.2.27.8.1.30) added recently. Shouldn't the OID of the objectclass change then? Anyway, how should I upüdate the schema using cn=config? Regards, Ulrich P.S. You can find a similar question at serverfault.com

2 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical