• Skip to main content
  • Skip to primary sidebar

Easy Cloud 2

Reinventing Cloud Computing

How to undo (almost) anything with Git

March 9, 2019 By ec2tec5_wp Leave a Comment

One of the most useful features of any version control system is the ability to “undo” your mistakes. In Git, “undo” can mean many slightly different things.

When you make a new commit, Git stores a snapshot of your repository at that specific moment in time; later, you can use Git to go back to an earlier version of your project.

In this post, I’m going to take a look at some common scenarios where you might want to “undo” a change you’ve made and the best way to do it using Git.

Undo a “public” change

Scenario: You just ran git push, sending your changes to GitHub, now you realize there’s a problem with one of those commits. You’d like to undo that commit.

Undo with: git revert <SHA>

What’s happening: git revert will create a new commit that’s the opposite (or inverse) of the given SHA. If the old commit is “matter”, the new commit is “anti-matter”—anything removed in the old commit will be added in the new commit and anything added in the old commit will be removed in the new commit.

This is Git’s safest, most basic “undo” scenario, because it doesn’t alter history—so you can now git push the new “inverse” commit to undo your mistaken commit.

Fix the last commit message

Scenario: You just typo’d the last commit message, you did git commit -m "Fxies bug #42" but before git push you realized that really should say “Fixes bug #42”.

Undo with: git commit --amend or git commit --amend -m "Fixes bug #42"

What’s happening: git commit --amend will update and replace the most recent commit with a new commit that combines any staged changes with the contents of the previous commit. With nothing currently staged, this just rewrites the previous commit message.

Undo “local” changes

Scenario: The cat walked across the keyboard and somehow saved the changes, then crashed the editor. You haven’t committed those changes, though. You want to undo everything in that file—just go back to the way it looked in the last commit.

Undo with: git checkout -- <bad filename>

What’s happening: git checkout alters files in the working directory to a state previously known to Git. You could provide a branch name or specific SHA you want to go back to or, by default, Git will assume you want to checkout HEAD, the last commit on the currently-checked-out branch.

Keep in mind: any changes you “undo” this way are really gone. They were never committed, so Git can’t help us recover them later. Be sure you know what you’re throwing away here! (Maybe use git diff to confirm.)

Reset “local” changes

Scenario: You’ve made some commits locally (not yet pushed), but everything is terrible, you want to undo the last three commits—like they never happened.

Undo with: git reset <last good SHA> or git reset --hard <last good SHA>

What’s happening: git reset rewinds your repository’s history all the way back to the specified SHA. It’s as if those commits never happened. By default, git reset preserves the working directory. The commits are gone, but the contents are still on disk. This is the safest option, but often, you’ll want to “undo” the commits and the changes in one move—that’s what --hard does.

Redo after undo “local”

Scenario: You made some commits, did a git reset --hard to “undo” those changes (see above), and then realized: you want those changes back!

Undo with: git reflog and git reset or git checkout

What’s happening: git reflog is an amazing resource for recovering project history. You can recover almost anything—anything you’ve committed—via the reflog.

You’re probably familiar with the git log command, which shows a list of commits. git reflog is similar, but instead shows a list of times when HEAD changed.

