MUC - add a JID programmatically to chat "users"

Hi folks,

I have a use case where I would like, every time a particular MUC
sends out packets to all its users (for example, if a user joins or
leaves, a groupchat message is posted, etc) to also send it to a
particular JID that I can designate. But I want it treated more like a
system account (in fact, it will probably be an external component). I
don't want this JID listed among the participants so everyone can see
it, I don't want the groupchat notified if this JID goes offline or
anything like that. If it *is* offline, I want the messages routed to
it to silently fail, just like any message routed to an invalid JID.

Basically something similar to mod_service_log, except for instead of
when the user sends the packet, I want it called with the MUC sends
the packet. I know I could use mod_service_log itself, but that would
be called for each packet the MUC sends to each user. That is not what
I want. I want each packet from the MUC to reach the special JID only
once.

Looking at the code for mod_muc_room, the only thing I can think of is
to somehow inject the value in to state.users and modify
send_existing_presences to somehow exclude this special JID. But that
seems a little tacky. Is there any better way?

thanks,
Dan

(no subject)

_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd

Re: (no subject)

On 5 Sep 2011 15:02:45 -0000
"anil  velea" <velea_anil <at> rediffmail.com> wrote:

> Please provide me steps installing jabber server for conferencing and
> chatting. Can I install it on windows server. Please provide the
> documentation. Thanks.
http://www.process-one.net/docs/ejabberd/guide_en.html

Re: MUC - add a JID programmatically to chat "users"

Just to spur some discussion :) I thought of a few less crude ways of
doing this:

1) Still modify mod_muc_room in all the places where it's about to
broadcast a packet to the audience, but instead of hard-coding the
rule about sending to a special configured JID, I'd just add a
run_hook for a new hook, perhaps called muc_send_packet for
consistency.

2) Similar to above, but add the functionality to mod_muc_log instead.
When it's logging an event, have a hook (maybe in this case I'd call
it muc_log_event or something) that could allow my own module to do
what it needs (route a packet). This has the advantage of being
asynchronous with the actual broadcast and saves me from modifying
mod_muc_room.

3) Alternative to 2). Instead of a hook, add some logic to make
mod_muc_log replaceable with a different implementation that follows
the same API, much as is done for auth_module.

Which of these would be best, or is there some yet better idea?

dan

On Thu, Sep 1, 2011 at 7:02 PM, Daniel Dormont <dan <at> greywallsoftware.com> wrote:
> Hi folks,
>
> I have a use case where I would like, every time a particular MUC
> sends out packets to all its users (for example, if a user joins or
> leaves, a groupchat message is posted, etc) to also send it to a
> particular JID that I can designate. But I want it treated more like a
> system account (in fact, it will probably be an external component). I
> don't want this JID listed among the participants so everyone can see
> it, I don't want the groupchat notified if this JID goes offline or
> anything like that. If it *is* offline, I want the messages routed to
> it to silently fail, just like any message routed to an invalid JID.
>
> Basically something similar to mod_service_log, except for instead of
> when the user sends the packet, I want it called with the MUC sends
> the packet. I know I could use mod_service_log itself, but that would
> be called for each packet the MUC sends to each user. That is not what
> I want. I want each packet from the MUC to reach the special JID only
> once.
>
> Looking at the code for mod_muc_room, the only thing I can think of is
> to somehow inject the value in to state.users and modify
> send_existing_presences to somehow exclude this special JID. But that
> seems a little tacky. Is there any better way?
>
> thanks,
> Dan
>

restart strategy for extauth

Hi, I am using extauth and I'm running into a tricky situation: what
happens if my extauth program crashes? As best I can tell, what
happens is the port closes and subsequent auth requests fail with a
message like:

=CRASH REPORT==== 6-Sep-2011::17:33:02 ===
  crasher:
    initial call: gen:init_it/6
    pid: <0.20948.0>
    registered_name: []
    exception exit: {badarg,[{extauth,call_port,2},
                             {ejabberd_auth_external,check_password_extauth,3},
                             {ejabberd_auth,check_password_loop,2},
                             {cyrsasl_plain,mech_step,2},
                             {cyrsasl,server_step,2},
                             {ejabberd_c2s,wait_for_feature_request,2},
                             {p1_fsm,handle_msg,10},
                             {proc_lib,init_p_do_apply,3}]}
      in function  p1_fsm:terminate/7
    ancestors: [ejabberd_c2s_sup,ejabberd_sup,<0.38.0>]
    messages: []
    links: [<0.263.0>]
    dictionary: [{'$internal_queue_len',0},{random_seed,{12982,22012,13984}}]
    trap_exit: false
    status: running
    heap_size: 6765
    stack_size: 24
    reductions: 3268
  neighbours:

Can extauth be configured to restart the program automatically? thanks,

dan

Re: restart strategy for extauth

It won't be restarted, so you will need to use your server monitoring 
tools to make sure that the program is running.

If your extauth program is complex (and consequently crashy), or you 
just want the ability to change or restart the program after it is 
already started, then I suggest you take a look at my post from 
7/13/2011 with Subject "Re: [ejabberd] multiple authentication methods: 
order and priority of operation" where I discuss an approach that allows 
you to restart your extauth program without restarting ejabberd.

Jesse

On 9/7/11 2:32 PM, Daniel Dormont wrote:
> Hi, I am using extauth and I'm running into a tricky situation: what
> happens if my extauth program crashes? As best I can tell, what
> happens is the port closes and subsequent auth requests fail with a
> message like:
>
> =CRASH REPORT==== 6-Sep-2011::17:33:02 ===
>    crasher:
>      initial call: gen:init_it/6
>      pid:<0.20948.0>
>      registered_name: []
>      exception exit: {badarg,[{extauth,call_port,2},
>                               {ejabberd_auth_external,check_password_extauth,3},
>                               {ejabberd_auth,check_password_loop,2},
>                               {cyrsasl_plain,mech_step,2},
>                               {cyrsasl,server_step,2},
>                               {ejabberd_c2s,wait_for_feature_request,2},
>                               {p1_fsm,handle_msg,10},
>                               {proc_lib,init_p_do_apply,3}]}
>        in function  p1_fsm:terminate/7
>      ancestors: [ejabberd_c2s_sup,ejabberd_sup,<0.38.0>]
>      messages: []
>      links: [<0.263.0>]
>      dictionary: [{'$internal_queue_len',0},{random_seed,{12982,22012,13984}}]
>      trap_exit: false
>      status: running
>      heap_size: 6765
>      stack_size: 24
>      reductions: 3268
>    neighbours:
>
> Can extauth be configured to restart the program automatically? thanks,
>
> dan
> _______________________________________________
> ejabberd mailing list
> ejabberd <at> jabber.ru
> http://lists.jabber.ru/mailman/listinfo/ejabberd

_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd

Setting up ejabberd MUC to supplement Google Talk

At my company we use Google Apps for many things (email, calendar,
etc) and that includes their Google Talk service.  I'd like to set up
a conference server that would work with it such that we can have chat
rooms as well.  I know you can create browser-based invite-triggered
impromptu chat rooms, however I'd like something persistent with
actual names.  I could install an IRC server, but then we'd have
multiple logins to manage.

Has anyone tried this before?

Here's the setup (domain sanitized to 'example.com' below)

  * example.com has SRV records pointing to Google Apps, per
http://www.google.com/support/a/bin/answer.py?ans
      $ dig -t any +short _xmpp-server._tcp.example.com
      5 0 5269 xmpp-server.l.google.com.
      20 0 5269 xmpp-server1.l.google.com.
      ...

  * ejabberd server configured as conference.example.com
     {hosts, ["conference.example.com"]}.

  * SRV and A records set up for federation:

      $ dig -t any +short _xmpp-server._tcp.conference.example.com
      20 20 5269 conference.example.com.

      $ dig -t any +short _xmpp-client._tcp.conference.example.com
      20 20 5222 conference.example.com.

      $ dig -t any +short conference.example.com
      xxx.yyy.zzz.www

