Hi!
I'm finally updating my file/ldap server and am struggling with converting my 2.3 slapd.conf file to 2.4 ldif format.
My plan to upgrade was:
- dump my old ldap db to a single ldif file - convert slapd.conf using slaptest - connect to slapd using an ldap browser and import my old db via the ldif file I created
Is this an appropriate approach that will work? Am I missing something?
I ran the slaptest program on my old slapd.conf file and generated a slew of configs under slapd.d.
However, I'm now running into an error when I try to start slapd.
slapd[4320]: config error processing cn={1}core,cn=schema,cn=config: olcAttributeTypes: Duplicate attributeType: "2.5.4.2" slaptest: bad configuration file! systemd[1]: PID file /var/run/slapd.pid not readable (yet?) after start.
I saw via google where the attribute is duplicated but I never could find how to edit/modify the configs to remove the duplicate entry.
Any ideas how to remove this duplicate entry?
Thanks,
Bobby
On 20/5/2012 8:31 μμ, Bobby Krupczak wrote:
Is this an appropriate approach that will work? Am I missing something?
slapcat the old dit. slapadd later in the new (correctly configured) ldap server, before starting it (no need to use an ldap browser to import data).
I saw via google where the attribute is duplicated but I never could find how to edit/modify the configs to remove the duplicate entry.
Any ideas how to remove this duplicate entry?
Correct things in the original schema files using a text editor and then run slaptest to create a correct slapd.d/ to be used for the config of your new 2.4.
Note however that the use of the dynamic config in 2.4 is not compulsory. You can migrate to 2.4 first (be careful for your ACLs, because there are some changes since 2.3!) using a standard slapd.conf and, when everything is working properly, at a later stage convert to dynamic config. This is the approach I suggest; one thing at a time.
Regards, Nick
Hi!
slapcat the old dit. slapadd later in the new (correctly configured) ldap server, before starting it (no need to use an ldap browser to import data).
Correct things in the original schema files using a text editor and then run slaptest to create a correct slapd.d/ to be used for the config of your new 2.4.
For some reason, I had duplicate schema files in the slapd.d/cn=config/cn=schema directory. Removing the duplicate files (with different {x} numbers) solved this problem.
I then got slapd to run with olc. However, none of my TLS settings transferred to the olc config. Do you know how to add these?
Are there any docs you can point me to on this? The ones I've found via google have not helped me handle any of these exceptions.
Note however that the use of the dynamic config in 2.4 is not compulsory. You can migrate to 2.4 first (be careful for your ACLs, because there are some changes since 2.3!) using a standard slapd.conf and, when everything is working properly, at a later stage convert to dynamic config. This is the approach I suggest; one thing at a time.
I'm contemplating this but I really dont want to go through this again. I've already spent so much time fighting slapd config, I'd like to get it over with. Yuck this transition sucks.
Thanks for your help.
Bobby
--On Monday, May 21, 2012 10:11 AM -0400 Bobby Krupczak rdk@krupczak.org wrote:
For some reason, I had duplicate schema files in the slapd.d/cn=config/cn=schema directory. Removing the duplicate files (with different {x} numbers) solved this problem.
I then got slapd to run with olc. However, none of my TLS settings transferred to the olc config. Do you know how to add these?
Are there any docs you can point me to on this? The ones I've found via google have not helped me handle any of these exceptions.
What version of OpenLDAP 2.4 are you using? You failed to state this anywhere that I can see.
--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
Hi!
Are there any docs you can point me to on this? The ones I've found via google have not helped me handle any of these exceptions.
What version of OpenLDAP 2.4 are you using? You failed to state this anywhere that I can see.
Sorry. Its 2.4 but thats not very specific. On F16, 2.4.26-7.fc16.x86_64 is what is installed.
My TLS/SSL primitives also do not port over to the new config.
Thanks,
Bobby
--On Monday, May 21, 2012 12:44 PM -0400 Bobby Krupczak rdk@krupczak.org wrote:
Hi!
Are there any docs you can point me to on this? The ones I've found via google have not helped me handle any of these exceptions.
What version of OpenLDAP 2.4 are you using? You failed to state this anywhere that I can see.
Sorry. Its 2.4 but thats not very specific. On F16, 2.4.26-7.fc16.x86_64 is what is installed.
My TLS/SSL primitives also do not port over to the new config.
a) Use a newer build, don't use distro crap
b) You'll need to give more information once you've ported using a current version of OpenLDAP. My TLS directives all port over just fine.
--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
Hi!
Is this a bug in the version I'm using?
It would be horrible if I had to go re-build all the software that came with my distro.
I've got it working, I think, with the old config file and need to finish moving my other services over before I tackle this problem again. Maybe when I upgrade the new box to the new new box, the migration will work.
One comment on the migration and I dont mean to be rude but changing config like this is a huge problem for admins that have to configure http/smtp/http/smb/Nfs/nis/Ldap/dns etc. I don't mean to come off as a whiner, but if all of these servoices changed their config like ldap, every other release or so, we would all be doomed. Kinda reminds me of how Microsoft changes their admin model every release.
Thanks for your help!
Bobby
On May 21, 2012, at 12:52 PM, Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Monday, May 21, 2012 12:44 PM -0400 Bobby Krupczak rdk@krupczak.org wrote:
Hi!
Are there any docs you can point me to on this? The ones I've found via google have not helped me handle any of these exceptions.
What version of OpenLDAP 2.4 are you using? You failed to state this anywhere that I can see.
Sorry. Its 2.4 but thats not very specific. On F16, 2.4.26-7.fc16.x86_64 is what is installed.
My TLS/SSL primitives also do not port over to the new config.
a) Use a newer build, don't use distro crap
b) You'll need to give more information once you've ported using a current version of OpenLDAP. My TLS directives all port over just fine.
--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 Monday, May 21, 2012 1:20 PM -0400 Bobby Krupczak rdk@krupczak.org wrote:
Hi!
Is this a bug in the version I'm using?
It would be horrible if I had to go re-build all the software that came with my distro.
Why would you have to rebuild the software that came with your distro? Leave the distro crap in place so the various utilities that use the client libraries can find them. Install OpenLDAP for SERVER into your own location.
--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
Hi!
I'm not sure I understand your point. I used the client and server builds that came with fedora. If I don't use their server build, I'd have to go re-build it, yes? If I had to do that with other packages, I'd double my work. Also, the distros issue patches and it's nice to have them pushed out to me. I'm not sure why we're discussing the merits of distros or not to distro.
Anyway, I'm really struggling with conf to olc migration and the lack of tls primitives. If this a bug in 2.4.26, I get that and will download/build a later version but if it's not, I'm not sure what the payoff is.
Thanks,
Bobby
On May 21, 2012, at 1:23 PM, Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Monday, May 21, 2012 1:20 PM -0400 Bobby Krupczak rdk@krupczak.org wrote:
Hi!
Is this a bug in the version I'm using?
It would be horrible if I had to go re-build all the software that came with my distro.
Why would you have to rebuild the software that came with your distro? Leave the distro crap in place so the various utilities that use the client libraries can find them. Install OpenLDAP for SERVER into your own location.
--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 Monday, May 21, 2012 1:58 PM -0400 Bobby Krupczak rdk@krupczak.org wrote:
Hi!
I'm not sure I understand your point. I used the client and server builds that came with fedora. If I don't use their server build, I'd have to go re-build it, yes? If I had to do that with other packages, I'd double my work. Also, the distros issue patches and it's nice to have them pushed out to me. I'm not sure why we're discussing the merits of distros or not to distro.
You can take the advise of someone who has been running OpenLDAP for over a decade, or you can continue to fail. Your choice. My point was, you can build the OpenLDAP binaries out to your own custom location for running it as a server, and leave the distro build in place for anything that is linked to its libraries.
I will also note that distro "patches" for OpenLDAP are not updating OpenLDAP to current versions. They are purely backports of a specific security issue. Backports of actual later releases are not done by most distros, and especially not rhel/fedora.
I would strongly advise reading: http://www.openldap.org/faq/data/cache/1456.html and http://www.openldap.org/software/release/changes.html
Anyway, I'm really struggling with conf to olc migration and the lack of tls primitives. If this a bug in 2.4.26, I get that and will download/build a later version but if it's not, I'm not sure what the payoff is.
In your last email, you failed to show the source of your "find" command. As has been mentioned more than once now, no one else is having them fail to migrate. It still remains entirely possible you are looking in the wrong location.
Here's an example of helpful output: root@zre-ldap004:/opt/zimbra/data/ldap/config# pwd /opt/zimbra/data/ldap/config root@zre-ldap004:/opt/zimbra/data/ldap/config# ls cn=config cn=config.ldif root@zre-ldap004:/opt/zimbra/data/ldap/config# grep -i olctls * cn=config.ldif:olcTLSCertificateFile: /opt/zimbra/conf/slapd.crt cn=config.ldif:olcTLSCertificateKeyFile: /opt/zimbra/conf/slapd.key cn=config.ldif:olcTLSCACertificatePath: /opt/zimbra/conf/ca cn=config.ldif:olcTLSCRLCheck: none cn=config.ldif:olcTLSVerifyClient: never
--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
Hi!
We seem to be going around in circles.
Once I get my new machine in place using the old .conf file, Ill come back to conversion and dilligently follow your advice.
Thanks,
Bobby
On May 21, 2012, at 2:03 PM, Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Monday, May 21, 2012 1:58 PM -0400 Bobby Krupczak rdk@krupczak.org wrote:
Hi!
I'm not sure I understand your point. I used the client and server builds that came with fedora. If I don't use their server build, I'd have to go re-build it, yes? If I had to do that with other packages, I'd double my work. Also, the distros issue patches and it's nice to have them pushed out to me. I'm not sure why we're discussing the merits of distros or not to distro.
You can take the advise of someone who has been running OpenLDAP for over a decade, or you can continue to fail. Your choice. My point was, you can build the OpenLDAP binaries out to your own custom location for running it as a server, and leave the distro build in place for anything that is linked to its libraries.
I will also note that distro "patches" for OpenLDAP are not updating OpenLDAP to current versions. They are purely backports of a specific security issue. Backports of actual later releases are not done by most distros, and especially not rhel/fedora.
I would strongly advise reading: http://www.openldap.org/faq/data/cache/1456.html and http://www.openldap.org/software/release/changes.html
Anyway, I'm really struggling with conf to olc migration and the lack of tls primitives. If this a bug in 2.4.26, I get that and will download/build a later version but if it's not, I'm not sure what the payoff is.
In your last email, you failed to show the source of your "find" command. As has been mentioned more than once now, no one else is having them fail to migrate. It still remains entirely possible you are looking in the wrong location.
Here's an example of helpful output: root@zre-ldap004:/opt/zimbra/data/ldap/config# pwd /opt/zimbra/data/ldap/config root@zre-ldap004:/opt/zimbra/data/ldap/config# ls cn=config cn=config.ldif root@zre-ldap004:/opt/zimbra/data/ldap/config# grep -i olctls * cn=config.ldif:olcTLSCertificateFile: /opt/zimbra/conf/slapd.crt cn=config.ldif:olcTLSCertificateKeyFile: /opt/zimbra/conf/slapd.key cn=config.ldif:olcTLSCACertificatePath: /opt/zimbra/conf/ca cn=config.ldif:olcTLSCRLCheck: none cn=config.ldif:olcTLSVerifyClient: never
--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
Hi!
You can take the advise of someone who has been running OpenLDAP for over a decade, or you can continue to fail. Your choice. My point
I have no intention of re-inventing the wheel, trust me.
In your last email, you failed to show the source of your "find" command. As has been mentioned more than once now, no one else is having them fail to migrate. It still remains entirely possible you are looking in the wrong location.
I'm not using Zimbra if that helps.
I looked in the /etc/openldap directory and all sub-directories.
I'm wondering if the slaptest utility did not convert my tls statements since I had not yet enabled ldaps in the /etc/sysconfig/ldap config file. (Yuck, yet another ldap config file! Yes I know this is a Fedora conf file.)
cn=config cn=config.ldif root@zre-ldap004:/opt/zimbra/data/ldap/config# grep -i olctls * cn=config.ldif:olcTLSCertificateFile: /opt/zimbra/conf/slapd.crt cn=config.ldif:olcTLSCertificateKeyFile: /opt/zimbra/conf/slapd.key cn=config.ldif:olcTLSCACertificatePath: /opt/zimbra/conf/ca cn=config.ldif:olcTLSCRLCheck: none cn=config.ldif:olcTLSVerifyClient: never
I looked in my equivalent.
Anyway, I'm going to continue using the conf file until I get my new machine in place and then I'll come back to the conversion and follow your advice to the letter. I do appreciate it.
Thanks!!
Bobby
Bobby Krupczak wrote:
Hi!
Is this a bug in the version I'm using?
It would be horrible if I had to go re-build all the software that came with my distro.
I've got it working, I think, with the old config file and need to finish moving my other services over before I tackle this problem again. Maybe when I upgrade the new box to the new new box, the migration will work.
One comment on the migration and I dont mean to be rude but changing config
like this is a huge problem for admins that have to configure http/smtp/http/smb/Nfs/nis/Ldap/dns etc. I don't mean to come off as a whiner, but if all of these servoices changed their config like ldap, every other release or so, we would all be doomed. Kinda reminds me of how Microsoft changes their admin model every release.
OpenLDAP's dynamic configuration mechanism was released in 2005. It does not change every other release. It's not our fault if your distro is so behind the times.
Thanks for your help!
Bobby
On May 21, 2012, at 12:52 PM, Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Monday, May 21, 2012 12:44 PM -0400 Bobby Krupczak rdk@krupczak.org wrote:
Hi!
Are there any docs you can point me to on this? The ones I've found via google have not helped me handle any of these exceptions.
What version of OpenLDAP 2.4 are you using? You failed to state this anywhere that I can see.
Sorry. Its 2.4 but thats not very specific. On F16, 2.4.26-7.fc16.x86_64 is what is installed.
My TLS/SSL primitives also do not port over to the new config.
a) Use a newer build, don't use distro crap
b) You'll need to give more information once you've ported using a current version of OpenLDAP. My TLS directives all port over just fine.
--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
Hi!
OpenLDAP's dynamic configuration mechanism was released in 2005. It does not change every other release. It's not our fault if your distro is so behind the times.
Interesting. My machine is admittedly a little out of date but given how much fun it is to upgrade these various services, you have all grant me just a tiny amount of slack. The old machine is running openldap 2.3.30 circa 2007.
Also, if the new config format has been out that long, I'm kinda surprised that the config conversion has been so hard.
Anyway, thanks for helping me. I think I'm going to get this new machine in place and then tackle the conversion. It needs to be done as I'd like to upgrade more often in the future.
Bobby
--On Monday, May 21, 2012 4:09 PM -0400 Bobby Krupczak rdk@krupczak.org wrote:
Hi!
OpenLDAP's dynamic configuration mechanism was released in 2005. It does not change every other release. It's not our fault if your distro is so behind the times.
Interesting. My machine is admittedly a little out of date but given how much fun it is to upgrade these various services, you have all grant me just a tiny amount of slack. The old machine is running openldap 2.3.30 circa 2007.
Also, if the new config format has been out that long, I'm kinda surprised that the config conversion has been so hard.
Conversion is not difficult at all. You use the slaptest utility to convert a conf file to cn=config. That is a single command. It would be hard to get any simpler than that.
I believe the majority of your issues stem from using your distributions build. For example, you are using Fedora. Fedora links OpenLDAP to NSS rather than the standardized OpenSSL. That NSS support was written by RedHat, and has had a large number of issues, which are still in the process of being resolved. If you were to follow my advice, and build your own OpenLDAP, linked to the industry standard OpenSSL, a large number of the problems you have encountered would simply go away.
--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
Hi!
It was easy running the slaptest utility -- you are correct. The output wasn't so easy to figure out with duplicate schema entries, tls being dropped, etc.
I saw that redhat uses nss and I'll have to confess that I don't understand the technical and political reasons for this. They (redhat) allege at it should be transparent to me.
Anyway, thanks for the suggestions. When I get my machine in place, I'll get back to converting the config and will post my workarounds.
Thanks,
Bobby
On May 21, 2012, at 4:30 PM, Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Monday, May 21, 2012 4:09 PM -0400 Bobby Krupczak rdk@krupczak.org wrote:
Hi!
OpenLDAP's dynamic configuration mechanism was released in 2005. It does not change every other release. It's not our fault if your distro is so behind the times.
Interesting. My machine is admittedly a little out of date but given how much fun it is to upgrade these various services, you have all grant me just a tiny amount of slack. The old machine is running openldap 2.3.30 circa 2007.
Also, if the new config format has been out that long, I'm kinda surprised that the config conversion has been so hard.
Conversion is not difficult at all. You use the slaptest utility to convert a conf file to cn=config. That is a single command. It would be hard to get any simpler than that.
I believe the majority of your issues stem from using your distributions build. For example, you are using Fedora. Fedora links OpenLDAP to NSS rather than the standardized OpenSSL. That NSS support was written by RedHat, and has had a large number of issues, which are still in the process of being resolved. If you were to follow my advice, and build your own OpenLDAP, linked to the industry standard OpenSSL, a large number of the problems you have encountered would simply go away.
--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 Monday, May 21, 2012 4:42 PM -0400 Bobby Krupczak rdk@krupczak.org wrote:
Hi!
It was easy running the slaptest utility -- you are correct. The output wasn't so easy to figure out with duplicate schema entries, tls being dropped, etc.
I saw that redhat uses nss and I'll have to confess that I don't understand the technical and political reasons for this. They (redhat) allege at it should be transparent to me.
The dropping of the TLS directives doesn't happen with an OpenSSL linked build. That's entirely my point. Duplicate schema entries doesn't occur with a standard openldap installation, and would have caused problems regardless of whether or not you were using cn=config. I.e., you had an invalid 2.3 configuration that is caught in 2.4, using slapd.conf or slapd-config.
--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
Hi!
I then got slapd to run with olc. However, none of my TLS settings transferred to the olc config.
Are you sure? Mine were migrated fine.
They lie in the {0}config (i.e. in the config root) branch.
These settings were in the original slapd.conf file.
TLSCipherSuite HIGH:MEDIUM TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt TLSCertificateFile /var/lib/ldap/columbia-slapd.crt TLSCertificateKeyFile /var/lib/ldap/columbia-slapd.key
Find produces nothing: # find . -print | xargs grep columbia-slap
Did I do something wrong?
Right now I've got my old slapd.conf running on this F16 openldap 2.4.26 server and I've imported my old ldap database via an ldif file.
However, the warnings about the .conf going away in future releases does not make me feel much better. I'm hoping the developers dont drop the .conf in a 2.4.x release.
Thanks,
Bobby
On 21/5/2012 7:44 μμ, Nick Milas wrote:
Are you sure? Mine were migrated fine.
They lie in the {0}config (i.e. in the config root) branch.
Sorry, they lie in the config branch, not in the {0}config branch.
Here is my config root branch:
DN: cn=config objectClass: olcGlobal cn: config olcAllows: bind_v2 olcArgsFile: /usr/local/openldap/var/run/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConfigDir: slapd.d olcConfigFile: slapd.conf olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexIntLen: 4 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcLocalSSF: 71 olcLogLevel: Sync olcPidFile: /usr/local/openldap/var/run/slapd.pid olcReadOnly: FALSE olcSaslSecProps: noplain,noanonymous olcSizeLimit: unlimited olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTimeLimit: unlimited olcTLSCACertificateFile: /usr/local/openldap/etc/openldap/certs/chain.pem olcTLSCertificateFile: /usr/local/openldap/etc/openldap/certs/cert.pem olcTLSCertificateKeyFile: /usr/local/openldap/etc/openldap/certs/priv.pem olcTLSCipherSuite: HIGH:MEDIUM:+SSLv2 olcTLSCRLCheck: none olcTLSVerifyClient: never olcToolThreads: 1 olcWriteTimeout: 0
I agree with Quanah on using a non-system LDAP package; of those I have worked with, I would propose you try using Symas Silver (excluding syncrepl providers - if you cannot afford paid support - otherwise check gold), or full-featured LTB project's RPMs (free, with on-line issue system). (We use the latter.)
Buchan's RPMs are fine too, but availability is sometimes limited and updates slower. There are surely other RPMs and/or SRPMs around.
This way you can upgrade at will and fully control your system.
It'll take you some time in the beginning to setup things fully (since non-default system paths are used), but you'll not regret it.
Nick
openldap-technical@openldap.org
-
Bobby Krupczak -
Howard Chu -
Nick Milas -
Quanah Gibson-Mount