Hello,
at the moment we have installed OpenLDAP 2.3.17 on our production servers. Recently we've decided to upgrade to 2.4.9 version and we came across an issue which doesn't seem easy to solve. It's about the "c" (country) attribute syntax definition which has been changed in the core schema between 2.3.17 and 2.4. In older days this attribute allowed string values, but now it has been limited to 2-characters only ("Country String"). Country value is a part of suffix in our DIT (e.g. l=$locality,c=$country), the problem is that our users in some cases used 3 or more letters for country attribute . This was on 2.3 server. Now I want to upgrade the server to the new version and at the same time I want to convert the old-fashioned slapd.conf configuration to dynamic one (slapd.d). When I try to bring up the database, the server fail to start and I get the following error:
(a snippet from slapd debug): ...
dnPrettyNormal: <olcDatabase={-1}frontend>
<<< dnPrettyNormal: <olcDatabase={-1}frontend>, <olcDatabase={-1}frontend>
dnNormalize: <cn=config>
<<< dnNormalize: <cn=config>
dnNormalize: <cn=config>
<<< dnNormalize: <cn=config> <= str2entry(olcDatabase={-1}frontend) -> 0x828cba4
dnPrettyNormal: <l=kranj,c=slo>
ldap_err2string config error processing olcDatabase={-1}frontend,cn=config: <olcDefaultSearchBase> invalid DN 21 (Invalid syntax) send_ldap_result: conn=-1 op=0 p=0 slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy.
OK, I understand that this is happening because of schema violation, but nevertheless, I still need some advices or tips, how to avoid getting into trubles when upgrading the servers. Is there an easy way to get rid of the problem, but still using this type of suffix with country value longer that 2 characters?
Thanks a lot. Best Regards, Domen
OK, I understand that this is happening because of schema violation, but nevertheless, I still need some advices or tips, how to avoid getting into trubles when upgrading the servers. Is there an easy way to get rid of the problem, but still using this type of suffix with country value longer that 2 characters?
Slapcat and fix the values; the 2 character abbreviations are an ISO standard you can download. Modify your application to only accept legitimate country codes.
http://www.iso.org/iso/country_codes/iso_3166_code_lists/english_country_names_and_code_elements.htm
Adam Tauno Williams writes:
OK, I understand that this is happening because of schema violation, but nevertheless, I still need some advices or tips, how to avoid getting into trubles when upgrading the servers. Is there an easy way to get rid of the problem, but still using this type of suffix with country value longer that 2 characters?
Slapcat and fix the values; the 2 character abbreviations are an ISO standard you can download. Modify your application to only accept legitimate country codes.
http://www.iso.org/iso/country_codes/iso_3166_code_lists/english_country_names_and_code_elements.htm
Or use 'co' (friendlyCountryName) from cosine.schema instead, though a 'c' attribute is required as well for friendlyCountry objects.
Or if renaming the DIT is not feasible in the short run, edit core.schema for now and put back the OpenLDAP 2.3 definition of 'c', which came from RFC 2256. OpenLDAP 2.4 uses the RFC 4519 definition, which matches the X.500 definition. Note that editing an existing attribute's schema definition also requires a slapcat/slapadd. This will not interoperate with other software which expect 2-letter 'c' attributes, so you do need to move away from your current DIT.
Maybe attributes exist somewhere for 3-letter and numberic 3-digit country codes as well. If not, you could submit an internet-draft for such attributes. Or suggest changing 'c' to allow both 2- and 3-letter codes, though I doubt that would be accepted. The latter would also need to be coordinated with an X.500 change.
Or use 'co' (friendlyCountryName) from cosine.schema instead, though a 'c' attribute is required as well for friendlyCountry objects.
Or if renaming the DIT is not feasible in the short run, edit core.schema for now and put back the OpenLDAP 2.3 definition of 'c', which came from RFC 2256. OpenLDAP 2.4 uses the RFC 4519 definition, which matches the X.500 definition. Note that editing an existing attribute's schema definition also requires a slapcat/slapadd. This will not interoperate with other software which expect 2-letter 'c' attributes, so you do need to move away from your current DIT.
Maybe attributes exist somewhere for 3-letter and numberic 3-digit country codes as well. If not, you could submit an internet-draft for such attributes. Or suggest changing 'c' to allow both 2- and 3-letter codes, though I doubt that would be accepted. The latter would also need to be coordinated with an X.500 change.
-- Hallvard
Hi,
I've already considered the "co" option, but in fact, there is too much effort, because in that case also applications (many of them) should be modified and unfortunatelly the "c" part of the suffix is hardcoded ;( .
Your second suggestion about core schema changes seems to be the easiest way - there is almost nothing to do. So, all existing c values stays as they are (2+ letters), on fresh OpenLDAP 2.4 installations the values of "c" could be limited to 2 letters (although the schema would allow more). But, changing the core schema doesn's seem to be a good practice? If I still do that, what kind of unpredictable situations might I be confronted with?
Thanks for your quick response! Domen
Mavric Domen writes:
But, changing the core schema doesn's seem to be a good practice?
Indeed, therefore I said "for now" and "in the short run".
If I still do that, what kind of unpredictable situations might I be confronted with?
It won't interoperate with implementations that expect the RFC 4519 schema. Other unpatched 2.4 servers, clients that only reserve 2 characters for 'c' values. Various implementations are getting more strict about schema checking, that's the problem you've just run into after all.
And of course you need to edit the schema whenever you upgrade.
If you want to use a different convention that those defined in the schemas or RFCs, it's best to create your own attribute and your own schema and use it. Register your OID too if you want to use it or every have anyone else reference it outside of your own location.
Changing schemas or using attributes differently from how they were designed is a recipe for headache in the future.
ref: http://www.openldap.org/doc/admin24/schema.html http://support.novell.com/techcenter/articles/ana20010904.html Sellers
On Jul 24, 2008, at 7:17 AM, Mavric Domen wrote:
Or use 'co' (friendlyCountryName) from cosine.schema instead, though a 'c' attribute is required as well for friendlyCountry objects.
Or if renaming the DIT is not feasible in the short run, edit core.schema for now and put back the OpenLDAP 2.3 definition of 'c', which came from RFC 2256. OpenLDAP 2.4 uses the RFC 4519 definition, which matches the X.500 definition. Note that editing an existing attribute's schema definition also requires a slapcat/slapadd. This will not interoperate with other software which expect 2-letter 'c' attributes, so you do need to move away from your current DIT.
Maybe attributes exist somewhere for 3-letter and numberic 3-digit country codes as well. If not, you could submit an internet-draft for such attributes. Or suggest changing 'c' to allow both 2- and 3-letter codes, though I doubt that would be accepted. The latter would also need to be coordinated with an X.500 change.
-- Hallvard
Hi,
I've already considered the "co" option, but in fact, there is too much effort, because in that case also applications (many of them) should be modified and unfortunatelly the "c" part of the suffix is hardcoded ; ( .
Your second suggestion about core schema changes seems to be the easiest way - there is almost nothing to do. So, all existing c values stays as they are (2+ letters), on fresh OpenLDAP 2.4 installations the values of "c" could be limited to 2 letters (although the schema would allow more). But, changing the core schema doesn's seem to be a good practice? If I still do that, what kind of unpredictable situations might I be confronted with?
Thanks for your quick response! Domen
++++++++++++++++++++++++++++++++++++++ Chris G. Sellers | Internet Engineer | NITLE 734.661.2318 | chris.sellers@nitle.org Jabber: csellers@nitle.org | AIM: imthewherd
openldap-software@openldap.org
-
Adam Tauno Williams -
Chris G. Sellers -
Hallvard B Furuseth -
Mavric Domen