Hi All,
I think it's worth adding an upgrading section, as I'm just playing with a copy of a live 2.3.38 system and an upgrade to LDAP_REL_ENG_2_4 is giving:
olcReplicationInterval: value #0: <olcReplicationInterval> keyword is obsolete (ignored) str2entry: invalid value for attributeType objectClass #0 (syntax 1.3.6.1.4.1.1466.115.121.1.38) => ldif_enum_tree: failed to read entry for /usr/local/etc/openldap/slapd.d/cn=config/cn=include{0}.ldif slaptest: bad configuration file!
Admittedly, no slapcat was done as the bdb env is the same, but thought I'd do what a normal user would ;-)
Should we list obsolete values from bconfig.c that will apply and discuss/present the best way to upgrade?
Thoughts?
Gavin Henry wrote:
Hi All,
I think it's worth adding an upgrading section, as I'm just playing with a copy of a live 2.3.38 system and an upgrade to LDAP_REL_ENG_2_4 is giving:
olcReplicationInterval: value #0: <olcReplicationInterval> keyword is obsolete (ignored) str2entry: invalid value for attributeType objectClass #0 (syntax 1.3.6.1.4.1.1466.115.121.1.38) => ldif_enum_tree: failed to read entry for /usr/local/etc/openldap/slapd.d/cn=config/cn=include{0}.ldif slaptest: bad configuration file!
Admittedly, no slapcat was done as the bdb env is the same, but thought I'd do what a normal user would ;-)
Should we list obsolete values from bconfig.c that will apply and discuss/present the best way to upgrade?
Obsolete values don't matter; like the message said - it was simply ignored.
The problem you ran into here is that 2.3.x had cn=include entries (which were also ignored in 2.3) but support for them was axed in 2.4. So, just delete all the cn=include* files from the config directory.
<quote who="Howard Chu">
Gavin Henry wrote:
Hi All,
I think it's worth adding an upgrading section, as I'm just playing with a copy of a live 2.3.38 system and an upgrade to LDAP_REL_ENG_2_4 is giving:
olcReplicationInterval: value #0: <olcReplicationInterval> keyword is obsolete (ignored) str2entry: invalid value for attributeType objectClass #0 (syntax 1.3.6.1.4.1.1466.115.121.1.38) => ldif_enum_tree: failed to read entry for /usr/local/etc/openldap/slapd.d/cn=config/cn=include{0}.ldif slaptest: bad configuration file!
Admittedly, no slapcat was done as the bdb env is the same, but thought I'd do what a normal user would ;-)
Should we list obsolete values from bconfig.c that will apply and discuss/present the best way to upgrade?
Obsolete values don't matter; like the message said - it was simply ignored.
Yeah.
The problem you ran into here is that 2.3.x had cn=include entries (which were also ignored in 2.3) but support for them was axed in 2.4. So, just delete all the cn=include* files from the config directory.
Will do and move on. Thanks. It will be worth noting some upgrades gotchas for those running with slapd.d/
-- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
<quote who="Howard Chu">
Gavin Henry wrote:
Hi All,
I think it's worth adding an upgrading section, as I'm just playing with a copy of a live 2.3.38 system and an upgrade to LDAP_REL_ENG_2_4 is giving:
olcReplicationInterval: value #0: <olcReplicationInterval> keyword is obsolete (ignored) str2entry: invalid value for attributeType objectClass #0 (syntax 1.3.6.1.4.1.1466.115.121.1.38) => ldif_enum_tree: failed to read entry for /usr/local/etc/openldap/slapd.d/cn=config/cn=include{0}.ldif slaptest: bad configuration file!
Admittedly, no slapcat was done as the bdb env is the same, but thought I'd do what a normal user would ;-)
Should we list obsolete values from bconfig.c that will apply and discuss/present the best way to upgrade?
Obsolete values don't matter; like the message said - it was simply ignored.
The problem you ran into here is that 2.3.x had cn=include entries (which were also ignored in 2.3) but support for them was axed in 2.4. So, just delete all the cn=include* files from the config directory.
Next one:
olcReplicationInterval: value #0: <olcReplicationInterval> keyword is obsolete (ignored) str2entry: invalid value for attributeType olcDbConfig #3 (syntax 1.3.6.1.4.1.1466.115.121.1.15) => ldif_enum_tree: failed to read entry for /usr/local/etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif slaptest: bad configuration file!
That line is: olcDbConfig: {3}
Whole section is (ignore vim line no. prefix):
21 olcDbConfig: {0}# Suretec Systems Ltd. - GH - 09/03/2006 22 olcDbConfig: {1}# 23 olcDbConfig: {2}# Not changed from defaults, will tweak once we have more entr 24 ies 25 olcDbConfig: {3} 26 olcDbConfig: {4}# one 0.25 GB cache 27 olcDbConfig: {5}set_cachesize 0 268435456 1 28 olcDbConfig: {6} 29 olcDbConfig: {7}# Data Directory 30 olcDbConfig: {8}#set_data_dir db 31 olcDbConfig: {9} 32 olcDbConfig: {10}# Transaction Log settings 33 olcDbConfig: {11}set_lg_regionmax 262144 34 olcDbConfig: {12}set_lg_bsize 2097152 35 olcDbConfig: {13}#set_lg_dir logs 36 olcDbConfig: {14} 37 olcDbConfig: {15}# Note: special DB_CONFIG flags are no longer needed for "qui 38 ck" 39 olcDbConfig:: ezE2fSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl 40 aXIgLXEgb3B0aW9uKS4g
Remove the lot?
All of these questions and answers are to be written up, so please forgive some of them ;-)
We *know* when 2.4.5 beta is out, people will ask the same ones, so at least all of us can provide a link or reference thread.
Cheers.
Next one:
olcReplicationInterval: value #0: <olcReplicationInterval> keyword is obsolete (ignored) str2entry: invalid value for attributeType olcDbConfig #3 (syntax 1.3.6.1.4.1.1466.115.121.1.15) => ldif_enum_tree: failed to read entry for /usr/local/etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif slaptest: bad configuration file!
That line is: olcDbConfig: {3}
Whole section is (ignore vim line no. prefix):
21 olcDbConfig: {0}# Suretec Systems Ltd. - GH - 09/03/2006 22 olcDbConfig: {1}# 23 olcDbConfig: {2}# Not changed from defaults, will tweak once we have more entr 24 ies 25 olcDbConfig: {3} 26 olcDbConfig: {4}# one 0.25 GB cache 27 olcDbConfig: {5}set_cachesize 0 268435456 1 28 olcDbConfig: {6} 29 olcDbConfig: {7}# Data Directory 30 olcDbConfig: {8}#set_data_dir db 31 olcDbConfig: {9} 32 olcDbConfig: {10}# Transaction Log settings 33 olcDbConfig: {11}set_lg_regionmax 262144 34 olcDbConfig: {12}set_lg_bsize 2097152 35 olcDbConfig: {13}#set_lg_dir logs 36 olcDbConfig: {14} 37 olcDbConfig: {15}# Note: special DB_CONFIG flags are no longer needed for "qui 38 ck" 39 olcDbConfig:: ezE2fSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl 40 aXIgLXEgb3B0aW9uKS4g
Doh, just didn't like empty attributes:
olcDbConfig: {3}
to:
olcDbConfig: {3}# olcDbConfig: {6}# olcDbConfig: {9}#
etc.
Next one:
[root@suretec openldap]# slaptest monitor_back_register_entry_attrs(""): base="cn=databases,cn=monitor" scope=one filter="(namingContexts:distinguishedNameMatch:=dc=suretecsystems,dc=com)": unable to find entry
backend_startup_one: bi_db_open failed! (1) slap_startup failed (test would succeed using the -u switch)
Gavin Henry wrote:
Next one:
[root@suretec openldap]# slaptest monitor_back_register_entry_attrs(""): base="cn=databases,cn=monitor" scope=one filter="(namingContexts:distinguishedNameMatch:=dc=suretecsystems,dc=com)": unable to find entry
backend_startup_one: bi_db_open failed! (1) slap_startup failed (test would succeed using the -u switch)
Pretty sure you reported this in an ITS a while back. The monitor DB defaults to no anonymous read access. You need to define a rootDN for the monitor DB so that the registration functions can actually see the tree. (The registration ops try to run as the rootDN, but if none is set, that means a zero-length DN, i.e. anonymous.)
I think this is a flaw in the design of these registration ops in back-monitor, they shouldn't depend on an actual Search operation to get their work done. The monitor code ought to be able to directly locate the entry corresponding to a given BackendDB pointer, and whatever lookup should not require filter or ACL evaluation.
<quote who="Howard Chu">
Gavin Henry wrote:
Next one:
[root@suretec openldap]# slaptest monitor_back_register_entry_attrs(""): base="cn=databases,cn=monitor" scope=one filter="(namingContexts:distinguishedNameMatch:=dc=suretecsystems,dc=com)": unable to find entry
backend_startup_one: bi_db_open failed! (1) slap_startup failed (test would succeed using the -u switch)
Pretty sure you reported this in an ITS a while back. The monitor DB defaults to no anonymous read access. You need to define a rootDN for the monitor DB so that the registration functions can actually see the tree. (The registration ops try to run as the rootDN, but if none is set, that means a zero-length DN, i.e. anonymous.)
Ah, yes. That was for the translucent/rwm ticket I think.
I think this is a flaw in the design of these registration ops in back-monitor, they shouldn't depend on an actual Search operation to get their work done. The monitor code ought to be able to directly locate the entry corresponding to a given BackendDB pointer, and whatever lookup should not require filter or ACL evaluation.
I'm not qualified enough to comment yet....
<quote who="Howard Chu">
Gavin Henry wrote:
Next one:
[root@suretec openldap]# slaptest monitor_back_register_entry_attrs(""): base="cn=databases,cn=monitor" scope=one filter="(namingContexts:distinguishedNameMatch:=dc=suretecsystems,dc=com)": unable to find entry
backend_startup_one: bi_db_open failed! (1) slap_startup failed (test would succeed using the -u switch)
Pretty sure you reported this in an ITS a while back. The monitor DB defaults to no anonymous read access. You need to define a rootDN for the monitor DB so that the registration functions can actually see the tree. (The registration ops try to run as the rootDN, but if none is set, that means a zero-length DN, i.e. anonymous.)
With rootdn added, I now have a working 2.4.X slave with a 2.3.38 master via delta-syncrepl.
Can you remind me what you can write to in cn=monitor with a rootpw setting? I'm sure ando told me and I'll go dig in the archives.
Gavin.
Gavin Henry wrote:
With rootdn added, I now have a working 2.4.X slave with a 2.3.38 master via delta-syncrepl.
Can you remind me what you can write to in cn=monitor with a rootpw setting? I'm sure ando told me and I'll go dig in the archives.
Off the top of my head, you can modify the server's debug level, as well as the read-only setting for any database. (Same caveat about the read-only flag applies as for cn=config though - if you set the frontend to read-only, you can't make any more modifications, so you can't toggle it back again without restarting the server.)
<quote who="Howard Chu">
Gavin Henry wrote:
With rootdn added, I now have a working 2.4.X slave with a 2.3.38 master via delta-syncrepl.
Can you remind me what you can write to in cn=monitor with a rootpw setting? I'm sure ando told me and I'll go dig in the archives.
Off the top of my head, you can modify the server's debug level, as well as the read-only setting for any database. (Same caveat about the read-only flag applies as for cn=config though - if you set the frontend to read-only, you can't make any more modifications, so you can't toggle it back again without restarting the server.)
Ah, yes. I'm still looking for the other thread, so I'll doc this in the monitor section.
Maybe Ando will get chance to read over the monitor section, as it was written with 2.3.x in mind.
Gavin.
-- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Howard Chu wrote:
Gavin Henry wrote:
Should we list obsolete values from bconfig.c that will apply and discuss/present the best way to upgrade?
Obsolete values don't matter; like the message said - it was simply ignored.
The problem you ran into here is that 2.3.x had cn=include entries (which were also ignored in 2.3) but support for them was axed in 2.4. So, just delete all the cn=include* files from the config directory.
The cn=include issue is now fixed and should require no intervention.
<quote who="Howard Chu">
Howard Chu wrote:
Gavin Henry wrote:
Should we list obsolete values from bconfig.c that will apply and discuss/present the best way to upgrade?
Obsolete values don't matter; like the message said - it was simply ignored.
The problem you ran into here is that 2.3.x had cn=include entries (which were also ignored in 2.3) but support for them was axed in 2.4. So, just delete all the cn=include* files from the config directory.
The cn=include issue is now fixed and should require no intervention.
OK, thanks.