<?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 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/43848"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/43847"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/43846"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/43845"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/43844"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/43843"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/43842"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/43841"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/43840"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/43839"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/43838"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/43837"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/43836"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/43835"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/43834"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/43833"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/43832"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/43831"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/43830"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.network.openldap.general/43829"/>
      </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/43848">
    <title>Re: openldap server migration issue</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43848</link>
    <description>
It's the same data, so of course if you are typing the wrong password, you'll
get the "Invalid credentials" message. How much clearer can the message be!



</description>
    <dc:creator>Gavin Henry</dc:creator>
    <dc:date>2008-08-30T08:41:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43847">
    <title>Re: olcServerID</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43847</link>
    <description>
Yeah, sounds good. Will add.

</description>
    <dc:creator>Gavin Henry</dc:creator>
    <dc:date>2008-08-30T08:39:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43846">
    <title>Re: olcServerID</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43846</link>
    <description>
I think the man page is concise and precise.  The admin guide could 
benefit from some more detailed explanation, and some examples of the 
case with URI:

&lt;slapd.conf&gt;
serverID 1 ldap://host1.example.com
serverID 2 ldap://host2.example.com
serverID 3 ldap://host3.example.com
&lt;/slapd.conf&gt;

same slapd.conf, different FQDN:

host1.example.com takes ID 1
host2.example.com takes ID 2
host3.example.com takes ID 3

each DSA will generate entryCSNs like

host1.example.com: 20080830094621.123456Z#000000#001#000000
host2.example.com: 20080830094621.123456Z#000000#002#000000
host3.example.com: 20080830094621.123456Z#000000#003#000000

                                              SID ^^^

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
Fax:     +39 0382 476497
Email:   ando&lt; at &gt;sys-net.it
-----------------------------------


</description>
    <dc:creator>Pierangelo Masarati</dc:creator>
    <dc:date>2008-08-30T07:48:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43845">
    <title>Re: OpenLDAP Date</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43845</link>
    <description>...

On the systems that I'm familiar with, /etc/profile is only read by 
interactive shells and not by shells that are running scripts.  If that's 
the case on your system, then the slapd started from a boot-time script 
would not see that setting, because there's no interactive shell in its 
process ancestry.


For Solaris, the TZ variable is set for 'init' via the /etc/TIMEZONE file 
and processes inherit it from init.

For Linux, you normally leave TZ unset and instead make /etc/localtime a 
symlink to the correct file under /usr/share/zoneinfo/.  If you run 
something chrooted then you may need to set up an /etc/localtime file 
inside the chroot if you care about the timezone it uses.



Nope.


Philip Guenther

</description>
    <dc:creator>Philip Guenther</dc:creator>
    <dc:date>2008-08-29T22:24:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43844">
    <title>Re: openldap server migration issue</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43844</link>
    <description>
Why not just slapcat the data from the old server and slapadd it to the new?

What version of OpenLDAP do you have?


"Invalid credentials" means exactly that.

</description>
    <dc:creator>Gavin Henry</dc:creator>
    <dc:date>2008-08-29T19:49:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43843">
    <title>Re: OpenLDAP Date</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43843</link>
    <description>
What does syslog honour?

</description>
    <dc:creator>Gavin Henry</dc:creator>
    <dc:date>2008-08-29T19:40:53</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43842">
    <title>openldap server migration issue</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43842</link>
    <description>Hi,

Can any one please help me in the following issue:

Desc: I am in the process of migrating openldap from one server to antother server.

current openldap server: server1.example.com
new openldap server : server2.example.com

Below is the procedure i have followed to migrate it:

1. setup server2.example.com as replica server of server1.example.com
2. after syncing the DB files , made it as standalone master ldap.

for testing iam using the below commands:

1. when i search for info as Manager it is giving all the information

server2#ldapsearch -x -b 'dc=example,dc=com' -D "cn=Manager,dc=example,dc=com" '(objectclass=*)' -H ldaps://server2.example.com -W

2. But when i try to search as a normal user it is throwing the following error.

server2# ldapsearch -x -b 'dc=example,dc=com' -D "uid=okkamagadu,ou=People,dc=example,dc=com" '(objectclass=*)' -H ldaps://server2.example.com -W
Enter LDAP Password: 
ldap_bind: Invalid credentials (49)                       &lt;&lt;&lt;am i missing any configration,any suggestio</description>
    <dc:creator>Naveen.X1.Sarabu&lt; at &gt;chase.com</dc:creator>
    <dc:date>2008-08-29T15:40:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43841">
    <title>Re: olcServerID</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43841</link>
    <description>
----- "Pierangelo Masarati" &lt;ando&lt; at &gt;sys-net.it&gt; wrote:


Maybe this should be added to the replication section of the admin guide.

The man page is consise:

       serverID &lt;integer&gt; [&lt;URL&gt;]
              Specify an integer ID from 0 to 4095 for this server (limited to 3 hexadecimal digits).  These  IDs  are  required
              when  using multimaster replication and each master must have a unique ID. Note that this requirement also applies
              to separate masters contributing to a glued set of databases.  If the URL  is  provided,  this  directive  may  be
              specified  multiple  times,  providing a complete list of participating servers and their IDs. The fully qualified
              hostname of each server should be used in the supplied URLs. The IDs are used in the "replica  id"  field  of  all
              CSNs generated by the specified server. The default value is zero.  Example:

            serverID 1


</description>
    <dc:creator>Gavin Henry</dc:creator>
    <dc:date>2008-08-29T15:41:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43840">
    <title>Re: olcServerID</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43840</link>
    <description>
The serverID config statement (olcServerID attribute in back-config) is 
used to inform a specific server about its own id within a local 
replication pool.  Without URL, only one occurrence of serverID is 
allowed.  When the URL is specified, multiple occurrences are allowed, 
but only one takes effect: the one whose URL matches the listener of the 
server.  So the URL-qualified multiple occurrences of serverID basically 
allow to share the same configuration within multiple servers of the 
same replication pool, guaranteeing that each server will pick up the 
correct id based on the URL.

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
Fax:     +39 0382 476497
Email:   ando&lt; at &gt;sys-net.it
-----------------------------------


</description>
    <dc:creator>Pierangelo Masarati</dc:creator>
    <dc:date>2008-08-29T14:37:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43839">
    <title>Re: OpenLDAP Date</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43839</link>
    <description>TZ="Europe/London"; export TZ

that's in /etc/profile, and the date shows up correctly as:

Fri Aug 29 11:09:34 BST 2008

Does openldap pull its timezone data from elsewhere.

Regards,

Andy

</description>
    <dc:creator>andylockran</dc:creator>
    <dc:date>2008-08-29T10:11:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43838">
    <title>Re: slapadd bulk load performance issue</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43838</link>
    <description>2008/8/29 Skulj Blaz &lt;b.skulj&lt; at &gt;iskratel.si&gt;


Unless I'm mistaken you've only set aside ~20m for the bdb cache. Adding
another zero might speed things up.
After some tips here, I recently slapadded a directory of about 4 million
entries (LDIF of 2.9GB) in much less than that, using -q. Didn't time or
monitor it closely, but less than a working day for sure.
</description>
    <dc:creator>tamarin p</dc:creator>
    <dc:date>2008-08-29T14:31:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43837">
    <title>olcServerID</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43837</link>
    <description>http://blog.suretecsystems.com/archives/40-OpenLDAP-Weekly-News-Issue-5.html

In the third box of code, this appears to set up the Master node with 3
serverIDs +URLS, when previously it was set up with a single serverID
(which I assumed to be its identifier) is this correct?

I'm running version 2.4.10 on both servers.

Regards,

Andy

</description>
    <dc:creator>andylockran</dc:creator>
    <dc:date>2008-08-29T08:03:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43836">
    <title>unique id required</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43836</link>
    <description>Dear List Members,

OpenLDAP version 2.3.39 on RHEL5

I am using "OpenLDAP " to store information. This information is
retrieved by a "client" and made available to "user" via the
vfs(virtual fire system) interface in linux. The user then
reads/writes/browses the information just like in a filesystem. I can
store a 64-bit id of each entry as inode number in my client.

A "unique id" of size 64-bits is required for each entry so that once
an entry is searched by giving "dn", further searches for the entry
can be done using that unique id.
The unique id must be in some way auto-generated by openldap server.

entryUUID has been identified to fulfills all the requirements except
that it is 128-bit long.

I would like to know if there is some other operational attribute
which is unique for each entry and of size 64-bits?
of if I can extract a 64-bit unique value from entryUUID or any other attribute?
If required the operation can be shifted to some other version of OpenLDAP also.

Arpit J.
Center for Development </description>
    <dc:creator>Arpit Jain</dc:creator>
    <dc:date>2008-08-29T07:29:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43835">
    <title>slapadd bulk load performance issue</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43835</link>
    <description>Hello,

Version OpenLDAP: 2.4.11
OS: Linux Red Hat ES 4.6
Storage: Berkeley DB 4.2 (+4 patches)


I'm testing performance in importing big LDIF file with 2 milions of entries (22.000.000 number of attributes). LDIF file is 600 MB big, one entry looks like this:

dn: itContainerId=20000001,ou=Container,l=example,c=com
objectClass: labeledURIObject
objectClass: itContainerOC
itContainerId: 20000001
itContainerType: 1
itContainerName: ljubljana1
itContainerStatus: 0
itParentContainerId: 3000000
itConfigurationNeeded: FALSE
itSerialNumber: 04
itRegType: 1


I use slapadd tool with -q option :

slapadd -q -f slapd.conf -l 2_milions_of_entry.ldif

and the following configuration settings:

database bdb
dbcachesize 1000000
cachesize 150000
sizelimit 150000
checkpoint      10    1

set_cachesize 0 20000000 0
set_lg_regionmax 262144
set_lg_bsize 2097152


In my case, it takes about 20!!! hours to load the entire LDIF contents. Is this normal? Did anybody has experiences with loading of such amount of data?
Am i perha</description>
    <dc:creator>Skulj Blaz</dc:creator>
    <dc:date>2008-08-29T07:49:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43834">
    <title>Re: OpenLDAP Date</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43834</link>
    <description>
No, there's nothing in slapd that messes with the system clock. Probably you 
have an incorrect TZ or other environment variable when slapd starts.

</description>
    <dc:creator>Howard Chu</dc:creator>
    <dc:date>2008-08-29T05:03:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43833">
    <title>OpenLDAP Date</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43833</link>
    <description>Hi,

I'm in the process of upgrading a 2.3.41 directory up to the 2.4 branch.
 I've got a few virtual machines with which I've been testing and
running syncrepl.

I've successfully 'pulled' all the data out from the old server (2.3)
and that's now in database 1 on my new server.

However, having installed openLDAP on another new server.. the date that
logs are reporting is an hour earlier than the system time.

Is there a configurable run-time option in slapd, to get the date?
I've currently not got monitoring setup.


Regards,

Andy

</description>
    <dc:creator>andylockran</dc:creator>
    <dc:date>2008-08-28T16:07:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43832">
    <title>Re: BDB and cache settings - anything wrong? userPassword field keepsgetting corrupted.</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43832</link>
    <description>
The default hash has always been SSHA.

It sounds like the original poster just doesn't know about base64 values in 
LDIF...

</description>
    <dc:creator>Howard Chu</dc:creator>
    <dc:date>2008-08-29T00:18:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43831">
    <title>Re: BDB and cache settings - anything wrong? userPassword field keepsgetting corrupted.</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43831</link>
    <description>
You dont seem to have an explicit "password-hash" statement that
specifies MD5 hash. Perhaps is defaulting to "password-hash {SSHA}"
which is a salted hash (even if you hash the same value, you get a
different string each time) unlike MD5 which usually gives you the
same hash string output, where the input string is the same.

Probably best to state the password hash type explicitly (assuming you
care), rather than rely on the default, which might change depending
on openldap version / compile options / libraries in the build
environment etc.,

Cheers
Brett

</description>
    <dc:creator>Brett &lt; at &gt;Google</dc:creator>
    <dc:date>2008-08-28T22:19:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43830">
    <title>Re: openldap 2.4.9 dies adding uid of a single character (overlayunique uid)</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43830</link>
    <description>
The above URL just seems to be an archive of OpenLDAP's bug mailing list, the 
mail referenced being:

Subject: (ITS#5511) SIGABRT in slapo-unique when setting uidNumber to 0

However, the OP could have found in the ITS that this appears to have been 
fixed in HEAD/RE24 on 15 May, and the fix should have been in 2.4.10 according 
to the release notes.

Regards,
Buchan

</description>
    <dc:creator>Buchan Milne</dc:creator>
    <dc:date>2008-08-28T11:28:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43829">
    <title>Re: openldap 2.4.9 dies adding uid of a single character (overlayunique uid)</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43829</link>
    <description>Please post replies to the list.

291168&lt; at &gt;telefonica.net wrote:

If people would post OpenLDAP issues to OpenLDAP instead of other, unrelated lists, issues could be resolved faster.
Anyway, I note that since OpenLDAP 2.4.9 there were at least two fixes related to unique overlay, if this is the case.  Did you 
check with the latest release?

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
Fax:     +39 0382 476497
Email:   ando&lt; at &gt;sys-net.it
-----------------------------------


</description>
    <dc:creator>Pierangelo Masarati</dc:creator>
    <dc:date>2008-08-28T11:05:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.network.openldap.general/43828">
    <title>Re: hdb search performance</title>
    <link>http://permalink.gmane.org/gmane.network.openldap.general/43828</link>
    <description>2008/8/26 Howard Chu &lt;hyc&lt; at &gt;symas.com&gt;


Wasn't aware of this parameter, and couldn't find it in the administrator
guide. Tried setting it to about the same as cachesize but it doesn't seem
to have a huge effect. The first time the search runs after server-start-up,
it still takes minutes to complete. Interestingly enough, CPU usage is very
low during this time, below 10%, and even below 5% most of the time. iostat
reports about 3.4% iowait.

Is there a way to verify that my indexes are working properly? As far as I
can tell, they are present. There's an o.bdb and an objectclass.bdb in
/var/lib/ldap. Also using loglevel 256 and not seeing any warnings in the
log about unindexed attributes. I tried running slapindex again but that
doesn't seem to have had any effect.
</description>
    <dc:creator>tamarin p</dc:creator>
    <dc:date>2008-08-28T09:50:44</dc:date>
  </item>
  <textinput 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>