I've got it listening on 5222/ejabberd_c2s, 5269/ejabberd_s2s_in,
5554/ejabberd_service (jabber-muc).  mod_muc is configured w/
host conference.example.com.  Other modules enabled include
adhoc/announce/caps/configure/admin_extra/disco/last/offline/private/
private/proxy65/roster/stats/time/vcard/version, with all the defaults.

This is on a vanilla Ubuntu 10.04 build, running ejabberd 2.1.2-2ubuntu0.1.

Anyone set up ejabberd to operate in this fashion before?  Have any ideas
or pointers to getting things working?

--

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

Usenet is like Tetris for people who still remember how to read.

Re: Setting up ejabberd MUC to supplement Google Talk

2011/9/7 Bri Hatch <bri <at> ifokr.org>:
> Anyone set up ejabberd to operate in this fashion before?  Have any ideas
> or pointers to getting things working?

You already configured and tried it, but you don't describe what
exactly does not work.

>  * ejabberd server configured as conference.example.com
>     {hosts, ["conference.example.com"]}.
>
> mod_muc is configured w/
> host conference.example.com

I suspect that config won't work, because it provokes a routing
confussion in ejabberd: the XMPP server and the MUC service have the
same JID!

1. Change just one line:
{hosts, ["example.com"]}.
2. Then restart ejabberd.
3. I hope now any other XMPP server can connect directly to mod_muc's
JID, which is conference.example.com and join rooms such as
room123 <at> conference.example.com

---
Badlop
ProcessOne
_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd

Re: restart strategy for extauth

Thanks Jesse. I'll certainly consider that, but I'm hesitant because
authentication to Ejabberd is just one step in a many-part process
that my users are going through at this point in my application, and
this process  (for reasons mostly not related to Ejabberd) is already
slow enough as it is, so I'm hesitant to add more overhead. Especially
so because the code that performs the actual work is written in Java
and depends on Spring.

dan

On Wed, Sep 7, 2011 at 4:01 PM, Jesse Thompson
<jesse.thompson <at> doit.wisc.edu> wrote:
> It won't be restarted, so you will need to use your server monitoring tools
> to make sure that the program is running.
>
> If your extauth program is complex (and consequently crashy), or you just
> want the ability to change or restart the program after it is already
> started, then I suggest you take a look at my post from 7/13/2011 with
> Subject "Re: [ejabberd] multiple authentication methods: order and priority
> of operation" where I discuss an approach that allows you to restart your
> extauth program without restarting ejabberd.
>
> Jesse
>
> On 9/7/11 2:32 PM, Daniel Dormont wrote:
>>
>> Hi, I am using extauth and I'm running into a tricky situation: what
>> happens if my extauth program crashes? As best I can tell, what
>> happens is the port closes and subsequent auth requests fail with a
>> message like:
>>
>> =CRASH REPORT==== 6-Sep-2011::17:33:02 ===
>>   crasher:
>>     initial call: gen:init_it/6
>>     pid:<0.20948.0>
>>     registered_name: []
>>     exception exit: {badarg,[{extauth,call_port,2},
>>
>>  {ejabberd_auth_external,check_password_extauth,3},
>>                              {ejabberd_auth,check_password_loop,2},
>>                              {cyrsasl_plain,mech_step,2},
>>                              {cyrsasl,server_step,2},
>>                              {ejabberd_c2s,wait_for_feature_request,2},
>>                              {p1_fsm,handle_msg,10},
>>                              {proc_lib,init_p_do_apply,3}]}
>>       in function  p1_fsm:terminate/7
>>     ancestors: [ejabberd_c2s_sup,ejabberd_sup,<0.38.0>]
>>     messages: []
>>     links: [<0.263.0>]
>>     dictionary:
>> [{'$internal_queue_len',0},{random_seed,{12982,22012,13984}}]
>>     trap_exit: false
>>     status: running
>>     heap_size: 6765
>>     stack_size: 24
>>     reductions: 3268
>>   neighbours:
>>
>> Can extauth be configured to restart the program automatically? thanks,
>>
>> dan
>> _______________________________________________
>> ejabberd mailing list
>> ejabberd <at> jabber.ru
>> http://lists.jabber.ru/mailman/listinfo/ejabberd
>
>
> _______________________________________________
> ejabberd mailing list
> ejabberd <at> jabber.ru
> http://lists.jabber.ru/mailman/listinfo/ejabberd
>
>

