HomeArchive by Category "Uncategorized"

Benchmarking Network Speeds for Traffic between Cornell and “The Cloud”

by Paul Allen

As Cornell units consider moving various software and services to the cloud, one of the most common questions the Cloudification Services Team gets is “What is the network bandwidth between cloud infrastructure and campus?” Bandwidth to cloud platforms like Amazon Web Services and Microsoft Azure seems critical now, as units are transitioning operations. It’s during that transition that units will have hybrid operations–part on-premise and part in-cloud–and moving or syncing large chunks of data is common.

(more…)

Automatic OS Patching

by Shawn Bower

One of the challenges as you move your infrastructure to the cloud is keeping your ec2 machines patched.  One highly effective strategy is to embrace ephemerality  and  keep rotating machines in and out of service.  This strategy is especially easy to employ using Amazon Linux. check this out from the FAQ (https://aws.amazon.com/amazon-linux-ami/faqs/):

On first boot, the Amazon Linux AMI installs from the package repositories any user space security updates that are rated critical or important, and it does so before services, such as SSH, start.

Another strategy, the one we will focus on in this post, is to be able to patch your ec2 instances in place.  This can be useful when your infrastructure has long running 24×7 machines.  This can be accomplished using Amazon’s SSM service and the AWS CLI or SDK.  First we have to install the SSM agent on all the machines we wish to patch.  For example to install the agent (as root) on an Amazon Linux machine in us-east-1 you would:

  1. curl https://amazon-ssm-us-east-1.s3.amazonaws.com/latest/linux_amd64/amazon-ssm-agent.rpm -o /tmp/amazon-ssm-agent.rpm
  2. rpm -i /tmp/amazon-ssm-agent.rpm
  3. rm /tmp/amazon-ssm-agent.rpm

This will download the agent, install it and turn on the service.  The agent will contact AWS over the public internet so makes sure your ec2 instance can send outbound traffic.  Once your machine registers with SSM you should see it listed in the Run Command GUI (ec2>commands>run a command).

run-command-gui

 

You can also verify that your instance has correctly registered using the AWS CLI, for example:

aws ssm describe-instance-information –instance-information-filter-list key=InstanceIds,valueSet=instance ID

If everything goes well you will get json like below:

srb55_—_ec2-user_dev__sync_—_-bash_—_142×27

If the instance can not be found you will receive an error, if the agent had registered but is no longer responding then you will see the PingStatus is Inactive.  Once we have the SSM agent installed we are good to send commands to our ec2 machines including patching them.  For our implementation I decided to use tags in ec2 to denote which machines should be auto patched.  I also added a tag called “os” so we could support patching multiple OSes.  Our ec2 console looks like:

ec2-tags

With the tags in place and the SSM agent installed I used the Ruby SDK to create a script that would look for ec2 instances that had the auto_patch tag and then determine the patching strategy based on the OS.  This script uses the cucloud module that is being collaboratively developed by folks all over campus.  The main script is:

auto_patch_rb_—__Users_srb55_projects_aws-examples_aws-ruby-sdk_ec2

Finally the function that sends the command via SSM is:

send-patch

This is just one example of how to keep your machines up to date and to improve your security posture.  If you have any questions about patching in AWS or using the cloud here at Cornell please send a note to the Cloudification team.