ejabberd Cluster problems with LDAP Authentication.

Hello all,

I have several ejabberd cluster nodes distributed across several sites, each configured to use site-local Active Directory servers to handle authentication via LDAP. This last weekend, both AD servers went down at one of the sites and all cluster nodes were unable to authenticate users. Also, once the AD servers were brought online I had to restart each ejabberd instance to return things to normal.

I've done text dumps of the database at each site, and I see the local AD servers configured properly for each. Can someone think of a reason why one site's LDAP servers going down would affect all nodes?

Thanks for the help, and ask if anything needs clarification.

-TimS

Additional information.

A quick addendum: All tables are replicated between all nodes. When I look in the text dump for the LDAP servers, they appear inside of `local_config'.

Better to replicate specific tables only

I think it's a bad idea to replicate all the Mnesia tables used by ejabberd, because some tables are used internally by ejabberd to keep information about that sepcific ejabberd node.

Better to replicate only the tables that contain information that you really want to be shared among all the ejabberd nodes. If you use internal storage (not SQL storage), then those tables are probably:

last_activity, offline_msg, passwd, privacy, private_storage, roster, and vcard. Maybe also the pubsub_* tables.

RE: Better to replicate specific tables only

Each time I add a node, I make the storage type of each table on the new node match the existing node(s).

My goal is for each node to operate independently if the sites get disconnected from each other, but if all WAN connections are operating normally then it will operate as a singe cluster. Wouldn't only replicating the tables above cause many of the others to depend on the other tables remotely, and basically grind the server at a given site to a halt if it gets isolated from the rest?

I can send you my current output of mnesia:info() if you like, they're the same on all nodes. We could take it to email and then I'll post the results here.

Look at incoherences

applsplatz wrote:

My goal is for each node to operate independently if the sites get disconnected from each other, but if all WAN connections are operating normally then it will operate as a singe cluster.

I'm not sure how will Mnesia handle the incoherences in the tables data when the new nodes reconnect again. You should check that topic.

If Mnesia clustering doesn't suit your needs, you can use mod_roster_odbc... and store information in a centralized external ODBC database. Or distributed ODBC database.

Syndicate content