1
votes

I am creating a launch configuration for a an auto scaling group.

WebAppLaunchConfig:
    Type: AWS::AutoScaling::LaunchConfiguration
    Properties:
      UserData: !Base64 |
        #!/bin/bash
        exec > >(tee /var/log/user-data.log|logger -t user-data -s 2>/dev/console) 2>&1
        sudo su
        apt-get update -y
        apt-get install unzip awscli -y
        apt-get install apache2 -y
        systemctl start apache2.service
        cd /var/www/html
        aws s3 cp s3://udacity-demo-1/udacity.zip .
        unzip -o udacity.zip
        /bin/echo "Hello World" >> /tmp/testfile.txt
      IamInstanceProfile:
        Ref: "ProfileWithRolesForOurApp"
      KeyName: UdacityCFNEC2Key
      ImageId: ami-005bdb005fb00e791
      SecurityGroups:
      - Ref: WebServerSecGroup
      InstanceType: t3.medium
      BlockDeviceMappings:
      - DeviceName: "/dev/sdk"
        Ebs:
          VolumeSize: '10'

I put the server in a public subnet to simply ssh in and confirm if Apache started and I can see it is not. When I try to run the start command I get an error that httpd.conf file does not exist.

What am I doing wrong here?

The closest question I found is: Using userdata in Cloudformation where they are discussing the type of ami and I have been able to export the userdata logs to the console successfully and I am using and ubuntu ami so I think this is not a similar problem.

3

3 Answers

0
votes

I believe is missing this command on your script

-> systemctl enable httpd

Here an example from AWS documentation:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html

0
votes

I found that the best way to determine the issue was to launch a new host with the same configuration with a public facing ip and security group which allows for ssh. Then ssh into the machine and run each command one by one to confirm which one was causing a failure.

In the end I simply I found that by choosing a different suggested AMI from the list of launch instances for my region, I was able to successfully get the user data script to complete successfully.

0
votes

I had the same issue, but instead of having a custom bash script to "update/fix" the issue, I tried with a recently built image.

My CloudFormation template is not being used on any production environment, so I switched the Amazon Machine Image (AMI) to one that was recently added, I hypothesized that a newer AMI could bring the latest patches so I don't have to apply any of the rm ... or kill ... commands suggested everywhere.

This is the AMI I'm using:

# Canonical, Ubuntu, 18.04 LTS, amd64 bionic image build on 2020-04-08
...
ImageId: ami-003634241a8fcdec0
...

I destroyed my CloudFormation stack, re-created it, and bingo. It works like a charm!