Vagrant - Resolving shared disk mounting issues

Prerequisites:
           Host:    Windows 7
           Guest:   Centos 7   ( + VirtualBoxGuestAdditions is installed)

Install VirtualBoxGuestAdditions:
@HostVirtualBox:
                Devices --> Insert Guest Additions CD image
            ## mounts C:\Program Files\Oracle\VirtualBox\VBoxGuestAdditions.iso
@GuestOS using SSH:
            $ mount /dev/cdrom /media; cd /media
            $ ./VBoxLinuxAdditions.run

==============================================================
Setup:


C:\> cd Program Files\Oracle\VirtualBox

Mount shared directory on guest:

C:\Program Files\Oracle\VirtualBox>VBoxManage sharedfolder add "devbox" --name "vbox-devbox" --hostpath "D:\tasks\vbox-devbox"

Start your guest headless:
C:\Program Files\Oracle\VirtualBox>VBoxManage startvm "devbox" --type headless


---------------------------------------------------------------------------------------------------------------
                                                 Errors
---------------------------------------------------------------------------------------------------------------

1. """"Error!!!""/sbin/mount.vboxsf: mounting failed with the error: No such device"""""

Solution: Run below commands on guest:

[root@localhost ~]# /etc/init.d/vboxadd setup
Removing existing VirtualBox non-DKMS kernel modules       [  OK  ]
Building the VirtualBox Guest Additions kernel modules
Building the main Guest Additions module                   [  OK  ]
Building the shared folder support module                  [  OK  ]
Building the OpenGL support module                         [  OK  ]
Doing non-kernel setup of the Guest Additions              [  OK  ]
Starting the VirtualBox Guest Additions                    [  OK  ]
[root@localhost ~]#
[root@localhost ~]# modprobe vboxsf
[root@localhost ~]#
[root@localhost ~]# vi /etc/modules-load.d/vboxsf.conf
vboxsf
[root@localhost ~]# vi /etc/fstab
vbox-devbox        /mnt          vboxsf  uid=root,gid=root,rw,dmode=700,fmode=600 0 0
[root@localhost ~]# mount -a

Vagrant Setup with Chef Solo

Architecture:
a)   Host Machine: Windows7
      Guest Machine: CentOS 7.0
b) Directory hierarchy on Host machine:

D:.
├───mount
├───vagrant
│   ├───.vagrant
│   │   └───machines
│   │       └───default
│   │           └───virtualbox
│   └───cookbooks
│       └───test
│           ├───attributes
│           ├───definitions
│           ├───files
│           │   └───default
│           ├───recipes
│           ├───spec
│           ├───templates
│ └───default
├───vbox
└───vfiles
    └───ssh

Prerequisite: 
A. create a vm "devbox" and install all the base softwares post OS install:
1. create user vagrant and key, add to wheel group for sudo access.
2. check in wheel group has "NOPASSWD" in sudoer file.
3. copy vagrant private key to your local and remove from VM
4. copy public key to "authorized_key" and "chmod 600 authorized_keys".
3.  $ cd D:\tasks\vagrant\vagrant
       $ vagrant plugin install vagrant-vbguest
# Above command is just to avoid - "Failed to mount folders in Linux guest. This is usually because the "vboxsf" file system is not available. Please verify that the guest additions are properly installed in the guest and can work properly. The command attempted was:       mount -t vboxsf -o uid=`id -u vagrant`,gid=`getent group vagrant | cut -d: -f3` vagrant /vagrant"
4. Then package the running VM to ".vbox":
$ vagrant package --base devbox

Working: 
A) Create a new file "Vagrantfile" under "D:\tasks\vagrant\vagrant":
    $ cd D:\tasks\vagrant\vagrant
$ vi Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
  config.vm.box = "vbase64"
  config.vm.box_url = "file:///D:/tasks/vagrant/vbox/centos7_64.box"
  config.vm.network "private_network", ip: "172.16.16.16"
  config.vm.provider "virtualbox" do |vb|
vb.name = "vbase64"
vb.memory = "512"
  end

  # Enable provisioning with a shell script and chef solo
  config.vm.provision "shell", inline: <<-SHELL
     touch /tmp/justtotest
  SHELL
  config.vm.provision "chef_solo" do |chef|
