Change Gitlab homepage using Apache’s mod_rewrite

For some time I have been looking for a way to share public projects easily using GitLab. With the Public Project option of GitLab this was already possible for some time, but it did not work quite as I would like to (i.e. I would like http://gitlab.mydomain.tld to be the URL for all public projects). Due to the way GitLab is setup, the default URL will redirect the user to the login page, which does provide a link to the Public Projects page, but was not quite what I want.

Of course, as GitLab is open source, I could change the code directly, but as I would have to do that after each upgrade of GitLab (which is monthly!) I did not want to do that. Today I found a way around changing the code by using the following mod_rewrite rules to my Apache configuration (I placed this in the <VirtualHost> configuration but should also work from a .htaccess file):

# Redirect /users/sign_in to /public unless it has a local refferer
# This makes the public projects page the homepage instead of the login page
RewriteCond   %{HTTP_HOST}@@%{HTTP_REFERER}    !^([^@]*)@@https?://1/
RewriteRule   ^/users/sign_in$                 https://%{SERVER_NAME}/public/          [R,L]

This is inspired by a blog post on referer checking from the Apache .htaccess file. To get to this solution I just had to realize that an internal redirect by the application clears the referrer and apply the opposite logic to intervene when this happened (no referrer implies a redirect, when the user clicks on a link the request will have a referrer). How this works is:

  1. The user visits http://gitlab.mydomain.tld/
  2. GitLab redirects this request to its sign_in page
  3. The browser requests the sign_in page, as this was a redirected page the referrer will be empty
  4. The above mod_rewrite rule kicks in and redirects the user to the public projects page

For me this setup works as I expect. The only caveats are that users with browsers setup not to provide a referrer (e.g. for privacy reasons) may no longer be able to login and that a direct link to the sign_in page won’t work (the user will be redirected to the public projects page and has to click the sign_in button). For my setup both are no issue, let me know through the comments if there are other issues or perhaps solutions for this.

Login issues after upgrade to GitLab 6.5

I have been playing around with Gitlab, the open-source self-hosted Github clone for a while now. I plan to use it to publish the scripts and small programs I did over the last few years and will still create later this year.

After the upgrade to Gitlab version 6.5.1 (which was a breeze BTW thanks to their excellent upgrade script) I noticed I could no longer login. to the server. In the logfile log/production I found messages like:

Started POST "/users/sign_in" for 2001:XXX:XXXX:X:XXX:XXXX:XXXX:XXXX at 2014-02-02 13:53:46 +0100
Processing by Devise::SessionsController#create as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"XXXXXXXXXXXXXXXXX", "user"=>{"login"=>"XXXXXXX", "password"=>"[FILTERED]", "remember_me"=>"0"}}
Can't verify CSRF token authenticity
Redirected to https://gitlab.mydomain.tld/
Completed 302 Found in 123ms (ActiveRecord: 7.3ms)
Started GET "/" for 2001:XXX:XXXX:X:XXX:XXXX:XXXX:XXXX at 2014-02-02 13:53:46 +0100
Processing by DashboardController#show as HTML
Completed 401 Unauthorized in 1ms
Started GET "/users/sign_in" for 2001:XXX:XXXX:X:XXX:XXXX:XXXX:XXXX at 2014-02-02 13:53:46 +0100

 
This turned out to be a known issue with the installation of Gitlab. Since Gitlab is only supports NGinX while I am running it on Apache, I needed to dig a bit further for the solution. The problem was caused by a security enhancement in Gitlab 6.5 in combination with HTTPS. Since the SSL processing is handled by Apache, which uses mod_proxy to connect to GitLab only using HTTP, cookies no longer worked properly. The solution was pretty simple, it required the following statement to be added to the Apache Virtual Host configuration:

RequestHeader set X_FORWARDED_PROTO 'https'

Please note that this does require mod_headers to be enabled, if this is not enabled, issue to following two commands to enable it:

sudo a2enmod headers
sudo /etc/init.d/apache2 restart

Factory reset after firmware upgrade of TP-Link SG3424

Since about a year I have a TP-Link SG3424, a manageable 24-ports gigabit switch that so far has proven to be table and reliable and was a good deal when I bought it compared to similar devices. It’s not a Cisco switch, but honestly I do not know what I am missing out on given the feature set is has. So far it covered my needs and has been operational without any noticable issues or hiccups. The only drawback (for me) so far was that it lacked IPv6 support, but that’s optional on an internal network anyway.

Today I noticed that TP-Link released a new firmware version in December for the SG-3424 switch that added IPv6 support and is available from their support site’s download page. I followed the installation guide, which was completely correct, but a bit incomplete as I had a few surprises during my upgrade:

  1. The installation manual instructs you to change your network settings to the 192.168.0.X network. As I have an operational environment using another IP range, I happily ignored this and was able to perform the upgrade. However, after the upgrade, I could no longer reach my switch until I changed the IP address of my laptop to the 192.168.0.X network. This is not an issue for someone that knows what he is doing, but should have been mentioned in the installation manual in my opinion…
  2. After the firmware update, the switch was back at its factory settings and lost all configuration settings (including the logins, so I had to login with admin/admin again). This is bad TP-Link, even if your update process requires a full reset, PUT IT IN THE UPGRADE MANUAL at least…
    Fortunately I have a tendency to make backups before I change things and did create a backup before the update , but it was a surprise one would not expect.
  3. When restoring the configuration, all settings were restored correctly EXCEPT the logins and password of the admin user. Again, not a blocker, but a surprise and something NOT DOCUMENTED.

All in all minor things that one can resolve pretty easily, but not something you would expect from a company that positions the product at the professional market… Cisco-like 10+ upgrade guides are a pain to get through, but a 2-pager with only half of the information doesn’t help either.

Apart from these glitches, the upgrade was worthwile as the switch now has IPv6 support, which functions great and has (as always) all features one can imagine (like being able to add manual addresses next to the auto-negotiation addresses, support for RA and DHCP6, support for IPv6 on all services like SSH and SNMP) appear to work fine.