Minimal configurations for sending mails using the terminal

This is something I came across while I was doing the performance test for our ESB. Performance test for the ESB took some time and had some output files. I wanted this output files after each iteration. However, It is not good to longing to the machine while the performance test is on going. Therefore, I wanted a notification system to notify me and send the files after each iteration. In order to archive this I used mails with attachments.

Like this there could be many scenarios where you have to send mails as a notification. This blog post shows how to configure and send mail using the terminal withing minutes.

MSMTP as the MSA (Message Sending Agent)

First thing we need to do is installing and configuring a MSA. For this I have chosen msmtp. Issue the following command to install msmtp.

sudo apt-get install msmtp

Then configure it to send mails. In my case I have used gamil for sending mails. In order to configure it first you need to change permission of the file ~/.msmtprc. To do this issue the following commands.

touch ~/.msmtprc
chmod 0600 ~/.msmtprc

Now you can configure it for sending mail with gmail as follows.

# Use an external SMTP server with insecure authentication.
# (manually choose an insecure authentication method.)
# Note that the password contains blanks.
defaults
######################################################################
# A sample configuration using Gmail
######################################################################
# account name is "gmail".
# You can select this account by using "-a gmail" in your command line.
account gmail
host smtp.gmail.com
tls on
tls_certcheck off
port 587
auth login
from <your gmail address>
user <username (I normally use the from value for this)>
password <password>
# If you don't use any "-a" parameter in your command line,
# the default account "someplace" will be used.
account default: gmail

Mutt as the mail sender

Though we can use msmtp to send mails, it is better to use something like mutt because it provides convenient options when your sending a mail such as sending attachments. However, mutt itself could not send mails. It needs a MSA such as msmtp.

Let's install mutt first.

sudo apt-get install mutt

Then configure it to use msmtp as its MSA.

vim ~/.muttrc
set sendmail="/usr/bin/msmtp"
set from=<your gmail address>

That's it. You are ready to go. Now issue the following command to test sending mails with attachments. 

echo "body." | mutt -d 1 -s "attachment" aaa@bbb.com -a abc.zip

Replace aaa@bbb.com and abc.zip as you wish and hit enter. There should be a mail in the destination mail with the subject attachment. 

Read More

How Python made it Better, Easier and Faster

In software engineering engineers come-across repetitive processes in their daily lives. These repetitive processes are more or less automated using scripting languages. This blog post is about a tool that we wrote to automate feature creation for components and etc, which is a repetitive processes we came-across. This blog post explains how we made the process better, easier and faster.

Introduction

This is a tool which is written with the focus of bringing all the Python script into one place. However, we thought of starting with automating feature creation for components as it is a burning problem in our organization. This document explains what are the existing problems of feature creation and its associated sub-tasks and how this tool overcome these problems.

The problem in hand

The process we use to release products is based on so-called chunking process in which we release products by releasing a chunk of the platform. The problem with this system is platform becomes a huge mix of released and un-released components and features. Not only that, it also allows the platform to have multiple sub-versions of components and features. This introduced some new problems on top of the existing problems. These are some of the problems we saw and came-across during ESB-4.8.0 release,

• It is hard to figure out if a component or a feature is released or not.
• Failing to propagate the changes to associated features.
• Failing to propagate the changes to associated features of features.
• Failing to find dependent projects.

As a result committing to released versions became more common, which in turn increased the number of build breaks. Making the problem to move from bad to worse. The tasks that we have in current release process is not only error-prone but also repetitive and time consuming. Therefore, to overcome these problems we thought of writing a tool.

Management Tool

In software engineering engineers come-across repetitive tasks in their daily lives. This is one good reason why scripting languages exist. Using scripting languages people can automate these repetitive tasks. Therefore, we thought of automating above mentioned tasks with the help of Python. One of the best scripting languages in the world. Following are the tasks we automated with our Python script.

• Validating the existing component.
• Creating a new component.
• Updating the component chunk pom.
• Finding dependent features.
• Validating the existing feature
• Finding dependent feature of features
• Creating new features or updating the existing ones.
• Updating the feature chunk pom.
• Revert the changes in case of failure.

Everything is done by looking at Nexus (with the help of Nexus REST API [1]). Therefore, it is literally impossible to commit to a released component or create an invalid component or feature version. Moreover, at the end of the execution it shows with a tree view how all the updated components are associated to each other, which helps you to have a better understanding about the updated components. Therefore, with that understanding you can either revert unwanted changes or proceed with the new changes. As a result of all these, now the process has become,

• Less error prone.
• Pretty fast.
• Consistent over the platform.
• How to run the tool
• To run the tool do the following,
• Get the code from link [2] or from the attachment (so2py.zip).

Run main.py with the component that you have done changes to (It has to be the latest version). For example: ./main.py /media/shafreen/source/public/turing-new/components/mediation/message-processor/org.wso2.carbon.message.processor/4.2.0

Note : when your are running the tool for the first time it will ask for the root of your SVN local copy. So, give the complete path to the root of your local SVN copy.
For instance: /media/shafreen/source/public/turing-new

That's it. Let the tool do the rest for you. Upon successful execution it will give something like in the below image and it will create log files in <ManagementTool_Home>/log directory.

Limitations and Future work

Following are some of the limitations that this tool have. However, These are not technical limitations. But we couldn’t find free time to implement it.

• Assumes that the svn is in buildable state.
• If the parent pom is not released it does not add the parent pom.
• Only works for components.

Following are some of the feature work we have in mind,

• Find dependent component of the updated component, purge those dependent. component in m2 and build the updated components. So that, all you need is a buildable svn and Nexus.
• Update feature chunk pom only with the features that are in the p2-profile pom of a particular product.
• Auto commit all the changes.
• Fix above mentioned limitations.
• Make it a proper command line tool that can take different commands and flags.

[1] https://repository.sonatype.org/nexus-restlet1x-plugin/default/docs/index.html
[2] https://github.com/raviu/so2py

Read More