Full_Name: Gavin Henry
Version: 2.4.6
OS: F8
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.159.59.85)
Note to self about man page missing any cn=config examples, for example:
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: {2}auditlog.la
dn: olcOverlay=auditlog,olcDatabase={1}hdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcAuditLogConfig
olcOverlay: auditlog
dn: olcOverlay={0}auditlog,olcDatabase={1}hdb,cn=config
changetype: modify
add: olcAuditlogFile
olcAuditlogFile: /tmp/auditlog.ldif
Nothing noting the format of olcAuditlogFile, i.e. /tmp or file:///tmp
Feature request:
New config setting to define mode. At the moment it's 0644
Thanks.
Full_Name: Pierre
Version: 2.4.6
OS: GNU/Linux
URL:
Submission from: (NULL) (82.224.217.20)
[...]
checking number of arguments of ctime_r... 2
checking number of arguments of gethostbyname_r... 6
checking number of arguments of gethostbyaddr_r... 8
checking db.h usability... no
checking db.h presence... no
checking for db.h... no
configure: error: BDB/HDB: BerkeleyDB not available
I have Berkeley DB 4.6.21 installed
hyc(a)symas.com wrote:
>> There have been at least 10 syncrepl-related fixes in 2.3 since 2.3.32,
>> with substantial bug fixes and improvements. Please update and check if
>> the issue has been already fixed.
>
> This works as designed. The identity that the syncrepl consumer uses to
> retrieve results must have sufficient privilege to retrieve a complete set of
> results.
Right, I probably misunderstood the question. If it was related to the
"sizelimit" option of the "syncrepl" statement, as far as I understand,
that parameter sets the amount of data the consumer is willing to
replicate, in case one wants to set up a partial replica. It must be
set to "unlimited" (i.e. no "sizelimit" used) to replicate as much as
possible of the producer. In the latter case, the amount of data a
consumer can get depends on the size limit the producer is willing to
return. For this purpose, the identity used by the consumer must have
no size limits to work correctly. A "limits" statement that sets the
size limit to "unlimited" for a "who" clause that includes the
consumer's replication identity should be used.
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
---------------------------------------
ando(a)sys-net.it wrote:
> There have been at least 10 syncrepl-related fixes in 2.3 since 2.3.32,
> with substantial bug fixes and improvements. Please update and check if
> the issue has been already fixed.
This works as designed. The identity that the syncrepl consumer uses to
retrieve results must have sufficient privilege to retrieve a complete set of
results.
--
-- 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/
There have been at least 10 syncrepl-related fixes in 2.3 since 2.3.32,
with substantial bug fixes and improvements. Please update and check if
the issue has been already fixed.
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
---------------------------------------
There's a difference between the two:
"sizelimit" is DSA-wide; "limits" are per-database and per "who" clause.
This is reflected in the man page by the respective location of the
statements in the "GLOBAL CONFIGURATION OPTIONS" and in the "GENERAL
DATABASE OPTIONS".
Of course, if "sizelimit" overrides a "limits" for a client identity
matching the "who" clause of that "limits" on a search spanning the
database the "limits" was defined for, then it's a bug.
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
---------------------------------------
ando(a)sys-net.it wrote:
> Current 2.3 release is 2.3.32; please do not report bugs for older
> releases, as chances are they're already fixed.
I meant: current is 2.3.39, while you reported a bug for 2.3.32.
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
---------------------------------------
Current 2.3 release is 2.3.32; please do not report bugs for older
releases, as chances are they're already fixed.
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: Ulrich Windl
Version: 2.3.32
OS: SLES10 SP1
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (132.199.156.178)
I'm unsure about the concept, but documentation is unclear anyway: For a
syncreply configuration using RefreshAndPersist, the initial sync is incomplete
if the whole database cannot be transferred in one attempt. When restarting the
consomer, the same entries that had been transferred before are transferred
again, and the consumer will never complete synchronization. Is it concept or a
bug that upon initial sync the whole database must be transferred in one search
result? If it's so, almost any sizelimit below "unlimited" is dangerous (that is
the number of database entries effectively must be the sizelimit).
Full_Name: Ulrich Windl
Version: 2.3.32
OS: SLES10 SP1
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (132.199.156.178)
The man page for slapd.conf leaves the impression that a "size=unlimited" within
a "limits" statement allows any size to be transferred. However it seems that
one may only lower the "sizelimit" (default 500) using "limits". The man page
doesn't say so.