Hey Quanah,
Oh no, my question was whether an arbitrary external variable (eg. URI1) could be set (eg. to ldap://host1.hq.mycompany.com:389/) inside an LDIF file and used in subsequent places in the file. (to avoid having to type in the value in multiple places). I suppose not?
Assuming not, I typed in each value into all its relevant places in my LDIF file and re-ran slapadd. Now it gives me the following error (on latest redhat 64bit): loaded module syncprov.la *module syncprov.la: null module registered*
Surely the above message signifies an error?
Anyway, processing continues until it gives the following final error:
dnPrettyNormal: <cn=config>
<<< dnPrettyNormal: <cn=config>, <cn=config> *<= str2entry: str2ad(changetype): attribute type undefined* slapadd: could not parse entry (line=48)
Could you please advise? I have no clue as to what is going wrong. I have attached the LDIF file "nwaymmr2s.ldif" and the debug output from running the command slapadd -d -1 -v -F /etc/openldap/slapd.d -n 0 -l /etc/openldap/nwaymmr2s.ldif >& output.txt.
Also, do I need to run slappasswd and copy the hash value from it into my LDIF' file's olcRootPW field value? Or can I just keep the original value, "secret"?
And a final question, please: Why does the data replication (unlike the config replication, which does operate in refreshAndPersist mode) have to operate in refreshOnly mode? Why can't it operate in refreshAndPersist mode?
Thank you very much.
Fal
On Mon, Dec 31, 2012 at 12:49 PM, Quanah Gibson-Mount quanah@zimbra.comwrote:
--On Monday, December 31, 2012 9:49 AM -0800 fal patel < fal0patel@gmail.com> wrote:
Hey Quanah,
Thank you very much for the debugging tip! -- Using it I got further in. Now I get an error "<= str2entry: str2ad(UR1): attribute type undefined". I must be setting my external variables (such as UR1) incorrectly in my LDIF file. What is the correct syntax for setting them, please? I tried each of the following sentences, none of which worked: URI1: ldap://host1.hq.mycompany.com:**389/http://host1.hq.mycompany.com:389/ URI1: ldap://host1.hq.mycompany.com:**389http://host1.hq.mycompany.com:389 URI1: "ldap://host1.hq.mycompany.**com:389/http://host1.hq.mycompany.com:389/ " URI1="ldap://host1.hq.**mycompany.com:389/http://host1.hq.mycompany.com:389/ " URI1="ldap://host1.hq.**mycompany.com:389http://host1.hq.mycompany.com:389 " URI1 ldap://host1.hq.mycompany.com:**389/http://host1.hq.mycompany.com:389/
There is no URI bit in the admin guide. I highly advise you go re-read it. What you posted is clearly invalid.
From the admin guide:
------------------------------**-----------------------
Now we setup the first Master Node (replace $URI1, $URI2 and $URI3 etc. with your actual ldap urls):
dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 $URI1 olcServerID: 2 $URI2 olcServerID: 3 $URI3------------------------------**-----------------------
I.e. the attribute name is "olcServerID".
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
Am Tue, 1 Jan 2013 23:50:20 -0800 schrieb fal patel fal0patel@gmail.com:
Hey Quanah,
Oh no, my question was whether an arbitrary external variable (eg. URI1) could be set (eg. to ldap://host1.hq.mycompany.com:389/) inside an LDIF file and used in subsequent places in the file. (to avoid having to type in the value in multiple places). I suppose not?
Assuming not, I typed in each value into all its relevant places in my LDIF file and re-ran slapadd. Now it gives me the following error (on latest redhat 64bit): loaded module syncprov.la *module syncprov.la: null module registered*
Surely the above message signifies an error?
[...]
Check wether the modul has been built and is in the defined directory, if not, check wether syncprov has been built in slapd. slapd -VVV will show you all builtin modules.
-Dieter
Hey Dieter,
Thank you very much for your email.
It turns out that in RedHat the overlays are automatically installed, and so should not be loaded again with olcModuleLoad.
Thanks very much for your advice! On to the next problem: I can't understand what in the world could be causing the following error:
dnPrettyNormal: <cn=config>
<<< dnPrettyNormal: <cn=config>, <cn=config> *<= str2entry: str2ad(changetype): attribute type undefined* slapadd: could not parse entry (line=48)
Thanks again, and best regards
Fal
On Wed, Jan 2, 2013 at 2:23 AM, Dieter Klünter dieter@dkluenter.de wrote:
Am Tue, 1 Jan 2013 23:50:20 -0800 schrieb fal patel fal0patel@gmail.com:
Hey Quanah,
Oh no, my question was whether an arbitrary external variable (eg. URI1) could be set (eg. to ldap://host1.hq.mycompany.com:389/) inside an LDIF file and used in subsequent places in the file. (to avoid having to type in the value in multiple places). I suppose not?
Assuming not, I typed in each value into all its relevant places in my LDIF file and re-ran slapadd. Now it gives me the following error (on latest redhat 64bit): loaded module syncprov.la *module syncprov.la: null module registered*
Surely the above message signifies an error?
[...]
Check wether the modul has been built and is in the defined directory, if not, check wether syncprov has been built in slapd. slapd -VVV will show you all builtin modules.
-Dieter
-- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E
On Wed, 2 Jan 2013, fal patel wrote:
Thanks very much for your advice! On to the next problem: I can't understand what in the world could be causing the following error:
dnPrettyNormal: <cn=config>
<<< dnPrettyNormal: <cn=config>, <cn=config> *<= str2entry: str2ad(changetype): attribute type undefined* slapadd: could not parse entry (line=48)
Thanks again, and best regards
The sladpadd(8) manpage says: ----- DESCRIPTION Slapadd is used to add entries specified in LDAP Directory Interchange Format (LDIF) to a slapd(8) database. <...> -----
Note the word "entries" there. slapadd only accepts LDIF 'content' records and not 'change' records. So, this record in your LDIF:
dn: cn=config changetype: modify replace: olcServerID olcServerID: 1 ldap://10.12.223.10:389/ olcServerID: 2 ldap://10.12.223.11:389/ olcServerID: 3 ldap://10.12.223.12:389/
is not valid for slapadd. If you want to alter entries like that then you'll both 1) need to use the ldapmodify utility instead, and 2) make your input valid LDIF!
To elaborate on the latter: * an LDIF file cannot mix entry ('content') records and change records * each modification specified has to be terminated with a line containing just a hyphen; check ldif(5) or RFC 2849 for examples.
Philip Guenther
Dieter Klünter wrote:
Am Tue, 1 Jan 2013 23:50:20 -0800 schrieb fal patel fal0patel@gmail.com:
Assuming not, I typed in each value into all its relevant places in my LDIF file and re-ran slapadd. Now it gives me the following error (on latest redhat 64bit): loaded module syncprov.la *module syncprov.la: null module registered*
Surely the above message signifies an error?
No, it is normal.
[...]
Hi Philip,
hank you very much for your email.
In that case, my original surmise is correct: The OpenLDAP Administrator's Guide's Section 18.3.3 "N-Way Multi-Master" definitely is buggy. Because my LDIF file is a direct copy thereof (except for my environment values substituted in instead of the labels such as $URI1, of course.) How can this be reported as a bug, please? (In OpenLDAP documentation or/and code). And can a *working* sample LDIF file be provided, please, for this important replication design, n-way multi-master?
Thank you very much and best regards.
Fal
On Wed, Jan 2, 2013 at 9:57 PM, Howard Chu hyc@symas.com wrote:
Dieter Klünter wrote:
Am Tue, 1 Jan 2013 23:50:20 -0800 schrieb fal patel fal0patel@gmail.com:
Assuming not, I typed in each value into all its relevant places in
my LDIF file and re-ran slapadd. Now it gives me the following error (on latest redhat 64bit): loaded module syncprov.la *module syncprov.la: null module registered*
Surely the above message signifies an error?
No, it is normal.
[...]
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/**project/http://www.openldap.org/project/
On Thu, 3 Jan 2013, fal patel wrote:
How can this be reported as a bug, please? (In OpenLDAP documentation or/and code).
Documentation and/or code issues are welcomed in the OpenLDAP ITS http://www.openldap.org/its so feel free to submit there. Patches/specific wording recommendations would be particularly welcome.
And can a *working* sample LDIF file be provided, please, for this important replication design, n-way multi-master?
test050-syncrepl-multimaster and test063-delta-multimaster both Work For Me. In your source tree, cd tests and then "./run -b mdb test050" or "./run -b mdb test063" -- look in the "testrun" directory for the associated configurations and data. Note that test063 only does 2 servers out of the box, and it looks like setting MMR > 2 is broken there at the moment. I'll leave that as an exercise...
fal patel wrote:
Hi Philip,
hank you very much for your email.
In that case, my original surmise is correct: The OpenLDAP Administrator's Guide's Section 18.3.3 "N-Way Multi-Master" definitely is buggy. Because my LDIF file is a direct copy thereof (except for my environment values substituted in instead of the labels such as $URI1, of course.)
The example in 18.3.3 works perfectly when you substitute the correct values in for the variables and follow the steps listed.
How can this be reported as a bug, please? (In OpenLDAP documentation or/and code). And can a *working* sample LDIF file be provided, please, for this important replication design, n-way multi-master?
openldap-technical@openldap.org
-
Aaron Richton -
Dieter Klünter -
fal patel -
Howard Chu -
Philip Guenther