The Fool on the Hill: Installing Forgejo

Most of my open source work is on Github. It's been there for years — since long before Github was bought by Microsoft. Github has a lot of good features, not least that, following on from Freshmeat in the 1990s and Sourceforge in the 2000s, it has become the go-to place so look for interesting open source projects and libraries.

But I've never liked Microsoft as a company, and their use (without permission and in breach of the General Public License) of other people's software to train their AI bots has made them much more obviously obnoxious and their qualification for custodianship of the world's major open source repository at best questionable. Furthermore, developments in the political world suggest that dependence on US based corporates for anything is now actively unsafe.

Over the years I have experimented with a number of open source git web integrations, none of which has been very satisfactory. This week, largely because of the promise that it will soon have ActivityPub integration, I've been trying Forgejo; and I'm impressed.

Installation

There isn't (yet) an official, Debian approved, Debian package. But there are a family of unofficial Debian packages, and I chose forgejo-sqlite because I don't want a big heavyweight instance serving a large number of users but a small, mainly personal one, serving my own projects and projects for at most a few trusted friends.

Adding the GPG key and Apt repository to my Debian configuration allowed me to automatically install the package, and it immediately worked. I did a small amount of reconfiguration following the excellent documentation. At that point it was serving pages under HTTP on a custom port; but I wanted it to serve HTTPS on the default port, and to do that I needed to reverse-proxy it behind my primary web server.

Apache integration

I still run Apache as my web server, mainly because I have done so for thirty years (and the NCSA server, from which it evolved, before that), so I know it very well. I failed to find the Forgejo Apache integration documentation (it's there, and it's good, but I missed it), but I was able to crib from the Nginx documentation and again, got web server integration working pretty quickly. That allowed me to set up a LetsEncrypt certbot certificate set up for it, and the web view was working perfectly.

This allowed me to migrate over all my repositories from Github, and again this was extremely slick and easy.

SSHD integration

Next job was SSH daemon integration. I use SSHD to control access to my server; I disallow passwords and require keypairs. It's really important to me that my SSH daemon doesn't get messed up, because if it did I'd lose control of my server.

Forgejo comes with its own built in SSH daemon, but if it detects an SSH daemon already running it doesn't start its own but instead makes use of the default one. I really did not want it to do this, for the reasons I've given. But there didn't appear to be a setting in the configuration file (stored in /etc/forgejo/app.ini) to force the start of the built in daemon, and this was the first real snag I hit.

Fortunately, a little web searching revealed that there is a setting, START_SSH_SERVER, which must be set to true in the [server] section of the configuration file. This configuration key is not present in the file by default, you have to explicitly add it. With this done and the forgejo service restarted, everything worked.

Note that I don't know that if I allowed forgejo to use the default SSHD it would cause problems; I just didn't want to take the risk.

General use

In appearance and general use, Forgejo is very similar to — a drop-in replacement for — Github. Most things work in exactly the same way, and those that are slightly different are clear and easy to use.

Things I haven't evaluated

Forgejo apparently does have a continuous integration facility, but I haven't tried this yet — and may not, since all my software these days is very experimental and exploratory.

I haven't discovered whether ActivityPub integration works yet, or how I would peer with other Forgejo instances, and this is really important, because without it we lose the discoverability which is Github's strongest feature. Until it does, I can't abandon Github.

I don't think Forgejo has an equivalent of Github Pages, and while I regret this, I understand why it hasn't.

A sidenote

Forgejo won't accept 2048 bit RSA keys; it has the view that they're too short, and insecure. Up to now, that's what I had been using (and all the other systems I use SSH to identify do as well). However, SSH is my main line of defence, and if anything thinks 2048 bit keys aren't sufficient, that's a warning to me, which I have heeded. I've generated a new, 4096 bit, key pair, which I'm now using by default. If nothing else good comes out of this exercise, that's good.

Conclusion

This is a really unusually well polished and well documented open source project, and seems to be an effective replacement for Github, except for

1. Github's important discoverability function, and
2. The fact that Github (and repositories on it) will (probably) continue to exist after I'm dead, if anyone is then still using any of my work.

I'm hoping that ActivityPub federation functions will solve the discoverability issue, but it isn't here yet; I'm hoping that informal cross-cloning agreements between instances may solve the legacy problem, although given that few of my projects are of much use to anyone else, that's less important.

In summary: this looks to be on the way to being an effective, light weight, open, federated replacement for Github, but it doesn't seem to me to be ready for prime time yet. My intention is to use my Forgejo instance as my primary repository, and to push from it to Github as a mirror, until such a time as at least the discoverability issue is solved.

Share on social media

I'm no longer offering links to kleptocrat owned social media. If you're still using it, please think about whether you should be.