Re: el9 bind ip address
Marc wrote: > Anyone know if this file is still working in el9? Looks like if I put > SLAPD_URLS it is not read. > > /etc/sysconfig/slapd > That's a question for Red Hat. No one on the OpenLDAP Project has anything to do with that. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Storage overhead of LMDB vs SQLite3 for file hierarchy indexing scenario
used 3701 > Overflow pages used... 0 > Total pages used.. 3735 > Unused bytes on index pages... 16998 12.2% > Unused bytes on primary pages. 1500963 9.9% > Unused bytes on overflow pages 0 > Unused bytes on all pages. 1517961 9.9% Looks like SQLite3 uses a much higher page fill factor than textbook B+trees. Normally for a random-insert case, pages are split when they're full, leaving you two pages at about 50% utilization each. So on average a B+tree's pages would be 75% full, with only 25% unused bytes. This is what LMDB does for random inserts. > LMDB: depth=3 branch_pages=66 leaf_pages=6021 overflow_pages=0 > Keyssize: 9495640 > Values size: 2261081 > Payload size: 11756721 > Pages size: 24932352 > Average key size: 20.000 (20-20) > Average value size:4.762 (1-5) > Average entry size: 24.762 > Entries number: 474782 > Overhead: 13175631 > Overhead/payload ratio: 1.121 > Overhead/entry avg: 27.751 > > I checked the overhead for in-order insertions and it's still around > 50% for this key/value sizes, much more than SQLite does (~21%) for > random insertions. > > But even if we were to remove this index, SQLite's file would still be > tighter... > > > That's it! > > > Best regards, > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: How to properly monitor MDB usage
Clément OUDOT wrote: > > Le 07/05/2024 à 17:07, Benjamin Renard a écrit : >> Hi, >> >> I'm looking for the right method to monitor the usage of an MDB database >> according to the limit of its size imposed via the parameter olcDbMaxSize. >> Currently, >> I am using the following command: >> >> # mdb_stat -e /var/lib/ldap/accesslog/ >> Environment Info >> Map address: (nil) >> Map size: 4294967296 >> Page size: 4096 >> Max pages: 1048576 >> Number of pages used: 1048572 >> Last transaction ID: 24153425 >> Max readers: 126 >> Number of readers used: 18 >> Status of Main DB >> Tree depth: 1 >> Branch pages: 0 >> Leaf pages: 1 >> Overflow pages: 0 >> Entries: 6 >> >> Here, I determine the percentage of database usage with the information >> "Number of pages used" and "Max pages". >> >> This seemed to be a good method, but I noticed that after a significant >> purge of objects in the directory, the number of used pages does not seem to >> decrease. You also need to account for the freelist. Use `mdb_stat -ef`. >> >> Is there another and/or better method to monitor this? Failing that, is >> there a solution to release "falsely" used pages, ideally without too much >> downtime of >> the service (so not a dump/restore)? I read that it was possible to use the >> "mdb_copy -c" command, but I am a little concerned about the duration on a >> database with approximately 1,000,000 entries. There is no reason to release free pages. They will get reused again anyway. > Hello Benjamin, > > if it helps, we have created a monitoring script for this: > https://ltb-project.org/documentation/check_lmdb_usage.html > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Need information related to multi thread support in OpenLDAP c sdk client
c.venugopal...@gmail.com wrote: > Hi Team, > > We are working on migration of nsldap C sdk to OpenLDAP c sdk for our > application client code. As part of this activity, replacing API one by one > and also looking for constant replacement. > > In NSLDAP C SDK: > /* > * Thread function callbacks (an API extension -- > * LDAP_API_FEATURE_X_THREAD_FUNCTIONS). > */ > #define LDAP_OPT_THREAD_FN_PTRS 0x05/* 5 - API extension */ > nsldap c sdk has thread function pointers option to support multi thread > functionality for client programs. In our existing code, we are using > 'LDAP_OPT_THREAD_FN_PTRS' option with ldap_set_option API like "Client code > usage: ldap_set_option(hLDAP, LDAP_OPT_THREAD_FN_PTRS, );". > > Now, we are looking for similar functionality with in OpenLDAP to use it in > our client program. Gone through OpenLDAP document and source code, but with > my knowledge, did not get any equivalent one. > > Could you please provide more details on this to achieve equivalent > functionality of LDAP_OPT_THREAD_FN_PTRS with OpenLDAP? No such feature exists; OpenLDAP libldap uses the underlying platform's native thread API. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Replication Questions
Erik de Waard wrote: > As taken from elsewhere on this list: > > The primary issue is that if a server goes into REFRESH mode, the order in > which the entries are sent back may not allow the slapo-memberOf overlay to > rebuild > the groups correctly. > > Details: > https://bugs.openldap.org/show_bug.cgi?id=8613 See https://bugs.openldap.org/show_bug.cgi?id=10167 that restriction has been eliminated. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: timeout and network-timeout values of zero for syncrepl in LAN replication
Christopher Paul wrote: > On 4/17/2024 11:24 PM, Howard Chu wrote: >> timeout has nothing to do with the duration of an operation. > > I'm confused then. Manual page ldap.conf(5) states: > > TIMEOUT > Specifies a timeout (in seconds) after which calls to > synchronous LDAP APIs will abort if no response is received. Also used for > any > ldap_result(3) calls where a NULL timeout parameter is supplied. > > The duration of an operation is the call to the LDAP API plus the time it > takes for the response/result, no? What am I missing here? The manpage language is precise. Your paraphrase is not. An LDAP operation may have more than one response. Search operations often do, extended ops may as well. The timeout is waiting for any response, not just the operation result. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: timeout and network-timeout values of zero for syncrepl in LAN replication
Christopher Paul wrote: > Concerning the "timeout" parameter, the ideal range might be between 60 to > 120 seconds, to handle operations exceeding a minute, but again, kicking in > retry > logic if they exceed two minutes. I admit that my stance on the "timeout" > setting is tentative, given that search operation duration hinges more on the > provider's responsiveness rather than network speed alone. timeout has nothing to do with the duration of an operation. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Strange search result in logs
Quanah Gibson-Mount wrote: > > > --On Wednesday, March 27, 2024 11:28 AM +0100 Frédéric Goudal > wrote: > >> Hello, >> >> I'm trying to analyse the requests done to my ldapserver from a nas. >> While browsing the logs I found the following entries : >> >> I have no specific ACL on the ip quering. > > > Do you have any "limits" directives in your configuration? He should instead check for a sizelimit being set by the client. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Help debugging slave slapd issues
BECOT Jérôme wrote: > Thank you for the help. We will look at the clients. I fear sssd would be the > culprit, but we have to investigate first. There's really nothing that needs to be done here. The deferred operations will eventually get processed. > > *De :* Howard Chu > *Envoyé :* lundi 25 mars 2024 20:52 > *À :* Quanah Gibson-Mount ; Christopher Paul > ; BECOT Jérôme ; > openldap-technical > > *Objet :* Re: Help debugging slave slapd issues > > [Vous ne recevez pas souvent de courriers de h...@symas.com. Découvrez > pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ] > > ATTENTION : Cet e-mail provient de l'extérieur de l'organisation. Ne cliquez > pas sur les liens et n'ouvrez pas les pièces jointes à moins que vous ne > reconnaissiez l'expéditeur et que vous sachiez que le contenu est sûr. > > Quanah Gibson-Mount wrote: >> >> >> --On Monday, March 25, 2024 6:06 PM + Christopher Paul >> wrote: >> >>>> Those aren't errors. >>> >>> But a deferral is not optimal, is it? I think the question "hints about >>> way to debug" is probably a good one. The brute force method to fix this >>> would be to add consumers and spread out the load. Horizontal scaling is >>> the main benefit of a replicated architecture. > >>>> slapd[37277]: connection_input: conn=32974 deferring operation: too many >>>> executing > >> Deferrals are common, they are not necessarily indicative of an issue, and >> without more detail there's no way to determine there is an issue that needs >> to be >> addressed or not. > > Yes, they're common, and these are caused by a client sending too many > operations over > a connection without waiting for them to complete. In other words, a poorly > written > client. > > Simply adding more replicas does nothing to address this, you need a load > balancer that > spreads all client queries out, even when they're all coming in from a single > connection. > > Better yet is to identify the client and fix it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Help debugging slave slapd issues
Quanah Gibson-Mount wrote: > > > --On Monday, March 25, 2024 6:06 PM + Christopher Paul > wrote: > >>> Those aren't errors. >> >> But a deferral is not optimal, is it? I think the question "hints about >> way to debug" is probably a good one. The brute force method to fix this >> would be to add consumers and spread out the load. Horizontal scaling is >> the main benefit of a replicated architecture. >>> slapd[37277]: connection_input: conn=32974 deferring operation: too many >>> executing > Deferrals are common, they are not necessarily indicative of an issue, and > without more detail there's no way to determine there is an issue that needs > to be > addressed or not. Yes, they're common, and these are caused by a client sending too many operations over a connection without waiting for them to complete. In other words, a poorly written client. Simply adding more replicas does nothing to address this, you need a load balancer that spreads all client queries out, even when they're all coming in from a single connection. Better yet is to identify the client and fix it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Logo usage
Gloria Semme wrote: > Dear OpenLDAP Technical Team, > > I am reaching out to seek your guidance and permission regarding the use of > the OpenLDAP logo. My team is in the process of creating a Grafana integration > designed to facilitate the monitoring of OpenLDAP applications for our users. > To enhance user experience and direct attention effectively, we plan to > incorporate the OpenLDAP logo within the Grafana Cloud interface. > > Upon reviewing the available licensing information, we noted the absence of > specific guidelines related to the use of the OpenLDAP logo. Given this, we > wish to > ensure our use aligns with your expectations and policies. Our design > considerations include adjusting the logo to fit a square format to suit the > dashboard's > aesthetic. We are committed to respecting your branding guidelines and are > open to any alternative suggestions or requirements you may have. You are free to use any of the logos shown here under the cited terms: https://openldap.org/project/powered.html > > We appreciate your support in this endeavor and look forward to your guidance. > > Thank you for your guidance. > > Best regards, > > > -- > photo > *Gloria Semme* > Sr. Engineering Manager > Cloud Infrastructure Observability > gloria.se...@grafana.com <mailto:gloria.se...@grafana.com> > > www.grafana.com <http://www.grafana.com/> > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Lock conflicts?
rzho...@tutamail.com wrote: > Thanks, this is what I feared. > > Does LMDB have some ways to "lock the environment" (while still keeping > MDB_NOLOCK)? MDB_NOLOCK means *none* of LMDB's locking code is used. > This might allow me to modify that other program to "lock the environment" > while it access the LMDB file. > > With "lock the environment" I mean, blocking access for other processes. > Something similar to MDBX_EXCLUSIVE/MDBX_BUSY in libmdbx. > > (By the way, what reputation does libmdbx have in this forum? It claims to > "improve" on LMDB but I thought I'd check here first... that project seems > unmaintained for 2 years.) > > - Zhou > > Mar 11, 2024, 15:07 by h...@symas.com: > > rzho...@tutamail.com wrote: > > At work we have a program that actively reads/writes into LMDB file. > This program uses MDB_NOLOCK (why, I'm not sure yet). > > Can I safely read/write to this LMDB file using my own programs or > mdb_ command line tools? > > > No. > > I worry that those (which by default use lock files) could conflict > with the manual locking of the existing program and cause data > corruptions. > > > You would have to use exactly the same locking code as the other program > uses. And the mdb_ command > line tools don't support any other locking methods. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Lock conflicts?
rzho...@tutamail.com wrote: > At work we have a program that actively reads/writes into LMDB file. This > program uses MDB_NOLOCK (why, I'm not sure yet). > > Can I safely read/write to this LMDB file using my own programs or mdb_ > command line tools? No. > I worry that those (which by default use lock files) could conflict > with the manual locking of the existing program and cause data corruptions. You would have to use exactly the same locking code as the other program uses. And the mdb_ command line tools don't support any other locking methods. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: LMDB fix sized key and data question
an...@pcloud.com wrote: > Hello, > > I'm designing an application that will use LMDB. All (or almost all) of my > databases will have a fixed size integer key (64bit) and fixed size data. > Data is larger than a single integer but generally in 16-32 bytes range > (range is for different databases, each database has a fixed data format). > > I'll not have duplicate key records. I'll mostly insert and retrieve single > records. The question is would I benefit and should I use > MDB_DUPSORT|MDB_DUPFIXED? Also the documentation says that MDB_DUPFIXED may > only be used with MDB_DUPSORT. However I see code that specifically checks > for MDB_DUPFIXED without MDB_DUPSORT and only then sets a flag for DUPFIXED > records. However I did not get too deep in the code. The documentation doesn't lie. > https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#L7743 > > My point is that with fixed sized keys and values the btree may chose not to > store record sizes, may not use pointers for the binary search but to search > values instead and so on. Is that the optimization that is being done for > MDB_DUPFIXED or is it something that only concerns duplicate values? Yes, with DUPFIXED the record sizes don't need to be stored per record, so you'll get some space and performance benefits from it. In other projects, where we don't actually need duplicate keys but we still want to use DUPFIXED, we just use a dummy key (e.g. 64bit zero) and concatenate the real key & value into the LMDB value. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Counter concurrency access
Howard Chu wrote: > Pascal Jakobi wrote: >> Hi there >> >> I am creating a program that needs to increment a counter. Typically a >> serial number has to be incremented every time I create a certificate. >> >> The problem is to handle concurrent access. Fundamentally I need to 1/ read >> the counter 2/ increment it. Therefore no one must be provided access to the >> counter >> during these two operations. >> >> Therefore I need to set a lock before the read operation and release it >> after the update. Is there a way to do this with OL ? I am conscious of the >> ldapmodify >> features thanks to Clement, however, this will not lock the read. > > You don't need to do any locking, just use the ldapmodify Increment operator > and the value will be incremented atomically. > On re-reading, I see - you want to read the value and then separately do an increment on it. In that case you just read the value, then do an ldapmodify with delete: current value - add: new value - Then the op will only succeed if the value hasn't changed yet. If the value changed, someone else got in there between your read and your modify, and you'll have to retry the entire sequence until it succeeds. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Counter concurrency access
Pascal Jakobi wrote: > Hi there > > I am creating a program that needs to increment a counter. Typically a serial > number has to be incremented every time I create a certificate. > > The problem is to handle concurrent access. Fundamentally I need to 1/ read > the counter 2/ increment it. Therefore no one must be provided access to the > counter > during these two operations. > > Therefore I need to set a lock before the read operation and release it after > the update. Is there a way to do this with OL ? I am conscious of the > ldapmodify > features thanks to Clement, however, this will not lock the read. You don't need to do any locking, just use the ldapmodify Increment operator and the value will be incremented atomically. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP SQL
kimkihoon wrote: > I'm trying to use mysql external db server for openLDAP db. > I just read this README file from openldap > github(https://github.com/openldap/openldap/blob/master/servers/slapd/back-sql/rdbms_depend/README) > But it seems only localhost server can be used. > Can anyone tell me how? Examples in documentation are only examples, nothing more. You can use any valid ODBC configuration but nobody has time to write every possible config value and use case out. Use your brain and try things yourself. > Thx for the help > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: slapo-translucent bug?
> homeDirectory: /home/ciccio
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
>
>
> So far, everything is okay, no anomalous behavior. The issue arises when a
> filter is introduced.
>
> 2) Querying servers with a filter
>
> ---
> Server "upstream"
> ---
> % ldapsearch -x -H ldap://:51389 -b ou=people,dc=example,dc=com uid=ciccio
> uidNumber
> # extended LDIF
> #
> # LDAPv3
> # base with scope subtree
> # filter: uid=ciccio
> # requesting: uidNumber
> #
>
> # ciccio, people, example.com
> dn: uid=ciccio,ou=people,dc=example,dc=com
> uidNumber: 1000
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
> ---
> Translucent server "buggy" (!!)
> ---
> % ldapsearch -x -H ldap://:52389 -b ou=people,dc=example,dc=com uid=ciccio
> uidNumber
> # extended LDIF
> #
> # LDAPv3
> # base with scope subtree
> # filter: uid=ciccio
> # requesting: uidNumber
> #
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 1
>
> ---
> Translucent server "compiled"
> ---
> % ldapsearch -x -H ldap://:53389 -b ou=people,dc=example,dc=com uid=ciccio
> uidNumber
> # extended LDIF
> #
> # LDAPv3
> # base with scope subtree
> # filter: uid=ciccio
> # requesting: uidNumber
> #
>
> # ciccio, people, example.com
> dn: uid=ciccio,ou=people,dc=example,dc=com
> uidNumber: 99
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
>
> Why does this behavior occur? I expect the "buggy" server to return the
> uidNumber attribute. The version of OpenLDAP in the container is the one
> installed with the Fedora package manager.
>
> Server configurations are available in the Git repository, but for
> convenience, I am listing them here:
>
> upstream:
> https://github.com/voidloop/openldap-bug/blob/main/upstream/slapd.ldif
> https://github.com/voidloop/openldap-bug/blob/main/upstream/entries.ldif
>
> buggy:
> https://github.com/voidloop/openldap-bug/blob/main/buggy/slapd.ldif
>
> compiled:
> https://github.com/voidloop/openldap-bug/blob/main/compiled/slapd.ldif
>
> The source code modification is as follows:
>
> % diff openldap/servers/slapd/overlays/translucent.c translucent.c -u
> --- openldap/servers/slapd/overlays/translucent.c 2024-02-29
> 11:30:52.620837844 +0100
> +++ translucent.c 2024-02-29 11:14:11.274843929 +0100
> @@ -928,16 +928,7 @@
> /* send it now */
> rs->sr_entry = re;
> rs->sr_flags |= REP_ENTRY_MUSTBEFREED;
> - if ( test_f ) {
> - rc = test_filter( op, rs->sr_entry,
> tc->orig );
> - if ( rc == LDAP_COMPARE_TRUE ) {
> - rc = SLAP_CB_CONTINUE;
> - } else {
> - rc = 0;
> - }
> - } else {
> - rc = SLAP_CB_CONTINUE;
> - }
> + rc = SLAP_CB_CONTINUE;
> }
> } else if ( le ) {
> /* Only a local entry: remote was deleted
>
> I have also found posts from individuals who have identified the same issue,
> but either received no response or the response was unsatisfactory:
>
> https://openldap.org/lists/openldap-technical/201304/msg00069.html
> https://www.openldap.org/lists/openldap-bugs/200905/msg00159.html
> https://www.openldap.org/lists/openldap-technical/201106/msg00036.html
>
> Thank you for your attention, and I apologize for the lengthy message.
>
> Marco
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: olcLimits and groupOfURLs dynlist
Norman Gray wrote: > > Howard, hello. > > On 8 Feb 2024, at 15:07, Howard Chu wrote: > >>> Norman Gray wrote: >>> >>> Howard, hello. >>> >>> On 8 Feb 2024, at 0:34, Howard Chu wrote: >>> >>>> 65c3df21.21fc2a30 0x16cacf000 >>>> ldap_url_parse_ext(ldap:///ou=groups,o=example?member?sub?(|(cn=ldap-admins-*)(cn=ldap-techs))) >>>> >>>> The above URL is not valid for a dynamic group. The attrs portion of the >>>> URL must be empty. >>>> >>>> Since it's invalid, after it is parsed it gets ignored. >>> >>> That's true when constructing what slapo-dynlist(5) calls a dynamic >>> group, but that's not what I'm constructing here, but instead a group >>> entry which is dynamically expanded, to a group, by a search. >> >> Whatever you've constructed is not a dynamic group, as defined in >> slapo-dynlist. >> As such, it is not supported for the purpose you're asking. > > Indeed -- it's not a 'dynamic group' in the terms of slapo-dynlist, but it is > an entry which has a set of 'member' attributes, which is dynamically > constructed (whatever one wants to call this). > > But I can't see that matters, since the slapd-config(5) text covering the > olcLimits configuration attribute seems to clearly indicate that > > olcLimits: > group/groupOfURLs/member="cn=ldap-operators,ou=groups,o=example" size=2 > > 'sets the limits for any DN listed in the values of the [member] attribute of > the [groupOfURLs] group whose DN exactly matches > ["cn=ldap-operators,ou=groups,o=example"]' (where [...] fills in the blanks > in the text there as I understand it). I can't see a way of interpreting > this manpage text which doesn't match this situation. This works as expected > when cn=ldap-operators is an entry which is not dynamically expanded. > > It doesn't say that that group has to be a 'dynamic group in the terms of > slapo-dynlist', it just says 'group'. > > And slapo-dynlist says: > >> Any time an entry with a specific objectClass is being returned, >> the LDAP URI-valued occurrences of a specific attribute are expanded >> into the corresponding entries, and the values of the attributes listed >> in the URI are added to the original entry. The text above is for a *dynamic list* - which is not a *dynamic group*. The code supports groups, not lists. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: olcLimits and groupOfURLs dynlist
Norman Gray wrote: > > Howard, hello. > > On 8 Feb 2024, at 0:34, Howard Chu wrote: > >>> 65c3df21.21fc2a30 0x16cacf000 >>> ldap_url_parse_ext(ldap:///ou=groups,o=example?member?sub?(|(cn=ldap-admins-*)(cn=ldap-techs))) >> >> The above URL is not valid for a dynamic group. The attrs portion of the URL >> must be empty. >> >> Since it's invalid, after it is parsed it gets ignored. > > That's true when constructing what slapo-dynlist(5) calls a dynamic > group, but that's not what I'm constructing here, but instead a group > entry which is dynamically expanded, to a group, by a search. Whatever you've constructed is not a dynamic group, as defined in slapo-dynlist. As such, it is not supported for the purpose you're asking. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: olcLimits and groupOfURLs dynlist
Norman Gray wrote:
>
> Howard, hello.
>
> On 7 Feb 2024, at 19:36, Howard Chu wrote:
>
>>> If I then make a query which has a few results, I do not get this limit
>>> imposed, and instead see in the logs
>>>
>>> 65c3ce83.0f52bea8 0x16e9d3000 => mdb_entry_get: found entry:
> "cn=ldap-operators,ou=groups,o=example"
>>> 65c3ce83.0f533f90 0x16e9d3000 <= mdb_entry_get: failed to find
>>> attribute member
>>
>> And those logs are correct, the group entry you specified has no member
>> attribute.
>> What it has is a memberURL attribute, and that's what you should have
>> configured
>> in your olcLimits statement.
>
> Aha. I had taken the description to refer to the synthesised 'member'
> attributes in the
> dynamically generated group. Thanks for this.
>
> On changing this, though, to
>
> olcLimits:
> group/groupOfURLs/memberURL="cn=ldap-operators,ou=groups,o=example" size=2
>
> and making a query, I now see in the logs (with -d-1):
>
> 65c3df21.21fa70c8 0x16cacf000 ==> limits_get: conn=1000 op=1
> self="uid=norman,ou=staff,o=example" this="o=example"
> 65c3df21.21fa97d8 0x16cacf000 => mdb_entry_get: ndn:
> "cn=ldap-operators,ou=groups,o=example"
> 65c3df21.21fab718 0x16cacf000 => mdb_entry_get: oc: "groupOfURLs", at:
> "memberURL"
> 65c3df21.21fb1ca8 0x16cacf000
> mdb_dn2entry("cn=ldap-operators,ou=groups,o=example")
> 65c3df21.21fb4b88 0x16cacf000 =>
> mdb_dn2id("cn=ldap-operators,ou=groups,o=example")
> 65c3df21.21fb8a08 0x16cacf000 <= mdb_dn2id: got id=0x2857
> 65c3df21.21fbb8e8 0x16cacf000 => mdb_entry_decode:
> 65c3df21.21fbd440 0x16cacf000 <= mdb_entry_decode
> 65c3df21.21fbef98 0x16cacf000 => mdb_entry_get: found entry:
> "cn=ldap-operators,ou=groups,o=example"
> 65c3df21.21fc0ed8 0x16cacf000 mdb_entry_get: rc=0
> 65c3df21.21fc2a30 0x16cacf000
> ldap_url_parse_ext(ldap:///ou=groups,o=example?member?sub?(|(cn=ldap-admins-*)(cn=ldap-techs)))
The above URL is not valid for a dynamic group. The attrs portion of the URL
must be empty.
Since it's invalid, after it is parsed it gets ignored.
> There's no mention of 'limits' after this point in the log.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: olcLimits and groupOfURLs dynlist
Norman Gray wrote: > > Greetings. > > I have another puzzle with my OpenLDAP configuration, where I'm not > sure if what I'm seeing is unexpected. > > Short version: should I expect a group in an olcLimits spec to work when the > group is dynamic? Yes. > I have a dynamic group set up, using the dynlist overlay, which > expands to a set of DNs which should be allowed slightly privileged > access to a directory. That group seems to be working OK: > > % ldapsearch -x -H ldap://localhost:8389 -b o=example -LLL > '(cn=ldap-operators)' > dn: cn=ldap-operators,ou=groups,o=example > cn: ldap-operators > objectClass: groupOfURLs > description: Members of all of the LDAP admin and tech groups > memberURL: > ldap:///ou=groups,o=example?member?sub?(|(cn=ldap-admins-*)(cn=ldap-techs)) > member: uid=norman,ou=staff,o=example > [...] > > One goal here is to remove query limits for this group. I can test > that by adding an artificially low limit: > > olcLimits: > group/groupOfURLs/member="cn=ldap-operators,ou=groups,o=example" size=2 > > If I then make a query which has a few results, I do not get this limit > imposed, and instead see in the logs > > 65c3ce83.0f52bea8 0x16e9d3000 => mdb_entry_get: found entry: > "cn=ldap-operators,ou=groups,o=example" > 65c3ce83.0f533f90 0x16e9d3000 <= mdb_entry_get: failed to find attribute > member And those logs are correct, the group entry you specified has no member attribute. What it has is a memberURL attribute, and that's what you should have configured in your olcLimits statement. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: LMDB cursor position
M Gurschi wrote: > Hello Howard, > > Tell me please, after *mdb_cursor_get(key, data, MDB_SET_RANGE)*, if i want > to consume the key, if i understand correctly the key will be updated (on > success). Will the reference to data also be updated or do i need to do: > *mdb_cursor_get(key, data, MDB_GET_CURRENT)* to get data to point at the data > from the key? That would be a useless behavior for the API if it required that, wouldn't it. > > Kind Regards, > Maxim Gurschi > > On 1 Feb 2024, at 20:21, M Gurschi wrote: > > Understood, thank you! > > Kind Regards, > Maxim Gurschi > > On 1 Feb 2024, at 17:53, Howard Chu wrote: > > M Gurschi wrote: >> Hello team, >> >> Can you please let me know, when using *mdb_cursor_get* with *MDB_SET* >> operation, in case the key is not present in the db, where is the cursor >> left pointing? >> >> My scenario is that i want to retrieve two adjacent keys. >> >> 1. first *mdb_cursor_get* with *MDB_SET* >> 2. after that, *mdb_cursor_get* with *MDB_NEXT* >> >> I'm wondering what can i expect the cursor to point at in case the key is >> not found in step 1. > > You cannot expect anything in particular. > > Use MDB_SET_RANGE instead. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: LMDB cursor position
M Gurschi wrote: > ...in addition, > > Can i rely that for both: > *mdb_cursor_get(key, data, MDB_SET_RANGE)* > and > *mdb_cursor_get(key, data, MDB_NEXT)* > > , if the call returns *MDB_NOTFOUND*, then the key i passed in the call will > be left unmodified? Of course. If the return code is NOTFOUND, there is nothing to return to you. > > Kind Regards, > Maxim Gurschi > > On 2 Feb 2024, at 11:23, M Gurschi wrote: > > Hello Howard, > > Tell me please, after *mdb_cursor_get(key, data, MDB_SET_RANGE)*, if i want > to consume the key, if i understand correctly the key will be updated (on > success). Will the reference to data also be updated or do i need to do: > *mdb_cursor_get(key, data, MDB_GET_CURRENT)* to get data to point at the data > from the key? > > Kind Regards, > Maxim Gurschi > > On 1 Feb 2024, at 20:21, M Gurschi wrote: > > Understood, thank you! > > Kind Regards, > Maxim Gurschi > > On 1 Feb 2024, at 17:53, Howard Chu wrote: > > M Gurschi wrote: >> Hello team, >> >> Can you please let me know, when using *mdb_cursor_get* with *MDB_SET* >> operation, in case the key is not present in the db, where is the cursor >> left pointing? >> >> My scenario is that i want to retrieve two adjacent keys. >> >> 1. first *mdb_cursor_get* with *MDB_SET* >> 2. after that, *mdb_cursor_get* with *MDB_NEXT* >> >> I'm wondering what can i expect the cursor to point at in case the key is >> not found in step 1. > > You cannot expect anything in particular. > > Use MDB_SET_RANGE instead. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: LMDB cursor position
M Gurschi wrote: > Hello team, > > Can you please let me know, when using *mdb_cursor_get* with *MDB_SET* > operation, in case the key is not present in the db, where is the cursor left > pointing? > > My scenario is that i want to retrieve two adjacent keys. > > 1. first *mdb_cursor_get* with *MDB_SET* > 2. after that, *mdb_cursor_get* with *MDB_NEXT* > > I'm wondering what can i expect the cursor to point at in case the key is not > found in step 1. You cannot expect anything in particular. Use MDB_SET_RANGE instead. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: UNKNOWN attributeDescription "..." inserted.
Bastian Tweddell wrote: > On 31Jan24 16:16+0000, Howard Chu wrote: >> File a bug against the totp module. If it is using this attribute, it >> should be registering it in the schema during module initialization. > > Do I understand correctly, that sbin/slapcat should also load initalize > all modules from slapd config? Yes, all the tools fully process the config. >>> - Is the removal of attribute definitions from the schema not >>> supported/suggested at all? >> >> Never recommended, no. If you're retiring a definition, just add OBSOLETE to >> it. > > Great! I'll revert the changes about that and will mark those attributes > obsolete. The OBSOLETE tag is not specified closer in manual. The RFC > says it is an indicator. I think, the tag is _just_ an meta data in the > schema and slapd will mostly ignore it, right? Right. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: UNKNOWN attributeDescription "..." inserted.
Bastian Tweddell wrote:
> Dear all,
>
> We are facing 'UNKNOWN attributeDescription' errors in our
> infrastructure, caused by two different reasons. I realized those only
> by using `slapcat` which prints the following error/warning message to
> STDERR:
> ```
> UNKNOWN attributeDescription "..." inserted.
> ```
> In both cases, this issue does not degrade the production of our system.
> All operations including syncreplication are working in normal
> parameter.
>
> Case A:
> In our production, a dedicated slapd syncrepl consumer has the totp
> module from contrib enabled and ldapbind calls against '{TOTP1}' are
> performed. This module introduces a new attribute "authTimestamp".
> IIUC, `slapcat` cannot know about this attribute, because it is
> not in the config. But attributes of that type are stored in the MDB.
> I'd like to ask:
> - How should we deal with this situation?
File a bug against the totp module. If it is using this attribute, it
should be registering it in the schema during module initialization.
> - Is it safe to continue as is or should we define the attribute
> "authTimestamp" in our schema extension as well?
It's mostly safe, unless you configured an index on authtimestamp and
needed to run slapindex on it.
> Case B:
> We are about to remove some attribute definitions from our schema
> extension. These are obsolete and not in use in the DB anymore. On the
> testbed slapd+syncrepl works as expected. But here as well, even though
> that the DB does not contain any of the obsolete attributes in any
> entry, `slapcat` throws the same error/warning for all removed
> attributes from the schema file.
> My first approach was to re-index the database (even with truncate
> mode), which did not solve the situation. Stopping the consumer slapd,
> removing the mdb files and restarting the syncrepl solves it. But on
> production I would not want to do re-sync everything unnecessarily (it
> would be possible though).
> I'd like to ask here:
> - Is there a way to cleanup MDB from obsolete attributes?
Generally no, the DB records every attribute type you have ever used.
> - Where/how are those attributes referenced in MDB?
Internal lookup tables.
> - Would it harm to ignore those errors?
They're just warnings. If they were errors, slapd would not start up.
> - Is the removal of attribute definitions from the schema not
> supported/suggested at all?
Never recommended, no. If you're retiring a definition, just add OBSOLETE to it.
> Btw, we are running slapd 2.6.3 with mdb backend. (Upgrade to 2.6.7 is
> in planning now).
>
> During the composition of this mail, further issues came up with
> slapd-totp and I would like to add some follow-up questions here. If you
> prefer, I'll write another mail or I could open an issue on bugzilla.
Open a separate issue in bugzilla.
>
> 1. By reading some code in slapd-totp.c I recognized that the introduced
>attribute authTimestamp is SINGLE-VALUE. But slapcat reveals that
>entries have multiple values of authTimestamp. This sounds not
>correct to me.
> 2. In slapd-totp.c: line 856 and 873 both call `ch_calloc` for the same
>structm, shadowing the same pointer. This looks like a memory leak to
>me, because also only one free is called. (I might be wrong though).
Note that contrib modules are explicitly not maintained by the Project.
You'll need to find someone in the community to fix these issues for you.
>
> Many thanks in advance,
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: olcDbMultival configuration
david.grac...@gmail.com wrote: > Hello, > > As part of a project, we'd like to know how to integrate olcDbMultival into > an existing and running configuration. > > Can this configuration be done while running ? Yes > Is it necessary to restart the directories after integration? No > Is it necessary to rebuild the primary database? No > In what order should we proceed? Doesn't matter. If it needed special handling the documentation would have told you so. Don't overthink these things. If nothing special is mentioned, nothing special is needed. > And the same question if we want to remove this attribute from a > configuration. Nothing changes in the DB until you actually modify an entry that would be affected by the setting. When the modified entry is written back into the DB it will use whatever setting is currently in effect. When an entry is read from the DB it is read according to how it was written, regardless of the current setting. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: etime calculation
david.grac...@gmail.com wrote: > Hello, > As part of a project we'd like to know exactly how etime is calculated in > openldap. > Is it purely the calculation time taken by openldap to execute the request, > or are other parameters also taken into account? It is the time from when the request was received by slapd until the time slapd sent the result message. > Like client time? > > For exemple, in local with a specific filter i do the search in 1 second and > the etime in my logs are 1 second. Now i have a client who do the same search > with the same filter and he perferm the search in 27 second and the etime in > my log are 27 second too. > Does the transfer time count? Does anything else count? If the result is large enough and the client is slow enough, then slapd's output buffers may fill, and then slapd would have to wait for the client to read enough data to unclog the slapd output before it can finish and send its result message. For simple requests with small responses, usually this isn't an issue. > > Thanks in advance > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: RE25 testing call (2.5.17) #1
Armin Tüting wrote:
> On Fri, 2024-01-19 at 10:27 -0800, Quanah Gibson-Mount wrote:
>> I sent this yesterday, but many people didn't get it due to the
>> mailman
>> upgrade issue that's now resolved.
>>
>> Thanks!
>>
>> --Quanah
> Compile error in 'ibraries/liblmdb' mdb_load.c
>
> --- openldap-OPENLDAP_REL_ENG_2_5/libraries/liblmdb/mdb_load.c 2024-
> 01-18 19:42:31.0 +0100
> +++ openldap-2.5.16/libraries/liblmdb/mdb_load.c2024-01-20
> 16:54:45.533564971 +0100
> @@ -449,7 +449,7 @@
> if (rc == MDB_KEYEXIST && putflags)
> continue;
> if (rc) {
> - fprintf(stderr, "%s: line %"Yu":
> mdb_cursor_put failed, error %d %s\n", prog, lineno, rc,
> mdb_strerror(rc));
> + fprintf(stderr, "%s: line %" Z "d:
> mdb_cursor_put failed, error %d %s\n", prog, lineno, rc,
> mdb_strerror(rc));
> goto txn_abort;
> }
> batch++;
>
> ...
>
>
Thanks for the feedback. This was a merge conflict from mdb.master. You have the
correct fix above, and it's now committed in mdb.RE/0.9
5eb93a3b8a3b6139da9321117ea013ea6c95c2c4
The fix will have to be merged to RE25 and RE26 as well.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Most efficient way to update multivalued attributes
Frédéric Goudal wrote: > Hello, > > > I have to update records with mutlivalued attributes, and I wonder what is > the best (fastest, or lighter for the server) to do : > > - either just set the value with the new list > > - or calculate which values to add and which to delete and than do the add > and remove operations. > > And to be a bit more precise, if we have a big number of values is one of the > two way best ? You should profile it yourself and see. Generally, you should only change what needs to be changed, so setting the entire value to a new list is the worst choice. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: SSL certificate install
Stefan Kania wrote: > Syntax error? Open your file with vi and do a "set: list" and you will see > additional blanks and tabstops. > > > Am 13.12.23 um 14:28 schrieb Jean-Luc Chandezon: >>> >>> You are missing "changetype: modify" >>> >>> this is how it should look >>> - >>> dn: cn=config >>> changetype: modify >>> add: olcTLSCertificateFile >>> olcTLSCertificateFile: /opt/symas/etc/openldap/example-net-cert.pem >>> - >>> add: olcTLSCertificateKeyFile >>> olcTLSCertificateKeyFile: /opt/symas/etc/openldap/example-net-key.pem >>> - >>> add: olcTLSCACertificateFile >>> olcTLSCACertificateFile: /opt/symas/etc/openldap/cacert.pem >>> >>> - >>> Stefan >>> >> >> Thank you Stefan! >> Sorry for the mistake due to last changes. >> >> Our ldf file content is: >> >> dn: cn=config >> changetype: modify >> add: olcTLSCACertificateFile >> olcTLSCACertificateFile: /etc/ssl/certs/LEXP_Infra_CA1.pem >> - >> add: olcTLSCertificateKeyFile >> olcTLSCertificateKeyFile: /etc/ssl/private/annuaire.lexp.fr.key >> - >> add: olcTLSCertificateFile >> olcTLSCertificateFile: /etc/ssl/certs/annuaire.lexp.fr.pem >> >> >> with the request: >> ldapmodify -Y EXTERNAL -H ldapi:/// -f /root/01-SSL.ldif >> result: >> modifying entry "cn=config" >> ldap_modify: Other (e.g., implementation specific) error (80) >> >> Any idea? >> >> Please find log content bellow >> >> 023-12-13T14:26:31.500282+01:00 bea-chicago slapd[63531]: #011#011one value, >> length 33 >> 2023-12-13T14:26:31.500380+01:00 bea-chicago slapd[63531]: #011add: >> olcTLSCertificateKeyFile >> 2023-12-13T14:26:31.500452+01:00 bea-chicago slapd[63531]: #011#011one >> value, length 37 As always - set a higher debug level and examine the debug output. Not the syslog output. syslog is for recording routine operation, not for isolating problems. Use the debug output for troubleshooting. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: solaris client ldap-backend to AD and DSE
Craig H Silva (Cenitex) wrote:
> from config:
>
> # {1}ldap, config
> dn: olcDatabase={1}ldap,cn=config
> objectClass: olcDatabaseConfig
> objectClass: olcLDAPConfig
> olcDatabase: {1}ldap
> olcSuffix: dc=myorg,dc=lcl
> olcAccess: {0}to dn.base="" by * read
> olcAccess: {1}to dn.base="cn=Schema" by * read
> olcAccess: {2}to dn.base="cn=Subschema" by * read
The above 3 ACLs are useless since none of them reside under the olcSuffix
namespace.
> olcAccess: {3}to * by self read by users read by anonymous auth
> olcAddContentAcl: FALSE
> olcLastMod: FALSE
> olcMaxDerefDepth: 15
> olcReadOnly: TRUE
> olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> olcSyncUseSubentry: FALSE
> olcMonitoring: FALSE
> olcDbURI: "ldaps://myorgdevad.myorgdev.lcl:636"
>
> Any guidance appreciated - logs available on request.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: solaris client ldap-backend to AD and DSE
Craig H Silva (Cenitex) wrote:
>
> I need to configure openldap as a proxy to AD so that AD can be upgraded to
> version 2019.
>
> Currently using Unix services for Windows, which works to provide nis
> information to solaris (11) and zfsappliance but it was deprecated after
> windows 2012.
>
> There's still nis info info in various attributes in AD schema, but the nis
> service is about to go. So an alternative is needed.
>
> I have the proxy configured with ldap-backend and its very happy to provide
> all the attribute information, but the solaris ldap client wants the DSE
> through the proxy and for the life of me I can't work out what is impeding
> it.
>
> I can "ldapsearch -Y EXTERNAL -H ldapi:/// -b "" -s base -LLL "+"" on the
> openldap system and the DSE is returned
>
> and I can get the DSE with an ldapsearch from the solaris client if I point
> directly at the AD ldap server, but if i point solaris at the openldap proxy
> - nada. This really upsets the ldapclient on solaris - it feels degraded.
>
> It feels like its an access issue as I can get a DSE when root on the
> openldap system.
You're talking about the rootDSE, not just any DSE.
The rootDSE is a per-server virtual entry. Requests for the rootDSE received by
slapd are handled by the slapd frontend, they
don't ever get forwarded to any backends. As such, it's impossible for
back-ldap to proxy those requests to anywhere else.
You should just extract whatever attributes Solaris wants to see from the
remote server, and add them to the slapd rootDSE.
See the olcRootDSE directive in slapd-config(5).
>
>
> from config:
>
> # {1}ldap, config
> dn: olcDatabase={1}ldap,cn=config
> objectClass: olcDatabaseConfig
> objectClass: olcLDAPConfig
> olcDatabase: {1}ldap
> olcSuffix: dc=myorg,dc=lcl
> olcAccess: {0}to dn.base="" by * read
> olcAccess: {1}to dn.base="cn=Schema" by * read
> olcAccess: {2}to dn.base="cn=Subschema" by * read
> olcAccess: {3}to * by self read by users read by anonymous auth
> olcAddContentAcl: FALSE
> olcLastMod: FALSE
> olcMaxDerefDepth: 15
> olcReadOnly: TRUE
> olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> olcSyncUseSubentry: FALSE
> olcMonitoring: FALSE
> olcDbURI: "ldaps://myorgdevad.myorgdev.lcl:636"
>
> Any guidance appreciated - logs available on request.
>
>
>
>
>
> Craig Silva |
> Specialist Engineer – Unix & Storage Services
> Level 18, 80 Collins Street,
> Melbourne 3000
> (03) 9063 5126
> cenitex.vic.gov.au
>
>
>
> Cenitex acknowledges the Traditional Owners
> and custodians of the land and we pay our respects to their Elders, past,
> present and emerging. We are an inclusive workplace that embraces diversity
> in all its forms.
>
>
>
> --
> Notice:
>
> This email and any attachments may contain information that is personal,
> confidential, legally privileged and/or copyright. No part of it should be
> reproduced, adapted or communicated without the prior written consent of the
> copyright owner.
>
> It is the responsibility of the recipient to check for and remove viruses.
>
> If you have received this email in error, please notify the sender by return
> email, delete it from your system and destroy any copies. You are not
> authorised
> to use, communicate or rely on the information contained in this email.
>
> Please consider the environment before printing this email.
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Transitioning from slapd.conf to slapd.d, best practices for maintaining configuration comments?
Ben Poliakoff wrote: > This is more of a practical question than a technical one, but it's prompted > by a technical change: I'm *very* **very** belatedly transitioning from flat > file > slapd.conf config to slapd.d/OLC. > > With flat file configuration, it was straightforward to include text comments > (e.g. "# blah blah"), but as far as I know there isn't any sort of analog for > comments, when using slapd.d. Looking for any tips about how best to annotate > slapd configuration, in a slapd.d/olc world. Does anyone have a practice that > they > find works well for them? Do people just maintain separate documents/wiki > pages/etc that describe their servers' configs? There's no real mechanism for commenting in the config itself. We could add optional "description" attributes to all of the config objectclasses, which would at least let you keep some information near the relevant locations, but it still wouldn't be the equivalent of line-by-line commenting. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: "user"/"users" keyword in documentation
Howard Chu wrote: > Uwe Sauter wrote: >> Hi all, >> >> in the ACL chapter of the online documentation to OpenLDAP 2.6 (and likely >> the versions before) >> there might be a mismatch of singular/plural usage of the "users" keyword. >> >> In chapter 8.3.2 "who to grant access to" table 5.3 lists specifier "users" >> as "authenticated users" >> entities. This is further shown in chapter 8.4.2 "matching anonymous and >> authenticated users". >> >> In chapter 8.4.9 "tips for using regular expressions in access control" the >> singular is used: >> "Use shorthands. The user directive matches authenticated users and the >> anonymous directive matches >> anonymous users." >> >> As well as in the subchapters 8.5.x where the singular is used in set >> definitions. > > The examples in monospaced font use the exact keywords. The wording in the > regular text is just conversational English. In particular, the Admin Guide is only a guide, not a reference manual. Read the slapd.access(5) manpage for exact syntax. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: "user"/"users" keyword in documentation
Uwe Sauter wrote: > Hi all, > > in the ACL chapter of the online documentation to OpenLDAP 2.6 (and likely > the versions before) > there might be a mismatch of singular/plural usage of the "users" keyword. > > In chapter 8.3.2 "who to grant access to" table 5.3 lists specifier "users" > as "authenticated users" > entities. This is further shown in chapter 8.4.2 "matching anonymous and > authenticated users". > > In chapter 8.4.9 "tips for using regular expressions in access control" the > singular is used: > "Use shorthands. The user directive matches authenticated users and the > anonymous directive matches > anonymous users." > > As well as in the subchapters 8.5.x where the singular is used in set > definitions. The examples in monospaced font use the exact keywords. The wording in the regular text is just conversational English. The keywords for sets are not the same as for regular ACLs. > My question now is: does it matter whether singular or plural of user is used > in ACLs? If so, where > to use one and where to use the other? Does it follow natural language useage? Use them as shown in the examples. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Thread Safety in LMDB with MDB_NOTLS and Readonly Cursors
xiaoya2...@gmail.com wrote: > Thanks Howard, > > Then I guess I have 2 follow-up questions: > > 1. Just to confirm (something I didn't get a clear answer): when MDB_NOTLS is > set, a cursor opened by a rw txn can be serially accessed by multiple > threads, one at a time. Is this write? No. MDB_NOTLS has no relevance to rw txns. The docs state quite clearly that it only affects read-only txns. Read more carefully. > 2. What does "Cursors may not span transactions" specifically mean? In my > understanding, a cursor belongs to one and only one txn, I didn't find an > LMDB API that allows users to operate a cursor with some random transactions? Read more carefully. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Thread Safety in LMDB with MDB_NOTLS and Readonly Cursors
xiaoya2...@gmail.com wrote: > Greetings LMDB Community, > > I am delving into the thread-safety aspects of LMDB, specifically regarding > the use of readonly cursors across multiple threads. With the MDB_NOTLS flag > enabled, which disables thread-local storage, my understanding is that > readonly transactions may be shared between threads, provided there is proper > synchronization to prevent concurrent access. > > Building upon this, I seek clarity on the following: Can multiple threads > safely access a single readonly cursor derived from such a synchronized > readonly transaction when MDB_NOTLS is enabled? > > Upon reviewing the LMDB source code, I noticed that cursors are tied to > transactions (see mdb.c#L1335). This suggests that if threads can > synchronously share a transaction, they might also share a cursor associated > with it for data retrieval. > > Meanwhile, while looking at the LMDB document > (http://www.lmdb.tech/doc/group__mdb.html#gad7ea55da06b77513609efebd44b26920), > it says “Cursors may not span transactions”, which is a little confusing for > me. To be crystal transparent, does it mean that, even if MDB_NOTLS is set, a > cursor opened by a readonly transaction still has to stay with one single > thread for its entire lifetime, and cannot be used by another thread even at > a different time? No that's not what it means. If it were to mean that, it would have said "cursors may not span threads". -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: email aliases - extended version
Chris Vogel wrote: > > Hi, > > I moved from a mailserver using exim/mysql to one based on postfix/ldap and > found a question I couldn't answer by searching: > > Is there a way to put "email aliases like I'm used to" into the directory? These questions really depend on Postfix. we don't define the LDAP schema they use nor how they use it, they do. > > By "email aliases like I'm used to" I mean 1-m aliases with the following > properties: > > - An email received for an alias address is send to multiple maildrops and/or > email addresses > > Additinally I'd like to add information about ownership/permissions: > > - An alias has got one or more owner(s) who > - are able to edit the list of receivers > - are allowed to delete the alias > - change permission on it like described below > - An alias has properties that describe the permission local receivers have > (for all of the local receivers or every single local): > - its open to subscription by every uid (user on the system) or only > the owners are > allowed to add new receivers > - delete oneself from the list of receivers > - allowed to use the alias address as email sender for emails > delivered by the account > > I know this sounds like mailinglist, but most of that has been possible in > exim using files and file permissions or values in a mysql database. A > listmanager > would add some interface for managing this, but that is not what I'm looking > for. > > I'm looking for an existing standard or quasi-official way on how to > represent this in the directory before inventing the wheel a second time. > > Along my way I stumbled over this two messages on the list which seem to > point in a similar direction: > > https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/thread/MF457XILOV3ACZOGWA3VBUOAB4RDHHVA/#MF457XILOV3ACZOGWA3VBUOAB4RDHHVA > https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/message/P4AF6OZTPTFBGT6S7DQV5EQVWXZ5ZPTF/ > > Thanks for any references or help > Chris > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Key/value chunk sizes / alignment?
Sam Dave wrote: > Hello, > > I have two LMDB databases, identical except one has key size 34 bytes and the > other key size 33 bytes. (Both have same value sizes and same number of > pairs). > > How can the file sizes on disk be exactly the same? Is this because of the > 2-byte alignment mentioned here? > https://github.com/AltSysrq/lmdb-zero/issues/8 > > I wonder if this 2-byte alignment was documented anywhere. RTFM. http://www.lmdb.tech/doc/group__internal.html Search for "align" -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: export certificate and key
Stefan Kania wrote: > > > Am 05.10.23 um 07:02 schrieb Howard Chu: >> Stefan Kania wrote: >>> Hi to all, >>> >>> I have autoca running with my own CA. And I can create certificates and >>> keys for users and hosts. But now I would like to use the certificate and >>> key for radius >>> 802.1x authentication so I need to export the certificate and the key. I >>> know how to convert a DER certificate to a pem certificate. But before I >>> can convert >>> the key and the certificate I need to export it. So how can I do that? >> >> Read tests/scripts/test066-autoca for examples of how to do that. >> > Does anyone has an answer for an non developer WITHOUT compiling the > software. I'm not a developer and I use the packages to install OpenLDAP and > the tests are > only running on self compiled versions. The OpenLDAP Project is an open source project. It only provides source code. If you have complaint about how your packagers are packing their builds, complain to them. . The answer of a question should NEVER be "read the source code" "or "compile it your self" The answer should be part of > the documentation A person receiving the results of all-volunteer work NEVER has the right to demand how or what should be given. You are far too entitled and should be ashamed of yourself. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: export certificate and key
Stefan Kania wrote: > > > Am 05.10.23 um 07:02 schrieb Howard Chu: >> Stefan Kania wrote: >>> Hi to all, >>> >>> I have autoca running with my own CA. And I can create certificates and >>> keys for users and hosts. But now I would like to use the certificate and >>> key for radius >>> 802.1x authentication so I need to export the certificate and the key. I >>> know how to convert a DER certificate to a pem certificate. But before I >>> can convert >>> the key and the certificate I need to export it. So how can I do that? >> >> Read tests/scripts/test066-autoca for examples of how to do that. >> > Does anyone has an answer for an non developer WITHOUT compiling the > software. I'm not a developer and I use the packages to install OpenLDAP and > the tests are > only running on self compiled versions. The answer of a question should NEVER > be "read the source code" "or "compile it your self" The answer should be > part of > the documentation The documentation tells you what attributes are used to store the values. The ldapsearch manpage tells you how to retrieve attributes. There is nothing else to document. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: export certificate and key
Stefan Kania wrote: > Hi to all, > > I have autoca running with my own CA. And I can create certificates and keys > for users and hosts. But now I would like to use the certificate and key for > radius > 802.1x authentication so I need to export the certificate and the key. I know > how to convert a DER certificate to a pem certificate. But before I can > convert > the key and the certificate I need to export it. So how can I do that? Read tests/scripts/test066-autoca for examples of how to do that. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Help troubleshooting SSL certificates issue
Jérôme BECOT wrote: > Hello, > > We have a couple of old ldap servers (Debian 7/openldap 2.4.31) on which we > try to replace the certificates. On these servers we have a bundled > configuration: Presumably since that's a Debian build it was built using GnuTLS. I suggest you try using gnutls-cli with your PEM file and see what works or doesn't work. > > # config > dn: cn=config > olcTLSCACertificateFile: /etc/ldap/tls/multi.deverywa.re.pem > olcTLSCertificateFile: /etc/ldap/tls/multi.deverywa.re.pem > olcTLSCertificateKeyFile: /etc/ldap/tls/multi.deverywa.re.pem > > The file is a bundle containing both the certificates (wildcard and it's > issuer) and the key. Until this year we just had to upload the new bundle and > restart > slapd. This year Gandi changed their signing certificate but it is still > issued by UserTrust. But OpenLDAP refuses to use it now. > > We tried to set LogLevel to any, but nothing really showed in the log. On the > server side: > > slapd[9217]: connection_read(16): TLS accept failure error=-1 id=1041, closing > > On the client side (localhost): > > openssl s_client -connect localhost:636 -servername ldap.deverywa.re > CONNECTED(0003) > 140365161965224:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake > failure:s23_lib.c:177: > --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 0 bytes and written 315 bytes > --- > New, (NONE), Cipher is (NONE) > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > SSL-Session: > Protocol : TLSv1.2 > Cipher : > Session-ID: > Session-ID-ctx: > Master-Key: > Key-Arg : None > PSK identity: None > PSK identity hint: None > SRP username: None > Start Time: 1695652388 > Timeout : 300 (sec) > Verify return code: 0 (ok) > > We still use 2048 RSA key to generate the certificates. We have checked > permissions and it is fine. How could I debug what's wrong on the server side > ? > > Thank you > > -- > *Jérôme BECOT* > Ingénieur DevOps Infrastructure > > Téléphone fixe: 01 82 28 37 06 > Mobile : +33 757 173 193 > Deveryware - 43 rue Taitbout - 75009 PARIS > https://www.deveryware.com <https://www.deveryware.com> > > Deveryware_Logo > <https://www.deveryware.com> -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: changing certificate and key for autoca
Stefan Kania wrote: > Thank you, now it's working. Would be nice if it documented somewhere, maybe > the manpage :-) That is precisely what the ";binary" option means. It is documented in RFC4522. You should not be using attribute options without understanding what they mean. > > > > Am 21.09.23 um 18:08 schrieb Howard Chu: >> Stefan Kania wrote: >>> Hi all, >>> >>> I like to change the certificate and the key for autoca, but I can't find >>> any description how to do it. I tried the following LDIF: >> >> The LDAP PKI schema uses DER values, not PEM. >> >>> --- >>> dn: dc=example,dc=net >>> changetype: modify >>> replace: cACertificate;binary >>> cACertificate;binary:< file:///root/mycert/cacert.pem >>> - >>> replace: cAPrivateKey;binary >>> cAPrivateKey;binary:< file:///root/mycert/cakey.pem >>> --- >>> I got: >>> --- >>> root@ldap-r01:~# ldapmodify -Y external -H ldapi:/// -f change-cert.ldif >>> SASL/EXTERNAL authentication started >>> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >>> SASL SSF: 0 >>> modifying entry "dc=example,dc=net" >>> ldap_modify: Invalid syntax (21) >>> additional info: cACertificate;binary: value #0 invalid per syntax >>> >>> So what is the right way to change the certificate and the key? >>> >>> >>> Thank's >>> >>> >>> Stefan >>> >>> >> >> > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: changing certificate and key for autoca
Stefan Kania wrote: > Hi all, > > I like to change the certificate and the key for autoca, but I can't find any > description how to do it. I tried the following LDIF: The LDAP PKI schema uses DER values, not PEM. > --- > dn: dc=example,dc=net > changetype: modify > replace: cACertificate;binary > cACertificate;binary:< file:///root/mycert/cacert.pem > - > replace: cAPrivateKey;binary > cAPrivateKey;binary:< file:///root/mycert/cakey.pem > --- > I got: > --- > root@ldap-r01:~# ldapmodify -Y external -H ldapi:/// -f change-cert.ldif > SASL/EXTERNAL authentication started > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > modifying entry "dc=example,dc=net" > ldap_modify: Invalid syntax (21) > additional info: cACertificate;binary: value #0 invalid per syntax > > So what is the right way to change the certificate and the key? > > > Thank's > > > Stefan > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: slapd-watcher -i X refreshing unexpectedly...?
Quanah Gibson-Mount wrote: > > > --On Wednesday, September 13, 2023 1:54 PM +0200 cYuSeDfZfb cYuSeDfZfb > wrote: > >> It feels like perhaps there is something wrong in the way the -i X option >> is implemented. > > Please file a report at https://bugs.openldap.org/ No, don't. The tool works correctly. > > --Quanah > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: slapd-watcher -i X refreshing unexpectedly...?
cYuSeDfZfb cYuSeDfZfb wrote:
> Hi,
>
> We noticed that, when using "slapd-watcher -i X" option to refresh display
> every X seconds, lagging replication statuses are often not cleared, when in
> fact
> replication as already recovered.
>
> In our MMR environment, we often see this for longer periods of time in
> slapd-watcher output :
>
> contextCSN: 20230913104435.605937Z#00#0dd#00 actv@2023-09-13
> 10:44:35, idle@2023-09-13 10:44:37
>
> But when running like this:
> do
> timeout --foreground 1 $SLAPDWATCHER -b $BASE -D $LDAPBINDDN -w $ADMINPW
> "${SERVERURIS[@]}" -s ${SERVERIDS[*]}
> done
>
> the lagging replication lines change back to "idle, sync'd" immediately after
> replication has recovered.
>
> It feels like perhaps there is something wrong in the way the -i X option is
> implemented.
There are no bugs in the slapd-watcher tool. But you must list the server URIs
in ascending order of serverID, and
make sure you provide the list of serverIDs in the matching order. If the list
of SIDs is out of order it won't be
able to compare the CSNs to the correct master.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Trying to understand mdb_env_set_mapsize
Siddharth Jain wrote: > Hello, > > can someone help me understand this parameter: > http://www.lmdb.tech/doc/group__mdb.html#gaa2506ec8dab3d969b0e609cd82e619e5 > > 1. why does a user need to specify this apriori? Other databases don't > require user to declare the size of the db beforehand. its not something a > user knows in > advance. It's not the size of the database. It's the maximum size the database will be allowed to grow to. Of course you don't need to know the actual size of the DB in advance. You ought to know how much storage you're willing to commit to the DB. At most, it is the size of the free space on your storage device. As for why: because setting the maximum size once, up front, gives higher performance than incrementally growing during runtime. If you don't care about performance, and can't handle this question, use some other slower DB. > 2. quoting: "The size of the memory map is also the maximum size of the > database.". what happens when the size of the db overflows this parameter? It can't overflow. The DB will reject writes when it reaches that limit. > 3. what is the trade-off if a user sets this parameter too large than is > necessary? The map just uses virtual address space, which is limited to 128TB on current 64bit CPUs. If you try to use all of that up, you won't have space for shared libraries in that process. > > S. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: lmdb usage in containers
Vitaly Repin wrote:
> Hello,
>
> I have a question about usage of the same lmdb database in different
> containers and in the host machine.
>
> So far I just mapped lmdp file in docker-compose.yml:
>
> volumes:
> - "/var/spool/lmdbenv/:/var/spool/lmdbenv/"
>
> And I'm reading/writing to/from the database from different containers.
>
> Everything seems to work at a first glance.
>
> Example of adding an element to lmdb:
>
> /usr/bin/python -mlmdb --env /var/spool/lmdbenv edit \
> --set "client"="{
> \"client_ip\" : \"$client_ip\",
> \"client_data\" : \"$client_data\"
> }"
>
> Is it the proper use case for lmdb? Is there any special "flush" API which I
> have to use to make sure that the record inserted in one container becomes
> visible
> in another?
LMDB requires every process using it to have a unique PID. Usually containers
all run their job as PID number 1, you'll have to make sure
they all use unique PIDs.
> Thanks in advance!
>
> --
> WBR & WBW, Vitaly
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Feature Request: slapd: expose SASL EXTERNAL identity to olcAccess rules
Sean Gallagher wrote: > On 1/08/2023 3:46 am, Jordan Brown wrote: >> On 7/31/2023 9:10 AM, Howard Chu wrote: >>> The fact that the TLS session is already authenticated is irrelevant. >>> Transport layer and Application layer are separate and independent. If a >>> client wants >>> to be authenticated on the LDAP layer it must request it. >> >> Does the RFC explicitly authorize controlling access based on the client's >> IP address? >> Does slapd allow controlling access based on the client's IP address? > > Howard is being very literal in his reading of the LDAP RFCs. RFCs are not poems, they aren't meant to be loosely interpreted. I've wasted enough time explaining things here. As always, in an all-volunteer open source project, if you want something changed, go change it yourself. Quit trying to browbeat other people into listening to your selfish demands. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Feature Request: slapd: expose SASL EXTERNAL identity to olcAccess rules
Jordan Brown wrote: > On 7/28/2023 7:32 AM, Howard Chu wrote: >> Regardless. A session is either authenticated, meaning it has an identity >> associated to it, or it is anonymous, meaning it has no identity associated >> to it. >> You can't have both at once. If you want an identity to be associated to the >> session, you perform a Bind operation. End of story. > > A TLS session that requires a client certificate is authenticated, whether or > not there's a bind operation. The question is whether the ACL subsystem can > make > use of that existing authentication - whether the TLS-level authenticated > identity is automatically made available at the LDAP layer. Repeating myself because you don't seem to read carefully: If you want an identity to be associated to the session, you perform a Bind operation. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Feature Request: slapd: expose SASL EXTERNAL identity to olcAccess rules
Sean Gallagher wrote: > On 28/07/2023 12:35 pm, Howard Chu wrote: >> Clients that don't Bind are, by definition, anonymous. > Yes, that is the term used in the RFCs, but the RFCs do not say what > anonymous sessions can and cannot do. This is up to the system administrator. > It is not > unreasonable to base those permissions on who by or how the connection was > established. >> >>> Compare: >>> access to dn="ou=people,o=Example Corp" attr="userPassword" by externalself >>> auth >>> access to dn="ou=people,o=Example Corp" attr="userPassword" by anonymous >>> auth >>> >>> clearly not exactly the same >> Clearly pointless, because an external bind doesn't need access to >> userPassword at all. > > Think SIMPLE bind over an ldaps channel. Just because the EXTERNAL identity > is there, does not force a client to use it. > >> The analogy fails because "auth" access doesn't allow a user to see the >> values of what access was granted to, while anyone could read the contents >> of the passwd >> file. Granting auth access only allows clients to perform Simple Bind ops. > > Not a perfect analogy, but still helpful. > >> You are asking to associate an identity to a session. That is what >> "authenticating" is. In LDAP a Bind request is used for authentication. >> >> You're asking for LDAP to perform some new, previously undefined operation >> to do exactly what a SASL EXTERNAL Bind does. >> > This is not a new or undefined operation, this is as old as computers > themselves. I control who my clients are by who I allow to connect to my > system. Signing a > certificate for a client is the modern day equivalent of "plugging it in". > The fact that LDAP has an explicit bind operation does not invalidate this > fundamental rule of computer networks. Regardless. A session is either authenticated, meaning it has an identity associated to it, or it is anonymous, meaning it has no identity associated to it. You can't have both at once. If you want an identity to be associated to the session, you perform a Bind operation. End of story. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Feature Request: slapd: expose SASL EXTERNAL identity to olcAccess rules
Quanah Gibson-Mount wrote: > > > --On Thursday, July 27, 2023 5:23 PM +0100 Howard Chu wrote: > >> Sean Gallagher wrote: >>> On 27/07/2023 5:57 pm, Ondřej Kuzník wrote: >>>> I'm not sure what you're trying to achieve here. Why do you want to >>>> distinguish different kinds of anonymous clients? >>> >>> My clients are very asymmetric. Each has a particular job to do, and a >>> particular set of operations to perform on the database. I was trying to >>> restrict access for each client, to just what was needed for it to >>> perform it's task. Then if one client is compromised, damage can be >>> (more) contained. >>> >>> As it stands, before a bind, all (IP) clients look the same (Apart from >>> the IP address) - and so all clients need "auth" access to all other >>> clients credentials. >> >> That is all false. No auth privileges are needed to perform a SASL >> EXTERNAL Bind. > > That is not necessarily true. If you do a direct mapping, correct. If you > have an ldap URI that does an internal lookup as part of validating the > external > bind, then auth is necessary on those attributes. This is noted explicitly > in the man page. Wrong. In a SASL EXTERNAL Bind there are no failure conditions, the entire point is that the presence of the session means it was already validated. Failure to map the SASL authc identity doesn't invalidate it, it just means the original identity is used as-is. Regardless, the Bind succeeds unconditionally. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Feature Request: slapd: expose SASL EXTERNAL identity to olcAccess rules
Sean Gallagher wrote: > > On 28/07/2023 1:23 am, Howard Chu wrote: >> That is all false. No auth privileges are needed to perform a SASL EXTERNAL >> Bind. > Not all clients use the EXTERNAL bind to authenticate. I'm also thinking > about clients that don't bind at all. Clients that don't Bind are, by definition, anonymous. >> The exact same is true with what you've proposed. > > Compare: > access to dn="ou=people,o=Example Corp" attr="userPassword" by externalself > auth > access to dn="ou=people,o=Example Corp" attr="userPassword" by anonymous auth > > clearly not exactly the same Clearly pointless, because an external bind doesn't need access to userPassword at all. > I see a parallel here with the evolution of shadow passwords on unix systems. > Before shadow passwords came along, all uses of the unix box could see hashes > of > all the other user's passwords. People realized this was a bad idea pretty > early on and so shadow passwords were invented. What I'm proposing is more > like > shadow passwords. The status-quo is more like the original system. The analogy fails because "auth" access doesn't allow a user to see the values of what access was granted to, while anyone could read the contents of the passwd file. Granting auth access only allows clients to perform Simple Bind ops. > >> All you're doing is inventing a new authentication mechanism instead of >> using one that already exists. > > I think "improving on one that already exists" is closer to the truth. In any > case you give me too much credit. I didn't invent TLS, I just want to see it > reach > it's potential. > > But it is true, with what I'm proposing, many clients would not need to bind > at all. I say good! save a round trip time on the transaction. > > All this really misses the point though. This is really about building walls > around each client and preventing them from interacting except in the limited > sense > deemed necessary by design. This is a basic tenet computer security and one > worth pursuing. You are asking to associate an identity to a session. That is what "authenticating" is. In LDAP a Bind request is used for authentication. You're asking for LDAP to perform some new, previously undefined operation to do exactly what a SASL EXTERNAL Bind does. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Feature Request: slapd: expose SASL EXTERNAL identity to olcAccess rules
Ondřej Kuzník wrote: > On Thu, Jul 27, 2023 at 10:32:08PM +1000, Sean Gallagher wrote: >> My clients are very asymmetric. Each has a particular job to do, and a >> particular set of operations to perform on the database. I was trying to >> restrict access for each client, to just what was needed for it to perform >> it's task. Then if one client is compromised, damage can be (more) >> contained. >> >> As it stands, before a bind, all (IP) clients look the same (Apart from the >> IP address) - and so all clients need "auth" access to all other clients >> credentials. If any client is granted some pre-bind rights, all clients get >> those same rights. One compromised client makes all clients vulnerable. This >> is not necessary. slapd _knows_ the identity of each client, it's just a >> matter of exposing it to the ACL rules. It's not even without precedent, the >> sasl_ssf is exposed to the ACL rules before a bind, why not other properties >> of the sasl state? >> >> Anyway, this is just a "nice to have" idea, the real-life effect this would >> have on security is pretty minimal. It's just frustrating when I have to >> weaken access controls to do things the "right" way.. > > For now, your best bet would be a dynacl module. Or you can implement > your proposed functionality yourself and see if we can get it merged. No. This is fallacious. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Feature Request: slapd: expose SASL EXTERNAL identity to olcAccess rules
Sean Gallagher wrote: > On 27/07/2023 5:57 pm, Ondřej Kuzník wrote: >> I'm not sure what you're trying to achieve here. Why do you want to >> distinguish different kinds of anonymous clients? > > My clients are very asymmetric. Each has a particular job to do, and a > particular set of operations to perform on the database. I was trying to > restrict access > for each client, to just what was needed for it to perform it's task. Then if > one client is compromised, damage can be (more) contained. > > As it stands, before a bind, all (IP) clients look the same (Apart from the > IP address) - and so all clients need "auth" access to all other clients > credentials. That is all false. No auth privileges are needed to perform a SASL EXTERNAL Bind. > If any client is granted some pre-bind rights, all clients get those same > rights. One compromised client makes all clients vulnerable. This is not > necessary. The exact same is true with what you've proposed. > slapd _knows_ the identity of each client, it's just a matter of exposing it > to the ACL rules. It's not even without precedent, the sasl_ssf is > exposed to the ACL rules before a bind, why not other properties of the sasl > state? > > Anyway, this is just a "nice to have" idea, the real-life effect this would > have on security is pretty minimal. It's just frustrating when I have to > weaken > access controls to do things the "right" way.. All you're doing is inventing a new authentication mechanism instead of using one that already exists. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: lmdb and alignment clarification
Howard Chu wrote: > b...@bullno1.com wrote: >> I have read a few threads on lmdb alignment but I am still not clear on what >> kind of padding should be done. >> >> Use case: I want to store aligned SIMD vectors in the value and operate on >> them directly with SIMD instructions without copying. >> >> As I understand it, lmdb guarantees 2-byte alignment. >> However, it can also move nodes around for tree rebalancing or page >> reclaiming. >> Thus, merely aligning the key and value might not be enough. LMDB's own headers are aligned to 16 byte boundaries. If your keys+values are also aligned to 16 byte boundaries then nodes shuffling around will have no effect on their alignment. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: lmdb and alignment clarification
b...@bullno1.com wrote: > I have read a few threads on lmdb alignment but I am still not clear on what > kind of padding should be done. > > Use case: I want to store aligned SIMD vectors in the value and operate on > them directly with SIMD instructions without copying. > > As I understand it, lmdb guarantees 2-byte alignment. > However, it can also move nodes around for tree rebalancing or page > reclaiming. > Thus, merely aligning the key and value might not be enough. > > Right now, based on my reading of the code, I'm assuming that the data layout > in a leaf page is like this: > > [page_header][mp_ptrs]...[node_header][key][value][node_header][key][value] > > Basically, nodes are stored contiguously in memory with `node_header` and > `key` always aligned to 2-byte. > New nodes are allocated from the bottom of the page and offsets are > stored/allocated into MDB_page.mp_ptrs from the top. > Is this correct? No. > > If so, to ensure that `value` has a certain alignment, even when accounting > for nodes being moved around, one would also have to ensure that > `sizeof(node_header) + sizeof(key) + sizeof(value)` is a multiple of the > alignment. > Is this reasoning correct? No. > > For the overflow page, is the structure similar? Just that one single page > header is used for a number of contiguous pages. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: slapindex a 60GB mdb in reasonable time
Maud Parratt wrote: > I’ve configured my arm64 instance with: > dn: cn=config > olcIndexHash64: FALSE > > > The indexes are still broken though, is this the configuration you’re > referring to? Given my mdb is from an amd64 box, it’ll be 32 bit, so I want > to match the > configuration. That is not what I wrote in my reply to you. > > *From: *Howard Chu > *Date: *Thursday, 20 July 2023 at 20:38 > *To: *Quanah Gibson-Mount , Maud Parratt > , openldap-technical@openldap.org > > *Subject: *Re: slapindex a 60GB mdb in reasonable time > > Quanah Gibson-Mount wrote: >> >> >> --On Thursday, July 20, 2023 7:13 PM +0100 Howard Chu wrote: >> >>>> Pretty sure they're not compatible. I.e., you must load from LDIF when >>>> switching architectures. >>> >>> There's no particular reason for arm64 and amd64 to be incompatible, >>> they're both 64bit little-endian. arm64 and x86 (32bit) would most likely >>> be incompatible though. >> >> >> Hm, not different page sizes perhaps? But if this is 64-bit on both ends, >> and the amd64 generated index databases don't work on ARM64, seems to >> indicate >> something's not compatible? > > I just checked on a local box. My ARM64 build defaulted to 64bit index keys, > the AMD64 build used 32bit index keys. Not sure why the defaults are > different, > but configuring 64bit index keys on the AMD64 box would fix this. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: slapindex a 60GB mdb in reasonable time
Quanah Gibson-Mount wrote: > > > --On Thursday, July 20, 2023 7:13 PM +0100 Howard Chu wrote: > >>> Pretty sure they're not compatible. I.e., you must load from LDIF when >>> switching architectures. >> >> There's no particular reason for arm64 and amd64 to be incompatible, >> they're both 64bit little-endian. arm64 and x86 (32bit) would most likely >> be incompatible though. > > > Hm, not different page sizes perhaps? But if this is 64-bit on both ends, > and the amd64 generated index databases don't work on ARM64, seems to indicate > something's not compatible? I just checked on a local box. My ARM64 build defaulted to 64bit index keys, the AMD64 build used 32bit index keys. Not sure why the defaults are different, but configuring 64bit index keys on the AMD64 box would fix this. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: slapindex a 60GB mdb in reasonable time
Quanah Gibson-Mount wrote: > > > --On Thursday, July 20, 2023 5:32 PM + Maud Parratt > wrote: > >> >> >> >> >> The last time slapadd was used on this database was many years ago, and >> yeah as I said, slapindex is my mitigation for queries not working after >> reloading the mdb with arm64. we're using cn=config. we see the same >> indexing performance on 2.6.2 though. >> >> >> i've not tested loading an arm64 mdb with an x86 instance, i'll try that >> tomorrow and report back. >> >> >> i may have to accept running the process through the day, then sync >> forwards after switching over. not ideal but not intolerable. it would be >> nice to know why indexes get messed up by the architecture swap though. > > Pretty sure they're not compatible. I.e., you must load from LDIF when > switching architectures. There's no particular reason for arm64 and amd64 to be incompatible, they're both 64bit little-endian. arm64 and x86 (32bit) would most likely be incompatible though. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: python-lmdb crashing ( d <= env->me_pglast' failed in mdb_freelist_save()) - unusable 300gb database
mark jayson wrote: > 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. It is. Extensively tested so, but storage devices can still lie about whether they successfully wrote data. > 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. Try using mdb_dump to see if it will backup the contents without crashing. Also, when asking for help you should specify exactly what version of liblmdb you used. The backtrace is a bit odd because normally just opening an environment shouldn't require committing any write txns. > > 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 0x77c96476 in __GI_raise (sig=sig@entry=6) at > ../sysdeps/posix/raise.c:26 > #4 0x77c7c7f3 in __GI_abort () at ./stdlib/abort.c:79 > #5 0x762fb3e2 in mdb_assert_fail (env=0x565b49f0, > expr_txt=expr_txt@entry=0x762fe308 "len >= 0 && id <= env->me_pglast", > func=func@entry=0x762fe930 <__func__.13> "mdb_freelist_save", > line=line@entry=3274, file=0x762fe010 "build/lib/mdb.c") at > build/lib/mdb.c:1545 > #6 0x762f10df in mdb_freelist_save (txn=0x56752950) at > build/lib/mdb.c:3274 > #7 mdb_txn_commit (txn=0x56752950) at build/lib/mdb.c:3646 > #8 0x762f369b in txn_db_from_name (env=env@entry=0x761c8090, > name=, flags=262144) at lmdb/cpython.c:1017 > #9 0x762f6e1d in env_open_db (self=0x761c8090, args= out>, kwds=) at lmdb/cpython.c:1665 > #10 0x556b23a9 in ?? () > #11 0x55699c14 in _PyEval_EvalFrameDefault () > #12 0x55696176 in ?? () > #13 0x5578bc56 in PyEval_EvalCode () > #14 0x557b8b18 in ?? () > #15 0x557b196b in ?? () > #16 0x557b8865 in ?? () > #17 0x557b7d48 in _PyRun_SimpleFileObject () > #18 0x557b7a43 in _PyRun_AnyFileObject () > #19 0x557a8c3e in Py_RunMain () > #20 0x5577ebcd in Py_BytesMain () > #21 0x77c7dd90 in __libc_start_call_main > (main=main@entry=0x5577eb90, argc=argc@entry=14, > argv=argv@entry=0x7fffe378) at > ../sysdeps/nptl/libc_start_call_main.h:58 > #22 0x77c7de40 in __libc_start_main_impl (main=0x5577eb90, > argc=14, argv=0x7fffe378, init=, fini=, > rtld_fini=, stack_end=0x7fffe368) > at ../csu/libc-start.c:392 > #23 0x5577eac5 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) > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Different loglevels based on IP prefix?
Dick Visser wrote: > 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 > There's no such feature currently. Feel free to submit a patch to add that. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: mdb_env_close, mdb_dbi_close, mdb_dbi_open
Sam Dave wrote: > Hi, > > I'm interested in understanding these functions better. These are not > criticisms.. since these functions are called rarely, I have no problem > synchronizing > them. I ask only for curiosity's sake. Everything in LMDB is defined within the context of a single environment. That should already be clear from the documentation. The constraints you reference below only apply within a single environment. Separate environments are completely independent of each other. > > * mdb_env_close: "Only a single thread may call this function." Why can't > different environments (separate files/dirs on disk) be closed from different > threads? > > * mdb_dbi_close: "Handles should only be closed by a single thread." Why > can't at least databases on different environments (separate files/dirs on > disk) be > closed from different threads? > > * mdb_dbi_open: "This function must not be called from multiple concurrent > transactions in the same process." Why can't this function be called from > different > threads to open at least databases on different environments (separate > files/dirs on disk)? > > What are the reasons for these limitations, under the hood? Could these > functions have been designed in a different way, to allow for more > multithreading > (again, I'm not asking for this, I'm just curious). > > - Sam -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: RSfd in top, memory, etc.
Sam Dave wrote: > While I write to an LMDB database, while it gets bigger and bigger, I can see > %MEM in top rising steadily. > > This is because %MEM is composed of three things, including "RSfd". From the > top manpage: > > RSfd -- Resident File-Backed Memory Size (KiB) > A subset of resident memory (RES) representing the implicitly shared pages > supporting program images and shared libraries. It also includes explicit file > mappings, both private and shared. > > Is it memory mapping that's resulting in the higher RSfd? LMDB uses shared memory mapped files, so yes. > > RSfd increases do not seem to have an effect on "buff/cache" or "avail Mem", > i.e. what most people think as "RAM" is not being used up. I still want to > ask, > could too high RSfd use result in less efficient use of memory for other > programs? I'm essentially wondering how efficient common OSes (e.g. MacOS, > Linux) are > in this area. No. The OS can reclaim LMDB's pages (at zero cost) for use by any other program whenever memory demands are tight. > - Sam -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Proposal to strengthen slapd EXTERNAL authentication
Christopher Paul wrote: >> The point of a certificate-based authentication system is not to have to >> implement authentication rules for each and every individual user. An LDAP >> server should only trust certificates issued by a single CA; that CA should >> only >> be issuing certs to valid users. Ideally, the LDAP server should be the CA, >> which is what slapo-autoca is designed for. > > Any peer in a TLS session that does validation seems to have three things to > validate: > 1. the x.509 subject name matching the name as known or claimed by the peer The above applies to clients validating servers. TLS is client-server, not peer-to-peer. Clients with certs assert their name to servers, and if the server trusts the cert issuer then it accepts the name that the client asserted. > 2. the signing authority > 3. the validity date > > Are we saying that the LDAP server should only care about #2? The date is important too of course. And revocation checks too, but they aren't relevant to this conversation. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Proposal to strengthen slapd EXTERNAL authentication
Sean Gallagher wrote: > On 26/06/2023 7:40 pm, Howard Chu wrote: >> That feature is already available using TLSVerifyClient in the slapd config. > > Not really. Using the TLSVerifyClient mechanism could be made to work and > would be a nice solution but it isn't there yet. To make this this work, you > would > need to pass to libldap, some type of specification of the names of > legitimate clients. Then in the tls_o.c:tlso_verify_cb() function, compare > the name on the > client cert with the specification and return the pass/fail status back to > the TLS layer. Then it would all "just work". > > The average user might be surprised to learn that TLSVerifyClient does not > currently involve checking the client's name. You would intuitively think > that was > pretty important. The point of a certificate-based authentication system is not to have to implement authentication rules for each and every individual user. An LDAP server should only trust certificates issued by a single CA; that CA should only be issuing certs to valid users. Ideally, the LDAP server should be the CA, which is what slapo-autoca is designed for. An LDAP server is not a web server or a client. There is no reason for it to trust certs from multiple CAs. > >> Pure nonsense. > > Pure hubris. > > It's sad when it takes a disaster to affect real change. Pure ignorance. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Proposal to strengthen slapd EXTERNAL authentication
Sean Gallagher wrote: > It seems there is no interest in this. That's disappointing but not > unexpected. Personally, I find it reckless that slapd would accept and > process packets from > parties that would happily take a flame thrower to your server if it got them > any advantage. > > I would strongly encourage the OpenLDAP team to properly validate PKI client > certificates and CLOSE THE CONNECTION if the client fails authentication. That feature is already available using TLSVerifyClient in the slapd config. > > I have made one proposal about how to add this functionality but I'm sure > there are many ways to approach it. > > In the mean time, I will continue using the proxy in front of slapd and would > strongly recommend anyone using client certs for authentication without a > dedicated CA to do the same. Pure nonsense. > > In all other repects, > > thanks for a great product. > > Sean. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: olcAccess rule with groupOfURLs
Quanah Gibson-Mount wrote: > > > --On Thursday, June 8, 2023 8:54 PM +0200 Souji Thenria > wrote: > >> On 6/8/23 18:13, Howard Chu wrote: >>> >>> Just use by group=cn=foo,... write >>> >> >> Thanks for the response. >> >> I tried to use group=... and group.exact=... without success. >> The Administrator's Guide [1] says that group=... assumes that the >> objectClass is "groupOfNames", and if I use another objectClass, I >> should use: >> by group//= > > > That is for static groups, not dynamic groups. Irrelevant. The ACL engine supports both static and dynamic groups using the same syntax. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: olcAccess rule with groupOfURLs
Souji Thenria wrote: > Hello, > > I am trying to use a group of the type "groupOfURLs" within an olcAccess > rule. However, I am having trouble getting this to work. > > For testing, I use a simple rule like: > by set="[cn=test,ou=System,dc=example,dc=local]/member & user" write That's not the right way to use groups. Just use by group=cn=foo,... write -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: mdb_txn_abort() thread
Sam Dave wrote: > Very nice, I missed MDB_NOLOCK completely. This might work for me. > > However, one thing got my curious about MDB_NOLOCK docs: "For proper > operation [of MDB_NOLOCK] the caller must ... ensure that no readers are > using old > transactions while a writer is active." > > Is this also true without MDB_NOLOCK, i.e. does the built-in locking > mechanism also "ensure that no readers are using old transactions while a > writer is > active."? (I guess not because it sounds like it would break "readers don't > block writers.") In the built in mechanism, readers never block writers. When using your own locking, readers must block writers otherwise you'll corrupt the views that read txns are seeing. Needless to say, with NOLOCK you must know what you're doing. From the level of this conversation so far, I wouldn't recommend you go this route. Your initial problem seems to be that you don't understand the actual semantics of transactions and threads. LMDB expects them to be 1:1. That's it. Anything else is a waste, just like M:N threading (multiple user-level threads on top of a different number of kernel threads) is a waste and has been abandoned by everyone. > > I was hoping I could do my own concurrency management only for write > transactions without worrying about read transaction - I thought that's what > "multiversioning" was all about. > > > > Jun 7, 2023, 19:17 by h...@symas.com: > > Sam Dave wrote: > > Read-write txns don't use TLS. TLS is only used for read-only > txns. > > > Why then is it important that a read-write transaction stays on the > same thread (including the final abort or commit)? (I just assumed it was > because it > needed > access to TLS, looks like I was wrong) > > > Write txns are serialized by a mutex. The mutex is taken when a write txn > begins and is released when the txn ends. > It is illegal for any thread other than the original locking thread to > release the mutex. > > If you don't want these semantics, just use MDB_NOLOCK and do your own > concurrency management. > > > Jun 7, 2023, 17:23 by h...@symas.com: > > Sam Dave wrote: > > Alternatively, could a more stateful API be provided (as an > alternative to API relying on TLS)? > > Roughly what I have in mind is, mdb_txn_create() returns a state > pointer, which should be passed into the next mdb_put(), which returns a > state pointer, > which > should be passed into the next mdb_put(), and so on, until the final > state is passed into mdb_commit() or mdb_abort(). > > > A txn pointer is a state pointer. > > > Jun 7, 2023, 10:26 by samd...@tuta.io: > > Thanks, I was just hoping abort was a (currently undocumented) > exception to this :) > > Would it be possible/feasible in the future to bring MDB_NOTLS > support to read-write transactions? (or at least some partial NOTLS support > for only e.g. > abort) > > > Read-write txns don't use TLS. TLS is only used for read-only txns. > > > Motivation: Ability to abort "later" (e.g. at garbage collection in > some languages).. as this "later" stuff does not necessarily happen on the > original > thread. > > - Samuel > > > > Jun 6, 2023, 18:44 by h...@symas.com: > > Sam Dave wrote: > > Hi, > > The documentation for mdb_txn_begin() says "A transaction and its > cursors must only be used by a single thread, and a thread may only have a > single > transaction > at a time.". > > Does this also hold for mdb_txn_abort() for read-write transactions? > I.e. does the abort also have to happen on the same OS thread as all the > previous things > (begin, put, etc.)? > > > Calling mdb_txn_abort() requires passing the txn as a parameter, > which looks pretty suspiciously to me like "using" it. Is this really a > serious question? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: SSL timeout
Robert T Dunn wrote: > We are experiencing a problem with SSL timeout as reported with issue 8047: > https://bugs.openldap.org/show_bug.cgi?id=8047 > Our issue is when the LDAP client does an SSL connect to establish the TLS > session with the remote server. If the SERVER_HELLO returned from the remote > server > takes a significant amount of time or does not come back from the server at > all (for example, someone unplugged the server), the LDAP client connection > DOES NOT > timeout, and there are no LDAP configuration options to force the session to > timeout. So, the LDAP client connection is effectively hung forever. Issue > 8047 > reported the SSL timeout issue, but the issues status is still UNCONFIRMED. > Are there any plans to correct this problem in future versions of LDAP > Client? As noted in this reply https://bugs.openldap.org/show_bug.cgi?id=8047#c5 This is not ours to fix; the underlying TLS libraries must provide async connection support. > > > > > > Thanks, > > Rob Dunn > > > IBM z/TPFDF development > > email: strmb...@us.ibm.com <mailto:strmb...@us.ibm.com> > phone: (845) 433-1312 > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Two mdb_env_open() on same file/dir? Etc.
Sam Dave wrote: > Can two or more mdb_env_open() be called on the same file/directory (in same > program or multiple programs)? In the same program: no, read the Caveats http://www.lmdb.tech/doc/ In multiple programs: yes > > Can two or more mdb_dbi_open() be called to open ultimately the same database? This is explicitly documented http://www.lmdb.tech/doc/group__mdb.html#gac08cad5b096925642ca359a6d6f0562a > > What are some ramifications of doing so (and of course working with various > readonly/readwrite transactions, etc.) > > I don't see much written about this in documentation. Read more carefully. > > - Samuel -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP - CLDAP and SASL
Simon Pichugin wrote: > Hi folks, > I am currently experiencing an issue with IPA Server set up on Fedora 36, > using ipa-adtrust-install, and I'm unsure if this is due to a bug or > misconfiguration > on my part. > > Here's what I've done: > > I ran the following ldapsearch command: > > ldapsearch -LL -H cldap://server.example.com <http://server.example.com> > -b '' -s base 'dc=example,dc=com' > "(&(DnsDomain='dc=example,dc=com')(NtVer=\x06\x00\x00\x00)(AAC=\x00\x00\x00\x00))" > > On OpenLDAP 2.4.46, it was working fine, and it gave an output. > But OpenLDAP 2.6.2 and 2.6.4 fails with No such object (32) error. > > I used gdb to investigate and found that the error occurred here: > https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/common.c#L1530-1535 > > It executes ldap_sasl_interactive_bind, but it exits right in the beginning: > https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/sasl.c#L445-455 > > So back at: > https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/common.c#L1530-1535 > It exists the do-while loop right away and leaves with no result. > > I'm wondering if I missed something or if there was an oversight in the > implementation of this RFC, specifically regarding the CLDAP case: > https://git.openldap.org/openldap/openldap/-/commit/2ae62e86bc8ffab713fc4897f38461c31f2c79a8 > cldap doesn't support authentication or authorization of any kind. Just add "-x" to your ldapsearch invocation. > Looking forward to your thoughts! > > Best Regards, > Simon > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Debugging TLS negotiation failure
terry.lem...@dell.com wrote:
> Hi Howard
>
> Thanks very much for the reply and the suggestion. Here is the output of a
> ldapsearch command that completes successfully when I omit '-H
> ldaps://ldpdd042.hop.lab.emc.com:636':
The lack of any server reply to the client's Hello message strikes me as
probably a TLS version mismatch.
Check what versions of TLS libraries are in use on both the client and server,
and if they've been configured
to include or exclude any particular TLS versions.
Also, both slapd and the clients should be configured to use the self-signed
server cert as a CA cert.
>
> ldpdd042:~ # ldapsearch -d -1 -x -b 'dc=example,dc=com' '(objectclass=*)' -H
> ldaps://ldpdd042.hop.lab.emc.com:636
> ldap_url_parse_ext(ldaps://ldpdd042.hop.lab.emc.com:636)
> ldap_create
> ldap_url_parse_ext(ldaps://ldpdd042.hop.lab.emc.com:636/??base)
> ldap_sasl_bind
> ldap_send_initial_request
> ldap_new_connection 1 1 0
> ldap_int_open_connection
> ldap_connect_to_host: TCP ldpdd042.hop.lab.emc.com:636
> ldap_new_socket: 3
> ldap_prepare_socket: 3
> ldap_connect_to_host: Trying 10.247.229.42:636
> ldap_pvt_connect: fd: 3 tm: -1 async: 0
> attempting to connect:
> connect success
> TLS trace: SSL_connect:before SSL initialization
> tls_write: want=334, written=334
> : 16 03 01 01 49 01 00 01 45 03 03 a2 85 24 0b ee I...E$..
> 0010: 8f 28 13 34 a4 e5 6a c3 48 50 69 d7 81 72 96 02 .(.4..j.HPi..r..
> 0020: 7b 56 46 6a ec d0 f3 64 71 35 b2 20 fd 17 70 c9 {VFj...dq5. ..p.
> 0030: 15 23 3d 7c 31 66 99 84 f3 92 4b c7 a9 ab e2 f8 .#=|1fK.
> 0040: 5b b3 42 44 7e 91 f5 4b 9a 5b c9 b1 00 46 13 02 [.BD~..K.[...F..
> 0050: 13 03 13 01 c0 2c c0 30 cc a9 cc a8 c0 ad c0 2b .,.0...+
> 0060: c0 2f c0 ac c0 23 c0 27 c0 0a c0 14 c0 09 c0 13 ./...#.'
> 0070: 00 9d c0 9d 00 9c c0 9c 00 3d 00 3c 00 35 00 2f .=.<.5./
> 0080: 00 9f cc aa c0 9f 00 9e c0 9e 00 6b 00 67 00 39 ...k.g.9
> 0090: 00 33 00 ff 01 00 00 b6 00 00 00 1d 00 1b 00 00 .3..
> 00a0: 18 6c 64 70 64 64 30 34 32 2e 68 6f 70 2e 6c 61 .ldpdd042.hop.la
> 00b0: 62 2e 65 6d 63 2e 63 6f 6d 00 0b 00 04 03 00 01 b.emc.com...
> 00c0: 02 00 0a 00 0c 00 0a 00 1d 00 17 00 1e 00 19 00
> 00d0: 18 00 23 00 00 00 16 00 00 00 17 00 00 00 0d 00 ..#.
> 00e0: 30 00 2e 04 03 05 03 06 03 08 07 08 08 08 09 08 0...
> 00f0: 0a 08 0b 08 04 08 05 08 06 04 01 05 01 06 01 03
> 0100: 03 02 03 03 01 02 01 03 02 02 02 04 02 05 02 06
> 0110: 02 00 2b 00 09 08 03 04 03 03 03 02 03 01 00 2d ..+-
> 0120: 00 02 01 01 00 33 00 26 00 24 00 1d 00 20 49 ea .3.&.$... I.
> 0130: 8c 2a c7 1e 18 82 13 d1 46 3d 46 b0 b7 2b bd b2 .*..F=F..+..
> 0140: 6e 13 ec ab c5 fa 25 4d 4f cc 58 77 78 69 n.%MO.Xwxi
> TLS trace: SSL_connect:SSLv3/TLS write client hello
> tls_read: want=5, got=0
>
> TLS trace: SSL_connect:error in SSLv3/TLS write client hello
> TLS: can't connect: .
> ldap_err2string
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> ldpdd042:~ #
>
> Here's what was written to /var/log/messages:
>
> 2023-05-11T16:04:32.584581-04:00 ldpdd042 slapd[21376]: conn=1000 fd=12
> ACCEPT from IP=10.247.229.42:47346 (IP=0.0.0.0:636)
> 2023-05-11T16:04:32.594205-04:00 ldpdd042 slapd[21376]: connection_get(12)
> 2023-05-11T16:04:32.594295-04:00 ldpdd042 slapd[21376]: conn=1000 fd=12
> closed (TLS negotiation failure)
>
> I'm using a self-signed server certificate, so no CA should be involved. Not
> sure if that is causing the problem?
>
> Thanks!
> tl
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Debugging TLS negotiation failure
terry.lem...@dell.com wrote: > Hi > > I've followed the instructions in > https://www.openldap.org/doc/admin26/quickstart.html to deploy openldap 2.6.4 > on a SLES 15 SP4 system. Once I confirmed that this was working correctly, I > moved on to configure TLS, following the instructions in > https://www.openldap.org/doc/admin26/tls.html. When I try a connection to the > LDAPS port (636), I see the following: > > ldpdd040:~ # openssl s_client -connect ldpdd042.hop.lab.emc.com:636 If you're going to use openssl s_client you also need to tell it which CA and/or server certs to trust. I'd start with using ldapsearch -d -1 instead. > CONNECTED(0003) > 139702302594704:error:140790E5:SSL routines:ssl23_write:ssl handshake > failure:s23_lib.c:177: > --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 0 bytes and written 293 bytes > --- > New, (NONE), Cipher is (NONE) > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > No ALPN negotiated > SSL-Session: > Protocol : TLSv1.2 > Cipher: > Session-ID: > Session-ID-ctx: > Master-Key: > Key-Arg : None > PSK identity: None > PSK identity hint: None > SRP username: None > Start Time: 1683823897 > Timeout : 300 (sec) > Verify return code: 0 (ok) > --- > ldpdd040:~ # > > I'm using this command to start slapd: > /usr/local/libexec/slapd -F /usr/local/etc/slapd.d -s 3 -h "ldap:/// > ldaps:///" > > When I execute the openssl command above, I look in /var/log/messages and see: > > 2023-05-11T12:51:55.213884-04:00 ldpdd042 slapd[20101]: conn=1000 fd=12 > ACCEPT from IP=10.247.229.40:56844 (IP=0.0.0.0:636) > 2023-05-11T12:51:55.213944-04:00 ldpdd042 slapd[20101]: connection_get(12): > got connid=1000 > 2023-05-11T12:51:55.214004-04:00 ldpdd042 slapd[20101]: connection_read(12): > checking for input on id=1000 > 2023-05-11T12:51:55.214065-04:00 ldpdd042 slapd[20101]: connection_read(12): > TLS accept failure error=-1 id=1000, closing > 2023-05-11T12:51:55.214138-04:00 ldpdd042 slapd[20101]: connection_close: > conn=1000 sd=12 > 2023-05-11T12:51:55.214207-04:00 ldpdd042 slapd[20101]: conn=1000 fd=12 > closed (TLS negotiation failure) > ldpdd0 > > I've appended these lines to /usr/local/etc/openldap/slapd.conf: > > # Added TLS directives > # > TLSCACertificateFile/var/lib/ca-certificates/ca-bundle.pem > TLSCertificateFile /etc/ssl/private/server.cert > TLSCertificateKeyFile /etc/ssl/private/server.key > #TLSCipherSuite ALL > > I can't find any log information that helps me understand what the problem > is. I'm using a self-signed server certificate that has the cn using the FQDN > of the server. > > How can I debug this? > > Thanks! > tl > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: [About lmdb's write performance] mdb_txn_commit blocking for a long time
Wang Zhiyong wrote: > Hello all. > > We are using lmdb in our own storage service and recently found a write > performance issue. > The phenomenon is that lmdb batch write is very slow, and a write transaction > operation takes several minutes. > For example, if a transaction writes 100,000 kv, the average value size is > 100 bytes, and it takes 5 minutes. Sounds like you should use smaller batches. > The size of lmdb data file is 460G. > > The analysis using perf is as follows: > > 53.14% liblgraph.so[.] mdb_page_alloc.isra.21 > 46.81% liblgraph.so[.] mdb_midl_xmerge >0.01% [kernel][k] __check_object_size >0.01% [kernel][k] __do_page_fault >0.01% [kernel][k] __fput >0.01% [kernel][k] get_futex_value_locked >0.01% [kernel][k] radix_tree_descend >0.01% libpthread-2.17.so [.] __errno_location > > The cpu are consumed on the two functions mdb_page_alloc and mdb_midl_xmerge. > > By adding time statistics, I found that the blocking is in the > mdb_freelist_save function in mdb_txn_commit. > I'm not familiar with lmdb source code, can anyone explain why > mdb_freelist_save consumes so much time? > is this the expected result when lmdb data gets bigger? > Is there any way to restore the write performance after the write becomes > worse? > What is the suggestion to improve the write performance of lmdb? > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: olcDbCacheSize in back_mdb
Stefan Kania wrote:
> Looking at the openldap.org adminhandbook to 2.6 I found
> https://openldap.org/doc/admin26/overlays.html#The%20Proxy%20Cache%20Engine
Looks like you should file an ITS against the docs. olcDbCacheSize is a
back-bdb/hdb parameter, not back-mdb.
>
> The configuration for the databas for pcache:
>
> dn: olcDatabase={0}mdb,olcOverlay={0}pcache,olcDatabase={2}ldap,cn=config
> objectClass: olcMdbConfig
> objectClass: olcPcacheDatabase
> olcDatabase: {0}mdb
> olcDbDirectory: ./testrun/db.2.a
> olcDbCacheSize: 20
> olcDbIndex: objectClass eq
> olcDbIndex: cn,sn,uid,mail pres,eq,sub
>
> But I'm getting:
> -
> adding new entry
> "olcDatabase={0}mdb,olcOverlay={1}pcache,olcDatabase={1}ldap,cn=config"
> ldap_add: Undefined attribute type (17)
> additional info: olcDbCacheSize: attribute type undefined
> -
>
> The back_mdb module is loaded.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: question about manpage slapo-dynlist
Stefan Kania wrote: > Hi to all, > the manpage of the slapo-dynlist is showing the following example: > --- > A dynamic group with dgIdentity authorization could be created > with an entry like > > dn: cn=Dynamic Group,ou=Groups,dc=example,dc=com > objectClass: groupOfURLs > objectClass: dgIdentityAux > cn: Dynamic Group > memberURL: > ldap:///ou=People,dc=example,dc=com??sub?(objectClass=person) > dgIdentity: cn=Group Proxy,ou=Services,dc=example,dc=com > --- > I can't find an explanation of the attribute "dgIdentity", it's not mentioned > what is "cn=Group Proxy,ou=Services,dc=example,dc=com". > Can someone explain it please. Read more carefully. There is an entire section labeled AUTHORIZATION in the manpage for this. > Stefan > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: .so dynamic library versioning
Sam Dave wrote: > Hello, > > Thanks in advance for some clues on the below: > > 1. > Has there ever been a release of LMDB that adds/removes/changes API? There have been additions to the API over time. > 2. > On both Debian 10 (with lmdb 0.9.22) and Debian 11 (with lmdb 0.9.24) , under > lib/ I see > > liblmdb.so -> liblmdb.so.0 (symlink) > liblmdb.so.0 -> liblmdb.so.0.0.0 (symlink) > liblmdb.so.0.0.0 (the original file) > > Has this always been at 0.0.0 since the beginning of LMDB? From the point of > view of what the LMDB developers would expect, I mean. (I have no idea which > distros were distributing LMDB in the early days) > 3. > What are your intentions regarding this .so versioning in relation to > adding/removing/changes to the API? > Something like this, perhaps? > https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html > 4. > Another Linux distribution (NixOS 22.11, with lmdb 0.9.29) has *only* this > under lib/: > > liblmdb.so (the original file) > > Does this sound right to you? > What I mean is, when people compile LMDB down to an .so, would you expect > them to normally add a version after the ".so"? (As they apparently did in > Debian) Read the makefile and see. Currently liblmdb compiles down to about 110KB of x86-64 object code as a static library, and 125KB as a shared library. IMO it is a waste of effort to use it as a shared library since it's such a tiny piece of code; it should just be statically linked into every project that uses it. (Also the performance difference between static and dynamic linking is a measurable proportion of liblmdb runtime, so it's just better to build and link it statically.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Please help to check the right schema.
luckydog xf wrote:
> Hi, list,
>
> I'm trying to migrate opendj to openLDAP. Here is a customized schema.
> ===
> dn: cn=schema
> objectclass: top
> objectclass: ldapSubentry
> objectclass: subschema
> cn: schema
> attributeTypes: ( 1.12.23.34.45.56.780 NAME 'active' SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.7 X-SCHEMA-FILE '99-user.ldif' )
> attributeTypes: ( 1.12.23.34.45.56.782 NAME 'accountName' SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.15 X-SCHEMA-FILE '99-user.ldif' )
> attributeTypes: ( 1.12.23.34.45.56.784 NAME 'djGroups' SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.15 X-SCHEMA-FILE '99-user.ldif' )
> attributeTypes: ( 1.12.23.34.45.56.786 NAME 'departmentId' SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.15 X-SCHEMA-FILE '99-user.ldif' )
> attributeTypes: ( 1.12.23.34.45.56.788 NAME 'department' SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.15 X-SCHEMA-FILE '99-user.ldif' )
> attributeTypes: ( 1.12.23.34.45.56.790 NAME 'companyCode' SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.15 X-SCHEMA-FILE '99-user.ldif' )
> attributeTypes: ( 1.12.23.34.45.56.792 NAME 'parent' SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.15 X-SCHEMA-FILE '99-user.ldif' )
> ds-sync-generation-id: 8408
> ds-sync-state: 01050186432c61a9f9ca10880
> ds-sync-state: 0105017a002b3170002f4a1b16311
> modifiersName: cn=Administrator
> modifyTimestamp: 20190711063414Z
> objectClasses: ( 1.12.23.34.45.56.880 NAME 'idmExt' DESC 'idm user extended
> attributes' SUP top AUXILIARY MUST active MAY ( accountName $ djGroups $
> departmentId $ department $ companyCode ) X-SCHEMA-FILE
> '99-user.ldif' )
> objectClasses: ( 1.12.23.34.45.56.890 NAME 'idmDept' DESC 'idm department
> extended attributes' SUP top AUXILIARY MAY parent X-SCHEMA-FILE
> '99-user.ldif' )
> ===
>
> I changed it to LDAP compliant one.
LDIF files must not have blank lines within a single entry. You added an entry
with "cn" and no other attributes.
> ---
> dn: cn=djuser,cn=schema,cn=config
> objectClass: olcSchemaConfig
> cn: djuser
>
> olcAttributeTypes: ( 1.12.23.34.45.56.780 NAME 'active' SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.7 )
> olcAttributeTypes: ( 1.12.23.34.45.56.782 NAME 'accountName' SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.15 )
> olcAttributeTypes: ( 1.12.23.34.45.56.784 NAME 'djGroups' SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.15 )
> olcAttributeTypes: ( 1.12.23.34.45.56.786 NAME 'departmentId' SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.15 )
> olcAttributeTypes: ( 1.12.23.34.45.56.788 NAME 'department' SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.15 )
> olcAttributeTypes: ( 1.12.23.34.45.56.790 NAME 'companyCode' SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.15 )
> olcAttributeTypes: ( 1.12.23.34.45.56.792 NAME 'parent' SYNTAX
> 1.3.6.1.4.1.1466.115.121.1.15 )
>
> olcObjectClasses: ( 1.12.23.34.45.56.880 NAME 'idmExt' DESC 'idm user
> extended attributes' SUP top AUXILIARY MUST active MAY ( accountName $
> djGroups $
> departmentId $ department $ companyCode ) )
> olcObjectClasses: ( 1.12.23.34.45.56.890 NAME 'idmDept' DESC 'idm department
> extended attributes' SUP top AUXILIARY MAY parent )
>
> -
> It can be imported by `ldapadd -Y EXTERNAL -H ldapi:/// -f 99-user.ldif`
> However, there is nothing in
> ===
> [root@hq-repo cn=config]# more cn\=schema/cn\=\{10\}djuser.ldif
> # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
> # CRC32 310b21fa
> dn: cn={10}djuser
> objectClass: olcSchemaConfig
> cn: {10}djuser
> structuralObjectClass: olcSchemaConfig
> entryUUID: 6b852150-4b97-103d-86fe-7b79b4eef873
> creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> createTimestamp: 20230228093837Z
> entryCSN: 20230228093837.038174Z#00#000#00
> modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> modifyTimestamp: 20230228093837Z
>
> ===
> I'm using openldap 2.4.
> Anything wrong with my schema ?
>
> Thanks.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Antw: [EXT] Re: Entering Multi-Byte Values for DirectoryString attributes
Howard Chu wrote: > Ede Wolf wrote: >> >>> Hi! >>> >>> I'd say: Get the proper app (eg. BabelPad on Windows, see attachment) and >>> then BASE64-encode the string. >>> >>> Regards, >>> Ulrich >>> >> >> Thanks, but windows is not an option. Again, base64 encoding is fine with >> echo -en "" | base64. >> With a browser I can search for the symbol and do copy paste into the ldif. >> All that works fine, even if my console font does not even support that >> symbol. I've >> done it. But feels a bit hackish. >> >> I just hoped, there was an option, to tell the server, when the ldif has >> this sequence, interpret it as an ecoding, not as a literal string. >> Now I know, this does only work for the dn (and maybe only openldap, will >> test, see other post), and for the rest I do have a work around. >> > The server doesn't do any reprocessing on the received strings Never mind this message. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Antw: [EXT] Re: Entering Multi-Byte Values for DirectoryString attributes
Ede Wolf wrote:
>
>> Hi!
>>
>> I'd say: Get the proper app (eg. BabelPad on Windows, see attachment) and
>> then BASE64-encode the string.
>>
>> Regards,
>> Ulrich
>>
>
> Thanks, but windows is not an option. Again, base64 encoding is fine with
> echo -en "" | base64.
> With a browser I can search for the symbol and do copy paste into the ldif.
> All that works fine, even if my console font does not even support that
> symbol. I've
> done it. But feels a bit hackish.
>
> I just hoped, there was an option, to tell the server, when the ldif has this
> sequence, interpret it as an ecoding, not as a literal string.
> Now I know, this does only work for the dn (and maybe only openldap, will
> test, see other post), and for the rest I do have a work around.
>
The server doesn't do any reprocessing on the received strings. The escaping
was done by the client
(or libldap) when parsing your input. The server only processes UTF-8. You can
see this in the slapd
logs associated with the example ops I sent before:
63f4fd23.22d06a0c 0x7f1ceadfe640 conn=1004 op=1 do_add
63f4fd23.22d07cdf 0x7f1ceadfe640 ber_scanf fmt ({m) ber:
63f4fd23.22d08b9b 0x7f1ceadfe640 conn=1004 op=1 do_add: dn (cn=
face,ou=people,dc=example,dc=com)
The escaping is purely a client-side concern.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Entering Multi-Byte Values for DirectoryString attributes
Ondřej Kuzník wrote: > On Tue, Feb 21, 2023 at 05:32:01PM +0100, Ede Wolf wrote: >> Hello Ondřej, >> >> Thanks very much! That is exactly the anwer I have been looking for - even >> more so in fact, as additionally I have been educated, that the dn is a >> different part from the rest of the ldif. Makes sense, but I've never really >> thought of this before. > > Correction: the dn is the same as anything else in the LDIF, it is the > server that then does extra processing on the text it receives because > its syntax is a DN, just like a 'member' attribute, 'seeAlso' and others > like them will allow you to do the same - they are of the distinguished > name syntax. Or like with the 'cn' attribute you can write 'TEST' or > 'tEst' and they will be considered equivalent, because its syntax says > so, not because the client did anything. > > Regards, > For example: viola:~/OD/hobj/tests> cat emoji.ldif dn: cn= face,ou=people,dc=example,dc=com objectclass: person cn: face sn: face viola:~/OD/hobj/tests> ../clients/tools/ldapmodify -x -a -H ldap://:9011 -D cn=manager,dc=example,dc=com -w secret -f emoji.ldif adding new entry "cn= face,ou=people,dc=example,dc=com" viola:~/OD/hobj/tests> ../clients/tools/ldapse ldapsearch* ldapsearch.sleep* viola:~/OD/hobj/tests> ../clients/tools/ldapsearch -x -H ldap://:9011 -b ou=people,dc=example,dc=com '(cn= face)' # extended LDIF # # LDAPv3 # base with scope subtree # filter: (cn= face) # requesting: ALL # # \F0\9F\98\80 face, People, example.com dn:: Y2498J+YgCBmYWNlLG91PVBlb3BsZSxkYz1leGFtcGxlLGRjPWNvbQ== objectClass: person cn:: 8J+YgCBmYWNl sn: face # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Entering Multi-Byte Values for DirectoryString attributes
Ede Wolf wrote: > Am 20.02.23 um 18:06 schrieb Howard Chu: >> Ede Wolf wrote: >>> Hello, >>> >>> This is probably more a ldif than an OpenLDAP question, but still, maybe >>> somebody knows the answer: Is there a way to put multibyte characters into >>> an attribute >>> value and let the server know, these are not to be treated literally, but >>> are utf8 character encodings? >> >> Strings in LDAPv3 are all UTF-8, by definition. This is in RFC4511 section >> 4.1.2. > > ... > >> base64 encoding for LDIF values is mostly optional. As long as the string >> you're entering doesn't have >> embedded NUL or CR/LF characters, you don't need to use base64. > > Thanks very much. Please, but how can I provide a non ascii character, that > is not on my keyboard, for which I only have the code point or the hex > values. Like > I can do within the dn The same way you would enter Unicode in any other application. This is not an LDAP- or LDIF-specific question. 1) use a terminal and locale that support UTF-8. 2) use whatever tools your OS provides for entering Unicode characters. Probably something named "Unicode character map" or similar. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenSSL1.1.1 support after its EOL
Anil 1. Tadikamalla (EXT-NSB) wrote: > Hi Howard, > > >>From your response we understood that OpenLDAP2.4.52 will continue the >>support of OpenSSL1.1.1 version. Can you let us know EOL of OpenLDAP 2.4.52 >>version? That was already posted on the openldap-annoounce list. You should not ask questions about information that is already publicly available. https://lists.openldap.org/hyperkitty/list/openldap-annou...@openldap.org/thread/5RJ3FXOE2C3UGJSHOV4AIR4DXEPPWD6P/ https://lists.openldap.org/hyperkitty/list/openldap-annou...@openldap.org/thread/IHS5V46H6NFNFUERMC6AWMPHTWRVNLFA/ > > If we upgrade OpenLDAP to 2.6.2 version, is OpenSSL 1.1.1 still supported? Yes. > If yes, can you please let us the EOL of OpenLDAP2.6.2 version? The EOL for 2.6 series has not been defined yet. The current release is 2.6.4. > > We understood that OpenLDAP project distribute source code. Our query is how > OpenLDAP uses OpenSSL. Does OpenLDAP depend on OS (Like RHEL, Windows etc) > for OpenSSL support or Does it include OpenSSL source code too as part of > OpenLDAP source code distribution? It is an open source project. Examine the source code yourself. > > Can you also let us know the OpenLDAP version that includes support for > OpenSSL3.0 ? Already answered in previous email, which you quoted below. Apparently without reading. > Regards, > Anil Kumar > > ------------ > *From:* Howard Chu > *Sent:* Tuesday, December 13, 2022 10:11 AM > *To:* Anil 1. Tadikamalla (EXT-NSB); openldap-technical@openldap.org > *Cc:* Seenivasan 1. Alagarsamy (EXT-NSB) > *Subject:* Re: OpenSSL1.1.1 support after its EOL > > Anil 1. Tadikamalla (EXT-NSB) wrote: >> Hi Team, >> >> Can you please help to address below queries ASAP from OpenLDAP point of >> view: >> >> 1. Please do let us know if OpenLDAP can provide extended support of >>OpenSSL1.1.1 beyond the EOL(End of life cycle) i.e after september 2023? > > We have no plans to delete support for OpenSSL 1.1.1. >> >> 2. Does OpenLDAP depend on RHEL for OpenSSL support or Does it package >>OpenSSL on its own? > > The OpenLDAP Project distributes source code. Not binary packages. This > question is inapplicable. > >> If it depends on RHEL and RHEL introduces OpenSSL3.0 support, how >> would this be handled by OpenLDAP? > > This question is inapplicable. RHEL does not support OpenLDAP, and OpenLDAP > has no dependencies on RHEL. > > OpenLDAP 2.6 includes support of OpenSSL 3.0. > >> >> Regards, >> Anil Kumar >> >> >> *From:* Anil 1. Tadikamalla (EXT-NSB) >> *Sent:* Friday, December 9, 2022 9:54:28 AM >> *To:* openldap-technical@openldap.org >> *Cc:* Seenivasan 1. Alagarsamy (EXT-NSB) >> *Subject:* Re: OpenSSL1.1.1 support after its EOL >> >> >> Hi Team, >> >> GENTLE REMINDER >> >> >> Can you please help to address below query to from OpenLDAP Point of View >> ASAP. >> >> Does OpenLDAP depend on RHEL for OpenSSL support or Does it package OpenSSL >> on its own? If it depends on RHEL and RHEL introduces OpenSSL3.0 support, >> how would >> this be handled by OpenLDAP? >> >> Regards, >> >> Anil Kumar >> >> >> >> *From:* Anil 1. Tadikamalla (EXT-NSB) >> *Sent:* Friday, December 9, 2022 12:53 AM >> *To:* openldap-technical@openldap.org >> *Cc:* Seenivasan 1. Alagarsamy (EXT-NSB) >> *Subject:* OpenSSL1.1.1 support after its EOL >> >> >> Hi Team, >> >> >> Please do let us know if OpenLDAP can provide extended support of >> OpenSSL1.1.1 beyond the EOL(End of life cycle) i.e after september 2023? >> >> >> Regards, >> >> Anil Kumar >> > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Entering Multi-Byte Values for DirectoryString attributes
Ede Wolf wrote: > Hello, > > This is probably more a ldif than an OpenLDAP question, but still, maybe > somebody knows the answer: Is there a way to put multibyte characters into an > attribute > value and let the server know, these are not to be treated literally, but are > utf8 character encodings? Strings in LDAPv3 are all UTF-8, by definition. This is in RFC4511 section 4.1.2. > > I've tried to dig into rfc3629 and 4517, but those were above my capabilities. > > It does of course work for the dn, it also works, if I provide base64 code to > the attributes, but is there a way, to directly put them into a ldif an let > the > server know, these are character encodings? > Also, rfc2849 only talks about not line breaking multi-byte characters. base64 encoding for LDIF values is mostly optional. As long as the string you're entering doesn't have embedded NUL or CR/LF characters, you don't need to use base64. > > In this silly, but easy, example, both cn: and description: are entered > literally, while the dn words as intended: > > dn: cn=A \F0\9F\99\82 Test,dc=example,dc=com > cn: A \F0\9F\99\82 Test > objectClass: person > sn: Test > description: %xF0%x9F%x99%x82 Test > > This is about understanding, not about the intention, to really put a smily > into a dn. I am aware, this a potential recipe for disaster. > > Also, I am aware, the OpenLDAP kindly adds a proper cn value anyway, but that > does not help here. And still would leave the description open. > > Also, as mentioned before: > echo -en "A \xF0\x9F\x99\x82 Test" | base64 > is a viable workaround, but a cumbersome one. > > So maybe there is an easier way > > Thanks > > Ede > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: "container" structural class
Timothy Stonis wrote: > Hi All, > > I’ve searched the internet, but can’t find any info, so sorry in advance if > this is a basic question… I’m trying to setup a “standard” DIT in an OpenLDAP > 2.6.3 deployment. I checked out my existing Active Directory deployment and > also an old macOS Server implementation, and they both make heavy use of the > “container” structural class. For example, users are in cn=users,dc=…,dc=… > which is objectClass container. I see this class is defined in the msuser > schema, but in 2.6.3 it’s definition is commented out in the msuser.schema > file. > > Can anyone help shed some light on why this is the case Read the msuser.schema comments more carefully. # Only the subset of Windows 2012 attributes needed to make the # user and group objectclasses work has been added to the previously # retrieved definitions. It may or may not work for you to uncomment other schema elements. Certainly has not been tested by us. > and maybe a pointer to what a modern best practices DIT might look like? > > Thanks in advance > > Tim > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: using SRV-records in syncrepl
Norman Gray wrote: > > Ondřej, hello. > > On 20 Jan 2023, at 10:47, Ondřej Kuzník wrote: > >> That said, patches implementing some kind of SRV are welcome. The easiest >> way might be to introduce an lloadd tier implementation that manages its >> backend collection accordingly. > > It's not an OpenLDAP patch, but I've attached a module which might be of > interest here. This exposes a function > > char* get_sorted_srv_records(const char* domain); > > which does a SRV lookup, and orders the records that come back according to > the specification of RFC 2782 (though in a single pass, rather than the > clumsy multiple pass algorithm that the RFC suggests). libldap already provides this functionality in ldap_domain2hostlist(). -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Antw: [EXT] Re: Slow Mod operations on LDAP
Quanah Gibson-Mount wrote: > > > --On Thursday, January 19, 2023 8:25 AM +0100 Ulrich Windl > wrote: > >>>>> Quanah Gibson-Mount schrieb am 18.01.2023 um >>>>> 14:50 in >> Nachricht <3D6804DEBBC5413284159965@[192.168.1.14]>: >> >> ... >>> I would note that it is not advised to use XFS with back-mdb. >> >> Would you explain why? Here we use XFS for all database filesystems. > > The filesystem journaling done by XFS is not required for back-mdb databases > and imposes a significant performance penalty for write operations. Unlike > ext4 > partitions it is not possible to disable the filesystem journal. The best > option for back-mdb databases on XFS is to tell XFS to use a external journal. Comparison of LMDB performance across various filesystems http://www.lmdb.tech/bench/microbench/july/#sec11 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: questions on index_hash64
Geert Hendrickx wrote: > Hi > > > I have a few questions on the index_hash64 / olcIndexHash64 feature; > > >> Use a 64 bit hash for indexing. The default is to use 32 bit hashes. >> These hashes are used for equality and substring indexing. The 64 bit >> version may be needed to avoid index collisions when the number of >> indexed values exceeds ~64 million. (Note that substring indexing >> generates multiple index values per actual attribute value.) Indices >> generated with 32 bit hashes are incompatible with the 64 bit version, >> and vice versa. Any existing databases must be fully reloaded when >> changing this setting. This directive is only supported on 64 bit CPUs. > > > What is the effect if hash collisions happen? Will slapd actually return > incorrect results, or does it just need to perform extra work to discard > false positives from an index search result? slapd will never return incorrect results. It will just have to do extra work. > Since this feature only impacts indexes and not data, isn't "slapindex" > enough to to regenerate indexes, instead of a full slapcat/slapadd ? Yes, using the truncate option to delete the old indices. > Finally, is there some way to detect if a given data.mdb file uses 32- or > 64-bit index hashes? I can load a "legacy" data.mdb in a server with > index_hash64 enabled, and slapd does not complain, indexes are just broken. You can simply look at the size of the keys of the index tables. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: about slapo totp
Bastian Tweddell wrote: > While working on this matter I discovered that there is not only > the slap-totp contrib module, but also the slapo-otp openldap module. > > With that one, I managed to get bind-authentication + 2FA to work; > thanks to the test code in openldap. This work so far when the user > entry has a userPassword attribute and is allowed to bind. The bind call > also gives the userpassword and 2FA token in the credentials. > > Now I would like to achieve, that only TOTP authentication is done. > Would this be possible with slapo-otp? Or am I in a dead end here? Use the contrib module instead, it only does TOTP and nothing else. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: about slapo totp
Bastian Tweddell wrote:
> On 17Jan23 17:33+0000, Howard Chu wrote:
>> Sounds more like a question for your SSH server, and whether you can
>> configure it to use PAM
>> after a successful pubkey authentication.
>
> Yes, PAM is enabled for sshd.
>
> I do not have the full picture how slap-totp works. For me, there two
> open questions:
>
> 1. From openldap pov:
>How would I make the bind call to slapd, so that only
>the TOTP is checked?
If you're talking about the totp module in the contrib source directory, all
you need
to do is a normal LDAP Simple Bind. LDAP modules for PAM would do this already.
>Would the following be sufficient to achieve 2FA only:
>
>```ldif:
> userPassword: {TOTP512}$BASE64
> # assuming the overlay is confgured properly
>```
Yes.
>Would it be possible to use another attribute than `userPassword`?
Not with the existing code, no.
>
> 2. PAM integration: This is not a question to this group here, but maybe
>there are some related ideas.
>How or which PAM module can be used?
nsspam-ldapd / nslcd, whatever the latest supported version is.
>
>
> The aim is to avoid copying the TOTP secret of users to the local
> systems (which are the public accessible hosts).
>
>
> Many thanks,
> Cheers,
> --
> Bastian Tweddell Juelich Supercomputing Centre
> phone: +49 (2461) 61-6586 HPC in Neuroscience, HPS
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: about slapo totp
Bastian Tweddell wrote: > Dear all, > > I am investigating if it is possible to use the TOTP overlay in the > following concept: > > Many thanks for any > > - nis related data of users are in ldap > - user ssh access to the system is pubkey only > - after successful authentication also request TOTP via PAM call to > slapd (only TOTP, no password) > > > Does this make sense and can this be achieved? Sounds more like a question for your SSH server, and whether you can configure it to use PAM after a successful pubkey authentication. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Q: incrementally adding LDIF entries using ldapadd
Ulrich Windl wrote:
> Hi!
>
> I'm working on a program that "mangles" existing LDIF files so that the LDAP
> server accepts them.
> So say 75% passed, 25% had errors (need additional fixes).
>
> I'm using ldapadd with "-c" (continue) and "-S skipped.ldif" (skipped
> entries) to add the input LDIF.
>
> The idea was to iterate over skipped.ldif until the file is empty, i.e.: make
> skipped.ldif the new input file for the next run of ldapadd.
> However "skipped.ldif" also contains entries that were skipped, because they
> had been imported (successfully) before ("ldap_add: Already exists (68)").
>
> Is there an easy way to extract only those entries that were not added?
>
> Of course I could write a program that implements that logic, talking to the
> LDAP server directly, but if avoidable I'd save the time to write such a
> program.
Don't use -c, fix errors as they appear, and use -j to resume.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: VRF support in openldap
tisha...@gmail.com wrote: > Hi Howard, > > Sorry for the confusion. I meant virtual routing and forwarding(VRF), where > in we will have to bind the socket to a particular vrf-id when connecting to > ldap-server. In Linux you must explicitly bind a socket to a VRF, as doc'd here https://docs.kernel.org/networking/vrf.html After you've bound your socket, you can give it to libldap with ldap_init_fd() and then use it normally thereafter. > > Thanks, > Smitha > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Queries regarding Openldap migration from 2.4.51 to 2.6.2
Nagesh Nikavade (EXT-NSB) wrote: > Hi Team, > > > > We are migrating openldap from 2.4.51 to 2.6.2 and we have the following > queries > > > > 1. What is the End of life date for 2.4.x series? September 2021. https://lists.openldap.org/hyperkitty/list/openldap-annou...@openldap.org/thread/5RJ3FXOE2C3UGJSHOV4AIR4DXEPPWD6P/ > 2. OpenLdap 2.6.x doesnt have BDB Data base Support but has MDB, but in our > existing machines where 2.4.51 is installed. Our data is populated in .BDB > files. So is there is any guide where and how our data will be migrated > from .*BDB format* to *.MDB format *? Same as for any other upgrade. slapcat / slapadd. Read the Admin Guide. > 3. There is a utility *db_verify* which verifies *.BDB *files which is not > working for *.MDB files. *What is utility to *verify .MDB data files?* There is no such utility. LMDB is corruption proof. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: VRF support in openldap
tisha...@gmail.com wrote: > Hi, > > I would like to know is there any support for passing vrf-id to openldap > library ? VRF in OpenLDAP means ValueReturnFilter, which has been supported for years. Look at the ldapsearch(1) manpage, or read the ldapsearch source code. > > Thanks, > Smitha > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
