Hi,
I used to be fine with slapd.conf way but now with slapd.d/ I am kind of lost. From the reading I did so far I have to load the syncprov module but I couldn't find a single document or example how to enable that on Redhat Fedora platform. The following list is all that comes with Redhat distribution:
[root@ldaprov1 cn=config]# pwd /etc/openldap/slapd.d/cn=config [root@ldaprov1 cn=config]# ll total 72 drwx------. 2 ldap ldap 4096 Jun 6 02:21 cn=schema -rw-------. 1 ldap ldap 52268 Jun 6 02:21 cn=schema.ldif -rw-------. 1 ldap ldap 572 Jun 6 02:55 olcDatabase={0}config.ldif -rw-------. 1 ldap ldap 1377 Jun 6 02:54 olcDatabase={1}bdb.ldif -rw-------. 1 ldap ldap 525 Jun 6 02:21 olcDatabase={-1}frontend.ldif -rw-------. 1 ldap ldap 556 Jun 6 03:00 olcDatabase={2}monitor.ldif
Can anyone point out to me how I can add the module required to do replication on the provider side? I will make a document if I am able to set it up eventually.
Thanks, Daniel
On Tue, 7 Jun 2011, Daniel Qian wrote:
Can anyone point out to me how I can add the module required to do replication on the provider side? I will make a document if I am able to set it up eventually.
You can find examples of using olcModuleLoad to instruct back-config to load the module in the OpenLDAP 2.4 Administrator's Guide. While the directive is not overlay-specific, there is an example that uses syncprov in section 18.3.3, as well as code examples in the "tests" directory.
If you're writing a document, it might be good to write back-config examples suitable for some other section(s) of the Admin Guide (perhaps, if you don't choose n-way multimaster, you can contribute whatever you use for your installation)?
On 11-06-07 1:40 PM, Aaron Richton wrote:
On Tue, 7 Jun 2011, Daniel Qian wrote:
Can anyone point out to me how I can add the module required to do replication on the provider side? I will make a document if I am able to set it up eventually.
You can find examples of using olcModuleLoad to instruct back-config to load the module in the OpenLDAP 2.4 Administrator's Guide. While the directive is not overlay-specific, there is an example that uses syncprov in section 18.3.3, as well as code examples in the "tests" directory.
If you're writing a document, it might be good to write back-config examples suitable for some other section(s) of the Admin Guide (perhaps, if you don't choose n-way multimaster, you can contribute whatever you use for your installation)?
I think I know what I need to get done based on the info I gathered on some Ubuntu websites. I just have no idea how those settings fit into Redhat layout. Correct me if I am wrong. Basically I need to load the module with something like this :
dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModuleLoad: {0}back_bdb *olcModuleLoad*: {1}*syncprov* olcModulePath: /usr/lib64/openldap
and then use the overlay with something like this:
dn: olcOverlay={0}syncprov,*olcDatabase={1}bdb,cn=config* objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100
But the question is in what files/folders I should put these settings? Fedora has a few database ldif files whose settings get loaded into openldap upon restart. Can I do the same with these settings as well?
Thanks, Daniel
Daniel Qian wrote:
On 11-06-07 1:40 PM, Aaron Richton wrote:
On Tue, 7 Jun 2011, Daniel Qian wrote:
Can anyone point out to me how I can add the module required to do replication on the provider side? I will make a document if I am able to set it up eventually.
You can find examples of using olcModuleLoad to instruct back-config to load the module in the OpenLDAP 2.4 Administrator's Guide. While the directive is not overlay-specific, there is an example that uses syncprov in section 18.3.3, as well as code examples in the "tests" directory.
If you're writing a document, it might be good to write back-config examples suitable for some other section(s) of the Admin Guide (perhaps, if you don't choose n-way multimaster, you can contribute whatever you use for your installation)?
I think I know what I need to get done based on the info I gathered on some Ubuntu websites. I just have no idea how those settings fit into Redhat layout. Correct me if I am wrong. Basically I need to load the module with something like this :
dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModuleLoad: {0}back_bdb *olcModuleLoad*: {1}*syncprov* olcModulePath: /usr/lib64/openldap
and then use the overlay with something like this:
dn: olcOverlay={0}syncprov,*olcDatabase={1}bdb,cn=config* objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100
But the question is in what files/folders I should put these settings? Fedora has a few database ldif files whose settings get loaded into openldap upon restart. Can I do the same with these settings as well?
On Ubuntu you would leave slapd running and just do this (as root):
# ldapmodify -H ldapi:// -Y EXTERNAL <<EOF dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov.la -
dn: olcOverlay=syncprov,olcDatabase={1}bdb,cn=config changetype: add objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 - EOF
--On Tuesday, June 07, 2011 12:37 PM -0700 Howard Chu hyc@symas.com wrote:
On Ubuntu you would leave slapd running and just do this (as root):
However, he is on Fedora, not Ubuntu, and hopefully they don't have the obnoxious ldapi:/// as root requirement.
--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
Quanah Gibson-Mount wrote:
--On Tuesday, June 07, 2011 12:37 PM -0700 Howard Chuhyc@symas.com wrote:
On Ubuntu you would leave slapd running and just do this (as root):
However, he is on Fedora, not Ubuntu, and hopefully they don't have the obnoxious ldapi:/// as root requirement.
There's nothing obnoxious about that; it's far simpler than requiring the admin to discover any secret credential that was automatically assigned to the DB, and obviously superior to leaving the DB with no credential at all, or with a well-known default that admins leave unchanged, leaving themselves vulnerable to whatever script-kiddie comes along down the road.
On Ubuntu you would leave slapd running and just do this (as root):
However, he is on Fedora, not Ubuntu, and hopefully they don't have the obnoxious ldapi:/// as root requirement.
This is definitely not obnoxious. This is in fact pretty useful! And I already have it on my TODO list for Fedora. It will be added soon.
Jan
On 11-06-07 3:37 PM, Howard Chu wrote:
Daniel Qian wrote:
On 11-06-07 1:40 PM, Aaron Richton wrote:
On Tue, 7 Jun 2011, Daniel Qian wrote:
Can anyone point out to me how I can add the module required to do replication on the provider side? I will make a document if I am able to set it up eventually.
You can find examples of using olcModuleLoad to instruct back-config to load the module in the OpenLDAP 2.4 Administrator's Guide. While the directive is not overlay-specific, there is an example that uses syncprov in section 18.3.3, as well as code examples in the "tests" directory.
If you're writing a document, it might be good to write back-config examples suitable for some other section(s) of the Admin Guide (perhaps, if you don't choose n-way multimaster, you can contribute whatever you use for your installation)?
I think I know what I need to get done based on the info I gathered on some Ubuntu websites. I just have no idea how those settings fit into Redhat layout. Correct me if I am wrong. Basically I need to load the module with something like this :
dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModuleLoad: {0}back_bdb *olcModuleLoad*: {1}*syncprov* olcModulePath: /usr/lib64/openldap
and then use the overlay with something like this:
dn: olcOverlay={0}syncprov,*olcDatabase={1}bdb,cn=config* objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100
But the question is in what files/folders I should put these settings? Fedora has a few database ldif files whose settings get loaded into openldap upon restart. Can I do the same with these settings as well?
On Ubuntu you would leave slapd running and just do this (as root):
# ldapmodify -H ldapi:// -Y EXTERNAL <<EOF dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov.la
dn: olcOverlay=syncprov,olcDatabase={1}bdb,cn=config changetype: add objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100
EOF
Looks like I don't even have a module{0} in my setup. Here is all the DNs from " ldapsearch -LLL -b cn=config -D cn=admin,cn=config -W dn"
dn: cn=config dn: cn=schema,cn=config dn: cn={0}corba,cn=schema,cn=config dn: cn={1}core,cn=schema,cn=config dn: cn={2}cosine,cn=schema,cn=config dn: cn={3}duaconf,cn=schema,cn=config dn: cn={4}dyngroup,cn=schema,cn=config dn: cn={5}inetorgperson,cn=schema,cn=config dn: cn={6}java,cn=schema,cn=config dn: cn={7}misc,cn=schema,cn=config dn: cn={8}nis,cn=schema,cn=config dn: cn={9}openldap,cn=schema,cn=config dn: cn={10}ppolicy,cn=schema,cn=config dn: cn={11}collective,cn=schema,cn=config dn: olcDatabase={-1}frontend,cn=config dn: olcDatabase={0}config,cn=config dn: olcDatabase={1}bdb,cn=config dn: olcDatabase={2}monitor,cn=config
Thanks, Daniel
Daniel Qian wrote:
On 11-06-07 3:37 PM, Howard Chu wrote:
On Ubuntu you would leave slapd running and just do this (as root):
# ldapmodify -H ldapi:// -Y EXTERNAL<<EOF dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov.la
dn: olcOverlay=syncprov,olcDatabase={1}bdb,cn=config changetype: add objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100
EOF
Looks like I don't even have a module{0} in my setup.
So what does that tell you? Use your brain and think.
Obviously the backends are working without any module configuration, which means the backends were statically compiled into slapd. So, knowing nothing else at all about how RedHat built this, you have a few possibilities: 1) there is no module support at all a) all of the overlays are statically compiled in b) some/none of the overlays are statically compiled in 2) there is module support a) all of the overlays are statically compiled in b) some of the overlays are dynamic
It would take all of a minute for you to investigate and discover what the situation is with your build.
Here is all the DNs from " ldapsearch -LLL -b cn=config -D cn=admin,cn=config -W dn"
dn: cn=config dn: cn=schema,cn=config dn: cn={0}corba,cn=schema,cn=config dn: cn={1}core,cn=schema,cn=config dn: cn={2}cosine,cn=schema,cn=config dn: cn={3}duaconf,cn=schema,cn=config dn: cn={4}dyngroup,cn=schema,cn=config dn: cn={5}inetorgperson,cn=schema,cn=config dn: cn={6}java,cn=schema,cn=config dn: cn={7}misc,cn=schema,cn=config dn: cn={8}nis,cn=schema,cn=config dn: cn={9}openldap,cn=schema,cn=config dn: cn={10}ppolicy,cn=schema,cn=config dn: cn={11}collective,cn=schema,cn=config dn: olcDatabase={-1}frontend,cn=config dn: olcDatabase={0}config,cn=config dn: olcDatabase={1}bdb,cn=config dn: olcDatabase={2}monitor,cn=config
On 11-06-07 4:12 PM, Howard Chu wrote:
Daniel Qian wrote:
On 11-06-07 3:37 PM, Howard Chu wrote:
On Ubuntu you would leave slapd running and just do this (as root):
# ldapmodify -H ldapi:// -Y EXTERNAL<<EOF dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov.la
dn: olcOverlay=syncprov,olcDatabase={1}bdb,cn=config changetype: add objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100
EOF
Looks like I don't even have a module{0} in my setup.
So what does that tell you? Use your brain and think.
Obviously the backends are working without any module configuration, which means the backends were statically compiled into slapd. So, knowing nothing else at all about how RedHat built this, you have a few possibilities:
- there is no module support at all
a) all of the overlays are statically compiled in b) some/none of the overlays are statically compiled in 2) there is module support a) all of the overlays are statically compiled in b) some of the overlays are dynamic
It would take all of a minute for you to investigate and discover what the situation is with your build.
I actually trying to think hard but there is just not enough information for me to think with :)
You pretty much listed all the possibilities. I think backend binary is compiled but not syncprov as I can see the distribution package installed this as separate library files - /usr/lib64/openldap/syncprov-2.4.so.2.6.0 /usr/lib64/openldap/syncprov.la
So I will have to manually add the entry to load the module?
Thanks, Daniel
Hi,
So I will have to manually add the entry to load the module?
You don't have to. After fresh installation, just add something like this: olcSyncrepl: rid=100 provider=ldap://foo searchbase=dc=foo,dc=my-domain,dc=com
into: /etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif
It should work. olcSyncrepl options are well described in "man slapd-config".
Jan
Jan Vcelak wrote:
Hi,
So I will have to manually add the entry to load the module?
You don't have to. After fresh installation, just add something like this: olcSyncrepl: rid=100 provider=ldap://foo searchbase=dc=foo,dc=my-domain,dc=com
into: /etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif
It should work. olcSyncrepl options are well described in "man slapd-config".
Ordinarily I would flame you to bits, but we just went thru this a couple months ago. Read this thread http://www.openldap.org/lists/openldap-technical/201104/msg00265.html and consider yourself flamed.
Ordinarily I would flame you to bits, but we just went thru this a couple months ago. Read this thread http://www.openldap.org/lists/openldap-technical/201104/msg00265.html and consider yourself flamed.
I know that it is not recommended and I feel ashamed. ;-) But is it possible to use slapadd to update one entry by adding an attribute? By default, there is nor olcRootPW or any other granting olcAccess set for cn=config database in Fedora.
dn: olcDatabase={1}bdb,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: rid=100 provider=ldaps://foo searchbase=dc=foo,dc=my-domain,dc=com
slapadding this LDIF did't work for me. When I set olcRootPW, ldapadd works.
Thank you.
Jan
On 06/08/2011 08:42 AM, Jan Vcelak wrote:
Ordinarily I would flame you to bits, but we just went thru this a couple months ago. Read this thread http://www.openldap.org/lists/openldap-technical/201104/msg00265.html and consider yourself flamed.
I know that it is not recommended and I feel ashamed. ;-) But is it possible to use slapadd to update one entry by adding an attribute?
You should use slapmodify(8).
p.
By default, there is nor olcRootPW or any other granting olcAccess set for cn=config database in Fedora.
dn: olcDatabase={1}bdb,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: rid=100 provider=ldaps://foo searchbase=dc=foo,dc=my-domain,dc=com
slapadding this LDIF did't work for me. When I set olcRootPW, ldapadd works.
Thank you.
Jan
On 06/08/2011 09:52 AM, Jan Vcelak wrote:
I know that it is not recommended and I feel ashamed. ;-) But is it possible to use slapadd to update one entry by adding an attribute?
You should use slapmodify(8).
Which is available only in git at the moment and not in official releases. :-) Good to know.
It's experimental, although it would be probably time to release it; feedback from users would be more than welcome.
p.
On 06/08/2011 10:18 AM, Pierangelo Masarati wrote:
On 06/08/2011 09:52 AM, Jan Vcelak wrote:
You should use slapmodify(8).
Which is available only in git at the moment and not in official releases. :-) Good to know.
It's experimental, although it would be probably time to release it; feedback from users would be more than welcome.
I tried it lately and apart from the missing manpage, I have not been able to use it either. It refuses to work with the cn=config database as bconfig does not set its bi_tool_entry_put and bi_tool_entry_modify callbacks.
Probably a few commits that live in a private branch somewhere?
On 06/08/2011 11:29 AM, Ondrej Kuznik wrote:
I tried it lately and apart from the missing manpage, I have not been able to use it either. It refuses to work with the cn=config database as bconfig does not set its bi_tool_entry_put and bi_tool_entry_modify callbacks.
Probably a few commits that live in a private branch somewhere?
Of course I meant bi_tool_dn2id_get instead of bi_tool_entry_put.
On 06/08/2011 11:29 AM, Ondrej Kuznik wrote:
On 06/08/2011 10:18 AM, Pierangelo Masarati wrote:
On 06/08/2011 09:52 AM, Jan Vcelak wrote:
You should use slapmodify(8).
Which is available only in git at the moment and not in official releases. :-) Good to know.
It's experimental, although it would be probably time to release it; feedback from users would be more than welcome.
I tried it lately and apart from the missing manpage, I have not been able to use it either. It refuses to work with the cn=config database as bconfig does not set its bi_tool_entry_put and bi_tool_entry_modify callbacks.
Good point, you probably better file an ITS.
Thanks, p.
On 06/08/2011 11:38 AM, Pierangelo Masarati wrote:
On 06/08/2011 11:29 AM, Ondrej Kuznik wrote:
On 06/08/2011 10:18 AM, Pierangelo Masarati wrote:
On 06/08/2011 09:52 AM, Jan Vcelak wrote:
You should use slapmodify(8).
Which is available only in git at the moment and not in official releases. :-) Good to know.
It's experimental, although it would be probably time to release it; feedback from users would be more than welcome.
I tried it lately and apart from the missing manpage, I have not been able to use it either. It refuses to work with the cn=config database as bconfig does not set its bi_tool_entry_put and bi_tool_entry_modify callbacks.
Good point, you probably better file an ITS.
Of course I meant if the bug (actually, missing feature) is confirmed :)
p.
On 11-06-07 6:27 PM, Jan Vcelak wrote:
Hi,
So I will have to manually add the entry to load the module?
You don't have to. After fresh installation, just add something like this: olcSyncrepl: rid=100 provider=ldap://foo searchbase=dc=foo,dc=my-domain,dc=com
into: /etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif
It should work. olcSyncrepl options are well described in "man slapd-config".
Jan
Thanks for reply Jan.
the line "olcSyncrepl: rid=100 provider=ldap://foo searchbase=dc=foo,dc=my-domain,dc=com" looks to be consumer side of the setup to me. But I am still struggling on the provider side at the moment.
Regards, Daniel
Am Tue, 07 Jun 2011 16:36:23 -0400 schrieb Daniel Qian daniel@up247solution.com:
On 11-06-07 4:12 PM, Howard Chu wrote:
Daniel Qian wrote:
On 11-06-07 3:37 PM, Howard Chu wrote:
On Ubuntu you would leave slapd running and just do this (as root):
# ldapmodify -H ldapi:// -Y EXTERNAL<<EOF dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov.la
dn: olcOverlay=syncprov,olcDatabase={1}bdb,cn=config changetype: add objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100
EOF
Looks like I don't even have a module{0} in my setup.
So what does that tell you? Use your brain and think.
Obviously the backends are working without any module configuration, which means the backends were statically compiled into slapd. So, knowing nothing else at all about how RedHat built this, you have a few possibilities:
- there is no module support at all
a) all of the overlays are statically compiled in b) some/none of the overlays are statically compiled in 2) there is module support a) all of the overlays are statically compiled in b) some of the overlays are dynamic
It would take all of a minute for you to investigate and discover what the situation is with your build.
I actually trying to think hard but there is just not enough information for me to think with :)
You pretty much listed all the possibilities. I think backend binary is compiled but not syncprov as I can see the distribution package installed this as separate library files - /usr/lib64/openldap/syncprov-2.4.so.2.6.0 /usr/lib64/openldap/syncprov.la
man slapd(8), slapd -VVV will show you all static build in overlays and backends.
-Dieter
On 11-06-08 2:27 AM, Dieter Kluenter wrote:
Am Tue, 07 Jun 2011 16:36:23 -0400 schrieb Daniel Qiandaniel@up247solution.com:
On 11-06-07 4:12 PM, Howard Chu wrote:
Daniel Qian wrote:
On 11-06-07 3:37 PM, Howard Chu wrote:
On Ubuntu you would leave slapd running and just do this (as root):
# ldapmodify -H ldapi:// -Y EXTERNAL<<EOF dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov.la
dn: olcOverlay=syncprov,olcDatabase={1}bdb,cn=config changetype: add objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100
EOF
Looks like I don't even have a module{0} in my setup.
So what does that tell you? Use your brain and think.
Obviously the backends are working without any module configuration, which means the backends were statically compiled into slapd. So, knowing nothing else at all about how RedHat built this, you have a few possibilities:
- there is no module support at all a) all of the overlays are statically compiled in b) some/none of the overlays are statically compiled in
- there is module support a) all of the overlays are statically compiled in b) some of the overlays are dynamic
It would take all of a minute for you to investigate and discover what the situation is with your build.
I actually trying to think hard but there is just not enough information for me to think with :)
You pretty much listed all the possibilities. I think backend binary is compiled but not syncprov as I can see the distribution package installed this as separate library files - /usr/lib64/openldap/syncprov-2.4.so.2.6.0 /usr/lib64/openldap/syncprov.la
man slapd(8), slapd -VVV will show you all static build in overlays and backends.
-Dieter
Thanks a lot for pointing out this useful command option. Its one of those things I was searching for but was not able to get easily.
In my case redhat has bdb/hdb compiled in but not syncprov and that explains what I have seen so far.
Am Tue, 07 Jun 2011 15:15:43 -0400 schrieb Daniel Qian daniel@up247solution.com:
On 11-06-07 1:40 PM, Aaron Richton wrote:
On Tue, 7 Jun 2011, Daniel Qian wrote:
Can anyone point out to me how I can add the module required to do replication on the provider side? I will make a document if I am able to set it up eventually.
You can find examples of using olcModuleLoad to instruct back-config to load the module in the OpenLDAP 2.4 Administrator's Guide. While the directive is not overlay-specific, there is an example that uses syncprov in section 18.3.3, as well as code examples in the "tests" directory.
If you're writing a document, it might be good to write back-config examples suitable for some other section(s) of the Admin Guide (perhaps, if you don't choose n-way multimaster, you can contribute whatever you use for your installation)?
I think I know what I need to get done based on the info I gathered on some Ubuntu websites. I just have no idea how those settings fit into Redhat layout. Correct me if I am wrong. Basically I need to load the module with something like this :
dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModuleLoad: {0}back_bdb *olcModuleLoad*: {1}*syncprov* olcModulePath: /usr/lib64/openldap
and then use the overlay with something like this:
dn: olcOverlay={0}syncprov,*olcDatabase={1}bdb,cn=config* objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100
But the question is in what files/folders I should put these settings? Fedora has a few database ldif files whose settings get loaded into openldap upon restart. Can I do the same with these settings as well?
You shouldn't put this data into any file or directory, just load this information by means of an ldap operation like add or modify. You may use an ldif file or any decent LDAP editor.
-Dieter
On 11-06-08 2:22 AM, Dieter Kluenter wrote:
Am Tue, 07 Jun 2011 15:15:43 -0400 schrieb Daniel Qiandaniel@up247solution.com:
On 11-06-07 1:40 PM, Aaron Richton wrote:
On Tue, 7 Jun 2011, Daniel Qian wrote:
Can anyone point out to me how I can add the module required to do replication on the provider side? I will make a document if I am able to set it up eventually.
You can find examples of using olcModuleLoad to instruct back-config to load the module in the OpenLDAP 2.4 Administrator's Guide. While the directive is not overlay-specific, there is an example that uses syncprov in section 18.3.3, as well as code examples in the "tests" directory.
If you're writing a document, it might be good to write back-config examples suitable for some other section(s) of the Admin Guide (perhaps, if you don't choose n-way multimaster, you can contribute whatever you use for your installation)?
I think I know what I need to get done based on the info I gathered on some Ubuntu websites. I just have no idea how those settings fit into Redhat layout. Correct me if I am wrong. Basically I need to load the module with something like this :
dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModuleLoad: {0}back_bdb *olcModuleLoad*: {1}*syncprov* olcModulePath: /usr/lib64/openldap
and then use the overlay with something like this:
dn: olcOverlay={0}syncprov,*olcDatabase={1}bdb,cn=config* objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100
But the question is in what files/folders I should put these settings? Fedora has a few database ldif files whose settings get loaded into openldap upon restart. Can I do the same with these settings as well?
You shouldn't put this data into any file or directory, just load this information by means of an ldap operation like add or modify. You may use an ldif file or any decent LDAP editor.
-Dieter
I was just a little confused when some documents say the entry module{0} should be there as part of the config but I couldn't find it available on Redhat. One more thing I did not know is on Redhat you actually define backends in ldif files but settings like these in ldap config database. I can understand it a little better now. Its like the chicken-and egg issue. You can have the backend defined in a backend db but that requires a backend to be defined first. ldif files are probably the Redhat way to get that "primed"? Correct me on this if I am wrong.
This is the first time I am dealing with cn=config so I am being a little cautious not to mess up anything. The server will eventually go into production and we want to stick to Redhat layout so it will be easy to manage down the road. Things seem to be clearing up now thanks to you and other people who tried to help.
Thanks, Daniel
--On Tuesday, June 07, 2011 12:27 PM -0400 Daniel Qian daniel@up247solution.com wrote:
Hi,
I used to be fine with slapd.conf way but now with slapd.d/ I am kind of lost. From the reading I did so far I have to load the syncprov module but I couldn't find a single document or example how to enable that on Redhat Fedora platform. The following list is all that comes with Redhat distribution:
Did you read the OpenLDAP admin guide? Sending us a list of files for your cn=config database isn't going to give you or the list anything useful, either. You also fail to state *which* version of OpenLDAP ships with the Fedora you are on.
--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
On 11-06-07 1:50 PM, Quanah Gibson-Mount wrote:
--On Tuesday, June 07, 2011 12:27 PM -0400 Daniel Qian daniel@up247solution.com wrote:
Hi,
I used to be fine with slapd.conf way but now with slapd.d/ I am kind of lost. From the reading I did so far I have to load the syncprov module but I couldn't find a single document or example how to enable that on Redhat Fedora platform. The following list is all that comes with Redhat distribution:
Did you read the OpenLDAP admin guide? Sending us a list of files for your cn=config database isn't going to give you or the list anything useful, either. You also fail to state *which* version of OpenLDAP ships with the Fedora you are on.
--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
I actually read the admin guide for v2.4 and also searched a bunch of websites. Sorry if my question is too Redhat specific but I am glad you care to ask about the version of my Openldap setup. I am currently running openldap 2.4.24-2 on Fedora 15. I sent the list of those files in the hope that someone on this mailing list knows enough about Redhat setup and can give me a straight answer so my setup process can be a little less painful. This will definitely benefit other people as well since there is not much information about how to do this on Redhat platform.
Thanks, Daniel
--On Tuesday, June 07, 2011 3:31 PM -0400 Daniel Qian daniel@up247solution.com wrote:
I actually read the admin guide for v2.4 and also searched a bunch of websites. Sorry if my question is too Redhat specific but I am glad you care to ask about the version of my Openldap setup. I am currently running openldap 2.4.24-2 on Fedora 15. I sent the list of those files in the hope that someone on this mailing list knows enough about Redhat setup and can give me a straight answer so my setup process can be a little less painful. This will definitely benefit other people as well since there is not much information about how to do this on Redhat platform.
There should be nothing specific to Fedora/RedHat about configuring cn=config, other than verifying what modules they built OpenLDAP with. One would assume syncprov is one of them. Other than that, how to update a cn=config database for replication is an LDAP function that is not vendor dependant.
--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
openldap-technical@openldap.org
-
Aaron Richton -
Daniel Qian -
Dieter Kluenter -
Howard Chu -
Jan Vcelak -
Ondrej Kuznik -
Pierangelo Masarati -
Quanah Gibson-Mount