chef.cookbooks_path = "cookbooks"
    chef.add_recipe "test"
  end

  # config.ssh.port = "22"
  config.ssh.username = "vagrant"
  config.ssh.private_key_path = "D:\\tasks\\vagrant\\vfiles\\ssh\\vagrant.key"
  config.vm.synced_folder "../mount", "/vagrant", disabled: false
  config.ssh.pty= true
end

B) Now do a vagrant up, this kicks off vagrant guest machine:
$ vagrant up

C) SSH to vagrant gues machine:
$ vagrant ssh   or
$ ssh 172.16.16.16

D) Run Chef Solo manually on guest(on centos):
$ sudo chef-solo -c /tmp/vagrant-chef/solo.rb -j /tmp/recipe.json
$  cat /tmp/recipe.json

{ "run_list": [  "recipe[base]",  "recipe[foo]",  "recipe[bar]",  "role[webserver]" ] }

E) Destroy VM:
$ vagrant destroy
F)  made some changes to vagrant file? just provision the VM  again, no need to "vagrant reload":
$ vagrant provision
Note: 
- nat interface would listen on 2222 and hostonly would listen on 22
- mentioned private key should be openssh compatible.

------------------------------------------------------

Troubleshooting:

# Before re-packaging some VM, make sure you removed the already provisioned box:
$ vagrant box list
$ vagrant box remove vbase64

# sudo: sorry, you must have a tty to run sudo
config.ssh.pty= true

# dont want to mount(in vagrantfile)
config.vm.synced_folder ".", "/vagrant", disabled: true

# vagrant destroy failed and causing issues with next up (VERR_ALREADY_EXISTS)
$ vagrant destroy -f

# check the ssh bit used:
vagrant ssh-config
# Make the instance name static:

 config.vm.provider "virtualbox" do |vb|
vb.name = "vbase64"
vb.memory = "512"
 end

---------------------------------------------------------------------

##############################################################################

Junk:
=> "vagrant up" output:

