https://bugs.openldap.org/show_bug.cgi?id=9790
Issue ID: 9790
Summary: Build failure with GCC 4.1 and 4.3
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: orgads(a)gmail.com
Target Milestone: ---
In file included from ../../include/lutil.h:21,
from passwd.c:60:
../../include/ac/socket.h:247: error: redefinition of typedef 'Sockaddr'
../../include/ldap_pvt.h:188: error: previous declaration of 'Sockaddr' was
here
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9788
Issue ID: 9788
Summary: make warns about disabling/resetting jobserver
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: orgads(a)gmail.com
Target Milestone: ---
Running make -j8 issues the following warning for each directory with make 4.3:
make[2]: warning: -j8 forced in submake: resetting jobserver mode.
with make 4.2.1:
make[3]: warning: -jN forced in submake: disabling jobserver mode.
With make 3.82 there is no warning, but the jobserver flags are duplicated for
each nested directory. e.g.:
cd back-monitor && make -w --jobserver-fds=3,4 - --jobserver-fds=3,4 -
--jobserver-fds=3,4 - --jobserver-fds=3,4 -j all
On my env this is fixed by removing all the occurrences of $(MFLAGS) from
build/dir.mk. MFLAGS is picked up by make when it exists, and there is no need
to pass it explicitly.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9785
Issue ID: 9785
Summary: test050 deadlock
Product: OpenLDAP
Version: 2.5.11
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Running test050 in a loop sometimes results in a deadlock. Took 17 iterations
on one system, was 100% on another.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9789
Issue ID: 9789
Summary: syncprov uses a thread-local counters for the detached
op
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Persistent searches routinely migrate across threads, however they keep using
op->o_counters from the original search op which is meant to be thread-local.
During shutdown, this counter can be destroyed as the original thread finishes,
but the persistent search might still be live somewhere else. At that point,
trying to acquire the destroyed sc_mutex fails and the thread usually stalls
forever.
slapd-asyncmeta is very likely to suffer from the same issues.
A representative backtrace of this happening:
Thread 3 (Thread 0x7f0b7d933640 (LWP 2928392) "slapd"):
#0 futex_wait (private=0, expected=2, futex_word=0x7f0b74000ff8) at
../sysdeps/nptl/futex-internal.h:146
#3 0x00007f0b7fd17a05 in ldap_pvt_thread_mutex_lock (mutex=Locked by LWP 0) at
thr_posix.c:313
#4 0x0000000000469564 in slap_send_search_entry (op=Search request conn=1003
op=1 = {...}, rs=Search entry = {...}) at result.c:1503
#5 0x00007f0b7f30561c in syncprov_sendresp (op=Search request conn=1003 op=1 =
{...}, ri=0x7f0b701eb8e0, so=0x7f0b74102b20, mode=1) at syncprov.c:976
#6 0x00007f0b7f305064 in syncprov_qplay (op=Search request conn=1003 op=1 =
{...}, so=0x7f0b74102b20) at syncprov.c:1028
#7 0x00007f0b7f304ecc in syncprov_qtask (ctx=0x7f0b7d932a58,
arg=0x7f0b74102b20) at syncprov.c:1086
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9584
Issue ID: 9584
Summary: cn=config replication ops/refresh should pause server
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Looking into this crash: https://git.openldap.org/openldap/openldap/-/jobs/7286
The thread in question is running a plain syncrepl refresh while another thread
seems to have done the same. This thread fetched the entryUUID attribute of the
'cn=config' entry as 'a' and in the meantime, that entry has been rewritten,
with 'a' presumably cleaned up and returned to the pool, so addressing
a->a_nvals[0] is a NULL-dereference now.
This might or might not be related to the fix in ITS#8102.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9791
Issue ID: 9791
Summary: Build failure with certain disabled features in
openssl
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: orgads(a)gmail.com
Target Milestone: ---
If openssl is configured with either OPENSSL_NO_MD4 or OPENSSL_NO_MD5 the build
fails.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9794
Issue ID: 9794
Summary: Define behaviour for pwdChangedTime modifications
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: david.coutadeur(a)gmail.com
Target Milestone: ---
This issue applies to:
- draft-behera-ldap-password-policy
- openldap 2.5
- openldap 2.6
It is a proposition of behaviour for pwdChangedTime modifications.
modification of the draft:
--------------------------
In section: "8.2.7. Policy State Updates", change this paragraph:
If the value of either pwdMaxAge or pwdMinAge is non-zero, the server
updates the pwdChangedTime attribute on the entry to the current
time.
into:
If the value of either pwdMaxAge or pwdMinAge is non-zero, the server
MUST update the pwdChangedTime attribute on the entry according to this
workflow:
Then insert a new paragraph:
- if the current operation (add or modify) on the password includes
adding or modifying a valid pwdChangedTime attribute, then use this
pwdChangedTime. A "Valid" pwdChangedTime means a syntactically
correct value, compliant with the schema, approved by access rules,
and MAY require a relax control according to the schema defined in
section 5.3.2.
See Relax control RFC for more information:
https://datatracker.ietf.org/doc/html/draft-zeilenga-ldap-relax
- an invalid pwdChangedTime value MUST result in an error, and the
pwdChangedTime MUST NOT be stored
- in any other case, compute the current date and store it in a
GeneralizedTime format
Feel free to comment or propose other ideas.
modification of the code:
--------------------------
If this behaviour makes a consensus, it would be useful to patch both OpenLDAP
2.5 and 2.6.
NOTE: current OpenLDAP 2.5 allows modifying pwdChangedTime alone, but fails to
add a user with both userPassword and pwdChangedTime (it results in a
duplicated pwdChangedTime error)
modification of the documentation:
----------------------------------
In slapo-ppolicy, it can be useful to add a comment in "OPERATIONAL ATTRIBUTES"
section:
Every attribute defined as "NO-USER-MODIFICATION" SHOULD not be
written by standard users.
If needed, an administrator MAY modify them with the relax control.
See Relax control RFC for more information:
https://datatracker.ietf.org/doc/html/draft-zeilenga-ldap-relax
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9620
Issue ID: 9620
Summary: back-monitor: search can access a persistent entry
freed in the meantime
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
With ITS#9600 there is now code that adds and removes "persistent" monitor
entries outside a server pause. A concurrent cn=monitor search lists all
children first and sends them later - monitor is happy to free some of them in
the meantime.
It seems to me that the monitor cache should be protected by a rw mutex
instead, which would be held for reading while a search is happening.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9784
Issue ID: 9784
Summary: Adding our OpenLDAP support services
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: contact(a)linuxstans.com
Target Milestone: ---
Hi,
We offer OpenLDAP support and we'd really appreciate it if you can add our
details to your support page https://www.openldap.org/support/
Here are the details:
<a href="https://linuxstans.com/support/">Linux Stans</a> - USA
Provides installation, configuration, maintenance, and 24/7 support services
for OpenLDAP.
Let me know if you need more info.
Thanks!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9497
Issue ID: 9497
Summary: back-ldif: test022-ppolicy failure
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: hamano(a)osstech.co.jp
Target Milestone: ---
The test022-ppolicy with back-ldif fail for two issue.
1. too short pwdMaxAge
~~~
$ ./run -b ldif test022-ppolicy
(snip)
Testing password expiration
Waiting seconds for password to expire...
sleep: missing operand
Try 'sleep --help' for more information.
Password expiration test failed
~~~
The script tries test for lockout and then a test for password expiration.
It will fail if the password has expired(pwdMaxAge: 30) by the time it starts
the password expiration test.
This is a timing issue and not directly caused by back-ldif.
However, the issue is reproduced only with back-ldif in my environment.
This test passed in my environment by extending pwdMaxAge by 5 seconds, but
there may be a better way.
2. duplicate ldap control response
~~~
Reconfiguring policy to remove grace logins...
Clearing forced reset...
expr: syntax error: unexpected argument '15'
Testing password expiration
Waiting seconds for password to expire...
sleep: missing operand
Try 'sleep --help' for more information.
~~~
This is back-ldif issue.
back-ldif responds duplicate ldap control response.
--
You are receiving this mail because:
You are on the CC list for the issue.