[ejabberd] Setting up ejabberd MUC to supplement Google Talk

Bri Hatch bri at ifokr.org
Tue Sep 13 19:26:19 MSD 2011

Approximately Mon, Sep 12, 2011 at 9:24 PM, Daniel Dormont
<dan at greywallsoftware.com> proposed:

> 1) Are you still attempting to have the XMPP host and the conference
> host be the same?


c.example.com ==> normal xmpp server
conference.example.com ==> muc server

> That won't work. I haven't studied this part of the
> code in detail, but it doesn't seem surprising that ejabberd would end
> up trying to set up both a local route and a MUC route for the same
> domain, and that could cause this result. Specifically, can you share
> the {hosts} and {mod_muc} portion of your ejabberd.cfg?

Relevent parts of the cfg:

{hosts, ["c.example.com", "conference.example.com"]}.

  {5222, ejabberd_c2s, [
                        {access, c2s},
                        {shaper, c2s_shaper},
                        {max_stanza_size, 65536},
                        starttls, {certfile, "/etc/ejabberd/c.example.com.pem"}
  {5223, ejabberd_c2s, [
                        {access, c2s},
                        {shaper, c2s_shaper},
                        {max_stanza_size, 65536},
                        tls, {certfile, "/etc/ejabberd/c.example.com.pem"}

  %% External MUC jabber-muc
  {5554, ejabberd_service, [
                            {ip, {127, 0, 0, 1}},
                            {access, all},
                            {shaper_rule, fast},
                            {host, "conference.example.com",
[{password, "xxxx"}]}


{s2s_certfile, "/etc/ejabberd/c.example.com.pem"}.
{domain_certfile, "conference.example.com",
{domain_certfile, "c.example.com", "/etc/ejabberd/c.example.com.pem"}.


  {mod_muc,      [
                  {host, "conference.example.com"},
                  {access, muc},
                  {access_create, muc},
                  {access_persistent, muc},
                  {access_admin, muc_admin},
                  {max_users, 500}

Note that I have two certificates, since there are two hostnames.
Both are signed by StartCom (www.startssl.com) which are trusted in
all browsers, so I'm assuming they're trusted by the google talk and
jabber.org servers.  The s2s_certfile is the 'normal' xmpp server
here, not the MUC.  I don't think that should matter from a SSL
client perspective, and from a TLS negotiation it is properly
negotiating to the correct cert due to the domain_certfile options
when I connect as a normal XMPP client.

Attached is the full .cfg.

Once I get this working more reliably I'd want to start trimming out
unneeded features, but for now I'm sticking as close to the
Debian/Ubuntu defaults.

> 2) Are you trying to set your MUC service on a subdomain of the very
> same XMPP domain that's hosted by Google?

  example.com - hosted by google.

  c.example.com - ejabberd (not really used, but set up w/ srv records since
                  ejabberd really wants something for the normal xmpp service)

  conference.example.com - ejabberd muc, same process.

> I haven't tried this, but I'm not sure the whole subdomain
> concept is capable of working that way.

I wouldn't think that it should be a problem, but I could see where
assumptions could have been made in one or the other side of the software.

I could try a completely different domain later, but I think I'd like to
see if I can get this working first a little longer.

Bri Hatch, Systems and Security Engineer. http://www.ifokr.org/bri/

Some electromagetic radiation was moduled in the creation of this email.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ejabberd.cfg
Type: application/octet-stream
Size: 16399 bytes
Desc: not available
URL: <http://lists.jabber.ru/pipermail/ejabberd/attachments/20110913/ae5e329e/attachment.obj>

More information about the ejabberd mailing list