CALL +44 (0)20 7183 3893
Blog

Tuesday 23 October 2012

Setting domain wide signatures for google mail

Using Google Apps Script and Google docs

While Google mail’s compliance footers are great for legal compliance, Google currently don’t offer an easy way to set signatures for all your users that are based on user specific variables. I had a quick look at the existing offerings but I also noticed that due to the openness of Google’s APIs it's easy to pull data from a Google spreadsheet and push out the signatures to users across a domain. Giving us:
  • Centrally managed user data in a simple spreadsheet 
  • A legal compliance footer enforced on all outbound emails 
  • A quickly customisable signature with contact details that can be edited/updated by users (no more waiting for IT to update your contact details) 


As Google Apps Script doesn't connect to the Google email settings API directly, this also makes use of Google Apps Script's support of oauth to securely authenticate from Google Apps Script to the Google email settings API. This post includes setup instructions and an overview of how it works, if you just want the code feel free to skip to the end...

Wednesday 6 June 2012

Auto Scaling and Chef Nodes Deregistration

Creating an infrastructure which scales dynamically according to the traffic volumes hitting a web site, is a reality using Amazon Web Services (AWS). However, there are a number of key design points, which differentiate a professional solution from an ad hoc collection of services.

One of these design principles for auto scaling an application is to strive keep it stateless.

Sometimes this is not possible, for example when OpsCode Chef is used to configure and deploy code to instances created via an auto scaling process. In order to use Chef on a new instance, it needs to first register itself first with a central Chef server and resolve credentials and ssh access so that code and commands can be executed.
The problem with registering autoscaling nodes, is that when those are terminated for one reason or the other, Chef Server is left in a “dirty” status, with references to nodes which are no longer active.

Fortunately, the AWS team have enhanced their platform with lots of additional services complementing EC2, two of which are useful to solve the problem described above.

When an action is triggered in an auto scaling group, this can generate a notification using the Amazon Simple Notification Service (SNS). SNS works across all the services offered by AWS, and an auto scaling group can be configured in order to generate an outbound notification for both scale up and scale down events.
SNS receives and publishes events using “topics”.  A topic is a communication channel to send messages and subscribe to notifications. It provides an access point for publishers and subscribers to communicate with each other.

An SNS topic can be created very easily using the web UI, or using the command line:

sns-create-topic MyTopic

Once a topic for autoscaling events is created, the auto scaling group needs to know where to publish notifications. This can be achieved in one of two ways; either using the command line interface:

as-put-notification-configuration MyGroup --topic-arn arn:placeholder:MyTopic --notification-types autoscaling: autoscaling:EC2_INSTANCE_TERMINATE topic-ARN MyTopic


or using CloudFormation:

"NotificationConfiguration" : {
             "TopicARN" : { "Ref" : "MyTopic" },
             "NotificationTypes" : [ "autoscaling:EC2_INSTANCE_TERMINATE"]
       },


Notifications by themselves are not very useful if something doesn’t consume them and act upon them. A naive approach would be to use email or SMS alerts and manually remove instances using the Chef user interface. Fortunately we can do better than this, and instruct machines (or scripts) to perform this (boring!) task on our behalf.

The method of consuming an SNS notification programmatically is to use Amazon Simple Queue Service (SQS) as an endpoint to SNS. The SNS topic can be configured in order to act as a producer for an SQS queue.

Once SNS and SQS are linked together, it’s just a matter of writing a consumer which is able to read EC2_INSTANCE_TERMINATE messages, and remove the node from Chef.

Given that Chef uses Ruby as language to define “recipes”, I choose to use FOG in order to leverage the SQS RESTful API.

Before retrieving the messages in the queue, authentication needs to take place.

sqs = Fog::AWS::SQS.new(
        :aws_access_key_id => access_key_id,
        :aws_secret_access_key => secret_access_key,
        :region => "eu-west-1"
       )


If the authentication is successful, the method receive_message will return a list containing  the number of messages specified as a parameter.

response = sqs.receive_message(QUEUE_URL, { 'Attributes' => [], 'MaxNumberOfMessages' => 10 })

From this point on, is a matter of parsing the JSON message, and if the event is a termination notification deleting the instance.

messages = response.body['Message']
unless messages.empty?
   messages.each do |m|
   body = JSON.parse(m['Body'])
   message = JSON.parse(body["Message"])
   if message["Event"].include? AUTOSCALING_NOTIFICATION["Terminate"]


In order to keep the code simple, the node is removed by invoking knife from the command line, so that there is no need to handle the authentication:

instance_id = message["EC2InstanceId"]
delete_node  = "knife node delete #{instance_id} -y"
delete_client= "knife client delete #{instance_id} -y"
output = `#{delete_node}`
result=$?.success?
if result == true
   result = `#{delete_client}`
end

        
Once a message is processed successfully, it can be removed from the queue:

sqs.delete_message(QUEUE_URL, m['ReceiptHandle'])

In order to work in an enterprise production environment, the script needs few additions, but this should be enough to get you started!

Alternatively, come and talk to the experts at Cloudreach.



Nicola Salvo
System Engineer
Cloudreach Limited

Thursday 1 March 2012

Cloudreach Becomes A Google Apps Premier Enterprise Reseller



