I am getting missing “Release file” in gitlab-ee repository when tried to update dependencies, would really appreciate for any workaround suggestions. Thanks.
alternatively, instead of running as a standard user, you can do this:
sudo su -
curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | bash
which would then run as the root user - note that now I don’t use sudo at all.
I have just tested this at my end, and this is the result:
root@ufo-build:/home/ian# curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | bash
Detected operating system as Ubuntu/focal.
Checking for curl...
Detected curl...
Checking for gpg...
Detected gpg...
Running apt-get update... done.
Installing apt-transport-https... done.
Installing /etc/apt/sources.list.d/gitlab_gitlab-ee.list...done.
Importing packagecloud gpg key... done.
Running apt-get update... done.
The repository is setup! You can now install packages.
root@ufo-build:/home/ian# apt-get clean all
root@ufo-build:/home/ian# apt-get update
Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease
Hit:2 http://archive.ubuntu.com/ubuntu focal-security InRelease
Hit:3 http://archive.ubuntu.com/ubuntu focal-updates InRelease
Get:4 https://packages.gitlab.com/gitlab/gitlab-ee/ubuntu focal InRelease [23.4 kB]
Get:5 https://packages.gitlab.com/gitlab/gitlab-ee/ubuntu focal/main amd64 Packages [23.3 kB]
Fetched 46.7 kB in 2s (22.6 kB/s)
Reading package lists... Done
root@ufo-build:/home/ian# aptitude search gitlab-ee
p gitlab-ee
as you can see, the repository works, which means there is something wrong with the way you are running the commands on your machine, or the problem is your server itself not downloading the correct information correctly, since the repository shows an error when running the update command. Could be a network problem, configuration problem with the network/DNS for your machine, or something like this. I cannot replicate your problem.
curl | sh commands are always a bad idea, curl | sudo sh are always a very bad idea.
You have no control over what curl fetches from the net (the server might return different contents to different people and based on user-agent) and executes on your machine. Always fetch the script, read it, and execute the copy you now have locally.
@grove agreed, I generally quote and post what the Gitlab documentation says - perhaps would be better for the docs to use curl to output the script to a local file, or just use wget instead with the url. Then review the script and afterwards chmod +x scriptname to then be able to run it or bash scriptname.
Step 1 — Installing the Dependencies
Before we can install GitLab itself, it is important to install some of the software that it leverages during installation and on an ongoing basis. Fortunately, all of the required software can be easily installed from Ubuntu’s default package repositories.
Since this is our first time using apt during this session, we can refresh the local package index and then install the dependencies by typing:
sudo apt update
sudo apt install ca-certificates curl openssh-server postfix
You will likely have some of this software installed already. For the postfix installation, select Internet Site when prompted. On the next screen, enter your server’s domain name to configure how the system will send mail.
Step 2 — Installing GitLab
Now that the dependencies are in place, we can install GitLab itself. This is a straightforward process that leverages an installation script to configure your system with the GitLab repositories.
Move into the /tmp directory and then download the installation script:
less /tmp/script.deb.sh
Once you are satisfied with the safety of the script, run the installer:
sudo bash /tmp/script.deb.sh
The script will set up your server to use the GitLab maintained repositories. This lets you manage GitLab with the same package management tools you use for your other system packages. Once this is complete, you can install the actual GitLab application with apt:
sudo apt install gitlab-ce
This will install the necessary components on your system.
Step 3 — Adjusting the Firewall Rules
Before you configure GitLab, you will need to ensure that your firewall rules are permissive enough to allow web traffic. If you followed the guide linked in the prerequisites, you will have a ufw firewall enabled.
View the current status of your active firewall by typing:
OpenSSH ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
As you can see, the current rules allow SSH traffic through, but access to other services is restricted. Since GitLab is a web application, we should allow HTTP access. Because we will be taking advantage of GitLab’s ability to request and enable a free TLS/SSL certificate from Let’s Encrypt, let’s also allow HTTPS access.
The protocol to port mapping for HTTP and HTTPS are available in the /etc/services file, so we can allow that traffic in by name. If you didn’t already have OpenSSH traffic enabled, you should allow that traffic now too:
sudo ufw allow http
sudo ufw allow https
sudo ufw allow OpenSSH
Check the ufw status again; you should see access configured to at least these two services:
sudo ufw status
Output
Status: active
To Action From
OpenSSH ALLOW Anywhere
80/tcp ALLOW Anywhere
443/tcp ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)
443/tcp (v6) ALLOW Anywhere (v6)
The above output indicates that the GitLab web interface will be accessible once we configure the application.
Step 4 — Editing the GitLab Configuration File
Before you can use the application, you need to update the configuration file and run a reconfiguration command. First, open Gitlab’s configuration file:
sudo nano /etc/gitlab/gitlab.rb
Near the top is the external_url configuration line. Update it to match your domain. Change http to https so that GitLab will automatically redirect users to the site protected by the Let’s Encrypt certificate:
/etc/gitlab/gitlab.rb
##! For more details on configuring external_url see:
##! Configuration options for the GitLab Linux package | GitLab
external_url ‘https://example.com’
Next, look for the letsencrypt[‘contact_emails’] setting. This setting defines a list of email addresses that the Let’s Encrypt project can use to contact you if there are problems with your domain. It’s a good idea to uncomment and fill this out so that you will know of any issues:
/etc/gitlab/gitlab.rb
letsencrypt[‘contact_emails’] = [‘sammy@example.com’]
Save and close the file. Run the following command to reconfigure Gitlab:
sudo gitlab-ctl reconfigure
This will initialize GitLab using the information it can find about your server. This is a completely automated process, so you will not have to answer any prompts. The process will also configure a Let’s Encrypt certificate for your domain.
Step 5 — Performing Initial Configuration Through the Web Interface
With GitLab running and access permitted, we can perform some initial configuration of the application through the web interface.
Note: Because these credentials might be present in your log files in plain text,
it is highly recommended to reset the password following Reset a user's password | GitLab.
OR USE:
$ sudo gitlab-rake “gitlab:password:reset”