Re: (ITS#5231) test045 failure in HEAD/RE24
by hyc＠symas.com
Gavin Henry wrote:
> <quote who="hyc(a)OpenLDAP.org">
>> Full_Name: Howard Chu
>> Version: HEAD/RE24
>> OS:
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (76.168.84.21)
>> Submitted by: hyc
>>
>>
>> The comparison fails after the first modify step, an entry that should
>> have been
>> deleted is still present on the slave.
>>
>> The presentlist is still left over from the initial query, and hasn't been
>> emptied yet. This appears to be a missing step when the initial query
>> transitions from Refresh to Persist mode.
> On RE24 mine on AMD64 Dual doesn't get that far. It dies on test033 with:
>
> Comparison failed - database not created correctly.
>
> I'll provide all details shortly, or best to create a new ticket?
I already fixed that in HEAD. See the commit logs.
--
-- 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/
15 years, 10 months
Re: (ITS#5231) test045 failure in HEAD/RE24
by ghenry＠suretecsystems.com
<quote who="hyc(a)OpenLDAP.org">
> Full_Name: Howard Chu
> Version: HEAD/RE24
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (76.168.84.21)
> Submitted by: hyc
>
>
> The comparison fails after the first modify step, an entry that should
> have been
> deleted is still present on the slave.
>
> The presentlist is still left over from the initial query, and hasn't been
> emptied yet. This appears to be a missing step when the initial query
> transitions from Refresh to Persist mode.
>
>
On RE24 mine on AMD64 Dual doesn't get that far. It dies on test033 with:
Comparison failed - database not created correctly.
I'll provide all details shortly, or best to create a new ticket?
>
15 years, 10 months
(ITS#5231) test045 failure in HEAD/RE24
by hyc＠OpenLDAP.org
Full_Name: Howard Chu
Version: HEAD/RE24
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (76.168.84.21)
Submitted by: hyc
The comparison fails after the first modify step, an entry that should have been
deleted is still present on the slave.
The presentlist is still left over from the initial query, and hasn't been
emptied yet. This appears to be a missing step when the initial query
transitions from Refresh to Persist mode.
15 years, 10 months
Re: (ITS#5227) old dsn acceptance
by ando＠sys-net.it
hyc(a)symas.com wrote:
> It seems a bit odd to be introducing support for that format now in 2.4, when
> it was completely unsupported in 2.2 and 2.3. I.e., why wasn't this issue
> raised during the migration to/thru either 2.2 or 2.3?
Probably because until 2.4
#define csnValidate blobValidate
and as such any incompatible CSN was silently ignored. So this has
always been broken, only 2.4 detects the inconsistency, but behaved
badly (assert) until your fix.
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
---------------------------------------
15 years, 10 months
Re: (ITS#5221) cache? of parent failes for hdb
by hyc＠symas.com
Dan.Oscarsson(a)tietoenator.com wrote:
> Full_Name: Dan Oscarsson
> Version: 2.3.32
> OS: SLES 10
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (193.15.240.60)
> From this I suspect that it is the cache of which parent node belongs to
> that gets corrupted. Or can it be something else?
> What more could I do to trace down the bug?
> I do not know if the above information is enough for you to find what is
> wrong? Cannot include data as it contains company internal information and
> a simple test program did not give the same error.
> I have looked at the code, but it takes some time to understand it when
> doing it for the first time. maybe som debugging code could be added
> find the place where the bug is.
This isn't a lot of information to go on. If you can create a test program
that shows the problem occurring, using dummy data, that would help.
--
-- 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/
15 years, 10 months
(ITS#5230) pagedresults ignores sizelimit for rootDN
by hyc＠OpenLDAP.org
Full_Name: Howard Chu
Version: 2.4
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (76.168.84.21)
Submitted by: hyc
Performing a search as rootDN with both an explicit sizelimit and pagedresults
causes the sizelimit to be ignored. Using the sizelimit and no pagedresults
correctly honors the specified limit.
This may also affect RE23, I haven't looked.
15 years, 10 months
Re: (ITS#5227) old dsn acceptance
by hyc＠symas.com
aej(a)wpi.edu wrote:
> Full_Name: Allan E. Johannesen
> Version: 2.4.6
> OS: Linux EL 4
> URL: http://users.wpi.edu/~aej/schema_init.diff
> Submission from: (NULL) (130.215.24.208)
>
>
> Old CSN stamps are not accepted by 2.4.6. I guess they must be _very_ old,
> since there is a "2/3" CSN conversion in the release.
>
> The stamps are of the form: YYYYMMDDHH:MM:SSZ
That's the format from when CSNs were introduced in OpenLDAP 2.1.
> Perhaps I'm the only person in the OpenLDAP universe who might see this problem,
> but I adapted the 2/3 conversion for these old fields.
It seems a bit odd to be introducing support for that format now in 2.4, when
it was completely unsupported in 2.2 and 2.3. I.e., why wasn't this issue
raised during the migration to/thru either 2.2 or 2.3?
I'm inclined to reject this patch; you can fix it in LDIF using sed or perl
and never have to think about it again.
--
-- 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/
15 years, 10 months
Re: (ITS#5229) `make install' writes to the source tree as root
by hyc＠symas.com
mills(a)cc.umanitoba.ca wrote:
> Full_Name: Gary Mills
> Version: openldap-2.3.38
> OS: Solaris 9
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (24.78.105.29)
>
>
> The usual procedure is to run `configure' and `make' in the install tree as an
> ordinary user, and then to run `make install' there as root. This install
> procedure
> writes to the install tree as root. In some cases, it actually relinks a
> shared
> library as root. We build on one server and install on another, where the
> install
> tree is mounted read-only. These errors prevent installation in this case.
> Really, it shouldn't be doing relinking at that point, when running as root.
> Perhaps it could do it earlier, during the compile step. I had to do a `make
> install' as root in libraries/liblber on build server and then modify the
> Makefiles
> in libraries/libldap and libraries/libldap_r to link with the installed
> library,
> in order to avoid the relink on the install server. This worked, but is not a
> good solution.
Agreed, it should not be relinking, ever, but that's libtool. I've submitted
patches to libtool to correct this a number of times over the past several
years but the problem remains, and it's our policy to avoid using customized
OpenLDAP-specific versions of the GNU tools so we no longer provide patched
versions of libtool in our CVS.
In the meantime, there's no reason for this to be affecting your source tree.
You can always build using an object tree separate from the source tree. And
you can always use "make install DESTDIR=/tmp/foo" on the build system to
create an alternate hierarchy that can then be copied to any other machine.
Since there is no fundamental bug in OpenLDAP here, this ITS will be closed.
--
-- 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/
15 years, 10 months
