<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.network.openldap.general">
    <title>gmane.network.openldap.general</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46677"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46676"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46675"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46674"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46673"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46672"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46671"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46670"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46669"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46668"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46667"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46666"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46665"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46664"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46663"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46662"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46661"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46660"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46659"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/46658"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46677">
    <title>Re: Shutdown of the OpenLDAP-Software list in favor of theOpenLDAP-Technical list</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46677</link>
    <description>&lt;pre&gt;
On May 24, 2010, at 11:07 AM, OpenLDAP Project wrote:


As there have been no discussions on the OpenLDAP-Software since its shutdown was announced, keeping this list open any longer is unnecessary.

This is list is now closed and will be completely shutdown.  See you on OpenLDAP-technical.

&lt;/pre&gt;</description>
    <dc:creator>OpenLDAP Project</dc:creator>
    <dc:date>2010-05-28T19:30:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46676">
    <title>Shutdown of the OpenLDAP-Software list in favor of theOpenLDAP-Technical list</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46676</link>
    <description>&lt;pre&gt;The Project has decided to shutdown the OpenLDAP-Software list in favor of the more broadly chartered OpenLDAP-Technical list.  This change is intended to eliminate a significant burden upon the list moderators (OpenLDAP-Software list, unlike the OpenLDAP-Technical list, has long had a narrow charter and strict moderation policy).

On May 29th, all new threads will be rejected by the moderator with a note to take them to the OpenLDAP-technical list.  A week will be given for active threads to be concluded (or moved to the openldap-technical list).   On June 5th, the list will be shutdown.  Archives will remain available.

Subscribers of the OpenLDAP-Software list will NOT automatically be subscribed to the OpenLDAP-Technical list.  Each person who wishes to follow the openldap-technical list must subscribe themself to the openldap-technical list.

&lt;/pre&gt;</description>
    <dc:creator>OpenLDAP Project</dc:creator>
    <dc:date>2010-05-24T18:07:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46675">
    <title>Re: Extra character when using search filter but won't appear in the search result</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46675</link>
    <description>&lt;pre&gt;Got it.

Thanks for the help! =)

On Fri, May 21, 2010 at 20:45, &amp;lt;masarati&amp;lt; at &amp;gt;aero.polimi.it&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>Wan Mohd Khairi Wan Mohamed</dc:creator>
    <dc:date>2010-05-22T05:36:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46674">
    <title>Re: Extra character when using search filter but won't appear in the search result</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46674</link>
    <description>&lt;pre&gt;

We have this line in slapd.conf.

index   customAttribute  pres,eq

Is this not automatic indexing? Or is it just specifying which attribute to
index when running slapindex?




I think so. That means, doing ldapmodify when ldap is running live will
automatically re-index the attribute?


Thanks for the help!

Regards,
Wan Mohd Khairi Wan Mohamed
wankhairi [at] nervesis [dot] com [dot] my
http://www.nervesis.com.my
&lt;/pre&gt;</description>
    <dc:creator>Wan Mohd Khairi Wan Mohamed</dc:creator>
    <dc:date>2010-05-21T09:02:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46673">
    <title>Re: Extra character when using search filter but won't appear in the  search result</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46673</link>
    <description>&lt;pre&gt;

man slapd.conf(5):

   (about index settings)
   ...
   Note: Indexing support depends on the particular backend in use.  Also,
   changing  these  settings  will  generally require deleting any indices
   that depend on these parameters and recreating them with  slapindex(8).
   ...

man slapd-bdb(5):

   (about the index directive)
   ... Note:   changing   index  settings  in
   slapd.conf(5) requires  rebuilding  indices,  see  slapindex(8);
   changing index settings dynamically by LDAPModifying "cn=config"
   automatically causes rebuilding of the indices online in a back-
   ground task.

Could it be any clearer?

p.




&lt;/pre&gt;</description>
    <dc:creator>masarati&lt; at &gt;aero.polimi.it</dc:creator>
    <dc:date>2010-05-21T12:45:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46672">
    <title>Re: Extra character when using search filter but won't appear inthe search result</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46672</link>
    <description>&lt;pre&gt;
Anything wrong with ownership/permission of the database files?

