Whenever you are deploying an application to a production server it's good practice to create a dedicated account for the application. This gives you a much greater level of control over the security of the application. Before we create the account we are going to create a group of users called webusers. We will add our new user to this group of users. This will become useful later when we add the apache user www-data to the same group allowing apache to have the correct necessary permissions to access folders within the application. To create the user group type
sudo groupadd webusers
To create an account for the tennisClub application type
sudo adduser tennisclub
You will be asked for a password. There is no strong password check here but you should be sure to use at least eight characters with at least one number and one special character and one upper case.
Your VM lives in the cloud and is exposed. Although you might not be storing your most sensitive information there's a more than reasonable chance that if you don't take reasonable security measures your VM will be hacked and used as a base from which to launch other malign attacks. In the modern era the security of the internet depends on anyone and everyone taking precautions - particularly if you are the administrator of a cloud server. As part of the user creation process, you will be asked for additional information such as the user's full name, room number and phone number. In the context of a user account created to host an application, these attributes are not as important and so can be left blank.
Next to add the new user to the group 'webusers' type
sudo adduser tennisclub webusers
Next login to the new account you have just created by typing
You will be prompted for your username and password.
There are a number of ways of getting your application files into this account. One popular way is to use WinSCP. Regardless of what file transfer mechanism you choose to use you will need to use public/private key encryption to secure the account.
To create public and private keys we use the same steps we did earlier.
Press enter to the questions which follow to choose the default responses. To change directory into the folder containing the keys - type:
To enable the public key to be used to login copy it to a file called authorized_keys by typing
cp id_rsa.pub authorized_keys
We can use the private key just as it is (openssh version) to connect using git. It's a good idea to give the private key an appropriate name to distinguish it from private key files you might have for other servers. With this in mind, take a copy of the private key file.
cp id_rsa newPhalconVM.private
To view the contents of this file type:
Stretch out your terminal window so you can see the entire contents of the file at once. Select the text of the file and then right click on your selected text to copy the contents of the file.
Open Notepad++ or your preferred Windows editor and paste in the contents of the file. Save this as newPhalconVM.private
You now have a private key with which you can login to the specific account which will be used to run your application. You will rarely, if ever, login to this account as it's an application account so you should not need to login to it. Keep the private key for this account stored and backed up securely somewhere. Many people have a dedicated my_keys folder which they keep carefully with their private key files.
If you just want to do file transfer at this point you can use WinSCP. This program allows for file transfer using the Secure File Transfer Protocol. This you will need generate a putty standard private key to do this. You can do this using the puttygen tool as we did earlier.
I use git both to store my repositories but also transfer my files. This allows me to set up my applications to do "devops"-style deployment. That is to say, every time I do a "commit" using git and "push" my code into the repository, the code will be live on the server.
For a truly live production system, this is a complex process that requires a very organised test-driven-development approach. For less mission critical systems it is a great way to get your system up in a live environment and start testing what it will be like to use it for real.
Before we set up a repository within our newly generated user account we need to create a separate folder for the repository. We can't use the home folder to store the repository as we will need to set special permissions on the folder which can conflict with the ssh access.
Before we create a new folder for the application you need to make sure you are back in the home folder - type
to return to the home folder for the tennisclub user. To create the new folder which will hold the working directory type
Now we need to change the permissions on this folder so that it belongs to the webusers group. Our setup depends on both the apache user(www-data) and the tennisclub user both belonging to the "webusers" group. Given that the folder has write permissions switched on for group members this means that Apache will be able to read and write to any subfolders which are copied into this folder. This will be important, particularly when it comes to the cache folder as apache will need to write files in here. To change the tennisclub application folder so that it is in the webusers group type
chgrp webusers tennisclub
To make files copied into this folder inherit the folder permissions we need to use the setgid bit of of the folder. This setgid bit refers to the set group id bit of the permissions of the folder. When applied to a folder with execute permissions means that any scripts executed from within this folder will be executed under the group permissions. When talking about files in the folder it means that all files copied in here will inherit the same permissions as the parent folder. This is very handy. To turn on the setgid bit for the tennisclub home folder, execute the following command:
chmod g+s tennisclub
Now when files are uploaded or copied into this folder they will inherit the permissions of the parent. This means that any user in the webusers group will have write access to the tennisclub folder and any new folders which are transferred into this folder.
Now we just need to add the apache user to the webusers group. The apache user on Linux is always www-data. We don't have to create this user it was created when we installed Apache. To add this user to the webusers group type
sudo adduser www-data webusers
Now to ensure the apache user properly picks up on this change, we need to restart the Apache webserver. To do this type
sudo service apache2 restart
It is possible to do this using a hosted repository system such as github or bitbucket, but it is also possible to set up a repository directly on your server. Next, we come to setting up a git repository on our server. This approach to hosting a repository is really a bit of a hack and I would not recommend setting up a production server in this way.
First change directory into the tennisclub folder which will contain the application source files:
To set up a repository directly on your server under your application account type
This will create the .git folder and the necessary folder structure within that which contains all the necessary information about your git repository. Next comes the hack part. In order to allow us to "push" code into this empty repository type the following command
git config receive.denyCurrentBranch updateInstead
The updateInstead ensures that the working directory of the repository is updated to point to the HEAD after a push. This allows for our working directory to be updated to the current version of the code after every push - allowing for devops style deployment. *
*Possibly a more correct way to do this would be to use the git hooks functionality as it would give you more control over what happens to the files after they're received. There's a good explanation of this approach here https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks