Suse9 3.1.2 upgrade failure

[DMRDave]

Hello. I recently attempted to upgrade from a functional 3.0.1 release on Suse Pro 9. This was to fix the SASL Auth problem noted here - SASL LOGIN authentication failure.

Below is the log from my install. Any idea from anyone where to go from here? Thank you.

I attached my install log as well. Additionally, I do have a backup so i can restore if needed. Thanks again.

dmrmail01:/zimbraInstallers/zcs # ./install.sh

Operations logged to /tmp/install.log.26298
Checking for existing installation...
zimbra-ldap...FOUND zimbra-ldap-3.0.1_GA_160
zimbra-logger...FOUND zimbra-logger-3.0.1_GA_160
zimbra-mta...FOUND zimbra-mta-3.0.1_GA_160
zimbra-snmp...FOUND zimbra-snmp-3.0.1_GA_160
zimbra-store...FOUND zimbra-store-3.0.1_GA_160
zimbra-apache...FOUND zimbra-apache-3.0.1_GA_160
zimbra-spell...FOUND zimbra-spell-3.0.1_GA_160
zimbra-core...FOUND zimbra-core-3.0.1_GA_160

Saving existing configuration file to /opt/zimbra/.saveconfig


PLEASE READ THIS AGREEMENT CAREFULLY BEFORE USING THE SOFTWARE.
ZIMBRA, INC. ("ZIMBRA") WILL ONLY LICENSE THIS SOFTWARE TO YOU IF YOU
FIRST ACCEPT THE TERMS OF THIS AGREEMENT. BY DOWNLOADING OR INSTALLING
THE SOFTWARE, OR USING THE PRODUCT, YOU ARE CONSENTING TO BE BOUND BY
THIS AGREEMENT. IF YOU DO NOT AGREE TO ALL OF THE TERMS OF THIS
AGREEMENT, THEN DO NOT DOWNLOAD, INSTALL OR USE THE PRODUCT.

License Terms for the Zimbra Collaboration Suite:
http://www.zimbra.com/license/collab...cense_1.0.html


Press Return to continue

Checking for prerequisites...
NPTL...FOUND
sudo...FOUND sudo-1.6.8p7-3.2
libidn...FOUND libidn-0.5.9-3
curl...FOUND curl-7.13.0-5.4
fetchmail...FOUND fetchmail-6.2.5-59
gmp...FOUND gmp-4.1.4-3

Checking for installable packages

Found zimbra-core
Found zimbra-ldap
Found zimbra-logger
Found zimbra-mta
Found zimbra-snmp
Found zimbra-store
Found zimbra-apache
Found zimbra-spell


The Zimbra Collaboration Suite appears already to be installed.
It can be upgraded with no effect on existing accounts,
or the current installation can be completely removed prior
to installation for a clean install.

Do you wish to upgrade? [Y] y

Select the packages to install
Upgrading zimbra-core
Upgrading zimbra-ldap
Upgrading zimbra-logger
Upgrading zimbra-mta
Upgrading zimbra-snmp
Upgrading zimbra-store
Upgrading zimbra-apache
Upgrading zimbra-spell

Installing:
zimbra-core
zimbra-ldap
zimbra-logger
zimbra-mta
zimbra-snmp
zimbra-store
zimbra-apache
zimbra-spell

The system will be modified. Continue? [N] y

Shutting down zimbra mail

Backing up ldap


Removing existing packages

zimbra-ldap...done
zimbra-logger...done
zimbra-mta...done
zimbra-snmp...done
zimbra-store...done
zimbra-spell...done
zimbra-apache...done
zimbra-core...done

Removing deployed webapp directories
Installing packages

zimbra-core......zimbra-core-3.1.2_GA_445.SuSEES9-20060530181808.i386.rpm...done
zimbra-ldap......zimbra-ldap-3.1.2_GA_445.SuSEES9-20060530181808.i386.rpm...done
zimbra-logger......zimbra-logger-3.1.2_GA_445.SuSEES9-20060530181808.i386.rpm...done
zimbra-mta......zimbra-mta-3.1.2_GA_445.SuSEES9-20060530181808.i386.rpm...done
zimbra-snmp......zimbra-snmp-3.1.2_GA_445.SuSEES9-20060530181808.i386.rpm...done
zimbra-store......zimbra-store-3.1.2_GA_445.SuSEES9-20060530181808.i386.rpm...done
zimbra-apache......zimbra-apache-3.1.2_GA_445.SuSEES9-20060530181808.i386.rpm...done
zimbra-spell......zimbra-spell-3.1.2_GA_445.SuSEES9-20060530181808.i386.rpm...done

