7.2.2 -> 8.0.2 Upgrade fails because of duplicate zimbra.ldifs?

[dwfallin]

i'm trying to upgrade a 7.2.2 foss to 8.0.2 and its failing at the point of ldap migration with:

5126fc9e olcAttributeTypes: value #0 olcAttributeTypes: Duplicate attributeType: "1.2.840.113556.1.2.146"
5126fc9e config error processing cn={4}zimbra,cn=schema,cn=config: olcAttributeTypes: Duplicate attributeType: "1.2.840.113556.1.2.146"
slapadd: bad configuration directory!

i believe whats happening is there's 2 zimbra.ldif's at the point of migration:
root@server:/opt/zimbra/data/ldap/config/cn=config/cn=schema# ls -l
...
-rw------- 1 zimbra zimbra 3316 2013-02-22 00:05 cn={3}dyngroup.ldif
-rw------- 1 zimbra zimbra 445851 2013-02-15 00:38 cn={3}zimbra.ldif
-rw------- 1 zimbra zimbra 30213 2013-02-15 00:38 cn={4}amavisd.ldif
-rw------- 1 zimbra zimbra 551442 2013-02-22 00:05 cn={4}zimbra.ldif
-rw------- 1 zimbra zimbra 33138 2013-02-22 00:05 cn={5}amavisd.ldif
...

is this supposed to be this way? i found this appears to happen with a call to "zmldapschema" during the upgrade, which copies over the {4}zimbra.ldif and {5}amavisd.ldif - so when zmslapadd is run, it dies on the second zimbra.ldif (i think!?).
Is zmldapschema supposed to be over-writing the files that are already there (looks like it does with the core/cosine/etc)? if so - would i be correct in saying i should rename the zimbra and amavisd files just before that step is run so that they too get overwritten?

i'm just not comfortable with ldap yet so i'm not sure what all is happening with migration, etc.

thanks!
dwf

[quanah]

It sounds like you had an initial migration that failed on 2/15, and then you did a new migration on 2/22, at which point it already "knows" that a prior migration took place, so it doesn't re-do the upgrade steps necessary from going from 7.2.2 to 8.0.2.

You can delete the {3}zimbra.ldif and {4}amavisd.ldif to proceed past this point, but other things may fail because of the fact the system thinks various upgrade steps already succeeded. If you did this via a VM snapshot, I advise going back to before the upgrade attempt on 2/22, then editing your /opt/zimbra/.install_history and remove the traces of any 8.x upgrade in that file.

[dwfallin]

ahhhh.. so one of the upgrade steps is to take care of the ldifs? gotcha.

ok - so i had already rolled back (it IS a vm) to 7.2.2. i'm looking at the history though, and there's no mention of 8.0.X? we started on 5, upgraded to 6->7.1.0->7.2.1->7.2.2->7.2.2(64bit), and now trying to go to 8. looks like there's an extra attempt for 7.2.2 - that shouldn't cause a problem, right? (history attached)

i plan on trying again tonight, but if i've missed a step somewhere, i'd much prefer the safer route! please let me know if you see anything alarming in that history file (or if there's another file that would be more informative).

thanks!

[quanah]

If you look at zmupgrade.pm, there is a function named "upgradeLdap" that gets called before anything else is done. In that function is:

unlink("/opt/zimbra/data/ldap/config/cn\=config/cn\=schema/cn\=\{3\}zimbra.ldif");
unlink("/opt/zimbra/data/ldap/config/cn\=config/cn\=schema/cn\=\{4\}amavisd.ldif");

The other option is that root is unable to delete these files for some reason on your system.

[dwfallin]

ok - i'll look for that step and see if i can tell why its getting skipped/not able to do what its supposed to (and manually intervene if necessary). all of the ldif's are (currently) owned by zimbra:zimbra and are 600, root _should_ be able to rm them

thanks again - i'll post the results.

[dwfallin]

little late of a start tonight, so just a quick attempt. i started the install process, then when it gets to the point of asking 'system will be modified, continue?' - i manually moved the zimbra and amavis.ldifs from /opt/zimbra/data/ldap/cn=config/cn=schema/ to a temp location, then said continue. this time it errored:

Sun Feb 24 00:37:07 2013 *** Running as zimbra user: /opt/zimbra/bin/zmlocalconfig -f -e ssl_allow_untrusted_certs='true' 2> /dev/null
Sun Feb 24 00:37:07 2013 LDAP backup file /opt/zimbra/data/ldap/ldap.bak is empty. Oohhh... in the install.log i see:

COMMAND: /opt/zimbra/libexec/zmslapcat /opt/zimbra/data/ldap
5129a64f /opt/zimbra/data/ldap/config: line 1: unknown attr "zimbraZimletUserProperties" in to clause

apparently i moved the file too soon?
too late to try again tonight, i'll try again tomorrow and time the 'move' a little later. i'm still a bit concerned that some steps are being skipped because somewhere it thinks the upgrade to 8.0.X has already occurred, any way i could isolate that? (why the unlink steps are skipped?)

thanks for any insight! i feel like i'm close!

[dwfallin]

one more attempt - didn't get a chance to clear those ldifs out between the ldap backup and the ldap migration. BUT - i looked at the zmupgrade.pm, and it looks like whats happening is the startVersion is being identified as 5.0.14_GA (startMajor would be 5), so its not calling upgradeLdap(), its calling migrateLdap()? which doesn't have the steps to remove those ldifs! if someone can clarify it thats whats expected, i would appreciate it! should startVersion be the version that we initially installed or the version that we're on just before this upgrade? i'm digging around trying determine myself.

[quanah]

This means there is something wrong with your .install_history file. It should start with your current version.

[dwfallin]

i posted the install_history file (see third post), does that look wrong? it looks ok to me, but i'm not sure what i'm looking for!?

[quanah]

Your install_history is utterly broken. A normal one has the following pattern per release:

INSTALL SESSION START
...
INSTALL SESSION COMPLETE
CONFIG SESSION START
....
CONFIG SESSION COMPLETE

If you look at your install history file, the *only* release that successfully completed the CONFIG SESSION was the 5.0.14 installation. Every session since then got aborted.

I would advise you to: back up the .install_history file, then
delete lines 1 to 119, then make the last line of the file be:
1360906747: CONFIG SESSION COMPLETE

Then try upgrading.