openldap-technical

openldap-technical@openldap.org

12 participants
9794 discussions

Re: OpenLDAP 2.6.0 testing call
by Nick Folino 07 Sep '21

07 Sep '21

No issues on Fedora 34. Any docs on how to work with the new logging options? Nick On Tue, Sep 7, 2021 at 1:01 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > This is the first testing call for OpenLDAP 2.6.0 Release. Depending on > the results, this may be the only testing call. > > Generally, get the code for RE26: > > < > https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_6/o… > > > > Extract, configure, and build. > > Execute the test suite (via make test) after it is built. Optionally, cd > tests && make its to run through the regression suite. > > A list of items fixed and added in 2.6 can be found at: > > < > https://bugs.openldap.org/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFI… > > > > A major change with 2.6 is the ability to bypass syslog for logging > (ITS#6949). This significantly improves slapd performance. Currently > this > is being adjusted so that lloadd also supports this new feature, but it > can > be tested with slapd at this time. > > Additionally, the following deprecated backends have been removed: > > back-ndb > back-shell > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

Issue with building of back-perl
by bourguijl＠gmail.com 07 Sep '21

07 Sep '21

Dears, I try to compile 2.5.7 version with --enable-perl module but I get issue as following : First issue I get : In file included from init.c:18: perl_back.h:21:10: fatal error: EXTERN.h: No such file or directory #include <EXTERN.h> ^~~~~~~~~~ compilation terminated. make[3]: *** [Makefile:334: init.lo] Error 1 To solve above issue, I had to install a missing rehl package (perl-devel.x86_64) and set CPPFLAGS=-I/usr/lib64/perl5/CORE/ of the "configure utility". I did : Make distclean Configure Make depend make Then "make" goes further but now I get a lot of entries as below then it stopped : libtool: link: cc -g -O2 .libs/slapdS.o -o .libs/slapd main.o globals.o bconfig.o config.o daemon.o connection.o search.o filter.o add.o cr.o attr.o entry.o backend.o backends.o result.o operation.o dn.o compare.o modify.o delete.o modrdn.o ch_malloc.o value.o ava.o bind.o unbind.o abandon.o filterentry.o phonetic.o acl.o str2filter.o aclparse.o init.o user.o lock.o controls.o extended.o passwd.o proxyp.o schema.o schema_check.o schema_init.o schema_prep.o schemaparse.o ad.o at.o mr.o syntax.o oc.o saslauthz.o oidm.o starttls.o index.o sets.o referral.o root_dse.o sasl.o module.o mra.o mods.o sl_malloc.o zn_malloc.o limits.o operational.o matchedValues.o cancel.o syncrepl.o backglue.o backover.o ctxcsn.o ldapsync.o frontend.o slapadd.o slapcat.o slapcommon.o slapdn.o slapindex.o slappasswd.o slaptest.o slapauth.o slapacl.o component.o aci.o txn.o slapschema.o slapmodify.o version.o -pthread -Wl,--export-dynamic libbackends.a liboverlays.a ../../libraries/liblunicode/liblunicode.a ../../libraries/librewrite/librewrite.a ../../libraries/liblutil/liblutil.a ../../libraries/libldap/.libs/libldap.so /usr/app/LDAP/binaries/openldap-2.5.7/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so -lltdl -lresolv -pthread -Wl,-rpath -Wl,/usr/app/LDAP/binaries/openldap-2.5.7/lib libbackends.a(perlinit.o): In function `perl_back_xs_init': /usr/app/LDAP/binaries/openldap-2.5.7/servers/slapd/back-perl/init.c:166: undefined reference to `boot_DynaLoader' libbackends.a(perlinit.o): In function `perl_back_db_open': /usr/app/LDAP/binaries/openldap-2.5.7/servers/slapd/back-perl/init.c:135: undefined reference to `Perl_push_scope' /usr/app/LDAP/binaries/openldap-2.5.7/servers/slapd/back-perl/init.c:135: undefined reference to `Perl_savetmps' /usr/app/LDAP/binaries/openldap-2.5.7/servers/slapd/back-perl/init.c:142: undefined reference to `Perl_call_method' /usr/app/LDAP/binaries/openldap-2.5.7/servers/slapd/back-perl/init.c:152: undefined reference to `Perl_pop_scope' /usr/app/LDAP/binaries/openldap-2.5.7/servers/slapd/back-perl/init.c:150: undefined reference to `Perl_sv_2iv_flags' /usr/app/LDAP/binaries/openldap-2.5.7/servers/slapd/back-perl/init.c:152: undefined reference to `Perl_free_tmps' /usr/app/LDAP/binaries/openldap-2.5.7/servers/slapd/back-perl/init.c:137: undefined reference to `Perl_markstack_grow' /usr/app/LDAP/binaries/openldap-2.5.7/servers/slapd/back-perl/init.c:138: undefined reference to `Perl_stack_grow' /usr/app/LDAP/binaries/openldap-2.5.7/servers/slapd/back-perl/init.c:147: undefined reference to `Perl_croak_nocontext' libbackends.a(perlinit.o): In function `perl_back_initialize': /usr/app/LDAP/binaries/openldap-2.5.7/servers/slapd/back-perl/init.c:91: undefined reference to `Perl_sys_init3' /usr/app/LDAP/binaries/openldap-2.5.7/servers/slapd/back-perl/delete.c:28: undefined reference to `Perl_croak_nocontext' collect2: error: ld returned 1 exit status make[2]: *** [Makefile:527: slapd] Error 1 make[2]: Leaving directory '/usr/app/LDAP/binaries/openldap-2.5.7/servers/slapd' make[1]: *** [Makefile:300: all-common] Error 1 make[1]: Leaving directory '/usr/app/LDAP/binaries/openldap-2.5.7/servers' make: *** [Makefile:321: all-common] Error 1 Here is my configure command which works fine without “—enable-perl” : ./configure --prefix=/usr/app/LDAP/binaries/openldap-2.5.7/ --sysconfdir=/usr/app/LDAP/binaries/openldap-2.5.7 --mandir=/usr/local/share/man --enable-modules --enable-ldap --enable-dynlist --enable-ppolicy --enable-unique --with-gnu-ld --enable-refint --with-tls --enable-dynamic --enable-valsort --enable-rwm --enable-perl Any idea of what's the issue ? THx, Jean-Luc.

