Get Git To Work On Your Synology

Git logo I'm the proud owner of a Synology Disk Station. Not only does it serve all of my files and stream all my media throughout the house with ease, it can also be used as a git server.

I had never used a version management system before. After all I have always worked alone on my projects, so why should I? Version control systems didn't even exist way back when I started programming. Lately however, I've seen the light and started using git for all of my projects.
The real power of git will be released if you have a git server which can hold all of your project repositories, which enables you to check out your work on any computer. On top of that it is way easier to make proper backups of your hard work if all of it is stored in a central place. That's when I decided to install the git server on my Synology Disk Station.

What A Disappointment

Most of the things you do on your Disk Station are so very simple. Even someone with just the bare minimum of computer knowledge can set it up and get to work with it. Not with git server you can't.
After installing it the usual way from within the package center, nothing particular has seemed to have happened. You'll be looking in vain for any GUI to get going with git. The only thing you can do is select the users who are allowed to use git. That's all.
If you open the online help and search for git you'll get a little bit further. But there are still quite some blanks to be filled in. Searching the internet provided me with bits and pieces of information, but never the complete picture.
I hope to get you going with the basics in a few small steps. Mind you, this page is not intended to be a git tutorial. I will only show you how to set up the git server and how to push and pull your work to and from the Disk Station. A good source to learn all there is to know about git is http://git-scm.com/book". It contains no long stories. It's right to the point. Exactly the way I like it.

Setting Up The Git Server

After installing the git server from the Synology package center you are presented with a screen asking you which users are allowed to use the git server. It's obvious what to do here. What is less obvious is what happens if you do so.

Git users GUI

The selected users will be able to ssh into the Synology Disk Station, a privilege which is normally only granted to the root or admin user. However a git user will only have limited shell access, powered by the so called git-shell (/var/packages/Git/target/bin/git-shell).
The git-shell allows you to do all git related things over ssh. Well not quite. It does work for normal pushing and pulling of your work. However in order to set up a new repository you'll need the help from the root or admin user again, which is at best awkward and dangerous at the worst.
And you'll have to enter your password each time you want to push or pull some project. There is no way to setup an ssh key pair to automate this process, because the git-shell is too limited to do so.

So let's change that. Let's allow the git user(s) to log in with a real shell, instead of the limited git-shell. True, such a user can do more than just use git. Which obviously is a bit less secure. But such a user can do far less harm than the root user could. And above all, I'm the only git user on my Disk Station, so what the heck.

You'll need ssh login to be enabled in order to be able to use the git server at all, so you'll have to enable that too. I can't remember if it is enabled automatically by installing the git server. So check if ssh is enabled in the control panel under Terminal & SNMP.

Enable ssh

Next you'll have to enable the homes directory on the Disk Station. You can find that setting in the control panel under User - Advanced. Tick the Enable user home service box and select the volume which should hold the homes directory (if you have more than one volume of course).

Enable user home directories

After that you may have to change some permissions to make the ssh server to accept and store public keys. I can't remember that I had to do that, but some feedback has reached me about the necessity to change these permissions.
Use ssh to login to your normal or git user account on the Synology. Linux and Mac users use the terminal to do so. Windows users can use the program Putty to do this. Then you can cd to your home directory. Within this directory you should be able to find a hidden directory called .ssh . Use the following commands to set the permissions right for the .ssh directory and the file authorized_keys within that directory.

chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Setting up a homes directory allows you to store ssh keys, which will allow the git user(s) to login to the system without the use of passwords. And it will allow the git user to have a place to land after log in. Otherwise an error message would be shown, warning you that the home directory doesn't exist every time the git user logs in.

Now we're going to login as root to the ssh shell on your Disk Station. I have received some feedback that you may not be able to login to your Diskstation as root. In that case you can login as admin and use the command sudo su - to become root.

Log in to ssh on your Disk Station as root:

ssh root@<ipofmysynology>

Enter your admin password (which will remain invisible). Then type the next commands:

cp /etc/passwd /etc/passwd.backup
vi /etc/passwd

The first command makes a backup copy of the passwd file, in case you mess up. If you do mess it up you can restore the backup copy. But be sure to do that BEFORE you log off. Chances are that you can't login any more if that file is corrupted.
By the way the passwd file does not store passwords, just in case you were wondering. It does hold user information, but no passwords.

The second line above will open up the users file in a text editor. Unfortunately vi is not an easy text editor for the Linux novice. So I'll explain what you'll have to do to make the necessary changes.
But first I'll explain what needs to be done.

Find the line which looks like the one below for each git user:

john:x:1030:100:John Doe:/var/services/homes/john:/var/packages/Git/target/bin/git-shell

And change it into:

john:x:1030:100:John Doe:/var/services/homes/john:/bin/ash

It goes without saying that the user name (john) and the full name (John Doe) will actually be your name.

This modification will give the git user a normal shell instead of the git-shell, allowing him/her to create new repositories without the help of the root user. And it will create the ability to use passwordless login using key pairs.

Using the text editor vi in a nutshell

While you're working in vi it is very easy to mess up your text completely. As a novice it is not very easy to correct your mistakes. And soon you'll get from bad to worse. So it is good to know how to quit vi without saving the messed up text.
No matter how bad you mess up your text, if you quit without saving no harm is done to the original file.

To quit vi without saving press the next keys in succession (not the blanks):

ESC ESC : q !

And you're back at the prompt, with your file unchanged. Then you can try again, without the mistakes this time.