D:\tasks\vagrant\vagrant>vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'vbase64'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: vbase64
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
==> default: Machine booted and ready!
No installation found.
Loaded plugins: fastestmirror, langpacks
base                                                     | 3.6 kB     00:00
extras                                                   | 3.4 kB     00:00
updates                                                  | 3.4 kB     00:00
updates/7/x86_64/primary_db    FAILED
updates/7/x86_64/primary_d 0% [                 ]  0.0 B/s |    0 B   --:-- ETA
http://mirror.digistar.vn/centos/7.0.1406/updates/x86_64/repodata/df859f8e88574d
f31f3d30c0847fb9156492a8c63af3f61fc21f9ae0798f8421-primary.sqlite.bz2: [Errno 12
] Timeout on http://mirror.digistar.vn/centos/7.0.1406/updates/x86_64/repodata/d
f859f8e88574df31f3d30c0847fb9156492a8c63af3f61fc21f9ae0798f8421-primary.sqlite.b
z2: (28, 'Operation too slow. Less than 1000 bytes/sec transferred the last 30 s
econds')
Trying other mirror.
updates/7/x86_64/primary_d 0% [                 ]  0.0 B/s |    0 B   --:-- ETA
updates/7/x86_64/primary_d 2% [                 ]  0.0 B/s | 178 kB   --:-- ETA
updates/7/x86_64/primary_d 11% [=-              ] 880 kB/s | 741 kB   00:06 ETA
updates/7/x86_64/primary_d 22% [===-            ] 958 kB/s | 1.4 MB   00:04 ETA
updates/7/x86_64/primary_d 33% [=====           ] 1.0 MB/s | 2.0 MB   00:04 ETA
updates/7/x86_64/primary_d 43% [=======         ] 1.1 MB/s | 2.6 MB   00:03 ETA
updates/7/x86_64/primary_d 54% [========-       ] 1.1 MB/s | 3.3 MB   00:02 ETA
updates/7/x86_64/primary_d 64% [==========      ] 1.2 MB/s | 3.9 MB   00:01 ETA
updates/7/x86_64/primary_d 74% [===========-    ] 1.2 MB/s | 4.5 MB   00:01 ETA
updates/7/x86_64/primary_d 82% [=============   ] 1.3 MB/s | 5.0 MB   00:00 ETA
updates/7/x86_64/primary_d 92% [==============- ] 1.3 MB/s | 5.6 MB   00:00 ETA
updates/7/x86_64/primary_db                                | 6.0 MB   00:08
Determining fastest mirrors
 * base: mirror.nbrc.ac.in
 * extras: mirror.digistar.vn
 * updates: mirrors.viethosting.vn
Package kernel-devel-3.10.0-123.el7.x86_64 already installed and latest version
Package gcc-4.8.2-16.2.el7_0.x86_64 already installed and latest version
Package 1:make-3.82-21.el7.x86_64 already installed and latest version
Package 4:perl-5.16.3-283.el7.x86_64 already installed and latest version
Nothing to do
Copy iso file C:\Program Files\Oracle\VirtualBox\VBoxGuestAdditions.iso into the
 box /tmp/VBoxGuestAdditions.iso
mount: /dev/loop0 is write-protected, mounting read-only
Installing Virtualbox Guest Additions 4.3.20 - guest version is
Verifying archive integrity... All good.
Uncompressing VirtualBox 4.3.20 Guest Additions for Linux............
VirtualBox Guest Additions installer
Removing installed version 4.3.20 of VirtualBox Guest Additions...
Copying additional installer modules ...
Installing additional modules ...
Removing existing VirtualBox non-DKMS kernel modules       [  OK  ]
Building the VirtualBox Guest Additions kernel modules
Building the main Guest Additions module                   [  OK  ]
Building the shared folder support module                  [  OK  ]
Building the OpenGL support module                         [  OK  ]
Doing non-kernel setup of the Guest Additions              [  OK  ]
Starting the VirtualBox Guest Additions                    [  OK  ]
Installing the Window System drivers
Could not find the X.Org or XFree86 Window System, skipping.
An error occurred during installation of VirtualBox Guest Additions 4.3.20. Some
 functionality may not work as intended.
In most cases it is OK that the "Window System drivers" installation failed.
==> default: Checking for guest additions in VM...
==> default: Mounting shared folders...
    default: /vagrant => D:/tasks/vagrant/vagrant/vfiles
    default: /tmp/vagrant-chef/952de30bae9c91c5205bd436b3b8899d/cookbooks => D:/
tasks/vagrant/vagrant/cookbooks
==> default: Running provisioner: chef_solo...
    default: Installing Chef (latest)...
Generating chef JSON and uploading...
==> default: Running chef-solo...
==> default: [2015-01-22T20:13:17+05:30] INFO: Forking chef instance to converge
...
==> default: Starting Chef Client, version 12.0.3
==> default: [2015-01-22T20:13:17+05:30] INFO: *** Chef 12.0.3 ***
==> default: [2015-01-22T20:13:17+05:30] INFO: Chef-client pid: 10152
==> default: [2015-01-22T20:13:23+05:30] INFO: Setting the run_list to ["recipe[
test]"] from CLI options
==> default: [2015-01-22T20:13:23+05:30] INFO: Run List is [recipe[test]]
==> default: [2015-01-22T20:13:23+05:30] INFO: Run List expands to [test]
==> default: [2015-01-22T20:13:23+05:30] INFO: Starting Chef Run for localhost
==> default: [2015-01-22T20:13:23+05:30] INFO: Running start handlers
==> default: [2015-01-22T20:13:23+05:30] INFO: Start handlers complete.
==> default: Compiling Cookbooks...
==> default: Converging 1 resources
==> default: Recipe: test::default
==> default:   * directory[/tmp/just/shutup] action create[2015-01-22T20:13:23+0
5:30] INFO: directory[/tmp/just/shutup] created directory /tmp/just/shutup
==> default:
==> default:     - create new directory /tmp/just/shutup
==> default: [2015-01-22T20:13:23+05:30] INFO: Chef Run complete in 0.05791181 s
econds
==> default: [2015-01-22T20:13:23+05:30] INFO: Skipping removal of unused files
from the cache
==> default:
==> default: Running handlers:
==> default: [2015-01-22T20:13:23+05:30] INFO: Running report handlers
==> default: Running handlers complete
==> default: [2015-01-22T20:13:23+05:30] INFO: Report handlers complete
==> default: Chef Client finished, 1/1 resources updated in 6.168898464 seconds
D:\tasks\vagrant\vagrant>vagrant ssh
Last login: Thu Jan 22 20:13:16 2015 from 10.0.2.2
[vagrant@localhost ~]$ logout
Connection to 127.0.0.1 closed.
D:\tasks\vagrant\vagrant>

----------------------------------------------------- END ---------------------------------------------------------------

AWS Facts: EC2 instance

------------------------------------ aws cli bits ----------------------------------------

##### two columns with listing ID and their names
 aws ec2 describe-instances --output text --filters "Name=instance-state-name,Values=running" --query 'Reservations[*].Instances[*].[InstanceId,Tags[?Key==`Name`].Value[]]' | sed '$!N;s/\n/         /'

 #### getting three columns (just for testing)
 aws ec2 describe-instances --output text --filters "Name=instance-state-name,Values=running" --query 'Reservations[*].Instances[*].[InstanceId,Tags[?Key==`Name`].Value[]]' | sed '$!N;s/\n/     /; $!N;s/\n/      /'


 #### $!N means read in the next line only if it is not the last line in the file. If it would try to read in the line after the last line some versions of sed simply quit without doing anything. That's why you should use $!.
 #### http://askubuntu.com/questions/461191/what-is-the-meaning-of-an-in-a-sed-command

AWS Facts: SES

• If you are granted production access, you no longer have to verify "To" addresses or domains; however, you must still verify any additional "From" or "Return-Path" addresses or domains. 

• sandbox: You can send a maximum of 200 messages per 24-hour period.

AWS Facts: Route53

A) ALIAS records:

• An ALIAS record will link your record set to a particular AWS resource directly (i.e. you can map a domain to an S3 bucket, ELB, CloudFront distribution) 
• You can create an alias resource record set at the zone apex. For example, if you register the DNS name example.com, the zone apex is example.com.
• if you try to set CNAME or A record of some apex zone(e.g. example.com), it will give you error. So the only option is just to make an alias entry. 
• Amazon Route 53 doesn't charge for alias queries, however charges for CNAME queries. 

------------------------------------ aws cli bits ----------------------------------------

### List all the hosted zones

$ for i in `aws route53 list-hosted-zones --output=text --profile myprofile --query 'HostedZones[*].Name'`; do echo "$i"; done

### List all the records against Z2A22EOFF20PZ7 hostedzone.

    $ aws route53 list-resource-record-sets --hosted-zone-id "/hostedzone/Z2A22EOFF20PZ7" --profile myprofile

AutoScaling: how to deploy code using autoscaling

Environment:
    Autoscaling limit: 3

• Release your code by taking the reference of some AMI.
• Post deployment, cut an AMI and create new Launch Configuration(e.g. product-141117).
• Take a snapshot of already running Instance.
• Change the launch configuration of particular Autoscaling Group by updating the AMI id.
• Now 'scale up' instance limit in "AutoScaling Group" from 3 to 6.
• De-select the old instances(3) from ELB.
• Test website.
• Scale down autoscaling group from 6 to 3.
• remove old launch configuration.

Note: Here point 8) is tricky one, how does Autoscaling know which EC2 instance to terminate?
   - Actually AutoScaling is built in such a way that when one scales it down, the system terminates the EC2 instance by "oldest-first" rule. That means the old EC2 instances get terminated.

AWS Facts - VPC(Virtual Private Cloud)

Amazon Virtual Private Cloud:-VPC

A virtual private cloud (VPC) is a virtual network that closely resembles a traditional network that you'd operate in your own data center, with the benefits of using the scalable infrastructure of Amazon Web Services (AWS).

Ø  Some of the key things in vpc:-

1. Subnet groups are different for different VPCs.

2. VPC is comprised of Subnets:

          1) Public Subnets

                 - Accessible from public

                 - Usually ELB, Bastion Hosts, NAT, VPN systems are launched under this subnet.

                 - Hosts can access internet by merely attaching EIP or public IP           

             

         2) Private Subnets

                 - Inaccessible from Public.

                 - Accessible from VPN, BastionHost, ELB

                 - Hosts can get access to internet only if configured through NAT instance.

3. Create new Internet Gateway for Public subnets (igw-xxxx)

4. You can categorize public and private subnets by creating two routing tables:

Target	Name	Description	Destination
igw-xxx	Route1	Public Subnet1	0.0.0.0/0
i-xxxxx	Route2	Private	0.0.0.0/0

5. Hosts on different subnets can access each other with Security Group allow rules.                              

6. Spin up NAT instance on public subnet against community provided AMIs (i-xxxxx).

            - Disable Source/Destination checks

            - Open ports from security group (Inbound- 80, 443 Outbound- All)

7. Type of firewalls:

• Security groups—Act as a firewall for associated Amazon EC2 instances, controlling both               inbound and outbound traffic at the instance level

           -        Termed as “first layer of defense”

           -        Supports allow rules only

           -        Associates to particular instance during or after launching.

   • Network access control lists (ACLs)—Act as a firewall for associated subnets, controlling both inbound and outbound traffic at the subnet level. It get applied VPC level

            -        Termed as “second layer of defense”

            -        Supports allow rules and deny rules

           -        Automatically applies to all instances in the subnets it's associated with (backup layer of defines, so you don't have to rely on someone specifying the security group)

    Note: To make blocking single layer, you can allow all ports in SG and then can manage the access from Network ACL resulting port management centralization

         

8. Subnet communication: Suppose we have VPC name "V1" and have two subnets down under as "S1" & "S2". Under S1 and S2, we have EC2 instances as I1 and I2 respectively:

o    I1 cannot access I2 ports unless the port is explicitly opened in SG and Network ACL.

         

9. Elastic IP v/s Public IP

o    EIP remains static during its lifetime, however public IP changes after every Shutdown-start(sometime remains same during restart).

o    EIP is chargeable, Public IP is free.

                                     

                                       

Practices:-

a)   Get your Amazon VPC combination right:  

·         You need to decide the right Amazon VPC & VPN setup combination based on your current and future requirements. It is tough to modify/re-design the Amazon VPC at later stage, so it is better to design it taking into consideration your NW and expansion needs for next ~2 years.

b)   Choose your CIDR Blocks:

·         While designing your Amazon VPC, the CIDR block should be chosen in consideration with the number of IP addresses needed and whether we are going to establish connectivity with our data centre.    

                     

·         Also when you design the Amazon VPC architecture to communicate with the on premise/data center ensure your CIDR range used in Amazon VPC does not overlaps or conflicts with the CIDR blocks in your On premise/Data center.

·         E.g., Your VPC CIDR block is 10.0.0.0/16 and if you have 10.0.25.0/24 subnet in a data center the communication from instances in VPC to data center will not happen since the subnet is the part of the VPC CIDR. In order to avoid these consequences it is good to have the IP ranges in different class. Example., Amazon VPC is in 10.0.0.0/16 and data center is in 172.16.0.0/24 series.

                  

c)   Securing Amazon VPC :

·         You can configure Intrusion Prevention or Intrusion Detection virtual appliances and secure the protocols and take preventive/corrective actions in your VPC

·         Configure VM encryption tools which encrypt your root and additional EBS volumes. The Key can be stored inside AWS (or) in your Data center outside Amazon Web Services depending on your compliance needs.

 http://harish11g.blogspot.in/2013/04/understanding-Amazon-Elastic-Block-Store-Securing-EBS-TrendMicro-SecureCloud.html

·         Configure Privileged Identity access management solutions on your Amazon VPC to monitor and audit the access of Administrators of your VPC.

·         Enable the cloud trail to audit in the VPC environments  ACL policy's. Enable cloud trail : http://harish11g.blogspot.in/2014/01/Integrating-AWS-CloudTrail-with-Splunk-for-managed-services-monitoring-audit-compliance.html

·         Apply anti virus for cleansing specific EC2 instances inside VPC. Trend micro has very good product for this.

·         Configure Site to Site VPN for securely transferring information between Amazon VPC in different regions or between Amazon VPC to your On premise Data center.

                            

·         Follow the Security Groups and NW ACL's best practices listed below

d)   Spread your NAT instance with Multiple Subnets:

·         What if you have hundreds of EC2 instances inside your Amazon VPC and they are making lots of heavy web service/HTTP calls concurrently. A single NAT instance with even largest EC2 size cannot handle that bandwidth sometimes and may become performance bottleneck. In Such scenarios, span your EC2 across multiple subnets and create NAT's for each subnet. This way you can spread your out going bandwidth and improve the performance in your VPC based deployments.

e) Plan your Tunnel between On-Premise DC to Amazon VPC:

Option 1: Secure IPSec tunnel to connect a corporate network with Amazon  VPC (http://aws.amazon.com/articles/8800869755706543)

Option 2 : Secure communication between sites using the AWS VPN CloudHub (http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPN_CloudHub.html)

          

Option 3: Use Direct connect between Amazon VPC and on premise when you have lots of data to be transferred with reduced latency (or) you have spread your mission critical workloads across cloud and on premise. Example: Oracle RAC in your DC and Web/App tier in your Amazon VPC. Contact us if you need help on setting up direct connect between Amazon VPC and DC.