openldap-technical

openldap-technical@openldap.org

6 participants
9858 discussions

Re: python-lmdb crashing ( d <= env->me_pglast' failed in mdb_freelist_save()) - unusable 300gb database
by mark jayson 18 Jul '23

18 Jul '23

Yep, my bad. LMDB version bundled is 0.9.29. >>> print(lmdb.version()) (0, 9, 29) On Wed, Jul 19, 2023 at 2:11 AM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Wednesday, July 19, 2023 2:59 AM +0800 mark jayson > <mark.alvarez123(a)gmail.com> wrote: > > > > > The lmdb version I'm using is: > > > > Python 3.10.6 > > > > lmdb==1.4.1 > > I'm going to guess that's the version of the python LMDB library. But the > deeper question is what is the version of the LMDB C library it is linked > to? > > --Quanah > > > > >

1 0

python-lmdb crashing ( d <= env->me_pglast' failed in mdb_freelist_save()) - unusable 300gb database
by mark jayson 18 Jul '23

18 Jul '23

Hello, I've created a program that writes data to an lmdb database using python bindings. I've written about 300gb worth of data but when I was re-reading the database by running my script again, it crashes immediately. Did a backtrace in gdb and this is what I got: Really have no clue what's going on here. I suspect that the server has rebooted (or was rebooted by someone while I was running the script but I thought lmdb is crash-proof. Do you have any idea how to best troubleshoot this? The database is worth 300gb+ so it's not easy to share it, not to mention it contains sensitive information. Starting program: /usr/bin/python3 read_events.py -d jul012022-23/ [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". build/lib/mdb.c:3274: Assertion 'len >= 0 && id <= env->me_pglast' failed in mdb_freelist_save() Program received signal SIGABRT, Aborted. __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737350283264) at ./nptl/pthread_kill.c:44 44 ./nptl/pthread_kill.c: No such file or directory. (gdb) backtrace #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=140737350283264) at ./nptl/pthread_kill.c:44 #1 __pthread_kill_internal (signo=6, threadid=140737350283264) at ./nptl/pthread_kill.c:78 #2 __GI___pthread_kill (threadid=140737350283264, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 #3 0x00007ffff7c96476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #4 0x00007ffff7c7c7f3 in __GI_abort () at ./stdlib/abort.c:79 #5 0x00007ffff62fb3e2 in mdb_assert_fail (env=0x5555565b49f0, expr_txt=expr_txt@entry=0x7ffff62fe308 "len >= 0 && id <= env->me_pglast", func=func@entry=0x7ffff62fe930 <__func__.13> "mdb_freelist_save", line=line@entry=3274, file=0x7ffff62fe010 "build/lib/mdb.c") at build/lib/mdb.c:1545 #6 0x00007ffff62f10df in mdb_freelist_save (txn=0x555556752950) at build/lib/mdb.c:3274 #7 mdb_txn_commit (txn=0x555556752950) at build/lib/mdb.c:3646 #8 0x00007ffff62f369b in txn_db_from_name (env=env@entry=0x7ffff61c8090, name=<optimized out>, flags=262144) at lmdb/cpython.c:1017 #9 0x00007ffff62f6e1d in env_open_db (self=0x7ffff61c8090, args=<optimized out>, kwds=<optimized out>) at lmdb/cpython.c:1665 #10 0x00005555556b23a9 in ?? () #11 0x0000555555699c14 in _PyEval_EvalFrameDefault () #12 0x0000555555696176 in ?? () #13 0x000055555578bc56 in PyEval_EvalCode () #14 0x00005555557b8b18 in ?? () #15 0x00005555557b196b in ?? () #16 0x00005555557b8865 in ?? () #17 0x00005555557b7d48 in _PyRun_SimpleFileObject () #18 0x00005555557b7a43 in _PyRun_AnyFileObject () #19 0x00005555557a8c3e in Py_RunMain () #20 0x000055555577ebcd in Py_BytesMain () #21 0x00007ffff7c7dd90 in __libc_start_call_main (main=main@entry=0x55555577eb90, argc=argc@entry=14, argv=argv@entry=0x7fffffffe378) at ../sysdeps/nptl/libc_start_call_main.h:58 #22 0x00007ffff7c7de40 in __libc_start_main_impl (main=0x55555577eb90, argc=14, argv=0x7fffffffe378, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe368) at ../csu/libc-start.c:392 #23 0x000055555577eac5 in _start () (gdb) client_loop: send disconnect: Broken pipe For what it's worth, this is how I've opened the database environment: dbenv = lmdb.open(db_dir, map_size=1099511627776, max_dbs=11, readahead=False)

3 3

Different loglevels based on IP prefix?
by Dick Visser 18 Jul '23

18 Jul '23

Hi Is there any way to configure slapd to log queries from certain addresses differently? I'm asking because we would like to have detailed logging for real traffic, but the loglevel we picked (stats + sync) our health checks cause a lot of noise. Since the health checks are located at specific IP addresses/prefixes, ideally we could have less or no logging for those. thanks Dick Visser

2 1

Re: [EXT] Re: pwdAccountLockedTime does not have any impact
by CVZ 17 Jul '23

17 Jul '23

Hi Everybody, Tanks Clément and tempo for your replies. Sorry for my late reply, last week was really busy. I confirm that applying ppolicy configuration, its now working fine. Ulrich, bellow, you have all the steps (Ubuntu with 2.5.14 openldap) Thanks / Merci Best Damien #configppolicy.ldif dn: olcOverlay=ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: ppolicy olcPPolicyDefault: cn=default,ou=policies,dc=abc,dc=org sudo -u openldap slapadd -n0 -l configppolicy.ldif ################### # Policies.ldif dn: ou=policies,dc=abc,dc=org objectClass: organizationalUnit ou: policies sudo -u openldap slapadd -n1 -l Policies.ldif ################### # Policies2.ldif dn: cn=default,ou=policies,dc=abc,dc=org objectClass: pwdPolicy objectClass: organizationalRole cn: default pwdAttribute: userPassword pwdMinAge: 0 pwdMinLength: .... pwdCheckQuality: 2 pwdMaxFailure: ... pwdLockout: TRUE pwdLockoutDuration: .... ... sudo -u openldap slapadd -n1 -l Policies2.ldif And restart slapd service On 12/7/23 15:42, Windl, Ulrich wrote: > Hi! > > You mean something like this?: > dn: cn=PP-Default,dc=policies,dc=...,dc=de > changetype: add > objectClass: namedObject > objectClass: pwdPolicy > cn: PP-Default > pwdAllowUserChange: TRUE > pwdAttribute: userPassword > pwdCheckQuality: 1 > pwdExpireWarning: 604800 > pwdFailureCountInterval: 1209600 > pwdLockout: TRUE > pwdLockoutDuration: 1800 > pwdMaxFailure: 10 > pwdMinAge: 30 > pwdMinLength: 8 > pwdMustChange: TRUE > pwdSafeModify: FALSE > > This is for an older version (obviously), however... > > Regards, > Ulrich > > -----Original Message----- > From: tempo(a)net-c.com <tempo(a)net-c.com> > Sent: Tuesday, July 11, 2023 6:02 PM > To: bremont(a)cvz.es; openldap-technical(a)openldap.org > Subject: [EXT] Re: pwdAccountLockedTime does not have any impact > > Hi, > > Could you show us your ppolicy settings please ? > > As far as I remember, you need at least pwdLockout set to TRUE in order to have the attribute pwdAccountLockedTime checked. > > > > > De : CVZ <bremont(a)cvz.es> > À : openldap-technical(a)openldap.org > Sujet : pwdAccountLockedTime does not have any impact > Date : 11/07/2023 11:41:41 Europe/Paris > > > > Hi Everybody, <https://urldefense.com/v3/__https://stackoverflow.com/posts/76341444/timeli… > > > Sorry, we are figghting with pwdAccountLockedTime. > > > I want to use "pwdAccountLockedTime" attribute to automatically lock an account using OpenLDAP (v.2.5.14). Whatever the value in the field, the account is never locked. > > I first started by activating the "ppolicy" module using slapadd and a ppolicy-module.ldif file suh as mentioned here "https://urldefense.com/v3/__https://stackoverflow.com/questions/49257247/ho… " <https://urldefense.com/v3/__https://stackoverflow.com/questions/49257247/ho… > , then I have checked that the module is loaded and I did not have any problem: > > $ sudo slapcat -n 0 | grep olcModuleLoad | grep ppolicy > olcModuleLoad: {0}ppolicy > > > Then, I have extended the LDAP scheme to allow using of ppolicy attributes such as "pwdAccountLockedTime". I have set it to "00000101000000Z" in order to lock permanently an account (to check if it was working). But I still can connect (using LDAP Admin tools) with the account that was supposed to be locked. > > We also tried to modify the value > > > dn: uid=... > replace: pwdAccountLockedTime > pwdAccountLockedTime: 20221021135537Z > > And even with dates in the future, but we are still able to connect. With whoami command, or from a SOGo webmail connected to the LDAP server. > > > Any idea? > Thank in advance for your help. > > > Best > Damien > >

1 0

Openldap 2.4 : Replication issue
by ramprasad.sharma＠orange.com 14 Jul '23

14 Jul '23

Dear Team, I'm facing a weird issue : My env is : root@repnode:~# ldap-utils/focal-security,focal-updates,now 2.4.49+dfsg-2ubuntu1.9 amd64 [installed,automatic] libldap-2.4-2/focal-security,focal-updates,now 2.4.49+dfsg-2ubuntu1.9 amd64 [installed,automatic] libldap-common/focal-security,focal-updates,now 2.4.49+dfsg-2ubuntu1.9 all [installed,automatic] sssd-ldap/focal-security,focal-updates,now 2.2.3-3ubuntu0.12 amd64 [installed,automatic] root@repnode:~# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.6 LTS Release: 20.04 Codename: focal root@repnode:~# Earlier, I was using two replications, without any filter and attrs..both were working fine.. But I got the requirement to select specific attributes from the master node. I applied filters and attrs based on the requirement. ( I Checked it in ldapsearch and it was working fine ) ( searchbase in both replications are different ) Replication highlighted in green is working fine.. But the replication highlighted in red is not working when applied filters , attrs or both ( without filters and attrs , it will replicating full data of that subtree ). syncrepl rid=AAA provider=ldaps://master.node:636/ bindmethod=simple filter="(objectClass=posixAccount)" attrs="cn,uid,x1sshPubKey,x2sshPubKey,uidNumber,gidNumber,homeDirectory,gecos,loginShell,description,sshPublicKey" binddn="cn=rep,dc=di-diod,dc=tech" credentials=XX searchbase="ou=people,dc=di-diod,dc=tech" scope=sub schemachecking=on type=refreshOnly interval=00:00:00:01 retry="30 5 300 3" # Replication source # The replication source must declare before mirrormode syncrepl rid=BBB provider=ldaps://master.node:636/ bindmethod=simple binddn="cn=rep,dc=di-diod,dc=tech" credentials=XX searchbase="ou=groups,dc=di-diod,dc=tech" filter="(objectClass=posixGroup)" attrs="cn,gidNumber,memberUid" scope=sub schemachecking=on type=refreshOnly interval=00:00:00:01 retry="30 5 300 3" I'm wondering, what I've done wrong here..Please help me for this issue. Warm Regards, Ram Prasad Sharma +91-9871192778 Orange Restricted ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

2 1

Rotating olcRootPW
by thomaswilliampritchard＠gmail.com 13 Jul '23

13 Jul '23

Hi, We have a 3 node multi master replication configuration setup with many consumers replicating from all 3 provider nodes. The consumers and providers replicate the from the MDB tree dc=example,dc=com. They do not replicate their config databases. The root password we are rotating is for cn=admin,dc=example,dc=com. Upon updating the olcRootPW we see the provider where the password was updated commit a new CSN and then syncrepl seems to fail for connected consumers with slapd[9227]: conn=1439 op=1 syncprov_op_search: consumer 2102 state 20230712210938.878334Z#000000#836#000000 is newer than provider 2102 state 20230712210402.018624Z#000000#836#000000 It seems as if the consumers reconnect with a state newer than the provider that just committed a new CSN for the new root password? It did not seem like the root password was replicated across the cluster however which I imagine is a deliberate choice to not replicate root db DNs. Is there a recommended workflow to rotate the root credential for a replicated database to avoid syncrepl disruption? OpenLDAP 2.4.56 (we are working to upgrade to OpenLDAP 2.5 LTS)

3 3

Re: Problem with restoring using ldif, OpenLDAP 2.6.3
by awsome jang 13 Jul '23

13 Jul '23

Hello, Thank you for your response - it was very helpful. Bug is registered with a solution proposal: https://bugs.openldap.org/show_bug.cgi?id=10077 I also saw that entryCSN can be negative as well but the proposed solution should fix the problem. createTimestamp: 20230110130503 entryCSN: 20230110130503.*-060060Z*#000000#000#000000 modifiersName: uid=root,ou=invalid,dc=vmbox,dc=int I was wondering how to handle this issue in case there is already this negative context CSN in the database? So scenario would be as follow: 1) do a backup create ldif (contains contextCSN: 20230410125515*.-401856Z* #000000#000#000000 or entryCSN with minus) 2) do an update of openldap, 3) restore backup from ldif. In this case restoring backup ends up with an error so there is no possibility to restore the backup database. Could you please provide some guidance on how to clean up this corruption in a proper way? Should I remove the line with negative contextCSN/entryCSN or remove the minus in the ldif file to restore the backup? Or is there any other way? Configuration uses provider and consumer with replication. Thank you in advance for your response, BR, Peter Am Mi., 14. Juni 2023 um 17:09 Uhr schrieb Quanah Gibson-Mount < quanah(a)fast-mail.org>: > > > --On Tuesday, June 13, 2023 12:11 PM +0200 awsome jang > <jangawsome(a)gmail.com> wrote: > > > > > Hello, > > > > I am running openldap 2.6.3 configured as provider-consumer and I would > > like to do backup/restore of the database on the provider. > > > > I create a backup on working sladp using command(ends with success, file > > created): > > slapd.exe –T cat –f slapd.conf –l backup.ldif > > > > And then trying to load it using slapd command into a new > > database(restore): > > slapd.exe -T add -f slapd.conf -l backup.ldif -d -1 > > > > Command ends with: > > . > > creatorsName: uid=root,ou=invalid,dc=vmbox,dc=int > > createTimestamp: 20230410111050Z > > entryCSN: 20230410111051.368528Z#000000#000#000000 > > modifiersName: uid=root,ou=invalid,dc=vmbox,dc=int > > modifyTimestamp: 20230410111050Z > > contextCSN: 20230410125515.-401856Z#000000#000#000000 > > > This appears to be a bug with generating the CSN on windows, likely due to > some type of overflow. Can you please file a bug report at > https://bugs.openldap.org > > Thanks! > > Regards, > Quanah > > >

3 3

auditlog to syslog
by cYuSeDfZfb cYuSeDfZfb 13 Jul '23

13 Jul '23

Hi, Playing with openldap 2.5 auditlog. Logging to a file works nicely. We wonder (as we use graylog for syslog aggregation for all (LDAP) servers) ... Is it possible to process the auditlogs through syslog? Tip for all: we have solved so many problems just by searching through graylog... if you don't use graylog (or some other log aggregation tool)... consider implementing it!

3 2

RE: [EXT] Re: CSN too old on each MOD, on working 4-node multi-master
by Quanah Gibson-Mount 12 Jul '23

12 Jul '23

--On Wednesday, July 12, 2023 2:13 PM +0000 "Windl, Ulrich" <u.windl(a)ukr.de> wrote: > Hi! > > I always wondered (assuming you have four MM servers A-D): > Assuming A has a local change, so it will sent them to B-D > When B receives a change from A, it will "check and perform", then > sending the changes to C and D (not back to A, right?) Likewise for C > and D > However B-D will send out more changes, but not to A (right?): > B->C, B->D > C->B, C->D > D->B, D->C > What will B (and C and D) do when receiving A's change via C for the > second time: Will it ignore the change, but still send out to other > (non-originating) nodes, or will it just "swallow" the change? I guess > it will "swallow", because otherwise the messages would circulate > forever, right? Correct, they discard ops they've already received. Which was the point of the log message referenced originally. --Quanah

1 0

LTB packages available for OpenLDAP 2.5.15 and 2.6.5
by Clément OUDOT 12 Jul '23

12 Jul '23

Hello, for people interested, the LDAP Tool Box project has published the packages for OpenLDAP 2.5.15 and 2.6.5. https://projects.ow2.org/view/ldaptoolbox/ltb-openldap-2-5-15-and-2-6-5-pac… -- Clément Oudot | Identity Solutions Manager clement.oudot(a)worteks.com Worteks | https://www.worteks.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