I sent this two days ago, from an unsubscribed account and it still hasn't shown up... don't know if moderation is hampered, or if it just didn't make through...
I have the basics covered - 1 master, 4 syncrepl slaves (going to 2-3 MM, 1-2 slaves). This setup has been working quite well - supporting AIX, Linux user data, Samba PDC/BDCs, and Kerberos (slapd 2.4.7 Debian Sid/unstable)
The only issue I have now, is having to find the master to perform any updates.
I'd like to use slapo-chain so that update referrals are automatically handled, especially since so little stuff supports referrals - even things that should.
There are a few examples here and there, and unfortunately, some of them contradict others (probably written to different ldap levels).
As an example of my plight, here is the output of ldappasswd on a slave machine (ldapmodify shows the same issue, but isn't as easy to show)
# # on the slave, when trying a ldappasswd: $ ldappasswd -Ydigest-md5 -w<my passwd> SASL/DIGEST-MD5 authentication started SASL username: renegade SASL SSF: 128 SASL data security layer installed. Result: Referral (10) Referral: ldap://ldap-master.cobpli.svl.ibm.com
# # The following is the slave ldap trace, and there is *no* traffic to the master... conn=0 op=1 BIND authcid="renegade@COBPLI.SVL.IBM.COM" authzid="renegade@COBPLI.SVL.IBM.COM" conn=0 op=1 BIND dn="uid=renegade,ou=users,dc=cobpli,dc=svl,dc=ibm,dc=com" mech=DIGEST-MD5 sasl_ssf=128 ssf=128 conn=0 op=1 RESULT tag=97 err=0 text= conn=0 op=2 EXT oid=1.3.6.1.4.1.4203.1.11.1 conn=0 op=2 PASSMOD conn=0 op=2 RESULT oid= err=10 text=
# # The basics work: $ ldapwhoami SASL/GSSAPI authentication started SASL username: renegade@COBPLI.SVL.IBM.COM SASL SSF: 56 SASL data security layer installed. dn:uid=renegade,ou=users,dc=cobpli,dc=svl,dc=ibm,dc=com
# # Proxy authentication works: $ ldapwhoami -Uproxy -Ydigest-md5 -w<passwd> -Xu:cowboy SASL/DIGEST-MD5 authentication started SASL username: u:cowboy SASL SSF: 128 SASL data security layer installed. dn:uid=cowboy,ou=users,dc=cobpli,dc=svl,dc=ibm,dc=com
# # Here is the likely relevant ldap sections (chain overlay, syncprop, updatref): # overlay chain chain-uri "ldap://ldap-master.cobpli.svl.ibm.com/" # Neither of these lines make a difference chain-rebind-as-user TRUE #chain-rebind-as-user FALSE # Here, I've tried simple/sasl, varied saslmech, etc... chain-idassert-bind bindmethod="simple" saslmech=digest-md5 authz=proxyauthz binddn="uid=proxy,ou=users,dc=cobpli,dc=svl,dc=ibm,dc=com" credentials="<passwd>" mode=self chain-idassert-authzFrom "*"
syncrepl rid=1 provider=ldap://ldap-master.cobpli.svl.ibm.com/ starttls=no binddn="cn=Replicator,ou=DSA,dc=cobpli,dc=svl,dc=ibm,dc=com" bindmethod=simple credentials=<passwd> searchbase="dc=cobpli,dc=svl,dc=ibm,dc=com" schemaChecking=off type=refreshAndPersist retry="10 10 300 +" updateref ldap://ldap-master.cobpli.svl.ibm.com/
Richard Nelson wrote:
I sent this two days ago, from an unsubscribed account and it still hasn't shown up... don't know if moderation is hampered, or if it just didn't make through...
I have the basics covered - 1 master, 4 syncrepl slaves (going to 2-3 MM, 1-2 slaves). This setup has been working quite well - supporting AIX, Linux user data, Samba PDC/BDCs, and Kerberos (slapd 2.4.7 Debian Sid/unstable)
The only issue I have now, is having to find the master to perform any updates.
I'd like to use slapo-chain so that update referrals are automatically handled, especially since so little stuff supports referrals - even things that should.
There are a few examples here and there, and unfortunately, some of them contradict others (probably written to different ldap levels).
Use the example in test018 of the test suite.
If you're looking at docs that aren't from OpenLDAP.org they're most likely wrong or at least out of date. There are a few notable exceptions (symas.com / connexitor.com tend to be pretty good as well ;)
On Sat, 17 May 2008, Howard Chu wrote:
Use the example in test018 of the test suite.
test018 uses a global chain overlay.
Well, using that layout did allow remote updates
However, I need this to be database specific as there are several databases being shadowed/cached (from various parts of the company), but only this one is updatable... Why forward requests to the local master when they are doomed to fail ?
So, I took the working global chain, and tried to make it database specific - and I'm back to square one (failure):
database hdb directory "/var/lib/ldap/cobpli.svl.ibm.com" suffix "dc=cobpli,dc=svl,dc=ibm,dc=com" rootdn "cn=Manager,ou=DSA,dc=cobpli,dc=svl,dc=ibm,dc=com" ... overlay chain chain-uri ldap://ldap-master.cobpli.svl.ibm.com/ chain-idassert-bind bindmethod=simple binddn="cn=Manager,ou=DSA,dc=cobpli,dc=svl,dc=ibm,dc=com" credentials=<password> mode=self ... syncrepl rid=1 provider=ldap://ldap-master.cobpli.svl.ibm.com/ starttls=no binddn="cn=Replicator,ou=DSA,dc=cobpli,dc=svl,dc=ibm,dc=com" bindmethod=simple credentials=<password> searchbase="dc=cobpli,dc=svl,dc=ibm,dc=com" schemaChecking=off type=refreshAndPersist retry="10 10 300 +" updateref ldap://ldap-master.cobpli.svl.ibm.com/
If you're looking at docs that aren't from OpenLDAP.org they're most likely wrong or at least out of date. There are a few notable exceptions (symas.com / connexitor.com tend to be pretty good as well ;)
:)
Richard A Nelson wrote:
On Sat, 17 May 2008, Howard Chu wrote:
Use the example in test018 of the test suite.
test018 uses a global chain overlay.
Well, using that layout did allow remote updates
However, I need this to be database specific as there are several databases being shadowed/cached (from various parts of the company), but only this one is updatable... Why forward requests to the local master when they are doomed to fail ?
So, I took the working global chain, and tried to make it database specific - and I'm back to square one (failure):
referral return when writing to a shadow database is handled by the frontend. That's why the slapo-chain(5) instance needs to be global. That's also the main reason global overlays were introduced at all.
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 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati writes:
referral return when writing to a shadow database is handled by the frontend. That's why the slapo-chain(5) instance needs to be global. That's also the main reason global overlays were introduced at all.
Please put that in the doc. (both slapo-chain and replication docs?) Also slapo-chain's "overlay chain" section which says "it is mainly intended for use with local storage backends". That may be technically correct, but in this context it's misleading.
Hallvard B Furuseth wrote:
Pierangelo Masarati writes:
referral return when writing to a shadow database is handled by the frontend. That's why the slapo-chain(5) instance needs to be global. That's also the main reason global overlays were introduced at all.
Please put that in the doc. (both slapo-chain and replication docs?) Also slapo-chain's "overlay chain" section which says "it is mainly intended for use with local storage backends". That may be technically correct, but in this context it's misleading.
Slapo-chain is intended to work with local databases. For the purpose of allowing transparently writing to a shadow server, it has to be global (for implementation related reasons). This IMHO is reflected in the docs: all examples related to replication are correct, and blame for the fact that people ignore examples in the official documentation cannot be put on the developers, nor on those who wrote the documentation.
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 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati writes:
Hallvard B Furuseth wrote:
Pierangelo Masarati writes:
referral return when writing to a shadow database is handled by the frontend. That's why the slapo-chain(5) instance needs to be global. That's also the main reason global overlays were introduced at all.
Please put that in the doc. (both slapo-chain and replication docs?) Also slapo-chain's "overlay chain" section which says "it is mainly intended for use with local storage backends". That may be technically correct, but in this context it's misleading.
Slapo-chain is intended to work with local databases. For the purpose of allowing transparently writing to a shadow server, it has to be global (for implementation related reasons).
Yes. But the manpage text by itself is misleading: It says the overlay works on local storage backends, so one puts it on database bdb or whatever. Come to think of it, maybe the same applies if one uses the 'referral' directive. Haven't tried.
This IMHO is reflected in the docs: all examples related to replication are correct, and blame for the fact that people ignore examples in the official documentation cannot be put on the developers, nor on those who wrote the documentation.
I'm not interested in blame, but communicating correct information. The replication section doesn't mention chaining. Someone who reads the slapo-chain manpage instead of the admin guide about chaining to the master won't be told.
Maybe there should be a guide to how to read the docs... I saw only one example of this one, in the admin guide's chaining section. But there are a lot of docs to read, with quite a bit of duplication by now. Are people required to read both the admin guide and the manpages? Even admin guide sections which mostly seem to repeat things from manpages, or vice versa? What if you think you know how chaining or whatever works because you read its manpage, but the admin guide mentions a few details the manpages didn't - or vice versa?
Hallvard B Furuseth wrote:
Maybe there should be a guide to how to read the docs... I saw only one example of this one, in the admin guide's chaining section. But there are a lot of docs to read, with quite a bit of duplication by now. Are people required to read both the admin guide and the manpages? Even admin guide sections which mostly seem to repeat things from manpages, or vice versa? What if you think you know how chaining or whatever works because you read its manpage, but the admin guide mentions a few details the manpages didn't - or vice versa?
In my opinion, the manpages are meant to be the exhaustive reference on syntax and features. They should not provide (m)any examples. The Admin Guide is *not* meant to be complete, with respect to available options and syntax. It *should* provide examples for common use cases.
In general, when we add new config keywords, I think it is imperative that they are documented in the manpages. It is unimportant to include them in the Admin Guide, but if you're going to show a use case then it's worth mention.
I strongly dislike the tendency to make the Admin Guide repeat everything that's already in the manpages.
Howard Chu writes:
In my opinion, the manpages are meant to be the exhaustive reference on syntax and features. They should not provide (m)any examples. The Admin Guide is *not* meant to be complete, with respect to available options and syntax. It *should* provide examples for common use cases.
In general, when we add new config keywords, I think it is imperative that they are documented in the manpages. It is unimportant to include them in the Admin Guide, but if you're going to show a use case then it's worth mention.
This sounds good - with one exception: If the documented feature is not too trivial to use I like manpages with an example or two. A glance at them early can provide a mental hook into which to plug the rest of the manpage. They can clarify things if either author or reader didn't get straight, though that may also mean the manpage should be fixed. And I think they are a valid place to sneak in some "admin guide"-like info. Examples of what the documented feature can be used for, and hints about other chatty stuff one doesn't want to waste the reader's time with in the "normative" manpage text.
OTOH I'm fine with calling it a manpage defect if removing an EXAMPLE(S) section would remove information about the documented feature. With a few exceptions, like if the text elsewhere refers to the examples because it'd be too complicated to explain otherwise.
I strongly dislike the tendency to make the Admin Guide repeat everything that's already in the manpages.
I agree.
I wrote:
Howard Chu writes:
I strongly dislike the tendency to make the Admin Guide repeat everything that's already in the manpages.
I agree.
On second thought, that's a bit strong. Some of the duplication is useful. It's good to have the admin guide more or less self-contained, so one can get through read it without referring manpages all the time. And after all the admin guide is edited to be readable and show the "you likely need to know this" parts, while manpages are not selective.
The main problem is that the guide doesn't say what is copied. It would help a lot just to prefix manpage extracts with "From the slapd-foo(5) manual page:", ensure the copy is verbatim, and use another font for it.
I do think too much is copied, but that's secondary.
BTW, another advantage with duplication: The admin guide can be more convenient to _print_ than a bunch of manpages. That's an issue which might be solved in a completely different way though.
On Sun, 18 May 2008, Pierangelo Masarati wrote:
referral return when writing to a shadow database is handled by the frontend. That's why the slapo-chain(5) instance needs to be global. That's also the main reason global overlays were introduced at all.
Ok, so I assume the frontend is matching the referral-uri to the chain-uri to select the proper upstream database
You guys are great, here and in #ldap :)
Thank you (both) Now that this is working, I'll start on the multi-master setup for the core servers.
openldap-technical@openldap.org
-
Hallvard B Furuseth -
Howard Chu -
Pierangelo Masarati -
Richard A Nelson -
Richard Nelson