I installed GitLab CE using the Omnibus package on a new CentOS 6 server. Since I had nothing else on the server at that time, everything GitLab setup and configured was sufficient. Later, however, I wanted to setup additional sites on the server using Apache, but now port 80 was already bound to by GitLab’s built-in Nginx web server.
What I really wanted to do is disable the built-in Nginx server and just use my self-managed Apache installation. Here’s how to do just that.
A component of the server migration I’m currently working on is to move all of the existing virtual host files. Unfortunately, they’re not all consistently setup, which makes them difficult to overview, and from past experience, difficult to manage.
There is also no easy way to tell which of them represent real sites, and which are purely for redirection. Some even have a document root, implying there may actually be a site there, but often I found only a single
.htaccess file that redirected the domain to another site.
In a previous blog post, I proposed several guidelines to effectively manage virtual host files going forward, and one aspect of that, which I’ll talk about more deeply in this blog post, is how to organize and manage the redirects in bulk.
I’m in the midst of building new servers, inventorying the existing ones, and creating a migration plan to move over anything that needs to make it over. This is the perfect time to look at the big picture and assess whether everything is implemented in the best way possible.
One of the items I’m reviewing are the virtual host files, and let me tell you, they’re a mess.
The permissions are all over the place, there doesn’t seem to be a clear naming convention, some virtual host files are purely redirects, and there are so many includes containing additional rules and rewrites, that according to the error logs, they’ve started stepping on each other’s toes (“Request exceeded the limit of 10 internal redirects due to probable configuration error”).
To get a site feature from development to production, it goes through four servers:
- Quality Assurance (QA)
Except for the development server, which is localhost, there are times people, other than developers, need access to view a particular site on the QA or staging server. In addition, sometimes you need to test your site externally, whether it’d be a mobile device not connected to the network or an external, automated service. This means that the aforementioned servers need to be publicly accessible, but without being accessible to just anyone.
I use Git as a version control and deployment system. When a website gets pushed to a server, all files get pulled into the web root (i.e.
htdocs) by a user named git executing
git pull in the post-receive hook.
By default, all files and folders git creates have 664 and 775 permissions, respectively, and are owned by that user. 664 translates to the user and group being able to read and write, and everyone else only being able to read, and 775 translates to the user and group being able to read, write and execute, and everyone else only being able to read and execute. (That’s a mouthful!)
-rw-rw-r-- 1 git git 30 Aug 15 23:04 test-file.txt
drwxrwxr-x 1 git git 102 Aug 15 23:04 test-directory
Now, in an instance where you need a folder in
htdocs writable by another user, like apache, for let’s say a caching system, you need to be able to set those particular permissions accordingly.
To accomplish this, you really only have two options:
- Set permissions of files to 666 and folders to 777
- Set the owner or group to apache (or a group that apache is a member of)
Personally, I favor restrictive permissions over convenience, so option #1 is out, which means we’re going to take a look at how to implement option #2.