OPS345 Lab 3

THIS PAGE IS A DRAFT, NOT A REAL COURSE PAGE

The current schedule for OPS345 is here: OPS335_Weekly_Schedule

In the last lab we created the ww instance:

• With a static private IP (10.3.45.11)
• We set up port forwarding for the SSH protocol so that incoming TCP packets to port 2211 on router are forwarded to TCP port 22 on ww.

Before you get started with the storage configuration, install httpd using yum on ww. You don't need to start the service at this point. Just install it.

Storage for the web server

In this lab we'll configure ww to function as a web server. The most important piece of learning in this lab is managing one type of storage available on AWS: Elastic Block Storage (EBS).

An EBS volume looks like any other block storage device (e.g. a harddrive partition) to an operating system in an AWS instance. But of course it's not a partition or a harddrive or an LVM logical volume, its actual implementation details are internal to AWS and of no concern to us, the users. The concept should be familiar to you because it's so similar to how in OPS245 you've created a virtual harddrive in VMware and attached it to an existing VM.

Create and attach EBS device

• First go to Volumes under Elastic Block Store. Notice that some volumes are already there. These are the virtual harddrives which your existing VMs have been installed on, where they store all the operating system files, the contents of the home directories, and anything else "on the harddrive".
• Click "Create volume".

• Don't neglect to click the "Info" link on each option. Remember that even though it may sound incomprehensible at first: you will pick up some knowledge every time you read this stuff, and eventually this will become easier to understand.
• Set the size to 1GB. This is the minimum allowed and is more than enough for what you need.
• Set its Name to www-data.
• Now you need to attach it to the ww VM.

The name of the device doesn't really matter. Mine turned out to be /dev/sdf.

Note that you don't need to shut down your VM nor even reboot it. The action you performed is the equivalent of plugging in a hot-pluggable storage device into a Linux desktop or laptop.

• In your ww terminal check that the new device showed up and is the correct size:

At this point you have a new block storage device of 1GB plugged into your box, but it is not currenty being used. Hopefully you paid attention in the OPS245 LVM labs because this is the same stuff, just in the cloud instead of a local hypervisor.

Use your new EBS device as a LV

It should not be difficult to imagine that your web server might run out of storage space if it only has 1GB available. How much work would it be to recreate the entire machine, reconfigure it, move all the files over, and do that without too much downtime?

In order to avoid all those problems you use LVM. The storage for your web server will be on a Logical Volume, on a separate EBS device than the operating system. If you run out of space: all you have to do is add another EBS device, and extend the logical volume to use the space on that new device as well. Exactly like you did in OPS245.

• Create a volume group vg_www, and add /dev/xvdf to it as a physical volume.
• Then create a logical volume lv_www and allocate all the space from /dev/xvdf to lv_www.
• Double-check with blkid and ls that your new logical volume has been created.
• Format that logical volume as ext4.

Mount your new LV on /var/www

• Mount your new filesystem on /var/www. You should not get any errors or surprises:

• That looks good in the screenshot. We don't need any of the contents that were originally in /var/www, so we'll set up the /dev/mapper/vg_www-lv_www device to mount automatically onto the /var/www directory every time the machine boots up. Add this to the end of /etc/fstab:

/dev/mapper/vg_www-lv_www /var/www ext4 defaults 0 0

• And test to make sure that it worked:

Don't reboot the machine if the following testing fails. You might end up with an unbootable VM, and you'll have to restart from the end of the previous lab.

• Once you're comfortable that your fstab isn't broken and your logical volume mounts properly: reboot ww and confirm that everything still works.

• mkdir /var/www/html
• vi /var/www/html/index.php

  Hello. My web server still works.<br />
  If this shows the current date and time, PHP works too:<br />
  <?php system("date"); ?>

• chown -R andrew /var/www/html
• systemctl start httpd
• On router: iptables -t nat -I PREROUTING -p tcp --dport 80 -j DNAT --to 10.3.45.11:80
• On www: iptables -I INPUT 3 -p tcp --dport 80 -j ACCEPT
• service iptables save
• Edit security group, allow HTTP
• ss -atnp on router and www
• install php, restart httpd
• make proper html page:

  <html>
  <head>
  <style>
  body  {background-color: powderblue;}
  table {border-spacing: 1cm 0cm;}
  h2    {color: blue;}
  th    {text-align: left;}
  p     {color: red; font-weight: bold;}
  </style>
  </head>
  <body>
  Hello. My web server still works.<br />
  If this shows the current date and time, PHP works too:<br /><br />
  <?php system("date"); ?>
  <h2>Instance Info</h2>
  <table>
  <tr><th>Configuration</th><th>Value</th></tr>
  <tr>
    <td><p>Private IP</p></td>
    <td><?php system("curl http://169.254.169.254/latest/meta-data/local-ipv4"); ?></td>
  </tr>
  <tr>
    <td><p>Public IP</p></td>
    <td><?php system("curl http://169.254.169.254/latest/meta-data/public-ipv4"); ?></td>
  </tr>
  </table>
  </body>
  </html>

• Removing public ip doesn't work. Have to modify subnet and recreate the vm:
  • Terminate www, rename it to www-deleted.
  • Modify subnet to not auto-assign public IPs.
  • Recreate the www instance with the same steps, except specify a primary ip.
  • Install httpd, php
  • To get yum install to work, allocate a new elastic ip "temporary" and associate with www
  • Note that www-data was not deleted when the original www was terminated. Attach it to www now.
  • All the data on the logical volume is still there, but fstab is gone, add lv-www back into there.
  • Start httpd, everything should be back to as it was.
  • Disasociate the public ip. Everything should keep working.
  • Release the elastic ip.
• Add a 404 check for missing ip:

<?php 
system("curl http://169.254.169.254/latest/meta-data/public-ipv4 2>&1| grep -q '404 - Not Found'", $rc);      
if ($rc == 0) 
  echo "None found";
else
  system("curl http://169.254.169.254/latest/meta-data/public-ipv4");
?>

• If you feel curious you can see what other metadata you can get via http://169.254.169.254 here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html
• Move www to ops345sgprivate, and add port 80 from ops345sg as a second inbound rule there.