Page 1 of 2 12 LastLast
Results 1 to 10 of 11

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

  1. #1
    Join Date
    Mar 2009
    Location
    Memphis
    Posts
    30
    Rep Power
    6

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

    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

  2. #2
    Join Date
    May 2007
    Location
    Zimbra
    Posts
    1,285
    Rep Power
    10

    Default

    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.
    Quanah Gibson-Mount
    Server Architect
    Zimbra, Inc
    --------------------
    Zimbra :: the leader in open source messaging and collaboration

  3. #3
    Join Date
    Mar 2009
    Location
    Memphis
    Posts
    30
    Rep Power
    6

    Default

    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!
    Attached Files Attached Files

  4. #4
    Join Date
    May 2007
    Location
    Zimbra
    Posts
    1,285
    Rep Power
    10

    Default

    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.
    Quanah Gibson-Mount
    Server Architect
    Zimbra, Inc
    --------------------
    Zimbra :: the leader in open source messaging and collaboration

  5. #5
    Join Date
    Mar 2009
    Location
    Memphis
    Posts
    30
    Rep Power
    6

    Default

    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.

  6. #6
    Join Date
    Mar 2009
    Location
    Memphis
    Posts
    30
    Rep Power
    6

    Default

    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!

  7. #7
    Join Date
    Mar 2009
    Location
    Memphis
    Posts
    30
    Rep Power
    6

    Default

    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.

  8. #8
    Join Date
    May 2007
    Location
    Zimbra
    Posts
    1,285
    Rep Power
    10

    Default

    This means there is something wrong with your .install_history file. It should start with your current version.
    Quanah Gibson-Mount
    Server Architect
    Zimbra, Inc
    --------------------
    Zimbra :: the leader in open source messaging and collaboration

  9. #9
    Join Date
    Mar 2009
    Location
    Memphis
    Posts
    30
    Rep Power
    6

    Default

    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!?

  10. #10
    Join Date
    May 2007
    Location
    Zimbra
    Posts
    1,285
    Rep Power
    10

    Default

    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.
    Quanah Gibson-Mount
    Server Architect
    Zimbra, Inc
    --------------------
    Zimbra :: the leader in open source messaging and collaboration

Similar Threads

  1. Replies: 8
    Last Post: 12-23-2010, 10:17 AM
  2. Replies: 1
    Last Post: 03-08-2010, 03:24 AM
  3. 4.5.10 -> 5.0 upgrade fails
    By InternetGuy in forum Administrators
    Replies: 3
    Last Post: 01-12-2008, 02:44 PM
  4. Upgrade fails
    By pbucher in forum Administrators
    Replies: 5
    Last Post: 06-03-2006, 06:44 AM
  5. Error during upgrade: Duplicate key name 'i_name'
    By hodel in forum Installation
    Replies: 6
    Last Post: 04-27-2006, 07:57 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •