Posted on
by

Gitosis is a GIT server system which, using ssh, lets you run a central git repository in much the same way as github does. This let you manage multiple developers easier, as well as providing a convenient place to access repositories while out and about, and for deployment.

Unfortunately, gitosis is no longer maintained, and has been removed from more recent versions of the major linux distributions. This was preventing me from performing some much needed server upgrades, so it was therefore necessary to migrate to another bit of software.

Gitolite is the recommended replacement for Gitosis, and acts as a drop in replacement. Perform the migration right, and you’re users will never notice that you did anything at all.

So, in hopes that this may be useful to someone, here’s how I migrated my gitosis server over.

The initial setup

The initial server configuration was as follows:

  • Debian server
  • Gitosis installed as user “git”

My goal was to replace the gitosis server, still on the GIT user, so my users would not need to modify any of the remote repository paths in any checked out repositories.

Migration

Start off by taking a backup, just incase this goes horribly wrong, then…

  1. Belts and braces, get rid of the old gitosis update hooks and prevent any new sessions by removing the authorized_keys file: mv git/repositories/gitosis-admin/hooks/post-update git/repositories/gitosis-admin/hooks/post-update.old; mv git/.ssh/authorized_keys git/.ssh/authorized_keys.old
  2. Move the old gitosis home directory out of the way: mv git git_old
  3. Install gitolite: apt-get install gitolite
  4. I then needed to reconfigure gitolite so it used the same user id as the previous gitosis install: dpkg-reconfigure gitolite
  5. Copy your old repositories to your newly created git directory: cp -a git_old/repositories git/
  6. Gitolite had trouble using my existing public ssh keys for the admin account, probably because they were already used as login keys, or perhaps because they were in the foo@bar.pub format. Either way, the simplest thing was to generate an admin key specifically for gitolite administration.
    1. Generate a new key, making sure you have at least one “.” after the “@”, so that the key looks like an email address: ssh-keygen -t rsa -C "gitoliteadmin@myserver.local" -f gitoliteadmin@myserver.local
    2. Make sure root, or whoever is going to admin your gitolite repo has a copy of these keys, as you’ll need them to make any configuration changes. You can simplify this somewhat by making a host alias for the gitolite admin user in the ~/.ssh/config file

      Host gitolite-admin
          HostName myserver.local
          User git
          IdentityFile ~/.ssh/gitoliteadmin@myserver.local

  7. On the server, change to the git user: su git
  8. Then initialise the gitolite repository, passing the location of your newly created admin key: gl-setup /path/to/gitoliteadmin@myserver.local
  9. Clone the gitolite-admin repository, note the use of the gitolite-admin host repository: git clone git@gitolite-admin
  10. Convert your gitosis settings file using gl-conf-convert, which if you’re running this on the server, can be found in /usr/share/gitolite. This script can be run in isolation, so it’s ok to copy it about if you need to run this on a different machine: /path/to/gl-conf-convert < /path/to/gitosis-admin/gitosis.conf >> /path/to/gitolite-admin/conf/gitolite.conf
  11. Now, check your gitolite.conf for errors, and if ok commit and push your changes. Since I had a number of keys in the format of user@machine, I had to change the occurrence of those users in the file to just the username before the “@” character. E.g. foo@machine becomes just foo
  12. Things should now be working on gitolite. You can verify that gitolite rather than gitosis is fielding your requests using ssh: ssh git@myserver.local info, you should see a list of the repositories on the server that your user has access to.

All being well, your migration over to gitolite should now be complete, and remotes in any existing clones of repositories on the server should still function.

Hope this helps!

Posted on
by

idno Idno is a modern #indieweb self hosted open source social networking platform. The project was started by Ben Werdmuller, who you may remember from such projects as Elgg, it makes use of a lot of cool technologies and has some very interesting features on the roadmap.

I recently got stuck into the project myself; as a former core Elgg developer myself, it seemed an obvious platform to look at when I wanted to PRISM break my social media activity, and move to a POSSE modal for Facebook and Twitter etc. It also forms the base to a couple of cool client projects that I’m working on.

The project is really starting to pick up speed, and you can see my social stream over at mapkyca.com.

Ben has done a really nice job at building the initial platform, and I can’t wait to see how the project develops!

Posted on
by

Unless you’ve been living under a rock, you’ll know by now that government agencies around the world are watching everything you do online, collecting this data and using it for various undisclosed purposes. Even before then, we knew that various private companies were harvesting data on us, and we could only hope that the worst they wanted to do was sell us things.

To say I wasn’t comfortable with this arrangement was something of an understatement.

So, I used all this as a spur to get my data out of NSA/Big Corporate controlled systems and onto FOSS based platforms that I own and control.

Starting Point

I was somewhat fortunate in regards my starting point. I had never bought into gmail, so my email accounts are hosted by a private mail server, to which I connect over an encrypted link. My main server, which hosts, among other things this website, is run of a private server in Germany.

My main computers at home are Linux based, and I already make extensive use of encryption; I use DNSCrypt to secure my DNS lookups from prying eyes, have HTTPS Everywhere and Adblock Plus installed on every browser, and secure sites with HTTPS (made considerably more affordable by StartSSL’s provision of free SSL certificates), and private code is hosted on my gitolite (nee gitosis) install rather than Github.

However, I still made use of services like Dropbox and Google drive, talked on Google chat, and use Google analytics for tracking.

The low hanging fruit…

The first thing I did was to grab and install a whole bunch of free certificates from StartSSL to remove the browser warnings from a bunch of the non-user facing sites that I run. This was important since the browser warning encouraged people to click through errors, and since the site always generated an error (even thought the site was being encrypted) it would be very vulnerable to MITM attacks.

Once this was accomplished I installed ownCloud, with the client software configured to talk only to the HTTPS endpoints. This was painless, and basically just a matter of downloading and installing the server software on a subdomain for it (the latter isn’t strictly necessary, but I like having things separate like that). The ownCloud client works exactly like the dropbox one, and is available for Linux, OSX, Windows (and a paid for one for iOS – presumably to drum up some money for the project – but it’s only a few pence).

Next, I started moving my sites away from Google Analytics. The open source world has moved a long way since I last looked at this, and Piwik, the best of breed, is very performant. Again, it was just a matter of installing the software on my server and then changing the embed code on the various sites. WordPress has a very functional plugin that integrates nicely with most themes.

The last easy thing I did was to change my browser’s default search engine from google to Startpage. The reason I picked Startpage over DuckDuckGo (which is the other main alternative) is twofold, firstly, the engine piggybacks off of google (but with identifiers removed), and despite while Google profile you for the NSA they still built a damn good search engine. Second, as a US company based in Pensilvania, DDG falls squarely under the sinister shadow of the US Patriot act and FISA, so, regardless of what they do now, they could still be forced to start spying.

Next, the harder stuff…

Update: while at the time of writing the, events in the pressure cooker article, linked above, were believed to be the result of active surveillance on the part of google, it now turns out to have been the result of an employee tipoff. Nevertheless, it seems nightly unlikely that this honeypot of profiling data isn’t being actively monitored, given how much other stuff is, although at the moment we have no evidence. This is one of the things that makes the Snowden revelations so frustrating.