Summary
Since installing 21.0-20241023-nightly, apps on my tablet can no longer access Internet when Wireguard is connected. This worked just fine right up until 20241023-nightly, and Wireguard’s app hasn’t been updated in over a year, so I’m pretty sure it’s the new build.
Looks like it’s DNS. (It’s always DNS.) There are a couple of conspicuously related-looking commits in this build: 406071 (VPN-covered DNS traffic may not fall through) and 406070 (Revert ”Prevent DNS traffic from bypassing lockdown VPNs”).
Expected Behavior
Apps should be able to connect to the Internet even when Wireguard is connected.
Current Behavior
Apps lose access to Internet immediately when Wireguard is connected. Curiously, Chrome is unaffected; all other apps that I’ve tested are affected, including Firefox, which says ”Address not found”, hinting at DNS.
Steps to Reproduce
- Install Wireguard
- Set up a connection that doesn’t route all traffic but just that interface’s address space. I’m including a screenshot of my Wireguard configuration below.
- Toggle the Wireguard interface on.
- Open Firefox and try to browse the web.
Device information
/codename gts4lvwifi /version 21 /date 2024-10-23 /kernel 4.9.337-g16026dfb9b4c #1 Wed Oct 23 13:53:22 UTC 2024 /baseband none /mods Google Apps
I have read the directions
Summary
I’m running 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
/opt/gitlab/embedded/service/gitlab-rails/.gitlab_kas_secret
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)
Environment details
- 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
Configuration details
Provide the relevant sections of `/etc/gitlab/gitlab.rb`
external_url 'http://localhost'
Related issues
#2635 is basically the same, but I’ve never seen debsums complain about schema.rb.
@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
usr/share/applications/codium-url-handler.desktop: FAILED
usr/share/applications/codium.desktop: FAILED
md5sum: WARNING: 2 computed checksums did NOT match
$ apt-cache policy codium
codium:
Installed: 1.51.1-1605141118
Candidate: 1.51.1-1605141118
Version table:
*** 1.51.1-1605141118 500
500 https://paulcarroty.gitlab.io/vscodium-deb-rpm-repo/debs vscodium/main amd64 Packages
100 /var/lib/dpkg/status
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.
