[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:


clearly shows:


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


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:


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


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:


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

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 ' 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
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
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.


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


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 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