Setting defaults from saved config in /opt/zimbra/.saveconfig/config.save
HOSTNAME=dmrmail01.dmrcom.com
LDAPHOST=
LDAPPORT=
SNMPTRAPHOST=dmrmail01.dmrcom.com
SMTPSOURCE=admin@dmrmail01.dmrcom.com
SMTPDEST=admin@dmrmail01.dmrcom.com
SNMPNOTIFY=yes
SMTPNOTIFY=yes
LDAPROOTPW=zimbra
LDAPZIMBRAPW=zimbra
Restoring existing configuration file from /opt/zimbra/.saveconfig/config.save...done
Operations logged to /tmp/zmsetup.log.29539
Setting defaults...Setting defaults from existing config...Done
Upgrading from 3.0.1_GA_160 to 3.1.2_GA_445
Thu Jun 1 20:33:31 2006: Stopping zimbra services
Thu Jun 1 20:33:33 2006: Checking mysql status
Thu Jun 1 20:33:33 2006: Starting mysql
Thu Jun 1 20:33:33 2006: SELECT value FROM config WHERE name = 'db.version'
Thu Jun 1 20:33:34 2006: Checking logger mysql status
Thu Jun 1 20:33:34 2006: Starting logger mysql
Thu Jun 1 20:33:35 2006: SELECT value FROM config WHERE name = 'db.version'
This appears to be 3.0.1_GA
Thu Jun 1 20:33:35 2006: Stopping mysql
An upgrade of the logger schema is necessary from version 2
Thu Jun 1 20:33:40 2006: Running /opt/zimbra/libexec/scripts/migrateLogger3-diskindex.pl
Thu Jun 1 20:33:41 2006: SELECT value FROM config WHERE name = 'db.version'
Thu Jun 1 20:33:41 2006: Verified schema version 2.
Thu Jun 1 20:33:41 2006: Adding Indices
Thu Jun 1 20:33:41 2006: alter table disk_aggregate add index i_device (device);
alter table disk_aggregate add index i_host (host);
alter table disk_aggregate add index i_period_start (period_start);
alter table disk_aggregate add index i_period_end (period_end);

Thu Jun 1 20:33:41 2006: SELECT value FROM config WHERE name = 'db.version'
Thu Jun 1 20:33:42 2006: Verified schema version 2.
Thu Jun 1 20:33:42 2006: Updating logger DB schema version from 2 to 3.
Thu Jun 1 20:33:42 2006: UPDATE zimbra_logger.config SET value = '3' WHERE name = 'db.version';

Thu Jun 1 20:33:42 2006: Running /opt/zimbra/libexec/scripts/migrateLogger4-loghostname.pl
Thu Jun 1 20:33:43 2006: SELECT value FROM config WHERE name = 'db.version'
Thu Jun 1 20:33:43 2006: Verified schema version 3.
Thu Jun 1 20:33:43 2006: Adding loghostname
Thu Jun 1 20:33:43 2006: alter table service_status add column loghostname VARCHAR(255) NOT NULL;

Thu Jun 1 20:33:44 2006: SELECT value FROM config WHERE name = 'db.version'
Thu Jun 1 20:33:44 2006: Verified schema version 3.
Thu Jun 1 20:33:44 2006: Updating logger DB schema version from 3 to 4.
Thu Jun 1 20:33:44 2006: UPDATE zimbra_logger.config SET value = '4' WHERE name = 'db.version';

Thu Jun 1 20:33:44 2006: Running /opt/zimbra/libexec/scripts/migrateLogger5-qid.pl
Thu Jun 1 20:33:45 2006: SELECT value FROM config WHERE name = 'db.version'
Thu Jun 1 20:33:45 2006: Verified schema version 4.
Thu Jun 1 20:33:45 2006: Adding loghostname
Thu Jun 1 20:33:45 2006: alter table mta add INDEX i_qid (qid);

Thu Jun 1 20:33:46 2006: SELECT value FROM config WHERE name = 'db.version'
Thu Jun 1 20:33:46 2006: Verified schema version 4.
Thu Jun 1 20:33:46 2006: Updating logger DB schema version from 4 to 5.
Thu Jun 1 20:33:46 2006: UPDATE zimbra_logger.config SET value = '5' WHERE name = 'db.version';

Thu Jun 1 20:33:46 2006: Stopping logger mysql
Thu Jun 1 20:33:50 2006: Migrating ldap data
/opt/zimbra/conf/slapd.conf: line 66: "attr" is deprecated (and undocumented); use "attrs" instead.
/opt/zimbra/conf/slapd.conf: line 73: "attr" is deprecated (and undocumented); use "attrs" instead.
/opt/zimbra/conf/slapd.conf: line 87: "attr" is deprecated (and undocumented); use "attrs" instead.
Thu Jun 1 20:33:51 2006: Checking ldap status
Thu Jun 1 20:33:51 2006: Starting ldap
Thu Jun 1 20:33:56 2006: ldap startup failed with exit code 1
UPGRADE FAILED - exiting

