Hello everyone, I got a gitlab from a client running a totally outdated 12.x version and with a miner running on it, to solve the problem I killed the miner, cut off internet access and generated a backup of gitlab and installed it in another instance. Due to being such an outdated version I had to upgrade from version to version and today I am at version 14.4.2, all installed using apt with the command: sudo apt-get install gitlab-ee=14.4.2-ee.0 removed from gitlab/gitlab-ee - Packages · packages.gitlab.com
Now to prevent the server from becoming completely out of date again, I would like to put a script to update packages via apt automatically 1x a week, as I do with clients without a contract, the problem is that when I do an apt-get upgrade --download-only , I see that gitlab tries to push version 14.5.0-ee.0.
I would like to know if there is any way I can make gitlab only deliver via apt upgrade only the 14.4.x family security packages and if I need it, I install 14.5.x and it only applies security updates!
I say this because in several new software we suffer from bugs that can impact the entire company and I would not like to leave without updating at all, as they have no infrastructure, gitlab will be 2 or 3 years without updates until another failure of security is discovered and another miner or something worse breaks in!
create a file called /etc/apt/preferences.d with the contents:
Package: gitlab
Pin: version 14.4.*
Pin-Priority: 1001
bear in mind though, that it won’t update to 14.5 until that file is edited or removed. This will also not help if any version is on 12.x and pushing a normal apt-get upgrade could get it to update to the latest 14.4.x without following the gitlab upgrade path. That could then break the install.
So a lot of that will only work, once you’ve upgraded all old instance to at least 14.3.x before pinning to 14.4.x so that it doesn’t go any higher. I don’t see a real benefit in doing that. I would just make sure the system is regularly updated, so that you never end up in a situation whereby it is behind far enough to cause issues. Updating once a week would be fine - I do that myself but manually. I don’t recommend scheduling automatic updates, since a problem with database migrations could break your install.
Also, even with something like this, I had an issue where mine got to 12.9.3 after updating it regularly, and wouldn’t go any further. I thought no updates had been released by gitlab, after about six months or so, decided to check the gitlab site and repo, and had to refresh by running the bash setup scripts for the repos, and only then did I see updates greated than 12.9.3. The only problem, now I had to follow the upgrade path. If I didn’t, pushing an automatic update would have broken my system.
Package: gitlab-ee
Pin: version 14.4.*
Pin-Priority: 1001
In this case, I’ll let the team know (if I’m not the one managing it), so that once a month or every 2 months, see which version is running and which is the newest and change this file. My fear is that a very new version, like 15.0.0 for example, where generally the possibility of bugs is greater, will be installed and will bring problems for the company.
Regarding the upgrade path, that’s what I had to do, going from 12.x to 14.4, going from version to version, because when I went from an older to a newer one, it broke gitlab.
But it’s that thing, not updating suffers from this problem, updating to a newer version and giving problems can stop the company in the same way, as I’m only providing the service to correct the gitlab problem, I’d rather sin for care than run the risk of someone updating and stopping everything.
There were compromised instances of gitlab that had processes running as the git user, which were cryptomining and causing all sorts of problems. So yeah, understand that upgrading can also introduce problems, but would be wise if not going to do regularly, to keep on top of any thing that appears like this. Users were created, snippets uploaded, which then compromised the server, giving them admin access, and allowing them to run processes which were cryptomining and overloading the server or causing it to kill the gitlab services.
I went through 80+ upgrades once bringing it up-to-date from 12.9.3 to 14.x so I tend to check once a week now. I have a test server on standby where I do the updates on it. I then check to make sure it works all OK, and if it does, then I repeat on the production server. That way if I break my test server, no problem. I don’t have anything on it as such, just a single repo, for testing push/pull etc, and general functionality. But it helps anyway to do that. You don’t need to host it anywhere, it can even run as a virtual machine on your laptop for example, and just power it on when you want to check/test upgrading and then shut it down again.
