xsf / infrastructure Goto Github PK

When trying to send a password reset email, the SMTP connection aborts due to an incorrectly set hostname in HELO ("localhost"?):

Error sending mail: Failed to add recipient: censored@address [SMTP: Invalid response code received from server (code: 504, response: 5.5.2 : Helo command rejected: need fully-qualified hostname)]

Hi iTeam

I would like to request a subdomain à la join.xmpp.org.

It should link to the "Getting started" page for the moment.

Would that be possible at one point?

Kind regards and thanks for your work.

Dear iTeam,

what converse version do we run at xmpp.org?

It possibly should receive an update if one finds time.

Set up a status page for reporting availability, incidents etc affecting the various XSF systems and services.

cachet was mentioned

xmpp.org went offline recently and came back online with the DH key size set to 2048. This caused federation with XMPP servers using a size of 1024 to fail.

In the cases for Java based XMPP servers like Openfire (which use a default value of 1024 inherited from the JVM), the error message being recieved from xmpp.org was "handshake_failure" instead of "dh key size too small" and that made debugging difficult.

Unless there is a very compelling reason, can we please use the default 1024 instead of 2048.

https://github.com/xsf/infrastructure/blob/master/xmppdotorg/README.md

travis-ci.org is shutting down "at the end of May". Meanwhile travis-ci.com remains open (their new platform), though with a more restrictive free tier.

I've migrated from travis-ci.org ->travis-ci.com. The dashboard is a bit weird and doesn't show credits or plan info, so I'm just giving it some time. If necessary I shall contact them to request sponsored OSS credits.

If for any reason this migration falls through, we'll migrate to Github Actions.

There are already badges for XMPP providers. Those badges could be hosted on https://data.xmpp.net. In addition, a page for each provider result could explain it and describe how it can be improved.

At the moment, there is only a JSON file listing the issues that must be resolved in order to be in a specific category. After clicking on the badge a provider embedded in its website, the JSON file is opened (see https://hookipa.net in the row hookipa.net for an example). The current state is only meant as a temporary solution since users and admins do not know what the JSON content means.

The proposed result page could outline the project's goals including a link to the upcoming introduction page, use the JSON file in order to represent it as text or even graphically and provide help for the provider's admins.

Current certbot setup on eos2 is not automated.

@mwild1 proposed that a subdomain of https://xmpp.net could provide the filtered lists of category A, B and C of the XMPP Providers project.

Steps

1. git clone https://invent.kde.org/melvo/xmpp-providers.git && cd xmpp-providers only once
2. git pull && ./filter.py -A && ./filter.py -B && ./filter.py -C once a day or even more often

Software Requirements

Python >= 3.7 is required for running ./filter.py.

Additional Thoughts

We could link from https://invent.kde.org/melvo/xmpp-providers to the three created JSON files on https://providers.xmpp.net or a similar subdomain.
It would be great if we could provide those lists as a first easy goal. In the future, we could create a welcome page with links to all lists or even a nice formatted table on https://providers.xmpp.net.

Currently https://xmpp.org/rfcs redirects to https://xmpp.org/rfcs/, which is a directory listing.

In xsf/xmpp.org#975 I built a new index page for xmpp.org/rfcs. In order to make this work correctly, we would need a server direction for xmpp.org/rfcs. Since xmpp.org serves some RFC files itself (e.g. https://xmpp.org/rfcs/rfc3920.html), and it should continue to do so, we would need an exact match directive for that (and only that URL), I think.

I know: No resources, time and prio. Anyway it seem not be a topic before

It seems our Tarsnap usage may have increased recently. It would be good to review what's currently stored, and what we're backing up to help reduce costs.

Hello,

I would like to suggest to merge together the maintenance of "rather small" repositories.

I think it helps to have a better overview and issues or task can be labeled accordingly to differ.

Of course, I may miss any specific technical reasons.

For example:
https://github.com/xsf/mediawiki-docker
https://github.com/xsf/registry-docker-base

Due to a misconfiguration and multiple debugging attempts, we hit rate limits for this domain. Need to try again soon.

Apparently Google has indexed XEPs here.

Need to figure out how this worked on old eos and replicate on eos2.

To gain independence from the host OS and consistency with other services that are running in Docker.