Archive for August, 2009

Gitosis – easy git security

August 30th, 2009

OK so maybe it’s time I write something useful.

Gitosis:

  • Pros: A fantastic program which simplifies the task of securely hosting git repositories.
  • Cons: It doesn’t do read-only unsecured shares

Getting Gitosis

There are gitosis packages for mos major distros but I haven’t had much luck getting them to work, best to get the latest source:
git clone git://eagain.net/gitosis.git
cd gitosis
python setup.py install

Don’t forget to install python setuptools.

Preparing the System

Now you have to set up a user for gitosis to run as.  The hosted repos will be stored in this user’s home dir, so choose wisely.  On my system I did
sudo adduser \
--system \
--shell /bin/sh \
--gecos 'git version control' \
--group \
--disabled-password \
--home /home/git \
git

Now, every user who interacts with Gitosis will need an SSH key.  Check ~/.ssh, if you’ve got id_rsa.pub in there you’re good otherwise generate one by
ssh-keygen -t rsa
Now to initialize a gitosis instance for your created user with your personal user authorised to administer. Copy your public key to /tmp (so you don’t have permission problems later on) then
sudo -H -u git gitosis-init < /tmp/id_rsa.pub
Now comes the sweet bit of Gitosis – administration isn’t actually done on the server, all gitosis hosting configuration is itself hosted by gitosis. On your personal machine then, clone the admin repository
git clone git@YOUR_SERVER_HOSTNAME:gitosis-admin.git
cd gitosis-admin

Now the administration workflow is

  1. Edit gitosis-admin/gitosis.conf
  2. Add user’s public keys to gitosis-admin/keydir
  3. git add keydir/*
  4. git commit -a -m 'Describe your changes'
  5. git push

Creating a new Repo

OK so now you’re set up and authorised for administration, sweet.  Let’s set up our first repository.  Open gitosis-admin/gitosis.conf and add a section like
[group groupname]
members = usernames
writable = new-repo

Where of course group names should be descriptive, new-repo is the name of, you guessed it, your repository and usernames is a space-separated list of fully qualified usernames allowed to write. That is, “user1@somecomp user2@anothercomp” etc.

Save this and exit.  If there are users other than yourself in the list, copy their keys to gitosis-admin/keydir.  The keyfile filenames should be the fully qualified username with a .pub extension, eg user1@somecomp.pub.

Add and commit any changes and push them back to the server like
git add keydir/*
git commit -a -m 'Added new-repo with users user1, user2'
git push

And that’s the configuration done. Now you of course need to give the repo content. We’re going to make the repo locally and push it up, so

cd ~/code/my-repo
git init
#make some changes, commit
git remote add origin git@SERVER_HOSTNAME:new-repo.git
git push origin master:refs/heads/master

Note that the push will fail unless you have at least 1 commit on the master branch. Once you’ve done this once, git will remember the local and remote refs so you’ll only need to
git commit [OPTIONS]
git push

And that’s it! There are a fair few config options I’ve left out, like using group names as user names in writable lists, read-only access (but not public access) etc. Check out example.conf in the directory where you originally cloned gitosis for more info.

Posted in Uncategorized | Comments (0)

Aevercore update

August 30th, 2009

The excuse: Work’s got massive so I haven’t had a good chance to work on Aevercore in ages.  However I’m still sold on the idea and have a bunch of almost-working scripts so it isn’t dead, just sleeping.  Stay tuned :-)

Posted in Uncategorized | Comments (0)

I hate browsers

August 30th, 2009

The browser these days is the centre of a hells of a lot of desktop activities.  I mean, how often do you actually spend “browsing” the internet?  I know I spend bugger all.  I go to Facebook, Twitter, LWN, LinuxForDevices, XKCD and a handful of other websites all the time but fairly rarely actually sit down and browse.  And I suspect you’re the same.

If the regularly visited sites are apps the browser is a complete secondary desktop environment with tabs instead of windowing and a whole lot besides.  Why do I want another desktop when GNOME/KDE work so well?  Why shouldn’t web apps be Revealed, ALT-Tab’d and resized like anything else?

There are solutions – both major Linux desktops have widgets which can bring some sites to my desktop and Twitter’s well defined API means that I can just use Gwibber.  All well and good where it works but I want to treat every web app this way.

In steps uzbl, a browser conforming to the UNIX philosophy that one program should do one thing and do it well.  In fact, browser may even be overstating it – let’s try interactive web renderer.  It uses the WebKit renderer so you get CSS, Javascript, Flash, all the things you need but nothing you don’t.

Using uzbl and a little bit of BASH we get Page Apps.  Normal apps which can be launched from GNOME-DO, run dialogs or menus but are nothing more or less than the web apps we all know and love.

page apps in action

page apps in action

OK so maybe people won’t get it.  What’s the problem with 1 extra mouse click or a few extra key strokes?  But they’re missing the point, it isn’t about that, it’s about promoting web apps to first class citizens.

By default uzbl is modal, VIM-like, so as yet my PageApps don’t quite act as you’d expect.  But they will.  You can get uzbl at http://www.uzbl.org/ and I’ll release my PageApps scripts just as soon as they’re ready.

Posted in Uncategorized | Comments (0)