[ejabberd] Setting up ejabberd MUC to supplement Google Talk

Daniel Dormont dan at greywallsoftware.com
Tue Sep 13 20:02:33 MSD 2011


I'm not an S2S expert, but I can tell you that I'm 90% sure the "bad"
behavior you're seeing is because "conference.example.com" is listed
in both {hosts} and {mod_muc}. Try removing it from {hosts} and see if
that works. If ejabberd then rejects the S2S connections from Google
because of that, then try changing the MUC subdomain to
conference.c.example.com instead (and use that same domain when
joining the MUC from your client, obviously).

Dan

2011/9/13 Bri Hatch <bri at ifokr.org>:
> 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?
>
> Nope.
>
> 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},
>                        %%zlib,
>                        starttls, {certfile, "/etc/ejabberd/c.example.com.pem"}
>                       ]},
>  {5223, ejabberd_c2s, [
>                        {access, c2s},
>                        {shaper, c2s_shaper},
>                        {max_stanza_size, 65536},
>                      zlib,
>                        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",
> "/etc/ejabberd/conference.example.com.pem"}.
> {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?
>
> Yes:
>  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.
>
> _______________________________________________
> ejabberd mailing list
> ejabberd at jabber.ru
> http://lists.jabber.ru/mailman/listinfo/ejabberd
>
>


More information about the ejabberd mailing list