https://bugs.openldap.org/show_bug.cgi?id=10243
Issue ID: 10243
Summary: Looking to get account on OpenLDAP Gitlab
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: ak.openldap(a)anroet.com
Target Milestone: ---
I'm trying to open an account on Gitlab.
The purpose for having an account on gitlab is so that I can start the process
of building a docker image for use in our Production K8s environment.
Currently, I can only find docker images for version 2.4 and the admission
controllers in out production k8s clusters isn't having none of that.
I'm attempting to create an account using the following email address:
ak.openldap(a)anroet.com
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10246
Issue ID: 10246
Summary: Impossible to add integerOrderingMatch ordering rule
for integer syntax attribute
Product: OpenLDAP
Version: 2.5.18
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: thierryblaise(a)hotmail.com
Target Milestone: ---
Hi everyone,
As I don't know anymore where to search, I'm trying here:
I added a custom objectClass to my v2.5.18 openLDAP deployment schema, and in
that schema, there's an attribute of type integer that I need to be able to
search for with filter "<=" and ">=".
To that end, and to my knowledge and following documentation
(https://www.openldap.org/doc/admin25/schema.html#Attribute%20Type%20Specifi…),
I need to declare an ordering matching rule in attribute definition of the
schema.
However, when I do that with the following olcAttributeTypes definition :
olcAttributeTypes: ( 1.3.6.1.4.1.xxx.x.x.xxx
NAME 'last-modified'
DESC 'Object Last Modified Time'
ORDERING integerOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE )
and try to import the ldif containing this definition, the following error
appears:
modifying entry "cn={5}clients,cn=schema,cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)
additional info: olcAttributeTypes: AttributeType inappropriate
matching rule: "integerOrderingMatch"
I tried with all documented OrderingMatch rules in case, but same error modulo
name of OrderingMatch rule.
Basic schemas only have been imported (core, nis, cosine, inetOrgPerson)
Any idea what I do wrong?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10245
Issue ID: 10245
Summary: mdb_env_set_maxdbs signature appears incorrect
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: bchik(a)meta.com
Target Milestone: ---
The current signature for mdb_env_set_maxdbs:
int mdb_env_set_maxdbs(MDB_env *env, MDB_dbi dbs);
The documentation says the second parameter is intended to be the maximum
number of databases, however, the parameter is typed as a DB handle. This
appears to work because MDB_dbi is typedef'd to an unsigned int.
I believe the intended signature would be:
int mdb_env_set_maxdbs(MDB_env *env, unsigned int dbs);
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10241
Issue ID: 10241
Summary: Crash in mdb_page_search_root()
Product: LMDB
Version: 0.9.24
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: david.komarek(a)whalebone.io
Target Milestone: ---
Hello,
The LMDB is crashing in mdb_page_search_root() on following instruction
`0x7f85221479d2 movzwl 0xa(%rdx),%eax`. This instruction corresponds to
following line in source code -
https://github.com/LMDB/lmdb/blob/LMDB_0.9.24/libraries/liblmdb/mdb.c#L5485
(while access mp_flags in MDB_page structure)
Here is callstack as generated by core dump (without symbols as we're using
package from Ubuntu repositories)
```
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f85221479d2 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0
No symbol table info available.
#1 0x00007f8522147d15 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0
No symbol table info available.
#2 0x00007f8522148432 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0
No symbol table info available.
#3 0x00007f8522148a70 in mdb_get () from
/usr/lib/x86_64-linux-gnu/liblmdb.so.0
No symbol table info available.
```
Translation
```
#0 mdb_page_search_root()
#1 mdb_page_search()
#2 mdb_cursor_set()
#3 mdb_get()
```
Registers in time of crash:
```
rax 0x2 2
rbx 0x7ffcd8d2a100 140723946168576
rcx 0x3 3
rdx 0x7f825baf7000 140197860700160
rsi 0x1000 4096
rdi 0x7f851c00f4d0 140209677202640
rbp 0x0 0x0
rsp 0x7ffcd8d29e40 0x7ffcd8d29e40
r8 0x7ffcd8d29e50 140723946167888
r9 0x7f851c00f5b8 140209677202872
r10 0x7f851c003090 140209677152400
r11 0x2ce33e6c02ce33e7 3234497591006606311
r12 0x0 0
r13 0x7ffcd8d2a510 140723946169616
r14 0x79 121
r15 0x7f851c003098 140209677152408
rip 0x7f85221479d2 0x7f85221479d2
eflags 0x10246 [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
k0 0x40 64
k1 0xfffff0f0 4294963440
k2 0xff01 65281
k3 0xffffffff 4294967295
k4 0xffffffff 4294967295
k5 0xffffffff 4294967295
k6 0xffffffff 4294967295
k7 0x0 0
```
Our setup is following:
We have single process (running in separate container) which reads and writes
to LMDB. It opens environment with following flags
MDB_NORDAHEAD|MDB_WRITEMAP|MDB_NOTLS|MDB_NOSYNC. The environment contain
several DBs. All DBIs are open with MDB_CREATE flag. Transactions are open
without flags.
On the other hand we have several processes running in the single container,
which are only allowed read (these processes crash). The environment is open
with following flags MDB_NORDAHEAD|MDB_WRITEMAP|MDB_NOTLS|MDB_RDONLY. All DBIs
are open without flags. Transactions are open with MDB_RDONLY flag.
Could you please investigate it? If you will need some other artifacts or
comments, please let me know.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10240
Issue ID: 10240
Summary: Information required about the end of support date for
OpenLDAP ver 2.6.3
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: bluesoulprince(a)gmail.com
Target Milestone: ---
Hi Team,
As we have integrated OpenLDAP 2.6.3 version in our application, we would like
to know the community support availability end of date for this version, to
plan our application maintenance accordingly.
Could you please help us with this information.
Thanks,
Vivek S
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10236
Issue ID: 10236
Summary: fragmentation makes mdb_page_alloc slow
Product: LMDB
Version: 0.9.31
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: aalekseyev(a)janestreet.com
Target Milestone: ---
Created attachment 1022
--> https://bugs.openldap.org/attachment.cgi?id=1022&action=edit
patch is relative to LMDB_0.9.31
It's a known problem that mdb_page_alloc can be slow
when the free list is large and fragmented. [1] [2] [3]
I'm not sure it's known *how* slow it can be.
In our workload we saw a fragmented freelist leading
to a pathological O(n^2) behavior.
To handle a multi-page allocation we iterate loading chunks of the
free list one by one, and at every iteration we do O(n) work to check
if the allocation can succeed.
Even small-ish allocations (tens of pages) are repeatedly hitting
this edge case, with free list growing to ~1000000, and the outer loop
taking ~2000 iterations (10^9 worth of work in total, just to allocate a
few pages).
Even though I'm sure there are ways to avoid hitting this pathological
scenario so much (avoid values larger than 4k, or fix whatever causes
fragmentation), it seems unacceptable to have a performance cliff this bad.
I made a patch to make the allocation take ~O(n*log(n)), by loading
and merging multiple chunks at once instead of doing it one-by-one.
I'd appreciate it if someone could review the patch (attached), improve it,
and/or come up with an alternative fix.
The code in `midl.c` is kinda meme-y, including a contribution from GPT-4o, but
it performs well enough to speed up our pathological workload by ~20x (which is
still ~3x away from the non-fragmented case).
Anyway, the main thing that warrants scrutiny is the change in `mdb.c`:
I understand very little about lmdb internals and I worry that loading
multiple pages at once instead of one-by-one might break something.
[1] issue #8664
[2]
https://lists.openldap.org/hyperkitty/list/openldap-bugs@openldap.org/threa…
[3]
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10239
Issue ID: 10239
Summary: The slapd domain name is inconsistent, synchronization
cannot be modified by the rewrite dn parameter dc.
Product: OpenLDAP
Version: 2.4.44
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: 2458943823(a)qq.com
Target Milestone: ---
/etc/openldap/slapd:
syncrepl rid=002
provider=ldap://172.18.1.1
bindmethod=simple
binddn="cn=Manager,dc=wsc,dc=ls,dc=com"
credentials=lnewnews1tter
searchbase="dc=wsc,dc=ls,dc=com"
schemachecking=off
type=refreshAndPersist
retry="60 +"
rewrite dn "dc=wsc,dc=ls,dc=com" "dc=wsc,dc=slave1,dc=ls,dc=com"
The error is as follows:
66912211 /etc/openldap/slapd.conf: line 281: Error: parse_syncrepl_line: unable
to parse "rewrite"
.
66912211 failed to add syncinfo
slaptest: bad configuration directory!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10235
Issue ID: 10235
Summary: Configure without --enable-nestgroup=no enables
feature
Product: OpenLDAP
Version: 2.6.8
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: stacey.marshall(a)gmail.com
Target Milestone: ---
OpenLDAP 2.6.8 configured with --enable-overlays.
Some openldap commands output a Duplicate attributeType notice, for example
# /sbin/slapcat -b cn=config -H ldap:///???olcTLSCertificateKeyFile=\* | grep
olcTLSCertificateKeyFile
register_at: AttributeType "( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC
'Group that the entry belongs to' SYNTAX '1.3.6.1.4.1.1466.115.121.1.12'
EQUALITY distinguishedNameMatch USAGE dSAOperation NO-USER-MODIFICATION
X-ORIGIN 'iPlanet Delegated Administrator' )": Duplicate attributeType,
1.2.840.113556.1.2.102
olcTLSCertificateKeyFile: /etc/certs/localhost/host.key
Specifying configure option --enable-nestgroup=no prevents nestgroup feature
and the message from being displayed.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10231
Issue ID: 10231
Summary: slapadd segfault on non-configured backend
Product: OpenLDAP
Version: 2.6.8
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
If the LDIF being loaded corresponds to a different backend than the one
specified (or the default backend, if none was specified), and the specified
backend's configuration is incomplete and lacks a suffix, slapadd will SEGV
when trying to print the error message about the LDIF not matching the
specified
backend, because it tries to print the suffix but the suffix is NULL.
E.g. using this setup:
###
mkdir dumb dumb/db
cat > dumb/slapd.conf <<EOF
include schema/core.schema
backend ldif
database ldif
directory dumb/db
EOF
slapd -Ta -f dumb/slapd.conf -l schema/inetorgperson.ldif
###
When fixed, the normal error message will be shown instead:
slapadd: line 1: database #1 ((null)) not configured to hold
"cn=inetorgperson,cn=schema,cn=config"; did you mean to use database #0
(cn=config)?
Closing DB...
--
You are receiving this mail because:
You are on the CC list for the issue.