Zimbra

When you click on a mailto: link, most of the time your Firefox will launch that version of Outlook Express or Apple Mail you never configured. For the novice user, they click next, next, next, next, then send their e-mail…and it never gets delivered. Well using a greasemonkey script that we’ll convert to a firefox extension, we can handle the mailto links.

This morning, I clicked on a link thinking it would take me to a “Contact us” form, but it was a mailto: link. I was a little annoyed that Apple Mail opened, and I thought: I wonder if there’s a way to change that link to open ZCS?

Well, I found a cool little hack using GreaseMonkey and a site that compiles GreaseMonkey scripts to an xpi extension.

First, some pre-requisites:
You’ll need ZCS 4.5.0 or newer.
This is a Firefox only hack. Sorry IE and Safari users.

This is a GreaseMonkey script for GMail. All we’re going to do is change the URL from GMail to your ZCS server. The script is licensed under GPL, and if you use it, please note that you MUST abide by the coder’s License guidelines. The script was written by Julien Couvreur.

Copy all of the text to your favorite text editor.

Now, in your text editor, you’re going to change a few lines.

Change:
# // ==UserScript==
# // @name Mailto Compose In GMail
# // @namespace http://blog.monstuff.com/archives/000238.html
# // @description Rewrites “mailto:” links to GMail compose links
# // @include *
# // @exclude http://gmail.google.com
# // ==/UserScript==

To:
# // ==UserScript==
# // @name Mailto Compose In Zimbra
# // @namespace http://blog.monstuff.com/archives/000238.html
# // @description Rewrites “mailto:” links to Zimbra compose links
# // @include *
# // @exclude http://mail.domain.com
# // ==/UserScript==

**Replace https and mail.domain.com with your server name.

and Change:
mailtoLink.href = “https://mail.google.com/mail?view=cm&tf=0″ +
(emailTo ? (“&to=” + emailTo) : “”) +
(emailCC ? (“&cc=” + emailCC) : “”) +
(emailSubject ? (“&su=” + emailSubject) : “”) +
(emailBody ? (“&body=” + emailBody) : “”);
// mailtoLink.onclick = function() { location.href = newUrl; return false; };

To:
mailtoLink.href = “https://mail.server.com/zimbra/h/search?action=compose” +
(emailTo ? (“&to=” + emailTo) : “”) +
(emailCC ? (“&cc=” + emailCC) : “”) +
(emailSubject ? (“&subject=” + emailSubject) : “”) +
(emailBody ? (“&body=” + emailBody) : “”);
// mailtoLink.onclick = function() { location.href = newUrl; return false; };

**Be sure to replace https with http or https (depending on if you use SSL). Also, be sure to replace mail.server.com with your Zimbra server address.

Now, go to this website:
http://arantius.com/misc/greasemonkey/script-compiler

And fill in the text areas. Leave the GUID the same, and copy and paste your new script into the script text area, then hit compile.

It will ask you to save the xpi file. Once you save it, Open Firefox, then click file->Open and locate your XPI. Restart firefox, and all of your mailto: links now point to the Zimbra server.

Thanks and credit go to:
Julien Couvreur who wrote the script
Anthony Lieuallen for the web based GreaseMonkey to Firefox Extension converter
cubicgarden for the flickr GreaseMonkey photo.

Gmail™ webmail service is a registered trademark of Google, Inc.
Firefox is a registered trademark of Mozilla, Inc.
Also, these sites and scripts are not hosted or affiliated with Zimbra or Yahoo.

In this Zimbra Administrator’s PowerTip, we’ll discuss how to move your instance of Zimbra to another machine. It applies to all version of Zimbra.

(more…)

Configuring BIND and Zimbra
on the same machine is a hot topic over in the forums. Zimbra checks to make sure that you have the correct MX an A records. In this Administrator’s PowerTip, we’ll discuss how to install and setup BIND and Zimbra on the same machine.

(more…)

The reasons can vary from an emergency restore of user accounts, to changing system architecture. In this Administrator’s PowerTip we will discuss how to export(dump) LDAP data to disk, and re import it.

(more…)

As many of our Administrators know, Zimbra Collaboration Suite logs just about everything. One of the most integral is the mailbox.log located in /opt/zimbra/log .

In this Administrator’s PowerTip, we’ll cover some common entries in the mailbox.log file, and what they mean.
*Note- This is an administrator PowerTip intended for System Administrators of Zimbra Collaboration Suite.

(more…)

Zimbra community members are often asking us how to integrate Zimbra with Samba in order to replace their current directory with Zimbra LDAP. User lfarkas, posted an article to Zimbra wiki where he wrote: “If we can manage posix and samba account in Zimbra’s LDAP server through Zimbra admin UI, than we’ve got everything (we only must configure Samba to use Zimbra’s LDAP server) and in this case that can be a real killer app!”.

(more…)

ZCS 4.5 helps make admins’ jobs easier — a lot easier in some cases. This post discusses advanced search in the admin console, backup and restore in the admin console, backup performance improvements, and good policies for creating a recoverable system.

Advanced Search for Users, Domains, Servers
We’ve added an advanced search capability to the admin console. It includes a search builder similar to what has been available in the end user client. We had heard from many customers that they wanted to create complex searches, such as “show me all domains with xyz in them” or “show me all users on server 3″ or “show me all users with last name xyz on server 5″. You can construct all these searches and quite a few more now, and since the search uses LDAP indexes it’s fast. This feature is AJAX helping admins.

