https://bugs.openldap.org/show_bug.cgi?id=8246
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|OL_2_5_REQ, reviewed |
--- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Commits:
• 7ff1f42f
by Howard Chu at 2021-03-21T14:58:22+00:00
ITS#8246 frontend and config DBs are unique
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9016
--- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Commits:
• cf67fc22
by OndÅ™ej KuznÃk at 2021-03-19T12:48:09+00:00
ITS#9016 Do not forget to close directory handle
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8589
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |TEST
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Howard Chu <hyc(a)openldap.org> ---
fixed in master
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9152
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |TEST
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Howard Chu <hyc(a)openldap.org> ---
Fixed in master.
Note that in this case, the overlay will never auto-install its own server
cert, you'll have to explicitly provide it later.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8577
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |TEST
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Howard Chu <hyc(a)openldap.org> ---
fixed in master
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8726
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |TEST
--- Comment #3 from Howard Chu <hyc(a)openldap.org> ---
fixed in master
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8545
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Howard Chu <hyc(a)openldap.org> ---
(In reply to shalopo(a)gmail.com from comment #0)
> Full_Name: Shahar Lupu
> Version: 2.4.44
> OS: Ubuntu
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (81.218.29.26)
>
>
> When calling ldap_result with a timeout={0,0} (polling), it returns
> LDAP_TIMEOUT
> even though there are available messages in the socket.
> This occurs when calling ldap_results with all=true and a multi-message
> response
> has arrived. In this case, if the client has already received on the socket
> every message for the response, it is desirable that all the messages are
> collected within this ldap_result call. Instead of only polling for the
> specified timeout, ldap_result applies the timeout (zero when polling) on the
> wait4msg loop. Consequently, ldap_result returns LDAP_TIMEOUT after the first
> message if the response is composed of more than one message.
> While it may be a good idea to apply a timeout for the wai4msg loop (rather
> than
> only the polling on the socket), it is undesirable in some cases and should
> at
> least be configurable. Or perhaps timeout=polling should never be applied on
> the
> wait4msg loop.
None of this will make any difference. In try_read1msg, there is a check
to see if the socket is still readable at the end, in which case it will
loop back and read the next message. As such, when it returns to wait4msg,
all readable messages have already been processed. So even if it returns
LDAP_TIMEOUT, it returns all available messages. If it only returns one
message, that means no others were available.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8458
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Howard Chu <hyc(a)openldap.org> ---
The bug report makes no sense.
(In reply to mozo(a)mozo.jp from comment #0)
> As LDIF backend tries to store the values for the attributes in "prettified"
> form and the value is transferred verbatim in wire, replication of
> pwdAttribute
> (1.3.6.1.4.1.42.2.27.8.1.1) ends up with the following error:
>
> > syncrepl_message_to_entry: rid=001 mo cheheck (pwdAttribute: value #0 invalid
> per syntax)
>
> The validation causing the error itself is done in the following part in
> servers/slapd/modify.c:
>
> /*
> * check that each value is valid per syntax
> * and pretty if appropriate
> */
> for ( nvals = 0; !BER_BVISNULL( &ml->sml_values[nvals] );
> nvals++ )
> {
> struct berval pval;
>
> if ( pretty ) {
> rc = ordered_value_pretty( ad,
> &ml->sml_values[nvals], &pval, ctx );
> } else {
> rc = ordered_value_validate( ad,
> &ml->sml_values[nvals], ml->sml_op );
> }
>
> if( rc != 0 ) {
> snprintf( textbuf, textlen,
> "%s: value #%ld invalid per syntax",
> ml->sml_type.bv_val, (long) nvals );
> *text = textbuf;
> return LDAP_INVALID_SYNTAX;
> }
>
> if( pretty ) {
> ber_memfree_x( ml->sml_values[nvals].bv_val, ctx );
> ml->sml_values[nvals] = pval;
> }
> }
>
> where pwdAttribute has the corresponding prettifier assigned to its schema
> (servers/slapd/overlays/ppolicy.c), which eventually is fed with the value in
> prettified form that will effectively make slap_bv2ad() in attrPretty() fail.
attrPretty will only fail if the item it's passed has not been defined
in the schema.
>
> {
> Syntax *syn;
> MatchingRule *mr;
>
> syn = ch_malloc( sizeof( Syntax ));
> *syn = *ad_pwdAttribute->ad_type->sat_syntax;
> syn->ssyn_pretty = attrPretty;
> ad_pwdAttribute->ad_type->sat_syntax = syn;
>
> mr = ch_malloc( sizeof( MatchingRule ));
> *mr = *ad_pwdAttribute->ad_type->sat_equality;
> mr->smr_normalize = attrNormalize;
> ad_pwdAttribute->ad_type->sat_equality = mr;
> }
>
> The replication works fine for other such attributes that have the same
> syntax
> (OID, 1.3.6.1.4.1.1466.115.121.1.38) like objectClass because those
> attributes
> are accompanied by the validators as well as prettifiers which validate the
> value both in prettified and OID form. For instance, objectClass has the
> corresponding validator oialalidate() besides the prettifier
> objectClassPretty().
The code you quoted from slapd/modify.c clearly shows that if a prettifier is
defined, then the validator is ignored, therefore it is irrelevant.
So again, this only fails if the schema element in question is not defined,
which means you have a configuration error. Closing this ITS.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7295
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |TEST
Status|UNCONFIRMED |RESOLVED
--- Comment #3 from Howard Chu <hyc(a)openldap.org> ---
Fixed in master
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8246
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |TEST
--- Comment #1 from Howard Chu <hyc(a)openldap.org> ---
fixed in master
--
You are receiving this mail because:
You are on the CC list for the issue.