debsums -c daily, hoping to catch file corruption and/or other abnormalities early. (The Debian package even provides a pre-made cronjob for this task.)
debsums -c gitlab-ce reports
.gitlab_kas_secret as deviating from the provided md5sum.
Steps to reproduce
- apt install gitlab-ce
- vi /etc/gitlab/gitlab.rb # set external URL
- gitlab-ctl reconfigure
- debsums -c gitlab-ce
What is the current bug behavior?
# debsums -c gitlab-ce
What is the expected correct behavior?
# debsums -c gitlab-ce
Details of package version
Provide the package version installation details
ii gitlab-ce 14.5.1-ce.0 amd64 GitLab Community Edition (including NGINX, Postgres, Redis)
- Operating System: Ubuntu 20.04
- Installation Target, remove incorrect values:
- Installation Type, remove incorrect values:
- Is there any other software running on the machine: plenty
- Is this a single or multiple node installation? single
Provide the relevant sections of `/etc/gitlab/gitlab.rb`
#2635 is basically the same, but I’ve never seen debsums complain about
@ohoral All right, I’ve now rebased, and then regenerated the .pot again. I didn’t know whether you want the commits squashed, so I left them as separate.
Okay, I’ve added that file now. I actually did install GDK to update the .pot file previously, but this last file I added here in the web IDE again.
@asubramanian1 Sure, I take it I’ll need to install GDK for that? I don’t have it set up yet, as I just edited the commit above here in the web UI.
This fixes a typo in the 2FA settings: ”an one time” -> ”a one time”
All right, looks like this is VSCode issue #37762 (and MD5 usage is #99760).
$ md5sum --quiet -c /var/lib/dpkg/info/codium.md5sums
md5sum: WARNING: 2 computed checksums did NOT match
$ apt-cache policy codium
*** 1.51.1-1605141118 500
500 https://paulcarroty.gitlab.io/vscodium-deb-rpm-repo/debs vscodium/main amd64 Packages
The git-annex page has a removal warning at the top (introduced here). It currently says ”Warning: GitLab has completely removed in GitLab 9.0 (2017/03/22).”
My guess is it’s actually supposed to say ”Git annex support has been completely removed in GitLab 9.0 (2017/03/22).”
If the services run under the ’git’ user, why is it that adding the ’git’ user to the ’redis’ group (with access to the socket) isn’t enough to give it access to the socket? Sorry if this is a dumb question.
With Gitlab 9.5.4-ce.0 and Apache 2.4.18, I had to set `DirectoryIndex disabled` for the Gitlab directory (in the vhost configuration) to fix this when using RewriteRules. (I’ve now switched to using ProxyPass instead.)