Full_Name: Quanah Gibson-Mount
Version: 2.4.39
OS: Linux 3.11
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.111.58.125)
When trying to find a set of broken entries, I found that it is impossible to
filter on objectClass=glue:
[zimbra@ldap01 ~]$ ldapsearch -x -LLL -D $zimbra_ldap_userdn -w
$zimbra_ldap_password -H $ldap_url -b
"ou=people,dc=xxx,dc=xxx,dc=xxx%2%2"(objectClass=glue)" 1.1
[zimbra@ldap01 ~]$ echo $?
0
I am immediately returned to the prompt, and the error result is success (0).
Instead, I expect all the broken glue'd objects returned instead.
On Fri, Jan 10, 2014 at 04:40:39AM +0000, fumiyas(a)osstech.co.jp wrote:
> If slapd.conf has the following config, slapd segfault at startup.
>
> overlay constraint
> constraint_attribute memberUid size 0
> # or
> constraint_attribute memberUid count 0
Hi,
I've uploaded a fix to this issue and #7781 to
ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20140915-ITS-7780-7781.tgz
could you confirm it fixes the issues for you?
The above patch is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the above patches
were developed by Ondřej Kuzník <ondra(a)mistotebe.net>. I have not
assigned rights and/or interest in this work to any party.
I, Ondřej Kuzník, hereby place the above 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.
Cheers,
Ondrej
--On Monday, September 15, 2014 12:19 PM +0000 sharbich(a)t-online.de wrote:
> Full_Name: Stefan Harbich
> Version: 2.4.31-1+nmu2 / amd64
> OS: Debian Wheezy 7.6
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (88.128.80.149)
The ITS system is for reporting bugs, not asking usage questions. Please
use the openldap-technical(a)openldap.org discussion list for questions.
This ITS will be closed.
--Quanah
--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
Full_Name: Stefan Harbich
Version: 2.4.31-1+nmu2 / amd64
OS: Debian Wheezy 7.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (88.128.80.149)
Hello everyone,
at the imput:
abc@xyz01:~$ ldapsearch -b
"dcSubMailAddress=sharbich(a)t-online.de,uid=test,ou=users,dc=xyz,dc=de", i get
the following result appears:
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
additional info: SASL(-1): generic failure: unable to canonify user and get
auxprops.
I run the command as root: root@xyz01:# ldapsearch -b
dcSubMailAddress=xyz(a)t-online.de,uid=test,ou=users,dc=xyz,dc=de
lists all values of ​​the user.
Can the problem be due to the authorization?
Many Thanks, by Stefan Harbich
pdg(a)uow.edu.au wrote:
> Full_Name: Peter Gray
> Version: 2.4.39
> OS: solaris 10
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (130.130.37.84)
>
>
> The code in back-sock seems to have an error.
>
> It opens a socket, converts the socket fd to a FILE *, and uses fprintf to send
> data to the socket. For example, from search.c:
Thanks for the report, fixed in git master.
>
>
> fprintf( fp, "SEARCH\n" );
> fprintf( fp, "msgid: %ld\n", (long) op->o_msgid );
> sock_print_conn( fp, op->o_conn, si );
> sock_print_suffixes( fp, op->o_bd );
> fprintf( fp, "base: %s\n", op->o_req_dn.bv_val );
> fprintf( fp, "scope: %d\n", op->oq_search.rs_scope );
> fprintf( fp, "deref: %d\n", op->oq_search.rs_deref );
> fprintf( fp, "sizelimit: %d\n", op->oq_search.rs_slimit );
> fprintf( fp, "timelimit: %d\n", op->oq_search.rs_tlimit );
> fprintf( fp, "filter: %s\n", op->_s_search.rs_filterstr.bv_val );
> fprintf( fp, "attrsonly: %d\n", op->oq_search.rs_attrsonly ? 1 : 0 );
> fprintf( fp, "attrs:%s", op->oq_search.rs_attrs == NULL ? " all" : ""
> );
> for ( an = op->oq_search.rs_attrs; an && an->an_name.bv_val; an++ ) {
> fprintf( fp, " %s", an->an_name.bv_val );
> }
> fprintf( fp, "\n\n" ); /* end of attr line plus blank line */
>
> /* read in the results and send them along */
> rs->sr_attrs = op->oq_search.rs_attrs;
> sock_read_and_send_results( op, rs, fp );
>
> However, it fails to flush the stream, so in sock_read_and_send_results when it
> issues a read from the socket, the data written has not been seen by the socket
> endpoint.
>
> This results in deadlock when slapd is waiting on the read, and the daemon on
> the other end of the socket is waiting on the ldap query.
>
> My fix is to call fflush as the first operation on sock_read_and_send_results
> and this worked fine.
>
> Here is the diff.
> *** .snapshot/nightly.0/result.c Sun Jan 26 00:36:15 2014
> --- result.c Thu Sep 11 11:25:07 2014
> ***************
> *** 48,53 ****
> --- 48,54 ----
> char line[BUFSIZ];
> char ebuf[128];
>
> + (void) fflush(fp);
> /* read in the result and send it along */
> buf = (char *) ch_malloc( BUFSIZ );
> buf[0] = '\0';
>
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Full_Name: Peter Gray
Version: 2.4.39
OS: solaris 10
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (130.130.37.84)
The code in back-sock seems to have an error.
It opens a socket, converts the socket fd to a FILE *, and uses fprintf to send
data to the socket. For example, from search.c:
fprintf( fp, "SEARCH\n" );
fprintf( fp, "msgid: %ld\n", (long) op->o_msgid );
sock_print_conn( fp, op->o_conn, si );
sock_print_suffixes( fp, op->o_bd );
fprintf( fp, "base: %s\n", op->o_req_dn.bv_val );
fprintf( fp, "scope: %d\n", op->oq_search.rs_scope );
fprintf( fp, "deref: %d\n", op->oq_search.rs_deref );
fprintf( fp, "sizelimit: %d\n", op->oq_search.rs_slimit );
fprintf( fp, "timelimit: %d\n", op->oq_search.rs_tlimit );
fprintf( fp, "filter: %s\n", op->_s_search.rs_filterstr.bv_val );
fprintf( fp, "attrsonly: %d\n", op->oq_search.rs_attrsonly ? 1 : 0 );
fprintf( fp, "attrs:%s", op->oq_search.rs_attrs == NULL ? " all" : ""
);
for ( an = op->oq_search.rs_attrs; an && an->an_name.bv_val; an++ ) {
fprintf( fp, " %s", an->an_name.bv_val );
}
fprintf( fp, "\n\n" ); /* end of attr line plus blank line */
/* read in the results and send them along */
rs->sr_attrs = op->oq_search.rs_attrs;
sock_read_and_send_results( op, rs, fp );
However, it fails to flush the stream, so in sock_read_and_send_results when it
issues a read from the socket, the data written has not been seen by the socket
endpoint.
This results in deadlock when slapd is waiting on the read, and the daemon on
the other end of the socket is waiting on the ldap query.
My fix is to call fflush as the first operation on sock_read_and_send_results
and this worked fine.
Here is the diff.
*** .snapshot/nightly.0/result.c Sun Jan 26 00:36:15 2014
--- result.c Thu Sep 11 11:25:07 2014
***************
*** 48,53 ****
--- 48,54 ----
char line[BUFSIZ];
char ebuf[128];
+ (void) fflush(fp);
/* read in the result and send it along */
buf = (char *) ch_malloc( BUFSIZ );
buf[0] = '\0';
requate(a)univention.de wrote:
> Full_Name: Arvid Requate
> Version: 2.4.35
> OS: Debian / UCS
> URL: http://apt.univention.de/download/temp/openldap/
> Submission from: (NULL) (82.198.197.8)
>
>
> After adjusting a matching rule of an attribute ldapsearch for existing
> attribute values returns unexpected results.
Making such changes requires the DB to be reloaded. This is not a bug, closing
this ITS.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Full_Name: Arvid Requate
Version: 2.4.35
OS: Debian / UCS
URL: http://apt.univention.de/download/temp/openldap/
Submission from: (NULL) (82.198.197.8)
After adjusting a matching rule of an attribute ldapsearch for existing
attribute values returns unexpected results. As an example the log file and the
script provided in the URL show what happened:
A) Start with the normal inetorgperson.schema.
1. create a inetOrgPerson object with and uppercase string in "carLicense"
2. search for the attributes in with different filters (normal and extensive
matching)
3. change the EQUALITY matching rule for that attribute from caseIgnoreMatch to
caseExactMatch (either in slapd.conf and restart or in cn=config without
restart).
4. search again.
Expected result A.1: the normal search for the uppercase value should return the
value
The log file shows: the search for the uppercase value returns no result
Expected result A.2: the normal search for the lowercase value should return no
result
The log file shows: the search for the lowercase value returns a result
The same holds for the extensible :caseExactMatch: search.
B) The second, morempreressive, inverse test shows that this behaviour depends
on the matching rule that was in place at the time the obejct gets created:
Starting now with a caseExactMatch EQUALITY matching rule for "carLicense" I
repeat the test above:
1. create a inetOrgPerson object with and uppercase string in "carLicense"
2. search for the attributes in with different filters (normal and extensive
matching)
3. change the EQUALITY matching rule for that attribute from caseExactMatch to
caseIgnoreMatch (either in slapd.conf and restart or in cn=config without
restart).
4. search again.
Expected result B.1: the normal search for the uppercase value should return the
value
The log file shows: the search for the uppercase value returns no result
Expected result B.2: the normal search for the lowercase value should return the
value
The log file shows: the search for the lowercase value returns no result
Expected result B.3: the :caseIgnoreMatch: extensible filter should find the
value
The log file shows: the search for the lowerca v value returns no result
The provided shell script works by changing the schema directly via cn=config,
but the same results can be found when using static configuration+schema files
and restarting slapd after each schema modification.
No index was configured for the "carLicense" attribute and a bdb backend was
used. See the cn=config.ldif provided.