Hi, There is some unknown on weather or not the OSUOSL will continue to support FLOSS projects[1][2], and Replicant has some of its infrastructure hosted there.
Fortunately, Replicant also has a small VM that runs inside the FSF
infrastructure. And there was also some plans in the past to be a bit
more independent infrastructure wise, and/or to have tools that are more
adapted to our use cases and to self-hosting. And over the years there
was some work to improve the situation.
I'm also confident that if we need new resources like a new VM and/or
space we could easily arrange that in some way (we could ask to many
non-profits, and non-profits like Libre En Communs probably can provide
a new VM if needed, especially if we pay for storage in case we need
more space than provided).
What is more problematic is that some of the migration might require
time and/or something even worse: increased maintenance which probably
require much more time in total or are simply unrealistic.
If OSUOSL has to stop, some services are relatively easy to migrate but
other not:
- The Replicant blog: The blog uses WordPress, and that didn't work
very well for us because we want to review each other's blog posts
before publishing them, and WordPress complicated a lot reviews
through mail.
Because of that, there was a lot of work to migrate it to Haunt, a
static website generator and the work is almost done.
The source is on the Replicant VM[3] and it is even already deployed
on blog.test.replicant.us. So far we have an archive of all the
previous blog posts, and we converted all of them to markdown for
Haunt.
We also have an archive or links and redirects to keep old links
working, and we can very easily add comments support (I've code for
that that isn't pushed yet).
The comments system will just be code that tells users to comment on
the mailing list and point to the respective article posted there
and/or telling that comments are over for older blog posts.
The only big issues that remains are:
- a legal question: what to do with the old comments: only the blog
post authors published them under a free license
- when to decide to make all that official and move the git
repository to official Replicant space and point the DNS to this
new blog.
- The Replicant "ftp", which is an https website where we host our
releases: we have a shell access to it so we can easily copy it all
through rsync or ssh. So it's more a matter of requesting space
and/or getting new resources to host them, and changing again the URL
to the releases files in our wiki (ideally in a way that let us point
to <something>.replicant.us, not to have to change that again). This
looks trivial to solve.
- The replicant.us website: this uses PHP for displaying the last posts
from the Replicant blog and forum. It is currently hosted by OSUOSL
though some git hook or clone mechanism. We can easily self-host it
but I don't really like the fact that it is not static as a security
issue in the code could lead to arbitrary execution of code. And we
don't want that in a VM that hosts all the Replicant source code as
well.
The only big issue I see here is the feature that loads the
latest posts from the Replicant forum: the website has already code
to convert the php pages into static pages, and if the blog is
migrated to something static, we might merge both the website and
the blog somehow and also generate the last blog post in a static way.
In the worst case we remove the feature(s) that is/are hard to
re-implement.
- Redmine. The good thing here is that we use redmine.replicant.us, so
moving to some other hosting won't break URLs.
However it doesn't seem easy to solve without self-hosting Redmine
and/or finding some hoster and we don't know any yet.
And Redmine isn't in Trisquel, so it means that the maintenance cost
would be increased a lot of we self-host it. Using Parabola instead
is also not an option for us because even if we get a new VM just for
that, we'd need to keep it up to date and it has no automatic updates.
And we can't easily move away from Redmine. Let's look at that in more
details with the features being used:
- Redmine wikis: There is code to convert some of the wikis being
used to MediaWiki by adding the articles to git and then using
git-mediawiki. The work is incomplete as only the smaller wikis
(like the one about the Replicant infrastructure) really import well
in git.
- Bug reports: So far there was 0 work at all to migrate the bug
report system.
- Nobody looked at the forum yet. I also have no idea of easy
alternatives that can be very easily self-hosted on Trisquel.
- The mailing list: we don't use the replicant.us domain for it and I'm
unsure how to archive it publicly. The ideal situation would be to
use public-inbox somehow or find a way to re-import it in some other
mailman instance.
The FSF and/or nongnu probably can probably host mailing lists. I'm
unsure if we could somehow have something
If we can re-subscribe current subscribers it would probably not
create much negative impact though. If we can't it would probably be
a huge issue given the current situation of Replicant.
The most problematic in all the above seems to be Redmine.
As I understand, our biggest security risk is probably the IRC bridge
(matterbridge) that we run on the Replicant virtual machine.
It comes from Guix, not Trisquel, and I somehow maintain the package it
comes from in Guix. And it's not automatically updated in any way. It
originally came with many bundled dependencies, but I've unbundled many
of them already. Also note that despite all that, it is a go program
and I've also reused/adapted a systemd unit (from Parabola) to heavily
sandbox it.
So if we start running Redmine on a different VM we increase
maintenance costs a lot, and if we run it on the same VM, then we
probably end up with a huge risk.
The problem is that in any cases I don't think I can find the time to
always keep up with the security updates of something like Redmine
when things are not done automatically and/or very strongly mitigated by
other means (I'm still not very comfortable with matterbridge for
instance despite the mitigations).
I managed so far to maintain the rest of the infrastructure because,
at worse, I only need to show up every 2 or 3 years to do an upgrade to
the next Trisquel version to keep being up to date, so it's not that
demanding because all the rest is taken care by Trisquel and as far as
I know the risk is low of things slipping through here as we use very
well known package for our infrastructure (like Apache for instance),
so it's unlikely that Trisquel and Ubuntu fail to apply security
updates there.
And of course I did work to keep things working, but even if I fail
here in the worst case there is a big downtime (it happened for the
contact address once) but it's not catastrophic as a huge failure here
will not make me have to re-do all the previous work (reinstall
everything from scratch, try to find what was modified, re-authenticate
all the source code for many Replicant versions, etc) just to get going.
References:
-----------
[1]https://lwn.net/Articles/1019520/
[2]https://osuosl.org/blog/osl-future/
[3]https://git.replicant.us/contrib/GNUtoo/infrastructure/haunt-blog
Denis.
pgpPzUGsRXWxc.pgp
Description: OpenPGP digital signature
_______________________________________________ Replicant mailing list [email protected] https://lists.osuosl.org/mailman/listinfo/replicant