Re: restart strategy for extauth

Yes, you definitely won't want to start up a JVM for every 
authentication request.

So, your options are:

1) Implement your desired crash-detection-restart code in ejabberd 
(you'll need to learn to code in erlang, but if you're successful, then 
you can share the feature back to the ejabberd community)

2) Make your java extauth program bullet proof so that it never crashes.

3) Use the technique that I describe, and implement it so that the 
persistent extauth program communicates with a persistent java program. 
  Then implement the crash-detection-restart code in that extauth program.

Jesse

On 9/7/11 4:07 PM, Daniel Dormont wrote:
> Thanks Jesse. I'll certainly consider that, but I'm hesitant because
> authentication to Ejabberd is just one step in a many-part process
> that my users are going through at this point in my application, and
> this process  (for reasons mostly not related to Ejabberd) is already
> slow enough as it is, so I'm hesitant to add more overhead. Especially
> so because the code that performs the actual work is written in Java
> and depends on Spring.
>
> dan
>
> On Wed, Sep 7, 2011 at 4:01 PM, Jesse Thompson
> <jesse.thompson <at> doit.wisc.edu>  wrote:
>> It won't be restarted, so you will need to use your server monitoring tools
>> to make sure that the program is running.
>>
>> If your extauth program is complex (and consequently crashy), or you just
>> want the ability to change or restart the program after it is already
>> started, then I suggest you take a look at my post from 7/13/2011 with
>> Subject "Re: [ejabberd] multiple authentication methods: order and priority
>> of operation" where I discuss an approach that allows you to restart your
>> extauth program without restarting ejabberd.
>>
>> Jesse
>>
>> On 9/7/11 2:32 PM, Daniel Dormont wrote:
>>>
>>> Hi, I am using extauth and I'm running into a tricky situation: what
>>> happens if my extauth program crashes? As best I can tell, what
>>> happens is the port closes and subsequent auth requests fail with a
>>> message like:
>>>
>>> =CRASH REPORT==== 6-Sep-2011::17:33:02 ===
>>>    crasher:
>>>      initial call: gen:init_it/6
>>>      pid:<0.20948.0>
>>>      registered_name: []
>>>      exception exit: {badarg,[{extauth,call_port,2},
>>>
>>>   {ejabberd_auth_external,check_password_extauth,3},
>>>                               {ejabberd_auth,check_password_loop,2},
>>>                               {cyrsasl_plain,mech_step,2},
>>>                               {cyrsasl,server_step,2},
>>>                               {ejabberd_c2s,wait_for_feature_request,2},
>>>                               {p1_fsm,handle_msg,10},
>>>                               {proc_lib,init_p_do_apply,3}]}
>>>        in function  p1_fsm:terminate/7
>>>      ancestors: [ejabberd_c2s_sup,ejabberd_sup,<0.38.0>]
>>>      messages: []
>>>      links: [<0.263.0>]
>>>      dictionary:
>>> [{'$internal_queue_len',0},{random_seed,{12982,22012,13984}}]
>>>      trap_exit: false
>>>      status: running
>>>      heap_size: 6765
>>>      stack_size: 24
>>>      reductions: 3268
>>>    neighbours:
>>>
>>> Can extauth be configured to restart the program automatically? thanks,
>>>
>>> dan
>>> _______________________________________________
>>> ejabberd mailing list
>>> ejabberd <at> jabber.ru
>>> http://lists.jabber.ru/mailman/listinfo/ejabberd
>>
>>
>> _______________________________________________
>> ejabberd mailing list
>> ejabberd <at> jabber.ru
>> http://lists.jabber.ru/mailman/listinfo/ejabberd
>>
>>
> _______________________________________________
> ejabberd mailing list
> ejabberd <at> jabber.ru
> http://lists.jabber.ru/mailman/listinfo/ejabberd

_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd