What Amazon Web Services (AWS) can learn from Google Compute Engine (GCE)?
GCE is now publically available after 18 months of its launch and as an AWS lover, I thought of logging into GCE console and explore things. After playing around GCE console for an hour, I found few interesting things which AWS can learn from GCE. I’m not talking about performance, hardware, optimization etc. comparison between AWS and GCE. I’ll leave those discussion to experts. I was just looking at the things which will improve the AWS user experience and provide more options to users.
Few pointers which AWS can learn from GCE:
Resource Limits
I witnessed all GCE resource limits are mentioned at one place and that too in their management console. This helps user to quickly identify his resource limits unlike AWS where we come to know about our limits after we are fully ready to launch our resources - “Limits reached or exceeded”. It would be great, if AWS can mention all limits at one place rather than user having bad experience or search through the documentation. In fact, AWS can mention limits of each service dashboard page along with the limits utilization level.
Price
Whenever we plan to launch an instance in GCE, it also shows price along with the name and computation power of that instance. My suggestion to AWS: why don’t you place the final cost of the instance on the summary page? This will help user to understand pricing of an instance in a better way. Also, if the user is making a mistake of selecting higher cost instance – this will alert him.
Asynchronous Replication
GCE Cloud SQL database instance provide option of choosing asynchronous and synchronous replication between master and standby database instance. AWS RDS Multi-AZ instances only provide synchronous replication between master and standby. To achieve asynchronous replication in AWS, we need to use the combination of RDS Master and Read Replica. Asynchronous replication between master and standby database instances will increase the performance of the database. This will help those users who have high write application, require better performance and can handle few minutes of database loss in case the master RDS instance goes down.
Automatic Migration of VM
The automatic migration of VM during maintenance is a nice feature introduced by GCE. This will prevent the downtime of the application. In AWS, we don’t have this feature available.
Persistant Disks
GCE provides persistant disks upto 10TB and it also allows to mount those disks to another instances in read-only mode. On another side, AWS provides EBS volumes upto 1TB and it does not allow us to mount same disks on multiple instances.
There might be a question: what GCE can learn from AWS? I’ll leave this question for now. GCE is new into IaaS market. Let’s give that sometime and we might automatically get all our questions answered.
I’ll keep on updating this blog with more pointers.
Data Security in Cloud - Compliance, Data Isolation and Data Governance
Security and Compliance considerations were are and always are going to be the critical factors while making cloud computing decisions. A clear and precise understanding is required to identify the security benefits and risks associated whenever an organization considers moving to cloud. While offering some protections, the cloud provider often leave security largely to their customers i.e., cloud providers allows organizations to store their data in cloud but the responsibility of maintaining it is still in the hands of organizations. On the other hand, there are lots of organizations who typically don’t protect their data believing that this has to be done by cloud provider. Therefore, the understanding between cloud provider and organizations is required in order to achieve set of realistic expectations and responsibilities each cloud model introduces whether it is Infrastructure as a Service (IaaS), Platform as a Service (PaaS) or Software as a Service (SaaS).
There is a notion among organizations that their data is exposed to more risks if stored in cloud i.e., there concerns amplifies as external control has access to organization data and there are chances of potential mismanagement which is not necessarily true. If proper security arrangements are placed with the cloud provider, the amount of security risks should not be any more than your own environment. Also, Cloud providers can provide better security level as they can afford to have bigger security budgets and skills than an average datacenter.
Points to consider before moving to cloud:
Compliance
Before moving data out of your datacenter to a cloud provider, we need to ensure that everything remains compliant with federal & state laws and industry regulations like Health Insurance Portability and Accountability act (HIPAA), Payment Card Industry Data Security Standard (PCI-DSS). These regulations ensure that strict controls are applied regarding what kind of data is stored in cloud, who has access to it and where it can be stored. Organizations need to identify what data they are going to put on cloud and how they are going control it. The Data Protection Act in UK says that data controllers are responsible for data control at any given stage even if the data is sent to an external party. Due to these reasons, audit and compliance teams are less keen to adopt cloud technologies.
Data Isolation and Protection
In multi-tenant cloud infrastructure, our resources i.e., servers, clouds, storage are shared by multiple organizations which provides flexibility and cost savings but also puts an organization data at risk, as it might go into the hand of their competitors or wrong hands. Therefore, administrators before moving their data to cloud need to ensure that only all data in cloud is completely secure and accessible only by authorized users. The best solution to isolate your data and safeguard it against potential hackers or cloud super-users is to encrypt it. With robust data encryption algorithms like AES-256 or DES, we can ensure that our data is safe even if it goes into wrong hands.
Data Governance
For an organization to grow and make decisions regarding planning, performance, predictability and accountability, well-organized data governance needs to be setup. No wonder organizations can work together with cloud providers to achieve compliance level, but still governance should reside in the hands of organizations. With dynamic moving workloads and multi-region infrastructures, organizations needs to place strong governance policies, processes and procedures so that every event can be identified, tracked and controlled anytime. This will help organizations to track and guard against unauthorized access.
In the next series of blogs, we will be discussing more about data isolation & protection and data governance and how to achieve that.
Stay tuned!!
Note : This blogpost is aggregation of various data security points on cloud. I was supposed to add reference links but lost all of them. Thanks and sorry to all the whitepaper authors who wrote on different cloud data security points.
[AWS Cost Saving] Use combination of on-demand and spot instances in Auto-Scaling
While reading about using spot instances in auto-scaling, I came up with an idea regarding using spot instances in our production auto-scaling setup.
Before we discuss more about this, let’s identify possible issues with spot instances :
Whenever spot price goes above our bid price, we will lose all our instances.
If we keep on increasing our bid price depending upon spot price, there are chances that we might pay more than price of on-demand instances. There are cases where in order to retain spot instances, people have bid too high and spot prices touched $1000. The below image depicts that spot users have spend more than $4 per hour for a m1.large instance while on_demand_price is just $0.240 per hour.
Spot price varies from availability zones to availability zones.
To tackle these issues, I came across a solution to avoid all these issues.
Create two auto-scaling groups:
Let’s create two auto-scaling groups i.e., one with on-demand instances (running minimal instances i.e., min-size = max-size = 2 instances) and another with spot instances (running majority of our instances). Both auto-scaling groups can be attached to same elastic load balancer. As Elastic load balancer distributes requests in round-robin fashion, so this will make sure that requests get served either by on-demand instances or spot instances.
Let’s handle scale-up:
For on-demand auto-scaling group, we can set scale up policy whenever average CPU utilization crosses 70% while for spot auto-scaling group, we can set scale down policy whenever average CPU utilization crosses 60%. This will make sure every time auto-scaling scale up activity happens from spot auto-scaling group and we don't pay more.
Let’s handle scale down:
For scale down activity, on-demand auto-scaling group will scale down whenever average CPU utilization touches 20% while spot auto-scaling group will scale down at average CPU utilization touches 30%. As on-demand auto-scaling group has kind-of fixed instances therefore down scale will also happen from spot auto scaling group.
How to avoid losing spot instances and not end up paying more when spot prices > on-demand prices?
To achieve these objectives, I came up with a small pseudo code:
Step 1: Identify the availability zones and their spot prices by parsing the output of “ec2-describe-spot-price-history”.
Step 2: Pick the maximum spot price from the output of #1.
Step 4: Using our bid price, create a spot auto-scaling group – attach it to our load balancer.
Step 5: Keep performing #1 every minute. If difference between bid_price and spot price is less than 20% - Update bid price i.e., execute #3 – create new launch configuration – update autoscaling group with new launch configuration.
Step 6: Keep performing #1 every minute. If the difference between on_demand_price and spot_price is less than 20%, reduce the number of spot_instances and spin up same number of instances using on_demand_instances. For example : Reduce the number of spot_instances by 2 and spin up same number of on_demand_instances. Make sure that we have our 50% instances running as on_demand and another 50% as spot_instances.
If the gap between on_demand_price and bid_price is less than 10%, make sure our 75% of the load is handled by on_demand_instances i.e., our one-fourth instances are spot_instances and remaining ones are on_demand_instances. This can be achieved by using min_size, max_size and desired capacity parameters.
If the on_demand_price is greater than bid_price, set the min_size of spot_instances autoscaling group to zero. This will make sure all instances are on_demand_instances and we are not paying more than the price of on_demand_instances.
The reason why we are gradually reducing number of spot instances when the price difference between spot and on_demand is less than 10% or 20% is mainly because the whole auto-scaling process takes a bit of time (like 2-3 minutes) to launch an instances and get attached to load balancer, pass health checks and start serving out traffic and if we shut down all spot instances at the same time when spot_price > on_demand_price, the end-user experience will get affected. To avoid that, we suggest gradually increasing or decreasing auto-scaling instances.
The above mentioned solution is just a prototype. Obviously, this can be more fine-tuned. Please share your thoughts.
My previous two blogposts talks about jenkins installation and configuration on Amazon Linux and jenkins integration with GitHub to trigger automatic build process.
This post focus around uploading build artifacts to amazon s3.
To upload your build artifacts to amazon s3, create a S3 bucket.
Once done, navigate to Jenkins dashboard -> Manage Jenkins -> Manage Plugins and select available tab. Look for "S3 plugin" and install that.
Once done, go back to Manage Jenkins and select "Configure System" and look for "Amazon S3 Profiles". Please provide a profile name, access key and secret access key for your AWS account. Don't provide ROOT AWS User credentials. Create an IAM user will S3 permissions.
Once done, create a job under "Build a free-style software project".
Navigate down to "Post-Build Actions" and click on "Add Post-Build Action" and select "Publish Artifacts to S3 Bucket".
Then, select your S3 profile, pass source of the files to upload (if you want to upload all files, please use " * " else provide valid path), destination bucket name.
Now, click on save and you are done !!
All your build artifacts will get uploaded to Amazon S3 bucket.
Other Links :
Install and Configure jenkins on Amazon Linux
Integrate jenkins with GitHub to trigger automatic build process on code commit.
Integrate Jenkins and GitHub to trigger build process on code commit
My last blogpost was regarding installing and configuring jenkins on amazon linux ec2 instance. In continuation to that, this post focus around how we can integrate GitHub repository with jenkins CI server.
This blogpost talks about installing GitHub plugin on jenkins server, configuring GitHub repository on jenkins and creating service hooks on GitHub which will trigger build process as soon as someone's commit new code to GitHub repository.
INSTALL and CONFIGURE GITHUB PLUGIN ON JENKINS
To install GitHub plugin, navigate to your Jenkins Dashboard, click on "Manage Jenkins" and select "Manage Plugins".
On the plugins page, select "Available" tab and search for "GitHub plugin" under "External Site/Tool Integrations".
Install the plugin. This will restart Jenkins server.
Once done, navigate back to dashboard for "Manage Jenkins" and select "Configure System". Under that, you might observe that Git is not installed.
If so, login into your EC2 instance and issue command :
# yum install git
Once done, please go further down the page and provide your username and email details for GitHub account.
That's it !! We have installed and configured our GitHub plugin on jenkins.
CREATE JENKINS JOB AND CONFIGURE GITHUB REPOSITORY
After installing GitHub plugin, it is time to create Jenkins job and integrate GitHub repository to it.
On Jenkins dashboard, click on "New Job" and provide name to "Build a free style software project" job.
Provide the path of GitHub repository under "GitHub Project" and provide "repository URL" for "GIT" under "Source Code Management".
Lower down the page, don't forget to enable "Build when a change is pushed to GitHub".
Now, we have configured Jenkins job in such a way that whenever a change is committed to GitHub repository - this will trigger build process on Jenkins.
CONFIGURE GITHUB SERVICE HOOK
To trigger the build process on Jenkins, we need to configure service hook on GitHub. In order to achieve this, navigate to GitHub repository settings and configure Jenkins Hook URL for GitHub plugin.
The URL format : http://<jenkins-username>:<jenkins-password>@<Elastic-IP-Address>:8080/github-webhook/
That's it !! GitHub is now integrated with Jenkins. If any developer commits any code to GitHub repository, this will trigger the build process on Jenkins.
In the next post, we will look at post-build process i.e., upload build artifacts to Amazon S3 bucket.
If you have any questions/suggestions, please feel free to drop a comment.
OTHER LINKS :
Install and Configure Jenkins on Amazon Linux EC2 Instance
Install and Configure Jenkins on Amazon Linux EC2 Instance
Jenkins is one of the most popular open source continuous integration tool. It is written in Java. If you want to read about jenkins before installing it, please do read this link.
Environment Details :
Operating System : Amazon Linux 2013.03.01
AMI-ID : ami-3ffed17a
Security Group Ports : 8080
Installation Steps :
1. Please launch an Amazon Linux instance using Amazon Linux AMI.
8. Start jenkins and make sure it starts automatically at system startup
# service jenkins start
# chkconfig jenkins on
9. Open your browser and navigate to http://<Elastic-IP>:8080. You will see jenkins dashboard.
That's it. You have your jenkins setup up and running. Now, you can create jobs to build the code.
Securing Jenkins Setup :
As seen, your above installed jenkins setup is directly accessible through internet and there are no security measures to prevent direct access. In order to secure your jenkins setup, you need to enable some sort-of security authorization on it.
To enable security for jenkins setup, please select "Manage Jenkins" on jenkins dashboard and click on "Configure Global Security".
After this, please select "Enable Security".
Jenkins provide different level of security methods like integrating it with your LDAP setup or using Unix user/group database. In our case, we will create "Jenkins' Own User Database". So, please select "Jenkins's Own User Database" under security realm. Don't forget to select "Allow users to sign up". Also, select "Matrix-based security" under Authorization.
Now, please add an user (for eg., admin) to jenkins user database by adding username under matrix-based security section.
Once done, please provide necessary privileges to this user. In our case, we make this user as an administrator, so he will have full privileges.
Once done, please click on save. Now, you will be asked to provide username and password for the user to login. But we don't have any. So, please click on "Create an account".
Now, please provide your username ( "admin" in our case) and provide necessary details like password, name and email address.
Once done, you will be logged into jenkins and your whole setup is secured.
Now, you can create jenkins jobs without any security issues.
In next blogpost, I'll discuss about how to integrate our jenkins setup with github.
If you have any questions/comments regarding this post, please drop a comment.
Install, Configure and Host your website using WHM - cPanel on AWS
In my previous post, I wrote about compatibility check for cPanel on AWS. As previously mentioned, cPanel doesn’t support Amazon Linux, requires redhat network subscription for RHEL and comfortably supports CentOS.
Lets go ahead and install cPanel on CentOS.
Environment Details :
Operating System : CentOS 6.3
cPanel and WHM Version : 11.34
AMI Id : ami-02765547
Installation and Configuration Steps :
Step 1 : Launch a CentOS instance.
Step 2 : Login to your CentOS instance using your private key.
Step 3 : Update and Upgrade your repositories and packages
# yum update –y
Step 4 : Install yum-plugin-fastestmirror
# yum install yum-plugin-fastestmirror
Step 5 : Download latest copy of cPanel
# wget –N http://httpupdate.cpanel.net/latest
Step 6 : Install cPanel on your CentOS instance
# sh latest
cPanel installation takes a lot of time (between 30-60 mins). So, grab a coffee and relax.
Once an installation is over, you will observe something like this :
For me, installation took more than 50 minutes. Once done, please reboot your instance.
# sudo init 6
Step 7 : Setup your CentOS root password
# passwd root
If possible, please map your cPanel CentOS instance to a domain name.
Step 8: Browse your WHM console on port 2087
If you don’t have a valid certificate, you might receive a window “Untrusted Communication”, don’t worry about that. Just add that as an exception.
Login into your WHM console using username “root” and root user password which we setup in step 6.
Step 9: Perform Initial Setup
Accept Agreement
Setup Networking
Provide hostname, contact email address, DNS resolvers etc.
Setup IP Addresses – You can skip this step
Configure Nameservers
You can provide your DNS provide nameservers.
Configure services – select whatever services you need (FTP, Mail Configuration etc)
Setup quotas
Bingo – we are done with initial WHM setup and it will look something like this.
Step 10: Create a new hosting account
Navigate to Account Functions >> Create a new account
Pass all the necessary information like domain names, select your package, Resellers settings etc. In our case, hosting account domain name will be blog.sanketdangi.com
Once you provided all this information, click on CREATE and this will create a cPanel account for this domain. You can pass this information to the user who has requested this.
Step 11 : Host your website using newly created cPanel account
To host your website, you need to login into your cPanel dashboard on port 2083. Pass your credentials created in step 9.
On login, you will receive a dashboard like this.
To create new content or upload new content, select File Manager.
Create a file in your public html folder. Lets say – index.html.
Add content to your index.html file.
Bingo – we have created a website – create new content. Time to view your site.
Browse your website url. In our case, it is blog.sanketdangi.com.
And we are done. We have installed cPanel + WHM on a CentOS instance, configured WHM, created a hosting account in WHM and configured out website through cPanel.
If you have questions or anything to share or point out any mistakes, please feel free to leave a comment.
As we all know, cPanel is one of the most popular web hosting control panel which provides a simple graphical interface and automation tools to host and manage our websites. Below mentioned are few points to consider before you plan to install cPanel on AWS.
Beginning main installation.
2013-07-30 12:48:50 557 ( INFO): cPanel install started at: Tue Jul 30 12:48:50 2013!
2013-07-30 12:48:50 558 ( INFO): This install will take 20-50 minutes depending on your hardware.
2013-07-30 12:48:50 559 ( INFO): Now is the time to go get another cup of coffee/jolt.
2013-07-30 12:48:50 560 ( INFO): The install will log to /var/log/cpanel-install.log.
2013-07-30 12:48:50 561 ( INFO):
2013-07-30 12:48:50 562 ( INFO): Beginning Installation v3
2013-07-30 12:48:50 479 (ERROR): I could not detect '/etc/redhat-release'.
2013-07-30 12:48:50 480 (ERROR): Unsupported distro detected. cPanel only supports CentOS, RedHat Enterprise, and CloudLinux 5 and 6
2013-07-30 12:48:50 481 (FATAL): Please re-install cPanel from a valid distro
Removing /root/installer.lock
Even if you try to create /etc/redhat-release file, it will look for rpm from which redhat-release file is created. We will witness another error like this : “2013-07-30 13:14:03 479 (ERROR): Unexpected RPM 'file /etc/redhat-release is not owned by any package' found managing the file /etc/redhat-release.”
2. cPanel supports RHEL but it requires RHEL subscription which is again a paid thing. If you try to install cPanel on RHEL without subscription, it will ask you to login into RHEL subscription manager. Below mentioned are installation log :
Beginning main installation.
2013-07-30 10:13:34 557 ( INFO): cPanel install started at: Tue Jul 30 10:13:34 2013!
2013-07-30 10:13:34 558 ( INFO): This install will take 20-50 minutes depending on your hardware.
2013-07-30 10:13:34 559 ( INFO): Now is the time to go get another cup of coffee/jolt.
2013-07-30 10:13:34 560 ( INFO): The install will log to /var/log/cpanel-install.log.
2013-07-30 10:13:34 561 ( INFO):
2013-07-30 10:13:34 562 ( INFO): Beginning Installation v3
2013-07-30 10:13:34 462 ( INFO): redhat-server 6 (Linux) detected!
2013-07-30 10:13:34 490 ( INFO): Validating that 'ip-10-188-161-32.us-west-1.compute.internal' is a FQDN
2013-07-30 10:13:34 1562 ( INFO): Checking Red Hat registration for updates
Unable to locate SystemId file. Is this system registered?
2013-07-30 10:13:42 1622 ( INFO): Validating you are subscribed to the optional RHN channel
2013-07-30 10:13:42 1636 (ERROR): You do not appear to be registered with a known base channel for redhat
2013-07-30 10:13:42 1637 (ERROR): $> /usr/sbin/spacewalk-channel --list
Unable to locate SystemId file. Is this system registered?
This system has no repositories available through subscriptions.
If you have redhat network subscription, you need to register your RHEL instance using rhn_register command.
3. If you don’t have redhat network subscription and don’t want to purchase that – it is advisable to use CentOS for your cPanel installation. cPanel works very well on CentOS environment. In my next blog post, I’ll post steps to install and configure cPanel on AWS.
AWS RDS Read Replica Load Balancing by defining multiple databases in PHP
With high traffic and more read requests, it is always advisable to split read and writes where our write queries goes to master database and read queries goes to slaves i.e., read replicas in AWS. Amazon provides option of creating 5 read replicas for our master database. When we have multiple read replicas, we need to load balance read requests between them. Already few people have made a feature request to Amazon to introduce load balancer at read replica level. Also, there are multiple solutions available to achieve this i.e., using HAProxy or MySQL Proxy.
Below mentioned is sample code :
(Disclaimer: I’m not a php expert. In fact this is the first time, I have written code in php. Please forgive me if coding standards are not met)
If you access this code on your browser, you will see something like this mentioned below :
Above mentioned output displays name of the read replica i.e., read replica from which other two records were fetched. If we refresh our screen, we will witness different read replica name which means request is served from different read replica.
Configuring PHPMYADMIN on Amazon EC2 to manage Amazon RDS
Well, the installation procedure of PHPMYADMIN is very simple and there are numerous blogs available across web which will help you to configure phpmyadmin.
Even, I followed same blogs/articles to configure phpmyadmin. But things didn't clicked for me. I figured out the reason and thought of writing a new blog on this.
There are two ways to configure phpmyadmin :
1. Download phpmyadmin package and install that.
I followed 2nd procedure.
Installation Steps :
1. To install phpmyadmin package :
# sudo yum --enablerepo=epel install phpmyadmin
2. Navigate to file "/etc/httpd/conf.d/phpMyAdmin.conf" and make sure you can access phpMyAdmin from outside (your local pc).
<Directory /usr/share/phpMyAdmin/>
<IfModule mod_authz_core.c>
# Apache 2.4
<RequireAny>
# Require ip 127.0.0.1
Require ip <Add-your-IP>
Require ip ::1
</RequireAny>
</IfModule>
<IfModule !mod_authz_core.c>
# Apache 2.2
Order Deny,Allow
Deny from All
# Allow from 127.0.0.1
Allow from <Add-your-IP>
Allow from ::1
</IfModule>
</Directory>
3. Edit mysql host in config.inc.php file
In order to access RDS database, we need to modify mysql host in config.inc.php file. Most of the blogs across web points to /usr/share/phpMyAdmin folder and copying config.sample.inc.php as config.inc.php. But modifying mysql host in this file didn't work for me.
In order to get that working, I had to modify config.inc.php in /etc/phpMyAdmin.
#2002 - Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
The server is not responding (or the local server's socket is not correctly configured).
Then most probably, you haven't modified mysql host in config.inc.php present in /etc/phpMyAdmin. Modifying mysql host in config.inc.php present in /usr/share/phpMyAdmin may not work for you.
Do let me know if you have any suggestions or alternatives.
According to AWS, “Amazon Machine Images (AMIs) are the basic building blocks of Amazon EC2. An AMI is a template that contains a software configuration (operating system, application server, and applications) that you can run on Amazon's proven computing environment.”
For example, an AMI might contain the software to act as a web server (Linux, Apache, and your web site) or it might contain the software to act as a Hadoop node (Linux, Hadoop, and a custom application).
There are three types of AMI’s :
A. Public AMI – These are the ones which are freely available, advertised and shared with all AWS accounts. AWS has a huge collection of Public AMI’s.
B. Paid AMI – These are the ones which you can purchase from AWS marketplace, developers or service contract with any organization like RedHat.
C. Private AMI – These are the AMI’s which are generated from Public AMI’s and customized by us for our future use. They are available in only our AWS account. If we want we can share these AMI’s with other AWS accounts too. Also, if we want to share our private AMI with whole AWS community, we can convert that into a public AMI.
Below mentioned are some pointers which one can consider before bundling AMI’s :
1. Remove Authorized Keys
Before bundling an AMI out of your current instance, please make sure to remove existing entries in .ssh/authorized_keys else the key from which the instance is launched will be automatically included. In case you forget to remove that entry, login into new instance (coming from newly bundled AMI) is only possible through old keypair. New keypairs won’t work.
For e.g., if the current instance is launched using keypair-1.pem and before bundling AMI, you have forgot to remove entries from authorized_keys, then access to new instance from newly bundled AMI is only possible through keypair-1.pem only. If you launch new instance using keypair-2.pem, we won’t be able to login into instance using keypair-2.pem file.
Important : You will lose access to your current instance if you remove authorized_keys and exit from your current ssh session. Hence, ssh into same instance won’t be allowed.
2. Delete history
It is always good to clear your command history. before bundling an AMI. For clearing your command history, remove .bash_history or issue command “history –c”. There are possibilities that you might have issued commands using your access key and secret keys, private key pairs or other sensitive information.
3. Provide meaningful names
It is advisable to provide meaningful names to your AMI’s and also post small description. It provides easy search for other users. This is strongly recommended if you plan to make your AMI as Public AMI.
4. Empty log files
It is always good habit if you clear your existing log files before bundling AMI. Your instance might have logs files from various packages like apache, tomcat etc.
5. Remove sensitive data
Don’t forget to remove any private keypairs and x.509 certificates or any additional confidential sensitive data if used.
6. Delete all downloaded packages and files
If you have downloaded some packages (like s3cmd tools) or additional files and configured them on your instance, please remove them before bundling AMI.
7. Disable SELINUX while bundling instance store backed AMI’s
If you are bundling instance store backed AMI’s, please remember to disable SELINUX before issuing ec2-bundle-vol command.
If you have any suggestions, please do let me know. Thanks !!
Chef Cookbooks : Configure Apache and Deploy SSL Certificates on RHEL EC2 Chef Client
If we look at cookbooks structure, it comprises of attributes, definitions, libraries, templates, files etc.
Please have a look at this link to learn about cookbook structure: http://docs.opscode.com/chef_overview_cookbooks.html
Objective of this post :
Install and Configure apache
Stop iptables
Deploy SSL certificates
Lets start !!
Note : Please note that this post is focused towards RHEL environment. Steps will vary if you use different flavor of Linux.
Step 1 : Create a cookbook apache
# knife cookbook create apache
The create argument is used to create a new cookbook directory which will include following directories and files
cookbook/attributes
cookbook/CHANGELOG.md
cookbook/definitions
cookbook/files/default
cookbook/libraries
cookbook/metadata.rb
cookbook/providers
cookbook/README.md
cookbook/recipes/default.md
cookbook/resources
cookbook/templates/default
Step 2 : Copy your SSL certificates to cookbook files folder
Before copying files, a folder is created in cookbooks/apache/files/default called “certificates”. After that, our SSL certificates are copied in certificates folder.
Step 3: Define attributes variables
Here, we are going to define certain attributes which will be retrieved from chef server and merged with chef client when cookbooks are run against chef clients. These attributes are apache directory path, directory where our SSL certificates will be copied, apache server name.
Create a file called “default.rb” in cookbooks/apache/attributes folder and define these variables:
Create recipes which will install apache and mod_ssl, stop services iptables and ip6tables, create a directory in chef-client called “/etc/httpd/ssl”, copy ssl certificates present in chef server’s certificates folder to client’s /etc/httpd/ssl, change selinux security context for ssl certificates, modify ssl certificate path and servername in ssl.conf
The apache recipe to achieve all these objectives is shown below :
# Cookbook Name:: apache # Recipe:: default # # Copyright 2013, YOUR_COMPANY_NAME # # All rights reserved - Do Not Redistribute # # Install httpd package but don’t start it package "httpd" do action [:install] end # Install mod_ssl package to enable ssl module in apache package "mod_ssl" do action [:install] end # Stop iptables service permanently service "iptables" do action [:disable,:stop] end # Stop ip6tables service permanently service "ip6tables" do action [:disable,:stop] end # Create /etc/httpd/ssl directory on chef client directory "#{node['apache']['dir']}/ssl" do action :create recursive true mode 0755 end # Copy ssl certificates from certificates folder to client’s /etc/httpd/ssl folder remote_directory "#{node['apache']['dir']}/ssl" do source "certificates" files_owner "root" files_group "root" files_mode 00644 owner "root" group "root" mode 0755 end # This will make changes to ssl.conf template "/etc/httpd/conf.d/ssl.conf" do source "ssl.conf.erb" mode 0644 owner "root" group "root" variables( :sslcertificate => "#{node['apache']['sslpath']}/chef_sanketdangi_com.crt", :sslkey => "#{node['apache']['sslpath']}/chef.sanketdangi.com.key", :sslcacertificate => "#{node['apache']['sslpath']}/chef_sanketdangi_com.ca-bundle", :servername => "#{node['apache']['servername']}" ) end # change selinux security context for ssl certificates execute "change_for_selinux" do command "chcon -Rv --type=httpd_sys_content_t /etc/httpd/ssl/" action :run end # start httpd service service "httpd" do action [:enable,:start] end
Now, if we look at template section of our default.rb recipe :
template "/etc/httpd/conf.d/ssl.conf" do source "ssl.conf.erb" mode 0644 owner "root" group "root" variables( :sslcertificate => "#{node['apache']['sslpath']}/chef_sanketdangi_com.crt", :sslkey => "#{node['apache']['sslpath']}/chef.sanketdangi.com.key", :sslcacertificate => "#{node['apache']['sslpath']}/chef_sanketdangi_com.ca-bundle", :servername => "#{node['apache']['servername']}" ) end
The variables sslcertificate, sslkey, sslcacertificate, servername will be resolved using values mentioned in attributes files.
Step 4: Define templates
As seen above, we have defined template in our recipes. Chef encourages use of templates instead of line by line modification in configuration files. A cookbook template is a file written in a markup language that allows the contents of a file to be dynamically generated based on variables or complex logic. Templates can contain Ruby expressions and statements. Templates are a great way to manage configuration files across a Chef environment.
Basically, we have to copy our ssl.conf and put it inside cookbooks/apache/templates/default folder and rename it to ssl.conf.erb. In order to ssl certificates work perfectly with apache, we need to modify server name and SSL certificates path.
We have modified certain parameters in ssl.conf.erb as shown below :
ServerName <%= @servername %>:443
This will resolve to ServerName chef.sanketdangi.com:443 as @servername (which is defined under template section in default.rb recipe) points to default[‘apache’][‘dir’] in attributes file.
SSLCertificateFile <%= @sslcertificate %>
This will resolve to SSLCertificateFile /etc/httpd/ssl/chef_sanketdangi_com.crt as @sslcertificate (which is defined under template section in default.rb) points to sslcertificate path
SSLCertificateKeyFile <%= @sslkey %>
This will resolve to SSLCertificateKeyFile /etc/httpd/ssl/chef.sanketdangi.com.key as @sslkey points to sslcertificate key path
SSLCACertificateFile <%= @sslcacertificate %>
This will resolve to SSLCACertificateFile /etc/httpd/ssl/chef_sanketdangi_com.ca-bundle as @sslcacertificate points to SSLCACertificate path.
Our ssl.conf.erb will look like :
# # This is the Apache server configuration file providing SSL support. # It contains the configuration directives to instruct the server how to # serve pages over an https connection. For detailing information about these # directives see <URL:http://httpd.apache.org/docs/2.2/mod/mod_ssl.html> # # Do NOT simply read the instructions in here without understanding # what they do. They're here only as hints or reminders. If you are unsure # consult the online docs. You have been warned. # LoadModule ssl_module modules/mod_ssl.so # # When we also provide SSL we have to listen to the # the HTTPS port in addition. # Listen 443 ## ## SSL Global Context ## ## All SSL configuration in this context applies both to ## the main server and all SSL-enabled virtual hosts. ## # Pass Phrase Dialog: # Configure the pass phrase gathering process. # The filtering dialog program (`builtin' is a internal # terminal dialog) has to provide the pass phrase on stdout. SSLPassPhraseDialog builtin # Inter-Process Session Cache: # Configure the SSL Session Cache: First the mechanism # to use and second the expiring timeout (in seconds). SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000) SSLSessionCacheTimeout 300 # Semaphore: # Configure the path to the mutual exclusion semaphore the # SSL engine uses internally for inter-process synchronization. SSLMutex default # Pseudo Random Number Generator (PRNG): # Configure one or more sources to seed the PRNG of the # SSL library. The seed data should be of good random quality. # WARNING! On some platforms /dev/random blocks if not enough entropy # is available. This means you then cannot use the /dev/random device # because it would lead to very long connection times (as long as # it requires to make more entropy available). But usually those # platforms additionally provide a /dev/urandom device which doesn't # block. So, if available, use this one instead. Read the mod_ssl User # Manual for more details. SSLRandomSeed startup file:/dev/urandom 256 SSLRandomSeed connect builtin #SSLRandomSeed startup file:/dev/random 512 #SSLRandomSeed connect file:/dev/random 512 #SSLRandomSeed connect file:/dev/urandom 512 # # Use "SSLCryptoDevice" to enable any supported hardware # accelerators. Use "openssl engine -v" to list supported # engine names. NOTE: If you enable an accelerator and the # server does not start, consult the error logs and ensure # your accelerator is functioning properly. # SSLCryptoDevice builtin #SSLCryptoDevice ubsec ## ## SSL Virtual Host Context ## <VirtualHost _default_:443> # General setup for the virtual host, inherited from global configuration #DocumentRoot "/var/www/html" ServerName <%= @servername %>:443 # Use separate log files for the SSL virtual host; note that LogLevel # is not inherited from httpd.conf. ErrorLog logs/ssl_error_log TransferLog logs/ssl_access_log LogLevel warn # SSL Engine Switch: # Enable/Disable SSL for this virtual host. SSLEngine on
# SSL Protocol support: # List the enable protocol levels with which clients will be able to # connect. Disable SSLv2 access by default: SSLProtocol all -SSLv2 # SSL Cipher Suite: # List the ciphers that the client is permitted to negotiate. # See the mod_ssl documentation for a complete list. SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW # Server Certificate: # Point SSLCertificateFile at a PEM encoded certificate. If # the certificate is encrypted, then you will be prompted for a # pass phrase. Note that a kill -HUP will prompt again. A new # certificate can be generated using the genkey(1) command. SSLCertificateFile <%= @sslcertificate %> # Server Private Key: # If the key is not combined with the certificate, use this # directive to point at the key file. Keep in mind that if # you've both a RSA and a DSA private key you can configure # both in parallel (to also allow the use of DSA ciphers, etc.) SSLCertificateKeyFile <%= @sslkey %> # Server Certificate Chain: # Point SSLCertificateChainFile at a file containing the # concatenation of PEM encoded CA certificates which form the # certificate chain for the server certificate. Alternatively # the referenced file can be the same as SSLCertificateFile # when the CA certificates are directly appended to the server # certificate for convinience. #SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt # Certificate Authority (CA): # Set the CA certificate verification path where to find CA # certificates for client authentication or alternatively one # huge file containing all of them (file must be PEM encoded) SSLCACertificateFile <%= @sslcacertificate %> # Client Authentication (Type): # Client certificate verification type and depth. Types are # none, optional, require and optional_no_ca. Depth is a # number which specifies how deeply to verify the certificate # issuer chain before deciding the certificate is not valid. #SSLVerifyClient require #SSLVerifyDepth 10 # Access Control: # With SSLRequire you can do per-directory access control based # on arbitrary complex boolean expressions containing server # variable checks and other lookup directives. The syntax is a # mixture between C and Perl. See the mod_ssl documentation # for more details. #<Location /> #SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \ # and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \ # and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \ # and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \ # and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \ # or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/ #</Location> # SSL Engine Options: # Set various options for the SSL engine. # o FakeBasicAuth: # Translate the client X.509 into a Basic Authorisation. This means that # the standard Auth/DBMAuth methods can be used for access control. The # user name is the `one line' version of the client's X.509 certificate. # Note that no password is obtained from the user. Every entry in the user # file needs this password: `xxj31ZMTZzkVA'. # o ExportCertData: # This exports two additional environment variables: SSL_CLIENT_CERT and # SSL_SERVER_CERT. These contain the PEM-encoded certificates of the # server (always existing) and the client (only existing when client # authentication is used). This can be used to import the certificates # into CGI scripts. # o StdEnvVars: # This exports the standard SSL/TLS related `SSL_*' environment variables. # Per default this exportation is switched off for performance reasons, # because the extraction step is an expensive operation and is usually # useless for serving static content. So one usually enables the # exportation for CGI and SSI requests only. # o StrictRequire: # This denies access when "SSLRequireSSL" or "SSLRequire" applied even # under a "Satisfy any" situation, i.e. when it applies access is denied # and no other module can change it. # o OptRenegotiate: # This enables optimized SSL connection renegotiation handling when SSL # directives are used in per-directory context. #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire <Files ~ "\.(cgi|shtml|phtml|php3?)$"> SSLOptions +StdEnvVars </Files> <Directory "/var/www/cgi-bin"> SSLOptions +StdEnvVars </Directory> # SSL Protocol Adjustments: # The safe and default but still SSL/TLS standard compliant shutdown # approach is that mod_ssl sends the close notify alert but doesn't wait for # the close notify alert from client. When you need a different shutdown # approach you can use one of the following variables: # o ssl-unclean-shutdown: # This forces an unclean shutdown when the connection is closed, i.e. no # SSL close notify alert is send or allowed to received. This violates # the SSL/TLS standard but is needed for some brain-dead browsers. Use # this when you receive I/O errors because of the standard approach where # mod_ssl sends the close notify alert. # o ssl-accurate-shutdown: # This forces an accurate shutdown when the connection is closed, i.e. a # SSL close notify alert is send and mod_ssl waits for the close notify # alert of the client. This is 100% SSL/TLS standard compliant, but in # practice often causes hanging connections with brain-dead browsers. Use # this only for browsers where you know that their SSL implementation # works correctly. # Notice: Most problems of broken clients are also related to the HTTP # keep-alive facility, so you usually additionally want to disable # keep-alive for those clients, too. Use variable "nokeepalive" for this. # Similarly, one has to force some clients to use HTTP/1.0 to workaround # their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and # "force-response-1.0" for this. SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 # Per-Server Logging: # The home of a custom SSL log file. Use this when you want a # compact non-error SSL logfile on a virtual host basis. CustomLog logs/ssl_request_log \ "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b" </VirtualHost>
Step 5 : Upload cookbook
# knife cookbook upload apache
Step 6 : Create Role
Before creating role, please set EDITOR environment variable in order to avoid EDITOR environment runtime error
To set EDITOR environment variable, please issue below mentioned command :
# export EDITOR=$(which vi)
For persistence, please add this line to .bashrc or .bash_profile.
# knife role create webserver
On issuing command, we will observe something like this :
Now, we have our webserver role and cookbook ready which can be deployed on our EC2 clients.
Step 7: Bootstrap EC2 clients and configure webserver role on them
A bootstrap is a process that installs Chef on a target system so that it can run as a chef-client and communicate with a Chef Server. Let’s assume the internal dns of our EC2 chef client is ip-10-141-154-133.ec2.internal.
This command will configure chef client on our EC2 clients and configure webserver role on them i.e., it will install apache, start apache service, configure SSL certificates and stop iptables.
That is, we have configured SSL certificates. Now, we should be able to access https://<domain-name>.
Note : We have to make sure our domain name is pointed to EC2 chef-client.
Thanks !!
Other Links :
Install and Configure Chef Server 11 on Amazon EC2 RHEL 6.3 Instance :
http://sanketdangi.com/post/50649257357/chef-11-configuration-aws-ec2-rhel-6-3-instance
Chef Cookbooks, Roles and Bootstrapping AWS EC2 RHEL Instances : http://sanketdangi.com/post/50663896403/cookbooks-roles-and-bootstraping-aws-ec2-rhel-instances
Launch EC2 Instances using Chef Server : http://sanketdangi.com/post/50718603662/launch-ec2-instances-using-chef
ERROR: Error installing knife-ec2:
ERROR: Failed to build gem native extension.
/usr/bin/ruby extconf.rb
checking for libxml/parser.h... no
-----
libxml2 is missing. please visit http://nokogiri.org/tutorials/installing_nokogiri.html for help with installing dependencies.
-----
*** extconf.rb failed ***
Solution :
yum install libxslt libxslt-devel
This command will install all necessary dependencies for knife ec2 gem.
Error 3 : Error while downloading cookbooks to your local laptop/PC from Chef Server (which is hosted on AWS EC2)
nameless@Nameless:~$ knife cookbook download apache
Downloading apache cookbook version 0.1.0
Downloading resources
Downloading providers
Downloading recipes
ERROR: Network Error: Error connecting to https://ip-10-190-87-80.ec2.internal/bookshelf/organization-00000000000000000000000000000000/checksum-9084de40dd574612517c5c00a2a502bb?AWSAccessKeyId=145e4345cadce32e88d7cd21dfd7808460e15146&Expires=1369139721&Signature=/36/gcGdqdT3EBzDTQv5unEVHdw%3D - getaddrinfo: Name or service not known
Check your knife configuration and network settings
Solution :
We face this error because the s3_url which is set to EC2 private dns address is used by erchef to talk to bookshelf and used to generate URLs that are given to clients that they use to access cookbook content.
To fix this, we need to add :
erchef['s3_url'] = https://<AWS-EIP>
to /etc/chef-server/chef-server.rb file. If the file is not present, please create that. Once done, please issue "chef-server-ctl reconfigure" command. [Thanks to Gionn and JB for highlighting this - see comments]
Another solution (Less Suggested) :
PATH : /var/opt/chef-server/erchef/etc/app.config
Modify s3_url from EC2 private dns address to EC2 EIP/Public DNS i.e., modify {s3_url, "https://ip-10-190-87-80.ec2.internal"} to {s3_url, "https://<AWS-EIP>"}.
After that, please perform a system restart. If you issue, chef-server-ctl reconfigure command, it will set s3_url value to original value.
FATAL: Net::HTTPServerException: template[/etc/httpd/conf/httpd.conf] (apache::default line 20) had an error: Net::HTTPServerException: 403 "Forbidden"
Solution : This error is encountered when we have large chef recipes whose deployment time on clients is large than 15 minutes. In order to avoid this error, please increase "s3_url_ttl" value from 900 seconds to required time interval.To increase this value, please add
erchef['s3_url_ttl'] = 900 in /etc/chef-server/chef-server.rb file. Once done, please issue "chef-server-ctl reconfigure" command. (Thanks Gionn and JB for highlighting this - see comments).
Another Solution (Less Suggested) :
We can find this value in app.config file under path "/var/opt/chef-server/erchef/etc"
After that, please perform a system restart. If you issue, chef-server-ctl reconfigure command, it will set s3_url value to original value.
Error 5 : RabbitMQ does not start on Oracle or Amazon Linux
RabbitMQ doesn't start when "chef-server-ctl reconfigure" command issued.
Solution : This error is encountered on Amazon Linux because amazon linux platform is not definited in runit chef recipe for chef server.
To fix this issue, navigate to "/opt/chef-server/embedded/cookbooks/runit/recipes/default.rb" and add below mentioned line after ubuntu platform description :
when "amazon" include_recipe "runit::upstart"
After that, the default.rb will look like :
case node["platform"] when "ubuntu" include_recipe "runit::upstart" when "amazon" include_recipe "runit::upstart"
when "redhat","centos","rhel","scientific" if node['platform_version'] =~ /^6/ include_recipe "runit::upstart" else include_recipe "runit::sysvinit" end
Once done, please issue "chef-server-ctl reconfigure" command again.
In my last blog, we discussed how to create cookbooks, roles and bootstrap AWS EC2 instances. In this post, we will see how to launch EC2 instances and assign roles to them using chef server.
For achieving our objective, we need to configure knife ec2 gem on our chef server or workstation.
Requirements:
· We have our chef server up and running.
· Cookbooks and roles are already created and cookbooks uploaded to chef server.
· Please make sure port 22 and 80 are open in chef clients EC2 instances security group.
· Make sure AWS keypair using which we want to launch our instances is copied to our chef server or workstation.
Before installing knife ec2 gem, please install libxslt and libxslt-devel packages. This will install all necessary dependencies required for successful configuration of knife ec2 gem.
# yum install libxslt libxslt-devel
Now, we are ready to install knife ec2 gem.
# gem install knife-ec2 --no-rdoc --no-ri
Now, configure your AWS settings in knife.rb file. Most probably, knife.rb file will be located under /root/.chef folder.
For configuring AWS credentials, please paste below mentioned line in the end of knife.rb file
ec2-23-22-209-62.compute-1.amazonaws.com - stop service service[ip6tables]
ec2-23-22-209-62.compute-1.amazonaws.com
ec2-23-22-209-62.compute-1.amazonaws.com
ec2-23-22-209-62.compute-1.amazonaws.com Chef Client finished, 7 resources updated
Instance ID: i-d9b40eb3
Flavor: m1.small
Image: ami-cc5af9a5
Region: us-east-1
Availability Zone: us-east-1a
Security Groups: chef-client
Security Group Ids: default
Tags: Namei-d9b40eb3
SSH Key: sanketkey
Root Device Type: ebs
Root Volume ID: vol-5c4a0a04
Root Device Name: /dev/sda1
Root Device Delete on Terminate: true
Public DNS Name: ec2-23-22-209-62.compute-1.amazonaws.com
Public IP Address: 23.22.209.62
Private DNS Name: ip-10-137-62-163.ec2.internal
Private IP Address: 10.137.62.163
Environment: _default
Run List: role[webserver]
Bingo !! Our EC2 instance is launched and we have configured apache on it. If we browse EC2 public DNS this newly launched instance, it will take us to default test page of apache.
If there are any errors or doubts, please leave a comment.
To Learn how to configure Chef Server 11 :
http://sanketdangi.com/post/50649257357/chef-11-configuration-aws-ec2-rhel-6-3-instance
To create cookbook, roles and bootstrap EC2 instances :
http://sanketdangi.com/post/50663896403/cookbooks-roles-and-bootstraping-aws-ec2-rhel-instances
Chef Cookbooks,Roles and Bootstrapping AWS EC2 RHEL Instances
After chef server installation and configuration, it is time to start cooking i.e., writing cookbooks.
A cookbook is the fundamental unit of configuration and policy distribution in Chef. Each cookbook defines a scenario, such as everything needed to install and configure MySQL, and then it contains all of the components that are required to support that scenario, including:
· Attribute values that are set on nodes
· Definitions that allow the creation of reusable collections of resources
· File distributions
· Libraries that extend Chef and/or provide helpers to Ruby code
· Recipes that specify which resources to manage and the order in which those resources will be applied
· Custom resources and providers
· Templates
· Metadata about recipes (including dependencies), version constraints, supported platforms, and so on
Step 1: Create a cookbook
# knife cookbook create apache
The create argument is used to create a new cookbook directory in "/var/chef/cookbooks" which will include following directories and files:
cookbook/attributes
cookbook/CHANGELOG.md
cookbook/definitions
cookbook/files/default
cookbook/libraries
cookbook/metadata.rb
cookbook/providers
cookbook/README.md
cookbook/recipes/default.md
cookbook/resources
cookbook/templates/default
Step 2: Write a recipe which will install apache, start apache service and disable iptables on client machine
# cd /var/chef/cookbooks/apache
# vi recipes/default.rb
package "httpd" do
action [:install]
end
service "httpd" do
action [:enable,:start]
end
service “iptables” do
action [:disable,:stop]
end
Step 3 : Upload cookbook to your chef server
# knife cookbook upload apache
tep 4 : Once our cookbook is ready, we can create roles.
Before creating role, please set EDITOR environment variable in order to avoid EDITOR environment runtime error
To set EDITOR environment variable, please issue below mentioned command :
# export EDITOR=$(which vi)
For persistence, please add this line to .bashrc or .bash_profile.
# knife role create webserver
On issuing command, we will observe something like this :
{
"run_list": [
],
"chef_type": "role",
"env_run_lists": {
},
"description": "",
"override_attributes": {
},
"json_class": "Chef::Role",
"default_attributes": {
},
"name": "webserver"
}
Please modify it to :
{
"run_list": [
"recipe[apache]"
],
"chef_type": "role",
"env_run_lists": {
},
"description": "apache webserver",
"override_attributes": {
},
"json_class": "Chef::Role",
"default_attributes": {
},
"name": "webserver"
}
Now, we have our webserver role and cookbook ready which can be deployed on our EC2 clients.
Step 5: Bootstrap EC2 clients and configure webserver role on them
A bootstrap is a process that installs Chef on a target system so that it can run as a chef-client and communicate with a Chef Server.
This command will configure chef client on our EC2 clients and configure webserver role on them i.e., this will install apache, start apache service and stop iptables.
The full output of this command would be like this :
Bootstrapping Chef on ip-10-141-154-133.ec2.internal
Install and Configure Chef Server 11 on Amazon EC2 RHEL 6.3 Instance
What is Chef?
Chef is a systems and cloud infrastructure automation framework that makes it easy to deploy servers and applications to any physical, virtual, or cloud location, no matter the size of the infrastructure. Each Chef organization is comprised of one (or more) workstations, a single server, and every node that will be configured and maintained by Chef. Cookbooks (and recipes) are used to tell Chef how each node in your organization should be configured. The chef-client (which is installed on every node) does the actual configuration.
In this post, we are going to install and configure chef server 11.0.8 on a RHEL 6.3 EC2 instance.
Before moving forward, we need to understand that there are two ways to manage our infrastructure i.e., using a chef-server for all purposes or splitting work between chef-server and workstations. A workstation is a computer that is configured to run knife, to synchronize with the chef repository, and interact with a single chef server. The workstation is location, from which most users of chef will do most of their work, including:
· Developing cookbooks and recipes
· Keeping the chef repository synchronized with version source control
· Using knife to upload items from the chef repository to the chef server
In this blog, we will be using chef server for all purposes i.e., running knife, creating cookbooks and recipes, chef repository etc.
Environment Details
Operating System : RHEL 6.3
Instance Type : m1.small
AMI ID : ami-cc5af9a5
Chef Server Version : 11.0.8
Region : US-East-1
Availability Zone : US-East-1A
Security Group Ports : 22,443
Installation and Configuration Steps
Step 1: Before installing chef-server, it is advisable to update your repositories
# yum update –y
Step 2: By default, iptables rules are operational in RHEL instances. We need to make sure that they are stopped always.
# service iptables stop
# service ip6tables stop
# chkconfig iptables off
# chkconfig ip6tables off
Step 3: Download chef-server rpm from opscode website. In order to get download link, navigate to http://www.opscode.com/chef/install/ and select Chef Server tab. Select necessary operating system(Enterprise Linux), version(6) and architecture(x86_64). Select the version of Chef Server 11.x to download, and then click the link that appears to download the package.
In order to download package on ec2 instance, copy link location and download using wget
Step 5: Execute chef-server-ctl command to configure chef-server.
The chef-server-ctl reconfigure command reads the /etc/chef-server/chef-server.rb file and applies the specified configuration to the system. Any time you make a change to your configuration, you need to run chef-server-ctl reconfigure to apply it. This command will set up all of the required components, including Erchef, RabbitMQ, PostgreSQL, and all of the cookbooks that are used by chef-solo to maintain Chef Server 11.x.
# chef-server-ctl reconfigure
Chef-server installation can be verified by using “chef-server-ctl test” command. This will run the chef-pedant test suite against the installed Chef Server 11.x and will report back that everything is working and installed correctly.
To have a look at chef processes, check process list using command “ps -ef”.
Step 6: Move chef-validator.pem and chef-webui.pem keys to .chef directory
# mkdir –p ~/.chef
# cp /etc/chef-server/chef-validator.pem .chef/
# cp /etc/chef-server/chef-webui.pem .chef/
# chown –R $USER .chef/
Step 7: Install knife gem
To install knife, we need to add a repository for installing ruby and ruby gems.
Now, we have our Chef Server up and running. We can also have a look at our chef server by navigating web-console url and providing admin or newly created user credentials. The default admin credentials are mentioned on login page.
URL : https://<Elastic-IP> or https://<EC2-Public-DNS>
Next Step: Start Cooking: Create chef cookbooks and recipes
Recovering Files from Windows Encryption File System
Disclaimer: Please use at your own risk!! I’m blogging about this because it worked for me. If it helps for you, please let me know. If not, sorry about that :)
In my last blog post, I discussed about recovering Windows 2008 R2 admin password. After completing password recovery, I got hit by another issue i.e., few folders in our C drive were in Green colour. Initially, I didn’t focus on that [Frankly speaking, I was very relieved and happy after recovering admin password] and started working on instance. As, I tried to access one of the files from that Green coloured folder, ACCESS DENIED. And I was like Oh..damn..what happened to these files? So again Google provided much needed explanation i.e., Folders in GREEN colour means they are encrypted i.e., the files are encrypted using Encrypting File System (EFS). I had no clue how I landed up into this situation. Immediate search results suggested that in-order to decrypt those files, right click on the folders/files – Go to properties – Click on Advanced in attributes section – Uncheck Encrypt Contents to secure data. Simple solution? Even, I thought so but something else was written in my destiny [may be yours too, if you end up having this issue]. After un-checking encrypt contents to secure data and applying it, another pop-up message came up which says ACCESS DENIED. I was wondering I’m logged in as Administrator how come access denied for me.
Well, I started searching more about this issue and most of the links suggested me to check user permissions – ownership – user control account settings – registry settings etc etc. Everything was good regarding user permissions or ownership. None of the solution worked for me. As more and more time was passing, I was moving towards EFS recovery tools.
Finally, I came across a link which says files are encrypted by a user key which is tied to your password and if you change your password – a new key is generated. The new key may not work with those encrypted files. In-order to decrypt those files, we need to have same key. One of the solutions [which worked for me] was to change my password back to old one and decrypt files. Phew..sign of relief when I saw files getting decrypted.
Bottom Line: If your files are encrypted using EFS and you have changed your Administrator password and hit by Access Denied error – try changing your password back to original one and it might decrypt your files.
