norbert(a)rittel.de wrote:
> When using attribute names containing hyphens the Set code erroneously considers
> the parts to either side of the hyphen as separate tokens.
>
> For example a <by> clause like
>
> by set.exact="this/apple-keyword & user/apple-keyword" read
>
> always yields an empty set. This means that on Apple Open Directory servers set
> clauses canot be used with any Apple-supplied attribute as they all begin with
> "apple-".
The code that parses attribute descriptions appears to be definitely
broken, since it does allow underscores but no hyphens, and it does not
allow digits in attribute descriptions (including OIDs). This should be
fixed now in HEAD, and the patch
servers/slapd/sets.c 1.41 -> 1.42
seems to apply to current re24 and re23 without much hassle.
Please test, p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
Full_Name: Norbert Rittel
Version: 2.3.27
OS: Mac OS X Server 10.5.2
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (217.91.71.78)
When using attribute names containing hyphens the Set code erroneously considers
the parts to either side of the hyphen as separate tokens.
For example a <by> clause like
by set.exact="this/apple-keyword & user/apple-keyword" read
always yields an empty set. This means that on Apple Open Directory servers set
clauses canot be used with any Apple-supplied attribute as they all begin with
"apple-".
Pierangelo Masarati was so kind to verify that this bug is still present in the
latest release. Hopefully the fix is a simple diff that we can apply to the
older version shipping with Mac OS X Server, too. :-)
--opJtzjQTFsWo+cga
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Mar 03, 2008 at 02:50:49PM -0800, Kurt Zeilenga wrote:
> On Mar 3, 2008, at 1:37 PM, mimir(a)samba.org wrote:
> In your rights statement, you claim this patch is only derived from =20
> OpenLDAP Software. Is this correct? Are there are works from which =20
> your work is derived? That is, did you copy any material from any other=
=20
> work (e.g., Samba)? Please document any in the rights statement and,=20
> when complete, update the ITS (by email reply-all) indicating so.
No, it is purely OpenLDAP work using GSS-API libraries.
> The rights statement needs to be amended to include a statement that the=
=20
> modifications are not subject to Stefan's employer. And then Stefan=20
> needs to send a copy of both statements from his email address to=20
> openldap-its(a)openldap.org with a subject of "ITS#5369 IPR statements"=20
> confirming they are correct. I've cc'ed Stefan on this note.
Thanks. The modifications are not subject to his employer, but thanks for
cc-ing him. Sorry Metze, I should have not forgotten about this.
> I note my review is limited to IPR issues. There may well be technical=
=20
> issues to address separately from this. These will be handled separately=
=20
> (normally post IPR review).
Sure, I understand.
cheers,
--=20
Rafal Szczesniak
Samba Team member http://www.samba.org
Likewise Software http://www.likewisesoftware.com
--opJtzjQTFsWo+cga
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHzRUvHvdfyv3qiKkRAga8AJ9aPei2BEkB0cAWnePy1oa0m09s/wCbBWs1
3l6JSyUrgaXSTr3GknJH/oQ=
=OedS
-----END PGP SIGNATURE-----
--opJtzjQTFsWo+cga--
May be a useful precision :
I think that the second protocol detail above shows that the sync provider in
server A "ignores" that the server B has closed the TCP connection.
Best regards
Ali
On Mar 3, 2008, at 1:37 PM, mimir(a)samba.org wrote:
>
> --zhXaljGHf11kAtnf
> Content-Type: text/plain; charset=iso-8859-2
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Fri, Feb 15, 2008 at 09:28:56AM -1000, Kurt Zeilenga wrote:
>> I note that the patch appears to be incomplete. No gssapi.c
>> included.
>
> Sorry about that. Wrong working dir when generating the patch. I've
> uploaded more complete file at http://samba.org/~mimir/head-
> gssapi.diff
> I've also added license notice. Let me know if there's anything else
> missing.
In your rights statement, you claim this patch is only derived from
OpenLDAP Software. Is this correct? Are there are works from which
your work is derived? That is, did you copy any material from any
other work (e.g., Samba)? Please document any in the rights statement
and, when complete, update the ITS (by email reply-all) indicating so.
The rights statement needs to be amended to include a statement that
the modifications are not subject to Stefan's employer. And then
Stefan needs to send a copy of both statements from his email address
to openldap-its(a)openldap.org with a subject of "ITS#5369 IPR
statements" confirming they are correct. I've cc'ed Stefan on this
note.
I note my review is limited to IPR issues. There may well be
technical issues to address separately from this. These will be
handled separately (normally post IPR review).
Regards, Kurt
>
>
>
> cheers,
> --=20
> Rafal Szczesniak
> Samba Team member http://www.samba.org
> Likewise Software http://www.likewisesoftware.com
>
>
> --zhXaljGHf11kAtnf
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: Digital signature
> Content-Disposition: inline
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHzG+9Hvdfyv3qiKkRAmFUAJ9mbHvUFgkz2f/urbdGwbjhSQ6mbQCeMxYZ
> XF5OP4ZaFhwZ5T6rO1FJ4FM=
> =Ii59
> -----END PGP SIGNATURE-----
>
> --zhXaljGHf11kAtnf--
>
>
--zhXaljGHf11kAtnf
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Feb 15, 2008 at 09:28:56AM -1000, Kurt Zeilenga wrote:
> I note that the patch appears to be incomplete. No gssapi.c included.
Sorry about that. Wrong working dir when generating the patch. I've
uploaded more complete file at http://samba.org/~mimir/head-gssapi.diff
I've also added license notice. Let me know if there's anything else
missing.
cheers,
--=20
Rafal Szczesniak
Samba Team member http://www.samba.org
Likewise Software http://www.likewisesoftware.com
--zhXaljGHf11kAtnf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHzG+9Hvdfyv3qiKkRAmFUAJ9mbHvUFgkz2f/urbdGwbjhSQ6mbQCeMxYZ
XF5OP4ZaFhwZ5T6rO1FJ4FM=
=Ii59
-----END PGP SIGNATURE-----
--zhXaljGHf11kAtnf--
Full_Name: Ali Pouya
Version: 2.4.8
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (145.242.11.4)
Hi,
I am testing OpenLdap 2.4.8 in mirrormode.
I have two mirror servers (A, and B) synchronized in SearchAndPersist mode with
a retry interval of 10 seconds : retry="10 +".
An injector writes data to A. The data is replicated in B. But this server
UNBINDs then reBINDs to A every 10 seconds !
This continues until slapd on A crashes with a SIGIOT. More investigation in the
slapd log shows that the crash is caused by the losing of the client syncrepl
connection coming from B !
If instead of B I configure an ordinary replica everything is OK.
I think there are two distinct problems :
1) Contrarily to an ordinary replica, a mirror ends the persistent search,
2) slapd crashes (very scarcely) after losing the client syncrepl connection to
which it was going to send data.
Below you find the backtrace after slapd crash.
See also more protocol details after the backtrace.
If required I can send any detailed information about my configurations.
Thanks for your help
Best Regards
Ali
============================
(gdb) bt
#0 0x009b47a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00138815 in raise () from /lib/tls/libc.so.6
#2 0x0013a279 in abort () from /lib/tls/libc.so.6
#3 0x00131d91 in __assert_fail () from /lib/tls/libc.so.6
#4 0x0805ecb2 in connection_state_closing (c=0xa272585c) at connection.c:680
#5 0x0806c444 in send_ldap_ber (conn=0xa272585c, ber=0x9f7f3c00) at
result.c:153
#6 0x0806f192 in slap_send_search_entry (op=0x9f7f3f50, rs=0x9f7f3de0) at
result.c:1187
#7 0x08134038 in syncprov_qtask (ctx=0x9f7f4210, arg=0x8e21498) at
syncprov.c:809
#8 0x081472df in ldap_int_thread_pool_wrapper (xpool=0x8cbf880) at tpool.c:625
#9 0x00a4e3cc in start_thread () from /lib/tls/libpthread.so.0
#10 0x001da1ae in clone () from /lib/tls/libc.so.6
============================
More protocol details :
1) As an answer to the SearchAndPersist Request, A sends to B an LDAP message
[OPERATION 25] (which I do not know). But this message is not sent to an
ordinary replica.
2) I also noticed that after sending UNBIND, B sends a [FIN, ACK] TCP packet.
As A does not ack this packet B sends a [RST, ACK] packet 30 micro-seconds
later.
-------- Original Message --------
Subject: Corrections for the autogroup README
Date: Mon, 03 Mar 2008 11:48:16 +0100
From: Aleksander Adamowski <aleksander.adamowski(a)altkom.pl>
Reply-To: postmaster(a)altkom.pl
To: hyc(a)symas.com
Hi!
I'd like to add some grammatical corrections to the README file for the
autogroup contrib module:
http://www.openldap.org/devel/cvsweb.cgi/~checkout~/contrib/slapd-modules/a…
The description section should read:
DESCRIPTION
The autogroup overlay allows automated updates of group memberships which
meet the requirements of any filter contained in the group definition.
The filters are built from the LDAP URI-valued attributes. Any time
an object is added/deleted/updated, it is tested for compliance with
the filters, and its membership in autogroups is accordingly updated.
For searches and compares it behaves like a static group.
--
Aleksander Adamowski
Administrator systemów korporacyjnych; Instruktor
Altkom Akademia S.A. http://www.altkom.pl
Warszawa, ul. Chłodna 51
kom. +48 601-318-080
Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego
Rejestru Sądowego,
KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN. Adres
rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa.
Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę
przedsiębiorstwa firmy Altkom Akademia S.A.
Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich
do własnych celów jest zabronione.
Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o
niezwłoczne skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii
niniejszej wiadomości.
This message contains proprietary information and trade secrets of Altkom
Akademia S.A. company.
Unauthorized use or disclosure of this information to any third party is
prohibited.
If you received this message by mistake, please contact the sender immediately
and delete all copies of this message.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
kurt(a)OpenLDAP.org wrote:
> IIRC, it's not listed because it only to be used in certain
> (extensible) matching rules cases and slapd(8) doesn't support any of
> those cases.
Technically, I note it's skipped by syn_schema_info() because it has no
validator (like many other known syntaxes). I don't recall the reason
of this behavior, though. Perhaps it could be relaxed.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
michael(a)stroeder.com wrote:
> Take note of this:
>
> authz-regexp
> "uid=([a-zA-Z0-9]+),cn=digest-md5,cn=auth"
> "ldap:///ou=authz-test,dc=stroeder,dc=local??sub?(uid=$1)"
> [..]
> access to
> dn.onelevel="ou=Users,ou=authz-test,dc=stroeder,dc=local"
> by * auth
>
>
> See test of recent RE23 (port 2003) vs. recent RE24 (port 2004):
As indicated in OpenLDAP 2.4's man page, now the LDA search operation
requires "search" privileges on the "entry" pseudo-attribute of the
searchBase. This was introduced to be able to honor the "disclose"
privilege (or, at least, in conjunction with code that is used to honore
the "disclose" privilege). The man page is erroneous in stating that
this requirement and that feature were introduced in OpenLDAP 2.3: the
code is indeed present in OpenLDAP 2.3, but actually #ifdef'd; it only
became the default behavior in OpenLDAP 2.4.
This requirement, as usual, is downgraded to "auth" when performing
authc/authz related lookups.
I'd take this ITS as a request to fix the documentation (indicate the
change since 2.4 and not since 2.3) and to better notify the different
behavior since 2.3.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------