Here are some pointers to useful tools and some solutions.
Good Geo IP location tool:
Reading large Zimbra log files:
/var/log/auth.log swamped by error messages (mail sudo: PAM adding faulty module: /lib/security/pam_smbpass.so):
This is an Ubuntu / Debian bug. Please follow this solution:
Zimbra admin guide (PDF):
The Zimbra installer uses an utility script to find out your distro and release:
/bin/get_plat_tag.sh
And the output of this determines which prerequisites the installer expects. This list of prerequisites is coded in
/util/utilfunc.sh
(search for "UBUNTU8" for instance)
In some cases, as in mine, this get_plat_tag.sh script may not detect your distro and/or version correctly which may lead to screw-ups with required prerequisites. You may want to use this dirty hack to solve the problem: modify the get_plat_tag.sh script at the very beginning to echo the distro and release you want (actually need) it to echo by inserting:
#quickfix
echo "DEBIAN5_64"
exit 0
You may find yourself running into missing requirements, in my case it was MISSING: libgmp3 – although I can't install this package (I have to use libgmp3c2 which was already installed and is the correct requirement for other distros). After setting the correct distro and release the installation was without problems!
In Zimbra Release 6.0.6_GA_2324.DEBIAN5_64 UBUNTU8_64 FOSS edition I had the problem, that a zmcontrol status would always show the service stats as stopped, no matter how often you would stop and start all services. After reading a bit on the Zimbra forums, I managed to fix that.
Do (as root):
chown -R zimbra:zimbra /opt/zimbra/zmstat
/opt/zimbra/bin/zmsyslogsetup
These are the two commands you need to run. After that, su zimbra to become the user zimbra and zmcontrol stop and zmcontrol start your server. Voilá, zmcontrol status should now show the stats as running.
Apparently the problem is, that some directories stats tries to access are set up incorrectly with the owner root instead of Zimbra. The error is reported to randomly occur again, so you may need to repeat the chown part.
Also see these websites for further details:
In general, you should follow this guide. Use this article for some extra information.
/usr/sbin/postgrey
my $VERSION = '1.33';
my $DEFAULT_DBDIR = '/var/spool/postfix/postgrey';
my $CONFIG_DIR = '/etc/postfix';(…)
whitelist_clients_files => $opt{'whitelist-clients'} ||
[ "$CONFIG_DIR/postgrey_whitelist_clients" ,
"$CONFIG_DIR/postgrey_whitelist_clients.local" ],
whitelist_recipients_files => $opt{'whitelist-recipients'} ||
[ "$CONFIG_DIR/postgrey_whitelist_recipients" ],
/etc/default/postgrey
POSTGREY_OPTS="–inet=127.0.0.1:60000"
Postgrey has to be installed, sometimes you have to do it manually. (It's a Perl script, which you can get here: http://postgrey.schweikert.ch/
The excerpt above should help you to set up and locate the proper locations of the files. There is an init.d script for Debian, which I am using.
You might want to get the postgrey package from Debian and try to understand the installation process from it, if you're stuck in a similar situation.
The command which the Debian install script uses to set up the run levels:
update-rc.d postgrey defaults 19 >/dev/null
To start postgrey use:
/etc/init.d/postgrey start
And then as user zimbra:
postfix reload
Postgrey is now set up on your system.
Nochmal durfte ich lernen: das DNS System ist einer der Angelpunkte eines IT-Unternehmens.
Deswegen muss es sowohl in der Hand eines erfahreren Administrators sein, als auch dieser immer Zugriff zu haben.
In meinem Fall sind das noch Nachwirkungen der Benutzung eines "Dumping-Providers" für Domains. Ich hatte darüber bereits einmal geschrieben.
Jetzt bin ich bei HTTP.net mit den Domains, die eine Domain (7vi.de) ließ sich aber nicht portieren da ich sie im System des alten Anbieters nicht lokalisieren konnte.
Unser System war zuletzt eine Mischung aus 7vi.de und ideaday.de;
Leider habe ich mich nicht rechtzeitig darum gekümmert, alles auf ideaday.de umzustellen. Als gestern abend 7vi.de wohl zu einem anderen Anbieter umgezogen & die DNS Einträge nicht ordnungsgemäß übernommen wurden, kam es in Zimbra heute zu einem Mailstau: die Mails konnten nicht mehr ausgeliefert werden, da das Zielsystem mail.7vi.de nicht erreichbar war.
Zimbra, LDAP and changing the hostname
We had the problem that we lost DNS administration control over one of our domains, which Zimbra was running on. Today I learned the hard way, that Zimbra depends on this external DNS servers, even for internal mail delivery.
Backup before using zmsetservername! It might be needed sorely later on!
Use the following to backup:
You might want to have a look at this Zimbra page, where I lifted the command from a script.
Proper DNS is essential for changing the hostname!
The best way to avoid trouble is to ensure, before changing the hostname, that the target host the LDAP server is running on (in my case identical with the main Zimbra host) is reachable. If it's not, add it into the /etc/hosts file. (see below)
If you use zmsetservername to change the hostname (which is the only sensible way to do it, and usually works painlessly on 6.0+ systems), you might get a connection error to the LDAP server.
Starting ldap…done.
Unable to contact ldap://mail.oldhost.de:389: Connection refused
Unable to contact ldap://mail.oldhost.de:389: Connection refused
Attention: if you get this error when running zmsetservername, important parts of your configuration (including the accounts) have not been updated. Do not start Zimbra (thus accepting mails, which you would loose if restoring from backup). It will not work!
If you get the error:
127.0.0.1 localhost.localdomain localhost
# Auto-generated hostname. Please do not remove this comment.
<your-IP> mail.newhost.de mail mail.oldhost.de
mail.7vi.de being the old hostname not being accessible anymore. Check that it is resolved once again
Starting ldap…done.
Searching for ldap server entry…done.< BR>Renamingcn=mail.oldhost.de,cn=servers,cn=zimbra…done.
Updating zimbraServiceHostnameforcn=mail.newhost.de,cn=servers,cn=zimbra…done.
Updating zimbraMtaAuthHostforcn=mail.newhost.de,cn=servers,cn= zimbra…Updating zimbraSpellCheckURLforcn=mail.newhost.de,cn=servers,cn=zimbra…done.
Updating zimbraSmtpHostnameforcn=mail.newhost.de,cn=servers,cn=zimbra…done.
Updating zimbraVirtualHostname fordc=oldhost,dc=de…done.
Updating zimbraLogHostname forcn=config,cn=zimbra…done.
Updating zimbraMailHost for uid=admin,ou=people,dc=mail,dc=somehost,dc=de…done.
zmsetservername is located in /opt/zimbra/libexec by the way. It would not work without the prepended path for me either.
If you want to go the other way and fix LDAP routing: good luck, we tried for like 3 hours to get it going. Don't forget, that you still need to update the users and a lot more other information. Trust me, restoring the backup is a better idea.
slapd will be running, but Zimbra won't be able to connect to it. As LDAP is at the core of Zimbra, your possibilities will be limited. You can use
ps auxww | grep zimbra | grep slapd
to check whether slapd is running. This page might be a good start to try and solve the LDAP problems, if you have to do it that way. Remember: you probably need to run zmsetservername once again, or do the steps it does for you – as it could not connect to the LDAP before!
Problems still needing fixing:
IMPORTANT:
Please read my new article Zimbra upgrade without tears before reading this article. It may save you a lot of work by fixing the cause of the problem instead of the symptoms!
And here is the original article:
The whole story started with the server suddenly not delivering mails anymore – in and outbound ones. For those who know the story: yes, it's the 15. of April. 1 of April would have been more appropriate, somehow.
http://www.clamav.net/lang/en/2009/10/05/eol-clamav-094/
The gist of the story: ClamAV wants users to upgrade to a newer version, so they stopped releases older than 0.95 artificially from working. Thus bringing this mail server (and probably quite a bunch of others, too) down.
So … the upgrade which we were planning to do anyways suddenly became necessary for the server to perform.
We were running Zimbra 5.0.11 on Debian 4, 64bit.
Zimbra 6 for Debian 4 is offered only in the 32bit flavour, which refuses to install on a 64bit platform.
So, we upgraded Debian 4 to Debian 5. (modify /etc/apt/sources.conf, run apt-get dist-upgrade. See Debian documentation for specifics).
Trying to install Zimbra 6.0.6 with the provided script failed – Perl / libperl is too "new" at version 5.10. It should be at version 5.8 – install.sh will not proceed.
Checking for suggested prerequisites…
FOUND: perl-5.8.8
After forcing a downgrade – look at this post for a how-to – the installer proceeded without problems up until a point where it failed throwing a Perl error without recovering.
/usr/bin/perl: symbol lookup error: /opt/zimbra/zimbramon/lib/x86_64-linux-gnu-thread-multi/auto/IO/IO.so: ndefined symbol: Perl_Istack_sp_ptr
# su zimbra
$ zmcontrol status
would throw the same or a similar (Perl) error afterwards:
perl: symbol lookup error: /opt/zimbra/zimbramon/lib/x86_64-linux-gnu-thread-multi/autundefined symbol: Perl_Istack_sp_ptr
Luckily, a guy named Jiménez (kudos!) posted the solution to get the upgrade running:
"a perl script (/opt/zimbra/libexec/zmsetup.pl) was run to setup some preferences to the installation before it started the server. I ran it manually, and my problems were solved."
What Jiménez did not mention: you need to have the newest Perl for this script to work – else it will fail with similar errors. So upgrade again (unlock pinned files if you did pin them = force them to be at the version 5.8.8):
# apt-get install perl
(… installs perl – the newest version … )# perl -v
This is perl, v5.10.0 built for x86_64-linux-gnu-thread-multi# /opt/zimbra/libexec/zmsetup.pl
Operations logged to /tmp/zmsetup.04162010-194935.log
Installing LDAP configuration database…done.
Upgrading from 5.0.10_GA_2638 to 6.0.6_GA_2324
Stopping zimbra services…done.
Verifying /opt/zimbra/conf/my.cnf
Starting mysql…done.
This appears to be 5.0.10_GA
Installing LDAP configuration database…done.
Migrating ldap data…done.
Checking ldap status…not running.
Running zmldapapplyldif…done.
Checking ldap status…already running.
Checking ldap status…already running.
Redolog version update required.
Fri Apr 16 19:51:03 2010: Verified redolog version 1.23.
Fri Apr 16 19:51:03 2010: Updating Redolog schema version from 1.23 to 1.28.
Redolog version update finished.
Schema upgrade required from version 53 to 64.
Running /opt/zimbra/libexec/scripts/migrate20080930-MucService.pl
Fri Apr 16 19:51:07 2010: Verified schema version 53.
Fri Apr 16 19:51:13 2010: Verified schema version 53.
Fri Apr 16 19:51:13 2010: Updating DB schema version from 53 to 60.
Running /opt/zimbra/libexec/scripts/migrate20090315-MobileDevices.pl
Fri Apr 16 19:51:15 2010: Verified schema version 60.
Fri Apr 16 19:51:15 2010: Adding ZIMBRA.MOBILE_DEVICES table.
Fri Apr 16 19:51:17 2010: Verified schema version 60.
Fri Apr 16 19:51:17 2010: Updating DB schema version from 60 to 61.
Running /opt/zimbra/libexec/scripts/migrate20090406-DataSourceItemTable.pl
Fri Apr 16 19:51:20 2010: Verified schema version 61.
Fri Apr 16 19:54:16 2010: Verified schema version 61.
Fri Apr 16 19:54:16 2010: Updating DB schema version from 61 to 62.
Running /opt/zimbra/libexec/scripts/migrate20090430-highestindexed.pl
Fri Apr 16 19:54:20 2010: Verified schema version 62.
Fri Apr 16 19:54:20 2010: Adding idx_deferred_count column to Mailbox table.
Fri Apr 16 19:54:22 2010: Verified schema version 62.
Fri Apr 16 19:54:22 2010: Updating DB schema version from 62 to 63.
Running /opt/zimbra/libexec/scripts/migrate20100106-MobileDevices.pl
Fri Apr 16 19:54:24 2010: Verified schema version 63.
Fri Apr 16 19:54:24 2010: Adding policy_values column to ZIMBRA.MOBILE_DEVICES table.
Fri Apr 16 19:54:25 2010: Verified schema version 63.
Fri Apr 16 19:54:25 2010: Updating DB schema version from 63 to 64.
Stopping mysql…done.
Updating from 5.0.11_GA
Updating from 5.0.12_GA
Updating from 5.0.13_GA
Updating from 5.0.14_GA
Updating from 5.0.15_GA
Updating from 5.0.16_GA
Updating from 5.0.17_GA
Updating from 5.0.18_GA
Updating from 5.0.19_GA
Updating from 5.0.20_GA
Updating from 5.0.21_GA
Updating from 5.0.22_GA
Updating from 5.0.23_GA
Updating from 6.0.0_BETA1
Migrating all domain admins to ACL based access manager…done.
Checking for default IM conference room…not present.
Initializing default IM conference room…done.< BR>Deletedcn=mime,cn=config,cn=zimbra
Updating from 6.0.0_BETA2
Updating from 6.0.0_RC1
Updating from 6.0.0_RC2
Updating from 6.0.0_GA
Updating from 6.0.1_GA
Updating from 6.0.2_GA
Updating from 6.0.3_GA
Updating from 6.0.4_GA
Updating from 6.0.5_GA
Updating from 6.0.6_GA
Updating global config and COS's with attributes introduced after 5.0.10_GA…done.
Stopping ldap…done.
Upgrade complete.Running bdb db_recover…done.
Running zmldapapplyldif…done.
Checking ldap status….already running.
Setting defaults…done.
Setting defaults from existing config…done.
Checking for port conflicts
Port conflict detected: 7306 (zimbra-store)
Port conflicts detected! – Any key to continue
Setting defaults from ldap…
Port conflict detected: 7306 (zimbra-store)
Debugging this error:
# netstat -lntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 78.47.177.193:389 0.0.0.0:* LISTEN 3157/slapd
tcp 0 0 127.0.0.1:7306 0.0.0.0:* LISTEN 19601/mysqld
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 9494/sshd
tcp6 0 0 :::22 :::* LISTEN 9494/sshd
Apparently there's something on the port which should not be there. At this point your mail server is back up again, although messages will probably not get delivered and queue up:
# su zimbra
$ zmcontrol status
Host mail.example.de
antispam Running
antivirus Running
ldap Running
logger Running
mailbox Stopped
mysql.server is not running.
mta Running
snmp Running
spell Running
stats Stopped
As you can see, the mailbox is stopped and the mysql server is not running. (Aside from a talent of stating the seemingly obvious, I'm also a great problem solver. Watch me:)
# su zimbra
$ zmcontrol stop
$ zmcontrol start
$ zmcontrol status
antispam Running
antivirus Running
ldap Running
logger Running
mailbox Running
mta Running
snmp Running
spell Running
stats Running
That was about the easiest part of the upgrade. Respect to the Zimbra guys for packaging the remainder of the process up so nicely! Zimbra way rocks.
Note: I do not know, whether you can directly call the upgrade script (/opt/zimbra/libexec/zmsetup.pl) without running install.sh first. I think, no:
It (install.sh) DID set up several values on the first successful run (Perl needing to be at 5.8.8, remember?):
# ./install.sh –platform-override
Operations logged to /tmp/install.log.5176
Checking for existing installation…
zimbra-ldap…FOUND zimbra-ldap-5.0.10_GA_2638.UBUNTU8_64
zimbra-logger…FOUND zimbra-logger-5.0.10_GA_2638.UBUNTU8_64
zimbra-mta…FOUND zimbra-mta-5.0.10_GA_2638.UBUNTU8_64
zimbra-snmp…FOUND zimbra-snmp-5.0.10_GA_2638.UBUNTU8_64
zimbra-store…FOUND zimbra-store-5.0.10_GA_2638.UBUNTU8_64
zimbra-apache…FOUND zimbra-apache-5.0.10_GA_2638.UBUNTU8_64
zimbra-spell…FOUND zimbra-spell-5.0.10_GA_2638.UBUNTU8_64
zimbra-convertd…NOT FOUND
zimbra-memcached…NOT FOUND
zimbra-proxy…NOT FOUND
zimbra-archiving…NOT FOUND
zimbra-cluster…NOT FOUND
zimbra-core…FOUND zimbra-core-5.0.10_GA_2638.UBUNTU8_64
ZCS upgrade from 5.0.10 to 6.0.6 will be performed.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/zimbra_public_eula_2.1.htmlPress Return to continue
Checking for prerequisites…
FOUND: NPTL
FOUND: sudo-1.6.9p17-2闩
FOUND: libidn11-1.8괺1
FOUND: libpcre3-7.6-2.1
FOUND: libgmp3c2-2:4.2.2痻3
FOUND: libexpat1-2.0.1-4闩
FOUND: libstdc4.4.2-9
FOUND: libperl5.8-5.8.8-7etch6
Checking for suggested prerequisites…
FOUND: perl-5.8.8
FOUND: sysstat
Prerequisite check complete.
Checking current number of databases…
df: no file systems processedDo you want to verify message store database integrity? [Y]
Verifying integrity of message store databases. This may take a while.
mysqld is alive
No errors found
mysqld is alive
Killing mysqld with pid 5694 done.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
Found zimbra-memcached
Found zimbra-proxyThe 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]
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-spellInstall zimbra-memcached [N]
Install zimbra-proxy [N]
Checking required space for zimbra-core
checking space for zimbra-storeInstalling:
zimbra-core
zimbra-ldap
zimbra-logger
zimbra-mta
zimbra-snmp
zimbra-store
zimbra-apache
zimbra-spellYou appear to be installing packages on a platform different
than the platform for which they were built.This platform is UBUNTU8_64
Packages found: DEBIAN5_64
This may or may not work.Using packages for a platform in which they were not designed for
may result in an installation that is NOT usable. Your support
options may be limited if you choose to continue.Install anyway? [N] Yes
The system will be modified. Continue? [N] Yes
Shutting down zimbra mail
Backing up the ldap database…done.
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…doneRemoving deployed webapp directories
Installing packageszimbra-core……zimbra-core_6.0.6_GA_2324.DEBIAN5_64_amd64.deb…done
zimbra-ldap……zimbra-ldap_6.0.6_GA_2324.DEBIAN5_64_amd64.deb…done
zimbra-logger……zimbra-logger_6.0.6_GA_2324.DEBIAN5_64_amd64.deb…done
zimbra-mta……zimbra-mta_6.0.6_GA_2324.DEBIAN5_64_amd64.deb…done
zimbra-snmp……zimbra-snmp_6.0.6_GA_2324.DEBIAN5_64_amd64.deb…done
zimbra-store……zimbra-store_6.0.6_GA_2324.DEBIAN5_64_amd64.deb…done
zimbra-apache……zimbra-apache_6.0.6_GA_2324.DEBIAN5_64_amd64.deb…done
zimbra-spell……zimbra-spell_6.0.6_GA_2324.DEBIAN5_64_amd64.deb…doneSetting defaults from saved config in /opt/zimbra/.saveconfig/config.save
HOSTNAME=mail.example.de
LDAPHOST=mail.example.de
LDAPPORT=389
SNMPTRAPHOST=mail.example.de
(…)
SNMPNOTIFY=yes
SMTPNOTIFY=yes
LDAPROOTPW=
LDAPZIMBRAPW=
LDAPPOSTPW=
LDAPREPPW=
LDAPAMAVISPW=
LDAPNGINXPW=
Restoring existing configuration file from /opt/zimbra/.saveconfig/localconfig.xml…done
/usr/bin/perl: symbol lookup error: /opt/zimbra/zimbramon/lib/x86_64-linux-gnu-thread-multi/auto/IO/IO.so: ndefined symbol: Perl_Istack_sp_ptr
Please ignore the screwed up error about us not running on Debian (which we are) – I think it's not part of this problem with Perl. It actually is the cause of the whole series of problems – see this update on upgrading Zimbra.
I hope this helps you. Would be nice if you leave comments and further tips how to fix this.
G'night. – Max
NetDNA - The Science of Acceleration.