Backup and Restore in the Admin Console
For the ZCS 4.5 Network Edition release we’ve also done a lot to help your success with backup and restore. First, we’ve extended the admin console’s ability to manage the backup and restore process. From the admin console you can now review all the backups, both fulls and incrementals, that exist on your system, and whether they ran successfully or not. You can also initiate an immediate backup. As in previous versions you can restore a single account, either to itself (the same account name) or to a new account. You can also choose whether you want to restore to a particular full or to “now”, applying all the data that is available for that account.

For the next major release we’ll add point in time recovery in the admin console. This will enable you to restore any mailbox (or set of mailboxes) to any point in time for which you have backups. For example, you could restore Sally’s mailbox to Sally_restored using data from 3PM last Tuesday, when she knows she had the key message she needs. Note that point in time recovery is already available with the CLI (zmrestore).

Backup Performance Improvements
We’ve also made some big improvements to backup performance on the server in 4.5. The main source of the improvements is an increased ability to make multiple concurrent i/o requests of the system when copying data. After some experimentation we decided to copy with a pool of worker threads, each of which takes responsibility for the serial copy of a particular file. There are, of course, enough files that need to be touched that this provides for as much parallelism as the disk system can handle. If you have i/o bandwidth available with 4.0’s backups you will see a decrease in backup time. Our tests showed solid improvements. We’ve seen initial full backups on systems with 1000 users (3 U320 10K RPM disks) take 40% of the time of 4.0. Subsequent full backups are even faster, taking only 18% of the time required by 4.0 code. Your mileage may vary of course, but we think you’ll like it.

Backup Management and Risks
Speaking of backups, you are running them, aren’t you? I’ve been surprised at the support cases we see where customers have either never set up backups or are doing backups on to the same disk (even the same partition) as their data. Remember that there are bugs in every piece of software — filesystem, drivers, firmware, even ZCS — and you need to protect against them as well as disk failure. Keeping your backup on the same partition as your data leaves you vulnerable, even if you have a RAID backing store.

To check what backup schedule you have, run the following (Note: all commands that follow should be run as the zimbra user):

zmschedulebackup -q

You’ll (hopefully) see something like:

Current Schedule:
f 0 1 * * 0
i 0 1 * * 1-6
d 1m 0 0 * * *

The results show when fulls (f), incrementals (i), and deletions (d) will run using standard crontab syntax. (In fact, this information is pulled from crontab for the zimbra user; cron invokes zmbackup for all these operations.) If you don’t get any output back, you don’t have backups running! The schedule above shows that fulls are run on Sundays at 1 AM and incrementals every other day at 1 AM. It also says that every day at midnight any backups older than 1 month will be purged.

If you don’t have backups configured, or don’t understand what you do have, there is a simple fix:

zmschedulebackup -D

This one command will set the backup schedule and deletion schedule to the default, which is what is shown above. That is all you have to do to make sure you have a reasonable backup schedule! The default schedule should be fine for smaller sites. It will put backups into /opt/zimbra/backup. It’s your job to make sure that is on a different disk and partition than your data.

Custom Schedules
You can use zmschedulebackup if you do need to set up a different schedule. Putting 3 cron lines into a single command line can be a little messy, so you may want to dump the schedule to a file, edit the file, and then copy-paste the desired schedule into the command.

zmschedulebackup -s > /tmp/sched.txt
vi /tmp/sched.txt

sched.txt will have something like

f "0 1 * * 6" i "0 1 * * 0-5" d 1m "0 0 * * *"

The cron timing follows the f/i/d letter. Deletion (d) is a little different — it has the age of backups to preserve between the d and the cron-style time to run. Once in the editor make your desired change. For example, to keep only backups younger than 8 days, change the “1m” to “8d”. Then, copy-paste your file’s contents into a zmschedulebackup -R (R for replace existing schedule):

zmschedulebackup -R  f "0 1 * * 6" i "0 1 * * 0-5" d 8d "0 0 * * *"

You can use the -A (append) option to add more timings to the backup schedule, creating a ruleset that is complicated if needed. There’s a wiki page describing zmschedulebackup if you’d like to learn more.

Disk Layout and Filesystems
As I mentioned earlier we sometimes see systems with all the data, redologs, and backups on one disk or one partition. A full discussion on disk layout would take more than a blog, but in the context of reliability here are a few quick tips:

• Put your redologs (/opt/zimbra/redolog) on a different disk and partition than your live data (mail store, indexes, and MySQL data). If you don’t do this and you were to lose both the live data and the redolog, the latest time you could restore to is the time of your last backup (full or incremental) that wasn’t also lost. That means data loss. Consider the cases if redologs and the live data are separate. If you lost the live data, then by using backups and redologs you will be able to restore to the point in time of the crash. If you lost just the redologs the server would halt immediately. In that case you will probably need to call support when the server comes back up to check for any MySQL/filesystem inconsistencies, but you should not lose any data.

• You can put your redologs and backups on the same disk and partition assuming you have some other place you have moved the full backups to. This is not the best for performance, but it’s OK for reliability.

• We run ext3 in data=ordered mode for the vast majority of our testing. There’s a good article (based on the 2.4 kernel, and courtesy of IBM) on ext3 here. Going forward I would like to see us do more testing in this area, but for now this a safe path with reasonable performance.

We’d like to make backup and restore as easy as possible for admins. If you have an idea for an improvement please either drop us a note or file an enhancement request.

Time for another REST update. We’ll talk about updating content via REST urls, as well as a new formater.

(more…)

Just a little update the previous “All REST and no play…” blog entry.

It has been a while since the last blog post, so we thought it was time for an update to let people know what is in the next release, and what is still to come in a future release.

(more…)