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