A couple of weeks ago, I wanted to share a repository with somebody else on the globe, without sharing it with the rest of the universe. So I figured I'd just create a Github private repository, and share that. But then I found I just ran out of permissions for more private repositories. Still, I need to share my code. Eventually I decided to temporarily take some of my existing private repositories out, and use the freed up space for having another temporary private repository.

This obviously stinks. When I started thinking about it a little more, I realised I'm actually sometimes deliberately holding off pushing something to a git server because of fear that I'm running out of private repositories. That's not good either. I have time machine and Arq backups of most of my system, but not for my local git repositories. As a consequence, all of that data is just sitting there, on my hard drive, waiting to get lost.

The easy solution would be to just to get a better Github plan. And I have been considering that. But then again, for which plan should I settle? Twelve? Twenty? It's harde to tell.

You do however want to think about it for a minute, since going from a Micro to a Small plan (7 additional private repos) is costing you another $60 a year.

Which actually would have been fine, if my need to have private repositories really was to make sure that somebody else is doing all the work to have backups, if I really wanted to share my data with many other people (but not the universe), if I really wanted all of the tools Github is offering.

But I don't. In most cases, I don't need that. I just want my data to be moderately safe. I don't want to pay for number of private repositories, I want to pay for the data that I'm storing in private repositories (which really isn't all that much in most cases.)

This is what typically happens. Whenever I have an idea, I will first write it down in my little black book of ideas. When that idea has been fermenting there for a while, and I have some time, I'll start playing around with some code. That code might be the start of something beautiful and huge. But in reality most projects stay never get there.

However, meanwhile, I don't want to loose what I have been writing. And I also don't want to share my ideas with the rest of the world – just yet.

WD My Cloud

Half a year ago, I needed another backup solution. It would be nice if it would have time machine support, but it would be even better if it would also have a bunch of other things. Ideally, it would be like a personal Dropbox.

That's actually one of the ways Western Digital's My Cloud is aspiring to be. And from the reviews, it seemed it was pretty easy to get it to work.

(Truth told: if you really want your personal Dropbox service, you might want to search a little further. My Cloud definitely is not offering you the same experience as Dropbox.)

And when I read that it even featured git support, I was sold. I got the pricey, huge, mirroring My Cloud Mirror. It worked pretty good for the things installed by default, but it didn't work all that great for git. In fact, the web site advertised that git support was something you could install through its web interface, but that option definitely did not exist for the version I had.

Only after I contacted customer support, I was able to upgrade my system and install git. I expected a web page allowing me to set some configuration options and create repositories. In reality, it didn't offer any of that. There is a configure button. It doesn't take you anywhere.

Git on My Cloud

Once I found out that this was just way more work than I expected, I gave up. Until today. I again had another repository I wanted to keep somewhere safe, and again noticed that I started looking around to see if I could delete one of my existing private repositories. This time, I couldn't live with myself anymore and just decided to fix it.

So here's what I did to get it working. Note that it assumes that you already have the app installed, which is something you can do through the web console.

Step 1: Create a folder for all your repositories

Ssh to your My Cloud instance (in my case called cloudy). The password is something you need to set in the web console.

ssh sshd@cloudy
cd /usr/share
mkdir git

Step 2: Create a git user

Note that you will be asked to enter a password. Make sure to hold on to that password. (Although we will replace it with key based authentication later on.)

useradd -m -d /usr/share/git git

Step 3: Allow ssh access for the git user

While still logged in as the admin (sshd) user, find the /etc/ssh/sshd_config file, and add add the git user to the AllowUsers key:

AllowUsers root sshd git

After that, you need to make sure the SSH daemon rereads its configuration data again. This is how I do it:

pkill -HUP sshd

Step 4: Ssh folder permissions

Go in to the /usr/share/git repository and fix the permissions:

cd /usr/share/git
chown go-w .
mkdir ./.ssh
touch ./.ssh/authorized_keys
chown -R git .
chmod 600 ./.ssh/authorized_keys
chmod 700 ./.ssh

Step 5: Add your public ssh key to the authorized_keys file

Just copy your public key, which is probably in ~/.ssh/id_rsa.pub on your local computer, and add it to the authorized_keys file on your My Cloud instance.

With these changes, you should now be able to logout from your current SSH session, and login using your new git user, without having to pass a password:

ssh git@cloudy

Step 6: Create a bare repository

Suppose that I have a local git repository (created with git init) and I want to make sure it can be pushed to a server as well, then you need to make sure that repository exists on the server. Assuming that you have an SSH session using the git user, and that you're in the /usr/share/git directory:

git init --bare test.git

Step 7: Add the repository you just created as a new remote to your local repository

In your local git repository, type the following command:

git remote add origin git@cloudy:/usr/share/git/test.git

If all went well, then you should now be able to to push your local changes to the remote repository:

git push origin master

Troubleshooting SSH

If you run into trouble while following the previous steps, there's a fair chance it has to do with file permissions. SSH is pretty picky on your permissions, and it's not always easy to figure out what's going on.

Unfortunately, your My Cloud instance doesn't have logging enabled for its sshd service. (Well, it is enabled, but there's no syslog configuration telling it where to go.)

In order to fix that, ssh into your My Cloud as the admin user (sshd), and add the following line to your /etc/syslog.conf file:

auth,authpriv.*                 /var/log/auth.log

Then restart the syslogd service:

pkill -HUP syslogd

To get more information on what's going on in your sshd service, add the following line to your /etc/ssh/sshd_config file:

LogLevel VERBOSE

… and restart the sshd service, just like you were doing it before:

pkill -HUP sshd

Now, you should be able to get some meaningful information from /var/log/auth.log.

An open letter to Western Digital

So I got it working. But it took me quite a while. I would be really really really nice if Western Digital would have done that work for me. I'm sure I'm not the only one who got this device to host a git repository.

Also, adding a new repository still allows me to ssh into the My Cloud instance and make some changes there manually. Not a huge problem, but it would have been really nice if the git support package would include a Github clone, such as Gogs, to have the ability to do all of that from the console.