https://bugs.openldap.org/show_bug.cgi?id=9284
Issue ID: 9284
Summary: Need man page for vc contrib overlay
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The verified credentials overlay in contrib is missing a man page describing
its purpose
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9444
Issue ID: 9444
Summary: Feature Request: Textual error data is not sent
through chaining overlay
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: andrewlanecarr(a)gmail.com
Target Milestone: ---
When operating in a replicated environment we would like to see the text
message accompany the error code propagated to the other nodes in the cluster.
For Example:
Master Log -
master slapd[406]: conn=1160 op=3 MOD attr=userPassword
master slapd[406]: conn=1160 op=3 RESULT tag=103 err=19 text=Password is not
being changed from existing value
Slave Log -
slave slapd[31094]: conn=1000 op=18 MOD attr=userPassword
slave slapd[31094]: conn=1000 op=18 RESULT tag=103 err=19 text=
The text "Password is not being changed from existing value" is not copied in
this process. This is using the following configuration:
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9224
Bug ID: 9224
Summary: Add support for PREPARE/2-phase commit
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
In LMDB, add support for PREPARE/2-phase commits
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9363
Issue ID: 9363
Summary: removing olcReadOnly on a DB does not set it to FALSE
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: maxime.besson(a)worteks.com
Target Milestone: ---
Created attachment 771
--> https://bugs.openldap.org/attachment.cgi?id=771&action=edit
ldif config that reproduces the issue
I am running the following test:
* add olcReadOnly: TRUE on a MDB database in cn=config
* Try to write to the MDB database => fails with "unwilling to perform" as
expected
* remove the olcReadOnly attribute from the MDB database
* Try to write to the MDB database => still fails with the same error
* Restart slapd
* Try to write to the MDB database => OK
However the following test works as expected:
* add olcReadOnly: TRUE on a MDB database in cn=config
* Try to write to the MDB database => fails with "unwilling to perform" as
expected
* modify olcReadOnly to FALSE on the MDB database
* Try to write to the MDB database => OK
It seems a little counter intuitive to me that removing a setting does not
reset it to its default value. The fact that a slapd restart make writing
possible again in the first test described above makes it seem to the casual
user that olcReadOnly cannot be undone without a restart at all.
Tested in 2.4.53 and 2.4.44, config attached but it probably works with any
config (hdb, etc)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9219
Bug ID: 9219
Summary: Streamline tool API for 2.5
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The current tool API is a mess and needs fixing for 2.5. This affects things
like slapacl (The fix for bug#7920 was a kludge to deal with this, needs
revisiting).
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9295
Issue ID: 9295
Summary: ppolicy and replication: pwdLockedTime replication
fails to replicate
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If you have the following setup, a replica will hit an error during
replication.
a) ppolicy is configured on provider(s) and replicas. Replica has
schemachecking=on in its syncrepl configuration
b) account gets locked on the replica, so pwdAccountLockedTime is set on the
replica but not on the provider(s)
c) admin does a MOD/ADD op against a provider for the user entry to add a value
to pwdAccountLockedTime
dn: ...
changetype: modify
add: pwdAccountLockedTime
pwdAccountLockedTime: ...
d) provider accepts this modification.
e) replica rejects this modification because the resulting change means that
there would be two pwdAccountLockedTime values on the account in question
Generally I believe that in this scenario, the MOD/ADD on the provider should
be treated as a replace OP instead of an ADD op
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9396
Issue ID: 9396
Summary: Docs might recommend applicationProcess for ppolicy
entries
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: kop(a)karlpinc.com
Target Milestone: ---
Created attachment 779
--> https://bugs.openldap.org/attachment.cgi?id=779&action=edit
Suggested doc patch
Hello,
The ppolicy section of the Admin Guide does not say why the "people" object
class is present in the example policy entry.
I suggest that the docs explain. Otherwise the reader is left wondering why
the particular choice of structural object class was made. The less informed
reader is left wondering why a second object class is required at all.
I also suggest that instead of the "people" object class,
that the applicationProcess object class be used in the example to provide the
structural object class the entry requires.
The slapo-ppolicy man page might also provide guidance.
Attached is a suggested patch, provided so that you have something to work
from. If you're not happy with the patch go ahead and discard it, I'm not
advocating
any particular wording.
I, Karl O. Pinc, 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.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9337
Issue ID: 9337
Summary: Slapd crash with lastbind overlay
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: frederic.poisson(a)admin.gmessaging.net
Target Milestone: ---
Hello,
I have an issue with a 2.4.50 OpenLDAP instance configured with replication (1
master and 1 replica), and when i activate the lastbind overlay. The replica
server crash like this :
slapd[8433]: segfault at 1d0 ip 000000000049f70b sp 00007f189f7fd1a0 error 4 in
slapd[400000+1d8000]
The database is this one with overlay loaded :
dn: cn=module{0},cn=config
olcModuleLoad: {0}sssvlv.la
olcModuleLoad: {1}ppolicy.la
olcModuleLoad: {2}syncprov.la
olcModuleLoad: {3}lastbind.la
olcModuleLoad: {4}pw-sha2.la
dn: olcDatabase={3}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcUpdateRef: ldap://master.server:389/
If i add this configuration it crash :
dn: olcOverlay={2}lastbind
objectClass: olcOverlayConfig
objectClass: olcLastBindConfig
olcOverlay: {2}lastbind
olcLastBindPrecision: 60
olcLastBindForwardUpdates: TRUE
Does the release 2.5.51 or 2.5.52 could solve this issue ?
Regards,
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9461
Issue ID: 9461
Summary: Deletion causes cursor to repeat
Product: LMDB
Version: 0.9.27
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: github(a)nicwatson.org
Target Milestone: ---
Created attachment 795
--> https://bugs.openldap.org/attachment.cgi?id=795&action=edit
repro of cursor delete bug
See attached source code for reproduction. The test behaves correctly in
0.9.26 and fails in 0.9.27 and 0.9.28.
The failing sequence is:
1. In a dupsort DB, create two different keys and values.
2. Create a cursor, setting the position to the second key.
3. Delete the first key.
4. Have the cursor get the next key. mdb_get_key will return the second key
instead of returning MDB_NOT_FOUND.
--
You are receiving this mail because:
You are on the CC list for the issue.