headers
alexej | 1 Oct 2010 09:20
Picon

Re: hierarchical MUC refactoring

Ok, thanks for the info, I solved the design problem by delegating one new 
erlang component to manage the visibility lists.

But I am now testing some javascript clients: 

speeqe is nice for my requirements: I can get one anonymous user connected to a 
MUC room, but when I start sending message stanzas I get 503 error service-
unavailable and I am not able to find anything about it:

Request payload:

<body rid='754718221' xmlns='http://jabber.org/protocol/httpbind' 
sid='2df79112bff96456f6f11a99849e03331fdc95b5'><message to='prova <at> vogon' 
from='3360385341285917107278142 <at> vogon/4956608181285917107695830' 
type='groupchat' id='6237' xmlns='jabber:client'><body xmlns='jabber:client'>my 
test message</body><x xmlns='jabber:x:event'><composing/></x></message></body>

Response payload:

<body xmlns='http://jabber.org/protocol/httpbind'><message xmlns='jabber:client' 
from='prova <at> vogon' 
to='3360385341285917107278142 <at> vogon/4956608181285917107695830' type='error' 
id='6237'><body xmlns='jabber:client'>my test message</body><x 
xmlns='jabber:x:event'><composing/></x><error code='503' type='cancel'><service-
unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error></message>
</body>

If use iJab all is going fine with group chats and messages, but I prefer speeqe 
and the Strophe library.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Márcio Luciano Donada | 5 Oct 2010 14:46
Picon

Re: administration of contacts

Em 21/9/2010 12:12, Badlop escreveu:
> 2010/9/21 Márcio Luciano Donada <mdonada <at> auroraalimentos.com.br>:
>> I managed to solve what I wanted, but now the web interface of ejabberd
>> can not erase, in particular user, contacts him
> 
> Your configuration is correct. There was a small bug in the patch.
> 
> Please apply the updated patch, or you can change manually the line,
> see my last comment in
> https://support.process-one.net/browse/EJAB-72
> 

Hi Badlop,
If I have the need to have some users who have access to add other
users, which would be the correct rule to allow this release? In acl roster

{access, roster, [{allow, admin},{allow, user},{deny, all}]}.

Thanks

--

-- 
Márcio Luciano Donada <mdonada -at- auroraalimentos -dot- com -dot- br>
Aurora Alimentos - Cooperativa Central Oeste Catarinense
Departamento de T.I.
_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Permalink | Reply | 3 comments |
headers
Felix Schäfer | 5 Oct 2010 23:53
Gravatar

Roster groups from DB

Hello,

I have seen there is a an extension available to create roster groups, but have seen no mention of being able
to fill said groups from an external source/DB. Is something like that available/possible?

Thanks,

Felix
Permalink | Reply | 0 comments |
headers
Tom | 6 Oct 2010 04:02
Picon

The following CRASH REPORT repeats approx. every 20 seconds

Earlier today, our 4 node ejabberd cluster crashed and after a full stop and restart, we started seeing the following error which repeats approx. every 20 seconds.
This is happening on 3 of the 4 servers.  This was not happening before out crash.

=CRASH REPORT==== 5-Oct-2010::21:39:50 ===
  crasher:
    pid: <0.14135.31>
    registered_name: []
    exception exit: {function_clause,
                        [{ejabberd_c2s,is_ip_blacklisted,[undefined]},
                         {ejabberd_c2s,init,1},
                         {gen_fsm,init_it,6},
                         {proc_lib,init_p,5}]}
      in function  gen_fsm:init_it/6
    initial call: gen:init_it(gen_fsm,<0.287.0>,<0.287.0>,ejabberd_c2s,
                              [{ejabberd_socket,
                                   {socket_state,gen_tcp,#Port<0.1114793>,
                                       <0.14133.31>}},
                               [{access,c2s},
                                {shaper,c2s_shaper},
                                {max_stanza_size,65536}]],
                              [])
    ancestors: [ejabberd_c2s_sup,ejabberd_sup,<0.36.0>]
    messages: []
    links: [<0.287.0>]
    dictionary: []
    trap_exit: false
    status: running
    heap_size: 377
    stack_size: 23
    reductions: 121
  neighbours:

_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Permalink | Reply | 4 comments |
headers
Evgeniy Khramtsov | 6 Oct 2010 04:47
Picon
Gravatar

Re: The following CRASH REPORT repeats approx. every 20 seconds

