Hosting git repositories on your VPS | Hacker News Reader

Hosting git repositories on your VPS

blog.heapsource.com

45 pointsrobermiranda22 comments

Today I’ll show you how to setup a gitolite installation on a VPS with Ubuntu 12.04 LTS. To save myself some typing I’ll be using the following conventions:

A command prefixed by sysadmin$ is meant to be run in your local workstation.

A command prefixed by user@vpshost:path# is meant to be run in the vps under the specified user on the specified path.

Open articleView on HN

This is pretty good. I wrote a similar article last year[1] that goes more in depth on things like automatic mirrors and various types of hooks. It was fairly well received on HN[2].

[1]: http://www.petekeen.com/hosting-private-git-repositories-wit...

[2]: https://news.ycombinator.com/item?id=4707747

I used gitolite on a VPS previously and it worked well, but when Bitbucket introduced free unlimited private repositories I switched.

IMO there is no reason to use gitolite now for unless you have (a) sensitive repos (with your own server, not a VPS of course), or (b) lots of private repos with lots of collaborators and you have no money for a Github or Bitbucket monthly fee and you aren't a non-profit (I think non-profits can get a free Bitbucket account).

That said, I'm interested to hear about other gitolite use cases I haven't thought of.

You can still use bitbucket on your own hardware with http://www.atlassian.com/software/stash/pricing

(Not affiliated with Atlassian/Bitbucket in any way - but I love their software)

Why was I not made aware of this sooner? $10 for 1-10 users? Nice. (also not affiliated)

They might share similar look-and-feel now but I think they are not the same thing, i.e. Python vs Java (Stash).

Totally. We use github for everything, but in this case, we are hosting a private repository since we need to trigger a compilation of code in a builder/worker of the cloud app we are developing. We modified the beginning of the post to clarify what our goal is by hosting privates repos with gitolite.

Couldn't you have done something similar with Github's web hooks? Something like have it ping the build server when a commit is made on master which pulls the code and builds? I'm just curious why the need to trigger builds jumped pushed you all the way to hosting it on your own.

There's also the issue of repository size; both BitBucket and GitHub have (entirely reasonable) fair use policies that seem to limit repos' sizes to 1GB or so. Yes, Git sucks with big files, but sometimes it's necessary to exceed this total size.

Im in the process of moving from self hosted (VPS) git server to Bitbucket as well. Github was just too expensive for me but when I discovered that Bitbucket was charging pr user instead of pr repo, switching was a no brainer.

We recently were at the same crossroads (choosing between "github" v/s "bitbucket" v/s own-hosted git repositories). I ran through the various options for own-hosted git repositories: (1) Gitlab, (2) Gitolite, and (3) Stash (10-user license for $10)

We ended up installing Stash as it seemed that it would reduce administration+maintenance by a tad bit (GUI + knowledgebase) and would be supported by a company responsible for bitbucket. Stash has been a pleasant experience so far.

You can also get paid support for GitLab from http://www.gitlab.com (disclosure: I work for GitLab.com).

Does anybody know if there is something to seamlessly encrypt a git repository in case I don't trust the git server provider (say a VPS)?

There's a solution with smudge/clean filters here: https://github.com/shadowhand/git-encrypt or a solution which acts as a git remote here: https://github.com/blake2-ppc/git-remote-gcrypt

Alternatively, you could just encrypt the directory that you push to remotely (probably /home/git in this tutorial), which seems like a cleaner solution: https://help.ubuntu.com/13.04/serverguide/ecryptfs.html

LUKS/dm-crypt. Super easy to use. https://wiki.archlinux.org/index.php/Dm-crypt_with_LUKS

The walkthrough is rather overwhelming.

Was it super easy to understand & set-up?

Yeah, the reality is it's about 3 additional commands to get going (over any other normal volume)...and a very short chef cookbook to automate it.

    # create a key file
    dd if=/dev/urandom of=/etc/mykeyfile.key bs=512 count=1
    # create the luks container
    cryptsetup luksFormat /dev/sdf1 /etc/mykeyfile.key
    # open the luks container
    cryptsetup luksOpen /dev/sdf1 myluksvolume --key-file /etc/mykeyfile.key
    # format the volume
    mkfs.xfs /dev/mapper/myluksvolume
    # mount the disk
    mount /dev/mapper/myluksvolume /mnt/mymountpoint

Any particular reason why most of the examples uses "sudo" while already logged in as root?

Additionally, either you have some strange prompts set up somewhere, or made a few typos when copying and pasting; a couple of places you appear to be logged in as a someuser@<...>, but with a hash-prompt(#) -- usually reserved for indicating root/super user access.

edit: Personally, I actually found the official documentation more helpful, even if it is very brief:

http://gitolite.com/gitolite/qi.html

In particular, it highlights that gitolite needs to run under a user, and needs a (your, the admin's) pubkey for setup -- but there's no need to generate a new one.

Behind the scenes, the pubkey used is added to the gitolite user's authorized_keys-file (and so is any other keys added, when users are added).

One other option to gitolite is SCM-Manager[1]. It's written in Java and can be deployed to an application server or installed as a standalone version.

I've used it for a year and I've been quite happy with it.

[1]: http://www.scm-manager.org/

A nice alternative to gitolite is gitosis[0]. I've found it much easier to use (in terms of adding users to repos) and faster to spin up new repos.

https://wiki.archlinux.org/index.php/Gitosis

Gitolite is actually better than Gitosis. With Gitolite, the owner of a repo can grant access privileges to that repo, it doesn't require the intervention of the Gitolite installation's administrator.

I've had some pushback on both of them from users because the command line fu necessary to use both of these projects is apparently just enough of a barrier that even developers find it annoying.

Gitlab is a bigger pain to administer and more resource-intensive, but much easier for users.

That's a good point. I'm normally the sole developer on projects, so I am my own Gitolite administrator.

Or, if you are a company and need some structure and ease of use, you can try contacting the guys at gitgear.com

Reply on news.ycombinator.com