https://bugs.openldap.org/show_bug.cgi?id=8447
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |0.9.31
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9496
Issue ID: 9496
Summary: Some writes missing from database
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: igfoo(a)github.com
Target Milestone: ---
With the attached test program, some of my database writes appear not to
actually be written to the database. For example, a run may look like this:
$ ./run.sh
All done.
All finished
1802 test.txt
foo_200 is missing
bar_200 is missing
foo_404 is missing
bar_404 is missing
foo_407 is missing
bar_407 is missing
The script that I am using to run the program is below. This is using
mdb.master 52bc29ee2efccf09c650598635cd42a50b6ecffe on Linux, with an ext4
filesystem.
Is this an LMDB bug, or is there a bug in my code?
Thanks
Ian
#!/bin/sh
set -e
if ! [ -d lmdb ]
then
rm -rf lmdb
git clone https://github.com/LMDB/lmdb.git
INSTALL_DIR="`pwd`/inst"
cd lmdb/libraries/liblmdb
make install prefix="$INSTALL_DIR"
cd ../../..
fi
gcc -Wall -Werror -Iinst/include loop.c inst/lib/liblmdb.a -o loop -pthread
rm -f test.db test.db-lock
./loop
echo "All finished"
mdb_dump -np test.db > test.txt
wc -l test.txt
for i in `seq 100 999`
do
if ! grep -q "foo_$i" test.txt
then
echo "foo_$i is missing"
fi
if ! grep -q "bar_$i" test.txt
then
echo "bar_$i is missing"
fi
done
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10017
Issue ID: 10017
Summary: ldap.conf setting "BINDDN" has no associated
LDAP_OPT_XXX constant for ldap_get_opt ldap_set_opt
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: sean(a)teletech.com.au
Target Milestone: ---
The Configuration file setting "BINDDN" has no associated LDAP_OPT_XXX constant
and is not exposed to the ldap_get_opt / ldap_set_opt API. This is the only
option that is not so accessible and this seems like an oversight.
Option "PORT" is also not exposed but that is deprecated. You could make the
case it shouldn't be.
This setting could obviously be of interest to the Application and I see no
reason for it to be hidden.
Simple applications / tools may not have their own configuration files and
instead rely solely of the ldap.conf file to configure openldap. Such an
application could not easy supply a DN to the "bind" calls but may still wish
to know the value specified in the configuration file.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10019
Issue ID: 10019
Summary: dynlist's +memberOf attribute not searchable/fetchable
with anonymous binds
Product: OpenLDAP
Version: 2.5.13
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: msl(a)touk.pl
Target Milestone: ---
Hi,
This is and issue we discovered (as a side effect of testing) after switching
from memberof overlay to dynlist with our confluence directory setup - which
previously worked fine, but not anymore.
Side effect of testing - as judging from the logs it seems that confluence is
doing normal binds (which is even stranger as non-anonymous bind ldapsearch
from commandline works correctly).
Anyway, consider the following setup:
groupOfURLs labeledURI uniqueMember+memberOf@groupOfUniqueNames
We only use static groups, so the following group with one of members:
DN: cn=TouK,ou=TouK,ou=Group,dc=touk,dc=pl
objectClass: groupOfUniqueNames
...
uniqueMember: cn=Michał Sołtys,ou=Touki,ou=People,dc=touk,dc=pl
Correlates to:
DN: cn=Michał Sołtys,ou=Touki,ou=People,dc=touk,dc=pl
...
memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
The initial ACLs are set as follows:
{0}to * by dn=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by
* break
{1}to dn.subtree=ou=People,dc=touk,dc=pl
attrs=entry,entryUUID,memberOf,@toukAnonAccess by anonymous =scr by * break
{2}to dn.subtree=ou=Group,dc=touk,dc=pl
attrs=entry,@groupOfUniqueNames,@groupOfNames by anonymous =scr by * break
... later ACLs handling specific accesses and stuff, terminated with:
{14}to * by users =scr
Now if we do search doing non-anonymous binds, everything works correctly:
ldapsearch -x -H ldaps://ldap.touk.pl -D "cn=Michał
Sołtys,ou=Touki,ou=People,dc=touk,dc=pl" -s sub -b
'ou=Touki,ou=People,dc=touk,dc=pl' -o ldif-wrap=no -y ./pass -LLL -v
'(uid=ast)' memberOf entryUUID
ldap_initialize( ldaps://ldap.touk.pl:636/??base )
filter: (uid=ast)
requesting: memberOf entryUUID
dn: cn=Adam Stus,ou=Touki,ou=People,dc=touk,dc=pl
entryUUID: 6c1adf48-a800-103a-8044-3100241d53c2
memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
But if we do an anonymous search - with ACLs as above explicitly allowing
access to all relevant parts as in rule {1}, memberOf is not returned (it can't
be used in filtering either):
ldapsearch -x -H ldaps://ldap.touk.pl -s sub -b
'ou=Touki,ou=People,dc=touk,dc=pl' -o ldif-wrap=no -LLL -v '(uid=ast)'
memberOf entryUUID
ldap_initialize( ldaps://ldap.touk.pl:636/??base )
filter: (uid=ast)
requesting: memberOf entryUUID
dn: cn=Adam Stus,ou=Touki,ou=People,dc=touk,dc=pl
entryUUID: 6c1adf48-a800-103a-8044-3100241d53c2
This - unless I missed something - looks like a bug.
As mentioned above - our local confluence install is using dedicated user, but
for some reason it is also unable filter using memberOf (though surprisingly it
does work from command line for non-anonymous bind). Relevant parts of the
slapd.log of such query:
Mar 6 19:21:24 lipa1 slapd[1206591]: conn=1009 op=0 BIND
dn="cn=confluence,ou=Apps,dc=touk,dc=pl" method=128
Mar 6 19:21:24 lipa1 slapd[1206591]: conn=1009 op=0 BIND
dn="cn=confluence,ou=Apps,dc=touk,dc=pl" mech=SIMPLE bind_ssf=0 ssf=256
Mar 6 19:21:24 lipa1 slapd[1206591]: conn=1009 op=0 RESULT tag=97 err=0
qtime=0.000016 etime=0.000230 text=
... other operations
Mar 6 19:26:58 lipa1 slapd[1206591]: conn=1009 op=28 SRCH
base="ou=Touki,ou=People,dc=touk,dc=pl" scope=2 deref=3
filter="(&(toukAccountActive=TRUE)(memberOf=cn=finanse,ou=touk,ou=group,dc=touk,dc=pl))"
Mar 6 19:26:58 lipa1 slapd[1206591]: conn=1009 op=28 SRCH attr=1.1
Mar 6 19:26:58 lipa1 slapd[1206591]: conn=1009 op=28 SEARCH RESULT tag=101
err=0 qtime=0.000019 etime=0.000541 nentries=0 text=
See (nentries=0) above - but identical search performed from command line,
e.g.:
ldapsearch -x -H ldaps://ldap.touk.pl -D "cn=confluence,ou=Apps,dc=touk,dc=pl"
-y ./b -a always -s sub -b 'ou=Touki,ou=People,dc=touk,dc=pl' -o ldif-wrap=no
-LLL -v
'(&(toukAccountActive=TRUE)(memberOf=cn=finanse,ou=touk,ou=group,dc=touk,dc=pl))'
1.1
correctly returns 6 people:
Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=0 BIND
dn="cn=confluence,ou=Apps,dc=touk,dc=pl" method=128
Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=0 BIND
dn="cn=confluence,ou=Apps,dc=touk,dc=pl" mech=SIMPLE bind_ssf=0 ssf=256
Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=0 RESULT tag=97 err=0
qtime=0.000025 etime=0.000269 text=
Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=1 SRCH
base="ou=Touki,ou=People,dc=touk,dc=pl" scope=2 deref=3
filter="(&(toukAccountActive=TRUE)(memberOf=cn=finanse,ou=touk,ou=group,dc=touk,dc=pl))"
Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=1 SRCH attr=1.1
Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=2 UNBIND
Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=1 SEARCH RESULT tag=101
err=0 qtime=0.000019 etime=0.002765 nentries=6 text=
--
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
----------------------------------------------------------------------------
Keywords|needs_review |
--
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 #7 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
(In reply to Fredrik Roubert from comment #6)
> Does anyone have any opinion about this?
We've assigned it for review, ty for the PR!
--
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
----------------------------------------------------------------------------
Keywords| |needs_review
--
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
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |smckinney(a)symas.com
--
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 #6 from Fredrik Roubert <fredrik(a)roubert.name> ---
Does anyone have any opinion about this?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10018
Issue ID: 10018
Summary: lmdb runs for two years and triggers abort error
Product: LMDB
Version: 0.9.23
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: Zhou.chang(a)h3c.com
Target Milestone: ---
We found that when the Last transaction ID exceeds the maximum value, the
database abort signal will be triggered and two errors will be reported:
Assertion 'rc == 0' failed in mdb_page_dirty()
Assertion 'mp->mp_pgno != pgno' failed in mdb_page_touch()
I would like to ask whether the current lmdb has considered this situation,
./mdb_stat -e /tmp/lmdb
Environment Info
Map address: (nil)
Map size: 10485760
Page size: 4096
Max pages: 2560
Number of pages used: 238
Last transaction ID: 4294967295
Max readers: 126
Number of readers used: 2
--
You are receiving this mail because:
You are on the CC list for the issue.