openldap-devel

openldap-devel@openldap.org

1416 discussions

Re: Guide PDF changes
by Kari Mattsson 20 Aug '07

20 Aug '07

Gavin Henry wrote: > > Should we change the outputed PDF to be called: > > OpenLDAP-Admin-Guide.pdf Yes. > or are you really happy with just: > > guide.pdf No. > Do we need to do for htmldoc: > > --size a4 > > Or do we want to stick with Letter? > > You can change this prior to print anyway. Maybe you should choose the smaller paper size? I've had some success by creating hybrid paper size of A4 width (210 mm), and Letter height (some inches). That is, take the smaller values of both. That way the printers (atleast some) seem to be happier. Most new printers seem to be able to scale between A4 and Letter. Ciao, Michael. //Kari

3 2

Guide PDF changes
by Gavin Henry 18 Aug '07

18 Aug '07

Dear All, I've changed the TOC depth to match the html of 3. Looks much nicer. Should we change the outputed PDF to be called: OpenLDAP-Admin-Guide.pdf or are you really happy with just: guide.pdf Do we need to do for htmldoc: --size a4 Or do we want to stick with Letter? You can change this prior to print anyway. For now I'm committing a toc of 3. Please let me know your thoughts on the rest. Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

5 7

librewrite or PCRE
by Gavin Henry 17 Aug '07

17 Aug '07

Dear All, I think I'm going to answer my own question, but what would I gain (except the obvious power of Perl regex's) in using PCRE over librewrite? For slapo-valregex should I just stick with our own librewrite? I think it's probably best not to introduce a new requirement. Your thoughts are welcome. Thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

2 2

BerkeleyDB versions
by Howard Chu 16 Aug '07

16 Aug '07

OK, so 4.6.18 changes the lock management system in ways that are incompatible with previous releases. The advice from Oracle is to just use a read-only transaction (which is actually what we used to do, several revisions back). Of course with BDB 4.2 that causes the problem of log files staying open unless you apply the patch I wrote for that issue. It seems we may need to either resurrect that patch (it should still be in CVS) or drop support for DB 4.2 so we can rewrite the lock management (yet again) to support DB 4.6. Our early tests with DB 4.6.1 thru 4.6.3 showed impressive performance gains, making it seem worthwhile. But we have no way of knowing how the current 4.6.18 will perform at the moment. -- -- 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/

8 21

tab-width (was: commit: ldap/servers/slapd backend.c bconfig.c proto-slap.h)
by Hallvard B Furuseth 16 Aug '07

16 Aug '07

ando(a)OpenLDAP.org writes: > Modified Files: > backend.c 1.384 -> 1.385 Just noticed your indentation... Note that OpenLDAP code looks best when edited and displayed with tab-width 4, not 8. -- Hallvard

3 3

Re: commit: ldap/servers/slapd/back-ldif ldif.c
by Pierangelo Masarati 16 Aug '07

16 Aug '07

hallvard(a)OpenLDAP.org wrote: > Log Message: > Fix rev 1.68 spew_entry() for ITS#4627: Do not dereference NULL save_errnop. > Add missing unlink(). Update debug messages, move one from spew_file(). > Also check the close() return code. ... you're still using *save_errnop without testing if it's not NULL. Fixing. 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 ---------------------------------------

2 1

Re: commit: ldap/servers/slapd/overlays pcache.c
by Pierangelo Masarati 13 Aug '07

13 Aug '07

ando(a)OpenLDAP.org wrote: > provide an interface to remove a set of entries from the cache The rationale behind this is that, for bandwidth occupation issues, we need to cache frequent proxied searches that retrieve very large objects. For this reason, we want relatively long TTL, but we also need to be very tight on updates on the remote server. For this purpose, I'm designing a layer based on the ldap_sync API (RFC 4533) that performs a persistent search looking for changes on the modifyTimestamp of the sensitive objects (small data that always gets modified, to be conservative) and, in case, removes those objects from the cache in a consistent manner. If this feature works as intended, and is considered useful, I can commit it (maybe it could become an integral part of pcache...). 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 ---------------------------------------

2 2

Re: commit: ldap/doc/man/man5 slapd-bdb.5
by Gavin Henry 11 Aug '07

11 Aug '07

<quote who="hyc(a)OpenLDAP.org"> > Update of /repo/OpenLDAP/pkg/ldap/doc/man/man5 > > Modified Files: > slapd-bdb.5 1.36 -> 1.37 > > Log Message: > Add dncachesize A new one for the tuning section. Will add soon. Also, in the e-mail titled "Maximum size of the database." - What is the maximum size of the database that OpenLDAP can support ? - What is the maxmum number of dns it can hold ? For the Tuning section and General info in out Guide, how does someone calculate the above? I'm interested as you said, "For a machine with 4GB of RAM I think it will max out at around 1-2 million DNs." What is the rule of thumb for above? Thanks, Gavin.

2 2

pcache response too early?
by Pierangelo Masarati 11 Aug '07

11 Aug '07

As far as I understand, pcache response takes care of caching searches __before__ sending the searchDone response to the client. This occasionally causes noticeably longer response times when large entry sets are being cached (in my case, bunches of certification authorities with very large CRLs). I wonder if it would make sense, or otherwise somehow conflict with the current design, to cache entries __after__. This could be done, for example, during cleanup. 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 ---------------------------------------

1 0

Re: commit: ldap/servers/slapd syncrepl.c
by Howard Chu 10 Aug '07

10 Aug '07

ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > syncrepl.c 1.333 -> 1.334 > > Log Message: > syncrepl searchbase must be within the database naming context (ITS#5073) This commit seems to have broken test048 in HEAD. I think it would be sufficient to use dnSuffix instead of select_backend() for this test. -- -- 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/

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel