AWS allowing access to Billing to IAM user

Problem

When you create a new AWS account the access to Billing for IAM users is not enabled by default.

Solution

In order to allow access you have to follow the steps below:

  • Login to your AWS account with your root user (email and password)
  • Go to the top right drop down ‘My Account’
  • Find the section that is called ‘IAM User and Role Access to Billing information’, use ‘Edit’, tick the box ‘Enable access’ and then ‘Update’.

More information can be found in the Amazon’s help page https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/control-access-billing.html#ControllingAccessWebsite-Activate

Get a list of your Route53 subdomains using aws cli docker image

Problem

You would like to have a list of your subdomains for a specific domain (hosted zone), that are hosted in Amazon’s Route 53.

Solution

You can install the aws cli docker image from here https://github.com/cgswong/docker-aws if you don’t want to install the aws cli in your computer.

You can afterwards start the container with:

docker run -it cgswong/aws:latest

Then configure it by running the following and adding your credentials and zone:

efe9881d4fd:/tmp# aws configure
 AWS Access Key ID [None]: aws_access_key_id
 AWS Secret Access Key [None]: aws_secret_access_key
 Default region name [None]: eu-central-1
 Default output format [None]:

Then run the first command to get a list of the hosted zones and get the id of the hosted zone you want to find the subdomains for:

3efe9881d4fd:/tmp# aws route53 list-hosted-zones
{
    "HostedZones": [
        {
            "ResourceRecordSetCount": 2, 
            "CallerReference": "RISWorkflow-RD:xxxxx", 
            "Config": {
                "Comment": "HostedZone created by Route53 Registrar", 
                "PrivateZone": false
            }, 
            "Id": "/hostedzone/HOSTEDZONEID", 
            "Name": "domain.net."
        }, 

Then pick the HOSTEDZONEID and run the following to get a list of subdomains for that domain:

3efe9881d4fd:/tmp# aws route53 list-resource-record-sets --hosted-zone="HOSTEDZONEID" | grep "Name" | uniq

   "Name": "alpah.domain.com.",                                                                                                                                                                                                                                             
   "Name": "beta.domain.com.",                                                                                                                                                                                                                                       
   "Name": "lamda.domain.com.",
......

Error in AWS when trying to include puppet modules (Error: Could not find class apache2 for …)

Problem

You are trying to work with puppet modules in AWS, after installing puppet as a gem, but when you try to put the modules and manifests outside the main manifests/site.pp file you get an error similar to following:

Solution

Create a file for the puppet configuration in /etc/puppet/puppet.conf and add the paths to your own manifests and modules, like :

and add your paths:

.rvm/bin/rvm-shell: No such file or directory error

Problem

When trying to set up the capistrano deploy recipe to deploy to the vagrant virtual box as described in ‘Deploying rails’, you get the error:

when you have installed rvm system wide on the virtual box.

Solution

Make sure that you add the following into your deploy.rb file to set up the path for rvm:

Solution taken from here

sudo: puppet: command not found – when trying to use puppet with rvm in aws

When trying to use the

command in a aws instance to follow the instruction from ‘Deploying Rails’, the following error complains that the puppet command is not found, like:

After some searching and having a look at the blog post here and using the rvm notes in the aws instance and looking at this:

It seems that for security reason the sudo command resets the path in the system.

You can actually see that this the case by running the command to display the path of the normal user:

and the corresponding one for the sudo:

So a workaround to make it work is to add your group into the exemptions group in the visudo file, which means editing the visudo file:

and adding the group that your user you are working with belongs to: