Re: How to determine olcDbMaxSize
--On Friday, August 27, 2021 6:27 PM +0100 Howard Chu wrote: My db does not come close to that but was curious how one can determine what the db size is currently ? Current size is irrelevant. Maxsize is the maximum you want to allow the DB to grow. This should be the amount of free space on the filesystem, minus any space you want to leave for other applications. This is why the man page literally says to set it to as large of a value as possible. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: OpenLDAP 2.5.7 dies
--On Friday, August 27, 2021 11:44 AM -0500 kevin martin
wrote:
41720 sendto(3, "<165>Aug 27 15:36:40 slapd[41718]: ppm: entry
uid=kmart,ou=people,dc=lecpq,dc=com", 87, MSG_NOSIGNAL, NULL, 0) = 87
41720 getpid() = 41718
41720 sendto(3, "<165>Aug 27 15:36:40 slapd[41718]: ppm: Reading
pwdCheckModuleArg attribute", 75, MSG_NOSIGNAL, NULL, 0) = 75
41720 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8} ---
41718 <... futex resumed>) = ?
41720 +++ killed by SIGSEGV +++
41719 <... epoll_wait resumed> ) = ?
41719 +++ killed by SIGSEGV +++
41718 +++ killed by SIGSEGV +++
still now coredump file. I'll try changing the kernel.core_pattern and
see if we get something somewhere.
Coredumps are often useless because they lose key information. You want to
get a trace under gdb while the process is executing.
Start slapd
gdb /path/to/slapd PID
(gdb) cont
execute the command that crashes slapd
at the gdb prompt:
gdb thr apply all bt full
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Re: OT: Net:LDAPapi / LDAPS-Support?
--On Thursday, August 26, 2021 8:57 PM +0200 "A. Schulze" wrote: Am 25.08.21 um 17:43 schrieb Quanah Gibson-Mount: I took over a service using the Perl NET::LDAPapi. Now I fail to establish an LDAPS connection. Does anybody know if that's even supported and if so, how I've to setup that? Yes, it's fully supported and has been as long as I've used it (about 2 decades now). For ldaps:// connections, you need to pass in an ldaps:/// URI. It will pull its defaults for TLS like any other libldap linked ldap application. Hello, thanks Quanah, for that clarification. I only found [1] that promise TLS-Support when build with a "Mozilla SDK" I also checked I used ldaps:/// (with three /). LDAPTLS_CACERT was also set, as Michael suggested. ldaps:/// wouldn't be valid by itself, unless you were connecting to the localhost. I.e., ldaps://my.domain.com:636/ would be valid (or just ldaps://my.domain.com/ if listening on 636 by default). The documentation hasn't been touched in years. I don't think it even supports compiling against the abandoned mozilla SDK At this point. It will support whatever support libldap has been compiled with. The primary reason to use Net::LDAPapi is if speed is a concern, as it is significantly faster than Net::LDAP. If it isn't of a concern, then Net::LDAP is fine. Generally I consider Net::LDAPapi abandonware. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: /usr/local/etc/openldap/slapd.conf: line 39: scheme not available ({SHA512})
--On Thursday, August 26, 2021 12:38 PM -0500 kevin martin wrote: so I sb able to take the pw-sha2 module that I compiled for RHEL7 and simply move it over to RHEL8? Ugh, so ugly that we can't remake the module on RHEL8 (is it unsupported?) due to missing dependencies... The pw-sha2 module has no dependencies on any radius libraries. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: /usr/local/etc/openldap/slapd.conf: line 39: scheme not available ({SHA512})
--On Thursday, August 26, 2021 12:32 PM -0500 kevin martin wrote: pw-ssha? I had a pw-sha2 module loaded but not pw-ssha. and the password module won't compile at this time because there's no radius-devel package for RHEL 8 that I can find in any repos. Sorry, pw-sha2 module. ;) If you have it instantiated and things aren't working, it would appear it's not actually loading as desired. But it's worked fine for me with existing 2.4 -> 2.5 configuration migrations, so this would be something different on your end. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: openSUSE/SLE users, migrate to back-mdb now!
--On Thursday, August 26, 2021 10:49 AM +0200 Michael Ströder wrote: On 8/26/21 9:41 AM, Ulrich Windl wrote: Honestly I'm quite afraid of the "space explosion" that seems to be an inherent feature of MDB. 8-( It's hard to tell about which problem you're talking without the usual technical details: - OS version - OpenLDAP version - which packages you're using - detailed example data In my personal experience in customer projects migrating to back-mdb is a no-brainer. Just do it now. back-mdb databases are literally smaller than the same back-bdb/hdb db, so I've no clue what is being refernced here either. It is true in some early releases of back-mdb there were some issues with fragmentation but that's been dealt with. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: /usr/local/etc/openldap/slapd.conf: line 39: scheme not available ({SHA512})
--On Thursday, August 26, 2021 11:55 AM -0500 kevin martin
wrote:
while trying to convert from a slapd.conf file to a cn=config style,
slaptest displays the error as shown in the subject line. openldap 2.4
supported "password-hash {SHA512}" in the slapd.conf, is this simply an
issue of password-hash not being able to be converted or is that
*particular* password-hash line unsupported in the latest 2.5 (building
from source)?
It has always required that the pw-ssha contrib module exist and be loaded
in the configuration. 2.5 is no different than 2.4 in this.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Re: 2.5.7 for RHEL8 - Question
--On Wednesday, August 25, 2021 3:57 PM -0400 Dave Macias wrote: Awesome! So then, if it's already shipped, why dont I see the schema files for ppolicy? Would have thought to find it here: /opt/symas/etc/openldap/schema I strongly advise reading the OpenLDAP 2.5 admin guide section on upgrading, specifically: <https://www.openldap.org/doc/admin25/appendix-upgrading.html#ppolicy%20overlay> which directly answers your question. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: 2.5.7 for RHEL8 - Question
--On Wednesday, August 25, 2021 2:33 PM -0400 Dave Macias wrote: Thank you Quanah for the response! Makes sense. One more question: under: /opt/symas/etc/openldap/schema/README It says that ppolicy is ppolicy.schema Password Policy Schema (work in progress) If i'm not mistaken, this would be the new ppolicy10 , yes? https://datatracker.ietf.org/doc/html/draft-behera-ldap-password-policy-10 Actually that should be deleted from the README, thanks. But yes, the ppolicy shipped with OpenLDAP 2.5 is based on draft 10, as documented in the man page. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: 2.5.7 for RHEL8 - Question
--On Wednesday, August 25, 2021 2:17 PM -0400 Dave Macias wrote: Without doing any configuration, I attempted to start the slapd but /opt/symas/etc/openldap/slapd.conf did not exist, since it was /opt/symas/etc/openldap/slapd.conf.default . Which was an easy name change. After that the slapd service started without issues. My question is, why are the pkg files now under /opt? Two reasons: a) It preserves the installation paths of the Symas OpenLDAP Gold product b) Installation paths are identical regardless of host OS. While RHEL8 has dropped OpenLDAP server support, other OSes have not. Additionally, RedHat has not stopped shipping the 2.4 libldap, so we still need isolation at that level. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: OT: Net:LDAPapi / LDAPS-Support?
--On Wednesday, August 25, 2021 1:46 PM +0200 "A. Schulze" wrote: Hello, I took over a service using the Perl NET::LDAPapi. Now I fail to establish an LDAPS connection. Does anybody know if that's even supported and if so, how I've to setup that? Yes, it's fully supported and has been as long as I've used it (about 2 decades now). For ldaps:// connections, you need to pass in an ldaps:/// URI. It will pull its defaults for TLS like any other libldap linked ldap application. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: OpenLDAP 2.5.5 PPA for Ubuntu 20.04 LTS
--On Tuesday, August 24, 2021 10:47 AM +0200 Saša-Stjepan Bakša wrote: Hi Quanah, Long time has passed since our last conversation. :-) Thank you for your info. I was looking around your site and didn't find this repo. Are those commercial release packages or public? Yes. :) It's our replacement for Symas OpenLDAP for Linux and Symas OpenLDAP for Gold. They are free to use and optional support contracts are available. We're currently working on an official announcement to post, but thought I'd point you at them since they're ready from the technical perspective. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: OpenLDAP 2.5.5 PPA for Ubuntu 20.04 LTS
--On Monday, August 23, 2021 3:15 PM +0200 Saša-Stjepan Bakša wrote: Does anyone maintain PPA for OpenLDAP 2.5.5 PPA for Ubuntu 20.04 LTS? On the Symas page, there is a package only for 2.4.59+dfsg-1ppa~bionic1 and since Quanah recommends the latest version for using dynlist I am in a bit of a problem. I just can't find the proper deb package for Ubuntu. Hi Saša-Stjepan Bakša, Symas OpenLDAP 2.5 can be obtained from: <https://repo.symas.com/soldap/ubuntu20/> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Antw: [EXT] Re: migrate from 2.4 to 2.5, determine existing MDB format
--On Friday, August 20, 2021 10:05 AM +0200 Ulrich Windl wrote: Hi! It might get interesting if you sync cn=config, however. cn=config uses back-ldif not back-mdb, and even if it was using back-mdb, it still wouldn't matter for the internal format change to back-mdb. I would also note that there are critical problems with cn=config replication in 2.4 so people shouldn't be doing that anyway. The issues we know of were fixed in 2.5, so that's the first release where I'd consider replication of cn=config. However, there are likely incompatibilities between 2.4 and 2.5 for cn=config replication. The fact that 2.5's ppolicy no longer uses a schema file for example. But again, people should not be using cn=config replication in 2.4. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: migrate from 2.4 to 2.5, determine existing MDB format
--On Thursday, August 19, 2021 1:35 PM -0500 kevin martin wrote: i understand that ldap is a protocol but it occurred to me that a database change (where tables and the like might be different and slapd version dependent) might need to be a sitewide thing, not a server by server thing (meaning the 2.4 servers, once the "database" is mirrored from the master server, might not understand the new format?). The only limitation would be that you could not mdb_copy a 2.5 database and run that under a 2.4 slapd. Since it's purely internal, the replication protocol has no "knowledge" of it, and it would not appear in an LDIF created by slapcat. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: pwdHistory setting not being honored
--On Thursday, August 19, 2021 1:17 PM -0500 kevin martin wrote: we HAD a password history setting with ppolicy to store 10 passwords in history, and that worked fine. Now, our policy has changed and only the last 4 passwords can't be used but when I try to change to a password that I know was not in the last 4 password changes I'm told that the password exists in my history. looking at an ldif dump my user has 10 pwdHistory entries but shouldn't the change in policy cause slapd to only look at my last 4 most recent pwdHistory entries, because it's certainly not doing so. do I have to dump the ldap into an ldif, remove pwdHistory entries, and reload it to make the password history stuff work correctly? version of slapd is 2.4.45. This is <https://bugs.openldap.org/show_bug.cgi?id=8349> Fixed in OpenLDAP 2.4.48. I strongly advise upgrading to current supported release for many reasons. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: migrate from 2.4 to 2.5, determine existing MDB format
--On Thursday, August 19, 2021 1:23 PM -0500 kevin martin wrote: if I have multiple slapd servers running 2.4 can I update my master server to 2.5 with the new format and will the 2.4 mirrors be able to handle the new format or is it an all or nothing upgrade of all servers at once? LDAP is a protocol, the internal change to the MDB database structure is immaterial. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Antw: [EXT] Re: Index seems to return wrong amount of candidate causing really poor search performance
--On Thursday, August 19, 2021 9:18 AM +0200 Ulrich Windl wrote: Still I'm slighly confused: If the default is 16 and you set it to (let's say) 18, by which power of two will the value be increased? 2^18 - 2^16 is not a power of 2, so you could increase the value three times by 2^16 (one to make 2^17, and another two to make 2^18). But I still guess the value is simply set to 2^18, whatever the increase from the default might be. If the value is 16, it will be 2^16 = 65536. If the value is 18, it will be 2^18 which is 262,144. So yes, the difference between them isn't a power of 2, but the point was the max value is always a power of 2. I would also note that every increment will cause slapd to require more memory. Larger values (such as 30) would require several terrabytes of RAM for slapd to function. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Antw: [EXT] Re: Index seems to return wrong amount of candidate causing really poor search performance
--On Wednesday, August 18, 2021 9:15 AM +0200 Ulrich Windl wrote: idlexp value increases the index slot range by a power of 2. The largest Did you mean "to a power of 2", or do you really mean "by a power of 2"? It increases by a power of 2, as documented in the man page. idlexp _exp_ Specify a power of 2 for the maximum size of an index slot. The default is 16, yielding a maximum slot size of 2^16 or 65536. Once set, this option applies to every mdb database instance. The specified value must be in the range of 16-31. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Index seems to return wrong amount of candidate causing really poor search performance
--On Tuesday, August 17, 2021 11:08 AM + Petteri Stenius wrote: Thank you. This information is very helpful. I think you need logging level "trace" (not "acl") to see the "mdb_index_read NN candidates" log entries. Yes, you are correct, trace indeed. :) Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Index seems to return wrong amount of candidate causing really poor search performance
--On Monday, August 16, 2021 10:00 PM + Petteri Stenius wrote: Thank you for your quick response. If idlexp is the accepted solution then I'd like to understand how to choose correct value for idlexp? I have quickly tested with most values. With my quick tests I could not find any significant impact on performance. Setting idlexp to maximum 31 did however cause slapd to crash with segmentation fault on my system. The appropriate value for any environment is entirely dependent on that environment's indexing and attribute value distribution for those indexed attributes. You generally want the minimum value for idlexp that allows searches to function without performance problems. Increasing the idlexp size increases slapd memory usage. Keep in mind that every increase in the idlexp value increases the index slot range by a power of 2. The largest value I've ever needed for a massively large db with wide value distributions was 22. "acl" level logging of slapd will show the candidate result sets for a query. For example on a db of approximately 6.4 million entries: 5f9496ad mdb_idl_fetch_key: [d393480d] 5f9496ad <= mdb_index_read 6463387 candidates 5f9496ad => key_read 5f9496ad mdb_idl_fetch_key: [9d5c550b] 5f9496ad <= mdb_index_read 6463379 candidates 5f9496ad => key_read 5f9496ad mdb_idl_fetch_key: [37ef4d9a] 5f9496ad <= mdb_index_read 6463379 candidates 5f9496ad => key_read 5f9496ad mdb_idl_fetch_key: [e5e52605] 5f9496ad <= mdb_index_read 42313 candidates 5f9496ad => key_read 5f9496ad mdb_idl_fetch_key: [8990480b] 5f9496ad <= mdb_index_read 24146 candidates 5f9496ad => key_read 5f9496ad mdb_idl_fetch_key: [7de12f45] 5f9496ad <= mdb_index_read 3217 candidates In the above set (which was for a substring search) there were 6 different breakdowns of the substring queried from the index. 3 of them were ranges (6463387 candidates). 3 of them were limited matches (42313, 24146, 3217). The results are pulled from the smallest candidate set (3217) which is a quick lookup. Alternately, here's what the same search looked like for a slightly larger substring value that was always slow: 5f9495b3 mdb_idl_fetch_key: [6a48da6f] 5f9495b3 <= mdb_index_read 6463377 candidates 5f9495b3 => key_read 5f9495b3 mdb_idl_fetch_key: [de44adf5] 5f9495b3 <= mdb_index_read 6463399 candidates 5f9495b3 => key_read 5f9495b3 mdb_idl_fetch_key: [174b5285] 5f9495b3 <= mdb_index_read 6463385 candidates 5f9495b3 => key_read 5f9495b3 mdb_idl_fetch_key: [9e5c550b] 5f9495b3 <= mdb_index_read 6462721 candidates 5f9495b3 => key_read 5f9495b3 mdb_idl_fetch_key: [9b5c550b] 5f9495b3 <= mdb_index_read 6463280 candidates 5f9495b3 => key_read 5f9495b3 mdb_idl_fetch_key: [d393480d] 5f9495b3 <= mdb_index_read 6463387 candidates You can see the 6 candidate sets are essentially "all entries" which is why it is so slow. After adjusting the idlexp value to 17, I got instead: 5f94a42e mdb_idl_fetch_key: [6a48da6f] 5f94a42e <= mdb_index_read 906885 candidates 5f94a42e => key_read 5f94a42e mdb_idl_fetch_key: [de44adf5] 5f94a42e <= mdb_index_read 6463399 candidates 5f94a42e => key_read 5f94a42e mdb_idl_fetch_key: [174b5285] 5f94a42e <= mdb_index_read 415219 candidates 5f94a42e => key_read 5f94a42e mdb_idl_fetch_key: [9e5c550b] 5f94a42e <= mdb_index_read 99550 candidates 5f94a42e => key_read 5f94a42e mdb_idl_fetch_key: [9b5c550b] 5f94a42e <= mdb_index_read 293028 candidates 5f94a42e => key_read 5f94a42e mdb_idl_fetch_key: [d393480d] 5f94a42e <= mdb_index_read 6463387 candidates So now we can see there are 4 candidate sets that are smaller than "all entries": 906,885 415,219 99,550 293,028 Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Index seems to return wrong amount of candidate causing really poor search performance
--On Monday, August 16, 2021 9:07 PM + petteri.sten...@ubisecure.com wrote: Hello, We have experienced a similar issue. Unfortunately we too have a confidential dataset we cannot share. Our dataset started slowing down at about 1.7m entries. With slapcat/slapadd tools I can reliably reproduce the issue: - first I add about 1.7m entries with slapadd to an empty mdb database - I test with a search operation that returns a single entry and it performs as expected, about 0.06s - next I add a single entry with slapadd - after this the exactly same search operation that returns a single entry slows down significantly, about 1.37s With the new idlexp parameter set to for example value 17 this slow down issue no longer happens with our dataset. I don't understand idlexp parameter well enough. My fear is that idlexp tuning is not actually fixing this issue, instead the issue is simply postponed. If setting idlexp fixed it, then the issue was that one additional entry caused the index to collapse to a range with the default idlexp value, which is why changing the setting had an effect since it would stop it from being a range at the higher idlexp value. I added documentation as to what the idlexp command does to the admin guide for OpenLDAP 2.5.6. You may want to read it, it applies to OpenLDAP 2.4 as well. <https://www.openldap.org/doc/admin25/slapdconf2.html#MDB%20Database%20Directives> Section 5.2.6.1 --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
RE25 testing call #1 (OpenLDAP 2.5.7)
This is the first testing call for OpenLDAP 2.5.7. Depending on the results, this may be the only testing call. Generally, get the code for RE25: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/openldap-OPENLDAP_REL_ENG_2_5.tar.gz> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.5.7 Engineering Fixed lloadd client state tracking (ITS#9624) Fixed slapd bconfig to canonicalize structuralObjectclass (ITS#9611) Fixed slapd-mdb multival crash when attribute is missing an equality matchingrule (ITS#9621) Fixed slapd-mdb compatibility with OpenLDAP 2.4 MDB databases (ITS#8958) Fixed slapd-monitor number of ops executing with asynchronous backends (ITS#9628) Fixed slapd-sql to add support for ppolicy attributes (ITS#9629) Fixed slapd-sql to close transactions after bind and search (ITS#9630) Fixed slapo-accesslog to make reqMod optional (ITS#9569) Fixed slapo-ppolicy logging when pwdChangedTime attribute is not present (ITS#9625) Documentation slapo-accesslog(5) note that reqMod is optional (ITS#9569) Add guide section on load balancer (ITS#9443) Updated guide to document multiprovider as replacement for mirrormode (ITS#9200) Updated guide to clarify slapd-mdb upgrade requirements (ITS#9200) Updated guide to document removal of deprecated options from client tools (ITS#9200) Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: migrate from 2.4 to 2.5, determine existing MDB format
--On Saturday, August 7, 2021 3:48 PM +0200 Michael Ströder wrote: On 8/7/21 1:34 PM, Howard Chu wrote: Michael Ströder wrote: On 8/7/21 9:58 AM, Michael Ströder wrote: On 8/7/21 12:02 AM, Quanah Gibson-Mount wrote: With OpenLDAP 2.5.7 and later it is possible to export a 2.4 database with slapcat in all circumstances. This will be very helpful because downstream packagers won't have to provide two different versions of slapcat (as currently discussed on opensuse-factory list). Is it sufficient to use commit d00efea7d19ad339f244f1325883031830125876 as back-port patch? backport into 2.5? Yes. Yes, of course into 2.5. I would also backport: commit dffa47ed752fd840e7a7cc0d1b95e4474f2de95b Author: Howard Chu Date: Fri Aug 6 22:13:47 2021 +0100 ITS#9611 bconfig: canonicalize structuralObjectclass until 2.5.7 is available, as that is also for 2.4 to 2.5 upgrade compatibility. It affects the dyngroup, dynlist, and memberof overlays. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: migrate from 2.4 to 2.5, determine existing MDB format
--On Friday, August 6, 2021 11:49 PM +0100 Howard Chu wrote: Michael Ströder wrote: On 8/6/21 11:01 PM, Quanah Gibson-Mount wrote: --On Saturday, July 31, 2021 7:05 PM +0200 Michael Ströder wrote: Can I find out the disk format version in any way, e.g. with python-lmdb? The id2v DB only exists in OpenLDAP 2.5 databases. However, stay tuned... Ah, this is very helpful: mdb_stat -s id2v Just to be clear, the current upgrade doc is a bit paranoid. A 2.4 DB is forward compatible with 2.5. But 2.5 allows you to configure new DB parameters that would make it incompatible with 2.4. Or another way to put it: Unless sortvals, multival, or idlexp is being newly configured as a configuration change during the upgrade process, there is no requirement to reload a back-mdb database on reload with OpenLDAP 2.5.6 and prior. However it will not be possible to export this database via slapcat until after an OpenLDAP 2.5 slapd has been executed with the database in place. With OpenLDAP 2.5.7 and later it is possible to export a 2.4 database with slapcat in all circumstances. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: migrate from 2.4 to 2.5, determine existing MDB format
--On Saturday, July 31, 2021 7:05 PM +0200 Michael Ströder wrote: Can I find out the disk format version in any way, e.g. with python-lmdb? The id2v DB only exists in OpenLDAP 2.5 databases. However, stay tuned... --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Modify memberOf olcAttributetype in schema
--On Thursday, August 5, 2021 7:55 AM + shekhar.shriniva...@gmail.com wrote: Hi Howard, Please ignore my earlier question. I was able to get the memberof.c changed, built and installed successfully. Thank you ! This is not the correct solution. The application is broken, you need to work with the application developer to fix their broken product. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Antw: [EXT] Re: Modify memberOf olcAttributetype in schema
--On Thursday, August 5, 2021 8:45 AM +0200 Ulrich Windl wrote: So "X-ORIGIN 'iPlanet Delegated Administrator'" is part of the built-in schema? Yes, it documents the ORIGIN of the attribute. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: ldap utils: option dropped
--On Wednesday, August 4, 2021 11:28 PM +0200 "A. Schulze" wrote: Hello, in openldap-2.5.6, ldapsearch no longer understand '-h' to specify an LDAP server. '-H' must be uses now everywhere. Yes, it makes sense, but it break some things here. So I read https://www.openldap.org/doc/admin25/appendix-changes.html and https://www.openldap.org/doc/admin25/appendix-upgrading.html but did not found documentation for this change. I hoped to find also information about other potential changes to plan the 2.4 -> 2.5 migration. Are there other places I may search for documentation? Hi Andreas, You can query the bug tracker to find all issues that have 2.5.x as a target. This will not pick up older items fixed from prior to the bugzilla migration though: <https://bugs.openldap.org/buglist.cgi?bug_status=VERIFIED_id=2108=OpenLDAP_format=advanced=FIXED_milestone=2.5.0_milestone=2.5.1_milestone=2.5.2_milestone=2.5.3_milestone=2.5.4_milestone=2.5.5_milestone=2.5.6> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Generating a memberOf attribute for posixGroups (dynlist module)
--On Tuesday, August 3, 2021 4:42 PM +0200 Benjamin Renard wrote: Hello, Le 30/07/2021 à 18:37, Quanah Gibson-Mount a écrit : You want OpenLDAP 2.5's version of dynlist. Just be sure, could-you please resume me the benefits when using OpenLDAP 2.5's version of dynlist overlay ? It's now possible to use "memberOf" (like) attributes in a filtering clause ? You could just read the 2.5 man page. <https://www.openldap.org/software/man.cgi?query=slapo-dynlist=0=0=OpenLDAP+2.5-Release=default=html> But yes, you can use the dynamically generated memberOf in ldap filters. You may also want to look at the dynlist test script, from line 749 on. <https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/tests/scripts/test044-dynlist#L749> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Antw: [EXT] Re: migrate from 2.4 to 2.5, determine existing MDB format
--On Monday, August 2, 2021 12:25 PM +0200 Ulrich Windl wrote: Of course Berkely DB cannot upgrade the MDB database; I was talking about the layout versions of Berkeley DB. I did not misunderstand you. I meant that Berkeley-DB could not do automagic upgrades of its files in case the application-specific format changes. IIRC in former times with back-bdb and back-hdb there was also sometimes the need to reload BDB files because the slapd-specific layout changed. Admittedly I never had or needed those. I only noticed changes of hash functions, and those did not need manual intervention. Don't confuse the underlying database software (LMDB) with the databse backend (slapd-mdb). The slapd-mdb database backend had a format change that requires a reload. This is, as Michael already noted, no different than when the slapd-bdb or slapd-hdb backends (which made use of BerkeleyDB) had format changes. Those type of format changes always require a reload regardless of the underlying database software being used. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Generating a memberOf attribute for posixGroups (dynlist module)
--On Friday, July 30, 2021 2:21 PM -0700 Quanah Gibson-Mount wrote: --On Friday, July 30, 2021 4:16 PM -0300 Eduardo Lúcio Amorim Costa wrote: Hi people! My version is the one below... ``` [root@ldap_provider ~]# slapd -VV @(#) $OpenLDAP: slapd 2.4.44 (Apr 28 2021 13:32:00) $ mockbu...@x86-02.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.44/ openldap-2.4.44/servers/slapd And as a side note, Symas has multiple customers using the 2.5 version of slapo-dynlist in production with great results. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Generating a memberOf attribute for posixGroups (dynlist module)
--On Friday, July 30, 2021 4:16 PM -0300 Eduardo Lúcio Amorim Costa wrote: Hi people! My version is the one below... ``` [root@ldap_provider ~]# slapd -VV @(#) $OpenLDAP: slapd 2.4.44 (Apr 28 2021 13:32:00) $ mockbu...@x86-02.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.44/ openldap-2.4.44/servers/slapd As I already stated, you want to use the slapo-dynlist from the OpenLDAP 2.5 release series. The current version is OpenLDAP 2.5.6. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Generating a memberOf attribute for posixGroups (dynlist module)
--On Friday, July 30, 2021 2:30 PM -0300 Eduardo Lúcio Amorim Costa wrote: According to this post http://blog.oddbit.com/post/2013-07-22-generating-a-membero/ it is possible to use a strategy for generating a memberOf attribute for posixGroups (dynlist module). This need arose for a legacy OpenLDAP LDAP and with several applications using it. So, this seems to me the best solution to be able to use the memberOf as a filter. You want OpenLDAP 2.5's version of dynlist. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Configure openldap 2.5.6 on CentOS7 with TLS
--On Thursday, July 29, 2021 5:13 PM -0700 Scott Classen wrote: checking for SSL_export_keying_material_early in -lssl... no configure: error: Could not locate TLS/SSL package Any idea how I might get past this? I can configure, make depend, and make if I don't specify the "--with-tls=openssl" option, but my understanding was that TLS was essential for OpenLDAP. You seem to have told it where to find the OpenSSL 1.1.1 header files but not the development libraries. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Much Higher Latency With Paged Results Asked
--On Wednesday, July 28, 2021 10:53 PM +0200 Romain Madala wrote: Hi, I'm trying to understand what I can do to reduce the time needed by slapd to answer one simple query even though using the paging response option. When I do my request without pr switch it takes 5 ms, but if i do use the option it's around 105ms. Question is why ? Because specifying paged results requires the server to do additional work. And how I can get back to 5 ms when using the option ? You can't. Generally, using paged results indicates a poorly written application. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Much Higher Latency With Paged Results Asked
--On Tuesday, July 27, 2021 8:13 PM +0200 Romain Madala wrote: Please provide additional details of the issue. Thanks, but you didn't answer the above. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Much Higher Latency With Paged Results Asked
--On Tuesday, July 27, 2021 1:50 PM + romain.mad...@gmail.com wrote: Hi, Is there anyone who could help me to figure out this behaviour ? What release of OpenLDAP are you running? What database backend are you using? Please provide additional details of the issue. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: adding a new module smbkrb5pwd - error missingAttributeDescription
--On Thursday, July 22, 2021 5:26 PM + "Heinemann, Peter G" wrote: Hello, Using: openldap 2.4.58 RHEL 8 I'm attempting to add a new module, smbkrb5pwd (because we use MIT Kerberos). Compiled and linked under the full openldap2.4.58 source tree per instructions (README and here https://github.com/opinsys/smbkrb5pwd) I would suggest contacting the author of that module for support as it is not a part of the OpenLDAP software distribution, not even the contrib/ modules. I would note that the module in general seems to be abandonware. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
RE25 testing call #1 (OpenLDAP 2.5.6)
This is the first testing call for OpenLDAP 2.5.6. Depending on the results, this may be the only testing call. Generally, get the code for RE25: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/openldap-OPENLDAP_REL_ENG_2_5.tar.gz> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.5.6 Engineering Fixed libldap buffer overflow (ITS#9578) Fixed libldap missing mutex unlock on connection alloc failure (ITS#9590) Fixed lloadd cn=config olcBkLloadClientMaxPending setting (ITS#8747) Fixed slapd multiple config defaults (ITS#9363) Fixed slapd ipv6 addresses to work with tcp wrappers (ITS#9603) Fixed slapo-syncprov delete of nonexistent sessionlog (ITS#9608) Build Fixed library symbol versioning on Solaris (ITS#9591) Fixed compile warning in libldap/tpool.c (ITS#9601) Fixed compile wraning in libldap/tls_o.c (ITS#9602) Contrib Fixed ppm module for sysconfdir (ITS#7832) Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Replacing memberof with dynlist
--On Friday, July 16, 2021 12:01 PM + j.vandevi...@gmail.com wrote: Hello, Apologies for my bad English, it's not my native langage I'm toying with openldap 2.5.5 and the dynlist overlay to replace the memberof overlay (since it's the recommanded way to manage the memberof attribute in a replicate environnement). If you are already using static groups, you can use dynlist to populate memberOf based off of static groups instead. That configuration looks something like: dynlist-attrset groupOfURLs memberURL member+memberOf@groupOfNames You may also want to look at the test suite configurations for dynlist. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Symas OpenLDAP for Linux 2.5
--On Thursday, July 15, 2021 1:15 PM -0400 Dave Macias wrote: Yes, although we haven't yet announced it since it's still a WIP. I see. So if I understand correctly, the 2.5 release is good to go, but the packaged (rpm/deb/etc) files are still WIP? Symas's 2.5 package is a WIP. Other packagers have different statuses. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Symas OpenLDAP for Linux 2.5
--On Wednesday, July 14, 2021 12:29 PM -0400 Dave Macias wrote: But looks like the baseurl for 2.5 is now: https://repo.symas.com/repo/rpm/SOLDAP/release25/ Yes? Yes, although we haven't yet announced it since it's still a WIP. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Symas OpenLDAP for Linux 2.5
--On Tuesday, July 13, 2021 5:37 PM -0700 "Paul B. Henson" wrote: We're currently using the RHEL8 sofl repo, which currently has version 2.4.59.1 available. Our management wants to start doing automatic updates to the latest patches for security compliance reasons. This isn't an issue with the native RHEL repos as they generally never release major updates or incompatible packages. I wanted to check though how the release of openldap 2.5 via sofl is going to be handled. Is it just going to show up one day in the existing repo such that it would automatically get upgraded to, or is it going to be a different package name or a new repo that will require manual intervention in order to upgrade? Symas OpenLDAP packages for 2.5 will be an entirely different beast. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Consumer Delta Sync Lost After Provider Restarted
--On Wednesday, July 7, 2021 1:18 AM + thomaswilliampritch...@gmail.com wrote: Correction * Manually searching the context CSN confirmed that the CSNs on the consumers were newer than the CSN used to re-establish the persistent connection. Have you updated yet to 2.4.59 or are you still on 2.4.56? I seem to recall a fix for something like this, but I don't recall if it went into 2.4 or was 2.5 only. I'd definitely update to 2.4.59 as a first step if not there yet. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Consumer Delta Sync Lost After Provider Restarted
--On Tuesday, June 29, 2021 6:50 PM + thomaswilliampritch...@gmail.com wrote: Hi, I'm experiencing an issue between my 3 providers and multiple consumer setup and delta sync repl. We manage a primary, or active, provider and send all writes to the primary as long as it's healthy letting the two others replicate and be standby providers ready to take over in the event of a failure. All consumers replicate from all providers and all providers replicate from all providers. After the system was running healthily for over a week a standby provider was restarted. This caused my consumers to re-establish the persistent sync connection. Upon re-establishing the connection, some consumers began a sync refresh with the following message. Jun 28 18:32:55 openldap-hdb-consumer slapd[15746]: do_syncrep1: rid=003 starting refresh (sending cookie=rid=003,csn=20210331192036.214412Z#00#000#00;2021011922595 5.133811Z#00#001#00;20210128213906.596429Z#00#002#00;2021 0226190704.219043Z#00#005#00;20210412181659.152626Z#00#065#00 ;20210610231714.990702Z#00#066#00;20210614191744.122968Z# 00#44d#00;20210412175600.595586Z#00#835#00;20210423182110.684 843Z#00#836#00;20210331193249.570935Z#00#ce5#00) Jun 28 18:32:55 openldap-hdb-consumer slapd[15746]: do_syncrep2: rid=003 LDAP_RES_SEARCH_RESULT Jun 28 18:32:55 openldap-hdb-consumer slapd[15746]: do_syncrep2: rid=003 delta-sync lost sync, switching to REFRESH Jun 28 18:32:55 openldap-hdb-consumer slapd[15746]: do_syncrep2: rid=003 (4096) Content Sync Refresh Required This was re-establishing a connection with rid=003 which is "20210412175600.595586Z#00#835#00" (a standby system) however we have only been sending writes to server #44d# (the primary provider). We see 44d CSN is over 7 days old, beyond our providers access log period. On the consumer that did not trigger sync refresh we see Jun 28 18:32:55 openldap-hdb-consumer slapd[24439]: do_syncrep1: rid=003 starting refresh (sending cookie=rid=003,csn=20210331192036.214412Z#00#000#00;2021011922595 5.133811Z#00#001#00;20210128213906.596429Z#00#002#00;2021 0226190704.219043Z#00#005#00;20210412181659.152626Z#00#065#00 ;20210621212459.620195Z#00#066#00;20210621214400.407867Z# 00#44d#00;20210412175600.595586Z#00#835#00;20210423182110.684 843Z#00#836#00;20210331193249.570935Z#00#ce5#00) Here we see 20210621214400.407867Z#00#44d#00 is much more recent and did not trigger a full resync, although it is close to the 7 day threshold at this point. We notice the rid=003 835 csn is the same as the consumer experiencing the problem which makes me believe the #44d# csn being old is what causes this sync refresh. I am concerned why when the standby provider is restarted the connection is getting re-established with old provider CSNs, when I search the CSNs on the consumers they look newer than the ones used to reestablish the connection. If we restart slapd on the providers after running consumers for 7 days it seems like it will trigger a sync refresh. How can we make the consumers re-establish the connection with the most recent CSN? Replication is working as expected, just the CSNs seem to remain old in this connection message. The sync refresh behavior causes a large load on the consumers and providers spiking bind times and degrading service making this concerning for our production environment. The actual age of the CSN is generally immaterial, as long as that is what current CSN on the provider is. I.e., if the CSN on 835 provider *for itself* matches what was on the consumer, that's fine. The real issue seems to be that the consumer stopped recieving updates for CSN 44d, so when the session was bounced for any given provider, the consumer was going to go into REFRESH. What you need to determine is why that consumer stopped receiving updates, as this would trigger a refresh no matter which provider got bounced since none of the providers would have the data available in their accesslog. I generally advise using some type of monitoring on the CSNs for each server so you can quickly be notified when such an issue has arisen. I would note that your syncrepl configurations do not specify any keepalive settings which is generally recommended so that if some type of network device (load balancers and other traffic management systems do this) closes the syncrepl connection, slapd can detect this and re-establish it. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Are Password Expired and Password Expiry warning (2.16.840.1.113730.3.4.5) controls supported in OpenLDAP
--On Tuesday, June 29, 2021 6:34 PM -0500 cst labs wrote: hello: I am currently evaluating the OpenLDAP version 2.4.58. I was told by someone that it does support the password expired control but I don't see that it is working. As per the RFC, the server should send this control as a part of response but it doesn't. I do see that the server returns the password policy state control that has expired and warning information. However, I am interested in the password expired control since I am looking to support an existing implementation that leverages that control. Can someone tell me how to configure openldap to return that control? I suggest reading the slapo-ppolicy(5) man page, which clearly documents how to enable that control. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: enable WiredTiger not defaulting to no
--On Friday, June 25, 2021 8:51 PM +0100 Howard Chu wrote: dbray925+openl...@gmail.com wrote: I'm currently testing out the 2.5.5 install, and during the configure process it fails with: configure: error: Package requirements (wiredtiger) were not met: Package 'wiredtiger', required by 'virtual:world', not found The documentation (--help) shows that this should be default to no: --enable-wt enable WiredTiger backend no|yes|mod [no] However, this is not the case, and I have to manually set: ./configure --enable-wt=no The configure script clearly defaults it to no. If that's not happening then something else on your system enabled it. I would suspect that there is more to the configure options being used than was shown. I routinely run ./configure with no options and WT is not enabled. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: totp1andpw
--On Thursday, June 17, 2021 9:34 PM +0200 Stefan Kania wrote: Hi to all, I'm still testing TOPT with OpenLDAP 2.5. I got TOTP1 running. So a user with an OTP can use the six-digit number from googleauthenticator (or freeOTP+) to authenticate while using ldapsearch. Then I switch to TOTP1ANDPW I generate a secretkey for the TOTP-part of userPassword. Then I create a password with "slappasswd" and put both TOTP1|password together in userPassword after decoding base64 I saw what I expected: Again, I have to ask why you simply aren't using the OTP module that ships with 2.5 and whatever your favorite password hashing scheme is (I advise ARGON2) to do this. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: pw-totp
--On Monday, June 7, 2021 9:03 PM +0200 Stefan Kania wrote: looks ok to me: --- My point was to examine the generated configuration in the testrun dir, which has a clearly working configuration for the argon2 module, and compare it to what you've done. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: 2.57 to 2.58 update no structural objectClass in configuration table
--On Monday, June 7, 2021 12:49 PM +0200 Lists Nethead wrote: Hi all, After 2.57 to 2.58 update, slapd refuses to start. OS is FreeBSD 12, slapd built from ports. No clue what is missing, the system ran for two years without a clitch during updates. It would appear the older build had the syncprov module built in statically, while the newer build has it built in dynamically, so at this point you would need to moduleload syncprov. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: pw-totp
--On Monday, June 7, 2021 4:40 PM +0200 Stefan Kania wrote: Am 07.06.21 um 15:29 schrieb Michael Ströder: To build with libargon2 (which supports all ARGON2 arguments): --enable-argon2 --with-argon2=libargon2 Now it's compiling but still the same error :-( I suggest examining test083 closely, as it uses cn=config to set up and configure ARGON2 with cn=config. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: unable to add DB DIT , getting value #0 invalid per syntax error in alpine Linux.
--On Sunday, June 6, 2021 12:19 PM + govid wrote: and then if i execute "ldapadd -x -D 'cn=config' -w secret -f create_sns_db.ldif" it works fine without any errors. not sure if the same line are present in the slapd.conf, why backend db modules are not initialized. One either uses slapd.conf OR cn=config. You clearly need to add an additional moduleload for the syncprov module to your cn=config configuration. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: unable to add DB DIT , getting value #0 invalid per syntax error in alpine Linux.
--On Saturday, June 5, 2021 2:02 PM + govid wrote: Here is the debug log output of centos when the slapd service is atsrted : clearly backend ldap configuration is missing in Alpine, not sure how to initialize the same ? I tired loading the modules in slapd.ldif after this slaptest initializes the backend mdb and test is successful in alpine, but the same (back_mdb) is not configured while starting the slapd services. In CentOS, back-mdb is built statically into the slapd binary. I'd hazard that this is not the case with Alpine linux. You haven't provided a useful export of your cn=config database on Alpine to examine, so there's no ability to tell if it's actually correctly configured to load the MDB database module. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: pw-totp
--On Saturday, June 5, 2021 4:27 PM +0200 Stefan Kania
wrote:
Hello,
I try to set up TOTP1 and TOTP1ANDPW as passworthash. I use Debian 10
with Kernel 5.9 from the backports. As OpenLDAP I use 2.5.5. I set up
everything via Ansible. My configure-options are:
root@ldap25-p01:/opt/openldap-2.5.5/servers/slapd
Jun 05 15:24:52 ldap25-p01 slapd[16210]: olcPasswordHash: value #0:
scheme not available ({TOTP1})
Jun 05 15:24:52 ldap25-p01 slapd[16210]: olcPasswordHash: value #0:
no valid hashes found
Jun 05 15:24:52 ldap25-p01 slapd[16210]: config error processing
cn=config: no valid hashes found
Hm, I've only ever used the OTP module that ships as a core part of
OpenLDAP 2.5:
<https://www.openldap.org/software/man.cgi?query=slapo-otp=0=0=OpenLDAP+2.5-Release=default=html>
Personally I'd combine that with ARGON2 password hashes for secure password
hash storage + 2 Factor auth.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Symas OpenLDAP for Linux 2.4.59 Released
The latest version of Symas OpenLDAP for Linux is now available for RHEL7, RHEL8, Ubuntu18 LTS, and Ubuntu 20 LTS. <https://repo.symas.com/sofl/> for installation instructions. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: OpenLDAP 2.4.x branch support
--On Friday, June 4, 2021 12:11 PM -0700 Norm Green wrote: Do we have some idea of how long the 2.4.x branch will be maintained and supported? The roadmap page appears to be out of date (https://openldap.org/software/roadmap.html). Thanks, I've filed a bug to get that updated. ;) I'd strongly advise investigating migrating to 2.5 when you can. There may be future OpenLDAP 2.4.x releases if a critical CVE etc comes up, but outside of that it's essentially done with. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: unable to add DB DIT , getting value #0 invalid per syntax error in alpine Linux.
--On Friday, June 4, 2021 4:20 AM + govid wrote: but the original issue still persists, as below: /opt/hpe/nns/NVME-OF-Server/open-ldap/initial_config # ldapadd -x -D 'cn=config' -w secret -f create_sns_db.ldif adding new entry "olcDatabase=mdb,cn=config" ldap_add: Invalid syntax (21) additional info: objectClass: value #0 invalid per syntax Then the value in the LDIF you are loading is invalid. This often is seen if there is a character such as a trailing space after the objectClass name, etc. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: hdb to mdb
--On Thursday, June 3, 2021 6:02 PM -0400 Dave Macias wrote: So therefore i dont need to worry about back_mdb since it's already loaded. Yes? Right. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: hdb to mdb
--On Thursday, June 3, 2021 5:43 PM -0400 Dave Macias wrote: slapd -VVV @(#) $OpenLDAP: slapd 2.4.58 (Mar 16 2021 19:13:56) $ build@c7rpm:/home/build/git/rheldap/RHEL7_x86_64/BUILD/symas-openldap-2.4 .58/openldap-2.4.58/servers/slapd Included static backends: config ldif monitor bdb hdb mdb Not sure what to look for... "mdb" is that is? Yes, that indicates mdb was built statically. -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: hdb to mdb
--On Thursday, June 3, 2021 12:49 AM -0400 Dave Macias wrote: Hello, Saw this link in a recent mail to this list. https://www.openldap.org/doc/admin25/appendix-upgrading.html Looks like hdb would no longer be supported. I googled a bit to see what it would take to move over to mdb and stumbled on this post. https://www.mail-archive.com/openldap-technical@openldap.org/msg25484.html My question is: Is it really that easy? yes. Make sure that you have back_mdb moduleloaded as well if it's built as a module. You do have to export your DB via slapcat and then reimport with slapadd as well. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: unable to add DB DIT , getting value #0 invalid per syntax error in alpine Linux.
--On Thursday, June 3, 2021 5:04 AM + govid wrote: Hi, I am trying to do this in Apline OS. the same command "ldapadd -x -D 'cn=config' -w secret -f create_sns_db.ldif" works fine in centos but fails in Alpine. content of create_sns_db.ldif is: dn: olcDatabase=mdb,cn=config objectClass: olcMdbConfig olcDatabase: mdb olcDbMaxSize: 1073741824 olcSuffix: dc=smartsan olcDbDirectory: /usr/local/var/openldap-data/sns_db olcRootDN: cn=admin,dc=smartsan olcRootPW: secret2 olcDbIndex: objectClass eq # Load dynamic backend modules: # modulepath/usr/local/libexec/openldap # moduleloadback_mdb.la # moduleloadback_ldap.la Looks like you failed to moduleload back_mdb. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Replication between 2.4.x 2.5.x versions
--On Wednesday, June 2, 2021 12:23 PM +0300 Nick Milas wrote: Hello, We are running a (small) number of OpenLDAP instances with v2.4.58. There is a single master and 4 syncrepl consumers (all on CentOS 7 boxes), all running with back-mdb. We are planning our migration from 2.4 to 2.5.x My question: Would it be OK if we migrate our master server to 2.5.latest, and leave consumers to 2.4.58 for a while? Would any implications be expected? I would wait for 2.5.5. Other than that, replication is a protocol level bit, so it works between 2.4 and 2.5 w/o issue. Finally: Is there a script or other way to check possible config incompatibilities with 2.5.x (in order to avoid surprises)? Have you read the upgrade appendix of the admin guide? <https://www.openldap.org/doc/admin25/appendix-upgrading.html> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: radlib.h: No such file or directory - passwd slapd-module
--On Saturday, May 29, 2021 1:58 AM + rguichards...@gmail.com wrote: Hi, while compile passwd slapd-modules, I've got error on Radius compilation. gcc -DOPENLDAP_FD_SETSIZE=4096 -O2 -g -DSLAP_SCHEMA_EXPOSE -g -O2 -I/usr/kerberos/include -I../../../include -I../../../include -I../../../servers/slapd -c radius.c -fPIC -DPIC -o .libs/radius.o radius.c:27:20: fatal error: radlib.h: No such file or directory #include I've searched which package could provide the radlib file but I didn't found it. Please confirm which package should be used .. or link to the source.. It comes from libradius, which is from the FreeBSD project. Patches welcome to update the code to use freeradius. There are some forks of libradius for linux on github you might want to try. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Openldap trying to setup mozillaAbPersonAlpha.schema
--On Saturday, May 29, 2021 12:23 AM + b...@gunas.co.uk wrote: I think the core schema is in use as it is in the It is not. You're telling slaptest to use the ldap.conf file you created, which in turn ignores everything in /etc/ldap/ --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
RE25 testing call #1 (OpenLDAP 2.5.5)
This is the first testing call for OpenLDAP 2.5.55. Depending on the results, this may be the only testing call. Generally, get the code for RE25: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/openldap-OPENLDAP_REL_ENG_2_5.tar.gz> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.5.5 Engineering Added libldap LDAP_OPT_TCP_USER_TIMEOUT support (ITS#9502) Added lloadd tcp-user-timeout support (ITS#9502) Added slapd-asyncmeta tcp-user-timeout support (ITS#9502) Added slapd-ldap tcp-user-timeout support (ITS#9502) Added slapd-meta tcp-user-timeout support (ITS#9502) Fixed incorrect control OIDs for AuthZ Identity (ITS#9542) Fixed libldap typo in util-int.c (ITS#9541) Fixed libldap double free of LDAP_OPT_DEFBASE (ITS#9530) Fixed libldap better TLS1.3 cipher suite handling (ITS#9521, ITS#9546) Fixed lloadd multiple issues (ITS#8747) Fixed slapd slap_op_time to avoid duplicates across restarts (ITS#9537) Fixed slapd typo in daemon.c (ITS#9541) Fixed slapd slapi compilation (ITS#9544) Fixed slapd to handle empty DN in extended filters (ITS#9551) Fixed slapd syncrepl searches with empty base (ITS#6467) Fixed slapd syncrepl refresh on startup (ITS#9324, ITS#9534) Fixed slapd-asyncmeta quarantine handling (ITS#8721) Fixed slapd-asyncmeta to have a default operations timeout (ITS#9555) Fixed slapd-ldap quarantine handling (ITS#8721) Fixed slapd-mdb deletion of context entry (ITS#9531) Fixed slapd-meta quarantine handling (ITS#8721) Fixed slapo-accesslog to record reqNewDN for modRDN ops (ITS#9552) Fixed slapo-pcache locking during expiration (ITS#9529) Fixed slappw-argon2 module installation (ITS#9548) Contrib Update ldapc++/ldaptcl to use configure.ac (ITS#9554) Documentation ldap_first_attribute(3) - Document ldap_get_attribute_ber (ITS#8820) ldap_modify(3) - Delete non-existent mod_next parameter (ITS#9559) Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
RE24 testing call #1 (OpenLDAP 2.4.59)
his is the first testing call for OpenLDAP 2.4.59. Depending on the results, this may be the only testing call. Generally, get the code for RE24: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_4/openldap-OPENLDAP_REL_ENG_2_4.tar.gz> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.4.59 Engineering Fixed libldap TLSv1.3 cipher suites with OpenSSL 1.1.1 (ITS#9521) Fixed libldap double free of LDAP_OPT_DEFBASE (ITS#9530) Fixed slapd syncrepl handling of add+delete on single value attr (ITS#9295) Fixed slapd-mdb cursor init check (ITS#9526) Fixed slapd-mdb deletion of context entry (ITS#9531) Fixed slapo-pcache locking during expiration (ITS#9529) Contrib Fixed slapo-autogroup to not thrash thead context (ITS#9494) Documentation ldap_modify(3) - Delete non-existent mod_next parameter (ITS#9559) Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Openldap trying to setup mozillaAbPersonAlpha.schema
--On Friday, May 28, 2021 7:45 PM + b...@gunas.co.uk wrote: I have tried look for example of how to setup Thunderbird address book but with no look. I do hope someone can help. You need to include core.schema before the mozilla schema. I would also note that ldap.conf is generally for the ldap client, slapd.conf is for the slapd server. Obviously slaptest won't care. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: unable to add DB DIT , getting value #0 invalid per syntax error in alpine Linux.
--On Wednesday, May 26, 2021 8:58 AM + govid wrote: unable to add DB DIT , getting value #0 invalid per syntax error below is the content of "create_sns_db.ldif" file below is the debug output for the ldapadd command used: # ldapadd -x -D 'cn=config' -w secret -f create_sns_db.ldif -d 255 Hello, This was already answered in the bug report you filed -- It appears you haven't actually loaded the MDB backend in your configuration. Additionally, supplying the debug output of the *client* is rather useless when it's the *server* that's doing the validation of the configuration and generating the error. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: How to enable argon2 module
--On Monday, May 10, 2021 6:05 PM +0200 Francesco Malvezzi wrote: hi everybody, my problem with argon2 is just the casus belli pointing to something I actually didn't understand in the modules setup. The install step is broken in 2.5.4, fixed for 2.5.5 (ITS#9548). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: pbkdf2 module install does not honour --prefix=/opt/openldap
--On Saturday, May 8, 2021 7:09 PM +0200 Francesco Malvezzi wrote: really sorry for the lack of details because I'm really outside my field. I was just observing in openldap-2.5.4 the pbkdf2 module tries to install to /usr/local/libexec/openldap despite the --prefix=/opt/openldap in the configure on the src root. I am pretty sure it worked fine on openldap-2.4.* (at the beginning it didn't but then it was fixed). No, it is a contrib module, it has never been tied to configured. Read the makefile for how to set the prefix correctly. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: MDB page growth
--On Thursday, May 6, 2021 12:47 PM -0700 Zetan Drableg wrote: What accounts for MDB free/unused page growth? We make lots of incremental inserts and removals (Add new user, add user to group, remove user from group, remove user). Removal actions seem to trigger the query latency. Your described write traffic pattern is known to cause fragmentation in the database (which causes there to be a large number of free pages). OpenLDAP 2.5 has features to address this, specifically the multival settings. See slapd-mdb(5) for OpenLDAP 2.5. Generally you would likely want to configure both that and sortvals on your deployment once you're on OpenLDAP 2.5. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Migrating From DSEE7 to OpenLDAP; Base64 Values Fail To Import Using ldapadd
--On Thursday, May 6, 2021 6:48 PM + Brian Harkness wrote: Quanah, The links provided define the attribute syntax as IA5 and not DirectoryString--which I require. I've created a "local-nis.ldif" and simply replaced the gecos syntax from IA5(1.3.6.1.4.1.1466.115.121.1.26) to UTF-8(1.3.6.1.4.1.1466.115.121.1.15) and my base64 entries import fine now. Hi Brian, I reviewed the file and found that whomever originally created it had done so incorrectly in several spots in regards to the draft. I've updated it to correspond to the draft. Please download the current copy. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Migrating From DSEE7 to OpenLDAP; Base64 Values Fail To Import Using ldapadd
--On Thursday, May 6, 2021 8:03 PM +0200 Michael Ströder wrote: @Felix: Try using a subschema file for RFC 2307bis instead of nis.schema (nis.ldif). Symas ships a copy in its OpenLDAP builds: cn=config: <https://gitlab.symas.net/symas-public/openldap/-/raw/ubuntu/focal/debian/schema/rfc2307bis.ldif> or slapd.conf: <https://gitlab.symas.net/symas-public/openldap/-/raw/ubuntu/focal/debian/schema/rfc2307bis.schema> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Migrating From DSEE7 to OpenLDAP; Base64 Values Fail To Import Using ldapadd
--On Thursday, May 6, 2021 7:22 PM +0200 Felix Schmitt wrote: Hi, The issues might come from the fact that ODSEE has implemented RFC 2307bis - which aimed to improve on the old RFC 2307. As far as I know this never got a real standard - even though some companies adopted it. No, the problem is that the attribute value is not valid for the attribute defined SYNTAX. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Migrating From DSEE7 to OpenLDAP; Base64 Values Fail To Import Using ldapadd
--On Thursday, May 6, 2021 3:21 PM + hark...@protonmail.com wrote: Hi, I am in the process of migrating away from our ancient Oracle DSEE7 directory servers to OpenLDAP 2.4.44-23.el7_9.x86_64. Why are you migrating to a release that's over 5 years old? I'd strongly advise saving time and migrating to a current supported release. If you're on RHEL7, Symas offers free drop in replacements for the ancient cruft shipped by RH: <https://repo.symas.com/sofl/rhel7/> The LTB project also offers current builds of OpenLDAP: <https://ltb-project.org/documentation/openldap-rpm#yum_repository> One problem I'm experiencing when importing entries with attribute values encoded in base64 is: adding new entry "cn=LastName,ou=People,dc=cs,dc=university,dc=edu" ldap_add: Invalid syntax (21) additional info: gecos: value #0 invalid per syntax In this example, the "gecos" attribute has the first name "Jérémie", e.g., "gecos:: SsOpcsOpbWll". When I decode it using `base64 -d` it decodes just fine. Why can I not import this base64 encoded value, and others, using ldapadd? I'm binding as olcRootDN which has the appropriate permission, manage, as far as I can tell but have also used SASL EXTERNAL--same results. Does the decoded version actually import successfully? You note it decodes just fine, but you didn't say if you can actually import it at that point. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: idletimeout setting is not working
--On Thursday, May 6, 2021 1:46 PM +0530 aRaviNd wrote: Hi, Eventhough we have configured idletimeout as 0 in our slapd.conf , every 5 mins slapd is closing the connection. Why the idletimeout setting is not taking effect? Did you restart slapd after making the change? Does your system even use slapd.conf, or is it actually using cn=config? etc. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Antw: [EXT] Re: SyncProv checkpointing
--On Thursday, May 6, 2021 10:01 AM +0200 Ulrich Windl wrote: Quanah Gibson-Mount schrieb am 05.05.2021 um 18:09 in Nachricht : ‑‑On Wednesday, May 5, 2021 9:37 AM +0200 Ulrich Windl wrote: schrieb am 04.05.2021 um 17:27 in I just wonder: Are you talking about a slapcat‑type of backup or about a file‑level backup? They literally stated multiple times they took the backup using the mdb_copy utility. I guess that's the equivalent of slapcat then, or are there differences? (I know that mdb_copy creates a new database file while slapcat creates LDIF entries, but both ore more clever than a (stupid) file backup). The mdb_copy essentially eliminates the need to do a slapadd on the other end, with the tradeoff being that it's likely going to be a larger binary file. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Antw: [EXT] Re: SyncProv checkpointing
--On Wednesday, May 5, 2021 9:37 AM +0200 Ulrich Windl wrote: schrieb am 04.05.2021 um 17:27 in I just wonder: Are you talking about a slapcat-type of backup or about a file-level backup? They literally stated multiple times they took the backup using the mdb_copy utility. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: SyncProv checkpointing
--On Tuesday, May 4, 2021 11:37 PM + thomaswilliampritch...@gmail.com wrote: You are correct we do not copy the access log, strictly the primary db. Ok good. When we restore a backup with a behind checkpoint we find some entries have incorrect fields in the new provider given the current state of the original provider, in other words, the databases do not match. The new provider seems to regain an incorrect state when syncing with a behind checkpoint from the current DB state. On Provider A (missing or large olcSpCheckpoint interval possibly days old). Add group1 with a set of 100 users. Add the 100 users to a new group, group2. Take a backup with mdb_copy. Delete group2. On Provider B Build / setup with the backup mdb_copy database. Turn on delta sync to Provider A When the catch up sync is finished, compare the database contents for accuracy. We are seeing group membership become incorrect on Provider B (the new provider). We cannot upgrade at the moment and olcSpCheckpoint: 1 1 seems to work. Is there any reason we should not use olcSpCheckpoint: 1 1? No, that's fine. The issue is more that you shouldn't be having any issues as long as the checkpoint is more frequent than the accesslog purge configuration. It would be useful to have a copy of your configuration for the two nodes (passwords redacted, if you can send them to me directly). I'd like to see if I can create a reproduction case. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: SyncProv checkpointing
--On Tuesday, May 4, 2021 7:13 PM + thomaswilliampritch...@gmail.com wrote: It is always running when we take backups via mdb_copy. Then it's expected the contextCSN won't be perfectly in sync at that point. I assume you're only doing an mdb copy of the primary db, and not the accesslog DB, since the accesslog DB is serverID specific. It's not clear to me what you mean by "most accurate". If the checkpoint is behind, the system should still be able to quickly regain its state since it will simply replay the accesslog on the other provider until it's current. I.e., as long as a reasonable checkpoint is already in place, it will never get particularly behind. I would generally advise upgrading to a current build, however, to pull in the more recent replication related fixes, particularly: OpenLDAP 2.4.57 Release (2021/01/18) Fixed slapo-syncprov to ignore duplicate sessionlog entries (ITS#9394) OpenLDAP 2.4.58 Release (2021/03/16) Fixed slapd syncrepl to check all contextCSNs (ITS#9282) Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: SyncProv checkpointing
--On Tuesday, May 4, 2021 4:27 PM + thomaswilliampritch...@gmail.com wrote: Provision Process: 1. Take backup of database with mdb_copy on initial provider. Is slapd stopped when you run mdb_copy, or running? Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: SyncProv checkpointing
--On Monday, May 3, 2021 10:52 PM + thomaswilliampritch...@gmail.com wrote: Hi, Through testing we have discovered restoring from backup is most accurate when we have the syncprov checkpointing at "1 1". Or checkpoint after 1 operation or 1 minute (olcSpCheckpoint: 1 1). Are there any concerns with having this frequent of checkpointing? Too little information here. What OpenLDAP release are you on? Do you use standard syncrepl or delta-syncrepl? What is your restore process? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Unable to delete root entry
--On Tuesday, April 27, 2021 12:47 AM +0300 Николай Данилов wrote: However, is it already fixed in the source code? https://github.com/openldap/openldap/commit/0c90b8c0011fdb80fc2f8a2d7192f 8b40217c7e3 Yep. If you build your own software, you should be able to backport it just fine. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Unable to delete root entry
--On Monday, April 26, 2021 11:56 PM +0300 Николай Данилов wrote: I will deal with the docker options. Is it possible to resolve the issue of removing the root record using standard openldap tools? No, it's a bug in the backend database. You could do what Howard said via ldapmodify as a runtime alternative. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Unable to delete root entry
--On Monday, April 26, 2021 11:39 PM +0300 Николай Данилов wrote: I tried the option with deleting mdb files the day before yesterday. It really works. However, we need to bring up the openldap service with replication in the k8s cluster. Therefore, low-level operations are unacceptable. Creating a default database is a function of how debian does the packaging. I believe there's an option you can pass to have it not do that. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Unable to delete root entry
--On Monday, April 26, 2021 10:46 AM -0700 Quanah Gibson-Mount wrote: --On Saturday, April 24, 2021 11:04 PM +0300 Николай Данилов wrote: When installing openldap with database mdb, root entry cannot be deleted. This is a bug with back-mdb that was not present with back-bdb/hdb. When you originally opened your issue in the bug tracker, you said you couldn't delete the rootDSE, which would be correct. This is an issue with deleting the root of the database DIT, which is different. As a workaround, you can stop slapd and delete the database files (data.mdb, lock.mdb) in your configured path for where they are stored for that specific database. Then add your new set of objects. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Unable to delete root entry
--On Saturday, April 24, 2021 11:04 PM +0300 Николай Данилов wrote: When installing openldap with database mdb, root entry cannot be deleted. This is a bug with back-mdb that was not present with back-bdb/hdb. When you originally opened your issue in the bug tracker, you said you couldn't delete the rootDSE, which would be correct. This is an issue with deleting the root of the database DIT, which is different. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: OpenLDAP 2.5 Release Candidate Testing (OpenLDAP 2.5.4)
--On Friday, April 23, 2021 9:49 AM -0700 Quanah Gibson-Mount wrote: --On Friday, April 23, 2021 9:05 AM -0700 Quanah Gibson-Mount wrote: Starting test043-delta-syncrepl for mdb... I was able to reproduce this one, thanks. ITS#9534. test043 issue should be fixed now. I still need more info on what you did to cause the load balancer test suite failure. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: OpenLDAP 2.5 Release Candidate Testing (OpenLDAP 2.5.4)
--On Friday, April 23, 2021 12:31 PM -0700 Scott Classen wrote: Is it possible to specify an alternate openssl? The default openssl that is distributed with CentOS7 is 1.0.2 which is too old. I have installed 1.1.1g from the epel repository so I have these packages available: openssl.x86_64 1:1.0.2k-21.el7_9 @updates openssl-devel.x86_641:1.0.2k-21.el7_9 @updates openssl-libs.x86_64 1:1.0.2k-21.el7_9 @updates openssl11.x86_641:1.1.1g-3.el7 @epel openssl11-devel.x86_64 1:1.1.1g-3.el7 @epel openssl11-libs.x86_64 1:1.1.1g-3.el7 @epel But I'm not sure how to specify this during configure. What path is the alternate OpenSSL installed into? I'd suggest uninstalling openssl-devel.x86_64 so it's not picked up, and then ensure your build flags are set appropriately. For example, assuming openssl11 was installed into /usr/local: LD_FLAGS=-L/usr/local/lib -Wl,-rpath,/usr/local/lib CPP_FLAGS=-I/usr/local/include etc Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: OpenLDAP 2.5 Release Candidate Testing (OpenLDAP 2.5.4)
--On Friday, April 23, 2021 9:05 AM -0700 Quanah Gibson-Mount wrote: Starting test043-delta-syncrepl for mdb... I was able to reproduce this one, thanks. ITS#9534. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: OpenLDAP 2.5 Release Candidate Testing (OpenLDAP 2.5.4)
--On Friday, April 23, 2021 2:35 PM +0200 Ondřej Kuzník wrote: On Fri, Apr 23, 2021 at 10:44:35AM +0200, Dieter Klünter wrote: There is a broken symlink in tests/testdata/homedir/skel/directory/ which points to it self. Which is part of the test, the problem was an copy-paste error at the beginning of the script that should have noticed the overlay was not available. That's fixed now in master (commit defa618405) and will be part of 2.5.4 when Quanah gets a chance to include it. Thanks for testing things and if you get a chance to test with the fix and further, much appreciated. Fixed in RE25 now. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: OpenLDAP 2.5 Release Candidate Testing (OpenLDAP 2.5.4)
--On Friday, April 23, 2021 4:51 PM +0200 "A. Schulze" wrote: Am 22.04.21 um 18:56 schrieb Quanah Gibson-Mount: Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. ./configure say "--enable-mdbenable mdb database backend no|yes|mod [yes]" so I took the default and don't pass it to confiure at all. What was the exact configure command used? /usr/bin/make -C . test make[1]: Entering directory '/<>' cd tests && /usr/bin/make test make[2]: Entering directory '/<>/tests' make[3]: Entering directory '/<>/tests' run configure with --enable-mdb to run MDB tests make[3]: Leaving directory '/<>/tests' make[3]: Entering directory '/<>/tests' Initiating LDAP tests for the Load Balancer... No suitable default database backend configured run again with '--enable-mdb=yes' solved that problem but "make test" still fail ... Starting test043-delta-syncrepl for mdb... running defines.sh Starting provider slapd on TCP/IP port 9011... Using ldapsearch to check that provider slapd is running... Using ldapadd to create the context prefix entries in the provider... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the provider directory... Waiting 7 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that provider slapd is running... Using ldapmodify to modify provider directory... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the provider... Using ldapsearch to read all the entries from the consumer... Filtering provider results... Filtering consumer results... Comparing retrieved entries from provider and consumer... test failed - provider and consumer databases differ test043-delta-syncrepl failed for mdb after 29 seconds Possibly a timing issue, without more details it's not possible to know. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: OpenLDAP 2.5 Release Candidate Testing (OpenLDAP 2.5.4)
--On Thursday, April 22, 2021 3:32 PM -0700 Quanah Gibson-Mount wrote: I'm not able to reproduce this, I'd need to have the contents of the testrun/ directory to get some idea why you're hitting it. Never mind, I can reproduce it, I misread the test #. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: OpenLDAP 2.5 Release Candidate Testing (OpenLDAP 2.5.4)
--On Friday, April 23, 2021 12:07 AM +0300 openldap-techni...@kolttonen.fi wrote: Hello, On Thu, 22 Apr 2021, Quanah Gibson-Mount wrote: Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. On RHEL8 and Fedora 33, ./configure && make && make test stops with the same failure: I'm not able to reproduce this, I'd need to have the contents of the testrun/ directory to get some idea why you're hitting it. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
OpenLDAP 2.5 Release Candidate Testing (OpenLDAP 2.5.4)
This is a testing call for OpenLDAP 2.5 Release Candidate (OpenLDAP 2.5.4) Depending on the results, this may be the only testing call. Generally, get the code for RE25: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/openldap-OPENLDAP_REL_ENG_2_5.tar.gz> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Note that there are new features in 2.5, so please examine the options available with configure carefully. Some examples: The new load balancer, which can either be built as a module for slapd (--enable-balancer=mod) or as a standalone server (--enable-balancer=yes) The libargon2 password module (--enable-argon2). Systemd notification support (--with-systemd=yes). Thanks! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: performance tuning for n-way and heavy client load
--On Friday, April 16, 2021 12:01 PM -0700 Zetan Drableg wrote: Do you have a lot of large groups that you frequently update? Yes we have several groups with ~40k users from which we frequently add/remove users based on upstream user provisioning workflows. Are you replacing the entire group when you do that, or only adding/deleting specific users? Either way, for 2.4 you definitely want to use sortvals. Likely what you need is OpenLDAP 2.5's multival feature as well. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: performance tuning for n-way and heavy client load
--On Friday, April 16, 2021 11:45 AM -0700 Zetan Drableg wrote: When I write LDIFs to one node like delete user or remove user from group, we see spikes in authentication latency metrics (what's normally .2 - .5 second response time goes up to 15-30 seconds) across all nodes in the cluster at the same time. I ran mdb_copy -c to compact the LDAP databases. The size went from 2.9G to 140M and the latency problem during inserts went away. I've noticed the LDAP data.mdb is growing about 25M per day. What accounts for the growth of free pages? Do you have a lot of large groups that you frequently update? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Problems setting up a proxy
--On Thursday, April 15, 2021 8:58 PM +0200 Hans van Zijst
wrote:
On 15-04-2021 19:09, Quanah Gibson-Mount wrote:
A few notes:
A) the "backend meta" directive is not needed. There's only one use
case for a "backend" statement at this time that I'm aware of, for
back-mdb, and only in OpenLDAP 2.5 or later.
>
B) You don't show that you loaded the back_meta module via moduleload.
I did mention it in the line above that, but for clarity's sake I should
have included the olcLoadModule for back_meta.la too: I made two almost
identical LDIF files and loaded them separately. Brevity isn't always a
good idea :)
It looks like the meta backend is loaded; this is what I find in
/etc/ldap/slapd.d/cn=config/cn=module{0}.ldif
dn: cn=module{0}
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_mdb
olcModuleLoad: {1}back_ldap.la
olcModuleLoad: {2}back_meta.la
structuralObjectClass: olcModuleList
But I notice that I only have the file cn=module{0}.ldif, and I would
expect to also find the directory cn=module{0}, am I correct?
No, it's an entry not a directory. Is there a back_meta.la file in
/usr/lib/ldap ?
backend definition and start the proxybackend.conf with "database meta",
I get this error when I run slaptest:
Unrecognized database type (meta)
6078774c proxybackend.conf: line 1: failed init (meta)
slaptest: bad configuration directory!
I would suggest you run slapd -d -1 and see what the full debug output is
and any errors.
How do I make sure those two backend definitions are actually loaded? If
I feed the two LDIF files that load the backends, I get the message:
modifying entry "cn=module{0},cn=config"
and if I try to load them again, I get the error:
modifying entry "cn=module{0},cn=config"
ldap_modify: Type or value exists (20)
additional info: modify/add: olcModuleLoad: value #0 already exists
That, to me, suggests that they're actually loaded, if if wasn't for the
slaptest error message that says it doesn't know about a meta database.
That tells you nothing about whether or not they're loaded. It says you're
trying to add a duplicate value to the entry, which is the correct error
for that scenario. ;)
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Re: Problems setting up a proxy
--On Thursday, April 15, 2021 6:39 PM +0200 Hans van Zijst
wrote:
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: back_ldap.la
6075bced /root/proxybackend.conf: line 1: failed init (meta)!
slaptest: bad configuration directory!
A few notes:
A) the "backend meta" directive is not needed. There's only one use case
for a "backend" statement at this time that I'm aware of, for back-mdb, and
only in OpenLDAP 2.5 or later.
B) You don't show that you loaded the back_meta module via moduleload.
There's definitely still a lot of work to be done in regards to better
documentation and examples when working with cn=config. Patches welcome
once you get it working. ;)
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
