Install and Configure Gitlab and Website on Apache Server in Your VPS

This article first appeared on the Chigisoft blog.

GitLab, like GitHub is an online repository that allows developers to create, store and manage their projects with the ability to roll back to an earlier state if an error is encountered. To use the online repository, no setup is required, just register an account and start creating projects.

My company decided to move our projects and repositories to an online VPS, we chose DigitalOcean Ubuntu Linux droplets which is easy to set up and also Gitlab offline server to store our project files. Digital Ocean has an already packaged droplet (omnibus-gitlab-droplet) that sets up the gitlab server for you without stress but we also want to use the same droplet to host some of our projects.

The gitlab server uses nginx as its default server, while our projects use apache server to serve contents. Running two internal servers simultaneously can pose a lot of issues (ports … etc). I will be sharing how I was able to set up the gitlab server and also set up the other project server using apache server (My preferred server, don’t we all have our preferences…).

Step 1:

First, I created the droplet using the digital ocean omnibus-gitlab-droplet but I got to discover that any DNS(Domain name server) that connects to the droplets redirects to the github installation which is not what I wanted. After searching for several days without a solution, I decided to destroy the droplet and install it manually by myself. Below are the commands I used to install gitlab manually using ubuntu Linux commands:

sudo apt-get install curl openssh-server ca-certificates postfix
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo apt-get install gitlab-ce

These commands installed the gitlab server on our VPS successfully.

Step 2:

I had to configure the URL to be used in accessing the gitlab server by editing the gitlab configuration file using this command:

sudo nano /etc/gitlab/gitlab.rb

Edit the configuration file by changing the external url to your desired url:

external_url “http://<yourdomain>”

Save your configuration and run this command:

sudo gitlab-ctl reconfigure

to reconfigure your gitlab installation. Your Gitlab installation should be working fine, visit the url specified to access your gitlab and log in using username root and password 5iveL!fe

Step 3:

Now we have a working gitlab server but we want it to run using the apache server so we can host other kinds of stuff (websites, apps etc) on the same droplet. We’ll go ahead to install the apache server and configure the gitlab to run from it.

Install the Apache server using:

sudo apt-get update
sudo apt-get install apache2

sudo a2enmod proxy_http
sudo a2enmod rewrite
sudo a2enmod ssl
sudo a2enmod headers
sudo service apache2 restart

These install and start the apache server. To check if the apache server is running use :

sudo systemctl status apache2

which should show active (running).

Let’s configure our gitlab server to use the apache server instead of the default nginx server.

Add the following to our gitlab configuration file (/etc/gitlab/gitlab.rb):

external_url “http://<yourdomain>”
# Disable nginx
nginx[‘enable’] = false
# Give apache user privileges to listen to GitLab
web_server[‘external_users’] = [‘www-data’]

Save the file, then go ahead to create the gitlab apache config file in the apache sites-available folder.

Copy and paste the following to the file:

<VirtualHost *:80> ServerName <your_domain_or_sub_domain>
ServerSignature Off

ProxyPreserveHost On
AllowEncodedSlashes NoDecode

<Location />
Require all granted

ProxyPassReverse http://127.0.0.1:8080
ProxyPassReverse <your_domain_or_sub_domain>
</Location>

RewriteEngine on
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule .* http://127.0.0.1:8080%{REQUEST_URI} [P,QSA]

# needed for downloading attachments
DocumentRoot /opt/gitlab/embedded/service/gitlab-rails/public

#Set up apache error documents, if back end goes down (i.e. 503 error) then a maintenance/deploy page is thrown up.
ErrorDocument 404 /404.html
ErrorDocument 422 /422.html
ErrorDocument 500 /500.html
ErrorDocument 503 /deploy.html

LogFormat “%{X-Forwarded-For}i %l %u %t \”%r\” %>s %b” common_forwarded
ErrorLog /var/log/httpd/logs/<your_domain_or_sub_domain>_error.log
CustomLog /var/log/httpd/logs/<your_domain_or_sub_domain>_forwarded.log common_forwarded
CustomLog /var/log/httpd/logs/<your_domain_or_sub_domain>_access.log combined env=!dontlog
CustomLog /var/log/httpd/logs/<your_domain_or_sub_domain>.log combined

</VirtualHost>

Save the file and enable the gitlab site by enabling the config using:

#Enable gitlab
sudo a2ensite gitlab#Restart apache
sudo service apache2 restart#Reconfigure gitlab
sudo gitlab-ctl reconfigure#Restart gitlab server
sudo gitlab-ctl restart

We are done setting up our Gitlab to run from apache server, now check the URL again to see a working gitlab.

To verify that our droplets can hold multiple sites, let’s add another site

Before we create the apache configuration for the new site, We will create the folder to hold the site content:

#Create directory for new site
sudo mkdir -p /var/www/new_site/public_html#Allow regular users to modify files in the directory
sudo chown -R $USER:$USER /var/www/new_site/public_html#Allow general read access to our web directory
sudo chmod -R 755 /var/www

Create a new configuration file for the new site by duplicating the /etc/apache2/sites-available/000-default.conf and renaming it to /etc/apache2/sites-available/new_site.conf, then edit the file:

<VirtualHost *:80>
ServerName <site-domain>
ServerAlias <site-domain>
ServerAdmin <site-admin-email>
DocumentRoot /var/www/new_site/public_html #Folder directory created earlier
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

After saving our conf, We can then enable our new site and restart apache to reflect the changes:

sudo a2ensite new_site.conf
sudo service apache2 restart

Let’s ensure our DNS (Domain Name Servers) have been configured to point to our droplet IP.

You can now test your URLs in our browser. Voila!!! it’s working!!!, if we encountered any error, we’ll go through our configurations to ensure everything was well configured.

Gitlab Admin Login Details:

In case you forgot your default root login details

If you’re like me after configuring your Gitlab server on Digital Ocean droplet and you forgot you default username and password, don’t cry too much, there is a solution:

sudo gitlab-rails console or sudo gitlab-rake rails console

This command takes you to the gitlab rails console

user = User.find_by(email: ‘admin@local.host’) or user = User.find(1)

This command searches for the default user and activates it. to change the password, run:

user.password = ‘secret_pass’ followed by user.password_confirmation = ‘secret_pass’ then user.save

After changing the password, type “quit” to quit the rails console. Log into your Gitlab root account using the new password. Ensure you change it once you have access to the gitlab dashboard.

Configure Push and Pull on Server Repositories:

Though our users can register and create projects on the Gitlab server, no one is allowed to pull or push to it. It returns a 500 error.

To solve this error, let’s add the following lines to our Gitlab config (/etc/gitlab/gitlab.rb):

…….
gitlab_workhorse[‘enable’] = true
gitlab_workhorse[‘listen_network’] = “tcp”
gitlab_workhorse[‘listen_addr’] = “localhost:8282”
…….

After saving the config file, reconfigure the Gitlab server using:

sudo gitlab-ctl reconfigure

Add this rewrite rule just after the RewriteEngine On:

……
RewriteEngine On
RewriteRule /[-\/\w\.]+\.git\/ http://127.0.0.1:8282%{REQUEST_URI} [P,QSA,L]
…….

We’ll save our config file and restart our apache server:

sudo service apache2 restart

Let’s try to pull again. Voila!!! It worked.

We have fully setup our Gitlab server that can allow us pull and push data to our repositories.

Proceed to configure https on the new gitlab server.

Will be updated in a follow-up article.