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.
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:
Build and Install
sudo make install
Once this is done, you can run a script like the one below, which was inspired (and borrowed) from this blog post
- 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.
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…
sudo apt-get install puppetmaster
sudo apt-get install puppet
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>
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:
Then start puppet:
service puppet start
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.
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:
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 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.
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!