I am using openfire 3.3.1 now, and 2000 users. SQL Server as database.
How to move these to ejabberd?
Thanks.
Looking for ejabberd docs?
To access the most up-to-date ejabberd documentation, please visit docs.ejabberd.im »
How to move openfire to ejabberd?
Why?
If you don't mind me asking. Why are you moving over to ejabberd?
We are trying to decide between the two and would appreciate input.
Thank you,
Ethan
http://www.jabber.org/admin/j
btw: this page needs to be updated
--
sander
Ejabberd vs Openfire
I'm looking to convert myself simply because Openfire, like most commercial solutions is to closed off. We aren't able to tie things in like we want. And also several features that are 'supposed' to work, don't. So I'd like to find a way to port users over as well. But I'm still struggling just getting ejabberd up and running.
Kevin
???
Why do want to switch? I considered for a long time whether I should use Openfire or eJabberd. But at the moment I tend to Openfire because of its features, many professinal plugins and the huge community. The biggest and I guess the only advantage of eJabberd is the clustering solution, but as I read the developers of Openfire will offering one soon :-) which will be commercial :-(
If I am wrong and there are big advantages of eJabberd against Openfire, please correct me. Maybe I just have not seen them...
Actually the main strengthes
Actually the main strengths of ejabberd are reliability (there is simply no match on this side), features set, manageability and scalability.
Regarding scalability, do not be fooled. ejabberd is the only XMPP server that is truly clusterisable, that is to say clustering everything including the router. Other solutions (including commercial ones) add connections managers, but if the router goes down you server goes down. This is not what I call clustering (and the new Flexarch clustering model in version 2.0 will also improve that part).
Regarding manageability, ejabberd has an unmatched feature: you can run commands from the Erlang command line. You can make all the possible maintenance tasks that you can imagine with this simple feature. Sysadmin of big sites love this feature. They can't live without this. One of the features you can leverage this way is hot code upgrade. This is a must have feature for an instant messaging site. You do not want to disconnect your users to put a new version online. For small sites, it is possible even if disruptive. However, for big sites it is simply impossible to kick tens of thousands or even hundreds of thousands like that.
Features set of ejabberd is impressive too. We implement probably one of the larger set of XEP and the upcoming version 2.0 will extend this coverage.
Reliability is something you can feel even with small sites. We have deployments of ejabberd that runs since months without a restart.
And if you think the admin console is a big deal, Process-one has developed a separate product to supervise ejabberd servers. See There are video demonstration at the bottom of the page.
It can provide you with good statistics of what is happening in your Instant Messaging cluster (which type of packets, graph, etc).
I hope this helps.
--
Mickaël Rémond
Why not to choose Openfire
Why not to choose Openfire (IMO!):
Remember that I am not talking about the features of the software, both ejabberd and Openfire have their own advantages. Also, this does not mean the ejabberd community has no issues.
--
sander
Regarding the Asterisk-IM
Regarding the Asterisk-IM plugin, there's a .
I, for one, have tried Ejabberd and now running Openfire but thinking to switching back, considering the number of implemented XEP.
But now that Openfire is going to support , I'm hesitating.
My choice will probably be based on which server provides the best PEP/PubSub support.
PEP has been available for a
PEP has been available for a long time as a patch.
We are integrated it in ejabberd 2.0, but we are adapting it to a new pubsub implementation which is much better that the current one. I should write a blog post to describe it :)
--
Mickaël Rémond
More patches natively supported, please
Yes, please, integrate a lot of patches for the next major release.
There are a lot of patches but as a novice sysadmin I don't know how to patch (gotta learn); moreover patches seem to make the server more unstable with side-effects.
Personally, I'd wish ejabberd could support PEP/PubSub, Message archiving and XEP-0154 (for FOAF) natively.
I'm waiting for ejabberd 2.0 release to switch, though.
And for Xmas, I'd ask for an ATOM-over-XMPP component (atompub-notify-xmpp). :)
Cheers.
P.S. : I have an idea of a combination of FOAF + PEP + Socialnetworks (Twitter, Jaiku, Plazes, Flickr, del.icio.us, etc) and atom-pub-notify.
Atom+pubsub
And for Xmas, I'd ask for an ATOM-over-XMPP component (atompub-notify-xmpp). :)
This already exists, sort of. You can use
mod_pubsuband do some extra plumbing to get interesting results. What do you have in mind?Social networks + FOAF + PEP + Atompub-notify-XMPP
There have been some about finding a way to unify the publication of presence streams.
Although Twitter and Jaiku use XMPP for their back-end, there's no real use of Jabber (yet) ; probably because those services may prefer to use the web as the principal UI (for monetization).
The idea would combine :
- FOAF : users would create a FOAF file thanks to the . The file would include the RSS feed or JID related to the service.
- User-Profile (XEP-0154) : the FOAF file would be uploaded on the Jabber server ;
- PEP : this would then automatically create corresponding PEP nodes and their buddies could easily subscribe to their presence streams, which would additionally be displayed in status message of the publisher.
This would require a transport that would fetch or be notified of new presence streams :
- by ATOM-over-XMPP if the service uses atompub-notify-xmpp ;
- or via a RSS transport ;
- or via a Jabber-to-Jabber transport similar to the .
But this would also require an enhanced GUI, perhaps like the Coccinella message archiving one, eventually with . (I hope that Psi will have an additional side-pane for message archiving).
There's also an ergonomic problem to solve with notifications (I'm using a RSS transport and have disabled events notifications, cos' I'm being flooded and it interrupts me too much).
It doesn't solve the question of publication per se (not sure how useful it'd be to publish the same things on the different services) but it would allow to centralize presence streams.
There might be also something to do with FOAF and OpenID thanks to the and the XEP-0070 similarly to the .
I haven't figured the whole picture and the idea is approximative but it might be the path to follow.
Instant Syndicating Standards
Nice one Kael... Long time no see...
I wonder where your ...
You guys might one to check ISS (Instant Syndicating Standards). It was part of Google's Summer of Code program in 2006. The report may be found at and the latest development may be found at .
XMPP PubSub and social networks monopoly
Nice one Kael... Long time no see...
I wonder where your ...
sigh
Nick,
Stop claiming that the idea I wrote is in any way inspired from ISS. It is so wrong.
Apart from the expression "social networks" and PubSub, ISS and what I suggested have few things in common.
ISS doesn't use FOAF, nor XEP-0154 neither OpenID. And I haven't waited to discover ISS to associate XMPP PubSub and social networks. So please, don't insinuate that it is a plagiarism of ISS.
It's like claiming that cars are a plagiarism of bicycles...
For the record, pubsub is
For the record, pubsub is there since a looong time, officially in ejabberd. We feel we are implementing quite fast XEP, are usage tend to be lagging, I think.
I am not sure a lot of deployment are using pubsub intensively (thought I am aware that some does).
--
Mickaël Rémond
Pubsub usage
Unfortunately, Pubsub doesn't seem very used (I have no idea what it concretely looks like) although mod_pubsub is available on lot of XMPP servers.
I tried to create a node manually via the XML console but I didn't get it - the node seems to be there but I don't know what to do with it. :\
Unfortunately: 1) Pubsub
Unfortunately:
1) Pubsub itself is too general for daily use;
2) ejabberd implements a very outdated pubsub version (even creating a node using current XEP-0060 will not work in ejabberd);
3) reasonable simplifications like PEP (XEP-0163) isn't shipped with ejabberd (it's available as a patch, but is incomplete implementation too);
4) If ejabberd will evolve so slow as during the last year, openfire will step ahead in features (it should get PEP as a Google summer of code project).
Pubsub and PEP
Unfortunately:
1) Pubsub itself is too general for daily use;
Sorry, I disagree. We have build clients that use pubsub, with end user using pubsub daily. Yes, daily use. Pubsub has to be wrapped by the client developer to be useful. I fail to see why being general make it less useful.
2) ejabberd implements a very outdated pubsub version (even creating a node using current XEP-0060 will not work in ejabberd);
When it was released ejabberd 1.1.3 implemented the latest version of pubsub. My personal opinion on this point is that XEP are evolving too fast. If you change the implementation of the XEP too often, client developers will have to change their implementation very often too and there will be a period where all clients will be not compliant. XMPP is for production these days. XMPP has left the lab a long time ago now :)
ejabberd 2.0 will however be upgraded to support the latest Pubsub XEP.
3) reasonable simplifications like PEP (XEP-0163) isn't shipped with ejabberd (it's available as a patch, but is incomplete implementation too);
PEP is good, but there is one catch. PEP is not fully compliant with Pubsub. You cannot build PEP on a standard pubsub component. You have to introduce a different behaviour. I feel it is kind of a mess.
However, as stated previously, ejabberd 2.0 will be released with PEP.
4) If ejabberd will evolve so slow as during the last year, openfire will step ahead in features (it should get PEP as a Google summer of code project).
We have PEP already and we are integrating it for 2.0. It is a lot of work as we are introducing at the same time a special and innovative feature in pubsub and I think and hope you will not be disapointed :)
Openfire is a good server but has a different philosophy. ejabberd has a longer release cycle because our target is to be the most scalable, the most robust and the most flexible server. It is used as a production server for some of the largest XMPP deployment and believe me, those sites do not want to upgrade every second day, but they care about stability, scability etc.
Openfire target Small Businesses, with fewer users, that need a all in one box and can afford to stop the service, upgrade more often etc. This is really different approaches.
--
Mickaël Rémond
Pubsub 1.8 was released
Pubsub 1.8 was released 2006-06-27. ejabberd 1.1.2 was released 2006-09-27 (after three months, and it's not 1.1.3, which was released even later). Pubsub 1.8 was in a pre-release stage for a quite a long time.
Try to create node using section 8.1.2 of XEP-0060 (note mandatory <configure/>). Do you really still think that ejabberd supports Pubsub?
I claim that Pubsub version which was published a long time before 1.1.2 (not 1.1.3 even) is unsupported. Period.
XEP process
Regarding the Asterisk-IM plugin, there's a .
I know, as I have said the problem is they need seems to be interested to move this to the . As long as they do not push protocol extensions they make to the XEP process so that other Jabber projects will/can use them, Jive Software is not contributing that much to the Jabber community (this is more worth that sponsoring the XSF!).
--
sander
We are willing to help you
We are willing to help you writting a migration script from OpenFire to ejabberd. I do not know OpenFire database schema but I know ejabberd database schema very well :)
--
Mickaël Rémond
About migration from Openfire to eJabberD
Bon jour, cher Mickaël Rémond!
AFAIK, the Openfire schema is not a secret - it can be found here (were I saw it last time :)
http://www.igniterealtime.org/builds/openfire/docs/latest/documentation/database-guide.htmlHope it helps...
BTW... can You please indicate, what is approx. number of concurent users "in real life" with single server ("modern" server, abt 2-4 modern CPU cores)? AFAIK, Openfire claims, that they can run abt 100k with their server... i doubt it.
But for ejabberd we have just quite old benchmarks (from Erlang conference :)... Is there more fresh numbers?
Respectueusement, Philip Jayasinghe
(to not be confused, du Moscou :)
Stats from public servers
what is approx. number of concurent users "in real life" with single server ("modern" server, abt 2-4 modern CPU cores)? Is there more fresh numbers?
If you want 'real life' and fresh numbers, you can check stats of Jabber servers:
Thanx a lot
!!!