Turn your DiskStation into a self-hosted Git server

One of the things I almost instantly wanted to do after purchasing my DiskStation was to use it as a private Git server. I thought I was in luck when I saw that Synology offers a DSM package for Git, but it turned out this is too basic for my taste.
The good thing is, since I now have HTTPS accessible Tomcat running on my DiskStation I can easily install and run GitBlit. So let’s turn our DiskStation into a private, HTTPS accessible, collaboration friendly Git server!

The Motivation

You might ask yourself: “Why not just use Synolog’s Git Package for DSM?”
Well, if you are the only one interacting with your repositories, you are fine with ssh accessing your DiskStation every time you want to create a new repository and like to create shared, bare repositories manually on the command line, feel free to do so. The best guide I could find for that is this one.
However, I did not like this solution for several reasons.
I do want to collaborate on my repositories and I do want to be able to do so without creating full DSM accounts for every collaborator.
I do want to have a GUI both for creating and managing access to my repositories instead of ssh accessing my DiskStation, manually creating the repository and fiddle with file and folder permissions.

My Way to go

So I started to look around and found there are several solutions out there. If you are interested you can check out this comparison of self-hosted web-based Git repository managers. Although GitLab looks like a really good and very popular choice I decided otherwise. Main reason being that the documented installation methods did not really spark any hope that I could get this to run on my DiskStation.

GitBlit however looked like an easy deployment of the GitBlit WAR file to Tomcat. It also offers all the features I was looking for. It provides me with a GUI to create repositories and manage access to them. This way my repositories are both private and accessible.

So now that you know why I chose GitBlit, read on to see how I managed to set it up and run it on my DiskStation.
If you want to follow along, make sure you have Tomcat 7 already running on your DiskStation. In my last post I described how to use a Let’s Encrypt certificate to enable HTTPS for your Tomcat server and linked to a guide I partially used to setup Tomcat on the DiskStation, so make sure to check it out.

Set up GitBlit

Obviously the first thing you want to do is to download the latest GitBlit WAR file from the official website.
At this point you could just drop this WAR file into the Tomcat folder on your DiskStation, wait a few seconds for Tomcat to finish the deployment and access GitBlit by URL, which should look something like this (assuming you followed my last post):
https://yourDomain:8443/gitblit

However there are a few tweaks that will ensure that all your repositories and settings will be persistent across GitBlit redeploys and updates and that all features are working properly.

First thing is to set a custom GitBlit baseFolder as Tomcat Context to externalize GitBlit data from its deployment path both for safety and persistence across updates and redeploys as described in the GitBlit WAR installation and setup guide.
So access your DiksStation through ssh as root and edit Tomcat’s context.xml file. You can use vi to edit the file. The command should be similar to this one:
vi /volume1/@appstore/Tomcat/src/conf/context.xml
Inside context.xml file you insert an Environment node within the Context node that looks like this:
<Environment name="baseFolder" type="java.lang.String" value="/volume1/@appstore/gitblit" />
If you deploy the GitBlit WAR now, all the configuration files and repositories will go inside the baseFolder you just specified.

To ensure all GitBlit generated URLs will work you need to do three things. First add org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true to CATALINA_OPTS. To accomplish this I edited the setenv.sh file located in /volume1/@appstore/Tomcat7/src/bin/. Add the following line to it:
CATALINA_OPTS=-Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true
Second ensure your Tomcat connector configuration uses the UTF-8 encoding (which it does if you followed my last post).
Check the GitBlit FAQ for these two steps.
Third add web.canonicalName to gitblit.Properties – which you can find in the baseFolder you specified earlier – and set it to the URL you use to access GitBlit.

It is noteworthy that GitBlit comes with a tickets feature, which is analogous to GitHub/BitBucket Issues+Pull Requests. However this feature is disabled by default and the main reason is that you must choose the persistence backend to use for the tickets.
You can choose between persisting to files, branch or to a Redis data store. Check out the documentation to make an informed decision. I decided to use the branch ticket service, so I added the following line to gitblit.properties:
tickets.service = com.gitblit.tickets.BranchTicketService

At this point I thought I was done, but when starting GitBlit and looking at the Tomcat log I noticed that GitBlit failed to start its git and ssh daemon on my DiskStation, because the ports were already in use.
If this is the case for you too, You can easily fix this by adding the settings git.daemonPort and git.sshPort to your gitblit.Properties file inside your basefolder and provide non-default port numbers, to allow GitBlit to run these services.
Don’t forget to setup port forwarding and an according firewall rule for the configured git.sshPort to allow usage of the ssh protocol for interaction with your repositories.

Now you are finally done! After restarting Tomcat (e.g. with the DSM Package Center) the new settings for Tomcat and GitBlit are applied and you can access your very own GitBlit server using an URL like https://yourDomain:8443/gitblit.  It is available through HTTPS, just like your Tomcat server is, without the need to configure anything HTTPS related in GitBlit itself.
GitBlit will now produce working URLs to interact with your repositories and store everything safely in the defined baseFolder. In my case this is /volume1/@appstore/gitblit, which is persistent even across DSM updates, so there won’t be anything gone missing after you update GitBlit or your DiskStation’s DSM version.

