Our system is redhat6, the current gitlab version is 11.11.3, and I want to upgrade to the secure version 13.10.x, but only el7 is supported after 13.7, can we still install version 13.10 on el6?
1 Like
Its unsupported platform. That is why no newer versions exist for el6. So not possible. To upgrade to newer versions you will need to upgrade el6 to el7 or migrate your gitlab to a new installation on el7 or higher.
2 Likes
As @iwalker pointed out, GitLab no longer builds packages for RedHat/CentOS 6.
RHEL 6 reached end of life in November 2020, meaning that no updates or patches will be released for this operating system. Once an operating system reaches EoL, GitLab also stops building new packages for that OS.
More details can be found here:
https://docs.gitlab.com/omnibus/package-information/deprecated_os.html
@gitlab-greg @iwalker Thanks for the reply, I have one more question. The server upgrade is not a simple matter. If we continue to use the 11.11.3 version and do not upgrade the gitlab, will there be serious security problems?
@betty_zheng from a quick google: Gitlab Gitlab version 11.11.3 : Security vulnerabilities
there are a number of CVE’s for security vulnerabilities, with scores between 3.5 and 5.0. So moderate risks. If the system is accessible externally, then you would really want to be making upgrades to ensure that nobody that can gain access can exploit the system. If this server is only accessible internally, then the risks aren’t as great, but it would still be possible for an internal employee to exploit or for a compromised computer to take advantage and exploit it. So you would want to weigh up the risks on this.
I personally would upgrade, but as with all upgrades, especially considering the operating system, you have to ensure you have backup/recovery procedures in the event that it fails. Online upgrade from EL6 to EL7 is possible, and the upgrade process would let you know before starting if it sees any issues that need to be rectified before continuing. Hopefully the impact of these issues would be minimal so that the upgrade could easily be achieved.
Unfortunately, I don’t have such system, I used DEB based systems, but I do know RHEL products and use them. It would take me a couple of hours to do a test upgrade without data to check/verify some points, but that would only be unique to my system, as your server could be configured differently and have different packages installed that I might not have. So even that wouldn’t be an ideal way to confirm whether the upgrade would work for you or not without completely replicating your setup identically.
That’s also not including the fact that EL6 is no longer supported by RHEL, etc, so there will also be security risks for the operating system packages, as well as the CVE’s I mentioned that only related to Gitlab itself.
The security patch package update of gitlab is very fast, unless the upgrade has been followed from the beginning, but obviously this is impossible. Considering that each version is to solve some vulnerabilities, can we consider upgrading to the highest version supported by el6 to avoid certain risks? Unfortunately, our current attempt to upgrade from 12.0.12 to 12.10.x has encountered many thorny issues, which have not been resolved for the time being.
You can certainly upgrade to the highest possible version that EL6 supports, to mitigate security risks. Also ensure EL6 is on it’s highest version which is 6.10.
Your upgrade path:
11.11.8 -> 12.0.12 -> 12.1.17 -> 12.10.14 -> 13.0.14 -> 13.1.11 -> latest 13.Y.Z
so from 11.11.3, you need to upgrade to 11.11.8 and then to each of the releases mentioned thereafter, to minimise downtime as well as problems. Also make sure that after each upgrade completes, that you check that background migrations have finished. There is a command in the upgrade docs that explains how to do this. The background migrations must be at zero before continuing the next upgrade. Perhaps this is why problems were experienced previously, or maybe an upgrade version was skipped that had certain migrations.
You mentioned 12.0.2 to 12.10.x, but you must go to 12.1.17 before attempting 12.10.14. So make sure to follow the upgrade path, and it should be fine. Also make sure your server meets the minimum requirements of 4 cpu and recommended 8gb of ram.
1 Like
@iwalker Why is 6.10 necessary? If we stay at 6.7, will there be any impact?
From a security point of view, if your system is accessible externally, operating system updates should be made as well as the application that runs on it - in this instance Gitlab. There are plenty of security fixes and package updates from 6.7 to 6.10. But the choice is yours dependent on the risks you wish to take.
Thanks for the guidance. Our system can only be accessed internally, and the system upgrade needs to be rebuilt. This risk cannot be estimated, so we still consider upgrading gitlab under the current version.
Hi @betty_zheng ,
To ensure you have the latest security patches and updates, I suggest running the latest version of GitLab and a Linux distribution that is receiving security updates and patches.
For your situation, I think a good path forward would be to:
- Create new VM or machine running RHEL 7 or CentOS 7
- Install GitLab 11.11.3 package on the RHEL 7 server
curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh | sudo bash
sudo EXTERNAL_URL="http(s)://<your_external_url>" yum install gitlab-ee-11.11.3-ee.0.el7
- Backup GitLab and config/secrets files on RHEL 6 server running GitLab 11.11.3
- Copy backups and config files to new RHEL 7 server
- Restore GitLab backup to RHEL 7 server
This should get your GitLab and GitLab data onto a RHEL 7 server, which will get new GitLab builds and OS security updates/patches through June 2024.
1 Like
Note that what @gitlab-greg isn’t mentioning explicitly is that GitLab only supports restoring backups made on the same version of GitLab, so you need to do as his procedure says, and install GitLab 11.11.3 on the new server.
After the procedure described, you can (and should) upgrade GitLab on the new server to 13.11.2, following the upgrade path @iwalker gave.
As @grove pointed out, you’ll need to install 11.11.3 on the new server this to work. Backups can only be restored if the GitLab version matches between backup/restore. Make sure to include the version number when installing on a new machine (yum install gitlab-ee-11.11.3-ee.0.el7)