[KevinH]

Looks like all was ok until LDAP tried to start. Can you try to restart it with:

su - zimbra
sh -x /opt/zimbra/bin/ldap start

[DMRDave]

Another item of note:

If i attempt to start zimbra i get the following.

zimbra@dmrmail01:~> zmcontrol status
Cannot determine services - exiting
zimbra@dmrmail01:~> zmcontrol start
Host dmrmail01.dmrcom.com
Starting ldap...Done.
FAILED
sudo: /etc/sudoers is mode 0440, should be 0640
ERROR - failed to start slapd

Thank you for any assistance.

[DMRDave]

Nice Kevin. Thanks for your reply. This is what i get after your suggestion.

zimbra@dmrmail01:~> sh -x /opt/zimbra/bin/ldap start
+ PID=
+ PIDFILE=/opt/zimbra/openldap/var/run/slapd.pid
+ mkdir -p /opt/zimbra/openldap/var/run/
+ case "$1" in
+ start
+ checkrunning
+ getpid
+ '[' -f /opt/zimbra/openldap/var/run/slapd.pid ']'
+ '[' x = x ']'
+ RUNNING=0
+ '[' 0 = 0 ']'
+ '[' '!' -f /opt/zimbra/openldap-data/DB_CONFIG ']'
+ /opt/zimbra/libexec/zmconfigure /opt/zimbra/conf/slapd.conf.in /opt/zimbra/conf/slapd.conf
+ sudo /opt/zimbra/openldap-2.3.21/libexec/slapd -l LOCAL0 -4 -u zimbra -h ldap://:389/ -f /opt/zimbra/conf/slapd.conf
sudo: /etc/sudoers is mode 0440, should be 0640
+ sleep 2
+ getpid
+ '[' -f /opt/zimbra/openldap/var/run/slapd.pid ']'
+ '[' x = x ']'
+ echo 'ERROR - failed to start slapd'
ERROR - failed to start slapd
+ echo ''

+ exit 1

[DMRDave]

I changed the permissions of /etc/sudoers using the following:

chmod 0640 /etc/sudoers

then ran Kevin's command to manually start LDAP (as zimbra user)
sh -x /opt/zimbra/bin/ldap start

started the server to:
Host dmrmail01.dmrcom.com
antispam Running
antivirus Running
ldap Running
logger Stopped
zmlogswatchctl is not running
mailbox Running
mta Running
snmp Stopped
swatch is not running
spell Running


Thanks Kevin. I'm upgraded and functional. I'll look into the logger and snmp issues and start another post if need be. High marks for all the good work to the zimbra crew.

[jholder]

That's interesting. Did the upgrade script change the permissions by mistake? or did you do it by accident?

Anyone else have this issue?

[technikolor]

I had the very same problem. Upgrades from 3.1.1 to 3.1.2 went fine, but an upgrade of my running QA system from 3.0.1 direct to 3.1.2 failed just as yours did. The last line in the setup log was an ldapadd line and it had a single quote in the string (ie: "John's site") and so I assumed, wrongly, that it was the addition that caused the failure.

Out of despiration, an hour later I restored 3.0.1 from a backup, started it up to verify it was properly restored and running, and then upgraded it from 3.0.1 to 3.1.1 and then upgraded from 3.1.1 to 3.1.2. Didn't have a single problem.

So the take away for me is that rather than use a work-around I'll simply step my upgrades in production, since it just feels safer.

As a side note, I'll note that my biggest problems when moving back and forth between releases has been on /etc/sudoers. It'd be nice if rather than using the full paths with version numbers if the sudoers referenced a more generic path that wasn't changing every release. It'd sure cut down on a lot of problems, for me at least.

[Dirk]

I noticed this one when installing 3.1.1 onto Suse 10.1

To get around it, I opened a second terminal window while the install was progressing and constantly changed the permissions of the sudoers file to what the installer wanted it to be.

I've no idea why it happens, but it should be a simple enough fix.

[KevinH]

Quick reminder to file this in bugzilla if you've got enough details for us to reproduce.

[Dirk]

Thanks Kevin, it's logged now on Bugzilla at http://bugzilla.zimbra.com/show_bug.cgi?id=8315

While checking to see if it was already logged, I noticed this one: http://bugzilla.zimbra.com/show_bug.cgi?id=7941 regarding a new build for suse 10.1 and the last comment seems to imply that it's not going to happen? Of course, I'm not sure what is meant by 'Edison' and I know it's internal people talking to internal people, but I'm just curious if you guys will be making a build available for download for future versions that will work smoothly with suse 10.1 ? If not, I may be tempted to try to downgrade the server (or just start it again) as a suse 10.0 installation.

Thanks.