The way I solved this was by checking the ansible_bios_version
fact. For example:
- debug:
msg: "This is an EC2 instance"
when: "'amazon' in ansible_bios_version"
This is probably not perfect, but at least it worked for me at the moment.
Note that the day after I needed this, Jeff Geerling posted an alternative way to check if you are in AWS.
]]>Let’s first start with what happened. My goal was to add user “mark”
to the /etc/sudoers
file so I could restart the web server (running
on port 80) from that account. It was going to be the last thing I
would do for that day.
I logged in as user “ubuntu” on the machine, used sudo
to become root and
edited the /etc/sudoers
file with visudo
. I logged out again, and logged in
as user mark and tried to sudo something. That didn’t work: “mark is not in the sudoers file.
” My first thought was that I must have made a typo while editing
the /etc/sudoers
file. So all I needed to do was to log in as user ubuntu,
become root again and fix the file. Just five more minutes and then off to bed.
When I had typed “sudo su
” as user ubuntu and was prompted for the password,
I started to sweat. “What do you mean, password?” First of all it had never been
necessary to give my password to sudo anything and secondly I never had to set
the password for the user ubuntu. To make matters even worse: I also didn’t
have to set a password for the root account either, so a simple “su
” command
would also not help me. Sure, the server was still running normally. But since I
would not be able to administer the machine, it was going to be a problem sooner
or later. Especially since there are a couple of production sites running on the
server, including a webshop.
After some searching and pondering I decided to take advantage of the fact that it is an Amazon Elastic Compute Cloud (EC2) instance with an Elastic Block Store (EBS) volume. These are the steps I took to access the box as root again:
/dev/sdb1
.sudoers
file./dev/sda1
.For most of the juggling with the storages I could use the
Elasticfox add-on
for Firefox. I only needed to use the
API command line tools
to create the instance and attach the storage back to the old
instance. All in all the instance was down for less than 15
minutes. And that includes the stress of not being able to attach the
storage back to the instance with Elasticfox, wondering whether it was
even possible to attach an EBS volume to a stopped instance, and
having to figure out how to do it with the command line (hint: use
ec2-attach-volume
and don’t forget to add the --region
parameter
if you are in the EU region).
You might be curious about the mistake I made to lock myself
out. Let’s first show you the last couple of lines of the /etc/sudoers
file before I touched it:
# ubuntu user is default user in ec2-images.
# It needs passwordless sudo functionality.
ubuntu ALL=(ALL) NOPASSWD:ALL
Now the version I had created:
# ubuntu user is default user in ec2-images.
# It needs passwordless sudo functionality.
ubuntu ALL=(ALL) NOPASSWD:ALL
ubuntu ALL=(ALL) ALL
Yes, I copied and pasted the last line and was so focussed on removing
the NOPASSWD
part, that I forgot to change the user name.
Besides gaining more insight in EC2, I also learned a couple of lessons the hard way: