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 probabl
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 probably depends
> on the installation and which backends are used if the
On 2016-04-14, 10:38 GMT, Tomasz Sterna wrote:
> W dniu 14.04.2016, czw o godzinie 10∶49 +0200, użytkownik Matěj Cepl
> napisał:
>> Do we know what is the upgrade story? Does the latest jabberd2
>> just takes over the original configuration?
>
> Upgrade path is documented:
> https://github.com/jab
W dniu 13.04.2016, śro o godzinie 09∶19 -0700, użytkownik John Oliver
napisał:
> 2) Can jabberd2 authenticate against LDAP?
Yes it can.
Use authreg_ldap or authreg_ldapfull backend.
> 3) Can jabberd2 have users auto-join or automatically be buddies?
Kind of...
storage_ldapvcard module pulls ros
W dniu 14.04.2016, czw o godzinie 10∶49 +0200, użytkownik Matěj Cepl
napisał:
> Do we know what is the upgrade story? Does the latest jabberd2
> just takes over the original configuration?
Upgrade path is documented:
https://github.com/jabberd2/jabberd2/blob/master/NEWS
--
/o__
(_<^' Some pe
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. As
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 exte
Hi,
I've been using jabberd2 for more than two years in our research unit. During
this time the amount of people has increase although some people has gone.
I am tired of adding and removing people from our roster template and from our
xmpp client, pidgin. Therefore, I decided to switch to
lda
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 ad
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 admin not to have access to all
>
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 p
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-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 route_MULTI_FROM?
> If not, I have
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 «
switch(targets->rtyp
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 f
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?
>
> G
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, this
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 l
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
>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 ti
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
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.
Le 09/10/2012 08:26, Tomasz Sterna a écrit :
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
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 mak
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
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 st
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 (
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).
>
> M
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 sticks to this decision for a predefined time.
Hmm... I was thinking while writing
'll keep you informed when there will be something interesting and /
or more questions.
--
-- \^/--
---/ O \-----
-- | |/ \| Alexandre (Midnite) Jousset | --
---|___|-----
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 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.
This
Le 17/09/2012 15:39, Tomasz Sterna a écrit :
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
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
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 sm2
Dnia 2012-09-17, pon o godzinie 12:12 +0200, Alexandre Jousset pisze:
> >> The router should send the messages to both SMs where the
> >> resources with same priority are bound, they will know what to do
> with
> >> them.
> >
> > What about iq and/or presence?
> >
> > - iq-get would get tw
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 po
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
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-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 my solution (I remember now).
>
>
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... Sor
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" :-(
--
-- \^/--
--
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 a
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 rec
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
actua
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 O
Alexandre,
Ha! I thought this was perhaps a little more complex then needed, but then
again, I've never been one for 'simple' solutions. :)
Your suggestion sounds really good, and would seem to work given that the most
recently-started session seems to be the most logical data-object to use.
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, Tomasz
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 pisz
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.
--
/\_
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 comm
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 know
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 l
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 th
Le 11/09/2012 13:35, Tomasz Sterna a écrit :
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 ju
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 con
rs used as components).
Please read my comments interspersed between yours and at the end of
this email I'll detail my ideas and ask you some questions.
Le 06/09/2012 10:36, Tomasz Sterna a écrit :
Dnia 2012-09-06, czw o godzinie 00:29 +0200, Alexandre Jousset pisze:
2) Is is OK to
on, I know I could find 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...
r protocol question, I know I could find 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...
t 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 s
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 tha
Hi again,
Le 29/08/2012 15:13, Tomasz Sterna a écrit :
Dnia 2012-08-29, śro o godzinie 08:08 +0200, Alexandre Jousset pisze:
I wondered if it was possible to run it in a cluster.
The answer is clearly "no", as far as I understood it.
[...]
I decided to think about what would be neede
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 \
Dnia 2012-08-29, śro o godzinie 08:08 +0200, Alexandre Jousset pisze:
> I wondered if it was possible to run it in a cluster.
> The answer is clearly "no", as far as I understood it.
[...]
> I decided to think about what would be needed to "clusterize" jabberd2. The
> result of my thoughts can be
Hi all,
I tested jabberd2 and, like a lot of people I wondered if it was
possible to run it in a cluster.
The answer is clearly "no", as far as I understood it.
I liked the way jabberd2 was implemented and, after roughly testing other
technologies, I decided to
"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
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
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
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? Do
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 length
74 matches
Mail list logo