http://www.openldap.org/faq/data/cache/136.html


No.

Ciao, Michael.

&lt;/pre&gt;</description>
    <dc:creator>Michael Ströder</dc:creator>
    <dc:date>2010-05-21T09:18:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46671">
    <title>Re: Need help syncing with syncrepl 2.3</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46671</link>
    <description>&lt;pre&gt;Hi Buchan - I updated the limits statement to the following:

limits dn.exact="cn=Replicator,dc=swa,dc=com"
    size=unlimited
    time=unlimited

and now it appears to be working as expected!

On a side note, I never received a "Size limit exceeded" using the same parameters from the syncrepl configuration (I'm under 500 entries).

Thanks!

Rafael

Below is the new output after a synchronization:

May 20 22:16:06 admin-agis01 last message repeated 3 times
May 20 22:16:48 admin-agis01 slapd2.3[32501]: do_syncrep2: rid 001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET 
May 20 22:16:48 admin-agis01 slapd2.3[32501]: syncrepl_del_nonpresent: rid 001 be_delete uid=dyrnaesd,ou=Software Applications,dc=swa,dc=com (0) 
May 20 22:16:48 admin-agis01 slapd2.3[32501]: syncrepl_entry: rid 001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 
May 20 22:16:48 admin-agis01 slapd2.3[32501]: syncrepl_entry: rid 001 be_search (0) 
May 20 22:16:48 admin-agis01 slapd2.3[32501]: syncrepl_entry: rid 001 cn=users,ou=groups,dc=swa,dc=com 
May 20 22:16:48&lt;/pre&gt;</description>
    <dc:creator>L. B.</dc:creator>
    <dc:date>2010-05-20T22:27:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46670">
    <title>Re: LDAPS connection failing with a "TLS accept failure error -1"</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46670</link>
    <description>&lt;pre&gt;Hi Dieter,

Thanks for the reply,

This server was only for testing purposes, so, that's why I used a
self-signed certificate.

I got it working, the issue, as stupid as it is, was that I was editing the
wrong ldap.conf file (Mac OSX has one on /etc/openldap and other on
/opt/local/etc/openldap, which was the one being used).

Marcelo.

On Thu, May 20, 2010 at 3:09 AM, Dieter Kluenter &amp;lt;dieter&amp;lt; at &amp;gt;dkluenter.de&amp;gt;wrote:

&lt;/pre&gt;</description>
    <dc:creator>Marcelo de Moraes Serpa</dc:creator>
    <dc:date>2010-05-20T16:03:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46669">
    <title>RE: LDAP performance slow intermittently</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46669</link>
    <description>&lt;pre&gt;________________________________________
From: openldap-software-bounces+dburklan=nmdp.org&amp;lt; at &amp;gt;OpenLDAP.org [mailto:openldap-software-bounces+dburklan=nmdp.org&amp;lt; at &amp;gt;OpenLDAP.org] On Behalf Of Khoa Nguyen
Sent: Wednesday, May 19, 2010 4:43 PM
To: openldap-software&amp;lt; at &amp;gt;openldap.org
Subject: LDAP performance slow intermittently

My LDAP server (version 2.3.43) performance is quite erratic; for a few minutes, search operations are lightning fast, and then it slows down to several seconds for a single search, and then it is fast again, etc.

I am not sure how to troubleshoot/determine the root cause of this intermittent problem. Any suggestions are appreciated.

Khoa
-----------------------------------------

Are you searching for the same entries each time? What exactly are you searching for? Are the entries that you are searching for indexed? What are the specs of the server? Is the box heavily loaded?

Dan

&lt;/pre&gt;</description>
    <dc:creator>Dan Burkland</dc:creator>
    <dc:date>2010-05-20T13:21:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46668">
    <title>Re: slapd read-only slave replica</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46668</link>
    <description>&lt;pre&gt;
Whether or not indexes make sense is not dependant on whether the LDAP service 
is a provider or consumer or not, but dependent on what searches the LDAP 
service serves.

For example, if a provider only provides writes and changes to consumers, but 
no searches from clients, it only makes sense to index attributes required for 
replication. If a consumer is run purely for making offline backups of the 
master (e.g. by slapcat), and serves no searches, it may also make sense to 
index only replication attributes.


While a replica doesn't accept any changes from clients, it will write just as 
much as it's provider does on the same dataset, or it isn't doing a good job 
of replicating.

Typically, one normally configures the environment to direct read operations to 
slaves, so typically they have a higher read/write ratio, and it makes sense 
to have more indexes on slaves (the additional write IO for maintaining 
indexes is justified).

Regards,
Buchan


&lt;/pre&gt;</description>
    <dc:creator>Buchan Milne</dc:creator>
    <dc:date>2010-05-20T12:12:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46667">
    <title>Syncrepl has deleted over 50%</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46667</link>
    <description>&lt;pre&gt;Hi!

    Syncrepl has decided make a cleaner in my consumer  this night. In 
aprox. 2 hours it has deleted over 50% of my directory ... of course 
it's a wrong, but i havent't idea about why.

    I have installed Openldap 2.4.19 in my producer (master) and in my 
consumer (slave).

   My config:
    syncrepl rid=001
    provider=ldap://xxxxxxx
    type=refreshAndPersist
    searchbase="o=xxxxxx"
    schemachecking=off
    attrs="*,+"
    retry="30 10 600 20"
    binddn="uid=syncrepl,o=xxxxx"
    credentials=xxxx


   In log file


First ... about 1 hour ..

May 20 03:32:06 ldap03 slapd[29549]: syncrepl_entry: rid=001 
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
May 20 03:32:06 ldap03 slapd[29549]: syncrepl_entry: rid=001 be_search (0)
May 20 03:32:06 ldap03 slapd[29549]: syncrepl_entry: rid=001 
uid=600000790,ou=UNIVERSIDAD DE 
MAYORES,ou=Alumnos,ou=Gente,o=Universidad Carlos III,c=es
May 20 03:32:06 ldap03 slapd[29549]: slap_queue_csn: queing 0x293d230 
20100520013206.383048Z#000000#000#000000
May 20 03:32:06 &lt;/pre&gt;</description>
    <dc:creator>Nacho Díaz Asenjo</dc:creator>
    <dc:date>2010-05-20T10:09:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46666">
    <title>Re: Extra character when using search filter but won't appear in the search result</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46666</link>
    <description>&lt;pre&gt;Yes, indeed this is our case. I had to manually slapindex, then only we got
the correct result (even though we have specified the attribute to index
automatically in slapd.conf).

However, do we have to slapindex nightly since this is a case, or is this a
bug (we're using openldap 2.4.19)?

Thanks.

Regards,
Wan Mohd Khairi Wan Mohamed
wankhairi [at] nervesis [dot] com [dot] my
http://www.nervesis.com.my


On Sat, May 15, 2010 at 10:40, &amp;lt;masarati&amp;lt; at &amp;gt;aero.polimi.it&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>Wan Mohd Khairi Wan Mohamed</dc:creator>
    <dc:date>2010-05-20T08:08:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46665">
    <title>Re: LDAP performance slow intermittently</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46665</link>
    <description>&lt;pre&gt;--On Wednesday, May 19, 2010 5:42 PM -0400 Khoa Nguyen 
&amp;lt;khoa.coffee&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:


Your email is very vague, for example, no idea what backend you are using 
(hdb/bdb/sql, etc).  But generally I would check the cachesize &amp;amp; 
idlcachesize setting in slapd.conf, and I would ensure I have a properly 
configured DB_CONFIG file if it is back-bdb or back-hdb.

--Quanah


--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration

&lt;/pre&gt;</description>
    <dc:creator>Quanah Gibson-Mount</dc:creator>
    <dc:date>2010-05-20T14:57:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46664">
    <title>Re: LDAP performance slow intermittently</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46664</link>
    <description>&lt;pre&gt;

It is hard to tell, but from my experience there are four or five main
reasons:
- insufficient memory,
- inadequate file system, 
- lack of appropriate indexes,
- transaction logs, database and syslog on the same disk,
- network failures,
- misconfigured clients.

-Dieter

&lt;/pre&gt;</description>
    <dc:creator>Dieter Kluenter</dc:creator>
    <dc:date>2010-05-20T14:55:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46663">
    <title>Re: slapd read-only slave replica</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46663</link>
    <description>&lt;pre&gt;--On Wednesday, May 19, 2010 11:02 PM +0200 DT Piotr Wadas &amp;lt;pwadas&amp;lt; at &amp;gt;dtpw.pl&amp;gt; 
wrote:


Indexing attributes has to do with how the slave is queried.  So, it 
depends how well you want the replica to perform while it is being "read". 
If you have no clients that query the replica, then I agree, there is no 
reason to index anything on it.  I will note that syncrepl itself acts as 
an internal client, and there are some indices on the replica that help 
sync replication perform more quickly.  But how badly you want to slow your 
replica down is of course entirely up to you. :)

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration

&lt;/pre&gt;</description>
    <dc:creator>Quanah Gibson-Mount</dc:creator>
    <dc:date>2010-05-20T14:55:43</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46662">
    <title>Re: slapd read-only slave replica</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46662</link>
    <description>&lt;pre&gt;
Indexes speed up reads and slow down writes.  That's why they are
especially useful on replicas.

p.


&lt;/pre&gt;</description>
    <dc:creator>masarati&lt; at &gt;aero.polimi.it</dc:creator>
    <dc:date>2010-05-20T13:29:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46661">
    <title>Re: Extra character when using search filter but won't appear in the  search result</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46661</link>
    <description>&lt;pre&gt;
How do you specify automatic attribute indexing in slapd.conf?  I didn't
know about that.


Apparently, you ran slapindex without even reading the man page.  It
*must* be run when you change indexes in slapd.conf, and only in that
case.  And slapd *must not* be running when you run slapindex (it
complains and refuses to start, otherwise, as far as I know).

Or, if you modify indexes using ldapmodify in cn=config, re-indexing will
be automatical, no need to run slapindex.  Is this what you meant?

p.


&lt;/pre&gt;</description>
    <dc:creator>masarati&lt; at &gt;aero.polimi.it</dc:creator>
    <dc:date>2010-05-20T13:27:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46660">
    <title>Re: LDAPS connection failing with a "TLS accept failure error -1"</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46660</link>
    <description>&lt;pre&gt;
[...]
[...]

This is not the proper way to create a certificate chain.
1. create a certificate authority
2. create a server certificate
3. sign the server certificate with the CA
4. extract the password from server certificate into a key

You may use tinyCA to create the chain
http://tinyca.sm-zone.net/index.html

-Dieter

&lt;/pre&gt;</description>
    <dc:creator>Dieter Kluenter</dc:creator>
    <dc:date>2010-05-20T08:09:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46659">
    <title>Re: cn=config and DB_CONFIG</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46659</link>
    <description>&lt;pre&gt;
If you ldapmodify via cn=config the DB environment will be closed and 
re-opened to make the new settings take effect.

&lt;/pre&gt;</description>
    <dc:creator>Howard Chu</dc:creator>
    <dc:date>2010-05-20T07:31:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46658">
    <title>LDAP performance slow intermittently</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46658</link>
    <description>&lt;pre&gt;My LDAP server (version 2.3.43) performance is quite erratic; for a few
minutes, search operations are lightning fast, and then it slows down to
several seconds for a single search, and then it is fast again, etc.

I am not sure how to troubleshoot/determine the root cause of this
intermittent problem. Any suggestions are appreciated.

Khoa
&lt;/pre&gt;</description>
    <dc:creator>Khoa Nguyen</dc:creator>
    <dc:date>2010-05-19T21:42:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/46657">
    <title>slapd read-only slave replica</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/46657</link>
    <description>&lt;pre&gt;
Hello,

Does it make any sens to enable indexing of any attribute on read-only 
slave syncrepl replica? I mean, isn't it just waste of resources, or, 
actually, is not a waste a resources at all, since replica is read-only 
and does not write anything anyway? This, I think, apply to any version of 
openldap.

Regards,
DT

&lt;/pre&gt;</description>
    <dc:creator>DT Piotr Wadas</dc:creator>
    <dc:date>2010-05-19T21:02:57</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.network.openldap.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.network.openldap.general</link>
  </textinput>
</rdf:RDF>

