1:52 a.m.
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?
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
2:08 a.m.
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.
--
-- 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/
2:34 a.m.
New subject: "Upgrading from 2.3.x" section in Changes Appendix for Admin Guide
<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/
2:40 a.m.
New subject: "Upgrading from 2.3.x" section in Changes Appendix for Admin Guide
<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?
2:47 a.m.
New subject: "Upgrading from 2.3.x" section in Changes Appendix for Admin Guide
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.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
2:57 a.m.
New subject: "Upgrading from 2.3.x" section in Changes Appendix for Admin Guide
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)
3:23 a.m.
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.
--
-- 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/
6:37 a.m.
New subject: "Upgrading from 2.3.x" section in Changes Appendix for Admin Guide
<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....
9:46 a.m.
New subject: "Upgrading from 2.3.x" section in Changes Appendix for Admin Guide
<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.
3:54 p.m.
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.)
--
-- 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/
2:03 a.m.
New subject: "Upgrading from 2.3.x" section in Changes Appendix for Admin Guide
<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/
3:53 a.m.
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.
--
-- 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/
5:56 a.m.
New subject: "Upgrading from 2.3.x" section in Changes Appendix for Admin Guide
<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.
5683
days inactive
5684
days old
12 comments
2 participants
participants (2)
-
Gavin Henry -
Howard Chu