Re: (ITS#7246) Addition of FedFS schema LDIF
by chuck.lever＠oracle.com
It appears that the schema LDIF files shipped with OpenLDAP are strictly for basic LDAP attribute type and object class definitions. Everything else is considered a "user schema," including schemas for implementing a DNS or NIS backend, and so on. It appears to me that FedFS would fall into this latter category, and thus should not be included in the packaged schema.
Comments?
9 years, 10 months
Re: (ITS#7385) back_mdb ENOSPC error returned from mdb_node_add incorrectly
by hyc＠symas.com
marco(a)schirrmeister.net wrote:
> On Sep 18, 2012, at 1:59 PM, hyc(a)symas.com wrote:
>
>> Marco Schirrmeister wrote:
>>> I pulled latest RE24 on Sep 15th and now I get this.
>>>
>>> ...
>>> indexing id=00010d0e
>>> indexing id=00010d0f
>>> 5056de89 => mdb_tool_entry_reindex: txn_commit failed: Unknown error 18446744073709520830 (-30786)
>>
>> That was fixed yesterday in commit 8bb10add2465eee34e79abeaa62011e3e234effb.
>> Please pull RE24 again today and try again, it should all be working fine.
>
> Just tested with latest RE24
>
> indexing id=00010d0e
> indexing id=00010d0f
> 50587b72 => mdb_tool_entry_reindex: txn_commit failed: MDB_PAGE_FULL: Internal error - page has no more space (-30786)
Thanks for your help, this is now fixed in master.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 10 months
Re: (ITS#7405) Improve refint documentation
by hyc＠symas.com
quanah(a)OpenLDAP.org wrote:
> Full_Name: Quanah Gibson-Mount
> Version: 2.4.32
> OS: NA
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (74.196.25.250)
>
>
> As per debian bug#688857:
>
> Modifications made by refint are not replicated. They neither update the
> modification timestamp nor the CSN used for replication. This is serious
> data loss, because the replicas gets out of sync pretty quickly. There
> seems to be no way to recover from this discrepancy without doing a
> complete replication.
>
> While this seems to be known, it is not documented at all in the
> man-pages related to the refint and memberof overlays. Also it violates
> the principle of least surprise, because the changes are not limited to
> operational attributes.
slapo-refint(5) manpage updated in master. slapo-memberof(5) was updated in
2.4.26 (ITS#6915) so at least that part of the bug report is invalid.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 10 months
(ITS#7405) Improve refint documentation
by quanah＠OpenLDAP.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.32
OS: NA
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (74.196.25.250)
As per debian bug#688857:
Modifications made by refint are not replicated. They neither update the
modification timestamp nor the CSN used for replication. This is serious
data loss, because the replicas gets out of sync pretty quickly. There
seems to be no way to recover from this discrepancy without doing a
complete replication.
While this seems to be known, it is not documented at all in the
man-pages related to the refint and memberof overlays. Also it violates
the principle of least surprise, because the changes are not limited to
operational attributes.
9 years, 10 months
(ITS#7404) back-ldap connection cache error
by hyc＠OpenLDAP.org
Full_Name: Howard Chu
Version: RE24/master
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (37.19.96.255)
Submitted by: hyc
back-ldap resets the local DN of a connection after a Bind request, even if the
Bind failed. Subsequent operations for that DN will reuse this connection, even
though it hasn't bound successfully. This is clearly wrong.
9 years, 10 months
(ITS#7403) back-ldap idassert always overrides
by hyc＠OpenLDAP.org
Full_Name: Howard Chu
Version: RE24/master
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (37.19.96.255)
Submitted by: hyc
If an idassert-bind directive has been configured, idassert processing is always
performed, even if a direct bind has occurred. In effect, back-ldap always
behaves as if flags=override was set in the idassert configuration. This is not
the documented or intended behavior. A fix is coming shortly.
9 years, 10 months
RE: (ITS#7401) OpenLDAP 2.4.32 - deadlock issues
by quanah＠zimbra.com
--On Tuesday, September 25, 2012 4:22 PM +0000 vb4607(a)att.com wrote:
> Thank you so much for the quick reply. We are a bit hesitant to try
> 4.7.25 as it is a 4 year old product. What about version 5.1 (5.1.29) as
> it is mentioned on your Web site
> (http://www.openldap.org/software/release/readme.html)?
I've been using BDB 4.7.25 (+all patches) for several years, and it has
been quite stable. No deadlocks. This version is used on all Zimbra
deployments across the world, with plenty of customers having millions of
entry DBs.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
9 years, 10 months
RE: (ITS#7401) OpenLDAP 2.4.32 - deadlock issues
by vb4607＠att.com
Thank you so much for the quick reply. We are a bit hesitant to try 4.7.25 as it is a 4 year old product. What about version 5.1 (5.1.29) as it is mentioned on your Web site (http://www.openldap.org/software/release/readme.html)?
Sincerely,
Venkatesh
-----Original Message-----
From: Howard Chu [mailto:hyc@symas.com]
Sent: Tuesday, September 25, 2012 11:19 AM
To: BAGLODI, VENKATESH
Cc: openldap-its(a)openldap.org
Subject: Re: (ITS#7401) OpenLDAP 2.4.32 - deadlock issues
vb4607(a)att.com wrote:
> Full_Name: Venkatesh Baglodi
> Version: 2.4.32
> OS: Red Hat Enterprise Linux Server release 5.5
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (144.160.226.53)
>
>
> We have been facing occasional deadlock issues when using OpenLDAP in
> multi-master mode (4 servers). It looks like deadlocks are occuring on
> objectClass index (eq). We have been using OpenLDAP 2.4.32 with hdb backend
> (BerkelyDB v5.3.21) on Red Hat Enterprise Linux Server release 5.5 (Tikanga). We
> tried to upload the DB stat reports on ftp.openldap.org/incoming/, but looks
> like the server is out of disk space. Some of the traces are provided below:
Your traces look much the same as ITS#7378. However, as noted in followup#4 to
that report, there's no code path in back-bdb/hdb that can legitimately cause
this situation. Can you switch to BDB 4.7.25 and still reproduce the problem?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 10 months
(ITS#7402)
by agarcia＠tempel.es
This is a multi-part message in MIME format.
--------------080808010700020804030601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
And sldapd change the shema
from:
attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' )
DESC 'RFC2256: ISO-3166 country 2-letter code'
SUP name SINGLE-VALUE )
to :
# RFC 4519 definition ('countryName' in X.500 and RFC2256)
attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' )
DESC 'RFC4519: two-letter ISO-3166 country code'
SUP name
SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
SINGLE-VALUE )
Thanks a lot for your quick reply, c=Net is not really Country (just a
TLD) but I used it in previous slapd version a worked well!
Thanks
--------------080808010700020804030601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Calibri">And sldapd change the shema <br>
<br>
from:<br>
<br>
</font>
<blockquote><font face="Calibri">attributetype ( 2.5.4.6 NAME ( 'c'
'countryName' )</font><br>
<font face="Calibri"> DESC 'RFC2256: ISO-3166 country
2-letter code'</font><br>
<font face="Calibri"> SUP name SINGLE-VALUE )</font><br>
</blockquote>
<font face="Calibri"><br>
to :<br>
</font>
<blockquote><font face="Calibri"># RFC 4519 definition
('countryName' in X.500 and RFC2256)</font><br>
<font face="Calibri">attributetype ( 2.5.4.6 NAME ( 'c'
'countryName' )</font><br>
<font face="Calibri"> DESC 'RFC4519: two-letter ISO-3166
country code'</font><br>
<font face="Calibri"> SUP name</font><br>
<font face="Calibri"> SYNTAX 1.3.6.1.4.1.1466.115.121.1.11</font><br>
<font face="Calibri"> SINGLE-VALUE )</font><br>
</blockquote>
<font face="Calibri"><br>
Thanks a lot for your quick reply, c=Net is not really Country
(just a TLD) but I used it in previous slapd version a worked
well! <br>
<br>
Thanks<br>
<br>
</font>
</body>
</html>
--------------080808010700020804030601--
9 years, 10 months
