I personally never heard of Git prior to looking at the Drupal CMS. If you do know Git, skip this paragraph, but if you know nothing like I did, then read on. Git was created by the founding father of the Linux operating system; Linus Torvalds. The Git website tells their own story, but you might not care about that. What you probably do care about is the undo key if you were working on a big group project. Git has the ability to store your whole revision history of that group project with notes about who did what and when they did it. When something breaks you wonder things like, when was it last working correctly, and what changed since then, and who did that, and why. If you use Git properly, all those important facts are at the ready. Rolling back the bad changes will be no problem if you're using Git. I surmise from listening to podcasts (mentioned in the next section) that the Drupal Community is solely in it for managing their software code base. But, suppose your PhD Thesis was a product formed by a group of collaborators writing a single finished document? Daa-dan-na, Git to the rescue! It doesn't care that you're doing revision history on a book for human eyeball reading, it just cares about keeping track of the difference between a moment ago and now. Their's so many possible uses for Git, but for the purposes of this tutorial, it's about the code. Suppose you have a server die on you, and the back-up isn't restoring the way you thought it would... Well, if you had been pushing your website up to any Git repository, one pull—or maybe better—clone command would have that website restored and working in no time. Suppose you have radical cool ideas for your website, but you are afraid to try them cause it might wreck something; if it ain't broke don't fix it. Well, you can use the Git repository to make a clone of your website where you experiment and get things right before you commit the changes to the production web-server.
Putting the Git program on any computer is easy, it might already be on yours by default. That's not what were doing here. We're making a server that can store your code base in a private way. Were making a place for repositories to be safely held. If you have no need for privacy and/or you want your code base to be opensource, their's plenty of free space on the web for you to put your stuff like GitHub. If you want a secure private repository that you control and a handy web interface for it then read on, I'm showing you how I did it below.
I don't know if GitLab is the only free opensource web interface to the Git software system, but it's the only one I know about today. If I'm wrong, sorry. GitLab does for Git what Webmin does for Linux. I have not found GitLab-CE an easy thing to install+run, in fact I have botched an installation for GitLab in the past and while uninstalling it I screwed up my entire server. I'm blaming my trust of outdated blogs for the failure to install and get it to work correctly. I'm also blaming my own impetuous rush to uninstall it and everything it touched. I have had other less catastrophic failures trying to install and run it. I'm not sure where I got the "how-to" when I devastatingly loused it all up, but these are the sources I'm following this time:
- A guide for simple install and run
- Guides for Secure setup install and run
I like the How To Forge the best, but it assumes an NGINX web-server, but I only want to run Apache on my main stack; a.k.a. the machine depicted in all the other videos and text of this site. While trying to get the GitLab to work on my current server, I had my Apache system go sideways a bit on me, so you will read about an installation of GitLab done on another internal server that doesn't have remote access on the web at this time. When it comes to security it doesn't get more private than that, so I will be skipping any/all SSL portions found in any of the other instructions.
First I do a minimalist server install like the one I've shown in Install Your Distro to Build Your Base Server, but skip the LAMP option in the Ubuntu server install procedure and omit the entire Webmin install shown after that. During initial server set-up I only select the
standard system utilities, and
OpenSSH server packages. After that finishes, I prepare the platform for GitLab using a command line interface.
At about 5:07 in the video I indicate that GitLab preferred NGINX. That is a false statement. GitLab doesn't need Apache or NGINX.
Here's what you do to prepare the platform on that minimalist server install
In a Terminal execute the following to prepare for GitLab:
ssh<root user name>
@<localhost machine name>e.g.
Start here if you have an American Power Conversion—Uninterruptible Power Supply:
sudo apt-get -y install apcupsd
sudo cp /etc/apcupsd/apcupsd.conf /etc/apcupsd/apcupsd.conf.bak
- Edit the following file according to your needs (see also)
sudo pico /etc/apcupsd/apcupsd.conf
sudo cp /etc/default/apcupsd /etc/default/apcupsd.bak
sudo pico /etc/default/apcupsd
- alter the file like this
- alter the file like this
sudo systemctl start apcupsd
sudo apcaccess status, never works for me until after reboot
sudo systemctl stop apcupsd
sudo apt-get install apcupsd-cgi
sudo cp /usr/lib/cgi-bin/apcupsd/*.cgi /etc/apcupsd/
Start here if you don't have a Uninterruptible Power Supply
sudo apt-get update
sudo apt-get upgrade
sudo apt update
sudo apt upgrade
Now you install GitLab
You MOST LIKELY already have these if you made an updated Ubuntu 16.04 server, but GitLab needs them. The worst you'll see if you run the command is that the most recent version is already installed.
sudo apt install curl openssh-server ca-certificates
curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo apt-get install gitlab-ce, You'll wait a while after that one. Make a keen observation after it finishes of what URL it tells you to use for logging into your newly installed server. Mine was wrong! It ended my machine name with
.verizon.netwhich would work but is awful. Earlier, my Ubuntu install also guessed wrong and appended
.verizon.netto the machine name to guess a FQDN during setup, but you should have edited that out if it happened to you.
sudo pico /etc/gitlab/gitlab.rb
external_url 'http://<your servers proper machine name>
sudo gitlab-ctl reconfigure(rerun this command EVERY TIME you edit the
At this point you may be able to load the GitLab URL (e.g. http://aGitLabThing). Wonderful for you if it does.
All the trouble I had in the past was because I didn't know how to make GitLab friendly with a web-server like Apache or NGINX. It seems like GitLab was designed to work with any of the set-up's but I don't want to find out how. It was easier to just not install NGINX or any LAMP stack.
- If you can't build an outward facing "plain-vanilla" server dedicated to just your GitLab software, my instructions are for you.
- If you can build the outward facing machine, follow the How To Forge source I linked at the top and if you have any trouble loading that startup page, try having the web-server turned off permanently before installing and re-configuring GitLab.