Re: (ITS#5764) addpartial patch
by dhawes@vt.edu
Pierangelo Masarati wrote:
> dhawes(a)vt.edu wrote:
>> Full_Name: David Hawes
>> Version: 2.4.12
>> OS: URL: ftp://ftp.openldap.org/incoming/david-hawes-081021.patch
>> Submission from: (NULL) (128.173.38.164)
>>
>>
>> This patch includes the following changes:
>>
>> - -fPIC added to the Makefile for compilation on x86_64 systems.
>> - No longer use be_search() to retrieve the entry that is to be
>> compared. Use
>> be_entry_get_rw() instead.
>
> You should probably use overlay_entry_get_ov() rather than
> be_entry_get_rw() from inside an overlay (AFAIR).
Okay, I'll make that change, thanks.
I notice that most overlays seem to use be_entry_get_rw(), and one
(translucent) uses both. What is the reasoning to use one over the other?
15 years, 1 month
(ITS#5781) syncrepl doing delete/add on items without equality
by rubin@physics.umn.edu
Full_Name: Alex Schumann
Version: 2.4.11
OS: freebsd 7.0-release-p3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (128.101.220.229)
We are using nis.schema's nisNetgroupTriple to hold unix netgroups. When we
make a change, we do so using the following code snipit:
$mesg = $ldap_master->modify ( $dn, replace => [ 'nisNetgroupTriple' =>
\@{$groups{$g}} ] );
The master accepts this change, but all the syncrepl slaves immediately start
failing:
Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 be_search (0)
Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001
cn=ng115,ou=Netgroup,dc=suppressed,dc=suppressed,dc=suppressed
Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 entry unchanged,
ignored (cn=ng115,ou=Netgroup,dc=suppressed,dc=suppressed,dc=suppressed)
Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 be_search (0)
Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001
cn=ng116,ou=Netgroup,dc=suppressed,dc=suppressed,dc=suppressed
Oct 29 11:54:28 lanark slapd[4187]: null_callback : error code 0x12
Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 be_modify (18)
Oct 29 11:54:28 lanark slapd[4187]: syncrepl_entry: rid=001 be_modify failed
(18)
Oct 29 11:54:28 lanark slapd[4187]: do_syncrepl: rid=001 retrying
Error code 0x12 is LDAP_INAPPROPRIATE_MATCHING, which indicates that syncrepl
tried to do a delete/add on a multivalued attribute witohout an equality
matching rule. Reason being, the schema for nis defines nisNetgroupTriple
without an EQUALITY. You can argue between openldap and sun if that is an error
in the schema, but fact is syncrepl should not fail in this or similar cases.
Proper behavior would be if there is no equality, syncrepl should fall back to a
replace.
many thanks to hyc on freenode #openldap for helping me to understand what was
going on here.
http://www.archivesat.com/OpenLDAP_bugs/thread1581049.htm indicates
nisNetgroupTriple is improperly defined according to SUN, but is really an aside
on this bug.
15 years, 1 month
Re: (ITS#5764) addpartial patch
by ando@sys-net.it
dhawes(a)vt.edu wrote:
> Full_Name: David Hawes
> Version: 2.4.12
> OS:
> URL: ftp://ftp.openldap.org/incoming/david-hawes-081021.patch
> Submission from: (NULL) (128.173.38.164)
>
>
> This patch includes the following changes:
>
> - -fPIC added to the Makefile for compilation on x86_64 systems.
> - No longer use be_search() to retrieve the entry that is to be compared. Use
> be_entry_get_rw() instead.
You should probably use overlay_entry_get_ov() rather than
be_entry_get_rw() from inside an overlay (AFAIR).
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
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
15 years, 1 month
Re: (ITS#5779) backsql_load_schema_map checks wrong schema column in db
by robb@wtg.cw.com
Pierangelo Masarati wrote:
> I have applied a blind fix to back-sql/schema-map.c; please apply the
> patch between r1.67 & r1.68 and report (presented below as a reference).
>
> p.
>
> diff -u -r1.67 schema-map.c
> --- servers/slapd/back-sql/schema-map.c 21 Aug 2008 20:07:29 -0000
> 1.67
> +++ servers/slapd/back-sql/schema-map.c 30 Oct 2008 13:02:24 -0000
applied the fix and issue is resolved.
Many thanks (and man that was fast :)
Rob
15 years, 1 month
Re: (ITS#5779) backsql_load_schema_map checks wrong schema column in db
by ando@sys-net.it
robb(a)wtg.cw.com wrote:
> Full_Name: Robert Brooks
> Version: 2.4.12
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (212.28.17.64)
>
>
> start-up of slapd reports
>
> "backsql_load_schema_map(): required column #6 "expect_return" is empty"
>
> however the value of ldap_oc_mappings.create_proc is actually being checked,
> this can be confirmed by changing create_proc value in database from empty value
> to non-empty.
>
> problem seems to be around line 567 of schema-map.c
>
> " { delete_proc_idx + 1, "expect_return" },"
>
> 6 seems correct value, but actual result is not correct
I have applied a blind fix to back-sql/schema-map.c; please apply the
patch between r1.67 & r1.68 and report (presented below as a reference).
p.
diff -u -r1.67 schema-map.c
--- servers/slapd/back-sql/schema-map.c 21 Aug 2008 20:07:29 -0000 1.67
+++ servers/slapd/back-sql/schema-map.c 30 Oct 2008 13:02:24 -0000
@@ -570,7 +570,7 @@
int i;
for ( i = 0; required[ i ].name != NULL; i++ ) {
- if ( oc_row.value_len[ i ] <= 0 ) {
+ if ( oc_row.value_len[ required[ i ].idx ] <= 0 ) {
Debug( LDAP_DEBUG_ANY,
"backsql_load_schema_map(): "
"required column #%d \"%s\" is empty\n",
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
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
15 years, 1 month
Re: (ITS#5759) whitespace vs white space
by ghenry@OpenLDAP.org
quanah(a)OpenLDAP.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: HEAD
> OS: NA
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (75.111.29.239)
>
>
> I noticed that the term "whitespace" and "white space" are used inconsistently
> throughout the documentation. Can we please pick one? ;)
>
> --Quanah
>
>
whitespace it is.
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
15 years, 1 month
Re: (ITS#5709) slapd sync provider skips some objects
by ghenry@OpenLDAP.org
Can you upload these zip attachments to our ftp server or somewhere else with online
access please. Then we can test.
>
> ------=_Part_18730_5320025.1224681987183
> Content-Type: application/zip; name=test018-parallel-import.zip
> Content-Transfer-Encoding: base64
> X-Attachment-Id: file0
> Content-Disposition: attachment; filename=test018-parallel-import.zip
--
Kind Regards,
Gavin Henry.
OpenLDAP Engineering Team.
E ghenry(a)OpenLDAP.org
Community developed LDAP software.
http://www.openldap.org/project/
15 years, 1 month