While you are in vi locate the line you want to change. Use the cursor keys to move to that line and place your cursor on the v of the second var (the one from /var/packages/Git.....). With your cursor on that character type the capital letter D. This will delete rest of line from the current cursor position.
Then type the letter a (the append command). Then type the text bin/ash after which the line should look like the example above.

If you need to change more lines (in case you have more than one git user), press ESC before using the cursor keys to move to the next line you want to change.

When you're done and have checked your work, press the next keys in succession in order to save your work and quit vi (not the blanks):

ESC ESC : w q

And you should be back at the prompt again. Double check your work with:

cat /etc/passwd

If you see errors (unintentional line breaks for instance) fix them before you log off, otherwise you may not be able to log in again.

It's a good idea to try to log in to ssh on your Disk Station as root user from another terminal after you've made the changes to make sure you didn't break anything. If you can't log in any more, use the first terminal, which is still logged in as root, and copy your backup file back over the damaged file and start all over again. Use the next command only if you want to restore the passwd file to its original state:

cp /etc/passwd.backup /etc/passwd

If everything is OK you can log off as root and log in as the git user, which should now be possible. If that all works we're almost ready.

Setting up passwordless login

Now all that's left to be done to finish the setup is to enable passwordless login, if you want that. If you're comfortable with entering your password every time you want to use your git repositories you can skip this part.
Passwordless login uses a key pair to authenticate the user. The private key is stored on the computer you use to log in from to your Disk Station. The public key is stored on the Disk Station. If those two match up, you are allowed to log in. Otherwise you are rejected.
You'll have to repeat these steps for every computer you want to connect to your Disk Station.

On your computer terminal (when you're not logged in to the Disk Station), type the next command (not for Windows users):

ls ~/.ssh

If you see at least one of the next pairs of files you already have a public/private key pair installed on your computer:

id_rsa and id_rsa.pub
id_dsa and id_dsa.pub

Only if you don't see one of those pairs you'll have to generate a brand new key pair by entering the next command:

ssh-keygen

You may have to press enter a couple of times when the program prompts you for information. I personally leave the pass phrase empty for machines on my home network.
A pass phrase is not the same as a password. The pass phrase is used to encrypt the key pairs, so a stranger still can't log in even if he/she has a stolen copy of the key pairs.

So you'll have a working key pair now. Let's copy the public one to the Disk Station now:

ssh-copy-id gituser@<ipofmysynology>

You'll have to enter the git user's password one last time now. After that you can login to the ssh shell of your Disk Station without it:

ssh gituser@<ipofmysynology>

Better still if the gituser is the same name as the user you are logged in to on your own computer you can even omit the gituser@ part of the login.

So far the description of the setup. Now let's get to work with our freshly installed and properly configured git server.

Working With The Git Server

By now you know how to set up the git server properly. So now it's time to learn how to use it. Before you can use it you'll have to install git on your computer too. That is usually a matter of installing the proper package. Be sure to setup the global variables like user name and email address after installing git. These settings will be used to identify the person who made the commits.

Create A New Repository

Log in to ssh as a git user on your Disk Station and change directory to your git directory as in the example below:

ssh gituser@<ipofmysynology>
cd /volume1/sharename/git

You can add some directories here in order to organize your repositories. You may have separate directories for your web site(s), your C code, your assembly code, your Python code, your shell scripts..... You name it, it's your party.

After you've set them up and changed in to the appropriate category directory you type the next commands to create a brand new empty repository:

mkdir example
cd example
git init --bare --shared

That's all there is to (g)it. You may log off from your Disk Station if you wish, for there is no more to be done here for now. Unless you wish to create more repositories of course.

Clone Your Empty Repository

Making a clone of the freshly created repository you simply type the following commnad on your computer:

git clone gituser@<ipofmysynology>:/volume1/sharename/git/category/example

You'll get a warning telling you that you've cloned an empty repository, but we know that already. Now you can start filling the project directory on your computer with your project files. Make some commits, which will remain local on your computer, until you're ready to push everything back to the git server again.

Push Your Work Back To The Server

After you have been working on your project on your computer for a while and have committed your changes, maybe even a couple of times, you may come to a moment when it's about bed time. Usually it is way past bed time in my case. This is a good moment to push your work to the server.

Here's how you do that for the first time:

git push gituser@<ipofmysynology>:/volume1/sharename/git/category/example origin master

Really, that's all there's to it. If you have set up the git server as described above you don't even have to enter your password! All subsequent pushes can be even shorter, there you don't have to include origin master anymore. So all subsequent pushes will look like this:

git push gituser@<ipofmysynology>:/volume1/sharename/git/category/example

Let's see if you've done it right. If you don't see any errors after the push command you might as well trust git to have done it's job correctly. However, since it's the first time we did this, we want to double check if we have done everything correctly.
Create an empty working directory on you computer somewhere. Change in to that directory and execute the git clone command from above again to get all your files magically to appear in this newly made directory.

A Small Tip Regarding IPv6 Addresses

I had some problems connecting to my Git server from the internet over IPv6. It worked, as long as I entered a domain name. However using a plain IPv6 address instead of a domain name wouldn't work. I have tried enclosing the IP address in square brackets, adding or removing the trailing colon, quoting the IPv6 address and I don't know what else I've tried. Google usually is my friend in such an occasion, but not this time.
Fortunately I managed to find a solution to the problem. The code below does the trick:

git pull ssh://user@2001:9:2:1:2:3:f:8/volume1/sharename/git/example

Basically it comes down to adding ssh:// in front of the URL and omitting the colon between IPv6 address and path on the server.