Installing and using imapsync on Ubuntu 12.04

imapsync is a popular tool for migrating from one IMAP server to another, including GMail and Google for Business. You can no longer download the source code directly from the author for free, however the unique ‘no limit’ license allows an unofficial fork to be available on GitHub. As of this writing the fork lags the original slightly, but it should not be an issue for most people.

Here is how to install it on Ubuntu.

Install Dependencies

sudo apt-get install makepasswd rcs perl-doc libmail-imapclient-perl

Clone the Git Repository

git clone git://github.com/imapsync/imapsync.git

Don’t forget to cd into the ‘imapsync’ directory once it is finished being cloned.

Create a Dist Directory

You need to make a `dist` directory. I suspect this is because Git does not track directories, only files:

mkdir dist

Build and Install

sudo make install

Run It

Once this is done, you can run a script like the one below, which was inspired (and borrowed) from this blog post

Further Reading

  • This post is where I found the original version of the script above.
  • You might also find this page about migrating your email to Google Apps useful.

Creating a Puppet Master on Ubuntu

You will need two systems for this walkthrough. One will become the Puppetmaster, controlling the deployment of the other system, known as a Puppet Node. I am using Amazon AWS for these systems, but you can use any solution that offers Ubuntu systems.

We will start with the Puppetmaster…

Installation

The Puppetmaster

sudo apt-get install puppetmaster

The Node

sudo apt-get install puppet

Configuration

You will need to be logged into both the master and the node for this next step.

On the node, the following command will get the node to connect to the master, where it will wait 60 seconds for the master to sign its certificate. Timing is important, you need to complete the steps on both servers within the allotted time.

On the node, run the following command:

sudo puppet agent --server <puppetmaster hostname> --waitforcert 60 --test

On the master, run the following to show the list of certificate requests. You should see your node listed:

sudo puppet cert list

Now sign the request:

sudo puppet cert --sign <node hostname>

Timeouts? Trouble?

If you an experience a timeout during the certificate signing process or if you run into trouble with this process, try deleting the /var/lib/puppet/ssl directory on both systems, then restart the puppetmaster daemon with:

sudo /etc/init.d/puppetmaster restart

Start Puppet Automatically

When you install puppetmaster on Ubuntu, it is configured to run automatically on boot, but you need to configure the node to start on boot.

Edit /etc/default/puppet and change:

START=no

to

START=yes

Then start puppet:

service puppet start

Conclusion

At this point you have a complete puppet configuration. The only thing you are missing is a puppet configuration to share from the master to the node.


Nano Tip: Make Pressing the Tab Key Add Spaces Instead of Tabs

The Nano text editor often gets a bad rap, but in reality for the non-biased it is lightning quick, easy to use, with a very low learning curve. Once you’ve been using it enough though, you might wonder why pressing <tab> adds an actual tab character, when most DevOps and coders will expect a series of spaces. Luckily, it is easy to make this change.

For a one off run, you can start nano like this:

nano -ET4

The ‘-E’ parameter will make nano use spaces, and -T 4 sets the tab size to four spaces.

If you want to make this change more permanent, just create (or edit) a ~/.nanorc file in your home directory and add these lines:

set tabstospaces
set tabsize 4

Now whenever you press tab in nano, it will automatically add 4 spaces.

For more information on this and other nano parameters, check out the man page.


Development Environments

I’ve been thinking for a while about trying to write this post, but was too lazy to do that. Now I think it’s time.

When you work on a project you need an environment to test what you are doing. Especially, if this is a big interprise system with complicated deployment process and many dependencies on other systems (usually a system could both depend and be dependent on other systems)

I’ve faced the problem of testing my projects several times. When you finish your task, but don’t know how to check that it works. Sometimes it’s not possible to run it on your local computer, and sometimes if it is, working system on your computer doesn’t mean that it’s going to work on production. So I want to share my thoughts how the process could be accomplished on my point of view. To be said that’s not my idea, I just want to share the experience that I think is good enough. So let’s get started.

In big enterprise systems there are usually many roles working on a project. Some of them are business analysts, system analysts, QA engineers, developers, deployment engineers. Based on that let’s say that there are different layers of environments for a particular role group.

Let’s assume that there are 2 projects depending on each other, project A and project B. Different teams work on each project. So how to do development and make sure all that work?

Here is how I think this could be accomplished. Again, this is not my idea, but I like it. You can have 3 layers of environments. Let’s call them DEV (development), QA (quality assurance) or SIT (system integration testing), UAT (user acceptance testing).

DEV environment is an environment where a developer can deploy and run the system to see how it’s working (or not working:) ) All dependencies to another systems can be stubbed on this layer. We don’t care if the dependent systems work on this stage. For project A and project B there could be different DEV environments, like DEVA and DEVB, so the projects could work and be deployed isolated from each other. QA team can also work on this environment to perform some testing. Once a QA team or a development team is happy with the results the project is deployed on the next layer – QA or SIT.

QA or SIT environment is an environment where QA team works on testing how the whole system works, including both project A an project B. On this stage there are no stubs. On this layer both project A and project B get tested. Once this is done, the whole system is deployed to the next layer – UAT.

UAT environment is an environment where end users perform testing. This is the stage where end users provide sign off for the system. This environment should look like as production as much as possible. After end users are happy with the system, the system can be deployed on production.

There is one more environment that stands out of the environments I described above. This is a prod like environment. On this environment anyone from dev or qa or a user can take a look how the system is currently working. This can be very useful when there is a bug and you don’t know if this was done in current release or it’s from production. Also, sometimes it is useful to see how the system works on production to figure out some behavior that you are not sure where it came from.

Thank you for reading!