Posted on
by

The ability to follow your friends, and receive notifications when they post new activity, is a vital part of what makes a social network – well – social.

With a distributed social platform like idno, this presents a bit of a problem.

In a previous post, I mooted a specification that would allow for distributed friend/follow/notification on Idno, and any indieweb platform that chooses to support the protocol.

Since it’s always a good thing to have a reference implementation for these things, I put together a couple of plugins that implement the spec. The first, Subscribe, provides the basic engine – the protocol endpoint, together with a subscriber and subscription list page. The second, SubscriptionNotification, provides a visual notification mechanism, via a popup label, and a summary page.

This is highly experimental, and is subject to change as we flesh out the mechanism, but I think it’s a good start.

» Subscribe plugin…
» SubscriptionNotification plugin…

Posted on
by

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!

Posted on
by

For the past few weeks I have included the following message in my email signature:

IMPORTANT NOTE, PLEASE READ:

Unless this email is encrypted, it will
almost certainly be read by multiple unknown
third parties; archived, processed and any
information contained in the email used for
purposes unknown.

If this makes you uncomfortable, please
read up on OpenPGP and email encryption. I
am happy to help you get started.

Please also read my data jurisdiction
statement:
http://mapkyc.me/158prCK

This is to draw attention to the fact that nearly all traffic that crosses UK and US borders is intercepted and read by the government, and in the case of the US, used for economic as well as political espionage.

If this makes you uncomfortable, and it should, especially if you’re using email for business, you should look at implementing email encryption throughout your company, and training your staff accordingly.