I was crafting a post-checkout hook and wanted to do something depending on the absolute path of
$GIT_WORK_TREE in the current environment. In git 2.7.4 (and up to 2.4.14) at least, that environment variable was set to “.” when inside the post-checkout hook, which was a little unhelpful in this case. So I spent some time trying to google why and coming up empty.
Here’s where you’re entitled to laugh at my over-thinking this.
Since I’m in the work tree already (.) when inside the hook, the absolute path is the current working directory, or $PWD. No need to fiddle with GIT_WORK_TREE at all.
It’s been a painful month battling with this and I’m too tired to document everything thoroughly, so I’ll just throw this out there:
# "Note this config assumes unicorn is listening on default port 8080 and
# gitlab-workhorse is listening on port 8181."
Alias /lab "/opt/gitlab/embedded/service/gitlab-rails/public"
ErrorDocument 404 /404.html
ErrorDocument 422 /422.html
ErrorDocument 500 /500.html
ErrorDocument 502 /502.html
ErrorDocument 503 /503.html
RequestHeader set X-Forwarded-Proto https
Header set Strict-Transport-Security: "max-age=15768000;includeSubdomains"
That one disabled line (
#DirectoryIndex disabled) was required (uncommented) when I used the
RewriteRules version of the recipe, otherwise it was 404 whenever logging in.
You also obviously need to either out-comment “
Include conf-available/geoblock-non-fi.conf” or add your own geoblocking rules in the file it references.
I spent the last few days online trying to get Mattermost working on my home server. It looks like a promising replacement for Slack, very polished and professional and the installation process is well documented. The only twist was that, since I’m already running Apache on the server, I figured I’d set it up to also function as a proxy for Mattermost. (The developers apparently favor nginx, whereas documenting usage with Apache rests on the community.)
Everything seemed to go smoothly, and the web app worked just fine when called locally. But when I tried to access it using my FQDN, it just kept failing with the “We’re having trouble connecting to Mattermost” page staring me bluntly. I’ve lost count how many times I’ve hit refresh only to see that page again and again.
This was only halfway towards the solution, I still spent hours tearing my hair out until I finally figured out the root of the problem: my home router doesn’t do NAT loopback.
After I pointed my FQDN to the home server in my desktop’s hosts file, the static JS came through in Firefox just as easily as it had in Chrome. (I shudder to think what it is that Chrome does that made it able to circumvent the problem.)
Now, I did try to access Mattermost from outside my home network previously, but being utterly disorganized in my debugging, I apparently had mangled the Apache configuration for the site each time I did those tests. With both the correct Apache configuration and the local hosts file fix in place, the FQDN works from inside the home LAN as well as from outside.