README: change order of operations so that user management and setup takes place where it should: before everything else.

Author: abstractmachines

README.md

@@ -45,7 +45,9 @@ Hand out a public IP which can be hit with a curl request.
 8. Deploy on AWS Linux Ubuntu EC2 VM instance.
 <br><br> This will involve setting up the virtual Ubuntu machine (14.04) using the AWS Console as well as selecting appropriate security groups. This will also involve setting up a new or existing key pair for secure SSH. Server user administration should not involve logging in with a password; instead, allow users access via their keys, and remove their access by removing their keys. Once an AWS EC2 Ubuntu instance is up and running, you can install desired software using appropriate package management tools, as follows.
 
-Getting started on AWS EC2 Ubuntu will involve downloading your private key keyname.pem, putting it in:
+<strong>Logging in</strong>
+
+Getting started on AWS EC2 Ubuntu will involve first logging in using keys. Start by downloading your private key keyname.pem, putting it in:
 ```
 ~/.ssh/keyname.pem
 ```
@@ -61,34 +63,6 @@ Scp a file to user's home ~/. Note that we aren't using rsync at this time.
 ```
 $ scp -i /path/to/keyname.pem /path/file.txt user@AWSpublicDNS:~
 ```
-User management follows in "step 3" of AWS process documented here. You don't want users to have to have your private key to login, of course. You'll also note that we have a "deploy user" for purposes of this simple Vertical Slice full stack app, but generally <strong>Jenkins</strong> or a similar continuous integration solution would deploy, not a user. <strong> You really don't want to setup your server as the "ubuntu" user, so strongly consider skipping ahead here to the user management stuff in step 3.</strong>
-
- <strong>Once you're set up properly with users, and have AWS access both as a non-ubuntu-username sudoer AND as a non-sudoer 'deploy' user that's in the same group as www-data:</strong>
-
- <strong>First you have to install Node: </strong> <br>
-I chose to install Node on AWS using nvm instead of using Debian's apt-get package manager to install Node. That's because nvm helps you manage specific versions of Node on a per-project basis. As with all npm-related projects, the point of a per-project package manager includes project-directory installations of software packages/versions *instead of global installs.*
-
- $ nvm script
-// To verify installed version:
-$ command -v nvm
-// Install the version you want:
-$ nvm install 4.2.3
-// To specify version in nvmrc file for THIS project directory (remember that one of the points of using npm is to manage packages PER project, and that's why global installs are something to watch out for and often avoid:) From project root dir:
-$ echo "4.2.3" > .nvmrc
-// Now, to USE that Node version:
-$ nvm use
-
- <strong>Second, you'll need to install a web server. I chose nginx instead of Apache or other options, and I installed it using Debian (Ubuntu) Linux's distribution's package manager tools apt-get. </strong> The point here is that we are managing our own installations rather than always using installers providers give us. It's always best to spin things up by hand so you learn the underlying logic/tech. MAGIC BAD.
-
-$ apt-get install nginx // or similar
-// you can start and stop nginx signals as such:
-$ sudo service yourappdirectory start
-$ sudo nginx -s reload
-
- Note that with the above, yourappdirectory will read nodeapp for us in the future.
-
- <strong>Third, you have to set up the proper users, groups, and permissions. </strong>
- Set and manage shell users and permissions on EC2 instance. Your deploy user cannot be a sudo-er. You want to restrict permissions and be conservative.
 
 Recall permissions are in binary/hex as such. Here is an example of our users group being able to read, write and execute, and everyone else can just read:
 ```
@@ -236,6 +210,38 @@ $ id gobbluth
 
 <strong>After you add a user and group, set a password for that user, and add the user to the appropriate group, you'll need to copy the public key for that user to the authorized keys directory for that user. </strong> *Check back with the numbered list items for user management above to ensure you went through all the steps. If you want another user to assume deploy, you'll have to copy that user's public key into the authorized_keys file for that user. Note that we normally wouldn't have a user deploying code, we'd use Jenkins or similar CI.*
 
+ <strong>Once you're set up properly with users, install git and curl:</strong>
+ ```
+ $ sudo apt-get install curl git
+ ```
+
+ <strong>Now we begin standing up the server:</strong>
+
+ <strong>First you have to install Node: </strong> <br>
+I chose to install Node on AWS using nvm instead of using Debian's apt-get package manager to install Node. That's because nvm helps you manage specific versions of Node on a per-project basis. As with all npm-related projects, the point of a per-project package manager includes project-directory installations of software packages/versions *instead of global installs.*
+
+ $ nvm script
+// To verify installed version:
+$ command -v nvm
+// Install the version you want:
+$ nvm install 4.2.3
+// To specify version in nvmrc file for THIS project directory (remember that one of the points of using npm is to manage packages PER project, and that's why global installs are something to watch out for and often avoid:) From project root dir:
+$ echo "4.2.3" > .nvmrc
+// Now, to USE that Node version:
+$ nvm use
+
+ <strong>Second, you'll need to install a web server. I chose nginx instead of Apache or other options, and I installed it using Debian (Ubuntu) Linux's distribution's package manager tools apt-get. </strong> The point here is that we are managing our own installations rather than always using installers providers give us. It's always best to spin things up by hand so you learn the underlying logic/tech. MAGIC BAD.
+
+$ apt-get install nginx // or similar
+// you can start and stop nginx signals as such:
+$ sudo service yourappdirectory start
+$ sudo nginx -s reload
+
+ Note that with the above, yourappdirectory will read nodeapp for us in the future.
+
+ <strong>Third, you have to set up the proper users, groups, and permissions. </strong>
+ Set and manage shell users and permissions on EC2 instance. Your deploy user cannot be a sudo-er. You want to restrict permissions and be conservative.
+
 <strong>Fourth, you have to spin up a service by hand on the AWS EC2 Ubuntu instance using upstart daemon, make it executable, and set the proper Linux run levels. Of course, a sudoer must complete all of these tasks, not your deploy user. You're replacing the start-at-boot init.d daemon with one of your own!</strong>
 
 Create the conf file: Where nodeapp is the name of your app's directory: