First off, total newbie. I've read everything I can find on ejabberd but I'm still don't think I've figured out how to properly configure ejabberd for my particular deployment requirements.
My requirements:
I want to deploy ejabberd on a research vessel to help with logging daily events. Users on board the vessel would log their events, observations, etc into persistent MUCs (with muc logging enabled). Additional users on shore (connected via satellite) can add events, observations, etc into the same persistent MUCs as the ship board users. Users (on the ship and/or the shore) can have regular peer-to-peer IM session. I also need a shared roster among all ship and shore users. Any server on the ship must be behind a firewall. Any server on shore must be behind a firewall. The ship and the shore reside on completely separate networks (connected only by the Internet). Because of bandwidth costs I need to minimize traffic over the satellite link.
Ideally what (I think) I want to do is setup a server on shore to service all the shore-based IM sessions. A second server on the ship to service all the ship-based IM sessions. Then I need to have the persistent MUC(s) replicated on both servers. Ideally the logfiles from the MUC(s) would also be replicated on each server. This would prevent users on the ship from having to access the logfiles on the shore server and vice versa. I would also need to replicated the users (maybe via a shared roster?).
Can this be accomplished with a cluster and if so, this there any information on setting up synchronization of MUC(s) and users between servers?
Thanks for any advice you can provide.
Bad news. All your
Bad news. All your description seemed possible with current ejabberd until you reached this sentence:
> I need to have the persistent MUC(s) replicated on both servers
In ejabberd you can replicate persistent information (accounts, contact lists, offline messages, ...) over several nodes of a cluster.
But it cannot replicate user sessions or rooms, because those are live processes, not information. A user session connected to ejabberd-ship is connected to ejabberd-ship. A room that was created in the MUC service at ejabberd-ship lives in that MUC service.
Summary: in ejabbberd it is possible to replicate information, but not possible to 'clone' processes.
Might still suit my needs
Thanks for the explanation. Rather than having "persistent MUCs replicated on both servers" is there a way to funnel all messages originating from shore through a single shore-side IP Addess, some sort of proxy perhaps?
It comes down to security policies, if I can have all messages destined for ejabberd-ship originate from the same shore-based IP address it is much easier for me to get securities approval and makes it much easier to add additional users.
Thanks again,
- Webb
> is there a way to funnel
> is there a way to funnel all messages originating
> from shore through a single shore-side IP Addess,
> some sort of proxy perhaps?
One idea: install a bot in ship that joins the room in ship and another room in shore. When a participant of one room says something, the bot 'says' that message on the other room, and viceversa.