- 27 Jun, 2013 2 commits
- 26 Jun, 2013 7 commits
-
-
incorrect inventory for example
John Jarvis committed -
John Jarvis committed
-
changing owner/group/mode for ssh_key_forward sudo config
John Jarvis committed -
John Jarvis committed
-
Jarv/update edxapp deploy
John Jarvis committed -
John Jarvis committed
-
John Jarvis committed
-
- 25 Jun, 2013 13 commits
-
-
John Jarvis committed
-
John Jarvis committed
-
Please enter the commit message for your changes. Lines starting
John Jarvis committed -
John Jarvis committed
-
John Jarvis committed
-
John Jarvis committed
-
John Jarvis committed
-
John Jarvis committed
-
John Jarvis committed
-
John Jarvis committed
-
John Jarvis committed
-
John Jarvis committed
-
John Jarvis committed
-
- 24 Jun, 2013 13 commits
-
-
John Jarvis committed
-
John Jarvis committed
-
John Jarvis committed
-
John Jarvis committed
-
John Jarvis committed
-
This adds termination support to the ec2 module
John Jarvis committed -
Add an empty default xserver env.
Feanil Patel committed -
John Jarvis committed
-
Feanil Patel committed
-
John Jarvis committed
-
John Jarvis committed
-
Bastion egress should be port 22 not 80.
Feanil Patel committed -
Feanil Patel committed
-
- 22 Jun, 2013 3 commits
- 21 Jun, 2013 2 commits
-
-
Initial set of files to bring up a staging edx
Joe Blaylock committed -
The main thing of interest here is stage-ansible.cfg and stage-ssh-config, which taken together offer a way to have an environment with different access control policies and a different VPC jumpbox without disturbing the usual case of working with your VPC production hosts. To run this, edit stage-ssh-config with a sensible jumpbox configuration and make sure the options in stage-ansible.cfg are the set of ansible options you expect to use, then invoke ansible with ANSIBLE_CONFIG like so: ``` ANSIBLE_CONFIG=stage-ansible.cfg ansible-playbook -v -i './ec2.py' edxapp_stage.yml ```
Joe Blaylock committed
-