Assignment for Week 3: Puppet setup

Description

In order to use Puppet for further system management in the remainder of this class, you'll need to install Puppet on your instances and set it up to sync its configuration from your team's Puppet repo on GitHub. (Note that we are using what is called "serverless" Puppet for simplicity and to save AWS resources, since current versions of the Puppet master server would require running a larger, and hence more expensive, AWS instance for the server.)

What you need to do

Obtain and install Puppet on your instances. This probably just means running apt-get install puppet (or the equivalent package manager command on Red Hat/Centos, SUSE, or Arch Linux).
Put your Puppet configuration files into Git version control from one of your instances. Do not edit files by hand in /etc/puppet either before or after you initialize git. Also, unless otherwise specified you should perform these commands with root privileges on your instance. It may be most convenient to just use sudo bash to get a root shell so you don't have to precede everything with "sudo".
```
    # cd /etc/puppet
    # git init
    # git add .
    # git commit
```
Upload your initial unmodified Puppet configuration to your GitHub puppet repository. First you'll need to configure your GitHub Puppet repository as the default remote ("origin") for /etc/puppet:
```
    # git remote add --mirror=fetch origin https://github.com/cis399-2019-team/teamname-puppet.git
```
(Substitute your own team's name for "teamname".) Then push your Puppet config files into GitHub.
```
    # git push origin master
```
Once you have Puppet's configuration files uploaded to GitHub from one of your instances, you can clone your GitHub repo onto your other instances so that they will also be connected to your GitHub puppet repo:
```
    # cd /etc
    # git clone https://github.com/cis399-2019-team/teamname-puppet.git
    # rm -rf puppet
    # mv teamaname-puppet puppet
```
This process also works to initialize any new AWS instances to use your existing Puppet configuration or as a way of resyncing your Puppet configuration if you find you are unable to pull from your GitHub puppet repo because of local modifications in /etc/puppet.
On your own personal computer you can clone your own working copy of the central repository.
$ git clone https://github.com/cis399-2019-team/teamname-puppet.git
From there you can use a standard Git workflow ("git pull", "git add", "git commit", "git push") to update the central repository from your personal copy, and update your Puppet configuration this way (and only this way) on the your instances:
```
    # cd /etc/puppet
    # git pull origin master
```
Add a node declaration for each instance to your Puppet manifests/site.pp in your team Puppet repository and pull that to your instances, so that there is a node declaration for each instance:
```
    node ip-10-0-x-yy {
    }

    node ip-10-0-x-zz {
    }
```
A node name is the "short" hostname as reported by hostname (without the domain name appended).
At this point you should be able to completely manage your instances using Puppet. One useful thing to do is to automate Puppet updates from your central git repository on your instances. Put this in code/modules/puppet/manifests/init.pp in your team Puppet repo:
```
    # update /etc/puppet and run "puppet apply":
    class puppet {
    	cron { "puppet apply":
	    command => "cd /etc/puppet && git pull -q origin master && puppet apply manifests/site.pp",
	    user    => root,
	    minute  => "*/5",
	}
    }
```
Then add include puppet to each of your nodes in manifests/site.pp:
```
    node ip-10-0-x-yy {
    	include puppet
    }

    node ip-10-0-x-zz {
    	include puppet
    }
```
Log in to each of your instances, become root with sudo bash, and run puppet apply -t to get this set up on each instance:
```
    # cd /etc/puppet
    # git pull origin master
    # puppet apply -t manifests/site.pp
```
("-t" causes Puppet to produce a little additional debugging output which can be useful when you run "puppet apply" by hand.)
This creates a cron job that runs every 5 minutes to update the Puppet files from your team Puppet repo and runs "puppet apply" to apply configuration. You can run the same sequence of commands by hand if you want to immediately apply Puppet changes to any one of your instances.
Create a module for the ssh service in code/modules/sshd and apply it to all of your EC2 instances. The module should make sure that:
1. The package that provides sshd is installed.
2. The service that manages sshd is started at boot time and restarted if it should happen to stop running.
3. It is capable of updating the /etc/ssh/sshd_config file on your system and notifying sshd when it changes.
4. Add each of your team's ssh keys to the accounts that are used for login access on each of your instances, usually ubuntu or ec2-user.
  An example resource declaration would look like:
```
ssh_authorized_key { "stevev-key-pair-oregon":
    	user => "ubuntu",
	key  => "AAAAB3NzaC1yc2EAAAADAQABAAABAQCrFq80b0ptexNiI6KP4hxww5d5RFm8djIpsdJqRZDyoyD5vaf7d30bTLef8su6stHuBBjKccMcUjNyu4BliJBXIy7bKVDllVB5oeLFizDahQcgqjYfzyqj16uEa7NLBW5/3ljLpPX8XEI7YFM/hg65JFgpQIAiBi2N6bGj9mQrh/51SpCO6FruQH8KVjDl/CLgbnFq9cDwRDAo4tvPO1b0MRVrvM8BbZbBUHqV/093jVXkwY+BxsU6cgOnHrSmoTnH4MqMXUI/ok31JORVbWW5NAz28Ag7V/NbDvRBIYicJOd9aqEST/L812+tmnE8iQzn3bZvv7v0E7FHneCS5Qpz",
}
```
Test that your Puppet module will properly handle these situations (be careful and stay logged in when doing these tests until you have verified the correct actions occur):
1. The sshd package is uninstalled.
2. sshd has been killed.
3. The /etc/ssh/sshd_config file is overwritten or deleted.
4. The ubuntu account's .ssh/authorized_keys file is overwritten or deleted.

What to turn in

Create a subdirectory in your team git repository with the name "week3" and create files containing your handin materials under that.

Transcripts showing what puppet apply -t /etc/puppet/manifests/site.pp outputs after you:
1. Remove the sshd package.
2. Stop sshd.
3. Modify or delete /etc/ssh/sshd_config.
4. Modify or delete .ssh/authorized_keys in an instance's user account.

Material for all of the above should be checked into your team git repository by class time on Monday, July 15. For an individual team member to receive credit for the assignment, they must have made at least one commit.

Evaluation

I'll be looking over your sshd module in your Puppet repository and the output of your "puppet apply" runs to make sure your module properly handles all of the specified sshd configuration and management tasks.

Steve VanDevender