Cloudreach Limited is proud to announce that it has become a Premier Enterprise Reseller of the Google Apps™ suite of communication and collaboration tools.  This new designation from Google enables customers to more easily assess a reseller’s expertise advising on and deploying Google products.  Cloudreach has moved from an Authorized to a Premier Reseller based on their expertise and success in helping customers deploy and use Google Apps. Cloudreach is a full service Google Apps partner providing technical migration, training / change management, support and application development services around Google App Engine and Google Apps scripts.

“The Google Apps Reseller program has been a critical component of our business," said Pontus Noren, Director & Co-Founder at Cloudreach. "We’re pleased to be recognized as a Premier Reseller, and we look forward to continuing our work helping Enterprise customers take advantage of Google Apps. The market is really buzzing and the interest around Google Apps and Cloudreach is massive. Our success to date with organisations such as Trinity Mirror and London Borough of Hillingdon demonstrates that Google Apps is the enterprise solution for forward thinking corporates and local authorities alike.”

Google Apps brings simple, powerful communication and collaboration tools to organizations of any size – all hosted by Google to streamline setup, minimize maintenance, and reduce IT costs.  With Gmail (including Google email security, powered by Postini), Google Calendar, and integrated IM, users can stay connected and work together with ease. And, using Google Docs and Google Sites, which include word processing, spreadsheet, presentation and website creation tools, they can share files and collaborate in real-time, keeping versions organized and available wherever and whenever users work.

About Cloudreach
Cloudreach, with offices in London and Edinburgh, is a full service Google Apps partner able to provide consultancy to help organisation build a business, migration services to move the users and their data to Google Apps including an extensive change management capability as well as 24/7 Network Operation Centre providing Google Apps support which is tightly integrated with Google’s internal support team.

Cloudreach also provides adoption services such as Google App Engine & Google Apps Scripts development as well as Technical Account Management and consultancy services for deeper integration of Google Apps within an organisation. Customers include Trinity Mirror, AG Barr and London Borough of Hillingdon.

Google, Google Apps, Gmail, Google Talk, Google Calendar, Google Docs, Google Sites and Google Video are trademarks of Google Inc.  

Issued on behalf of Cloudreach Limited
Email: pontus.noren@cloudreach.co.uk
Tel: +44 20 7183 3893




Thursday 2 February 2012

London Borough of Hillingdon Goes Google with Cloudreach!

Take a look in any standard file system, and you’ll find several versions of the same documents, updated and renamed whenever changes have been made. If those documents were created in collaboration with others, then those people will have their own versions of the same document - adding up to dozens of essentially the same data clogging up servers across the world. 
 
That’s one of the major pluses of a move to Google Apps, and a strong selling point when the London borough of Hillingdon chose the cloud-based service to provide its email, calendar, documents, word processing, instant messaging and voice and videoconferencing services. 


Naturally, the cost savings are a major benefit, too, but it was the improved collaboration capabilities that swung the decision making, says Councillor Jonathan Bianco, Hillingdon Cabinet Member for Finance, Property and Business Services at Hillingdon
 
Pontus Noren, CEO of Google reseller Cloudreach says that there is a huge interest in Google Apps among local authorities. Many are at a point where they need to replace email platforms that are reaching end-of-life, and Google’s offering is “an extremely attractive option, for several reasons. Migration from one on-premise infrastructure to another is quite complex and costly. Even with cloud based solutions other than Google Apps, many are very reliant on clients like Outlook. That ties the user tightly to a device, and puts pressure on IT departments to install, maintain and upgrade all these clients. 


One of the biggest costs in IT departments is having to image and reimage laptops and PCs. Whereas if it’s on the browser, each user is self sufficient. Very few people work with one device today such as a stationary PC but will have laptops, smart phones and tablets. The users expect the same experience across all devices and Google Apps is the only device-agnostic solution in the market today,” Noren says.
 
Hillingdon is the first UK local authority to move to Google Apps, with 3,500 users making the change. It is hoped this will bring savings of up to £3 million over the next four years.
The Hillingdon project is in the planning stages, Noren says, and key decisions have yet to be made. For most clients, however, Cloudreach recommends that users do not transfer their older files to the new system. “It is possible to store all your older Word and Excel files in the Google infrastructure, but we recommend against it - you’re really just transferring the problem of multiple versions of the same document. In most cases we see that, even where people do transfer older documents, they very quickly switch to using native Google documents as they discover the collaboration potential and the ease of use,” he says. 

 
Training in the use of Google Apps is “super easy”, Noren says - usually taking one to two hours per member of staff, with more in-depth training available for users who will manage other people’s email and calenders. “Even that only takes a couple of hours. As we say - people don’t need training for YouTube! Software in the past was created by engineers for engineers, so it’s full of buttons and functionality that no one uses. Google Apps comes with a different ethos, in that it’s as simple and intuitive as possible.”

 
Security is naturally a concern when local authorities consider cloud computing, but Noren says fears are quickly put to rest. “Once we show the the security built into Google’s systems they realise that they could never, ever achieve that level of security themselves. And then there’s the fact that people aren’t walking around with laptops and USB sticks full of sensitive data, just ready to be left on a train.”

 
Cllr Bianco said: "Going with Google makes the most sense for Hillingdon economically and it will enable us to realise the tremendous opportunities afforded by cloud computing. Doing this means we're ahead of the curve in anticipating the changes in technology over the coming years. It also means we'll have more opportunities to look at how we communicate with local residents and organisations in the Borough, such as remote working. Simply, it makes both financial and business transformational sense to make the change."

Source: Gillian Law, ICT Knowledge Transfer Network

Pontus is ready and waiting to answer your questions