So log in with  the default administrator credentials admin / admin and change your admin password, create repositories, set their access policy, create users for collaborators, grant them access to specific repositories and enjoy all of this on your very own self-hosted Git server!

The icing on the cake

In case you plan to deploy further applications on Tomcat, I ask you: Wouldn’t it be nice if you could use the same credentials instead of creating a new user for every application you deploy?
By default GitBlit uses a simple users.conf file to store user information inside its baseFolder. But If you want to take this a little step further, instead of using GitBlit’s own users.conf file you can configure GitBlit to use the LDAP authentication provider and thus connect GitBlit to a directory server to handle user authentication. What lucky coincidence that Synology’s Package Center offers a Directory Server package, right?

So I hope this was interesting to you and recommend you check back for my next post to find out how to setup Synology Directory Server and connect GitBlit to it!

10 thoughts on “Turn your DiskStation into a self-hosted Git server”

  1. Hi again 🙂
    So, one month after your installation, are you still happy about GitBlit ? I was planning to install Gitlab, but it is packaged only with Docker (2 containers, one for GitLab and the other for Redis) and I found many problems (Ruby memory leaks are this biggest one). So, I have few questions for you ^^ how much memory take your GitBlit process ?
    Also, I installed Git Server with ssh keys, all is working fine. I would like to keep going like this but, if users want, they could also use an IHM. Is your installation of GitLib working like that ? (cause GitLab don’t, it encapsulate everything inside the Docker container)

    1. Hi again =)
      I am actually very happy with GitBlit. It offers the features I was looking for, works reliably and is configurable to suite my needs (using the ticket service, connecting to LDAP for centralized user management across GitBlit and Jenkins, etc.).

      However I am using it only with repositories that I created with GitBlit.
      But you might be able to configure GitBlit to work with your existing repositories, too. That is what the configuration option “git.repositoriesFolder” is for. You can have a look at the documentation here: http://gitblit.com/properties.html

      For the question about memory usage:
      I am not sure how to check Gitblit’s individual memory consumption, since I run it inside Tomcat.
      Here are the memory values for Tomcat running both GitBlit and Jenkins:
      Free memory: 54.48 MB Total memory: 168.25 MB

      Hope this helps.

      1. Your configuration sounds great ! So you have GitBlit and Jenkins on your Tomcat ? I really think I will do the same, but maybe with BitBucket (dont know it but seems good and free up to 5 users) Even if I would be glad to learn Docker, I think using it on Syno is not a good a idea.^^

        1. Well thanks, I am quite happy with this setup =)

          Since Synology’s Docker package is not available for my DS214play, Gitblit was the next best, easy to install option.
          I have no idea how to get GitLab oder BitBucket up and running on a DiskStation without using Docker containers.

  2. Please fix your email parameters so people can be alerted when you post / answer comment 😉 (and dont see this ugly error after posting a comment :D)

    1. I’m not sure what you mean by “fix your email parameters”.
      When I check the “Notify me of new comments via email” checkbox I do get an E-Mail asking me to confirm the subscription.

      For the error that appears after submitting a comment: I don’t know what causes the error and thus I have no idea how to fix it. I opened a support ticket (https://wordpress.org/support/topic/jetpack-comments-box-error-on-submission?replies=2), but have no replies yet. The Jetpack staff is not available until next Monday, so I wasn’t able to contact them directly to get help.

      If you know this error and how to fix it, please let me know, too.

      1. Oh sorry, your email subscription works now ! For your comment problem, did you try to reinstall jetpack ? Or maybe you installed another plugin recently which come in conflict. I will check again the error message with this post and tell you if I find something 🙂

        1. Glad to hear email subs is working for you, too.
          I did disconnect and reconnect Jetpack and also deactivated all plugins except Jetpack. All of this had no effect and the error was always the same. Completely uninstalling and reinstalling Jetpack is on my todo list for the weekend =)

          Thank you for your feedback and help, much appreciated.

          1. Your error :
            Erreur d’analyse XML : entité non définie
            Emplacement : https://melo.myds.me/wordpress/wp-comments-post.php?for=jetpack
            Numéro de ligne 6, Colonne 26 :Submitting Comment & hellip ;
            (I put space around ‘hellip’ word in order to post the comment otherwise it fails)

            So, it seems the problem is the HTML entity hellip, equivalent to “…”. I think you just have to find and supress this special characater :
            – check in wp-comments-post.php and all your comments template part php files
            – check your .po file if you use internationalization
            Since this character is collapse with “Submitting Comment” I think the easiest way is to grep all your files for searching theses words 🙂

            I don’t think it is in the database, but if these solutions above don’t work you will maybe have to search in DB.

Leave a Reply