Someone in the forums recently asked about ways to migrate individual accounts from one ZCS instance to another, so thought I’d share the enlightenment with all. Whether you are going from an on-premise install to a hosting provider, want to create handy archives of old employee accounts, or just need to duplicate mailbox contents of a user; the syntax in this article proves remarkably useful, and applies to all editions.

There are a multitude of comparable RFE’s on addressing this need via different approaches. (Bugzilla entries 19630, 29573, 28443 & 30163 to name a few.) Some want graphical tools to browse data and selectively migrate certain things, while others would be happy with a cross LDAP zmmailboxmove.
Depending on your situation, several backup tools can take care of a large portion of your daily needs; and there are ways to do Zimbra-to-Zimbra migrations using the Network Edition’s backup and restore capabilities - however they require admin abilities on both systems. Meanwhile, most of the frequently used open source backup solutions are simply an “all accounts at-once” approach. So what to do when you need to move from your personal setup to a hosting provider? Or if you’re a hosting provider, move a tiny handful of accounts to a separate infrastructure? Before diving into the wiki on user migration for info on Imapsync, REST exports, CURL imports, etc; there’s a handy way to avoid the “one item type at-a-time” transfer methods.
In ZCS 5.0.9+ you can export an entire mailbox with:
/opt/zimbra/bin/zmmailbox -z -m user@domain.com getRestURL “//?fmt=tgz” > /tmp/account.tgz
Next transfer via rsync, scp, sftp, etc. You’ll also need to create the account on the 2nd server if the desired account doesn’t exist at your destination server yet.
Then import with:
/opt/zimbra/bin/zmmailbox -z -m user@domain.com postRestURL “//?fmt=tgz&resolve=reset” /tmp/account.tgz
The resolve= paramater has several options:
‘Reset’ will be a bit faster on an empty destination mailbox because it skips most dupe checks.
Note: There were some duplication fixes and additional issues (mainly sync related) corrected with the tar formatter in 5.0.10.
Not a Zimbra Admin? Users can get the same zip/tar formatter on REST URL’s by visiting:
http:// server.domain.com/home/user?fmt=zip&query=is:anywhere
The zip format has been around for a long time, but doesn’t contain account & item metadata like the tar formatter automatically does:
http:// server.domain.com/home/user/?fmt=tgz
Infact, this same technique is currently used in Zimbra Desktop’s alpha backup solution.
If this approach doesn’t scale performance wise for your situation, or you simply don’t want to have everyone hit a REST URL for 30GB mailboxes all at the same time, here’s a collection of helpful scripts and other ways to systematically migrate:
Mysqldump & rsync with an interesting blob management technique: Zimbra2Zimbra
Imapsync for mail + postRestURL for contacts, calendar & filters: ZimbraMigrate (Expand the concept for tasks, documents, and briefcase items.)
Another method that could be extrapolated upon for migrations: Per User Mailbox Backup (OE Version - Zimbra :: Wiki)
Most of these solutions aren’t going to respect share permissions, but when pulling an account out of an environment that’s to be expected.
Zimlet spin-offs:
- Mail backup options for end users (.eml)
- Zimlet to save email in a txt file (.txt or html)
The above Zimlets are aimed at making quick self-copies & not for restores, but there are many methods for putting messages back into Zimbra, including tools like zmmailbox addMessge, zmlmtpinject, CURL, etc; for more info checkout these threads: Recover data from store folders & Moving Folders between users
If moving your entire server, I’m a huge fan of the install.sh -s trick when using NE backups to do so isn’t an option.
Are you a new Linux user? Fantastic! Welcome to the world of freedom. Freedom of choice, freedom of expression, freedom from vendor lockin. You've made an excellent choice. Now that you've chosen, installed, and are using Linux there are a few things you should keep in mind as you learn the ropes of your new system.
1. Not all Communities are the Same
Each Linux distribution has its own distinct community with their own ideas. Think of owning a vehicle or a certain brand of appliance...along with the ownership of this comes the lifestyle that is reflected by users/owners of the product. The same is true with Linux. Each community will have a different idea on what is important. What is important to you may not be even on the radar of those users and developers of that community. Find one that suits you.
Keeping this in mind, be patient. Ask questions the smart way. Be explicit and tactful. Be precise and direct. Provide more information than you think is necessary...no one will become upset if you provide too much information but they may not answer your question if you have too little.
I’m happy to announce the first and hopefully last release candidate (zip) for Dojo 0.4.2. As usual, you can grab your favorite builds from download.dojotoolkit.org. 0.4.2 is a minor patch release to address the most severe issues and regressions in 0.4.1. Unlike 0.4.1, there are few if any new features. We encourage adventurous users of 0.4.1 to try the release candidate and give us feedback. The final 0.4.2 release is tentatively scheduled for two weeks from now.
While 0.4.2 doesn’t include new features, the build system has changed significantly thanks to the hard work of James Burke from AOL. It now supports cross-domain builds even better and a new sub-domain, build.dojotoolkit.org, has been setup to support a brand-new web-based build tool. The 0.4.2rc1 build page is up and it includes details on how to use the simple x-domain inclusion script that we’re maintaining for all new releases. Significant work has gone into 0.4.2 to ensure that x-domain builds work correctly and the new web-based build tool will let you easily generate a new dojo.js file to optimize your deployments without ever needing to download the “source” of Dojo or learn how to use Ant. I’m tremendously excited about this.
Work continues on ensuring that 0.4.2 is the highest quality Dojo release to date, but major changes have also been quietly taking place. At last month’s 3D2 significant decisions were made about how to evolve the toolkit. First, Dojo 1.0 will ship this year. Secondly, we will be splitting the project up into 3 separate but coordinated efforts: dojo core, dijit, and dojox. Lastly, it was decided that a major backwards incompatible jump will be made for the next major release of Dojo. To date, we have always attempted to provide at least one full point revision’s warning regarding APIs that were changing or being removed. This policy has allowed attentive users to easily stay abreast of porting their applications between Dojo versions but it has also contributed significant cruft to the core of the toolkit. This cruft will be removed wholesale in the next major revision, Dojo 0.9. No in-code deprecation warnings will be provided. Instead, a full and complete porting guide for 0.4.x users will be created. The extent of the planned changes make back-compat shims unrealistic.
In the coming weeks we will be outlining the details of the project split, but the major outlines of how to proceed have been decided and are already under way. The first part of the plan involves restructuring the Dojo subversion repository to represent the three major projects. The roles and responsibilities of these projects and their leads are also being clarified:
dojo core will consist of a tightly constrained set of lower-level APIs that make JavaScript better as a language and make DOM manipulation easier. All code in the core (and its widget-focused sister project, dijit) will be required to meet stringent quality, testing, and documentation standards. Most of the code currently in Dojo’s utility namespaces is being pored over and most will be either discarded outright or moved to dojox. The resulting core will be very lean, stable, and fast. I will continue to be the project lead for the core effort.
dijit is the new home for the “official” widget set. Not all of the current widgets will make the cut for Dijit and only those that are accessible, internationalized, themed, tuned for performance, and agreed to be generally useful will be part of Dijit. The widget system is being significantly streamlined to support this effort. APIs for base widgets are being rationalized, the inheritance hierarchy drastically simplified, and the page parsing infrastructure scrapped in favor of a much higher performance approach demoed at 3D2. Bill Keese, the uber-capable and dedicated module owner for the widget system, will become project lead for Dijit.
dojox will carry on Dojo’s strong tradition of invention. Many of the most important Dojo modules push the edges of what’s possible and have helped to bring the theoretical into the plausible over the last 2 years they will be allowed to thrive in dojox without the restrictions placed on core and Dijit code. Dojox will impose fewer restrictions and regulations on projects developed there. Far from being a second-class code ghetto, dojox will be home to important modules like dojo.storage, dojo.gfx, and dojo.charting.
No matter what project a module “lives” in, the entire spectrum of modules will continue to be available from an evolved version of the new web-based build tool.
I know this post has run long, and so I’ll finish with a brief word on timing and leave the inevitable slew of questions for discussion on dojo-interest and to follow-up blog posts. In the next several weeks we expect to have a solid first draft of the 0.9 API specification for the Core. Based on that and progress in porting widgets to Dijit and migrating code to dojox, milestone releases will be made available for the adeventurous starting sometime in March. The current plan, subject to some play in the joints, is for an alpha release of 0.9 in late spring, a beta shortly thereafter, and 0.9 final in early to mid summer. From 0.9 to 1.0 we are targeting testing, completeness, and few if any API changes in the Core and Dijit.
Dojo 1.0 will be available in late summer or fall of this year.
The Dojo Community Resouces project has not been forgotten! Lately there have been many comments to the mailing lists regarding my last article requesting input on a Dojo Community Resource website. Well it hasn’t been forgotten. Infact the project that is more or less being the test bed for its community building software is underway and has been well recieved by the other contributors.
Some of the Dojo Contributors (myself included) are working on a project using the same CMS software (Drupal), once we’ve got this going and are more comfortable working with the software, the Community Resource site will be started. Currently I am still looking for a good domain name to register for the Community site, but thats only minor compared to actually setting it up, but if you have any good ideas for names, feel free to pass them on to me
If you have any comments or suggestions, don’t hesitate to leave a comment!
Our good friends at Renkoo have just launched a public beta of their Comet-driven, Dojo-based evite killer. If you’ve been wanting to try it out, now’s your chance to give it a spin!
What I am hoping to achieve by writing this article, is to receive community feedback regarding the construction of this community resource. Now that I have said all that, here are the things I hope to see achieved by the creation of this community resource.
Note: This is not a replacement to the http://dojotoolkit.org website but rather a collaborative site that allows for unofficial modules and widgets to be collectively offered to the Dojo Community. Code contributions to this site would not require Contributor License Agreements, the poster will maintain liability for content provided by him/herself in this case. Just because this site won’t require a CLA, this should not be seen as an easy way out to contributing to the Dojo Community, contribution of good ideas and useful code is still encouraged to be made directly to the Dojo Toolkit project.
As everyone knows, the Dojo community has been expanding at an enormous rate since the release of Dojo 0.3.0, and with it that growth has come the question; “Where can we find Dojo resources on the web, that aren’t direct products of The Dojo Foundation?”. This of course has been addressed in the past, but in a passive manner, nobody has yet taken an active role in solving this problem. Consider this article step #2 in the process of solving this problem. Step #1 was of course my brainstorming and researching possible ways of approaching this.
As of this past weeks IRC meeting in #Dojo-meeting, it has been decided to work towards integrating a Forum system into the current list of Dojo resources and the need for a “Dojo Resources” type community was also addressed. At this time, I believe that the “Dojo Community Resources” site could very well be hosted off the normal domain, in fact I would encourage it to be on its own namespace (to steal a term from Dojo/Javascript). By moving this project to a seperate domain, it will I believe, remove liability from the Dojo Foundation, for submissions that may have been made without prior authors consent. My idea on this is that the submitter would maintain liability for their submissions, if this is at all possible. Of course I am not a lawyer, so this is just my idea how I would like to see things work.
Why I am writing this article? Well, I believe that this is to be a resource for the Dojo Community, that it is only right that you the community, should have some idea of what is being considered for your benefits. As it stands, I have volunteered web space from my personal account, as well as to purchase the domain name (yet to be determined). As for the resources available to make this happen, I have been considering using a PHP framework/CMS to meet the “community” aspect of the site, and preferably one that has a forum project integrated into it. It has been suggested that the scope of this search should be extended beyond just PHP software, so I’ll be entertaining a few suggestions on that as well, however my strengths lie in PHP and JavaScript so I’ll admit that I am biased towards that as a solution.
What projects have I looked at? Well in my years of playing “Web developer” I have experimented with several of the CMSs out there. Among them I have used: Joomla, Mambo, phpCake, MKP, and most recently Seagull. Of all these, there are various forums associated with them or that have been integrated by third parties, however only one of the forums really supports the features that we were looking for to integrate into the current Dojo resources; FUDforums which is integrated into the Seagull Framework. So that is what I am hoping gets adopted by as the forum of choice for Dojo; not only because it supports all the features we want, but it is also supported by the PHP framework that I am wanting to use for the community site.
Basically what I am aiming for is a site where the community contributes most of the content. I am hoping for a small amount of help from at least 1 other Dojo contributor in order to be mediators between the Community and the Dojo contributors. I would also hope for several trust worthy and knowledgeable community members to help maintain the community forums and such as well. These people would be working on site layout etc, forum moderation, and if capable, feature modification/creation to meet the needs of the community site.
If you have any comments or suggestions regarding what would aide in creating the best “Community Resource” website out there, by all means post a comment below with your ideas and recommendations. As I am wholly expecting the Dojo Community to play a major role in how this project starts, evolves, and runs. To make that possible, I’m counting on loads of feedback and cooperation from you, our Community.