Two Drifters

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:

• zmcontrol stop (as zimbra)
• create the /backup/zimbra directory
• install rsync if necessary (here's a manpage)
• (as root) rsync -avHK /opt/zimbra/ /backup/zimbra/

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:

• if you started Zimbra and tried various things, shut it down, move /opt/zimbra to /opt/zimbra_2, so you can access any e-Mails which arrived in the meantime (they will be located in /opt/zimbra/data/postfix/spool/deferred – replace zimbra by zimbra_2 if you moved your folder)
• Restore your backup to /opt/zimbra
• Do not start Zimbra yet
• Edit the /etc/hosts file as follows:

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

• After that, you can run the zmsetservername, it will connect to the LDAP, and update all necessary files. No manual changes (apart from recreating the certificates) will be needed. If everything works, you will see output like the following:

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.

• Now you can (should) restart your system, and start Zimbra
• Go to the webadmin interface, and flush your mail queues. Wait a bit.
• if you had the other system running, and some additional mails arrived to the deferred queue, you can just copy & paste them into the /opt/zimbra/data/postfix/spool/deferred folder – complete with their paths, i.e. 0/whatever to 0/whatever.
  Change the permissions to postfix:postfix
  Flush again – some mails should arrive double, but it's better than loosing mails!

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:

• update the certificates
• /opt/zimbra/libexec files don't seem to be in the global PATH
• (maybe related to the problem above): logging does not work
• reenable postgrey