Developers love by Git (or any repo, really) but we sysadmins generally don’t care. If the web-server is running and the modules are available, we’re happy! But there are times when a developer asks that a web-server be provisioned with the necessary php modules and also a place for them to put their code on the web-server. Well, this is the article for you, the SysAdmin who doesn’t care about Git, code-bases and web-applications but needs the job done.
Quick scope check: We’re starting with a BitBucket repo ready to go. Our web-server is running and modules installed. We’re going to get the vhost ready, cloning a repo into it and secure it.
The workflow: This is the key to it all. Knowing how things fit together in a business environment. There are three groups of people. 1) the system administrator (sysadmin), 2) the developer, and 3) the people who view the results either in testing or in production. The sysadmin creates the environment including the server, web server and manages file permissions and ownership. The developer creates the code on their test system and “pushes” it to Git. Either the sysadmin or developer can then “pull” the code-base down from Git making it available via the web server. Sometimes the sysadmin creates two identical environments – “staging” and “production”. Staging is where the developer demonstrates their work to the client (those paying) and Production is where the world can see it.
Our repo is “firstname.lastname@example.org:example/project.git”. We got this from the developer. Otherwise we can get it by logging into BitBucket, going to the “example” project and grabbing the “path” which is usually at the top right of the BitBucket project page. In this article the BitBucket repo name “EXAMPLE” will be written in capitals to signify that you should replace “EXAMPLE” with your repo name.
The code for the web-application
The web-app code has to have a specific structure. The “index.php” file must exist in side the “/public” directory such as “/var/wwww/html/www.example.com/EXAMPLE/public” because Apache (the web-server) is going to look there. If it can’t find an “index.php” file in that location, it will error.
We’re using Apache in this article. NginX is a little different with the “setfacl” command and the “vhost” file. You might like to read this article for more details about ACLs “http://www.agix.com.au/document-root-permissions-recommendations/”.
The Linux Distro
We’re running all of this on a CentOS 7 system. The it would be very similar on any Redhat-like system of version 6 and/or 7.
The Users and Groups
We’re going to create a POSIX “group” called “developers” and we’ll add any developer’s user accounts to that group. Members of that group will have write access to the “/var/wwww/html/www.example.com” directory and its sub-directories.
let’s get started!
First we create the group “developers” and a user “nige”. Nige is going to be able to SSH into the server, change to the appropriate directory and run “git” commands.
groupadd developers useradd -G developers nige
Now Apache. We’ll create the first part of the document root. We’ll ignore the “EXAMPLE/public” part for now. The “git clone” command that we’ll use later will create that for us:
mkdir -p /var/wwww/html/www.example.com/
Now set the ownership and permissions of the above directory. The “restorecon” command is there for SELinux. It shouldn’t be needed but get into the habit of running it on CentOS and Redhat systems.
chown apache.apache -R /var/wwww/html/www.example.com setfacl -R -b -m user:root:rwx -m d:user:root:rwx -m group:developers:rwx -m d:group:developers:rwx -m group:apache:rx -m d:user:apache:rx /var/www/html/example.com/ restorecon -rv /var/www/html/www.example.com/
Our “vhost” file looks like the following. We could either put this in “/etc/httpd/conf/httpd.conf” or in its own file in “/etc/httpd/conf.d/www.example.com.conf”.
<VirtualHost *:80> <Directory /var/www/html/www.example.com/EXAMPLE/public> AllowOverride All </Directory> RedirectMatch 404 /\.git ServerAdmin email@example.com DocumentRoot /var/www/html/www.example.com/EXAMPLE/public ServerName www.example.com ErrorLog logs/www.example.com-error_log CustomLog logs/www.example.com-access_log common </VirtualHost>
The above vhost will become active only after a “reload” or “restart” of Apache.
systemctl reload httpd
Next we need to login as the user “nige” and clone the Git repo into the new web-server document root.
ssh -l nige www.example.com cd /var/www/html/www.example.com/ git clone firstname.lastname@example.org:example/project.git
You will now have the directory path as follows where “/EXAMPLE/” is the Git repo name created by the “git clone” command above. The “/public” directory is part of the Git repo and not something we (the sysadmin) needs to create manually – the programmer created that earlier (before “pushing” to Git) and it’s where the “index.php” lives.
You can browse to your website now at “http://www.example.com”. You should see your website content assuming the paths are correct, the file/directory permissions and ownership are correct and the website is correct. Oh and the code-base has no errors. I’d suggest checking the Apache logs for errors.
tail -f /var/log/http/www.example.com-error_log*
From this point forward, given that you have already run “git clone” to get your code-base down from BitBucket, you can get the latest changes from BitBucket using “git pull” rather than “git clone”.
cd /var/www/html/www.example.com/ git pull
At this point you’re done.