There are now many plugins for Known, a lot of them I’ve written, are available on Github.

Many people, myself included, like to install these plugins via a git submodule checkout – this simplifies deployment and makes updating installed plugins easier, however it can be problematic.

The problem is that either the repository contains the actual plugin in a subdirectory (e.g. my Github plugin is in the repo ‘KnownGithub‘, and the plugin is in a subdirectory ‘Github’), or if they don’t, the actual clone of the repository will default to an incompatible name (e.g. Known’s Facebook plugin is in a repo ‘facebook’, but the code wants it in a directory ‘Facebook’).

Both have their own issues, but both mean you can’t directly use them in a submodule git checkout (unless you use my symlink trick). It would be nice if you could use these repos directly, so I put together a patch (which has been accepted) that allows you to build your plugin repos in such a way that they can be used directly from a git clone.

Introducing the autoloader

The patch I submitted introduces the ability to provide a loader for your plugin in the root directory of your plugin repository. So, if your plugin is Foo in a directory inside your repository KnownFoo, you could create a special autoloader.php file in the root that will allow Known to load your plugin in the normal way, direct from a git clone into your IdnoPlugins directory.

To do this, create a file autoloader.php with the following code:

/**
 * Support loading of direct checkout.
 */
spl_autoload_register(function($class) {
        $class = str_replace('\\', DIRECTORY_SEPARATOR, $class);

    $segments = explode(DIRECTORY_SEPARATOR, $class);
    $PLUGIN_NAME = $segments[1];

        $basedir = dirname(dirname(dirname(__FILE__))) . '/'; 
        $file = str_replace($PLUGIN_NAME, basename(dirname(__FILE__)) . "/$PLUGIN_NAME", $class);

    \Idno\Core\site()->plugins()->plugins[basename(dirname(__FILE__))] = \Idno\Core\site()->plugins()->plugins[$PLUGIN_NAME];
    unset(\Idno\Core\site()->plugins()->plugins[$PLUGIN_NAME]);

        if (file_exists($basedir . $file . '.php')) {
                include_once($basedir . $file . '.php');
        }

});

This code will automatically load your plugin classes from its “real name” subdirectory, and make it available to your plugin loader.

Have a look at my Github plugin for an example, have fun!

Ok, so the other week I wrote a little bit about migrating my git server from gitosis (which is no longer maintained), over to gitolite.

Along side this, I also run a gitlist server. Gitlist is a web front end for git, similar to gitweb, which provides a slick and modern looking “github” style interface. It is also remarkably easy to set up and configure.

One gotcha I found was that, while unmodified gitosis repositories displayed correctly, as soon as you pushed a change, gitlist presented an error:

Oops! fatal: Failed to resolve HEAD as a valid ref.

After some investigation, it seems the problem stems from a permission issue. By default, gitolite creates new files and repositories with a slightly more restricted set of permissions.

Fixing the problem

Once the problem was identified, the solution is thankfully fairly trivial:

  1. First, stop gitolite making the situation any worse. Go to the gitolite home directory and edit .gitolite.rc, and set

    $REPO_UMASK = 0027;

    This will cause new files to be created with access to group, as well as user.

  2. Next, give your web server process access to the gitolite group. Assuming, as with me, the user is git, modify /etc/group and add your webserver user to the git group, e.g. git:x:128:www-data
  3. Restart apache for your changes to come into effect.

Fixing broken repositories

New repositories and files should now be created using the more permissive access permissions, which gitlist/gitweb will now be able to see. However, you may need to fix the permissions on some existing repositories.

find repository-name.git -type d | xargs -i{} chmod 750 {};
find repository-name.git -type f | xargs -i{} chmod 640 {}

Hope this helps!

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!