Month: September 2017

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"

<Directory /opt/gitlab/embedded/service/gitlab-rails/public>
    Include conf-available/geoblock-non-fi.conf
    
    Options -MultiViews
    #DirectoryIndex disabled
</Directory>

<Location /lab>
    Include conf-available/geoblock-non-fi.conf
    
    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"

    ProxyPass "http://127.0.0.1:8181/lab"
    ProxyPassReverse "http://127.0.0.1:8181/lab"
</Location>

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.

Today I had a breakthrough when I realized that a statically served JavaScript file was failing to load, and bizarrelly only in Firefox: when I finally fired up Chrome out of desperation, everything was working just fine. With Firefox, or with wget for that matter, trying to load the JS file directly only resulted in loading a fraction of the file, or not at all.

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.