Some caveats:

  • HEAD changes only.HEAD changes when you switch branches, make commits with git commit and un-make commits with git reset, but HEAD does not change when you git checkout -- <bad filename> (from an earlier scenario—as mentioned before, those changes were never committed, so the reflog can’t help us recover those.
  • git reflog doesn’t last forever. Git will periodically clean up objects which are “unreachable.” Don’t expect to find months-old commits lying around in the reflog forever.
  • Your reflog is yours and yours alone. You can’t use git reflog to restore another developer’s un-pushed commits.
reflog

So… how do you use the reflog to “redo” a previously “undone” commit or commits? It depends on what exactly you want to accomplish:

  • If you want to restore the project’s history as it was at that moment in time use git reset --hard <SHA>
  • If you want to recreate one or more files in your working directory as they were at that moment in time, without altering history use git checkout <SHA> -- <filename>
  • If you want to replay exactly one of those commits into your repository use git cherry-pick <SHA>

Once more, with branching

Scenario: You made some commits, then realized you were checked out on master. You wish you could make those commits on a feature branch instead.

Undo with: git branch feature, git reset --hard origin/master, and git checkout feature

What’s happening: You may be used to creating new branches with git checkout -b <name>—it’s a popular short-cut for creating a new branch and checking it out right away—but you don’t want to switch branches just yet. Here, git branch feature creates a new branch called feature pointing at your most recent commit, but leaves you checked out to master.

Next, git reset --hard rewinds master back to origin/master, before any of your new commits. Don’t worry, though, they are still available on feature.

Finally, git checkout switches to the new feature branch, with all of your recent work intact.

Branch in time saves nine

Scenario: You started a new branch feature based on master, but master was pretty far behind origin/master. Now that master branch is in sync with origin/master, you wish commits on feature were starting now, instead of being so far behind.

Undo with: git checkout feature and git rebase master

What’s happening: You could have done this with git reset (no --hard, intentionally preserving changes on disk) then git checkout -b <new branch name> and then re-commit the changes, but that way, you’d lose the commit history. There’s a better way.

git rebase master does a couple of things:

  • First it locates the common ancestor between your currently-checked-out branch and master.
  • Then it resets the currently-checked-out branch to that ancestor, holding all later commits in a temporary holding area.
  • Then it advances the currently-checked-out-branch to the end of master and replays the commits from the holding area after master‘s last commit.

Mass undo/redo

Scenario: You started this feature in one direction, but mid-way through, you realized another solution was better. You’ve got a dozen or so commits, but you only want some of them. You’d like the others to just disappear.

Undo with: git rebase -i <earlier SHA>

What’s happening: -i puts rebase in “interactive mode”. It starts off like the rebase discussed above, but before replaying any commits, it pauses and allows you to gently modify each commit as it’s replayed.

rebase -i will open in your default text editor, with a list of commits being applied, like this:

rebase-interactive1

The first two columns are key: the first is the selected command for the commit identified by the SHA in the second column. By default, rebase -i assumes each commit is being applied, via the pick command.

To drop a commit, just delete that line in your editor. If you no longer want the bad commits in your project, you can delete lines 1 and 3-4 above.

If you want to preserve the contents of the commit but edit the commit message, you use the reword command. Just replace the word pick in the first column with the word reword (or just r). It can be tempting to rewrite the commit message right now, but that won’t work—rebase -i ignores everything after the SHA column. The text after that is really just to help us remember what 0835fe2 is all about. When you’ve finished with rebase -i, you’ll be prompted for any new commit messages you need to write.

If you want to combine two commits together, you can use the squash or fixupcommands, like this:

rebase-interactive2

squash and fixup combine “up”—the commit with the “combine” command will be merged into the commit immediately before it. In this scenario, 0835fe2 and 6943e85will be combined into one commit, then 38f5e4e and af67f82 will be combined together into another.

When you select squash, Git will prompt us to give the new, combined commit a new commit message; fixup will give the new commit the message from the first commit in the list. Here, you know that af67f82 is an “ooops” commit, so you’ll just use the commit message from 38f5e4e as is, but you’ll write a new message for the new commit you get from combining 0835fe2 and 6943e85.

When you save and exit your editor, Git will apply your commits in order from top to bottom. You can alter the order commits apply by changing the order of commits before saving. If you’d wanted, you could have combined af67f82 with 0835fe2 by arranging things like this:

rebase-interactive3

Fix an earlier commit

Scenario: You failed to include a file in an earlier commit, it’d be great if that earlier commit could somehow include the stuff you left out. You haven’t pushed, yet, but it wasn’t the most recent commit, so you can’t use commit --amend.

Undo with: git commit --squash <SHA of the earlier commit> and git rebase --autosquash -i <even earlier SHA>

What’s happening: git commit --squash will create a new commit with a commit message like squash! Earlier commit. (You could manually create a commit with a message like that, but commit --squash saves you some typing.)

You can also use git commit --fixup if you don’t want to be prompted to write a new commit message for the combined commit. In this scenario, you’d probably use commit --fixup, since you just want to use the earlier commit’s commit message during rebase.

rebase --autosquash -i will launch an interactive rebase editor, but the editor will open with any squash! and fixup! commits already paired to the commit target in the list of commits, like so:

rebase-autosquash

When using --squash and --fixup, you might not remember the SHA of the commit you want to fix—only that it was one or five commits ago. You might find using Git’s ^and ~ operators especially handy. HEAD^ is one commit before HEAD. HEAD~4 is four commits before HEAD – or, altogether, five commits back.

Stop tracking a tracked file

Scenario: You accidentally added application.log to the repository, now every time you run the application, Git reports there are unstaged changes in application.log. You put *.log in the .gitignore file, but it’s still there—how do you tell git to to “undo” tracking changes in this file?

Undo with: git rm --cached application.log

What’s happening: While .gitignore prevents Git from tracking changes to files or even noticing the existence of files it’s never tracked before, once a file has been added and committed, Git will continue noticing changes in that file. Similarly, if you’ve used git add -f to “force”, or override, .gitignore, Git will keep tracking changes. You won’t have to use -f to add it in the future.

If you want to remove that should-be-ignored file from Git’s tracking, git rm --cachedwill remove it from tracking but leave the file untouched on disk. Since it’s now being ignored, you won’t see that file in git status or accidentally commit changes from that file again.


That’s how to undo anything with Git. To learn more about any of the Git commands used here, check out the relevant documentation:

  • checkout
  • commit
  • rebase
  • reflog
  • reset
  • revert
  • rm

Filed Under: Coding

Amazon EC2 Reserved Instances

September 15, 2016 By ec2tec5_wp Leave a Comment

Amazon EC2 Reserved Instances allow you to reserve Amazon EC2 computing capacity for 1 or 3 years, in exchange for a significant discount (up to 75%) compared to On-Demand instance pricing.

Reserved Instances can significantly lower your computing costs for your workloads and provide a capacity reservation so that you can have confidence in your ability to launch the number of instances you have reserved when you need them.

To learn how to buy a Reserved Instance, visit the Amazon EC2 Reserved Instance Getting Started page.

Manage Your AWS Resources

Enter EC2 Console


Introduction to Amazon EC2 Reserved Instances

Why Should I Use Reserved Instances?

Reserved Instances provide you with a significant discount (up to 75%) compared to On-Demand instance pricing.

Reserved Instances provide a capacity reservation so that you can have confidence in your ability to launch the number of instances you have reserved when you need them.

You have the flexibility to pay all, part, or nothing upfront. The more you pay up front, the more you save. If your requirements change, you can modify or sell your Reserved Instance.


The Reserved Instance hourly rate is applied to your Amazon EC2 instance usage when the attributes of your instance usage match the attributes of your Reserved Instances.

With Reserved Instances, you can choose the type of capacity reservation that best fits your application needs.

  • Standard Reserved Instances: These instances are available to launch any time, 24 hours/day x 7 days/week. This option provides the most flexibility to run the number of instances you have reserved whenever you need them, including steady state workloads.
  • Scheduled Reserved Instances: These instances are available to launch within the time windows you reserve. This option allows you to match your capacity reservation to a predictable recurring schedule that only requires a fraction of a day, a week, or a month. For example, if you have a predictable workload such as a monthly financial risk analysis, you can schedule it to run on the first five days of the month. Another example would be scheduling nightly bill processing from 4pm-12am each weekday.
  • Instance type: Instance types comprise varying combinations of CPU, memory, storage, and networking capacity. For example, m3.xlarge.
  • Availability Zone: Amazon EC2 provides you the ability to purchase Reserved Instances within AWS Availability Zones. For example, us-east-1a.
  • Platform description: Reserved Instances can be purchased for Amazon EC2 running Linux/UNIX, SUSE Linux, Red Hat Enterprise Linux, Microsoft Windows Server, and Microsoft SQL Server platforms.
  • Tenancy: Each instance that you launch has a tenancy attribute. Generally, instances run with a default tenancy (running on multi-tenant hardware) unless you’ve explicitly specified to run your instance with a tenancy of dedicated (single tenant hardware) or host (dedicated physical server).

Standard Reserved Instances

  • Term: AWS offers Reserved Instances for 1 or 3 year terms. Reserved Instance Marketplace sellers also offer Reserved Instances often with shorter terms.
  • Payment Option: You can choose between 3 payment options: All Upfront, Partial Upfront, and No Upfront. If you choose the Partial or No Upfront payment option, the remaining balance will be due in monthly increments over the term.

Scheduled Reserved Instances

  • Term: Scheduled Reserved Instances have a 1 year term commitment.
  • Payment Option: Scheduled Reserved Instances accrue charges hourly, billed in monthly increments over the term.

Visit the Amazon EC2 Pricing page to view the Reserved Instance prices sold by AWS and volume discounts.

If you purchase a large number of Reserved Instances in an AWS region, you will automatically receive discounts on your upfront fees and hourly fees for future purchases of Reserved Instances in that AWS region.

Reserved Instances are sold by third-party sellers on the Reserved Instance Marketplace, who occasionally offer even deeper discounts at shorter terms.


Reserved Instance Marketplace allows other AWS customers to list their Reserved Instances for sale. Third-party Reserved Instances are often listed at lower prices and shorter terms. These Reserved Instances are no different to Reserved Instances purchased directly from AWS. To learn more about how to buy a Reserved Instance from AWS or from third-party sellers, visit the Amazon EC2 Reserved Instances Getting Started page.

To learn more about selling your Reserved Instances on the Reserved Instance Marketplace, visit the Amazon EC2 Reserved Instance Marketplace page.


Visit the Amazon EC2 Reserved Instance Getting Started page to learn more about how to purchase the right Amazon EC2 Reserved Instance.

Filed Under: Amazon EC2

Tutorial: Installing a LAMP Web Server on Amazon Linux

August 12, 2016 By ec2tec5_wp Leave a Comment

The following procedures help you install the Apache web server with PHP and MySQL support on your Amazon Linux instance (sometimes called a LAMP web server or LAMP stack). You can use this server to host a static website or deploy a dynamic PHP application that reads and writes information to a database.

Prerequisites

This tutorial assumes that you have already launched an instance with a public DNS name that is reachable from the Internet. For more information, see Step 1: Launch an Instance. You must also have configured your security group to allow SSH (port 22), HTTP (port 80), and HTTPS (port 443) connections. For more information about these prerequisites, see Setting Up with Amazon EC2.

Important

If you are trying to set up a LAMP web server on an Ubuntu instance, this tutorial will not work for you. These procedures are intended for use with Amazon Linux. For more information about other distributions, see their specific documentation. For information about LAMP web servers on Ubuntu, see the Ubuntu community documentation ApacheMySQLPHP topic.

To install and start the LAMP web server on Amazon Linux

  1. Connect to your instance.
  2. To ensure that all of your software packages are up to date, perform a quick software update on your instance. This process may take a few minutes, but it is important to make sure you have the latest security updates and bug fixes.

    Note

    The -y option installs the updates without asking for confirmation. If you would like to examine the updates before installing, you can omit this option.

    [ec2-user ~]$ sudo yum update -y
  3. Now that your instance is current, you can install the Apache web server, MySQL, and PHP software packages. Use the yum install command to install multiple software packages and all related dependencies at the same time.
    [ec2-user ~]$ sudo yum install -y httpd24 php56 mysql55-server php56-mysqlnd
  4. Start the Apache web server.
    [ec2-user ~]$ sudo service httpd start
    Starting httpd:                                            [  OK  ]
  5. Use the chkconfig command to configure the Apache web server to start at each system boot.
    [ec2-user ~]$ sudo chkconfig httpd on

    Tip

    The chkconfig command does not provide any confirmation message when you successfully enable a service. You can verify that httpd is on by running the following command.

    [ec2-user ~]$ chkconfig --list httpd
    httpd           0:off   1:off   2:on    3:on    4:on    5:on    6:off

    Here, httpd is on in runlevels 2, 3, 4, and 5 (which is what you want to see).

  6. Test your web server. In a web browser, enter the public DNS address (or the public IP address) of your instance; you should see the Apache test page. You can get the public DNS for your instance using the Amazon EC2 console (check the Public DNS column; if this column is hidden, choose Show/Hide and select Public DNS).

    Tip

    If you are unable to see the Apache test page, check that the security group you are using contains a rule to allow HTTP (port 80) traffic. For information about adding anHTTP rule to your security group, see Adding Rules to a Security Group.

    Important

    If you are not using Amazon Linux, you may also need to configure the firewall on your instance to allow these connections. For more information about how to configure the firewall, see the documentation for your specific distribution.

    Apache test page

    Note

    This test page appears only when there is no content in /var/www/html. When you add content to the document root, your content appears at the public DNS address of your instance instead of this test page.

Apache httpd serves files that are kept in a directory called the Apache document root. The Amazon Linux Apache document root is /var/www/html, which is owned by root by default.

[ec2-user ~]$ ls -l /var/www
total 16
drwxr-xr-x 2 root root 4096 Jul 12 01:00 cgi-bin
drwxr-xr-x 3 root root 4096 Aug  7 00:02 error
drwxr-xr-x 2 root root 4096 Jan  6  2012 html
drwxr-xr-x 3 root root 4096 Aug  7 00:02 icons

To allow ec2-user to manipulate files in this directory, you need to modify the ownership and permissions of the directory. There are many ways to accomplish this task; in this tutorial, you add awww group to your instance, and you give that group ownership of the /var/www directory and add write permissions for the group. Any members of that group will then be able to add, delete, and modify files for the web server.

To set file permissions

  1. Add the www group to your instance.
    [ec2-user ~]$ sudo groupadd www
  2. Add your user (in this case, ec2-user) to the www group.
    [ec2-user ~]$ sudo usermod -a -G www ec2-user

    Important

    You need to log out and log back in to pick up the new group. You can use the exitcommand, or close the terminal window.

  3. Log out and then log back in again, and verify your membership in the www group.
    1. Log out.
      [ec2-user ~]$ exit
    2. Reconnect to your instance, and then run the following command to verify your membership in the www group.
      [ec2-user ~]$ groups
      ec2-user wheel www
  4. Change the group ownership of /var/www and its contents to the www group.
    [ec2-user ~]$ sudo chown -R root:www /var/www
  5. Change the directory permissions of /var/www and its subdirectories to add group write permissions and to set the group ID on future subdirectories.
    [ec2-user ~]$ sudo chmod 2775 /var/www
    [ec2-user ~]$ find /var/www -type d -exec sudo chmod 2775 {} \;
  6. Recursively change the file permissions of /var/www and its subdirectories to add group write permissions.
    [ec2-user ~]$ find /var/www -type f -exec sudo chmod 0664 {} \;

Now ec2-user (and any future members of the www group) can add, delete, and edit files in the Apache document root. Now you are ready to add content, such as a static website or a PHP application.

(Optional) Secure your web server

A web server running the HTTP protocol provides no transport security for the data that it sends or receives. When you connect to an HTTP server using a web browser, the URLs that you enter, the content of web pages that you receive, and the contents (including passwords) of any HTML forms that you submit are all visible to eavesdroppers anywhere along the network pathway. The best practice for securing your web server is to install support for HTTPS (HTTP Secure), which protects your data with SSL/TLS encryption.

For information about enabling HTTPS on your server, see Tutorial: Configure Apache Web Server on Amazon Linux to use SSL/TLS.

To test your LAMP web server

If your server is installed and running, and your file permissions are set correctly, your ec2-useraccount should be able to create a simple PHP file in the /var/www/html directory that will be available from the Internet.

  1. Create a simple PHP file in the Apache document root.
    [ec2-user ~]$ echo "<?php phpinfo(); ?>" > /var/www/html/phpinfo.php

    Tip

    If you get a “Permission denied” error when trying to run this command, try logging out and logging back in again to pick up the proper group permissions that you configured in To set file permissions.

  2. In a web browser, enter the URL of the file you just created. This URL is the public DNS address of your instance followed by a forward slash and the file name. For example:
    http://my.public.dns.amazonaws.com/phpinfo.php

    You should see the PHP information page:

    Note

    If you do not see this page, verify that the /var/www/html/phpinfo.php file was created properly in the previous step. You can also verify that all of the required packages were installed with the following command (the package versions in the second column do not need to match this example output):

    [ec2-user ~]$ sudo yum list installed httpd24 php56 mysql55-server php56-mysqlnd
    Loaded plugins: priorities, update-motd, upgrade-helper
    959 packages excluded due to repository priority protections
    Installed Packages
    httpd24.x86_64                          2.4.16-1.62.amzn1                    @amzn-main
    mysql55-server.x86_64                   5.5.45-1.9.amzn1                     @amzn-main
    php56.x86_64                            5.6.13-1.118.amzn1                   @amzn-main
    php56-mysqlnd.x86_64                    5.6.13-1.118.amzn1                   @amzn-main

    If any of the required packages are not listed in your output, install them with thesudo yum install package command.

  3. Delete the phpinfo.php file. Although this can be useful information to you, it should not be broadcast to the Internet for security reasons.
    [ec2-user ~]$ rm /var/www/html/phpinfo.php

To secure the MySQL server

The default installation of the MySQL server has several features that are great for testing and development, but they should be disabled or removed for production servers. Themysql_secure_installation command walks you through the process of setting a root password and removing the insecure features from your installation. Even if you are not planning on using the MySQL server, performing this procedure is a good idea.

  1. Start the MySQL server.
    [ec2-user ~]$ sudo service mysqld start
    Initializing MySQL database:  Installing MySQL system tables...
    OK
    Filling help tables...
    OK
    
    To start mysqld at boot time you have to copy
    support-files/mysql.server to the right place for your system
    
    PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
    ...
    
    Starting mysqld:                                           [  OK  ]
    
  2. Run mysql_secure_installation.
    [ec2-user ~]$ sudo mysql_secure_installation
    1. When prompted, enter a password for the root account.
      1. Enter the current root password. By default, the root account does not have a password set, so press Enter.
      2. Type Y to set a password, and enter a secure password twice. For more information about creating a secure password, see http://www.pctools.com/guides/password/. Make sure to store this password in a safe place.

        Note

        Setting a root password for MySQL is only the most basic measure for securing your database. When you build or install a database-driven application, you typically create a database service user for that application and avoid using the root account for anything but database administration.

    2. Type Y to remove the anonymous user accounts.
    3. Type Y to disable remote root login.
    4. Type Y to remove the test database.
    5. Type Y to reload the privilege tables and save your changes.
  3. (Optional) Stop the MySQL server if you do not plan to use it right away. You can restart the server when you need it again.
    [ec2-user ~]$ sudo service mysqld stop
    Stopping mysqld:                                           [  OK  ]
  4. (Optional) If you want the MySQL server to start at every boot, enter the following command.
    [ec2-user ~]$ sudo chkconfig mysqld on

You should now have a fully functional LAMP web server. If you add content to the Apache document root at /var/www/html, you should be able to view that content at the public DNS address for your instance.

(Optional) Install phpMyAdmin

phpMyAdmin is a web-based database management tool that you can use to view and edit the MySQL databases on your EC2 instance. Follow the steps below to install and configure phpMyAdmin on your Amazon Linux instance.

Important

We do not recommend using phpMyAdmin to access a LAMP server unless you have enabled SSL/TLS in Apache; otherwise, your database administrator password and other data will be transmitted insecurely across the Internet. For information about configuring a secure web server on an EC2 instance, see Tutorial: Configure Apache Web Server on Amazon Linux to use SSL/TLS.

  1. Enable the Extra Packages for Enterprise Linux (EPEL) repository from the Fedora project on your instance.
    [ec2-user ~]$ sudo yum-config-manager --enable epel
  2. Install the phpMyAdmin package.
    [ec2-user ~]$ sudo yum install -y phpMyAdmin

    Note

    Answer y to import the GPG key for the EPEL repository when prompted.

  3. Configure your phpMyAdmin installation to allow access from your local machine. By default,phpMyAdmin only allows access from the server that it is running on, which is not very useful because Amazon Linux does not include a web browser.
    1. Find your local IP address by visiting a service such as whatismyip.com.
    2. Edit the /etc/httpd/conf.d/phpMyAdmin.conf file and replace the server IP address (127.0.0.1) with your local IP address with the following command, replacingyour_ip_address with the local IP address that you identified in the previous step.
      [ec2-user ~]$ sudo sed -i -e 's/127.0.0.1/your_ip_address/g' /etc/httpd/conf.d/phpMyAdmin.conf
  4. Restart the Apache web server to pick up the new configuration.
    [ec2-user ~]$ sudo service httpd restart
    Stopping httpd:                                            [  OK  ]
    Starting httpd:                                            [  OK  ]
  5. Restart the MySQL server to pick up the new configuration.
    [ec2-user ~]$ sudo service mysqld restart
    Stopping mysqld:                                           [  OK  ]
    Starting mysqld:                                           [  OK  ]
  6. In a web browser, enter the URL of your phpMyAdmin installation. This URL is the public DNS address of your instance followed by a forward slash and phpmyadmin. For example:
    http://my.public.dns.amazonaws.com/phpmyadmin

    You should see the phpMyAdmin login page:

    Note

    If you get a 403 Forbidden error, verify that you have set the correct IP address in the /etc/httpd/conf.d/phpMyAdmin.conf file. You can see what IP address the Apache server is actually getting your requests from by viewing the Apache access log with the following command:

    [ec2-user ~]$ sudo tail -n 1 /var/log/httpd/access_log | awk '{ print $1 }'
    205.251.233.48

    Repeat Step 3.b, replacing the incorrect address that you previously entered with the address returned here; for example:

    [ec2-user ~]$ sudo sed -i -e 's/previous_ip_address/205.251.233.48/g' /etc/httpd/conf.d/phpMyAdmin.conf

    After you’ve replaced the IP address, restart the httpd service with Step 4.

  7. Log into your phpMyAdmin installation with the root user name and the MySQL root password you created earlier. For more information about using phpMyAdmin, see the phpMyAdmin User Guide.

Related Topics

For more information on transferring files to your instance or installing a WordPress blog on your web server, see the following topics:

  • Transferring Files to Your Linux Instance Using WinSCP
  • Transferring Files to Linux Instances from Linux Using SCP
  • Tutorial: Hosting a WordPress Blog with Amazon Linux

For more information about the commands and software used in this topic, see the following web pages:

  • Apache web server: http://httpd.apache.org/
  • MySQL database server: http://www.mysql.com/
  • PHP programming language: http://php.net/
  • The chmod command: https://en.wikipedia.org/wiki/Chmod
  • The chown command: https://en.wikipedia.org/wiki/Chown

If you are interested in registering a domain name for your web server, or transferring an existing domain name to this host, see Creating and Migrating Domains and Subdomains to Amazon Route 53 in the Amazon Route 53 Developer Guide.

Filed Under: Amazon EC2

Linux AMI Virtualization Types

August 12, 2016 By ec2tec5_wp Leave a Comment

Linux Amazon Machine Images use one of two types of virtualization: paravirtual (PV) or hardware virtual machine (HVM). The main difference between PV and HVM AMIs is the way in which they boot and whether they can take advantage of special hardware extensions (CPU, network, and storage) for better performance.

For the best performance, we recommend that you use current generation instance types and HVM AMIs when you launch your instances. For more information about current generation instance types, see the Amazon EC2 Instances detail page. If you are using previous generation instance types and would like to upgrade, see Upgrade Paths.

For information about the types of the Amazon Linux AMI recommended for each instance type, see the Amazon Linux AMI Instance Types detail page.

HVM AMIs

HVM AMIs are presented with a fully virtualized set of hardware and boot by executing the master boot record of the root block device of your image. This virtualization type provides the ability to run an operating system directly on top of a virtual machine without any modification, as if it were run on the bare-metal hardware. The Amazon EC2 host system emulates some or all of the underlying hardware that is presented to the guest.

Unlike PV guests, HVM guests can take advantage of hardware extensions that provide fast access to the underlying hardware on the host system. For more information on CPU virtualization extensions available in Amazon EC2, see Intel Virtualization Technology on the Intel website. HVM AMIs are required to take advantage of enhanced networking and GPU processing. In order to pass through instructions to specialized network and GPU devices, the OS needs to be able to have access to the native hardware platform; HVM virtualization provides this access. For more information, see Enhanced Networking and Linux GPU Instances.

All current generation instance types support HVM AMIs. The CC2, CR1, HI1, and HS1 previous generation instance types support HVM AMIs.

To find an HVM AMI, verify that the virtualization type of the AMI is set to hvm, using the console or the describe-images command.

PV AMIs

PV AMIs boot with a special boot loader called PV-GRUB, which starts the boot cycle and then chain loads the kernel specified in the menu.lst file on your image. Paravirtual guests can run on host hardware that does not have explicit support for virtualization, but they cannot take advantage of special hardware extensions such as enhanced networking or GPU processing. Historically, PV guests had better performance than HVM guests in many cases, but because of enhancements in HVM virtualization and the availability of PV drivers for HVM AMIs, this is no longer true. For more information about PV-GRUB and its use in Amazon EC2, see PV-GRUB.

The C3 and M3 current generation instance types support PV AMIs. The C1, HI1, HS1, M1, M2, and T1 previous generation instance types support PV AMIs.

To find a PV AMI, verify that the virtualization type of the AMI is set to paravirtual, using the console or the describe-images command.

PV on HVM

Paravirtual guests traditionally performed better with storage and network operations than HVM guests because they could leverage special drivers for I/O that avoided the overhead of emulating network and disk hardware, whereas HVM guests had to translate these instructions to emulated hardware. Now these PV drivers are available for HVM guests, so operating systems that cannot be ported to run in a paravirtualized environment (such as Windows) can still see performance advantages in storage and network I/O by using them. With these PV on HVM drivers, HVM guests can get the same, or better, performance than paravirtual guests.

Filed Under: Amazon EC2

Andy Jassy is finally named CEO of Amazon Web Services

July 7, 2016 By ec2tec5_wp Leave a Comment

Amazon Web Services senior vice president Andy Jassy speaks at the public cloud's re:Invent conference in Las Vegas on Nov. 12, 2014.

Above: Amazon Web Services senior vice president Andy Jassy speaks at the public cloud’s re:Invent conference in Las Vegas on Nov. 12, 2014.

Image Credit: Screen shot

Amazon today announced that the head of Amazon Web Services (AWS), Andy Jassy, has finally been promoted to chief executive of that Amazon business unit. AWS is now the market leader of the public cloud business, and Jassy has been the face of the company. Now he’s is getting the very well-deserved CEO title.

Meanwhile, Jeff Wilke has been named chief executive of worldwide consumer for Amazon.

“This is not a reorganization but rather a recognition of the roles they’ve played for a while,” Amazon said in a blog post. Until today, Jassy was only a senior vice president.

AWS is 10 years old now. Jassy spent plenty of time with Amazon CEO Jeff Bezos and has managed to scale AWS into a business that generated nearly $2.5 billion in revenue in a single quarter. The business is without a doubt a bright spot on Amazon’s quarterly earnings statements as it brings in considerable operating income in contrast to the rest of Amazon, which historically loses money in pursuit of long-term growth.

Filed Under: AWS

EC2 Run Command adds support for more predefined commands and announces open source agent

July 7, 2016 By ec2tec5_wp Leave a Comment

Posted On: Apr 4, 2016

Today we are excited to announce two new predefined commands for EC2 Run Command for your Windows instances. To learn more about how to use these new commands, please visit the user guide.

  • On-demand patching: Using these commands, you will be able to scan to find out which updates are missing, and then install specific or all missing updates.
  • Collecting inventory information: The inventory command lets you collect on-instance information such as operation system related details, installed programs, and installed Windows Updates.

We are also making the EC2 Run Command Linux agent available as open source. The source code for the Amazon SSM Agent is available on GitHub. We encourage you to submit pull requests for changes that you would like to have included.

We launched EC2 Run Command in October 2015 to provide a simple way of automating common administrative tasks like installing software or patches, running shell commands, performing operating system changes and more. Run Command allows you to execute commands at scale and provides visibility into the results, making it easy to manage your instances.

To get learn more, please visit the EC2 Run Command webpage and the user guide for Linux and Windows.

Filed Under: Amazon EC2

  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Go to Next Page »

Primary Sidebar

Contact

We are a subsidiary of Easy Cloud.

office: 626-607-4250
support: Visit Support Site

FULLY MANAGED CLOUD HOSTING ON AMAZON

Get the most out of your Amazon Cloud. Our Cloud Architects will set you up and our SysAdmins will support you.

Bring your clients, your applications, and your new ideas under our full-service managed cloud platform.

All our plans include 24/7 Certified SysAdmin support, proactive server monitoring, and much more.

Fully Managed Atlassian hosting on Amazon EC2

We handle the infrastructure. You focus on your business.

Corporate Website

  • Atlasssian JIRA on Amazon EC2
  • Atlassian Confluence on Amazon EC2
  • Atlassian Bitbucket on Amazon EC2
  • The entire suite of Atlasssian tools on your very own Amazon EC2 instance (HipChat, Bamboo, Clover, Fisheye, Crucible and Crowd)

ENTERPRISE WORDPRESS HOSTING ON AWS

Our Enterprise WordPress Hosting on the Amazon Cloud can handle your traffic peaks better than any other WordPress solution.

Disaster-Proof Uptime
Our one-of-a-kind architecture features no single point of failure and multiple layers of redundancy to keep your site up no matter what.

Immediate Scaling
Our container-based architecture scales in seconds, not minutes, providing a seamless experience that’s always just right for your site.

Security You Can Count On
Security-minded architecture and workflows plus world-class DDoS protection keep your sites safer.

Seasoned Support Engineers
Enjoy 24/7 proactive monitoring, and around the clock support from our experienced WordPress- and Amazon-certified engineers.

Copyright © 2021 · Powered by Easy Cloud Solutions