06.10.2010 12:02, Tom wrote:
> Earlier today, our 4 node ejabberd cluster crashed and after a full stop and
> restart, we started seeing the following error which repeats approx. every
> 20 seconds.
> This is happening on 3 of the 4 servers.  This was not happening before out
> crash.
>
> =CRASH REPORT==== 5-Oct-2010::21:39:50 ===
>    crasher:
>      pid:<0.14135.31>
>      registered_name: []
>      exception exit: {function_clause,
>                          [{ejabberd_c2s,is_ip_blacklisted,[undefined]},
>                           {ejabberd_c2s,init,1},
>                           {gen_fsm,init_it,6},
>                           {proc_lib,init_p,5}]}
>        in function  gen_fsm:init_it/6
>      initial call: gen:init_it(gen_fsm,<0.287.0>,<0.287.0>,ejabberd_c2s,
>                                [{ejabberd_socket,
>                                     {socket_state,gen_tcp,#Port<0.1114793>,
>                                         <0.14133.31>}},
>                                 [{access,c2s},
>                                  {shaper,c2s_shaper},
>                                  {max_stanza_size,65536}]],
>                                [])
>      ancestors: [ejabberd_c2s_sup,ejabberd_sup,<0.36.0>]
>      messages: []
>      links: [<0.287.0>]
>      dictionary: []
>      trap_exit: false
>      status: running
>      heap_size: 377
>      stack_size: 23
>      reductions: 121
>    neighbours:

It seems like you are using some ancient version of ejabberd. This bug 
is fixed in recent versions: 
https://git.process-one.net/ejabberd/mainline/commit/6f080f7fed3c09593beb3daa8136ff56549fd6b7

--

-- 
Regards,
Evgeniy Khramtsov, ProcessOne.
xmpp:xram <at> jabber.ru.
Permalink | Reply | 3 comments |
headers
Tom | 6 Oct 2010 05:05
Picon

Re: The following CRASH REPORT repeats approx. every 20 seconds

Why would we start seeing these errors after our ejabberd crash?  We had been running on 2.0.5 for a while and had not been seeing these errors.

What version was this fixed with?  We had issues with 2.1.5, but it could have been introduced earlier.
Our users are seeing 503s and there doesn't seem to be a way to suppress them.. Until we can fix it with our clients, we need to stay at a version that doesn't give them the 503s.


On Tue, Oct 5, 2010 at 10:47 PM, Evgeniy Khramtsov <xramtsov <at> gmail.com> wrote:
06.10.2010 12:02, Tom wrote:
Earlier today, our 4 node ejabberd cluster crashed and after a full stop and
restart, we started seeing the following error which repeats approx. every
20 seconds.
This is happening on 3 of the 4 servers.  This was not happening before out
crash.

=CRASH REPORT==== 5-Oct-2010::21:39:50 ===
  crasher:
    pid:<0.14135.31>
    registered_name: []
    exception exit: {function_clause,
                        [{ejabberd_c2s,is_ip_blacklisted,[undefined]},
                         {ejabberd_c2s,init,1},
                         {gen_fsm,init_it,6},
                         {proc_lib,init_p,5}]}
      in function  gen_fsm:init_it/6
    initial call: gen:init_it(gen_fsm,<0.287.0>,<0.287.0>,ejabberd_c2s,
                              [{ejabberd_socket,
                                   {socket_state,gen_tcp,#Port<0.1114793>,
                                       <0.14133.31>}},
                               [{access,c2s},
                                {shaper,c2s_shaper},
                                {max_stanza_size,65536}]],
                              [])
    ancestors: [ejabberd_c2s_sup,ejabberd_sup,<0.36.0>]
    messages: []
    links: [<0.287.0>]
    dictionary: []
    trap_exit: false
    status: running
    heap_size: 377
    stack_size: 23
    reductions: 121
  neighbours:

It seems like you are using some ancient version of ejabberd. This bug is fixed in recent versions: https://git.process-one.net/ejabberd/mainline/commit/6f080f7fed3c09593beb3daa8136ff56549fd6b7

--
Regards,
Evgeniy Khramtsov, ProcessOne.
xmpp:xram <at> jabber.ru.

_______________________________________________
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
Permalink | Reply | 2 comments |
headers
Evgeniy Khramtsov | 6 Oct 2010 05:11
Picon
Gravatar

Re: The following CRASH REPORT repeats approx. every 20 seconds

06.10.2010 13:05, Tom wrote:
> Why would we start seeing these errors after our ejabberd crash?  We had
> been running on 2.0.5 for a while and had not been seeing these errors.
>    

No idea. You didn't provide any information about your installation. I'm 
not a telepath.

> What version was this fixed with?  We had issues with 2.1.5, but it could
> have been introduced earlier.
> Our users are seeing 503s and there doesn't seem to be a way to suppress
> them.. Until we can fix it with our clients, we need to stay at a version
> that doesn't give them the 503s.
>    

You can apply the fix from the commit I've pointed to in previous comment.

--

-- 
Regards,
Evgeniy Khramtsov, ProcessOne.
xmpp:xram <at> jabber.ru.
Permalink | Reply | 1 comment |
headers
Tom | 6 Oct 2010 05:23
Picon

Re: The following CRASH REPORT repeats approx. every 20 seconds



On Tue, Oct 5, 2010 at 11:11 PM, Evgeniy Khramtsov <xramtsov <at> gmail.com> wrote:
06.10.2010 13:05, Tom wrote:
Why would we start seeing these errors after our ejabberd crash?  We had
been running on 2.0.5 for a while and had not been seeing these errors.
 

No idea. You didn't provide any information about your installation. I'm not a telepath.


The installation is on CentOS 5.3 using ejabberd-2.0.5-linux-x86-installer.bin in a 4 node environment running against MySQL-server-community-5.0.51a-0.rhel5
 

What version was this fixed with?  We had issues with 2.1.5, but it could
have been introduced earlier.
Our users are seeing 503s and there doesn't seem to be a way to suppress
them.. Until we can fix it with our clients, we need to stay at a version
that doesn't give them the 503s.
 

You can apply the fix from the commit I've pointed to in previous comment.

I'm not sure how to do this.. can the fix be applied to the version I have installed?  If so, are there any docs you can point me to?
 


--
Regards,
Evgeniy Khramtsov, ProcessOne.
xmpp:xram <at> jabber.ru.

_______________________________________________
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
Permalink | Reply | 0 comments |
headers
Badlop | 6 Oct 2010 10:57
Picon

Re: administration of contacts

2010/10/5 Márcio Luciano Donada <mdonada <at> auroraalimentos.com.br>:
> If I have the need to have some users who have access to add other
> users, which would be the correct rule to allow this release? In acl roster
>
> {access, roster, [{allow, admin},{allow, user},{deny, all}]}.

Complete example:

{acl, admin, {user, "bob", "example.org"}}.
{acl, admin, {user, "sarah", "example.org"}}.

{acl, rosterpowerusers, {user, "tim", "jabber.org"}}.
{acl, rosterpowerusers, {user, "jean", "example.org"}}.

{access, roster, [{allow, admin}, {allow, rosterpowerusers},  {deny, all}]}.

{modules,
 [
  ...
  {mod_roster, [{access, roster}]},
  ...
 ]}.

---
Badlop
ProcessOne
_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Permalink | Reply | 2 comments |
headers
Márcio Luciano Donada | 6 Oct 2010 13:32
Picon

Re: administration of contacts

Em 6/10/2010 05:57, Badlop escreveu:
> 2010/10/5 Márcio Luciano Donada <mdonada <at> auroraalimentos.com.br>:
>> If I have the need to have some users who have access to add other
>> users, which would be the correct rule to allow this release? In acl roster
>>
>> {access, roster, [{allow, admin},{allow, user},{deny, all}]}.
> 
> Complete example:
> 
> {acl, admin, {user, "bob", "example.org"}}.
> {acl, admin, {user, "sarah", "example.org"}}.
> 
> {acl, rosterpowerusers, {user, "tim", "jabber.org"}}.
> {acl, rosterpowerusers, {user, "jean", "example.org"}}.
> 
> {access, roster, [{allow, admin}, {allow, rosterpowerusers},  {deny, all}]}.
> 
> {modules,
>  [
>   ...
>   {mod_roster, [{access, roster}]},
>   ...
>  ]}.
> 

Hi, Badlop
I've been doing some testing tonight with a server that rode with the
backup of my production and I noticed some items that would be
interesting to evaluate you as well. In the first test I did the following:

{acl, liberados, {user "fulano", "mydomain.foo"}}.
{acl, liberados, {user "beltrano","mydomain.foo"}}.

{access, roster, [{allow,admin},{allow,liberados},{deny,all}]}.

I found that with these rules:

- To conduct the first test, the user can add others, however, by
removing the acl, user beltrano, for example, yet it stays the same with
the right to add other users, which should not.

- Second test I created separate groups for each user that I wish I had
the same access and oh yes it worked properly.

I'm using version 2.1.5 of ejabberd on FreeBSD, I performed the update
and applied the patch last week.

Thank you for your attention.
--

-- 
Márcio Luciano Donada <mdonada -at- auroraalimentos -dot- com -dot- br>
Aurora Alimentos - Cooperativa Central Oeste Catarinense
Departamento de T.I.
_______________________________________________
ejabberd mailing list
ejabberd <at> jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Permalink | Reply | 1 comment |

Gmane