Hi all,
I have noticed recently that for extop plugins the
SLAPI_REQUESTOR_ISROOT parameter is never set.
Is that intended behaviour?
>From the plugin guide chapter 53.3 I would assume it should be ..
Regards,
Jochen
https://fedorahosted.org/389/ticket/47720https://fedorahosted.org/389/attachment/ticket/47720/0001-Ticket-47720-Norm…
Description: DN normalizer (slapi_dn_normalize_ext) follows RFC 4514
and keeps a white space if the RDN attribute type is not based on the
DN syntax. But Directory server's configuration entry sometimes uses
"cn" to store a DN value (e.g., dn: cn="dc=A,dc=com",cn=mapping tree,
cn=config), which expects the value of cn treated as DN although cn
is not a DN syntax type. To solve the problem, this patch introduces
a configuration parameter "nsslapd-cn-uses-dn-syntax-in-dns" to "cn=
config" which takes "on" or "off". If "on" is set, if the value of
cn under "cn=config" is quoted, it's processed as DN. By default,
nsslapd-cn-uses-dn-syntax-in-dns: off
See <http://jenkins.cloud.fedoraproject.org/job/389-ds-base/359/>
------------------------------------------
Started by an SCM change
Building remotely on Fedora20 in workspace <http://jenkins.cloud.fedoraproject.org/job/389-ds-base/ws/>
Wiping out workspace first.
Cloning the remote Git repository
Cloning repository http://git.fedorahosted.org/git/389/ds.git/
Fetching upstream changes from http://git.fedorahosted.org/git/389/ds.git/
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkCredentials(CliGitAPIImpl.java:1933)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1123)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$200(CliGitAPIImpl.java:87)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:254)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:410)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:328)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
ERROR: null
https://fedorahosted.org/389/ticket/47780https://fedorahosted.org/389/attachment/ticket/47780/0001-Ticket-47780-Some…
Fix description:
. Modified idl_free interface as follows so that passed idl is cleared
with NULL once the IDList is successfully freed.
{{{
-idl_free(IDList *idl)
+idl_free(IDList **idl)
}}}
This change is used to clean up search candidates when ldbm_back_
search_cleanup (ldbm_search.c) is called as an error return. The
cleanup function frees the search candidates when it's not NULL and
it's not assigned to sr_candidates field in the search result. This
fixes a memory leak when VLV/Sort op fails.
. ldbm_back_search_cleanup (ldbm_search.c) calls slapi_send_ldap_result
if an ldap error is passed to the function. The logic used to be
"if (ldap_result>=LDAP_SUCCESS)", which is based upon that mozldap
return codes are all positive. Supporting openldap library, there
is a chance to get a negative return code (e.g. LDAP_PARAM_ERROR ==
-9). This patch supports the negative return codes, as well.
. In ldbm_back_search (ldbm_search.c) vlv_filter_candidates could
ruturn errors such as and LDAP_TIMELIMIT_EXCEEDED, LDAP_ADMINLIMIT_
EXCEEDED. The search results are supposed to be returned to the
client with the error code if the control is not critical. The code
is added.
. The VLV operation stores the result in vlv_response_control.result
in ldbm_back_search (ldbm_search.c), which occurs at 3 places, vlv_
filter_candidates, sort_candidates and vlv_trim_candidates_txn.
The return code from the latter calls used to override the former
return code. This patch fixes it to respect the former return code.
https://fedorahosted.org/389/ticket/47764https://fedorahosted.org/389/attachment/ticket/47764/0001-Ticket-47764-Prob…
Bug description: When checking a child entry on a node, it only
checked the first position, which was normally "deleted" if there
were no more children. But in some cases, a tombstoned child was
placed there. If it occurred, even though there were no live child
any more, _entryrdn_delete_key returned "has children" and the delete
operation failed.
Fix description: This patch checks all the children of the to-be-
deleted node and if there is no child or all of them are tombstones,
it goes to the next process. Also, the fixed a typo reported by
chatfield (Thank you!!)