Please select Ubuntu 16.04, if it’s possible, as the server os, for both the servers. I’m using this. I’ll try to write the steps as os agnostic as possible and shall try to give proper links to install for other distributions.
And of-course put the domain/sub-domain name you are going to use as the name of the server. It’s required.
This is the second part of the series to configure a source control hosting. This post contains only installation steps. If you need any push to motivate youself to do this, you may find the first part helpful.
Here is the first part, regarding choice of hosting and some inspiration.
I’ve used the Omnibus package for installation. Found this as most convenient one. And I’ve seen that, it’s possible to tweak all the services installed by this package. You can also opt for installation of individual components of GitLab. You can find lot of options here.
Before we start the installation, we need to log into the system by SSH and update our system. If you’re using any version of Linux or Mac, you have your terminal and the command
ssh is available. For Windows use Putty. More details.
# first update the registry
Internet Siteduring Postfix installation
It may happen that, your server provider has blocked the SMTP port by default. Check if mails are going from the server.
sudo apt-get install mailutils
If not, configure the mail server properly. It’ll be needed by GitLab.
But before executing the command
gitlab-ctl reconfigure, we have to do something to configure this server with SSL.
Please don’t use the server with IP. Use a domain name with SSL. It’ll give a level of security inside the network layer. More details.
Theoretically you can use a IP for your server hostname. But, if you are configuring a git server for yourself. Give it a name. Even a subdomain like
subdomain.domain.tld looks good. And there are lots of providers selling cheap ssl certificates. Get one of them. I’ve seen Comodo Positive SSL’s are the cheapest ones and will show a green lock in the address bar of the browser.
It’s also possible to use self-signed certificate. But that will show a red lock with cross in the address bar. Main difference will be the
.crt certificate we are going to use for the server. To configure SSL for an HTTP server we need one
.key and corresponding
.crt file. Details about private keys and csr’s are described here. To summerize, for self issued certificate, first generate a private key and a
# replace the domain with a name you like
If you’ve bought a SSL certificate from a provider like Comodo, you need one
.csr file to upload to the site to issue a
domain validated certificate.
openssl req \
.csr file to the site and after validation/completion of the required steps you can download a
.zip file containing either two files like
domain.crt and something like
domain-bundle.crt or 4 files, such as
COMODORSADomainValidationSecureServerCA.crt. This is the case of Comodo Positive SSL. If you find it otherwise, please consider your SSL issuer’s document about this.
Either way, you need to concatenate all the
.crt files into one.
# if you've two .crt files
To configure your server with the domain name you decided, you have to register the domain name and point the domain to the server or you can use sub-domain of an existing domain. For subdomain create just one CNAME. Here you can find some details. Open the generic steps. Use the name you decided for the subdomain as the alias.
To use a root domain like
domain.tld, you need to create one A-record and one CNAME record. Here, you can read about various record types for DNS, here is one guide to add A-record and here, you will get the details regarding how to point your domain to your server. For that you need to know the IP of the server. Either get it from the mail, you got after buying the server or server provider’s control panel or by the following method, if you are logged into your server by ssh.
# icanhazip is a free service for ip lookup
We are in the last phase of configuration of our GitLab server. Open the file
/etc/gitlab/gitlab.rb and add/modify some lines in it. Replace the
sudo gitlab-ctl reconfigure. It’ll take some time, depending on the speed of the server. And, if everything goes ok, we should be able to open GitLab client in the browser at
https://domain.tld, with a green lock of SSL.
First the browser will be redirected to set the password of the initial administrator account
root. Set the password and log into the dashboard by entering the username
root and the password you’ve just set. Click on the small range icon to the right hand side of the top bar and then click on the settings icon to left. There you’ll find lot of options to customize. Probably you need to stop the public Sign-up first and use two-factor authentication.
Your server is set-up. Now we have to configure our CI. This is pretty straight forward.
ssl.crt to the server, intended for the CI. SSH into this server.
sudo apt-get update
Create a new project. Configure
.gitlab-ci.yml and enjoy build at every push. Don’t forget to add one badge to the
README, will come in the format,
Happy coding. Try to live in your own terms. :-)