https://bugs.openldap.org/show_bug.cgi?id=10078
Issue ID: 10078
Summary: segfault error 4 in in dynlist-2.5.so.0.1.8
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: gustav(a)spllg.de
Target Milestone: ---
whenever i execute an ldapsearch, slapd crashes and i find the following lines
in /var/log/syslog
segfault at 0 ip 00007f876bece9c1 sp 00007f876a1fc0c0 error 4 in
dynlist-2.5.so.0.1.8[7f876becb000+6000] likely on CPU 0 (core 0, socket 0)
Code: 48 29 d0 48 89 d7 48 89 c1 31 c0 83 c1 6c c1 e9 03 f3 48 ab 48 8b 84 24
10 02 00 00 4c 89 ef c7 84 24 a0 00 00 00 03 00 00 00 <48> 8b 00 ff 50 78 44 39
73 64 74 09 45 84 e4 0f 85 22 03 00 00 48
Stopping OpenLDAP: slapd.
slapd.service: Deactivated successfully.
the database had been imported from ldap-2.4.57 where ldap runs fine.
is there anything i can do to fix the problem?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10075
Issue ID: 10075
Summary: back-sql regression between 2.4.40 and 2.4.44
Product: OpenLDAP
Version: 2.4.44
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: daniel.walker(a)ncas.ac.uk
Target Milestone: ---
I have just upgraded from CentOS6 to CentOS7 ( I know, not my pick :). On
OpenLdap back-sql 2.4.40 on CentOS6, this seems to be honoured:
"Multiple attributeType definitions are allowed for an entry; that is, multiple
ldap_attr_mappings rows can refer to the same ldap_oc_mappings row with the
same name; the resulting attribute values are honored for multivalued
attributes in search filters, in search results, in compare AVAs. However, only
rules according to the first instance of that attributeType are followed in
add, modify and delete operations. This limitation, under certain
circumstances, may be removed in the future." (from
https://www.openldap.org/faq/data/cache/978.html )
I was using this feature to get memberAddress attributes from two separate
tables in my SQL (internal people and external people)
Upon upgrading to 2.4.44 on CentOS7, the second entry is no longer honoured.
Relevant entries:
MariaDB [ncas_database]> SELECT
name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u
FROM ldap_attr_mappings WHERE oc_map_id=4 AND name='memberAddress';
+---------------+--------------------------------------+------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+-------------+-------------+---------------+------------+
| name | sel_expr | from_tbls
| join_where
| add_proc | delete_proc | param_order | expect_return |
sel_expr_u |
+---------------+--------------------------------------+------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+-------------+-------------+---------------+------------+
| memberAddress | CONCAT(emails.address,"@domain.name") | groups,people_groups
AS ps,people,emails | groups.id=ps.group_id AND ps.person_id=people.id AND
people.id=emails.person_id AND emails.main=1 AND (people.contract_end > NOW()
OR people.contract_end IS NULL) | NULL | NULL | 3 |
0 | NULL |
| memberAddress | email |
groups,external_members | groups.id=external_members.group_id
| NULL | NULL |
3 | 0 | NULL |
+---------------+--------------------------------------+------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+-------------+-------------+---------------+------------+
2 rows in set (0.000 sec)
The second one is ignored; no requests to the external_members table show in
the logs.
Is this a known bug? I did look through the archives, but I wasn't able to find
it.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10069
Issue ID: 10069
Summary: Error when installing openldap from brew on Macos
Catalina
Product: OpenLDAP
Version: 2.6.4
Hardware: x86_64
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: marianogedisman(a)gmail.com
Target Milestone: ---
Hello!
I'm getting this error when installing from Homebrew on MacOS Catalina:
==> ./configure --prefix=/usr/local/Cellar/openldap/2.6.4
--sysconfdir=/usr/loca
n==> make install
Error: inreplace failed
/usr/local/etc/openldap/slapd.conf:
expected replacement of #<Pathname:/usr/local/Cellar/openldap/2.6.4> with
#<Pathname:/usr/local/opt/openldap>
/usr/local/etc/openldap/slapd.ldif:
expected replacement of #<Pathname:/usr/local/Cellar/openldap/2.6.4> with
#<Pathname:/usr/local/opt/openldap>
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=4066
--- Comment #5 from knotmecute <kmcbacklink(a)gmail.com> ---
Step into the vibrant world of Knotmecute's Banjaran collection, where
exquisite bohemian jewelry takes center stage, inspired by tribal aesthetics
and vibrant cultures. Our brand strives to revive the rich heritage art of
tribes, incorporating abstract patterns and colorful mirror work into stunning
pieces that make a bold and stylish statement.
Crafted with meticulous precision and attention to detail, our luxury bohemian
jewels are designed to complement a variety of occasions, from carefree beach
travels to destination weddings. Each piece is thoughtfully created to evoke a
sense of wanderlust and adventure, adding a touch of boho charm to your jewelry
ensemble.
The Banjara collection offers a wide range of accessories that cater to every
woman's unique style and trending preferences. Whether you desire a statement
necklace to elevate your evening attire or vibrant earrings to accentuate your
beachy look, we have the perfect piece to fulfill your needs.
Every jewelry piece in the Banjara collection is a work of art, meticulously
handcrafted with vibrant colors, intricate mirror work, and captivating
patterns. These colorful jewels go beyond being mere accessories—they carry a
personalized touch, reflecting the essence of your vibrant spirit.
Embrace the beauty of bohemian aesthetics with Knotmecute's Banjara brand.
Discover our collection and adorn yourself with these stunning jewels that will
turn heads wherever you go. Experience the joy of wearing luxurious, colorful
bohemian jewelry that reflects your individuality and leaves a lasting
impression.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10066
Issue ID: 10066
Summary: fsync -> fcntl(F_FULLFSYNC) on Apple platforms?
Product: LMDB
Version: unspecified
Hardware: All
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: christophersauer(a)pacbell.net
Target Milestone: ---
Hi, Howard,
I was thinking of adopting LMDB for a cross-platform project, but when quickly
browsing the code, didn't see specializations for Apple platform' weakened
fsync -> fcntl(F_FULLFSYNC). (Doc quick link, if useful:
https://developer.apple.com/library/archive/documentation/System/Conceptual…)
Should I be concerned? I think it's very likely that you're way ahead of me,
but I just wanted to check in. (And couldn't otherwise find anything online
about this.)
Thanks so much for all you do!
Chris
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10054
Issue ID: 10054
Summary: Value size limited to 2,147,479,552 bytes
Product: LMDB
Version: unspecified
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: louis(a)meilisearch.com
Target Milestone: ---
Hello,
According to the documentation[0], a database that is not using `MDB_DUPSORT`
can store values up to `0xffffffff` bytes (around 4GB).
In practice, under Linux, the actual limit is `0x7ffff000` though (2^31 - 4096,
so around 2GB).
This is due to the write loop in `mdb_page_flush`. The `wsize` value
determining how many bytes will be written can be as big as
`4096*dp->mp_pages`[1], and the number of overflow pages grows with the size of
the value put inside the DB.
The `wsize` is not split in smaller chunks in the case where there are many
overflow pages to write, and as a result the call to `pwrite`[2] does not
perform a full write, but only a "short" write of 2147479552 bytes (the maximum
allowed on a call to `pwrite` on Linux[3]).
This would be OK if the short write condition was handled by looping and
performing another `pwrite` with the rest of the data, but instead `EIO` is
returned[4].
There seems to be a related, but different issue on macOS when trying to
`pwrite` more the 2^31 bytes, that was already reported[5].
This issue was reported to me by a Meilisearch user because it causes their
database indexing to fail[6]. I had to investigate a bit because their setup
was peculiar (high number of documents in their database) and the `EIO` error
code is not very descriptive of the underlying issue.
I join a C reproducer of the issue that attempts to add a 2147479553 bytes
value to the DB and fails with `EIO` (decreasing `nb_items` to a smaller value
such as `2107479552` does succeed)[7].
Thank you for making LMDB!
Louis Dureuil.
[0]:
https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/lmdb.h#LL284…
[1]:
https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#LL3770…
[2]: https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#L3820
[3]:
https://stackoverflow.com/questions/70368651/why-cant-linux-write-more-than…
[4]: https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#L3840
[5]: https://bugs.openldap.org/show_bug.cgi?id=9736
[6]: https://github.com/meilisearch/meilisearch/issues/3654
[7]: https://github.com/dureuill/lmdb_3654/tree/main
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10062
Issue ID: 10062
Summary: How to store a data item of length greater than 511 in
a dupsort db
Product: LMDB
Version: 0.9.30
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: mega.alpha100(a)gmail.com
Target Milestone: ---
Is there a workaround to storing a data item with a length greater than the
value of `fn mdb_env_get_maxkeysize()` or 511 in a dupsort db?
Also, I tried to change the value of the `MDB_MAXKEYSIZE` macro but that led to
an illegal instruction
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10061
Issue ID: 10061
Summary: Query on setting TLSVerifyClient option set to demand
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ramajay52(a)gmail.com
Target Milestone: ---
Dear Experts,
In my case, I had set TLSVerifyClient to demand.
I couldn't be able to establish a connection While providing
TLSCACertificateFile alone.
While setting the TLSVerifyClient option demand is it mandatory to provide the
following option?
1. TLSCACertificateFile
2. TLSCertificateKeyFile
3. TLSCertificateFile
Regards,
Ram
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8447
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|TEST |FIXED
--- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Fixed in RE0.9:
• 76bad923
by Howard Chu at 2023-05-25T19:33:44+00:00
ITS#8447 fix cursor_put(MDB_CURRENT) on DUPSORT DB with different-sized data
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9736
Issue ID: 9736
Summary: pwrite bug in OSX breaking LMDB promise about the
maximum value size
Product: LMDB
Version: unspecified
Hardware: All
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: renault.cle(a)gmail.com
Target Milestone: ---
Hi,
I was working with LMDB and found an issue when trying to write a value of
approximately 3.3GiB in the database, I dive into the LMDB source code of the
mdb_put method using the lldb debugger and found out that it was not related to
an issue in LMDB itself but rather a bug in the pwrite function of the Mac OS
libc implementation.
The pwrite function is given four parameters, the file descriptor, the buffer,
the count of bytes to write from the buffer and, the offset of where to write
it in the file. On Mac OS the count of bytes is a size_t that must be a 64bits
unsigned integer but when you call pwrite with a number bigger or equal to 2^31
it returns an error 22 (invalid argument). LMDB was returning a 22 error from
the mdb_put call and not an EINVAL because the error was cause by an internal
issue and not something catchable by LMDB.
I am not sure about what we can do, can we implement this single pwrite [1] as
multiple pwrite with counts smaller than 2^31 in a loop, just for Mac OS? Like
for Windows where we do specific things for this operating system too?
I also found this issue on the RocksDB repository [2] about a similar problem
they have with pwrite and write on Mac OS it seems. I understand that this is
not a real promise that LMDB is specifying but rather an "in theory" rule [3].
Thank you for your time,
kero
[1]:
https://github.com/LMDB/lmdb/blob/01b1b7dc204abdf3849536979205dc9e3a0e3ece/…
[2]: https://github.com/facebook/rocksdb/issues/5169
[3]: http://www.lmdb.tech/doc/group__mdb.html#structMDB__val
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10055
Issue ID: 10055
Summary: EOS EOL
Product: OpenLDAP
Version: 2.4.44
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: andrew.hudson(a)rtx.com
Target Milestone: ---
Hello,
I work with Raytheon Intelligence and Space. I just have a quick question. I am
in charge of keeping track of the software that is on my program's environment.
We are on version 2.4.44. I am just wondering what the End of Support and the
end of life of this version. Thank you very much.
Andrew Hudson
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=4501
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=4501
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
--- Comment #11 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Commits:
• f200ebd2
by Fredrik Roubert at 2023-02-18T18:27:29+01:00
ITS#4501 Set javac source="8".
• 578fba58
by Fredrik Roubert at 2023-02-18T18:27:29+01:00
ITS#4501 Delete unused class Compare.
JDK 1.5 removed the String.compareTo(Object) method so this class won't
compile anymore, but luckily it's unused and can simply be deleted.
• fa6c4c44
by Fredrik Roubert at 2023-02-18T18:27:29+01:00
ITS#4501 Replace use of 'enum' as an identifier.
Java 1.5 made 'enum' a keyword, which may not be used as an identifier.
• 339120d5
by Fredrik Roubert at 2023-02-18T18:27:29+01:00
ITS#4501 Replace use of deprecated class StringBufferInputStream.
JDK 1.1 deprecated class StringBufferInputStream because it does not
properly convert characters into bytes.
• f494f56d
by Fredrik Roubert at 2023-02-18T18:27:29+01:00
ITS#4501 Replace call to deprecated LDAPConnection.bind() method.
JLDAP Sep_ndk_2003 deprecated LDAPConnection.bind(int, String, String)
in favour of LDAPConnection.bind(int, String, byte[]).
• 70b87f22
by Fredrik Roubert at 2023-02-18T18:27:29+01:00
ITS#4501 Replace call to deprecated File.toURL() method.
JDK 6 deprecated File.toURL() in favour of File.toURI().toURL() because
it does not automatically escape characters that are illegal in URLs.
• 44c3341b
by Fredrik Roubert at 2023-02-18T18:27:29+01:00
ITS#4501 Add @Deprecated annotations to deprecated interface methods.
JDK 1.5 deprecated these interface methods so they should be annotated
as deprecated also in this implementation of that interface.
• 25e88de0
by Fredrik Roubert at 2023-02-18T18:27:29+01:00
ITS#4501 Use full package name to disambiguate ambiguous reference.
JDK 8 introduced java.util.Base64 which has the same class name as
com.novell.ldap.util.Base64 which this code calls.
• 762419dc
by Fredrik Roubert at 2023-02-18T18:27:29+01:00
ITS#4501 Add java.sql interface methods introduced by JDK 6.
• 8432fbfe
by Fredrik Roubert at 2023-02-18T18:27:29+01:00
ITS#4501 Add java.sql interface methods introduced by JDK 7.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10053
Issue ID: 10053
Summary: liblber/idtest.c (and psap.h dependency) irrelevant to
OpenLDAP
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
configure.ac checks for psap.h presence, the only user being liblber's idtest.c
- a test program that uses none of liblber API and claims to be part of ISODE
X.500 code.
I'm tempted to remove the configure check and the source file, letting that
project adopt it if they still use it for something.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=4501
--- Comment #10 from Shawn McKinney <smckinney(a)symas.com> ---
(In reply to Fredrik Roubert from comment #9)
> I never managed to find any documentation about what JAR files were needed,
> so instead I used guesswork and Google to come up with this list on my own
> for building with JDK 1.4.2:
>
> ant-1.7.0.jar
> ant-junit-1.6.5.jar
> ant-launcher-1.6.5.jar
> jface-3.0.1.jar
> junit-3.8.1.jar
> novell-jldap-2013.08.30.1433-xplat.jar
> swt-linux-gtk-3.0.1.jar
>
> I have no idea how correct that list might be, but at least it turned out to
> be sufficent to make the build work.
>
> For building with JDK 8, the list becomes substantially smaller:
>
> jface-3.0.1.jar
> novell-jldap-2013.08.30.1433-xplat.jar
> swt-linux-gtk-3.0.1.jar
Thanks, before I saw your reply, got it built with these (similar list):
jldap-2009-10-07.jar
junit-4.13.2.jar
org.eclipse.jface-3.29.0.jar
org.eclipse.swt.gtk.linux.x86_64-3.122.0.jar
>
> But I can't help wondering about JdbcLdapBrowserApp, whether that really is
> something that is ever used by anyone anymore, for if it is not, you would
> be able to simplify your codebase considerably by deleting all that source
> code (and with that, the need for org.eclipse.swt and jfaces).
Fortunately, these jars, other than jdbcldap, are recent, meaning they at least
have no known CVE's outstanding? But, like you I'm left with the same thoughts.
Who's using this, what parts can be sundowned, how do we test it, what to do
next.
--
Shawn
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=4501
--- Comment #9 from Fredrik Roubert <fredrik(a)roubert.name> ---
I never managed to find any documentation about what JAR files were needed, so
instead I used guesswork and Google to come up with this list on my own for
building with JDK 1.4.2:
ant-1.7.0.jar
ant-junit-1.6.5.jar
ant-launcher-1.6.5.jar
jface-3.0.1.jar
junit-3.8.1.jar
novell-jldap-2013.08.30.1433-xplat.jar
swt-linux-gtk-3.0.1.jar
I have no idea how correct that list might be, but at least it turned out to be
sufficent to make the build work.
For building with JDK 8, the list becomes substantially smaller:
jface-3.0.1.jar
novell-jldap-2013.08.30.1433-xplat.jar
swt-linux-gtk-3.0.1.jar
But I can't help wondering about JdbcLdapBrowserApp, whether that really is
something that is ever used by anyone anymore, for if it is not, you would be
able to simplify your codebase considerably by deleting all that source code
(and with that, the need for org.eclipse.swt and jfaces).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10052
Issue ID: 10052
Summary: ldapsearch error "can't contact LDAP Server" <1%
Product: OpenLDAP
Version: 2.4.44
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: w3eagle(a)yahoo.com
Target Milestone: ---
version used: 2.4.44 that is from Amazon2 core
OS: AWS Linux2
Details:
Users reported occasional issues with AD server authentication with
MicroStrategy. Open case with MicroStrategy and learnt then use openldap
library for the AD authentication. We were able to reproduce the issue with
ldapsearch like below.
ldapsearch -H ldaps://$REMOTEHOST:$REMOTEPORT \
-x -D "CN=??????" \
-y pssd.txt -LLL \
-b "OU=???????" "(sAMAccountName=????)" dn
We use crontab to query AD once every minute, and we were able to see a few
issues each day, error rate is more than 1/1000 but less than 1/100. The error
looks like below -
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
Not much info was logged other than this.
We tried all kinds of stuff but it didn't help, eg. the ldap.conf settings to
ignore certs validation, simplify the cert folder files etc. and the like.
We think perhaps the TLS might be the issue, so we setup an nginx node within
the same vpc, which communicates with AD server over TLS, but terminates TLS
and talk to other ec2 with clear text. We were not able to see any errors.
So we have proved, for some reason, then ldapsearch over ldaps fails with a low
percentage.
I previously reported case 10049, but it was closed. The message is like
openldap is using other components for https/tls; so possibly bugs from other
libraires.
So to prove this issue is indeep on openldap, I schedule the same ldapsearch on
the nginx box itself. Knowing nginx was using the same openssl library (openssl
1.0.2k), we reproduced the same, ~1% "can't contact LDAP server" error, on the
nginx box. So this error is perhaps more related to openldap, or perhaps Cyrus
SASL? (cyrus-sasl-lib 2.1.26).
My question is whether this sounds like an openldap bug. Please advise. Thanks
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10051
Issue ID: 10051
Summary: ldapsearch error can't contact LDAP <1%
Product: OpenLDAP
Version: 2.4.44
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: w3eagle(a)yahoo.com
Target Milestone: ---
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10049
Issue ID: 10049
Summary: ldapsearch can't contact LDAP
Product: OpenLDAP
Version: 2.4.44
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: w3eagle(a)yahoo.com
Target Milestone: ---
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=4501
--- Comment #8 from Shawn McKinney <smckinney(a)symas.com> ---
I've setup a build env, using Java 8, apache ant 1.10, etc. Now, getting errors
on missing dependencies, org.eclipse.swt.*, jfaces, ...
I have not found instructions on openldap.org website how to build this. That's
fine, certainly not something for this MR to address. But, before I go spend
time chasing this down, are there steps written down? Doesn't have to be
accurate, anything at all would help.
Thanks
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10021
Issue ID: 10021
Summary: Cannot insert data into wiredtiger backend
Product: OpenLDAP
Version: 2.6.4
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: jailbird(a)fdf.net
Target Milestone: ---
I have a test system running OpenLDAP 2.6.4 linked against WiredTiger 11.1.0
running on a RHEL9.1-based system. Running kernel is 6.1.16, filesystem is XFS.
back_wt.la was added to cn=module and a simple olcDatabase=wt was created like:
dn: olcDatabase=wt
objectClass: olcDatabaseConfig
objectClass: olcWtConfig
olcDatabase: wt
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=fdf,dc=net
olcLimits: {0}dn.base="cn=root,dc=fdf,dc=net" time.soft=unlimited time.hard=u
nlimited size.soft=unlimited size.hard=unlimited
olcRootDN: cn=root,dc=fdf,dc=net
olcWtConfig: create
olcDbIndex: objectClass,uid,gidNumber,uidNumber pres,eq
olcDbIndex: ou,cn,mail pres,eq,sub
structuralObjectClass: olcWtConfig
I start slapd and it creates the database files correctly. I then go and try to
create the container with a simple .ldif and ldapadd:
dn: dc=fdf,dc=net
objectClass: dcObject
objectClass: organization
o: FDF
dc: fdf
That generates:
[1677801597:758327][83158:0x55b4158fb640], file:dn2id.wt, WT_CURSOR.insert:
[WT_VERB_DEFAULT][ERROR]: __wt_txn_id_check, 1339: write operations are not
supported in read-committed or read-uncommitted transactions.: Operation not
supported
Mar 2 15:59:57 slapd[83158]: wt_dn2id_add: insert failed: Operation not
supported (95)
That comes from WiredTiger @
https://github.com/wiredtiger/wiredtiger/blob/5a032be765b1ebd9bb789e837cd00…
but I don't seem to understand why it's happening on a simple add? Am I missing
something obvious?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9436
Issue ID: 9436
Summary: OpenSSL 3.0: libldap uses depreciated functions
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
OpenLDAP master fails to build against OpenSSL 3.0 alpha when "no-deprecated"
is specified.
Currently hitting these errors:
./.libs/libldap.so: undefined reference to `SSL_get_peer_certificate'
./.libs/libldap.so: undefined reference to `PEM_read_bio_DHparams'
./.libs/libldap.so: undefined reference to `ERR_get_error_line'
./.libs/libldap.so: undefined reference to `DH_free'
./.libs/libldap.so: undefined reference to `SSL_CTX_set_tmp_dh'
Notes:
SSL_get_peer_certificate is SSL_get1_peer_certificate in 3.0.0
SSL_CTX_set_tmp_dh should be replaced as follows:
# define SSL_CTX_set_tmp_dh(ctx,dh) \
SSL_CTX_ctrl(ctx,SSL_CTRL_SET_TMP_DH,0,(char *)(dh))
Have to dig deeper for:
PEM_read_bio_DHparams
ERR_get_error_line
DH_free
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10036
Issue ID: 10036
Summary: ldapsearch to support IPv6 addresses in session
tracking control
Product: OpenLDAP
Version: 2.6.4
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: vantaa(a)outlook.com
Target Milestone: ---
When ldapsearch is told to include the session tracking control (-e
sessiontracking), it gets the local IP address via gethostbyname() which is
IPv4 only. Probably it should use getaddrinfo() which is IPv6 capable.
The source code is in clients/tools/common.c:st_value().
--
You are receiving this mail because:
You are on the CC list for the issue.