librehosters issueshttps://lab.libreho.st/groups/librehosters/-/issues2021-05-28T23:30:38Zhttps://lab.libreho.st/librehosters/infrastructure/-/issues/9Medium for Discussion2021-05-28T23:30:38ZRaghav Gururajanrg@raghavgururajan.nameMedium for DiscussionHello Team,
I was wondering if you could open an IRC Channel or a XMPP Conference? It would be very useful for hosters, users and anyone to communicate about libreho.st itself or topics related to it.
Thoughts?
Regards,
RG.Hello Team,
I was wondering if you could open an IRC Channel or a XMPP Conference? It would be very useful for hosters, users and anyone to communicate about libreho.st itself or topics related to it.
Thoughts?
Regards,
RG.https://lab.libreho.st/librehosters/directory/-/issues/5Move `librehost.json` under `/.well-known/`2020-05-15T09:34:19ZhowMove `librehost.json` under `/.well-known/`We started off with putting the `librehost.json` file under the domain's web root. Recently privacytools.io created a JSON file under `/.well-known/librehost.json`. The `/.well-known/` directory is indeed made to host that kind of data (...We started off with putting the `librehost.json` file under the domain's web root. Recently privacytools.io created a JSON file under `/.well-known/librehost.json`. The `/.well-known/` directory is indeed made to host that kind of data (cf. [RFC8615](https://tools.ietf.org/html/rfc8615)).
Using a location under `/.well-known/` requires a formal registration with IANA (see [Well Known URIs Registry](https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml)) in the form of an RFC at IETF. Therefore this move should come as a 'natural' evolution of our discovery protocol. Yet, it requires some effort in order to obtain a permanent identifier from IANA.
Discussion needs to happen over these requirements:
- [ ] set a proper location, e.g.: `/.well-known/librehosters/librehost.json` and register `librehosters` with IANA
(note that we could register `/.well-known/librehost.json`, but setting a directory enables future extensions, e.g., supporting such things as `/.well-known/librehosters/services.json`)
- [ ] follow registration instructions in sections [3](https://tools.ietf.org/html/rfc8615#section-3) and [3.1](https://tools.ietf.org/html/rfc8615#section-3.1) to write an RFC
- [ ] open relevant shared draft topic on talk.libreho.st
- [ ] write, discuss, and validate RFC (see for example https://tools.ietf.org/html/rfc7033#section-10)
- [ ] update all current `librehost.json` to new format and location
- [ ] publish RFChttps://lab.libreho.st/librehosters/libreho.st/-/issues/5Value: produce free software2019-06-15T13:09:11ZhowValue: produce free softwareSee https://talk.libreho.st/t/value-produce-free-software/121See https://talk.libreho.st/t/value-produce-free-software/1212019-06-14https://lab.libreho.st/librehosters/infrastructure/-/issues/8Nginx frontend configuration for Android 72019-04-19T10:46:04ZhowNginx frontend configuration for Android 7After a lot of fiddling, I have fixed the Nginx configuration so that it runs properly on Android 7 mobiles. As it involves downgrading `ssl_ecdh_curve` from `secp384r1` to `prime256v1`, we need to decide whether it's security-critical e...After a lot of fiddling, I have fixed the Nginx configuration so that it runs properly on Android 7 mobiles. As it involves downgrading `ssl_ecdh_curve` from `secp384r1` to `prime256v1`, we need to decide whether it's security-critical enough that we want to create a dummy SSL host to capture broken Androids rather than applying to the Gitlab config. Anyway I think it would make sense as it would clarify the configuration in case we add another host before "lab" (see https://talk.libreho.st/t/tls-sni-how-to-break-https-on-android-7-0-nougat/171 for explanation).
Note that it would take me a few minutes to fix an `aaaa.libreho.st` dummy SSL virtual host to take care of this and re-up the Gitlab config to `secp384r1`.
I wanted to have this issue so that we do not have to wonder why this is the case!https://lab.libreho.st/librehosters/directory/-/issues/4Update Request to Join2019-04-13T18:03:53ZhowUpdate Request to JoinThe file Request_to_join.md should include questions from the first pad proposed by Ana from Activix that got us together in the first place (suggested by @gust during our meeting).
https://lab.libreho.st/librehosters/directory/blob/mas...The file Request_to_join.md should include questions from the first pad proposed by Ana from Activix that got us together in the first place (suggested by @gust during our meeting).
https://lab.libreho.st/librehosters/directory/blob/master/.gitlab/merge_request_templates/Request_to_join.mdhttps://lab.libreho.st/librehosters/librehost-api/-/issues/5Proposed new fields2020-03-06T15:52:40ZmboothProposed new fieldsI was thinking about fields that it would be useful to have in this API and the following two came to mind:
```json
"infraRepo" : "https://git.darkpeak.org/darkpeak/darkpeak-services.git/about/",
"issueTracker" : "https://issues.darkpea...I was thinking about fields that it would be useful to have in this API and the following two came to mind:
```json
"infraRepo" : "https://git.darkpeak.org/darkpeak/darkpeak-services.git/about/",
"issueTracker" : "https://issues.darkpeak.org/",
```
**infraRepo** because it would be nice to easily discover what technology other co-ops are using, and how they implemented something (sharing is caring)
**issueTracker** because if you make a change to this API, you will want to inform us somehow to update our librehoster.json file ;-)https://lab.libreho.st/librehosters/directory/-/issues/3Document merge- and voting-process2019-04-13T17:54:22ZGhost UserDocument merge- and voting-processrelated to https://lab.libreho.st/librehosters/directory/merge_requests/10#note_211
I knew that some voting is required cause of librehosters-members who told a friend of mine at FOSDEM :confounded:
It might make sense to put a note ...related to https://lab.libreho.st/librehosters/directory/merge_requests/10#note_211
I knew that some voting is required cause of librehosters-members who told a friend of mine at FOSDEM :confounded:
It might make sense to put a note or documentation about the process in your [README](https://lab.libreho.st/librehosters/directory/blob/master/README.md)https://lab.libreho.st/librehosters/libreho.st/-/issues/4Add the directory of hosters on the website.2019-02-17T14:08:24ZPierre OzouxAdd the directory of hosters on the website.Using a static site generation tool (like hugo), we can parse the list of hosters, and render HTML from that.
Then, we need a pipeline to publish automatically the website when there is a change on this repo.
Then we need to hook the d...Using a static site generation tool (like hugo), we can parse the list of hosters, and render HTML from that.
Then, we need a pipeline to publish automatically the website when there is a change on this repo.
Then we need to hook the directory repo, to trigger the pipeline when a new comer is merged (to make sure the website is built again).
We can also rebuilt the site every days, to make sure that if one hoster modified its json, the next day, the change is present.https://lab.libreho.st/librehosters/infrastructure/-/issues/7Add docker runners to GitLab2019-04-19T22:20:31ZPierre OzouxAdd docker runners to GitLabAs part of libre.sh project, I was planning to have the images built on this GitLab.
For that, we'd need a docker runner.
What do you think about the idea?
It relates to https://lab.libreho.st/librehosters/infrastructure/issues/6
Thi...As part of libre.sh project, I was planning to have the images built on this GitLab.
For that, we'd need a docker runner.
What do you think about the idea?
It relates to https://lab.libreho.st/librehosters/infrastructure/issues/6
This would help https://lab.libreho.st/librehosters/libreho.st/issues/4https://lab.libreho.st/librehosters/infrastructure/-/issues/6Add Docker registry to GitLab2019-04-05T05:59:46ZPierre OzouxAdd Docker registry to GitLabPart of the libre.sh project, I'll need to host docker images.
I was thinking to do it on this GitLab, what do you think about the idea?Part of the libre.sh project, I'll need to host docker images.
I was thinking to do it on this GitLab, what do you think about the idea?https://lab.libreho.st/librehosters/directory/-/issues/2pipeline to test json of new comers2019-04-19T22:20:31ZPierre Ozouxpipeline to test json of new comershttps://lab.libreho.st/librehosters/librehost-api/-/issues/4cli test tool2019-04-18T13:59:41ZPierre Ozouxcli test toolIt would be nice to have a CLI to be able, given a schema version, to test an endpoint or a json against our schema.It would be nice to have a CLI to be able, given a schema version, to test an endpoint or a json against our schema.https://lab.libreho.st/librehosters/infrastructure/-/issues/5Technology choices for managing infrastructure as code2019-02-22T10:15:56ZgandhianoTechnology choices for managing infrastructure as codeIn order to make our infrastructure management transparent, debatable, portable and as far as possible immutable, we should use one or more technologies capable of managing configurations and automating deployments of our infrastructure ...In order to make our infrastructure management transparent, debatable, portable and as far as possible immutable, we should use one or more technologies capable of managing configurations and automating deployments of our infrastructure from this git repository.
Options include (feel free to add more):
- [ ] ansible
- [ ] docker-compose
- [ ] puppet
- [ ] chef
- [ ] salt
- [ ] terraformhttps://lab.libreho.st/librehosters/librehost-api/-/issues/3organisation type2019-06-10T09:24:05ZPierre Ozouxorganisation typeIn upstream schema org, we need more to describe our diversity.
If you want to comment on this discussion:
https://github.com/schemaorg/schemaorg/issues/246In upstream schema org, we need more to describe our diversity.
If you want to comment on this discussion:
https://github.com/schemaorg/schemaorg/issues/246https://lab.libreho.st/librehosters/infrastructure/-/issues/4Adjusting sysctl.conf parameters2018-11-15T20:08:23ZhowAdjusting sysctl.conf parametersI added `/etc/sysctl.d/42-local.conf` with a few recommended settings for Discourse. Please review, comment, etc.
```
# Might be as well zero
vm.swappiness = 10
vm.overcommit_memory = 1
net.core.somaxconn = 512
```I added `/etc/sysctl.d/42-local.conf` with a few recommended settings for Discourse. Please review, comment, etc.
```
# Might be as well zero
vm.swappiness = 10
vm.overcommit_memory = 1
net.core.somaxconn = 512
```https://lab.libreho.st/librehosters/infrastructure/-/issues/3backups2019-06-15T16:55:37ZrealitygapsbackupsWe need good backups of the vm, any preferences?We need good backups of the vm, any preferences?https://lab.libreho.st/librehosters/librehost-api/-/issues/2Issues with schema.org2019-06-09T10:18:39ZPierre OzouxIssues with schema.orgI think I found a way to test our api against schema.org:
https://search.google.com/structured-data/testing-tool#url=https%3A%2F%2Findie.host%2Flibrehost.json
I think we can diverge, but we should PR to schema.org too.
https://github.c...I think I found a way to test our api against schema.org:
https://search.google.com/structured-data/testing-tool#url=https%3A%2F%2Findie.host%2Flibrehost.json
I think we can diverge, but we should PR to schema.org too.
https://github.com/schemaorg/schemaorg
I know google is evil, but if people like google can work with our tool, hen anybody will.
(let's not discuss google here, I personally don't have issue in this context, I'm just careful, and understand some people might have, if you want to discuss that, please do in the forum).https://lab.libreho.st/librehosters/libreho.st/-/issues/1Link to tools2019-02-04T21:04:08ZgandhianoLink to toolsVisitors should be informed about the existing tools and places for communication. These should include at least:
- [x] login.libreho.st
- [x] talk.libreho.st
- [x] lab.libreho.st
- [ ] Riot/IRC channel (e.g. https://riot.allmende.io/#/...Visitors should be informed about the existing tools and places for communication. These should include at least:
- [x] login.libreho.st
- [x] talk.libreho.st
- [x] lab.libreho.st
- [ ] Riot/IRC channel (e.g. https://riot.allmende.io/#/room/#librehosting:matrix.allmende.io)
We can link them directly on top, but I find it better to link to a short description/explanation of the tool purpose and from there provide one (or more) links to the tools.