2 3

Can expensive write-related ACL checks somehow be avoided when a client only wants to read?
by haraldme＠gmail.com 06 Sep '21

06 Sep '21

Hi, we’re trying to (re-)implement some rather complicated ACLs, and are running into performance troubles. Thing is, the ACLs are only (or at least mostly) complicated in the “I want to update stuff” case; read access is relatively straightforward. For example, we have some group entries with lots of members, and want any authenticated user to be allowed to read those - but to update a group, you’ll have to both be in the “write allowed set" for the group and for the entries of the member DNs you’re touching. You’re in the “write allowed set” of an entry if 1) you’re a ‘member' of the group who is ‘manager’ for the entry, 2) as 1, but allow recursive groups, 3) you’re a ‘member’ of the group who is ‘manager’ for the entry’s ‘owner’, 4) as 3, but allow recursive groups, 5) as 3-4, but also allow recursive ‘owner’, or 6) if neither the entry nor any of its recursive owners has any ‘manager’ (and you have the “allow writes to unprotected entries” general access). This is implemented as ACLs akin to this: access to dn.subtree=“$our_root" attrs=@ourDistinguishedNameAttrs val.regex="^(.+)$$" by set.expand="( [${v1}]/manager*/member* | [${v1}]/manager* ) & user" break by set.expand="[${v1}]/manager" read stop by set.expand="[${v1}]/owner*/manager*/member* & user" break by set.expand="[${v1}]/owner*/manager" read stop by set.expand="[${v1}]/objectClass" break by * -a continue by * +z break … which /works/, but performs rather badly when someone e.g. tries to read a group with hundreds of ‘member’ attributes. Is there some feature I’m missing, or some way we can organize the ACLs, so that LDAP operations that only need read access won’t have to do the expensive write-protection checks? Best regards -- Harald Meland

1 0

In LMDB the maximum number of pages is less than the sum of free and used pages?
by Дилян Палаузов 05 Sep '21

05 Sep '21

