basic question about setting up new staging

[cccs-ip]

I am following the installation instructions [which need to be updated] as well as the instructions for configuring staging, but (as usual) I am stuck at the basic configuration.

To create a new project, I should first create a user:

sudo adduser min.

Great, now min exists. So I make min a virtual environment:

cd /home/min/

sudo mkvirtualenv min

Great, now min has a virtualenv. But did I do this incorrectly? Should I have created the virtualenv as min rather than using sudo?

Now I wish to clone in our project:

git clone git@github.com:cccs-web/core.git min

Cloning into 'min'...
The authenticity of host 'github.com (192.30.252.129)' can't be established.
RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,192.30.252.129' (RSA) to the list of known hosts.
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

.. so there are a couple of things I realize I am doing wrong. Firstly, I didn't try to clone the 'min' branch that I had made; how do I do that? Secondly, I am being told that our open-source git project requires an ssh key to clone? I suppose others normally fork to their own GitHub account to git around this?

Kindly help to guide me through this process.

[pwhipp]

No worries. Just the instructions then:

If min is working into a branch that you or I typically deploy then he does not need to be added as a user. If he is going to do his own deployment then you would add him as a user. If he is added as a user, the user either needs his normal private key to identify him properly to github (I don't advise this but lots of people do it - personally I like my private key to stay on my local machine) OR you can get a deploy key for him (google for github instructions). Beyond that, these instructions are pretty much identical for either case.

If you use sudo, you are working as root. You will almost never want to create a virtual environment as root. You create it as the user you are working as.

So... on the assumption that you want a site with min as the branch being used the process is as follows:

Bring your local working copy up to date, make sure you've got the min branch and switch to it (git checkout min).

We need a deployment for min: cp -ar deploy/staging deploy/min Edit the resulting files to match the intended paths and domain (replace staging with min throughout and it should all be good) - I should script this some time.

Stage, commit and push it (testing nginx locally needs a setup you don't have and these are pretty straightforward changes so should be OK).

Next you need to decide whether or not min should have his own database (probably). If so, make sure that it is set up locally and that you have sorted a secrets.py for it. Create a min.py to reference the database.

Test this locally by explicitly providing the settings to the runserver command e.g.

django runserver --settings settings.min

Commit and push everything.

rsync the db to crossculturalconsult.com

On crossculturalconsult.com, restore the db and add the db user. Then switch to the cccs user (sudo -iu cccs) and make a new virtual environment (I'd call it min). Set the settings module.

Clone a working copy into a folder called 'min' alongside production and staging. cd to it and 'setvirtualenvproject' and 'add2virtualenv .'

Use 'django runserver 12345' to make sure everything works (12345 is an unused port but you cannot access it outside because of security so you are just doing a sanity check - if the server runs, its all good). I could open a port for more involved testing of this sort but I've never needed to.

Now link the deploy/min/nginx.conf into /etc/nginx/sites-available and then link that into sites-enabled. Test with 'sudo nginx -t' and reload nginx if all good.

Finally, copy deploy/min/upstart.conf to /etc/init/cccs_min.conf and start the service. Check its status because upstart fails silently if anything is wrong:

sudo service cccs_min start
sudo service cccs_min status

Phew. All done. Test the result by visiting min.crossculturalconsult.com

Note that by copying staging you included the basic site protection so you'll need to login with the usual credentials to access the site.

[cccs-ip]

Hi Paul, and thanks.. but let's focus on the very basics:

Bring your local working copy up to date, make sure you've got the min branch and switch to it (git checkout min).

this is not git clone git@github.com:cccs-web/core.git min is it?

also, you glossed a somewhat challenging configuration step with this statement:

If min is working into a branch that you or I typically deploy then he does not need to be added as a user. If he is going to do his own deployment then you would add him as a user.

If we don't need him as a user, then where / how would we set up the 'min' branch?

... As for creating a user for min (which is what I assume we did for 'staging'), I am fine to create a DH key and to store it on the server.... but wouldn't this key need to be linked to min's GitHub account? That is, we can't create a key for 'min' without also creating a pseudo 'min' user on GitHub, or otherwise linking the pub key into min's user, correct?

... I am sure that min would help us to add in the public key to his profile if needed. The server, however, would be set up the same as production or staging... where we pull into it changes that are being pushed to GitHub. Min doesn't need to be on the server, but you previously told me that each instance of the site needs a specific user. I don't entirely follow why this message suggests now that no 'min' user is necessary...

[pwhipp]

This is fully deployed as https://test.crossculturalconsult.com/

The working copy is at /home/cccs/test and it is currently serving the min branch.

The test deployment uses the cccs_test which can be periodically updated as a snapshot of cccs_production as needed. This should always be done before testing migrations.

To update the deployment:

~ $ ssh crossculturalconsult.com
...
~ $ sudo -iu cccs
cccs:~ $ workon test
(test)cccs:~/test $ git status
On branch min
Your branch is up-to-date with 'origin/min'.
(test)cccs:~/test $ git pull
Already up-to-date.
(test)cccs:~/test $ # django migrate (if there are migrations (or if in doubt))
(test)cccs:~/test $ # django collectstatic (if there are new static files (or if in doubt))
(test)cccs:~/test $ logout
~ $ sudo service cccs_test restart
cccs_test stop/waiting
cccs_test start/running, process 28692