[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Supplemental information regarding an recent(-ish) post to the openldap mailing list.

--On Thursday, February 12, 2009 7:09 PM -0700 Gary Brubaker <gary.brubaker@microchip.com> wrote:

Hi Gary,

First, I don't know why you are emailing me directly. You should reply to the list. Otherwise, I will assume you are contacting me because you wish to open up a support relationship, at which point I will start billing you at my current rates for the time it takes me to write these emails and any further support you require. Please read: <http://www.eyrie.org/~eagle/faqs/questions.html> to understand the importance of following up emails where they belong. Also, the OpenLDAP foundation already has a location for reporting bugs: <http://www.openldap.org/its>. This includes documentation errors. Thankfully, there are no bugs in your email here, read on to see why.

Second, your email is full of incorrect statements:



I was reading the post, show below, on the mailing list archives, and
thought
you might like to know that this link:

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

clearly shows: 

[snip]

which, as you can plainly see, contains the offending attribute setting:

attrs="*,+"

There is nothing offending about this line in the example. As I said in the email you quote, setting it to attrs="*" is what was broken, not that setting it to attrs="*,+" is what is broken. That value is actually the default value, and quite correct. It can also be omitted so that the default value is used.


Also, this link:

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

Is very important!  The reason for this; my particular problem was solved
from
this link.  In particular, the examples for replication, obtained from:

	http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master

Clearly shows:

	retry="5 5 300 5"

as does the syncrepl statement (shown above) illustrates:

	retry="60 +"

neither of which function as expected.  The actual parameter, which
appears to function
properly is:

	retry="60,+"

NB: It is requisite that a comma (,) be placed between the retry
parameters.  This is
a small but subtle thing which caused me to spend a lot of time trying to
figure out
why replication would only work for the first few moments the server was
up and running
and then never replicate thereafter (even with type=refreshAndPersist
set).


Again, you are incorrect. A comma is *not* needed, and putting in a comma is incorrect. I've always used the retry="[value] [value]+" format, and it has always worked. Perhaps you have any number of problems with your syncrepl statement, which you did not provide.

Even section '5.2.5.8. olcSyncrepl' from the admin guide shows:

	[retry=[<retry interval> <# of retries>]+]

NB: There is a blank space between the interval and the number of
retries, and not a
comma (,) character.


This is because that is the correct usage.

It is unclear to me whether this is a documentation issue or if it is, in
fact,
a bug (not my call).

None the less, it might be worthwhile to either update the documentation,
or declare
this a bug and fix it.

 From all outward appearances you seem to be a significant contributor to
openldap;
it seemed prudent to let you know.

Thank you, in advance, for your time and consideration.

Sure thing. Fortunately, there are no real issues here that need addressing.


--Quanah



--On Tuesday, December 09, 2008 4:45 PM -0500 Justin Lintz
<jlintz@gmail.com> wrote:

     Hi,


     I am currently working on trying to configure replication between 2
     ldap servers.  Here is my current setup....



     slapd.conf on ldap02 is":


     directory       /var/lib/ldap2.4
     checkpoint 256 5
     index   objectClass                                             eq
     index   cn,mail,surname,givenname
     eq,subinitial index
uidNumber,gidNumber,memberuid,member,uniqueMember
     eq index   uid
     eq,subinitial index   sambaSID,sambaDomainName,displayName
     eq referral ldaps://ldap01/
     syncrepl rid=123
       provider=ldaps://ldap01/
       type=refreshAndPersist
       searchbase="dc=example,dc=net"
       scope=sub
       schemachecking=off
       bindmethod=simple
       binddn="cn=manager,dc=example,dc=net"
       attrs="*"
       credentials=


You should specify an attrs= line unless you know what you're doing. You
should just leave it empty and accept the default (which is "*,+" btw).
Right now you are excluding all the operational attrs, so it loses its
ability to track where it is at replication wise. If you can identify
where you got the idea to use that line, that'd be great so we can kill
it, unless of course it came from offsite documentation.

--Quanah


--


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




--

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