Hello, I want to monitor the MDB storage for being too full, and enlarge it manually if necessary. https://ltb-project.org/documentation/nagios-plugins/check_lmdb_usage can do such monitoring. It calls mdb_stat -fe , parses the lines Max pages: 2560 Number of pages used: 2559 Free pages: 54 extracts the numbers and calculates either the percent ($pages_used / $max_pages * 100) or ($pages_free / $max_pages * 100 ) As can be seen in this expamle, the maximum number of pages is less than the sum of free and used pages. Shall the database be enlarged, when ($pages_used / $max_pages * 100) gets too high, or when ($pages_free / $max_pages * 100 ) gets too low? Greetings Дилян

1 0

LMDB: Ask for help with debugging MDB_MAP_FULL
by libor.peltan＠nic.cz 02 Sep '21

02 Sep '21

Hi, I'm struggling with an issue that a large, but mostly free LMDB database is claiming MDB_MAP_FULL when trying to store a large write transaction. The LMDB mapsize is configured to 40 GiB and indeed, the database (data.mdb) already has this size. Thus, it cannot grow. mdb_stat says: Status of Main DB Tree depth: 3 Branch pages: 24 Leaf pages: 1123 Overflow pages: 152153 Entries: 27423 Computing [ (branch + leaf + overflow) * page_size ] (I assume page_size is 4 KiB) leads to only ~600 MiB of the real database usage, which corresponds to the estimated amount of data stored there. So the database is used by just 1.5% and ought to have plenty free space inside. The write attempt that fails, tries to insert 700 MiB more data in one transaction, still just small percentage of the mapsize. However, this fails with MDB_MAP_FULL. Note that our application stores such large data in the way that it splits them into small chunks (~70 KiB each) and stores them as many key-value records. This is done to avoid issues with searching for too large continuous free space. I have tracked down one such failing write attempt with gdb to see what exactly fails: #0 mdb_page_alloc (mc=0x7fffd7e9fa08, num=8, mp=0x7fffd7e9f518) at contrib/lmdb/mdb.c:2286 #1 0x00000000004e2cf6 in mdb_page_new (mc=0x7fffd7e9fa08, flags=4, num=8, mp=0x7fffd7e9f578) at contrib/lmdb/mdb.c:7178 #2 0x00000000004e6108 in mdb_node_add (mc=0x7fffd7e9fa08, indx=98, key=0x7fffd7e9fc08, data=0x7fffd7e9fc20, pgno=0, flags=65536) at contrib/lmdb/mdb.c:7320 #3 0x00000000004de628 in mdb_cursor_put (mc=0x7fffd7e9fa08, key=0x7fffd7e9fc08, data=0x7fffd7e9fc20, flags=65536) at contrib/lmdb/mdb.c:6947 #4 0x00000000004e830a in mdb_put (txn=0x7fffd000cd80, dbi=1, key=0x7fffd7e9fc08, data=0x7fffd7e9fc20, flags=65536) at contrib/lmdb/mdb.c:9022 It shows an unsuccessful attempt to allocate 8 pages (interestingly, quite a little amount, since it had allocated a lot of 20-paged chunks just before). Tracking down the LMDB source code I found this interesting line: https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblmdb/… Unfortunately, I have not enough insight to understand mdb_page_alloc() in its complexity, but this seems like a kind of heurstics. It limits the number of scanned fragments of free space (for unknown reason). In the past, it has also been "tuned": https://git.openldap.org/openldap/openldap/-/commit/5ee99f1125a775f28ed69b0… I tried to patch my copy of LMDB source code by doubling this magic constant (60 -> 120), and voila, this particular write transaction succeeded afterwards. However, this is obvoiusly no sustainable way of sorting this out. What is interesting to me is that the number of retries relies only on the size of the allocated chunk (number of pages to alloc), but not the mapsize. It seems possible to me that in a huge database, there might probably be a lot of tiny (e.g. one-page) fragments of free space, that need to be skipped before finding any large-enough one. However, I don't yet dare to create an issue on this. Could you please tell me if my thoughts lead some proper, or some wrong way? Does LMDB need some improvement to avoid this (and similar) issues? Do you think that chunking the large data to even smaller parts (70 KiB -> 3 KiB) by our application could be more clever to reduce fragmentation of overflow-pages-space in LMDB? Thank you for any hints and more insight to LMDB internals. Many cheers, Libor Knot DNS | CZ NIC

