| Author |
Message |
|
| Guest |
 Posted: Sat Sep 23, 2006 3:15 pm |
 |
|
|
Guest
|
Hello,
Just a quick notice to let you know that we have started preparing
ejabberd version 1.1.2.
This version promotes many changes since ejabberd 1.1.1.
Improvements include:
- Major improvements on the LDAP module. It is now more flexible and
should work in a much larger number of cases.
- Roster management improvements to make it more reliable (especially in
cases where users are on different servers).
- Improved robustness: It is now possible to limit the number of opened
connections for a single user.
- Database support: Microsoft SQL Server is now officially supported
(ODBC mode).
- Improved MUC component.
- Shared rosters are now more reliable.
- Anonymous login bugfixes.
- Some protocol compliance small bugs have been fixed.
- The command line tool ejabberdctl has been improved.
- The build chain has been improved, including MacOSX support.
- A Czech translation has been added.
As we have already started working on version 1.2, a branch has been
created in SVN and can be checked out with the following command:
svn co https://svn.process-one.net/ejabberd/branches/ejabberd-1.1.2/
For those that prefer downloading a .tar.gz archive, they can head to:
http://www.process-one.net/en/projects/ejabberd/download/beta/ejabberd-1.1.2_beta1.tar.gz
The complete list of changes for this version is available from the
following (long) URL:
https://support.process-one.net/secure/ConfigureReport.jspa?filterid=10110&mapper=components&selectedProjectId=10011&reportKey=com.atlassian.jira.plugin.system.reports%3Asinglelevelgroupby&Next=Next
You can start beta testing the version and share any problem found with
this version.
We are currently preparing the binary installers to make them ready for
the final release.
Cheers,
--
Micka |
|
|
| Back to top |
|
| Guest |
| Posted: Sat Sep 23, 2006 6:41 pm |
|
|
|
Guest
|
2006/9/23, Mickael Remond <mickael.remond@process-one.net>:
> You can start beta testing the version and share any problem found with
> this version.
There's a bug with the HTTP-Poll timeout. Since 1.1.2 will not include
HTTP-Bind yet, the bug should be fixed on 1.1.2.
I've just tested this beta and the bug still happens:
http://www.jabber.ru/bugzilla/show_bug.cgi?id=266
The severity of this bug can be considered 'severe' since http-poll is
used almost only for JWChat, and closing sessions is critical to not
miss messages, etc. With this bug, it should be better to not enable
the HTTP-Poll component.
--
_______________________________________________
ejabberd mailing list
ejabberd@jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sat Sep 23, 2006 6:47 pm |
|
|
|
Guest
|
Le Sat, 23 Sep 2006 20:40:51 +0200, Badlop <badlop@gmail.com> m'a avoué:
> 2006/9/23, Mickael Remond <mickael.remond@process-one.net>:
> > You can start beta testing the version and share any problem found with
> > this version.
>
> There's a bug with the HTTP-Poll timeout. Since 1.1.2 will not include
> HTTP-Bind yet, the bug should be fixed on 1.1.2.
Could you confirm that this bug also exist in 1.1.1 ?
> I've just tested this beta and the bug still happens:
> http://www.jabber.ru/bugzilla/show_bug.cgi?id=266
>
> The severity of this bug can be considered 'severe' since http-poll is
> used almost only for JWChat, and closing sessions is critical to not
> miss messages, etc. With this bug, it should be better to not enable
> the HTTP-Poll component.
--
Beber - E-Mail / Jabber (+GMail) : beber_AT_meleeweb.net
http://www.meleeweb.net
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sun Sep 24, 2006 2:00 am |
|
|
|
Guest
|
On Sat, Sep 23, 2006 at 05:12:09PM +0200, Mickael Remond wrote:
> - Improved robustness: It is now possible to limit the number of opened
> connections for a single user.
This is a good fix. In general I think that if a server does not enable
the admin to limit the number of simultaneous connections per user, it
is possible to launch a denial of service attack against the server (or
at least that is my experience with other server codebases).
Peter
_______________________________________________
ejabberd mailing list
ejabberd@jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sun Sep 24, 2006 8:42 am |
|
|
|
Guest
|
Hello Badlop,
* Badlop <badlop@gmail.com> [2006-09-23 20:40:51 +0200]:
> 2006/9/23, Mickael Remond <mickael.remond@process-one.net>:
> >You can start beta testing the version and share any problem found with
> >this version.
>
> There's a bug with the HTTP-Poll timeout. Since 1.1.2 will not include
> HTTP-Bind yet, the bug should be fixed on 1.1.2.
>
> I've just tested this beta and the bug still happens:
> http://www.jabber.ru/bugzilla/show_bug.cgi?id=266
>
> The severity of this bug can be considered 'severe' since http-poll is
> used almost only for JWChat, and closing sessions is critical to not
> miss messages, etc. With this bug, it should be better to not enable
> the HTTP-Poll component.
This bug exists in 1.1.1 but should normally have been fixed in 1.1.2:
We are using http-poll in this version and it is working correctly.
I need more information on what could be going wrong in your case. You
said this is working correctly with tkabber and not JWchat. Do you have
a TCP dump of the difference between the two clients?
In the meantime I will look again at the code to see if I can imagine a
case where the timeout could not be triggered.
Thank you !
--
Micka |
|
|
| Back to top |
|
| Guest |
| Posted: Sun Sep 24, 2006 8:58 am |
|
|
|
Guest
|
|
| Back to top |
|
| Guest |
| Posted: Sun Sep 24, 2006 9:05 am |
|
|
|
Guest
|
Hello Peter,
* Peter Saint-Andre <stpeter@jabber.org> [2006-09-23 20:59:47 -0500]:
> On Sat, Sep 23, 2006 at 05:12:09PM +0200, Mickael Remond wrote:
>
> > - Improved robustness: It is now possible to limit the number of opened
> > connections for a single user.
>
> This is a good fix. In general I think that if a server does not enable
> the admin to limit the number of simultaneous connections per user, it
> is possible to launch a denial of service attack against the server (or
> at least that is my experience with other server codebases).
To my knowledge, all servers are vulnerable at different level.
If you do not limit the number of opened connections per user, each new
connection create a presence broadcast to the previous ones and from
the previous ones to the new one.
Depending on the server, it will crash at different level. At 500 opened
connections for a single user, all servers should be very slow to
respond, if they do not have crashed before.
I suggest to use this new options to limit the number of connections per
user to 10 on a production server.
--
Micka |
|
|
| Back to top |
|
| Guest |
| Posted: Sun Sep 24, 2006 9:34 am |
|
|
|
Guest
|
2006/9/24, Mickael Remond <mickael.remond@process-one.net>:
> This bug exists in 1.1.1 but should normally have been fixed in 1.1.2:
I've just tried again with 1.1.2, and it seems to be fixed 
Since I tested several versions (1.0.0, 1.1.1, 1.1.2, svn), maybe I
forgot to reduce the timeout on 1.1.2.
BTW, the timeout is default to 5 minutes. JWChat has configurable poll
intervals of 1 second up to 30. Is there any point in having a timeout
of 300 seconds? Shouldn't 35 seconds, or 60, be more appropiate?
Curiosity: This is the log when closing a JWChat client on
ejabberd+Yaws 1.64. Even with that Yaws ERROR, the session is closed
correctly after the timeout:
=INFO REPORT==== 24-Sep-2006::11:19:09 ===
I(<0.294.0>:ejabberd_listener:90): (#Port<0.853>) Accepted connection
{{127,0,0,1},46122} -> {{127,0,0,1},5280}
=INFO REPORT==== 24-Sep-2006::11:19:09 ===
I(<0.288.0>:ejabberd_http:76): started: {gen_tcp,#Port<0.853>}
=INFO REPORT==== 24-Sep-2006::11:19:09 ===
I(<0.294.0>:ejabberd_listener:90): (#Port<0.858>) Accepted connection
{{127,0,0,1},40460} -> {{127,0,0,1},5280}
=INFO REPORT==== 24-Sep-2006::11:19:09 ===
I(<0.727.0>:ejabberd_http:175): (#Port<0.853>) http query: 'POST' /http-poll/
=INFO REPORT==== 24-Sep-2006::11:19:09 ===
I(<0.288.0>:ejabberd_http:76): started: {gen_tcp,#Port<0.858>}
=INFO REPORT==== 24-Sep-2006::11:19:09 ===
I(<0.730.0>:ejabberd_http:175): (#Port<0.858>) http query: 'POST' /http-poll/
=ERROR REPORT==== 24-Sep-2006::11:19:09 ===
Yaws process died: {{error,ebadf},
[{yaws,gen_tcp_send,2},
{yaws_revproxy,ploop,3},
{yaws_server,aloop,3},
{yaws_server,acceptor0,2},
{proc_lib,init_p,5}]}
=INFO REPORT==== 24-Sep-2006::11:19:22 ===
I(<0.702.0>:ejabberd_c2s:1161): ({http_poll,<0.701.0>}) Close session
for user@localhost/jwchat
--
_______________________________________________
ejabberd mailing list
ejabberd@jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Sun Sep 24, 2006 9:49 am |
|
|
|
Guest
|
* Badlop <badlop@gmail.com> [2006-09-24 11:33:40 +0200]:
> 2006/9/24, Mickael Remond <mickael.remond@process-one.net>:
> >This bug exists in 1.1.1 but should normally have been fixed in 1.1.2:
>
> I've just tried again with 1.1.2, and it seems to be fixed
>
> Since I tested several versions (1.0.0, 1.1.1, 1.1.2, svn), maybe I
> forgot to reduce the timeout on 1.1.2.
>
> BTW, the timeout is default to 5 minutes. JWChat has configurable poll
> intervals of 1 second up to 30. Is there any point in having a timeout
> of 300 seconds? Shouldn't 35 seconds, or 60, be more appropiate?
I thought the same, but I have discussed this with Alexey and and told
that a very big timeout is necessary to deal with bad link quality.
That's why we have let it at 5 minutes.
However, I think it make sense to make this an option to override the
timeout value from the config file directly.
> Curiosity: This is the log when closing a JWChat client on
> ejabberd+Yaws 1.64. Even with that Yaws ERROR, the session is closed
> correctly after the timeout:
Yaws says there is an error, because he tries to push something back to
the client socket, whereas there is no more remote peer.
However, this is not a real "error" as from Yaws sysadmin point of view,
the system is working correctly. This is a "client-side error" and
should probably be reported as an info.
The same happens when you download a big file and interrupt the download
from the client side.
I will submit the idea to change this to the Yaws mailing list.
--
Micka |
|
|
| Back to top |
|
| Guest |
| Posted: Sun Sep 24, 2006 3:19 pm |
|
|
|
Guest
|
Op zaterdag 23 september 2006 17:12, schreef Mickael Remond:
<snip>
> As we have already started working on version 1.2, a branch has been
> created in SVN and can be checked out with the following command:
> svn co https://svn.process-one.net/ejabberd/branches/ejabberd-1.1.2/
>
> For those that prefer downloading a .tar.gz archive, they can head to:
>
> http://www.process-one.net/en/projects/ejabberd/download/beta/ejabberd-1.1.
>2_beta1.tar.gz
<snip>
> You can start beta testing the version and share any problem found with
> this version.
I made a patch that is only compatible with this beta; I'm not going to make
it compatible with 1.1.1 so that people have an additional incentive to test
the beta these days (yes, and also because I'm a bit lazy  ).
Features:
* ejabberdctl: no something@host needed anymore
* ejabberdctl: configuration file
* some other ejabberdctl enhancements
* ejabberd.inetrc included to bypass a bug in some Erlang versions
* ejabberdctl: starting ejabberd
* ejabberdctl: open an Erlang console
Requirements:
* a userfriendly operating system that has basic tools like an sh compatible
shell pre-installed
* it will probably also work on the userunfriendly operating system if you
install an sh compatible shell and other basic tools on it (correct me if
this sentence needs to be in plurar)
The instructions:
1) Unpack the archive in the src directory of ejabberd-1.1.2_beta1 (yes,
configure.ac and Makefile.in must be replaced)
2) Run autoconf in the src directory
3) Run the configure script with the desired parameters, compile, and install
4) Create a user to run ejabberd with (e.g. adduser ejabberd)
5) Give this user permissions to the automatically created log and data
directories (e.g: chown -R
ejabberd:ejabberd /usr/local/var/log/ejabberd /usr/local/var/lib/ejabberd/data)
6) Eventually edit ejabberd.cfg (by default installed
in /usr/local/etc/ejabberd): at least add an admin acl if you want to test
the web interface and/or Ad Hoc client-side configurarion: {acl, admin,
{user, "theadmin"}}.)
7) Switch to this user and run ejabberdctl showconfig to see of you like to
see if the ejabberdctl config file is ok for you (normally it should suit
your "testing ejabberd needs").
 Run ejabberdctl start
9) Eventually create the admin account(s) you specified in ejabberd's
configuration: ejabberdctl register theadmin localhost password
That's all: now you can start testing the beta and reporting as much as
possible bugs!
--
Mvg, Sander Devrieze.
xmpp:sander@devrieze.dyndns.org
ejabberd, the expandable Jabber daemon. --
http://ejabberd.jabber.ru/
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Mon Sep 25, 2006 2:58 am |
|
|
|
Guest
|
On Sun, Sep 24, 2006 at 11:02:34AM +0200, Mickael Remond wrote:
> Hello Peter,
>
> * Peter Saint-Andre <stpeter@jabber.org> [2006-09-23 20:59:47 -0500]:
>
> > On Sat, Sep 23, 2006 at 05:12:09PM +0200, Mickael Remond wrote:
> >
> > > - Improved robustness: It is now possible to limit the number of opened
> > > connections for a single user.
> >
> > This is a good fix. In general I think that if a server does not enable
> > the admin to limit the number of simultaneous connections per user, it
> > is possible to launch a denial of service attack against the server (or
> > at least that is my experience with other server codebases).
>
> To my knowledge, all servers are vulnerable at different level.
Sure. Probably it would be good to define some best practices to reduce
the potential for DoS attacks.
> If you do not limit the number of opened connections per user, each new
> connection create a presence broadcast to the previous ones and from
> the previous ones to the new one.
> Depending on the server, it will crash at different level. At 500 opened
> connections for a single user, all servers should be very slow to
> respond, if they do not have crashed before.
In my experience, 50 connections is enough to cause serious trouble.
> I suggest to use this new options to limit the number of connections per
> user to 10 on a production server.
That sounds reasonable.
Peter
--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml
_______________________________________________
ejabberd mailing list
ejabberd@jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
