[ejabberd] Seeking information for building a modular ansible role

Nicolas North [norðurljósahviða] nz at os.vu
Wed May 15 17:16:20 MSK 2019

Hi Hartmut!

I'm so glad you've decided to start this project, and I'm taking a look at your website.
I've spent the last 2 years working at my hackerspace's project aenigma, which does exactly what you're trying to achieve, a state-of-the-art XMPP server. All of the work has already been done, we get 100% compliance right out of the box, have a employ all of the latest security standards, perfectly outlined provisioning process that works every single time, and have a very clear and simple one-touch install script that explains everything and automates everything.
The only missing things IMO are postgresql DB provisioning [which I'm working on literally right now], nginx uploads, and Movim pod auto-provisioning. That will take us to v0.9.x.
So far all of the work has been towards the end result, and I think we're really like 95% of the way there. We have not however worked much on how we get there, and as much as I love our pure-bash approach and the bash automation framework we've built, we've always envisioned moving to a different codebase for v1.0. Ansible has always been the leading candidate, however we're also looking into re-writing our synthia+dna framework in nodejs, which is currently happening but in parallel to aenigma.
I think if we worked on this together we could achieve both goals in a fraction of the time. In these two years I've gone to extreme lengths to get all of the details right. All of the logic, the features, and workflow are already there. If you'd like to work on this together, we could schedule a jitsi call, I could show you around, and it would be a simple matter of translating our pure bash approach into an ansible workflow. That would get us both to the finishing line in the shortest and most linear amount of time.
I have so far received a few hundred € in donations for aenigma, all of which go into resources, and although I have server costs for the testing and development infrastructure, I was keeping most of them aside to have a DB admin audit my work on PSQL, but I'd be very happy to share these very limited funds - but most importantly any future donations - with your project to make this happen.
Let me know if you'd like to work on this together!
You can find all of our features here: https://github.com/openspace42/aenigma and our work-in-progress website here: https://aenigma.xyz
On May 15 2019, at 1:56 pm, Holger Weiß <holger at zedat.fu-berlin.de> wrote:
> * Hartmut Goebel <h.goebel at crazy-compilers.com> [2019-05-15 13:31]:
> > This would enable more people to run a xmpp server on their own.
> Recent ejabberd releases should already make that quite easy, though :-)
> > 1) What are the features required to run a state-of-the-art XMPP server?
> > (E.g. Is file upload, pubsub, proxy65, muc, or bosh required,
> > recommended or optional?)
> Currently I would recommend all of those you mentioned (pubsub can be
> PEP-only if you don't support 'social' clients such as Movim; proxy65
> only to support traditional clients; BOSH only to support web clients
> such as Converse.js that don't do XEP-0198 over WebSocket).
> You could use https://compliance.conversations.im/add/ to check your
> configurations.
> > 2a) Regarding hostnames: Are different hostnames required for upload,
> > proxy, pubsub (as [1] sec. 3.3 shows), or can this be the same hostname
> > as the "base" XMPP server ("my-club.org")?
> It can't be the same hostname, but DNS records aren't strictly required
> for services that are only offered to local users (as ejabberd doesn't
> perform DNS lookups for local services).
> > 2b) If any, which of these hostnames are to be read or typed in be user
> > and which can be just meaningless (ajkdfha.my-club.org)
> Usually, nothing but "my-club.org" should be exposed to the user. Plus
> possibly the MUC domain if users explicitly join (public) rooms by their
> room address (as opposed to creating private group chats and inviting
> others).
> > 3a) Regarding TLS certificates: I assume the TLS certificates need to
> > cover all the hostnames 8as in question 2). Is this correct?
> They should, though the answer is the same as for question 2: Hostnames
> for services that are only offered to local users don't *need* to be
> added to certificates (but omitting them can yield warnings in log
> files).
> > 3b) Let's assume I have a SRV record for "my-club.org" pointing to "...
> > some.server.net". Does the certificate need to include "my-club.org" or
> > "some.server.net" or both?
> Only "my-club.org" (except that some obscure clients, such as some Apple
> Messages versions, incorrectly check against "some.server.net").
> > 4) Which are the modules to be activated for a state-of-the-art XMPP server?
> See the current default configuration:
> https://github.com/processone/ejabberd/blob/master/ejabberd.yml.example
> > 5) If you have a basic XMPP server, what has to be changed/added in
> > configuration options to activate for each of muc, in-band
> > registration, registration via web, file upload, pubsub, proxy65, muc,
> > bosh, etc. I need this information to allow enabling or disable features
> > as described at the top of this posting.
> Except for web/in-band registration, the features you mentioned are all
> enabled in the default configuration. You will want to make sure not to
> offer open registration without at least requiring CAPTCHAs by default.
> https://compliance.conversations.im/add/ will give hints regarding how
> to add missing features.
> > 6a) Regarding DNS: Which SRV records are required to be set up? I
> > assume {_xmpp,_xmpps}.{_client,_server}.my-club.org.
> _xmpp-{client,server}._tcp are required if the A record of "my-club.org"
> doesn't point to the XMPP server and/or if you'd like to use non-default
> ports. _xmpps-{client,server}._tcp are optional but kinda recommended.
> > 6b) Are there any SRV records required for other hostnames (according to
> > in question 2)? Of course A/AAAA/CNAME records need to be defined for
> > all of theses hostnames.
> No (assuming you're not also offering STUN, TURN, and/or SIP services).
> > https://www.kuketz-blog.de/ejabberd-installation-und-betrieb-eines-xmpp-servers/
> I would recommend against the strict TLS settings suggested in that
> article, by the way.
> Holger
> _______________________________________________
> ejabberd mailing list
> ejabberd at jabber.ru
> http://lists.jabber.ru/mailman/listinfo/ejabberd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.jabber.ru/pipermail/ejabberd/attachments/20190515/ee1025ec/attachment.html>

More information about the ejabberd mailing list