(ITS#9180) Update slapo-memberOf man page about replication
Full_Name: Quanah Gibson-Mount Version: 2.4.49 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.236) After discussion with Howard, slapo-memberOf should be replication compatible on REFRESH as long as the dangling option is set to ignore. The man page should be updated to reflect this, although I want to do some testing to confirm with how it behaves when refint is set to TRUE as well.
Re: (ITS#9175) ldapsearch segfault
Thanks for the report, suggested fix has been applied.
Regards,
Quanah
--On Friday, February 21, 2020 8:38 PM + lha...@meditech.com wrote:
> --3b4d37059f1c0189
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> footnote: In my first followup, I intended to write "as I am quite
> UNaccustomed to working with the data"
> Cheers
>
> On Fri, Feb 21, 2020 at 3:27 PM Lexi Haley wrote:
>
>> FOUND THE ISSUE! So - in GDB , while paused in the "{mM}" processing
>> tha=
> t
>> ber_scanf does (called from ldap_get_attribute_ber), I kept seeing the
>> variable arguments list not properly setting off --- and sure enough,
>> digging in memory, on the stack was 0x1 ... which was the cause
>> =
> of
>> the eventual segfault.
>>
>> Well, backtracking to the ber_scanf call itself, I see a zero 0 which
>> isn't cast to the ber_len_t type, and as such, will only occupy 4 bytes
>> a=
> s
>> a sizeof int - instead of (( on my system 8, for sizeof (ber_len_t). So
>> =
> -
>> the solution was just to cast the argument. So that the cookie.off =3D
>> va_arg( ap, ber_len_t ); will unpack only bytes we've intentionally sent
>> =
> it
>> -- not garbage left over.
>>
>> So - the change suggested is:
>>
>>
>> diff --git a/libraries/libldap/getattr.c b/libraries/libldap/getattr.c
>> index 31784d765..0300ea574 100644
>> --- a/libraries/libldap/getattr.c
>> +++ b/libraries/libldap/getattr.c
>> @@ -147,7 +147,7 @@ ldap_get_attribute_ber( LDAP *ld, LDAPMessage *entry,
>> BerElement *ber,
>>
>> /* skip sequence, snarf attribute type */
>> tag =3D ber_scanf( ber, vals ? "{mM}" : "{mx}", attr,
>> val=
> s,
>> - , 0 );
>> + , (ber_len_t)0 );
>> if( tag =3D=3D LBER_ERROR ) {
>> rc =3D ld->ld_errno =3D LDAP_DECODING_ERROR;
>> }
>>
>>
>> I hope you can take this haphazard issue submit, and do whatever is right
>> with it - to get this patch considered. Thanks!
>>
>>
>>
>> On Fri, Feb 21, 2020 at 1:06 PM Lexi Haley wrote:
>>
>>> continuing notes - as I am quite accustomed to working with the data
>>> structures and processes for LDAP - my hacky fudge was just that - and
>>> a=
> lso
>>> useless. By bailing out at that point, ldapsearch doesn't list the
>>> tag=3Dvalue results. I am continuing to dig around ...
>>>
>>> Lexi
>>>
>>> On Thu, Feb 20, 2020 at 3:09 PM wrote:
>>>
>>>>
>>>> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***
>>>>
>>>> Thanks for your report to the OpenLDAP Issue Tracking System. Your
>>>> report has been assigned the tracking number ITS#9175.
>>>>
>>>> One of our support engineers will look at your report in due course.
>>>> Note that this may take some time because our support engineers
>>>> are volunteers. They only work on OpenLDAP when they have spare
>>>> time.
>>>>
>>>> If you need to provide additional information in regards to your
>>>> issue report, you may do so by replying to this message. Note that
>>>> any mail sent to openldap-its@openldap.org with (ITS#9175)
>>>> in the subject will automatically be attached to the issue report.
>>>>
>>>> mailto:openldap-its@openldap.org?subject=3D(ITS#9175)
>>>>
>>>> You may follow the progress of this report by loading the following
>>>> URL in a web browser:
>>>> http://www.OpenLDAP.org/its/index.cgi?findid=3D9175
>>>>
>>>> Please remember to retain your issue tracking number (ITS#9175)
>>>> on any further messages you send to us regarding this report. If
>>>> you don't then you'll just waste our time and yours because we
>>>> won't be able to properly track the report.
>>>>
>>>> Please note that the Issue Tracking System is not intended to
>>>> be used to seek help in the proper use of OpenLDAP Software.
>>>> Such requests will be closed.
>>>>
>>>> OpenLDAP Software is user supported.
>>>> http://www.OpenLDAP.org/support/
>>>>
>>>> --
>>>> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.
>>>>
>>&g
Re: (ITS#9173) Openldap configuration
--On Monday, February 17, 2020 4:28 PM + biswas.r...@gmail.com wrote: > Full_Name: Raju Biswas > Version: 2.4.44 Hello, The ITS system is for reporting bugs, not help requests. If you need help use the openldap-techni...@openldap.org email list, as that is what it is for. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9168) Memory Leak in LDAP search operation
--On Thursday, February 13, 2020 4:50 PM + bananashake2...@yahoo.de wrote: > Full_Name: Stefan Koch > Version: 2.4.44 Hello, The 2.4.44 release is over 4 years old. Please use a current OpenLDAP release prior to reporting bugs. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9167) Using OpenLDAP as Proxy
--On Thursday, February 13, 2020 1:40 PM + abboud.makh...@emcrey.com
wrote:
> Full_Name: Abboud Makhoul
> Version: 2.4.44
> OS: oracle linux 7.6
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (109.233.20.178)
>
>
> We are trying to use OpenLDAP as a proxy to OUD (Oracle Unified
> Directory). We have added the following file in
> /etc/openldap/slapd.d/cn=config: olcDatabase={1}ldap.ldif
Hello,
The ITS system is for reporting bug, not usage questions. Please use the
openldap-techni...@openldap.org email list for usage questions such as
this. This ITS will be closed.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Re: (ITS#9164) back-monitor returning non-requested attributes
--On Thursday, February 6, 2020 8:47 PM + qua...@openldap.org wrote: > This appears to be because they (IMHO) incorrectly SUP monitoredInfo or > monitorCounter Or, thinking on it further, I think this is ok, just not what I expected. I'll close the ITS. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
(ITS#9164) back-monitor returning non-requested attributes
Full_Name: Quanah Gibson-Mount Version: 2.4.49 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.236) The new additions to back-monitor to expose more data from back-mdb are returning unrequested attributes. For example: ldapsearch -x -LLL -H ldap:/// -s base -b "cn=database 1,cn=databases,cn=monitor" "(|(objectClass=monitorCounterObject)(objectClass=monitorOperation)(objectClass=monitoredObject))" monitorCounter monitorOpInitiated monitorOpCompleted monitoredInfo olmMDBPagesMax olmMDBPagesUsed olmMDBPagesFree olmMDBReadersMax olmMDBReadersUsed olmMDBEntries Will return: dn: cn=Database 1,cn=Databases,cn=Monitor monitoredInfo: mdb monitorOverlay: dynlist olmMDBPagesMax: 262144 olmMDBPagesUsed: 629 olmMDBPagesFree: 58 olmMDBReadersMax: 126 olmMDBReadersUsed: 2 olmMDBEntries: 1005 olmDbDirectory: /var/symas/openldap-data/example/ Note that I did not request monitorOverlay nor did I request olmDbDirectory This appears to be because they (IMHO) incorrectly SUP monitoredInfo or monitorCounter
Re: (ITS#9162) dbMaxSize property does not as expected
--On Monday, February 3, 2020 9:49 AM + pasumarthivijayku...@gmail.com wrote: > Full_Name: Vijay Kumar > Version: 2.4.48 > OS: windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (103.204.96.6) Please stop filing ITSes, as you clearly are working with an already broken database. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9161) Codespell report for "OpenLDAP" (on fossies.org)
--On Thursday, January 30, 2020 8:48 PM + jens.schleuse...@fossies.org wrote: > Full_Name: Jens Schleusener > Version: 2.4.49 > OS: (irrelevant) > URL: https://fossies.org/linux/misc/openldap/codespell.html > Submission from: (NULL) (2003:cf:71a:5655:2905:9b7a:fef1:ab74) > > > The FOSS server fossies.org - also supporting "OpenLDAP" - offers a new > feature "Source code misspelling reports": This is very nice, thank you. Definitely some items in here that need fixing. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9159) mdb_put failed: MDB_MAP_FULL: Environment mapsize limit reached(-30792)
--On Thursday, January 30, 2020 2:38 PM +0530 Vijay Kumar wrote: > > > Thank you Quanah, > > I am not familiar about your process of subscribing to lists. > I have gone though the documentation to understand the mdb size for > windows. Can you please share me the documentation you might referring? The information on the mailing lists and how to subscribe is directly accessible from the main page for the OpenLDAP project: <https://www.openldap.org/> Click on the link that says "Mailing lists" Click on the link that says "OpenLDAP-technical" to get to: <https://www.openldap.org/lists/mm/listinfo/openldap-technical> The man page for slapd-mdb(5) has all of the documentation: <https://www.openldap.org/software/man.cgi?query=slapd-mdb=0=0=OpenLDAP+2.4-Release=html> Again, the default MAXIMUM size for an MDB database is 10MB if the maxsize parameter is not set. You *must* set this value to something larger. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9159) mdb_put failed: MDB_MAP_FULL: Environment mapsize limit reached(-30792)
--On Thursday, January 30, 2020 6:09 AM + pasumarthivijayku...@gmail.com wrote: > --25b743059d554b79 > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > Thanks for your reply I do know that info for windows also is it the > same.? I am unable to use stats tool also. As I already stated, the maxsize parameter specifies the maximum size the database can reach. > As I don=E2=80=99t see any reply from our many mails to > openldap-techni...@openldap.org I have created this case to clarify. The openldap-technical list is only open to subscribers, if you want to post to it you must subscribe first. > Why don=E2=80=99t you forward the query to the concerned team instead > closi= ng. Your query would not be forwarded because you failed to read and/or understand the documentation. This system is for bug reports only. > No reply to us.! I did reply. This is clearly shown in the ITS. > Please let us know answer to solve a issue.! I already provided you the answer in my earlier response. Set an approprate maxsize setting, the default of 10MB is clearly too low. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9159) mdb_put failed: MDB_MAP_FULL: Environment mapsize limit reached(-30792)
--On Wednesday, January 29, 2020 10:54 AM + pasumarthivijayku...@gmail.com wrote: > Full_Name: Vijay Kumar > Version: 2.4.48 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (103.204.96.6) > > > I am not setting any map size for openldap with mdb configuration in > windows. Hello, Usage questions need to be sent to the openldap-techni...@openldap.org email discussion list. The ITS system is for bug reports only. However, I would suggest carefully reading the slapd-mdb(5) man page, and consider the fact that the maxsize parameter determines what the allowed maximum size of the database is. If you do not set the parameter, it limits the database to 10MB in size (The default value). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
(ITS#9152) Configuring autoca before database exists crashes slapd
Full_Name: Quanah Gibson-Mount
Version: HEAD
OS: N/A
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.143.26)
If you configure autoca via cn=config when the underlying DB does not yet exist,
slapd will crash.
i.e., I added this entry to my cn=config db:
dn: olcOverlay=autoca,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcACAConfig
olcOverlay: autoca
olcACAlocalDN: cn=anvil4.rb.symas.net,ou=Servers,dc=rb,dc=symas,dc=net
while the mdb database was not yet populated.
Re: (ITS#9143) Segfault in libcrypto.so.1.1
--On Thursday, December 19, 2019 9:46 PM + qua...@symas.com wrote: > > > --On Saturday, December 14, 2019 10:54 PM + s.peil...@caenlamer.fr > wrote: > >> Can you tell me what to modify to correct this error? > > Hello, > > Libcrypto is not provided by the OpenLDAP project. I would also note > that Debian & Ubuntu use GnuTLS by default rather than OpenSSL. I would > advise contacting the Debian/Ubuntu project and their GnuTLS package > maintainers specifically. If you are building your own OpenLDAP linked to your own OpenSSL build, you'll need to dig deeper into the issues, as you're a bit outside of what Debian/Ubuntu do with OpenLDAP. I would note that at least for Ubuntu 18, there is already a backport provided of the 2.4.48 release that does not appear to exhibit the issues you describe. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9143) Segfault in libcrypto.so.1.1
--On Saturday, December 14, 2019 10:54 PM + s.peil...@caenlamer.fr wrote: > Can you tell me what to modify to correct this error? Hello, Libcrypto is not provided by the OpenLDAP project. I would also note that Debian & Ubuntu use GnuTLS by default rather than OpenSSL. I would advise contacting the Debian/Ubuntu project and their GnuTLS package maintainers specifically. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9144) Remove ICU detection
--On Thursday, December 19, 2019 9:36 PM + qua...@openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.48 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.143.26) > > > In 2005, ICU library detection was added to the build process, however > nothing was ever added to use it. This can result in an unwanted > dependency when building on system where the library is present, causing > issues later down the line. See also commits a956f7592 and 1cf5838e0 I found this to be a problem when slapd is compiled on a system where the ICU libs are present and then the build is later deployed on a system where it doesn't exist, causing slapd to fail. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
(ITS#9144) Remove ICU detection
Full_Name: Quanah Gibson-Mount Version: 2.4.48 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.143.26) In 2005, ICU library detection was added to the build process, however nothing was ever added to use it. This can result in an unwanted dependency when building on system where the library is present, causing issues later down the line.
Re: (ITS#9142) LDAP Connection Close
--On Saturday, December 14, 2019 11:09 AM + pasumarthivijayku...@gmail.com wrote: > Full_Name: Vijay Kumar > Version: 2.4.48 > OS: Debian Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (124.123.75.91) Hello, The ITS system is for bug reports only. Questions about OpenLDAP functionality should be directed to the openldap-technical mailing list. Your log shows no issues. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#8980) Async mode and TLS Non-Blocking Issue
--On Thursday, December 5, 2019 9:27 PM + "Sun, Wei" wrote: > It seems to be that on the 2.4.48 release, in file tls2.c, > LDAP_USE_NON_BLOCKING_TLS is tied to LDAP_DEVEL, however, on the main > branch, it is enabled by default? Because it is a 2.5 feature. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
(ITS#9122) slapadd with dry run fails with back-mdb
Full_Name: Quanah Gibson-Mount Version: 2.4.48 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.143.26) When testing an slapadd import with back-mdb as the database backend, it errors out incorrectly with a unknown attribute error: slapadd -F /tmp/slapd.d -l slapd-config-config.ldif -n 0 -u 5ddc186e PROXIED attributeDescription "DC" inserted. 5ddc186e <= str2entry: str2ad(olcDbNoSync): attribute type undefined slapadd: could not parse entry (line=1620) _### 99.10% eta none elapsednone spd 18.7 M/s However the actual LDIF file is just fine: slapadd -F /tmp/slapd.d -l slapd-config.ldif -n 0 _ 100.00% eta none elapsednone fast! Closing DB... I'm guessing that on a dry-run, it doesn't actually fully load the modules defined in moduleload to get their schema definitions, which results in a false failure instead of a success.
(ITS#9121) dynlist enhancements
Full_Name: Quanah Gibson-Mount Version: 2.4 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.143.26) There are some enhancements to dynlist that would make it more useful/versatile: a) Be able to do (unique)member= searches to find all groups a given group member belongs to b) be able to generate dynamic (is)memberOf values on user entries for the groups they belong to
(ITS#9119) back-monitor can miscount monitorOpCompleted
Full_Name: Quanah Gibson-Mount Version: 2.4.43 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.143.26) When querying the monitor backend for monitorOpCompleted, the results are inconsistent. The code that calculates this value is also inefficient, as there is already a global counter of completed operations, but back-monitor doesn't use this and instead queries all the per-operation counters and then sums them together for the result, causing unnecessary work. These are the results of a series of queries: monitorOpCompleted: 326801 monitorOpCompleted: 326733 monitorOpCompleted: 326830 monitorOpCompleted: 326830 monitorOpCompleted: 326752 monitorOpCompleted: 326855 monitorOpCompleted: 326777
(ITS#9118) Add support for MAP_NOSYNC
Full_Name: Quanah Gibson-Mount Version: 2.4.48 OS: FreeBSD 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.143.26) To improve back-mdb performance on LMDB when dbnosync is set, it would be useful to support MAP_NOSYNC as documented at http://nixdoc.net/man-pages/FreeBSD/mmap.2.html
Re: (ITS#9115) It seems like the parameters about tlsCipherSuite not work
--On Wednesday, November 6, 2019 8:14 AM + bjm...@cn.ibm.com wrote: > Full_Name: nancy.mo > Version: 2.4.46 > OS: redhat7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.42.208.182) Hello, The ITS system is for bug reports, not help requests. Please redirect your question to the openldap-technical list for further assistance. <https://www.openldap.org/lists/mm/listinfo/openldap-technical> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9113) i can not find memberOf.la file
--On Tuesday, October 29, 2019 2:47 AM + machao0...@qq.com wrote: > Full_Name: ma > Version: 2.4.44 > OS: centos 7.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (119.253.39.18) Hello, The ITS system is for bug reports, not help requests. Please redirect your question to the openldap-technical list for further assistance. <https://www.openldap.org/lists/mm/listinfo/openldap-technical> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9114) pagedResultsControl not available in openldap search response
--On Monday, November 4, 2019 11:52 AM + prashanthmadd...@gmail.com wrote: > Full_Name: Prashanth Madduri > Version: 2.4.40 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (103.6.33.5) > > > Hi Team, > > I have huge data in OpenLDAP server and retrieve data using pagination. I > am using LDAPJS client library search functionality with paging to > retrieve the data. However as per my observation the response is not > returning pagedResultsControl in response. Hello, The ITS system is for bug reports, not help requests. Please redirect your question to the openldap-technical list for further assistance. <https://www.openldap.org/lists/mm/listinfo/openldap-technical> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9107) new feature
--On Monday, October 28, 2019 2:33 AM + ydgd...@163.com wrote: > Full_Name: Nannan Song I would ask in the future that you not spam the bug system with 8 copies of the same report. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
(ITS#9102) Update sasl-secprops ssf wording
Full_Name: Quanah Gibson-Mount Version: 2.4.48 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.154.120) The slapd.conf(5)/slapd-config(5) man pages contain this wording for the sasl-secprops keyword: 0 (zero) implies no protection, 1 implies integrity protection only, 56 allows DES or other weak ciphers, 112 allows triple DES and other strong ciphers, 128 allows RC4, Blowfish and other modern strong ciphers. The default is 0. I think it's been quite a while since RC4 was considered a "modern strong cipher".
Re: (ITS#9101) man pages don't reflect some global options are actually global/database
--On Friday, October 25, 2019 10:09 PM + qua...@openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.48 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.154.120) > > > The slapd.conf(5)/slapd-config(5) man pages list the security/olcSecurity > configuration option as a "GLOBAL" only config option. Correction, slapd-config(5) handles this via discussion of the frontend database. It's slapd.conf(5) where this is a mess (doesn't have any differentiation). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
(ITS#9101) man pages don't reflect some global options are actually global/database
Full_Name: Quanah Gibson-Mount Version: 2.4.48 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.154.120) The slapd.conf(5)/slapd-config(5) man pages list the security/olcSecurity configuration option as a "GLOBAL" only config option. However, inspection of the code reveals that it is in fact global OR a general database option. The man pages should be updated to reflect this fact. The same issue exists for the sizelimit and timelimit directives as well. May need to add a new structure to the manual pages to cover these 3 items, as they appear to be the only things that can exist as both global and per-db items. I.e., we should cover what happens if they are set both globally and per-db (what takes precedence, etc).
Re: (ITS#9098) assert fails in meta_back_search in some cases after reconnect
--On Wednesday, October 16, 2019 8:37 PM + maxime.bes...@worteks.com wrote: > Full_Name: Maxime Besson > Version: 2.4.47 > OS: Debian Jessie > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a01:cb00:802:8400:2cbe:3c60:fca6:e50b) I suggest upgrading to 2.4.48 to pick up this fix: Fixed slapd-meta assertion when network interface goes down (ITS#8841) --Quaanh -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9018) dynlist don't close connection
Decoded we have: "I have changed back-meta to the back-ldap, and it resolved this problem." --On Tuesday, September 24, 2019 11:59 AM + i.har...@a1.by wrote: -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9092) LDAP server out of memory
--On Wednesday, October 9, 2019 9:38 AM + gihanrid...@gmail.com wrote: > Full_Name: Gihan De Silva > Version: 2.4.44 > OS: 7.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (123.231.119.138) Hello, The OpenLDAP bug tracking system is for bug reports only. Usage questions should be directed to the OpenLDAP Technical discussion list: <https://www.openldap.org/lists/mm/listinfo/openldap-technical> If you have an urgent support need, then I suggest contacting one of the listed 3rd party support providers at: <https://www.openldap.org/support/> This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44
--On Friday, September 27, 2019 10:50 AM + Rajalakshmi Jayaraman wrote: > > > Hi Quanah, > > Can we have a solution for the issue reported at the earliest. Since we > have a release and the fix needs to be done. Hello Raji, If you need an immediate fix to an issue, you may wish to contact one of the companies that offers such services via the support page: <https://www.openldap.org/support/> The project itself cannot commit to when it will or will not have a specific issue resolved. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44
--On Thursday, September 26, 2019 3:11 PM + Rajalakshmi Jayaraman wrote: > > > Hi, > > The FTP "ftp://ftp.openldap.org/incoming/; is not working. Hence pasted > the pcap details, hope this helps It's working just fine: quanah@ub18:~$ ftp ftp.openldap.org Connected to www.openldap.org. 220 ProFTPD 1.3.4a Server (gauss) [:::23.92.27.230] Name (ftp.openldap.org:quanah): ftp 331 Anonymous login ok, send your complete email address as your password Password: 230 Anonymous access granted, restrictions apply Remote system type is UNIX. Using binary mode to transfer files. ftp> pass Passive mode on. ftp> cd incoming 250 CWD command successful ftp> mkdir its9088 257 "/incoming/its9088" - Directory successfully created ftp> cd its9088 250 CWD command successful ftp> lcd /tmp Local directory now /tmp ftp> put blah local: blah remote: blah 227 Entering Passive Mode (23,92,27,230,156,55). 150 Opening BINARY mode data connection for blah 226 Transfer complete ftp> -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
RE: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44
--On Thursday, September 26, 2019 2:19 PM + Rajalakshmi Jayaraman wrote: > > > Hi, > > Thanks for sharing the inputs. We have tried with the unmodified release > of OpenLDAP that was suggested. From the pcap, we have noticed the LDAP > search requests are sequential. (pl. find attached the pcap) for > reference Please put your pcap file on the FTP server rather than sending it via the ITS system. Then respond to the ITS with a link to the file. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9088) Concurrency not seen in OpenLDAP 2.4.44
--On Monday, September 23, 2019 10:22 AM + jrajalaks...@juniper.net wrote: > Full_Name: Rajalakshmi > Version: 2.4.44 > OS: RHEL 7.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (116.197.184.12) Hello, RedHat makes changes to OpenLDAP that are not reviewed by the OpenLDAP project. I would advise using an unmodified version of the current release of OpenLDAP to confirm whether or not this issue is in OpenLDAP itself or is caused by a change made by RedHat. You can use the packages from the LTB project for testing: <https://ltb-project.org/documentation/openldap-rpm#yum_repository> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9082) Issues while upgrading to 2.4.48
--On Tuesday, September 17, 2019 6:47 PM + krishradh...@gmail.com wrote: > Full_Name: Radhe Krish > Version: 2.4.44 > OS: Centos 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (139.85.223.11) Hello, The ITS system is for reporting bugs, not usage questions. Please redirect your query to the openldap-techni...@openldap.org email list for questions such as yours. I will note that this question has been asked and answered there already for other individuals, so if you look at the list archives, you'll find your answer. <https://www.openldap.org/lists/mm/listinfo/openldap-technical> <https://www.openldap.org/lists/openldap-technical/> <https://www.openldap.org/lists/openldap-technical/201908/msg00157.html> This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9079 documentation: slapo-unique syntax explanation unclear
--On Friday, September 13, 2019 6:07 PM + g...@nxg.name wrote: > Full_Name: Norman Gray > Version: 2.4.48 > OS: FreeBSD 12.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.209.45.140) Note: this is now ITS#9079. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9078) Indices MDB
--On Friday, September 13, 2019 5:54 PM + dpa-openl...@aegee.org wrote: Hello, The ITS system is for bug reports, not usage questions. Please redirect your questions to the openldap-techni...@openldap.org mailing list. This ITS will be closed. <https://www.openldap.org/lists/mm/listinfo/openldap-technical> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9077) slapo-unique spins its wheels on a non-trivial olcUniqueURI spec
--On Friday, September 13, 2019 4:34 PM + g...@nxg.name wrote: > Full_Name: Norman Gray > Version: 2.4.48 > OS: FreeBSD 12.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.209.45.140) Unrelated side note, ITS number fixed to be 9077. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9072) openLdap client problem
--On Friday, August 30, 2019 7:14 AM + feng.w...@iquantex.com wrote: > Thank you very much for getting support! > In the production of openldap is the HA environment, other uses are > normal, only in the modification of the user to multiple groups (some > client new user information is updated, and some other host clients are > not updated). Please update to a current release of OpenLDAP, i.e, at least version 2.4.48 as numerous replication fixes have been made to the product since that time. You were already told to upgrade in ITS#9053 as well. Please stop filing ITSes until such a time as you have upgraded to a current release. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9070) Failing to include openssl1.1.1c with openLDAP
--On Thursday, August 29, 2019 3:13 PM + vishal.bafna...@gmail.com wrote: > I am trying to build openLDAP using openssl1.1.1c. > It is failing to locate the SSL/TLS package. > I have given the openssl lib and include paths in LDFLAGS and CPPFLAGS > respectively in the Makefile of LDAP. The Make file also has > --with-tls=openssl \ mentioned as config option The ITS system is for bug reports, not help requests on how to build the software. If you need help with building the software, please use the openldap-techni...@openldap.org email list. <https://www.openldap.org/lists/mm/listinfo/openldap-technical> This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
(ITS#9071) Invalid olcDbStartTLS values generated on back-ldap conversion
Full_Name: Quanah Gibson-Mount Version: 2.4.48 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) When converting this basic slapd.conf for back-ldap: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/openldap.schema include /usr/local/etc/openldap/schema/ppolicy.schema include /usr/local/etc/openldap/schema/misc.schema loglevel 256 pidfile /var/run/slapd.pid argsfile/var/run/slapd.args modulepath /usr/local/libexec/openldap moduleload rwm moduleload back_ldap databaseldap readonlyyes protocol-version3 rebind-as-user yes uri "ldaps://universe.example.com" suffix "dc=universe,dc=example,dc=com" overlay rwm rwm-map attribute uid sAMAccountName rwm-map attribute mailproxyAddresses chase-referrals yes idassert-bind bindmethod=simple binddn="cn=ldap_phone,ou=LDAP Access,dc=example,dc=com" credentials='Password1234' tls_cacert=/usr/local/etc/openldap/example_com_Universe_Root_CA.cer The resulting back-ldap configuration has an invalid olcDbStartTLS attribute: olcDbStartTLS: none starttls=no Per the man page, "none" is not valid at all, and also per the man page, since the URI is using ldaps, the value should be: olcDbStartTLS: ldaps Config is based off of a real life configuration from an end user, where things worked with slapd.conf but were broken post-conversion to cn=config. Fixing the olcDbStartTLS value to be valid resolved the issue.
Re: (ITS#9066) Missing custom attrs after restart slapd
--On Thursday, August 22, 2019 12:08 PM + juanma...@yahoo.es wrote: > Full_Name: JuanMa > Version: 2.4.45 > OS: Ubuntu 18.04.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.176.151.51) > > > Afeter creating custom attrs, I can see in ldap browser, but after > restart sldap daemon, custom attrs are missing (sorry, bad english) > OLC mode and mdb database Hello, That is not the correct way to modify the schema or add new attributes. Please use the openldap-techni...@openldap.org list for help. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
(ITS#9065) slapo-ppolicy(5) man page refers to wrong attribute
Full_Name: Quanah Gibson-Mount Version: 2.4.48 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) The slapo-ppolicy(5) man page has this statement in the description of pwdGraceUseTime: If too many grace logins have been used (please refer to the pwdGraceLoginLimit password policy attribute), However, there is no such attribute as "pwdGraceLoginLimit". It is instead pwdGraceAuthnLimit
Re: (ITS#9064) client tools not recognizing BINDDN from ldap.conf
--On Sunday, August 18, 2019 12:19 AM + fabrice.du...@gmail.com wrote: > In my ldap.conf The ldap.conf(5) man page clearly states that the BINDDN variable is a USER ONLY option. That means it will only be honored if it appears in the ~user/.ldaprc file. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9062) Please have /build/mkdep respect TMPDIR if set
--On Sunday, August 11, 2019 7:34 PM + zag...@oclc.org wrote:
> Would you please consider changing this to:
>
> TMP=${TMPDIR-/tmp}/mkdep$$
Thanks for the report, this is fixed in OpenLDAP master.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
(ITS#9063) tls_reqcert in slapd.conf/slapd-config man pages should be bold
Full_Name: Quanah Gibson-Mount Version: 2.4.48 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) When looking at the man pages, the tls_reqcert description in the section of the man page about syncrepl is missing a BOLD tag, unlike the other keywords. Trivial fix.
Re: (ITS#9061) LDAP replication issue on a big network
--On Wednesday, August 07, 2019 10:35 AM + ale...@wildix.com wrote: > Full_Name: Alex > Version: 2.4.44+dfsg-5+deb9u2 Hello, The ITS system is for bug reports, not usage questions. Additionally, if you're doing replication of any type, please upgrade to the latest release (2.4.48). Ensure you are using delta-syncrepl. For any other questions, please use the correct forum which is the openldap-techni...@openldap.org mailing list: <https://www.openldap.org/lists/mm/listinfo/openldap-technical>. I believe there is a backport of 2.4.48 for Debian9 from the backports repo. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9059) session log parsing triggers cascading REFRESH
--On Thursday, August 01, 2019 4:16 PM + qua...@openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.47 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.128.44) > > > In investigating why a particular consumer went into REFRESH mode, I find > that this was triggered by one of its providers currently parsing a > sessionlog. Sessionlog parsing should *not* cause a consumer of that > server to fall back to REFRESH. Some notes on this specific environment and situation. This is a 4-way MMR setup. Via the use of a load balancer, only iam-ed-ldp-p01 recieves write operations. Thus there should never be any REFRESHes occurring anywhere, so the fact that there is is already problematic. Servers are p01, p02, p03 (all in the same data center) and b01 (offsite DR system). At the time this issue hit: p01 was upgraded to a new release of OpenLDAP @ 21:26:48, thus we see: Jul 30 21:25:17 iam-ed-ldp-p01 slapd[30495]: slapd shutdown: waiting for 0 operations/tasks to finish Jul 30 21:26:48 iam-ed-ldp-p01 slapd[20978]: @(#) $OpenLDAP: slapd 2.4.47 (Mar 22 2019 09:12:20) $#012#011bu...@rhel7build.rb.symas.net:/home/build/sold-2.4.47.3/redhat7-x86_64/build/openldap.x86_64/servers/slapd Jul 30 21:26:48 iam-ed-ldp-p01 slapd[20979]: slapd starting Jul 30 21:26:48 iam-ed-ldp-p01 slapd[20979]: do_syncrep2: rid=002 LDAP_RES_INTERMEDIATE - REFRESH_DELETE Jul 30 21:26:48 iam-ed-ldp-p01 slapd[20979]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT Jul 30 21:26:48 iam-ed-ldp-p01 slapd[20979]: do_syncrep2: rid=001 delta-sync lost sync, switching to REFRESH Jul 30 21:26:48 iam-ed-ldp-p01 slapd[20979]: do_syncrep2: rid=001 (4096) Content Sync Refresh Required Jul 30 21:26:48 iam-ed-ldp-p01 slapd[20979]: do_syncrep2: rid=003 LDAP_RES_INTERMEDIATE - REFRESH_DELETE p03 was operating w/o issue. Interstingly enough, when it was restarted for the software update @ 21:37:16, it got an error (53) talking to p02 instead of an error (4096) like p01 did. This is likely because p02 was restarted for its software update @ 21:32:19, which wiped out its sessionlog. p02 had started doing session log parsing @ 21:26:17 with Jul 30 21:26:17 iam-ed-ldp-p02 slapd[3750]: conn=18205759 op=1 SEARCH RESULT tag=101 err=4096 duration=18.462ms nentries=0 text=sync cookie is stale We see the connection to p02 from p01 with a similar issue when it starts up: Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: conn=18205790 op=1 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: conn=18205790 op=1 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: conn=18205790 op=1 SEARCH RESULT tag=101 err=4096 duration=0.431ms nentries=0 text=sync cookie is stale b01 had its software update @ 21:21:25 Generally it seems like restarting/wiping the sessionlog made things incredibly bad across the cluster. -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
(ITS#9059) session log parsing triggers cascading REFRESH
Full_Name: Quanah Gibson-Mount Version: 2.4.47 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) In investigating why a particular consumer went into REFRESH mode, I find that this was triggered by one of its providers currently parsing a sessionlog. Sessionlog parsing should *not* cause a consumer of that server to fall back to REFRESH. Server that got dropped into REFRESH incorrectly: Jul 30 21:26:48 iam-ed-ldp-p01 slapd[20979]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT Jul 30 21:26:48 iam-ed-ldp-p01 slapd[20979]: do_syncrep2: rid=001 delta-sync lost sync, switching to REFRESH Jul 30 21:26:48 iam-ed-ldp-p01 slapd[20979]: do_syncrep2: rid=001 (4096) Content Sync Refresh Required RID001 server: Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181127055648.177968Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181109151409.323374Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181127122502.661263Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181127061139.881198Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181127062500.514773Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181127061139.941766Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181127062500.622874Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181127061139.977196Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181127062500.656726Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181109151409.575116Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181127062500.672371Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181127062500.701608Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181109151409.833435Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181127062500.766277Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181109151410.102670Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181127055648.192922Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181127061140.091604Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181127062500.859669Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181127061140.160929Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181127122502.664055Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181127061140.213051Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: cmp -256, too old Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181127122502.666873Z#00#001#00 Jul 30 21:26:48 iam-ed-ldp-p02 slapd[3750]: log csn 20181127062500.892859Z#00#001#00
Re: (ITS#9052) ACL protections get lost if same identity uses different SSF levels
--On Wednesday, July 24, 2019 3:45 PM -0700 Quanah Gibson-Mount wrote: > For informational purposes, here's additional detail as the subject and > original problem description do not fully capture the extend of the > problem. In all 2.x releases prior to 2.4.48 (I.e., 2.0.x, 2.1.x, 2.2.x, > 2.3.x, and 2.4.x up to 2.4.47), the SASL security factor layer was set > globally rather than per connection. So once a connection had been made > that sets a SASL SSF, any and all non SASL connections would inherit that > value. Correction -- sasl SSF was set per connection structure. Any new client connection that used the same connection structure as a previous connection would inherit the sasl_ssf value of the prior connection. In slapd, one can generally tell which connection structure is being used by looking at the file descriptor in use by a given connection (stats level logging will display this information, for example). On a busy server where connection structures are routinly being re-used then there is a high probability that this would apply to most connections as long as the majority of connections are setting SASL SSF values. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9052) ACL protections get lost if same identity uses different SSF levels
For informational purposes, here's additional detail as the subject and original problem description do not fully capture the extend of the problem. In all 2.x releases prior to 2.4.48 (I.e., 2.0.x, 2.1.x, 2.2.x, 2.3.x, and 2.4.x up to 2.4.47), the SASL security factor layer was set globally rather than per connection. So once a connection had been made that sets a SASL SSF, any and all non SASL connections would inherit that value. If ACLs are used to limit access via setting restrictions with the sasl_ssf parameter, connections with no sasl_ssf could match those ACLs incorrectly. For example, access to * by users sasl_ssf=56 read by users tls_ssf=128 read by * none Would allow a user who bound without any encryption full access to the database as long as one SASL connection had been made that had a minimum sasl_ssf value of 56. Another contrived example: access to attrs=userPassword by self sasl_ssf=56 =xw by * auth Would allow a user to change their own password whether or not they had performed a SASL bind with a sasl_ssf of 56. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9056) Replication does not work with different schemas on primary and secondary LDAP
--On Tuesday, July 23, 2019 8:10 AM + alex.solov...@wildix.com wrote: > Actually, I have the configuration with several LDAP server without this = > problem. But the version of these LDAPs is a bit less - 2.4.31.=20 > On this installation when I changed the schema on the main server, on = > secondary I see fully replicated data and warnings about unknown = > attributes like: Yes, that was a known bug with older OpenLDAP versions. In general: a) Don't mix versions of OpenLDAP b) Use current releases of OpenLDAP c) Use delta-syncrepl for replication d) Upgrade the schema on replicas first, then on masters Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#7326) additional notes
The related glibc bugs are: <https://sourceware.org/bugzilla/show_bug.cgi?id=12398> <https://sourceware.org/bugzilla/show_bug.cgi?id=12377> RedHat patched around this as noted in <https://bugzilla.redhat.com/show_bug.cgi?id=505105> Other useful information in <https://bugzilla.redhat.com/show_bug.cgi?id=699576> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#7326) [PATCH] use AI_ADDRCONFIG if defined in the environment
This patch is rejected as it requires RedHat's custom version of glibc that has been patched to address issues like: <https://sourceware.org/bugzilla/show_bug.cgi?id=12398> <https://sourceware.org/bugzilla/show_bug.cgi?id=12377> In the future, I would ask that RedHat not submit patches that depend on custom RedHat implementations of core libraries. Thanks. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
--On Thursday, July 18, 2019 7:37 PM + g...@members.scinet.supercomputing.org wrote: > - Allow the OTP from the previous time window to be accepted, provided > there has been no successful bind in or after that time window. This > avoids false authentication failures if for example the time window rolls > over as the OTP is being entered or transmitted. This should be a configuration item that is an integer value of the number of seconds to allow outside of the timeslice, with 0 meaning only the default time slice is allowed. Allowing people to authenticate outside of the time slice is of course a security issue and should not be allowed by default (So the default value of the parameter should be 0). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9054) Add support for multiple EECDH curves
--On Tuesday, July 16, 2019 9:45 PM + qua...@openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.47 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.128.44) > > > Currently OpenLDAP only allows for a single EECDH curve to be configured. > However, OpenSSL 1.0.2 released in January 2015 was the first release to > implement negotiation of supported curves in TLS servers. OpenLDAP needs > updating to support this functionality. tls_dh.c in postfix/src/tls_dh.c gives some insight into how to correctly do this with OpenSSL, in the tls_auto_eecdh_curves fucntion. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
(ITS#9054) Add support for multiple EECDH curves
Full_Name: Quanah Gibson-Mount Version: 2.4.47 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) Currently OpenLDAP only allows for a single EECDH curve to be configured. However, OpenSSL 1.0.2 released in January 2015 was the first release to implement negotiation of supported curves in TLS servers. OpenLDAP needs updating to support this functionality.
Re: (ITS#9051) slapo-accesslog fails to log compare, search
--On Monday, July 08, 2019 11:33 PM + qua...@openldap.org wrote: Note: compare operations are confirmed also to not log. :~# ldapcompare -Y EXTERNAL -H ldapi:/// cn=admin,dc=rb,dc=symas,dc=net cn:admin TRUE ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=accesslog -LLL dn: cn=accesslog objectClass: auditContainer cn: accesslog dn: reqStart=2019070817.00Z,cn=accesslog objectClass: auditBind reqStart: 2019070817.00Z reqEnd: 2019070817.01Z reqType: bind reqSession: 1014 reqAuthzID: reqDN: cn=admin,dc=rb,dc=symas,dc=net reqResult: 0 reqVersion: 3 reqMethod: SIMPLE dn: reqStart=20190709001033.00Z,cn=accesslog objectClass: auditBind reqStart: 20190709001033.00Z reqEnd: 20190709001033.01Z reqType: bind reqSession: 1019 reqAuthzID: reqDN: cn=admin,dc=rb,dc=symas,dc=net reqResult: 0 reqVersion: 3 reqMethod: SIMPLE --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
(ITS#9051) slapo-accesslog fails to log compare, search
Full_Name: Quanah Gibson-Mount
Version: 2.4.47
OS: N/A
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.128.44)
In testing out various logging scenarios with the accesslog overlay, it has been
found that it fails to log certain operations in the underlying accesslog DB.
Specifically, it fails to log "reads" or "compare" + "search". It does however
log "writes" or "bind".
Example configuration:
dn: olcDatabase={2}mdb,cn=config
objectClass: olcMdbConfig
objectClass: olcDatabaseConfig
olcDatabase: {2}mdb
olcDbDirectory: /var/lib/ldap/accesslog
olcAddContentAcl: FALSE
olcDbIndex: default eq
olcDbIndex: objectClass
olcDbIndex: entryUUID
olcDbIndex: entryCSN
olcDbIndex: reqStart
olcDbIndex: reqEnd
olcDbIndex: reqResult
olcDbIndex: reqDN
olcDbMaxReaders: 0
olcDbMaxSize: 512
olcDbMode: 0600
olcDbNoSync: FALSE
olcDbRtxnSize: 1
olcDbSearchStack: 16
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcMonitoring: TRUE
olcReadOnly: FALSE
olcRootDN: cn=config
olcSuffix: cn=accesslog
olcSyncUseSubentry: FALSE
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=extern
al,cn=auth manage by * break
dn: olcOverlay={0}accesslog,olcDatabase={1}mdb,cn=config
objectClass: olcAccessLogConfig
objectClass: olcOverlayConfig
olcAccessLogDB: cn=accesslog
olcOverlay: {0}accesslog
olcAccessLogOps: reads
olcAccessLogOps: writes
olcAccessLogPurge: 1+00:00 1+00:00
olcAccessLogSuccess: TRUE
Performing a search in this scenario results in nothing logged.
Changing it to "reads" only (no writes), nothing logged
Changing it to "bind, search, compare", the bind is logged, but nothing else:
root@anvil3:~/accesslog-testing# ldapsearch -Y EXTERNAL -H ldapi:/// -b
cn=accesslog -LLL -Q
dn: cn=accesslog
objectClass: auditContainer
cn: accesslog
dn: reqStart=2019070817.00Z,cn=accesslog
objectClass: auditBind
reqStart: 2019070817.00Z
reqEnd: 2019070817.01Z
reqType: bind
reqSession: 1014
reqAuthzID:
reqDN: cn=admin,dc=rb,dc=symas,dc=net
reqResult: 0
reqVersion: 3
reqMethod: SIMPLE
Search is clearly logged at STATS level logging:
Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 fd=12 ACCEPT from IP=[::1]:51644
(IP=[::]:389)
Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=0 BIND
dn="cn=admin,dc=rb,dc=symas,dc=net" method=128
Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=0 BIND
dn="cn=admin,dc=rb,dc=symas,dc=net" mech=SIMPLE ssf=0
Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=0 RESULT tag=97 err=0 text=
Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=1 SRCH
base="dc=rb,dc=symas,dc=net" scope=2 deref=0 filter="(objectClass=*)"
Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=1 SEARCH RESULT tag=101 err=0
nentries=2 text=
Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=2 UNBIND
Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 fd=12 closed
Re: (ITS#8977) Make IDL sizes configurable in back-mdb
--On Thursday, June 27, 2019 8:56 PM + qua...@symas.com wrote: > --On Thursday, June 27, 2019 8:35 PM + h...@symas.com wrote: > >> No, because order is irrelevant for these. > > Cool, thanks! I'll continue on with deeper testing then. :) Given the current implementation of OpenLDAP, this feature is impossible to use w/o recompiling OpenLDAP when a change to the IDL size is made. This is because LDAP_PVT_THREAD_STACK_SIZE must be adjusted as well and that requires a recompile. The default size for LDAP_PVT_THREAD_STACK_SIZE is: ( 1 * 1024 * 1024 * sizeof(void *) ) which works for an IDL size of 16 (2^16) which is 65536. If you change the IDL size, say to 22, then the new IDL size is: 4,194,304. We then use this difference to find the offset we need to adjust LDAP_PVT_THREAD_STACK_SIZE by: 4194304/65536 = 64 So it needs to be 64 time larger: ( 64 * 1024 * 1024 * sizeof(void *) ) Generally, this feature is simply unusuable (currently) as a tunable given the requirement for recompiling OpenLDAP to use it. --QUanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
--On Sunday, April 07, 2019 10:15 AM + henrik.bohnenk...@ionos.com wrote: > On Thu, Apr 04, 2019 at 05:32:16PM +0100, Howard Chu wrote: > Hi Howard, > > thanks for your comments. There is now a new version of patches available > in my github repository. Apart from addressing your comments, I have > rebased the patches against the current master branch (quite a lot > activity in the last two months, I have noticed). In particular, the new > function mdb_get_aliases now also uses the global size variables for IDL > dimensions, rather than the previous CPP constants. Had a customer who was hitting this issue try out these patches -- It greatly decreases the search time (from unknown/infinite to 1 minute). Unfortunately slapd then segv's. Working on getting a test database to reproduce the issue with for a good backtrace. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#8427) Incorrect value of tls_reqcert in syncrepl
Hello, Unfortunately this patch introduces a regression and breaks existing configurations where the protocol in use is ldaps:///. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Regression after ITS#8427 fix with back-ldap
--On Thursday, June 27, 2019 11:51 PM +0200 Abdelkader Chelouah wrote: > > I tried with with > > > olcDbStartTLS: ldaps > > > with no success. > > > Logs on the proxy > > > 2019-06-27T20:46:07.602925+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > fd=11 ACCEPT from IP=[::1]:46462 (IP=[::1]:10020) > 2019-06-27T20:46:07.603476+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=0 BIND dn="uid=alice,ou=people,dc=local" method=128 > 2019-06-27T20:46:07.609212+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=0 ldap_back_retry: retrying URI="ldaps://arrakis.local:10011" DN="" > 2019-06-27T20:46:07.613435+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=0 RESULT tag=97 err=52 text=Proxy operation retry failed > 2019-06-27T20:46:07.613968+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=1 UNBIND > 2019-06-27T20:46:07.614264+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > fd=11 closed > > Logs on the backend ldap server > > > 2019-06-27T20:46:07.609971+00:00 arrakis slapd-2.4-aa[14682]: conn=1011 > fd=12 ACCEPT from IP=172.18.0.2:47156 (IP=172.18.0.2:10011) > 2019-06-27T20:46:07.613718+00:00 arrakis slapd-2.4-aa[14682]: conn=1011 > fd=12 closed (TLS negotiation failure) Thanks! Please include the openldap-its list in your replies so that they properly get associated with the relevant ITS. I'll raise this up as a priority for the 2.4.48 release. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Regression after ITS#8427 fix with back-ldap
--On Thursday, June 27, 2019 9:08 PM + a.chelo...@gmail.com wrote: > This is a multi-part message in MIME format. > --93F3FA89632EC27DC6224304 > Content-Type: text/plain; charset=utf-8; format=flowed > Content-Transfer-Encoding: 7bit > > Hello, > > Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up > TLS settings on each reconnection) introduce a regression when the proxy > connect to the**Backend ldap server via ldaps:// Thanks for the follow up! It may be useful in the future to participate in the testing calls that are noted on the openldap-devel list as well. Does the issue persist if you set: olcDbStartTLS: ldaps as documented in the slapd-ldap(5) man page? Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#8977) Make IDL sizes configurable in back-mdb
--On Thursday, June 27, 2019 8:35 PM + h...@symas.com wrote: > No, because order is irrelevant for these. Cool, thanks! I'll continue on with deeper testing then. :) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#8977) Make IDL sizes configurable in back-mdb
--On Tuesday, June 25, 2019 7:07 PM + qua...@symas.com wrote:
> c) That conversion from slapd.conf to cn=config be fixed so that it works.
I'm not entirely sure that the fix that went in for this in
ec411582d663667d6b638162db51dfa70f5263d3 is correct. Specifically, unlike
everything else, there is no associated weight. If in the future other
backends (such as SQL, LDAP, etc) support server-wide settings via an
olcBackend configuration, the weight would need to exist.
root@anvil4:/tmp/q/slapd.d/cn=config# ls -l
total 64
-rw--- 1 root root 448 Jun 27 12:19 'cn=module{0}.ldif'
drwxr-x--- 2 root root 4096 Jun 27 12:19 'cn=schema'
-rw--- 1 root root 39646 Jun 27 12:19 'cn=schema.ldif'
-rw--- 1 root root 435 Jun 27 12:19 'olcBackend=mdb.ldif'
-rw--- 1 root root 596 Jun 27 12:19 'olcDatabase={-1}frontend.ldif'
-rw--- 1 root root 584 Jun 27 12:19 'olcDatabase={0}config.ldif'
-rw--- 1 root root 859 Jun 27 12:19 'olcDatabase={1}mdb.ldif'
I.e., I was rather expecting:
olcBackend={1}mdb.ldif
or similar.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Re: (ITS#8977) Make IDL sizes configurable in back-mdb
--On Monday, May 06, 2019 9:28 PM + qua...@symas.com wrote: To further document the issues after further testing with OpenLDAP master as of 6/25/2019 a) If a value for idlexp is set in a slapd.conf file that is not allowed (< 16 or > 31), converting to cn=config using slaptest will incorrectly report that the target "slapd.d" directory doesn't exist, like: /usr/local/etc/openldap# /usr/local/sbin/slaptest -f slapd.conf -F /tmp/slapd.d slaptest: bad configuration directory! ls -ld /tmp/slapd.d drwxr-xr-x 2 root root 40 Jun 25 17:59 /tmp/slapd.d b) If the idlexp value is corrected to be within the allowed range, the converted cn=config database loses the backend configuration and the idlexp setting: /usr/local/sbin/slaptest -f slapd.conf -F /tmp/slapd.d config file testing succeeded cd /tmp/slapd.d/ find . -type f | xargs grep -i idlexp ./cn=config/cn=schema.ldif:olcAttributeTypes: ( OLcfgBkAt:12.1 NAME 'olcBkMdbIdlExp' DESC 'Power of 2 u ./cn=config/cn=schema.ldif: onfiguration' SUP olcBackendConfig STRUCTURAL MAY olcBkMdbIdlExp ) No olcBackend... file exists, etc. Suggested remedies: a) The man page documentation be updated to note the limitations on valid ranges for the idlexp setting (16<=x<=31), at least for 64-bit systems. b) slaptest provides a valid error if the idlexp setting is not within the valid range (as opposed to complaining the target directory does not exist, when in fact it does). c) That conversion from slapd.conf to cn=config be fixed so that it works. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9042) loglevel setting that allows seeing attribute values for MOD operations
--On Tuesday, June 25, 2019 5:04 PM + qua...@openldap.org wrote: > Currently there is no way to see what values a client is providing for a > MOD operation outside of the "packets" debug level. It would be helpful > for debugging purposes where one does not have control of the client to > be able to set a loglevel that would expose this information. STATS2 would be the appropriate loglevel setting. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
(ITS#9042) loglevel setting that allows seeing attribute values for MOD operations
Full_Name: Quanah Gibson-Mount Version: HEAD OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) Currently there is no way to see what values a client is providing for a MOD operation outside of the "packets" debug level. It would be helpful for debugging purposes where one does not have control of the client to be able to set a loglevel that would expose this information.
Re: (ITS#9041) cyrus.c includes limits.h twice
--On Friday, June 21, 2019 10:58 PM + qua...@openldap.org wrote: > This should be cleaned up. Fixed in b02807ea2f5eaf85e57e67e5851931a116947b94 --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
(ITS#9041) cyrus.c includes limits.h twice
Full_Name: Quanah Gibson-Mount Version: RE24 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) There appear to have been dueling commits on April 10, 2005 and April 9, 2005, so that we get: 3e800f20bd (Kurt Zeilenga 2005-04-10 19:32:14 + 28)#ifdef HAVE_LIMITS_H 3e800f20bd (Kurt Zeilenga 2005-04-10 19:32:14 + 29)#include 3e800f20bd (Kurt Zeilenga 2005-04-10 19:32:14 + 30)#endif 3e800f20bd (Kurt Zeilenga 2005-04-10 19:32:14 + 31) bc0cc3272c (Kurt Zeilenga 2003-02-21 17:48:03 + 32)#include "ldap-int.h" bc0cc3272c (Kurt Zeilenga 2003-02-21 17:48:03 + 33) bc0cc3272c (Kurt Zeilenga 2003-02-21 17:48:03 + 34)#ifdef HAVE_CYRUS_SASL bc0cc3272c (Kurt Zeilenga 2003-02-21 17:48:03 + 35) eca819d866 (Howard Chu 2005-04-09 06:41:39 + 36)#ifdef HAVE_LIMITS_H eca819d866 (Howard Chu 2005-04-09 06:41:39 + 37)#include eca819d866 (Howard Chu 2005-04-09 06:41:39 + 38)#endif This should be cleaned up.
Re: (ITS#7996) Tighten race in ldap_int_initialize
--On Monday, June 17, 2019 7:16 PM +0200 Armin T=C3=BCting=20 wrote: >> I.e., it started and then got as far as reading your ldap.conf file. >> What is the contents of ldap.conf? > Attached 'ldap.conf'. Nothing unusual... > >> Have you run the test suite (make test)? Does it pass? fail? > Attached 'make_test.txt'. As far as I can see - it has been passed. Ok, so make test passes without issue, so it would appear there's something = specific with your configuration that is triggering the problem. Would you = be able to provide your slapd configuration (minus any passwords and the=20 like)? Additionally, if you could get a full gdb backtrace of the hung slapd=20 process that would be useful as well. I.e.: start up slapd gdb /path/to/slapd at the gdb prompt: thr apply all bt full Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#7996) Tighten race in ldap_int_initialize
--On Monday, June 17, 2019 9:59 AM +0200 Armin T=C3=BCting=20 wrote: >> > Hi, >> > >> > Thanks for the report. When reporting issues, please keep them on >> > the=3D20 OpenLDAP bug tracking list, rather than directly emailing >> > individuals. >> You will need to provide substantially more information about what >> you're seeing. I would start with starting slapd in full debug mode >> (add -d -1 to the startup flags to slapd) and see what issue(s) it >> reports. > Slapd won't even start at all! No log! > I'm attaching the redirected output from 'make test'. In addition the > 'config.log' and 'slapd_start.txt'. Hi Armin, Again, I will please ask you CC replies to the OpenLDAP ITS list=20 (openldap-its@openldap.org) so they properly get entered into the issue=20 tracker. Your slapd_start.txt attachment clearly shows slapd starting: time /opt/openldap/libexec/slapd -F /opt/openldap/etc/openldap/slapd.d -u=20 ldap -h "ldapi:/// ldap:/// ldaps:///" -d -1=20 ldap_url_parse_ext(ldap://localhost/) ldap_init: trying /opt/openldap/etc/openldap/ldap.conf ldap_init: using /opt/openldap/etc/openldap/ldap.conf ^C I.e., it started and then got as far as reading your ldap.conf file. What=20 is the contents of ldap.conf? Have you run the test suite (make test)? Does it pass? fail? Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#7996) Tighten race in ldap_int_initialize
--On Sunday, June 16, 2019 7:54 PM + qua...@symas.com wrote: > --On Sunday, June 16, 2019 4:06 PM +0200 Armin T=C3=BCting=20 > wrote: > >> Hello Quanah, >> >> I'm following OPENLDAP_REL_ENG_2_4. The commit >> 'cde56fad154fcd25e351c3cd84d8173d263b0a01' breaks starting slapd. It >> won't start at all... >> >> I'm using a fairly up-to-date CentOS 7 version... >> 3.10.0-957.21.2.el7.x86_64 #1 SMP Wed Jun 5 14:26:44 UTC 2019 x86_64 > > Hi, > > Thanks for the report. When reporting issues, please keep them on the=20 > OpenLDAP bug tracking list, rather than directly emailing individuals. > > I'm unable to reproduce this with Ubuntu18 (all tests in the test suite=20 > pass via make test, and I can start slapd just fine w/o debug mode). > I'll=20 test on centos7 and see if I can reproduce. I'm also unable to reproduce any issues with current RE24 (0c44b22d3e347f2f05f913e7e3ffa907816574ed) under fully updated Centos7: CentOS Linux release 7.6.1810 (Core) kernel-headers.x86_64 3.10.0-957.21.2.el7 @updates You will need to provide substantially more information about what you're seeing. I would start with starting slapd in full debug mode (add -d -1 to the startup flags to slapd) and see what issue(s) it reports. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#7996) Tighten race in ldap_int_initialize
--On Sunday, June 16, 2019 4:06 PM +0200 Armin T=C3=BCting=20 wrote: > Hello Quanah, > > I'm following OPENLDAP_REL_ENG_2_4. The commit > 'cde56fad154fcd25e351c3cd84d8173d263b0a01' breaks starting slapd. It > won't start at all... > > I'm using a fairly up-to-date CentOS 7 version... > 3.10.0-957.21.2.el7.x86_64 #1 SMP Wed Jun 5 14:26:44 UTC 2019 x86_64 Hi, Thanks for the report. When reporting issues, please keep them on the=20 OpenLDAP bug tracking list, rather than directly emailing individuals. I'm unable to reproduce this with Ubuntu18 (all tests in the test suite=20 pass via make test, and I can start slapd just fine w/o debug mode). I'll=20 test on centos7 and see if I can reproduce. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9033) Computer Object
--On Thursday, June 13, 2019 12:43 PM + jgbuenavent...@gmail.com wrote: > Hi, > > I am trying to add a computer/network device (windows, linux, routers) in > Openldap, but i cannot find a specific, schema/objectclass/attribute for > that. Any advice? Hello, The ITS system is for reporting bugs, not asking usage questions. Please use the openldap-techni...@openldap.org mailing lists for questions such as those above (<https://www.openldap.org/lists/mm/listinfo/openldap-technical>). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
(ITS#9031) Guide updates for 2.4
Full_Name: Quanah Gibson-Mount Version: 2.4.47 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) The admin guide for delta-syncrepl needs updating. For example, it is missing the reqDN attribute being indexed. Additionally, it should be updated to reference mdb rather than hdb, since it is the preferred backend now in 2.4
Re: (ITS#8962) Dead links in FAQ page "Where can I find listings of schema items?"
--On Friday, June 07, 2019 8:53 AM +0200 Michael Str=C3=B6der=20 wrote: > The FAQ contains the only documentation for set-based ACLs. > > So it's not an option to just shutdown FAQ-O-MATIC. Sure, any useful articles need to get moved to something. Just saying=20 overall, I think it's time for the existing FAQ to die. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#8946) openldap bug
Hello, There is no bug here. Your configuration is invalid. If you need help with configuring OpenLDAP, then please use the openldap-techni...@openldap.org mailing list. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#8962) Dead links in FAQ page "Where can I find listings of schema items?"
--On Friday, January 25, 2019 9:25 PM + mich...@stroeder.com wrote: > All links herein are dead: > https://www.openldap.org/faq/data/cache/220.html > > I'd suggest to remove this FAQ page completely. I tried, but unfortunatley the FAQ software breaks Apache when you try and delete an answer. I think the better solution is just to remove the FAQ software completely. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#8988) Undefined Behavior in slapadd
--On Thursday, March 07, 2019 10:10 AM + noloa...@gmail.com wrote: > Full_Name: JW > Version: 2.4.47 > OS: Linux (Fedora 29, x86_64, fully patched) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (151.196.22.177) > > > I added -fsanitize=undefined to CFLAGS. Hello, In this case, the compiler is the problem. LMDB is 100% correct regarding alignment on all supported CPUs (which is most of them). The x86 family fully supports unaligned access, so LMDB makes use of this. On other CPUs, which do not support unaligned access (e.g., SPARC), LMDB doesn't use them. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9029) MDB_MAP_FULL error after removing some records from DB
--On Wednesday, June 05, 2019 7:53 PM + Alexey Dubovkin wrote: > Thank you! > Alexey Hi Alexey, As Howard already noted in his response to the ITS, there is no demonstrated bug here. It would appear you've run out of free pages given the mapsize you started with. As noted in the documentation, the general expectation is one sets a very large mapsize from the start. Hope that helps! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9029) MDB_MAP_FULL error after removing some records from DB
--On Tuesday, May 28, 2019 10:12 PM + adubov...@linkedin.com wrote: > Full_Name: Alex > Version: LMDB 0.9.23 > OS: iOS > URL: https://hastebin.com/raw/arexecefew > Submission from: (NULL) (2620:119:5001:3000:242c:3bea:acec:6a7d) ITS#8969 perhaps? <https://www.openldap.org/its/index.cgi/?findid=8969> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#8417) mdb_load could use an option to specify the mapsize.
--On Tuesday, May 03, 2016 12:48 PM + eriixblaike+...@gmail.com wrote: > I, Eric Monson, hereby place the following modifications to OpenLDAP > Software (and only these modifications) into the public domain. Hence, > these modifications may be freely used and/or redistributed for any > purpose with or without attribution and/or other notice. > > https://eriix.org/download_file/eric-monson-16-05-03.patch This URL is not accessible (requires a login?). I suggest uploading it to our FTP server as documented for contributed patches. Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9028) Not able to add 'syncprov' module
--On Sunday, May 26, 2019 12:47 PM + danybensig...@gmail.com wrote: > Full_Name: Dany Bensighar Hello, The ITS system is for bug reports. Usage questions such as this should be sent to the openldap-techni...@openldap.org mailing list (<https://www.openldap.org/lists/mm/listinfo/openldap-technical>) This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9025) Suggested enhancement: Automatically order module loading according to dependencies
--On Saturday, May 18, 2019 9:48 AM + ja...@turnersoft.co.uk wrote: > Full_Name: James Turner > Version: 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.86.27.193) > > > As OpenLDAP 2.4, system administrators have to make sure that they > configure the correct order in which modules are loaded during sever > startup. (e.g. load "back_monitor" last, "auditlog" typically second from > last). Configuring this order incorrectly often prevents the server from > starting up, or modules from functioning as expected. I've never encountered a situation where the order in which moduleload executes matters. Can you please provide an example configuration exhibiting problematic behavior based on moduleload order? Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#8060) mdb_from_db (bdb import)
--On Tuesday, February 17, 2015 5:07 PM + gra...@gmail.com wrote: > Full_Name: Jonathan Graehl > Version: n/a > OS: n/a > URL: > ftp://ftp.openldap.org/incoming/0001-mdb_from_db-new-options-bugfix.patch > Submission from: (NULL) (104.174.227.200) > > > (see 0001-mdb_from_db-new-options-bugfix.patch) > > mdb_from_db utility for direct import from Berkeley DB to mdb > > Apparently this can only be distributed in binary form using older > berkeley db versions, but building the utility from source for bulk > import should be fine. Hello, This submission is missing a required IPR, as noted at <https://www.openldap.org/devel/contributing.html#notice> An IPR is necessary to consider this work. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#8986) [PATCH] Fix union semun undefined from FreeBSD 12 onward
--On Friday, May 17, 2019 5:30 PM + khng...@gmail.com wrote: > Bump. I've added this to the review list. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9024) [PATCH] Fix union semun undefined from FreeBSD 12 onward
--On Friday, May 17, 2019 5:02 PM + khng...@gmail.com wrote: > Full_Name: Ka Ho Ng > Version: mdb.master > OS: FreeBSD 12.0-RELEASE > URL: ftp://ftp.openldap.org/incoming/Ka-Ho-Ng-190517.patch > Submission from: (NULL) (2001:470:fa95:1300::3) > > By the way, please help close ITS#8986 as this version is a resend of the > patch. The correct path is to follow up to your original ITS, not submit a new one. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
RE: (ITS#9023) crash using ppolicy chaining from slave to master
--On Friday, May 17, 2019 4:09 PM + "AYANIDES, JEAN-PHILIPPE" wrote: > > > Hello Quanah, > > I am not very familiar with gdb. Can you help me doing that? Start slapd on the server that's crashing Get the process ID of slapd gdb /path/to/slapd PID For example, if slapd is located in /usr/sbin, and the process ID is 1234: gdb /usr/sbin/slapd 1234 At the (gdb) prompt, enter the command "cont" to continue execution Run your operation that causes slapd to crash. This should drop you back to the (gdb) prompt. Then run the command: thr apply all bt full This will provide the full backtrace. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9023) crash using ppolicy chaining from slave to master
--On Friday, May 17, 2019 3:50 PM + jpayani...@prosodie.com wrote: > Full_Name: JPh Ayanides > Version: 2.4.47 > OS: Linux Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.46.216.78) > > > Hello, I cannot succeed in making the following configuration to work. > Instead of that, openldap crashes. > > I have 2 openldap servers in master-slave: the slave is installed on a > machine named rada, and a master is installed on another machine named > simby. The ppolicy is activated on rada and simby, and I use chain and > updateref in order to sync failures in ppolicy coming from rada back to > simby. When I test that feature, with trying a bind with a wrong > password, openldap on the slave crashes. I failed in understanding why, > even with gdb. Ensure you have debugging symbols installed, and provide a full backtrace of all threads from gdb. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9008) module rpath incorrect
--On Wednesday, April 17, 2019 11:19 AM + on...@openldap.org wrote: > Full_Name: Ondrej Kuznik > Version: re24/master > OS: Linux > URL: https://github.com/mistotebe/openldap/tree/its9008 > Submission from: (NULL) (82.10.24.68) > > > Modules that link against libraries not already present in slapd will > only try to look in the rpaths encoded in the module, not in slapd. And > there is no point encoding $(moduledir) there, since we never install > anything of substance there. All the while the libraries we need probably > live in $(libdir). > > The linked patch fixes this and makes it possible for $(moduledir) (the > path modules will be installed into) to be set at configure time. This patch depends on a custom version of libtool that is not available to others and can cause significant build breakage when building under a packaging system. More work needed, either removing libtool from the build process for OpenLDAP, or modifications to this work to allow it to work properly with a non-custom version of libtool. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#8700) Compile error
--On Thursday, July 27, 2017 1:04 AM + papach...@gmail.com wrote: > I am getting the error below while compiling openldap 2.4.45 on the > latest macOS sierra (10.12.6). I am only setting two configuration options > > configure-options = > --disable-slapd > --disable-slurpd > > Undefined symbols for architecture x86_64: > "_ERR_remove_thread_state", referenced from: > _tlso_destroy in libldap.a(tls_o.o) Hello, What version of OpenSSL were you linking against? Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
(ITS#9022) Force slapadd to rewrite all entryCSN values
Full_Name: Quanah Gibson-Mount Version: OpenLDAP 2.4 OS: 2.4.47 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.128.44) Per the slapadd man page: -S SID Server ID to use in generated entryCSN. Also used for contextCSN if -w is set as well. Defaults to 0. However, if this is run against an export that already has entryCSN values in the entries, those values are not updated. This is problematic when wanting to update a database from single provider (SID0) to MMR (SID1+). I generally think that if the -S option is provided, and is non-zero, that all entryCSN values that currently have a "0" serverID in the entryCSN field should be updated to the specified -S value. In the above case, it would be critical to additionally flag -w on the end user part. This helps to clean up data when doing migrations.
Re: (ITS#9021) TLS: can't connect: TLS: hostname does not match CN in peer certificate
--On Friday, May 10, 2019 9:32 PM + darshan mistry wrote: > how we can ignore to look server name in subject of certificate so I can > use LDAP server ip address instead of host name? If you want to allow connecting over the IP address with TLS, then add it as a subjectAltName value in the certificate, for example: subjectAltName=IP:1.2.3.4 > Also want to know if there is any open CVE which says it is > vulnerabilities to use LDAP server ip address instead of name in ldap > configuration. I'm not aware of any such CVE or why there would be one. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#9021) TLS: can't connect: TLS: hostname does not match CN in peer certificate
--On Friday, May 10, 2019 8:52 PM + darshankmis...@yahoo.com wrote: > Full_Name: Darshankumar Mistry > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:420:10b:1272:fc1b:1ea:d311:6cac) > > > I would like to know why Open LDAP behavior was changed where we must > have to configure FQDN name mentioned in certificate in order to work LDAP > authentication... else TLS start failing. OpenLDAP has worked this way since I first started using it in 2002. This behavior is nothing new. And this is the correct behavior. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: (ITS#8708) SASL EXTERNAL binds and sasl-secprops minssf
--On Wednesday, May 08, 2019 12:56 PM -0400 David Hawes wrote: >> Hi David, >> >> I believe this was fixed with ITS#8796 (part of the 2.4.46 release). Can >> you confirm? > > Confirmed. ITS#8796 fixes #8708. Hi David, Thanks for the quick confirmation! I've closed ITS#8708 and noted that the fix for ITS#8796 resolved it. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
