"Siôn Lloyd" wrote in message news:[email protected]...
On 26/06/12 11:42, Fred Zwarts (KVI) wrote:
"Siôn Lloyd" wrote in message
news:[email protected]...
On 26/06/12 10:45, Fred Zwarts (KVI) wrote:
In a separate server we run OpenDNSSEC with a configuration mirroring
the configuration of our master DNS server for testing purposes. In
this system we tried to upgrade from version 1.3.8 to 1.4.01a. When we
try to start OpenDNSSEC, we see the message:
ERROR: database version number incompatible with software; require 3,
found 2. Please run the migration scripts
I was not able to find the documentation about migration scripts. Could
someone help me to point to the documentation? Where are these
migration scripts and how am I supposed to run them?
Hi Fred.
In the root directory of the tarball there should be a file called
"MIGRATION" which has the instructions for changing the database schema.
For the 1.3 to 1.4 migration the instructions are under the section
"Migrating trunk". In short you need to run one of two scripts:
enforcer/utils/migrate_adapters_1.mysql
or
enforcer/utils/migrate_adapters_1.sqlite3
depending on your database choice.
They are just sql statements so can be run in many ways, e.g.:
sqlite3 [PATH_TO_DB] < enforcer/utils/migrate_adapters_1.sqlite3
Thank you.
Sion
Thanks, Siôn, for your reply.
I found the MIGRATION document, but there is no section 1.3 to 1.4.
(There are only sections about the 1.1 to 1.2 and about 1.2 to 1.3
migration.) So I read, as you said, the section about migrationg trunk.
But, in the enforcer/utils directory, there are no migrate_adapters_1
scripts. I see the following scripts:
migrate_id_mysql.pl
migrate_keyshare_mysql.pl
migrate_keyshare_sqlite3.pl
migrate_to_ng_mysql.pl
migrate_to_ng_sqlite.pl
I guess with database, you mean the kasp.db file and if I am correct this
is a sqlite3 database file, not a mysql file, so three of the five
scripts I do not need.
Do I need both other scripts? In which order?
Ah, apologies... The required migration scripts were not included in the
"a1" tarball; they are in the "a2" which is what I was looking at.
There are only 3 lines of SQL required to convert a v1.3 database to 1.4;
they are:
alter table zones add column in_type varchar(512) default "File";
alter table zones add column out_type varchar(512) default "File";
update dbadmin set version = 3;
The easiest thing might be to run:
"sqlite3 [PATH_TO_KASP.DB]"
then cut and paste the above into the terminal.
The scripts that you list above are for earlier versions, or preparation
for v2.0.
Sorry about that.
Sion
Thanks. That worked, I think. Most zones now run as before. For one zone I
see strange messages:
Jun 26 13:31:47 KVIVS13 ods-signerd: [engine] signer started
Jun 26 13:31:47 KVIVS13 ods-signerd: [hsm] unable to get key: key
c6cbe2b255ddd91b7d9ebb613eedb0dc not found
Jun 26 13:31:47 KVIVS13 ods-signerd: [zone] unable to publish dnskeys for
zone 0.6.0.0.8.0.a.1.0.1.6.0.1.0.0.2.ip6.arpa: error creating dnskey
Jun 26 13:31:47 KVIVS13 ods-signerd: [zone] unable to recover zone
0.6.0.0.8.0.a.1.0.1.6.0.1.0.0.2.ip6.arpa: corrupted file
Jun 26 13:31:47 KVIVS13 ods-signerd: [engine] unable to recover zone
0.6.0.0.8.0.a.1.0.1.6.0.1.0.0.2.ip6.arpa from backup, performing full sign
Jun 26 13:31:48 KVIVS13 ods-signerd: [signconf] zone
0.6.0.0.8.0.a.1.0.1.6.0.1.0.0.2.ip6.arpa signconf: RESIGN[PT7200S]
REFRESH[PT259200S] VALIDITY[PT1209600S] DENIAL[PT1209600S] JITTER[PT86400S]
OFFSET[PT3600S] NSEC[50] DNSKEYTTL[PT3600S] SOATTL[PT86400S]
MINIMUM[PT10800S] SERIAL[datecounter]
In the signer queue, I see this zone still in the configure state:
On Tue Jun 26 13:46:53 2012 I will [configure] zone
0.6.0.0.8.0.a.1.0.1.6.0.1.0.0.2.ip6.arpa
I'm worried about the "key ... not found" message and the "unable to publish
dnskeys" message. In the list shown with "ods-ksmutil key list --verbose" I
do not see c6cbe2b255ddd91b7d9ebb613eedb0dc:
0.6.0.0.8.0.a.1.0.1.6.0.1.0.0.2.ip6.arpa KSK dsready When
required (keypub) 2048 8
6bdf2e906c11612ef6aa969a331db5b1 SoftHSM 21061
0.6.0.0.8.0.a.1.0.1.6.0.1.0.0.2.ip6.arpa ZSK ready next
rollover (active) 1024 8
78c7dd05b98cff9b31bc90d5cb784ec6 SoftHSM 56050
0.6.0.0.8.0.a.1.0.1.6.0.1.0.0.2.ip6.arpa ZSK active 2012-08-22
17:02:12 (retire) 1024 8 8ac106af8e85056bbef28ca6f8106b95
SoftHSM 52464
0.6.0.0.8.0.a.1.0.1.6.0.1.0.0.2.ip6.arpa KSK active 2012-11-14
10:41:23 (retire) 2048 8 96c8b52a476c2c254c42b6b73320ee1c
SoftHSM 23881
(Also the other zones do not show this c6cbe2b255ddd91b7d9ebb613eedb0dc.)
In fact, apart from the messages in the log and the [configure] in the queue
list, everything looks normal. I wonder whether something is really wrong
and how it can be repaired.
_______________________________________________
Opendnssec-user mailing list
[email protected]
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
