On Thu, Apr 14, 2016 at 04:19:06PM +0200, Matěj Cepl wrote:
> On 2016-04-14, 10:26 GMT, Adrian Reber wrote:
> > In the configuration I am running jabberd2 on Fedora I did not
> > have many (maybe any) upgrading the last few versions. EPEL-7
> > would be an upgrade from 2.3.2 to 2.3.6. It
On Thu, Apr 14, 2016 at 10:49:30AM +0200, Matěj Cepl wrote:
> On 2016-04-14, 06:27 GMT, Adrian Reber wrote:
> > On Wed, Apr 13, 2016 at 09:19:45AM -0700, John Oliver wrote:
> >> 1) Is this project the 'jabberd' that's available in EPEL?
> >
> > I can answer that one. jabberd in EPEL is jabberd2.
On 2016-04-14, 06:27 GMT, Adrian Reber wrote:
> On Wed, Apr 13, 2016 at 09:19:45AM -0700, John Oliver wrote:
>> 1) Is this project the 'jabberd' that's available in EPEL?
>
> I can answer that one. jabberd in EPEL is jabberd2. As it is EPEL it
> will not see as many updates as the upstream package
On Wed, Apr 13, 2016 at 09:19:45AM -0700, John Oliver wrote:
> 1) Is this project the 'jabberd' that's available in EPEL?
I can answer that one. jabberd in EPEL is jabberd2. As it is EPEL it
will not see as many updates as the upstream package
Adrian
1) Is this project the 'jabberd' that's available in EPEL?
2) Can jabberd2 authenticate against LDAP?
3) Can jabberd2 have users auto-join or automatically be buddies?
Thanks...
--
***
* John Oliver
Hi,
I've finally been able to get it working after few modifications.
First, as I was getting an error ([error] failed loading storage module
'ldapvcard' (/usr /lib/jabberd/storage_ldapvcard.so: undefined symbol:
_ldap_get_lderrno)) while trying to use as storage ldapvcard, I removed
the
Le 18/10/2012 16:42, Tomasz Sterna a écrit :
Dnia 2012-10-18, czw o godzinie 16:12 +0200, Alexandre Jousset pisze:
What if you do not manage all the routers in the mesh?
And you were given a password to access only one or two routers of the
mesh?
I think it is pretty unusual for the
About this topic, I have some more comments and questions:
Le 15/10/2012 02:22, Alexandre Jousset a écrit :
Le 12/10/2012 19:53, Tomasz Sterna a écrit :
We do. In the simplest way to do it, routers don't forward other routers'
binding requests. Of course it is possible
Dnia 2012-10-15, pon o godzinie 02:22 +0200, Alexandre Jousset pisze:
We talked earlier about weighted randomization instead of
priorities. With weighted randomization it is impossible to be sure
that a local component will be preferred, this is why I made an
implicit priority for
Le 15/10/2012 10:03, Tomasz Sterna a écrit :
Dnia 2012-10-15, pon o godzinie 02:22 +0200, Alexandre Jousset pisze:
We talked earlier about weighted randomization instead of
priorities. With weighted randomization it is impossible to be sure
that a local component will be preferred,
Dnia 2012-10-15, pon o godzinie 12:15 +0200, Alexandre Jousset pisze:
But I still don't see a rationale, why local components are better
than
remote ones?
Why does local component should be preferred just because the
connection
happened to come from local c2s?
Going to a
Le 15/10/2012 14:43, Tomasz Sterna a écrit :
Dnia 2012-10-15, pon o godzinie 12:15 +0200, Alexandre Jousset pisze:
But I still don't see a rationale, why local components are better
than
remote ones?
Why does local component should be preferred just because the
connection
happened to come
I respond to this message back in time to ask a question:
Le 11/09/2012 13:35, Tomasz Sterna a écrit :
[...]
Components have its own names.
Each component needs to be uniquely named.
Is it because components could previously have same names that there is «
Le 15/10/2012 19:38, Tomasz Sterna a écrit :
Dnia 2012-10-15, pon o godzinie 18:29 +0200, Alexandre Jousset pisze:
Is it because components could previously have same names that
there is « switch(targets-rtype) » at router/router.c:502, and all
the multi attribute, route_MULTI_TO and
Dnia 2012-10-13, sob o godzinie 22:37 +1100, James Wilson pisze:
Just thought of this: if you use an 'auto-config' type setting
perhaps we could take a 'Bonjour' like route in that each server
broadcasts within its local IP range / subnet for other XMPP servers
and makes a live, real time list
Le 12/10/2012 19:53, Tomasz Sterna a écrit :
We do. In the simplest way to do it, routers don't forward other
routers' binding requests. Of course it is possible to implement it to allow
multi-hops, but I'm afraid this could lead to problems (and inefficiency) for
no real gain (except
Just thought of this: if you use an 'auto-config' type setting, perhaps we
could take a 'Bonjour' like route in that each server broadcasts within its
local IP range / subnet for other XMPP servers and makes a live, real time list
of available instances.
Regards,
James
This message was
Dnia 2012-10-12, pią o godzinie 17:18 +0200, Alexandre Jousset pisze:
Maybe it would be a good thing to say this (only 1 SM per domain to use
less memory) in the install / config guide after the changes.
I've now reread it and got it.
Yes, it is worth mentioning in the documentation.
Dnia 2012-09-19, śro o godzinie 01:19 +0200, Alexandre Jousset pisze:
You need bare-jid level binds only when there is more than one component
handling the domain. If there is only one, you can do domain based
routing without the need for user@domain binding.
This approach does not use
Dnia 2012-09-19, śro o godzinie 05:08 +0200, Alexandre Jousset pisze:
I don't see any need to stick with a (now weighted) random
decision, other than in the user@domain auto-bind case.
According to the pseudo code I've just written there are 3
cases where the router makes a
and /
or more questions.
--
-- \^/--
---/ O \-----
-- | |/ \| Alexandre (Midnite) Jousset | --
---|___|-----
Dnia 2012-09-18, wto o godzinie 21:50 +0200, Alexandre Jousset pisze:
About routing levels and the user@domain binding... With this
solution, there's no more domain-only level at the beginning, so each
SM should bind directly bare JIDs and domains (still with
auto-binding).
Le 19/09/2012 00:19, Tomasz Sterna a écrit :
Dnia 2012-09-18, wto o godzinie 21:50 +0200, Alexandre Jousset pisze:
About routing levels and the user@domain binding... With this
solution, there's no more domain-only level at the beginning, so each
SM should bind directly bare JIDs and domains
About this, and after reading/writing other posts in other parts of
this thread:
Le 17/09/2012 17:50, Tomasz Sterna a écrit :
I would just make it temporary and extend it to all routing levels.
Whenever the router makes a (random) decision to choose one of equal
binds to route to, it
Le 17/09/2012 10:05, Tomasz Sterna a écrit :
Dnia 2012-09-16, nie o godzinie 23:06 +0200, Alexandre Jousset pisze:
Err... Sorry again, but in case of delivery I've found that:
http://xmpp.org/rfcs/rfc3921.html#rules (see 11.1.4.1 for messages)...
This page was what I saw before posting
Dnia 2012-09-17, pon o godzinie 10:55 +0200, Alexandre Jousset pisze:
The question was:
But then - what happens if two resources of the same priority get
connected to two different sm instances?
After reading the link I posted in my previous message, I
don't see what
Le 17/09/2012 11:02, Tomasz Sterna a écrit :
Dnia 2012-09-17, pon o godzinie 10:55 +0200, Alexandre Jousset pisze:
The question was:
But then - what happens if two resources of the same priority get
connected to two different sm instances?
After reading the link I
Le 17/09/2012 13:10, Tomasz Sterna a écrit :
Again.
There is 'u...@example.com/foo' resource with priority 1 bound on sm1.
There is 'u...@example.com/bar' resource with priority 1 bound on sm2.
1. There is an incoming iq-get request for u...@example.com vCard.
- it is being sent to sm1 and
Dnia 2012-09-17, pon o godzinie 14:29 +0200, Alexandre Jousset pisze:
I see a possibility for this but it looks hackish...: router
looks into the messages when there are more than 1 possible recipient
component (in user@domain case). If it is an IQ = it generates the
error itself. Or
Le 14/09/2012 16:08, Tomasz Sterna a écrit :
Let's say, that we won't allow several SM instances handle resources of
the same user.
How? This needs tiny modification of C2S/SM protocol. Instead sending
the user session creation request to the user domain, let's send it to
the user bare-JID.
Dnia 2012-09-17, pon o godzinie 17:25 +0200, Alexandre Jousset pisze:
(There is a possibility of race - handling several session creation
requests by router and pushing to several random SMs, before first
one
binds user bare JID.)
This case could be resolved if the router
Le 14/09/2012 21:17, Tomasz Sterna a écrit :
There is nothing in XMPP about delivering to most recent resource.
I would like to stick to the specification :-)
Sorry, I mixed the notions of binding and delivering :-(
--
-- \^/--
---/
Le 16/09/2012 21:54, Alexandre Jousset a écrit :
Le 14/09/2012 21:17, Tomasz Sterna a écrit :
There is nothing in XMPP about delivering to most recent resource.
I would like to stick to the specification :-)
Sorry, I mixed the notions of binding and delivering :-(
Err... Sorry
Hi,
Le 13/09/2012 16:15, James Wilson a écrit :
I've been watching this discussion unfold and thought I might contribute.
Thanks for your contribution.
Personally, I have not ran a jabberd2 instance in a long time, but this
question below:
On 13/09/2012, at 11:35 PM,
Dnia 2012-09-14, pią o godzinie 00:15 +1000, James Wilson pisze:
It should be noted this is a hair-brained idea that has no testing or
code to back it up.
1) Lets just say that, for arguments sake, you have an SM instance
setup within the cluster that says:
I will accept ONLY
Le 14/09/2012 16:08, Tomasz Sterna a écrit :
[...]
(There is a possibility of race - handling several session creation
requests by router and pushing to several random SMs, before first one
binds user bare JID.)
This race condition, in theory, has small probability to happen, but
Dnia 2012-09-14, pią o godzinie 15:50 +0200, Alexandre Jousset pisze:
I was thinking about another idea: AFAIK the protocol says
that in that case the message should either be duplicated, and we've
seen previously that this may lead to problems (IQs, ACKs), or sent to
one of the
Dnia 2012-09-14, pią o godzinie 17:10 +0200, Alexandre Jousset pisze:
This race condition, in theory, has small probability to
happen, but actually I see some cases where it is possible (e.g. c2s
crash and / or restart, some network problems...), especially with a
lot of users and
Le 13/09/2012 00:05, Tomasz Sterna a écrit :
[...]
Looks simple.
Too simple? ;-)
It's never too simple :-) I think that, as you said before, the
current implementation was designed open enough to be adapted and that will greatly
simplify the coding of these new features.
In real
Dnia 2012-09-13, czw o godzinie 13:45 +0200, Alexandre Jousset pisze:
AFAIK the routing to a domain is done only from c2s to sm when
a user connects. Then the sm answers with the domain in the from
part and gives its ID too for further communication. So, after this
moment c2s knows to
Le 13/09/2012 14:57, Tomasz Sterna a écrit :
Dnia 2012-09-13, czw o godzinie 13:45 +0200, Alexandre Jousset pisze:
AFAIK the routing to a domain is done only from c2s to sm when
a user connects. Then the sm answers with the domain in the from
part and gives its ID too for further
Dnia 2012-09-13, czw o godzinie 15:07 +0200, Alexandre Jousset pisze:
But then - what happens if two resources of the same priority get
connected to two different sm instances?
*This* was my real question ;-)
I don't have answer.
Will have to think about it.
--
/\_./o__
Hi everyone,
I've been watching this discussion unfold and thought I might contribute.
Personally, I have not ran a jabberd2 instance in a long time, but this
question below:
On 13/09/2012, at 11:35 PM, Tomasz Sterna wrote:
Dnia 2012-09-13, czw o godzinie 15:07 +0200, Alexandre Jousset
Dnia 2012-09-12, śro o godzinie 20:22 +0200, Alexandre Jousset pisze:
How do you recover from this split when parts get reconnected? :-)
Well, why not behave as if it was a normal bind?
I haven't thought a lot about it, I definitely need to do it,
but in my first thoughts
Dnia 2012-09-10, pon o godzinie 19:40 +0200, Alexandre Jousset pisze:
with separate set of 'ad...@example.org/something' full-JIDs.
Ok for this. I'll use linked lists, which will be pretty small
after all (and ordered, too).
Or you can just stick to one routing table for all
at the process you sent earlier, and I could start to
think about the tree structure just by following the process.
That led me to have to ask some questions about this:
1) A minor one: is it right that it's a typo when you wrote example.org
instead of example.com at some places
the answer in the online docs,
but as I have you at hand ;-) Is it possible to have 2 full-JIDs connected at the same
time? With equal or different priorities? I suppose the answer is no to both
questions, but just to be sure...
Obviously, no.
6) The tree structure I'm thinking about
Dnia 2012-09-01, sob o godzinie 00:21 +0200, Alexandre Jousset pisze:
I didn't want to create huge routing tables too. c2s and sm are quite
big memory consumers when many users are connected, I didn't want to
make the router the same. But I'm afraid this is unavoidable.
The good thing is that
Hi Tomasz,
Thanks for your answer. I'll study your message in detail when I'll
have time to. I think I'll be able to work on this topic during the week-end.
Regards,
--
-- \^/--
---/ O
I always find this annotation as misleading. It tightens the current
habbit of tightly binding services with servers.
Yeah, that's the main thing about it that bothered me. The standards
seem to encourage the use of sub-domains for naming services. The
examples in XEP-0030 place each service on a
Hi Keith,
I did some investigations on this topic last year. As far as I see it is
not possible without rewriting the sm-component to pass some iq-stanzas
to its clients.
My approach was to write a component that binds to a dummy-domain and
simulates a c2s-connection (e.g. the component starts a
Dnia 2011-01-31, pon o godzinie 23:23 -0800, Keith Jay Gillis pisze:
A host that offers text-based conferencing capabilities; often but not
necessarily a sub-domain of a Jabber server (e.g.,
conference.jabber.org).
I always find this annotation as misleading.
It tightens the current habbit of
Hi,
XEP-0045 defines a multi-user chat service as:
A host that offers text-based conferencing capabilities; often but not
necessarily a sub-domain of a Jabber server (e.g.,
conference.jabber.org).
Is it possible to use mu-conference with jabberd2 without putting
mu-conference on a sub-domain?
Hello.
I have jabberd2 mostly up and running.
Could somebody please clarify exactly which settings should be set to
completely deny unencrypted client-to-server and client-to-client
communications?
Also, what's the simplest way to deny the setting of account passwords
of less than a given
54 matches
Mail list logo
