the community has not been that active lately, and we are also partly responsible for that.
We currently host the VMs that host the different services.
And we maintain the GitLab (we perform regular updates).
We plan on moving our tools away from this GitLab.
And so, we plan to stop paying for the VM in 6months.
I don’t know what is the plan for the people? Do you want to move the tools somewhere else? Do you want to pay the VM? I think it is up to you, and we could help if necessary.
I think it is better to shutdown things if they are not used.
We at eco:bytes could host the one or the other instance. Notably, in comparison with other self-hosted software, GitLab and Discourse are quite memory and CPU intensive, even when they are doing nothing. Which is most probably the case with Librehosters lately.
Anyway, I think we should keep it. Librehosting has become a term on its own, and is used out in the wild independently from us. I think we can consider this a major achievement. And given the political and economical developments of the last years, we may want to keep this network around for reassuring each other that we’re building something larger together.
I’m regularily referencing people to the network’s landing page, to show that we are coordinating loosely with other practitioners in the field and to show that our cause is not a singular one.
How can we proceed to port the existing services to a new home?
Gitlab, Discourse and Keycloak are running there. The Keycloak is super outdated and upgrading is likely a pain in the ass. Maybe exporting the accounts and importing them into a new instance might work better.
I think IndieHosters and you should decide what goes where.
There are two offers on the table, but as a side node, we already run few Discourses from the stock launcher, which means fewer adaptations for this migration target…
Authentik, Zitadel and KanIDM also appear to be proper candidates for taking on the IdP role, while we’re at it.
And porting the IdP sounds like fun! What would this involve, exporting a CSV with Argon2ID hashes? Edit: Okay, arguably also migrating all application integration endpoints + credentials. I for myself wouldn’t feel comfortable with maintaining Keycloak. The new stuff is just so lean.
AFAIC the Discourse should be upgraded to test-passed instead of remaining on stablewhich does not seem so much stable since — I dunno 'bout you — notifications seem to flood.
Anyway, wrt the IdP, I have run Authentik for a couple of years now, and it shines. No idea about Zitadel nor KanIDM. Will look them up. And yes, it’s probably a bit of a hassle to port, but it’s also the right time to do it.
That’s the Ecobytes mail server under heavy load, and happens on our Discourse instances, too. :-/
This behaviour of the socket not closing in time despite the message was sent is only seen with Discourse and Authentik. Other applications using SMTPS for transactional mail don’t show this behaviour. We’ll have to upgrade the infrastructure, I guess.
@how I’m available for any of the proposed migrations, maybe Discourse first.
@mmekimia Would you still like to take the GitLab?
@pierreozoux What do we do with Keycloak? Does it have a complex configuration, or would we just be migrating few applications, few users and a few password hashes? I think it’s not even used for group permissions.
Yes I can host the gitlab , but it might be easier if all components are hosted on the same infra and we share the task of maintaining it with regular meetings
Basically we are talking about usernames, email addresses and password hashes, am I correct? All client authentications and links to usernames might have to be updated, including a switch of the subdomain of the identity provider. Admittedly, it might be easier just to carry over the existing containers, not breaking any existing authorisations.
Although the idea of porting a user base away from a Java monster shines with a certain aesthetic quality, I must admit.
Why would you think so? The distributed hosting has served us quite well up until now. Which were deficiencies that we observed with this setup? The different timeliness people can contribute to keeping things up to date and for resolving regressions?
Let’s also not forget the domain and the DNS zone, which lies with Webarchitects.
$ whois libreho.st | grep -P -e '^Name'; dig +short NS libreho.st
Name Server: dns1.webarchitects.co.uk
Name Server: dns0.webarchitects.co.uk
Name Server: dns2.webarch.info
Name Server: dns3.webarch.info
dns0.webarchitects.co.uk.
dns1.webarchitects.co.uk.
dns3.webarch.info.
dns2.webarch.info.
@chrisc Do we have a nice web interface for managing the DNS zone, where we can login and edit the records collectively?