1 0

Support for member;range=0-1499
by shekhar.shrinivasan＠gmail.com 01 Sep '21

01 Sep '21

Hi, Does openLDAP support searching with "member;range=0-1499" ? We have a back_meta configured in front of AD and when we try to search for a group having more than 1500 members using the following filter - ldapsearch -LLL -h <hostname> -p <port> -D <user dn> -w -s sub -b <basedn> '(cn=<group-dn>)' 'member;range=0-1499' we get the error as seen below - slap_bv2undef_ad(member;range=0-1499): AttributeDescription contains inappropriate characters. Any pointers ? Thanks for your help !

2 2

migrate from slapo-memberof to slapo-dynlist
by Michael Ströder 31 Aug '21

31 Aug '21

HI! It's easy to change the config of OpenLDAP 2.5 from "overlay memberof" to "overlay dynlist" and it just works. Nice. :-) But the existing database then still contains the 'memberOf' attribute values. Ideally one should reload the database. But if anything fails: Does it do any harm if 'memberOf' attribute values are still present in the database but slapo-dynlist is supposed to compute 'memberOf' attribute values based on recently changed group membership? At the end I will instruct the admins to reload databases especially to also save space. But it would be less operational stress if I could decouple the config change from the database re-load. Ciao, Michael.

2 3

Re: 2.5.7 - adding memberof module Duplicate attributeType
by Saša-Stjepan Bakša 30 Aug '21

30 Aug '21

On Mon, 30 Aug 2021 at 19:33, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > > @Dave Macias Can you share the structure of your groups? > > member/memberOf depend on LDAP groups, not unix groups, which are based on > DNs. > > Example groups objectClasses are: > > groupOfNames (core schema) > groupOfUniqueNames (core schema) > groupOfMembers (rfc2307bis schema) > > > Of these three, I would recommend either groupOfNames or groupOfMembers > > Thank you Quanah! I will try them as you suggested. br Saša

1 0

Re: 2.5.7 - adding memberof module Duplicate attributeType
by Quanah Gibson-Mount 30 Aug '21

30 Aug '21

--On Monday, August 30, 2021 8:26 PM +0200 Saša-Stjepan Bakša <ssbaksa(a)gmail.com> wrote: > --On Monday, August 30, 2021 11:14 AM +0200 Saša-Stjepan Bakša > <ssbaksa(a)gmail.com> wrote: > >> I have similar situation and also a replicated environment. I am using >> posixGroup only and never had any need for a memberOf attribute. >> But now, my devs have a software which insists on that attribute so I >> should provide it for them. > > posixGroup is not a valid objectClass to use with providing memberOf > information. > > --Quanah > > > > > > Ouch! I have 51 different posixGroup groups which have been in use for > more than 10 years and now because of one > piece of software I must change the way I manage them all. Not happy at > all. > > > What is your suggestion Quanah? Can I just add an object? It would be a > problem if I must change all services. > Or maybe just add a few new groups of different types for that software. > That will be great if it is appropriate. > > > > @Dave Macias Can you share the structure of your groups? member/memberOf depend on LDAP groups, not unix groups, which are based on DNs. Example groups objectClasses are: groupOfNames (core schema) groupOfUniqueNames (core schema) groupOfMembers (rfc2307bis schema) Of these three, I would recommend either groupOfNames or groupOfMembers 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: OpenLDAP 2.5.7 dies
by kevin martin 30 Aug '21

30 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9656 --- Regards, Kevin Martin On Mon, Aug 30, 2021 at 10:01 AM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Monday, August 30, 2021 10:41 AM -0500 kevin martin <ktmdms(a)gmail.com> > > wrote: > > > > > > > issue handled. missing pwdCheckModuleArg in the password policy > > (apparently not using ppm.conf anymore). once added to the schema the > > password change works. > > This still should not cause slapd to crash. Please file a bug at > https://bugs.openldap.org with the reproduction steps. Thanks! > > Regards, > 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