Finish setting up ejabberd cluster #243
Closed
opened 2020-11-23 10:23:29 +00:00 by raucao
·
1 comment
No Branch/Tag Specified
Labels
Clear labels
monitoring
bug
design
dev environment
docs
duplicate
enhancement
feature
good first issue
idea
invalid
kredits-1
kredits-2
kredits-3
on hold
ops
question
security
ui/ux
wontfix
service
discourse
Kosmos Community Forums
Infrastructure metrics, alerts, notifications, etc.
service
accounts
Kosmos Accounts
service
drone-ci
Kosmos Drone CI
service
email
mail.kosmos.org
service
garage
S3-compatible object storage
service
gitea
Kosmos Gitea
service
ipfs
Kosmos IPFS
service
lightning
Lightning address, lndhub, etc.
service
mastodon
kosmos.social
service
nostr
Relays, Blossom server, etc.
service
postgres
Database cluster
service
remotestorage
Portable data storage for the Web
service
wiki
Kosmos Wiki
service
xmpp
Kosmos Chat
Something is not working
Graphic/visual design
Config, builds, CI, deployment, etc.
Documentation
This issue or pull request already exists
Improving existing functionality
New functionality
Dive in, and start contributing
Something to consider
Not a bug
Small contribution
Medium contribution
Large contribution
Currently not actionable
Manual IT ops activities
Looking for an answer
release
major
release
minor
release
patch
All your base are belong to us
User interface, process design, etc.
This won't be fixed
No labels
feature
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: kosmos/chef#243
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
For some reason we hadn't documented this when we started setting up the cluster a couple of months ago. We got to the point where we have ejabberd running on both andromeda (the current master) and draco (in a VM, the new cluster node).
However, there is still a problem with HTTP uploads (i.e. posting pictures and other files to chats from clients) failing when connected to the wrong node.
I have asked in the XMPP Service Operators channel, and the common solution to this problem is to use the external uploads feature, where you post to a dedicated service using a lightweight protocol that just requires a secret token for POSTing. The ejabberd HTTP uploads module supports this already.
Behind that POST API, you can then obviously host/replicate/etc. that data in any way you want. As we already use nginx for everything, I think it would be easiest to just set up this Perl module with it:
https://github.com/weiss/ngx_http_upload
Set up ejabberd clusterto Finish setting up ejabberd clusterAnother thing we hadn't considered is how this works with Tor. I guess one of the ejabberd nodes/VMs should be designated a Tor hidden service role, with the privkeys stored in an encrypted data bag. It's enough to connect to just that one from Tor then.