Suitability for large installation, some ldap problems

Nathan_Olla · February 1, 2005, 2:03am

Hi,

I’‘m evaluating different XMPP server solutions, which are free, and I’'ve come to like many features of Jive Messenger – the admin console among them.

Our deployment will be very large, 3000-5000 users potentially, maybe even more.

LDAP integration is working, except for some changes that look like they might make it into the next version (select ldap filter being one). However, I am having an issue with LDAP SSL connections on the backend. LDAP without SSL works fine.

THe issue seems to be that there is a missing library from ( src/java/org/jivesoftware/messenger/ldap/LdapManager.java)

183 if (sslEnabled) {

184 env.put(“java.naming.ldap.factory.socket”,

185 “com.jivesoftware.util.ssl.DummySSLSocketFactory”);

186 env.put(Context.SECURITY_PROTOCOL, “ssl”);

187 }

That’‘s from the nightly src.tar.gz but it’'s the same in the 2.1.1 release version.

I don’'t see this in either the source or the binary installations. The error in the debug.log is

2005.01.31 19:41:52 Creating a DirContext in LdapManager.getContext()…

2005.01.31 19:41:52 Created hashtable with context values, attempting to create context…

2005.01.31 19:41:52 Exception thrown when searching for userDN based on username ‘‘nathan_olla’’

javax.naming.CommunicationException: 123.123.123.123:636 Root exception is java.lang.ClassNotFoundException: com.jivesoftware.util.ssl.DummySSLSocketFactory

So, 2 questions:

#1 Has this been run on a large configuration? Does it scale? Any obvious reasons why not?

#2 is there a solution to this LDAP SSL issue? Am I even close to dissecting the issue?

TIA for any help you can provide,

Nathan Olla

(sorry for the long post)

matt · February 1, 2005, 3:37am

Nathan,

THe issue seems to be that there is a missing library

from (

“com.jivesoftware.util.ssl.DummySSLSocketFactory”);

Whoops! Looks like a paste error. I’'ll move that class over into Jive Messenger to fix the issue.

#1 Has this been run on a large configuration? Does

it scale? Any obvious reasons why not?

The LDAP portion of the code definitely scales – it’‘s essentially the same code as from our commercial products which have been used in very large environments. I don’‘t think you’'d have a problem handling 3000-5000 users in the core XMPP server either. However, 5K is probably the max number of concurrent users you could handle on one box until we switch to a new networking layer.

#2 is there a solution to this LDAP SSL issue? Am I

even close to dissecting the issue?

I’‘ve filed the issue as JM-152. I’'ll attempt to get a fix into CVS tonight and it will officially be released as part of 2.1.2.

Regards,

Matt

matt · February 1, 2005, 8:53am

Fix checked in. If you have a chance to try tomorrow’'s daily build, that would be great.

Thanks,

Matt

Nathan_Olla · February 1, 2005, 4:44pm

Will do, sometime tonight.

Next questions…I bet it’'s already been answered…is there a way to implment A) a JUD that uses the LDAP data as the backend and B) vcard-from-ldap so that the users will see the data mapped from LDAP into the vcard when they do “get-user-info”? Finally, are there docs how to connect up w/ aim, yahoo, msn transports?

Using external 3rd party stuff is OK but for full end to end enterprise use, we need LDAP for evertying. I can post another thread if that’'s more appropriate.

matt · February 1, 2005, 5:59pm

Next questions…I bet it’'s already been

answered…is there a way to implment A) a JUD that

uses the LDAP data as the backend

A JUD?

and B)

vcard-from-ldap so that the users will see the data

mapped from LDAP into the vcard when they do

“get-user-info”?

This feature has been requested before and is in the issue tracker as JM-121. If the feature is important to you, please vote for it, as we do use those votes to prioritize

Finally, are there docs how to

connect up w/ aim, yahoo, msn transports?

No transports are available yet. One person is planning on writing a native MSN transport starting this month. We’'ll also have external component support soon, which would provide a way to hook up existing gateways.

Regards,

Matt

Nathan_Olla · February 1, 2005, 11:35pm

I thought I had replied. Weird. Anyways…

A JUD?

http://www.jabber.org/jeps/jep-0055.html

As far as I understand this is a different issue than the VCARD-backed-by-LDAP one. Essentially the ability to search on stuff in VCARDs, in this case as backed by LDAP.

In case this becomes a feature request (hint ) it would be extremely useful to provide a mechanism to define the mapping/matching so that it could be molded to our LDAP implementation.

This feature has been requested before and is in the

issue tracker as JM-121. If the feature is important

to you, please vote for it, as we do use those votes

to prioritize

Done!

matt · February 2, 2005, 2:43am

Nathan,

JEP-55 is actually being worked on by Ryan Graham as a plugin. JM-122 relatest to this and will allow for better searching. There will likely need to be some additional work after that to get all the LDAP stuff working that you’'re talking about, but it will be a start.

Regards,

Matt

Ryan_Graham · February 2, 2005, 3:03pm

JEP-55 is actually being worked on by Ryan Graham as

a plugin. JM-122 relatest to this and will allow for

better searching.

Nathan,

I actually have a JEP-55 compliant plugin ready to go for the 2.1.1 version of Messenger. Currently, its ease of use is somewhat limited since there is no way to register the plugin as a server feature (JM-146). So, clients like Psi, which rely on the discoverable server features can’‘t use the search functionality at all, and clients like Exodus, require the user to manually enter the server’‘s name before they can run a search. Because of this issue, I’‘m a bit reluctant to release the plugin since supporting it would become an issue. As soon as a version of Messenger is released that has a resolution for JM-146, I’'ll release the search plugin.

Thanks,

Ryan

Gaston_Dombiak · February 2, 2005, 3:29pm

Hey guys,

I’'m now implementing external components which requires JM-146. So in the near future you will be able to run JEP-55 as an external component.

Regards,

– Gato

Ryan_Graham · February 2, 2005, 3:35pm

Hi Gato,

Great to hear. I wasn’'t trying to put any pressure on you.

Thanks,

Ryan

Nathan_Olla · February 2, 2005, 3:41pm

Matt,

I tested the 02-02-2005 nightly build and the LDAP ssl issue looks to be resolved. Thank you for that!

Ryan,

OK, that sounds reasonable. Certainly the feature needs to be usable by default in my environment (Psi and JAJC clients).

So close…JM-146, JM-130, JM-129 and JM-121 plus the ability to connect to external transports…all I need.

Here’‘s a few nice-to-haves that lack from other free XMPP servers AFAIK. I’'d not consider this a feature request or anything so presumptuous, just my thoughts as someone facing a corporate wide IM rollout…

Multiple Levels of Administrator

This would be breaking up the administrator rights in to sets and assigning to different roles. This could allow, for example, a user who could terminate sessions but not restart the whole server.

Administrator access by LDAP group or attribute

This would prevent me from having to setup admins individually. Combine with the above for easy delegation of responsibilities.

GUI elements to manage the previous 2
Conversion of Users from Jabber 1.4 to Jive

To preserve presence subscriptions, contact information and so on.

easy to implement, bulletproof clustering
A backup utility for easing migration from one server to another.

Not sure if this is necessary with the architecture but if I wanted to move my Jive installation from hardware A to hardware B it’'d be nice if there was a handy way to do it that preserved any/all settings and so on.

Thank you both for the swift and helpful answers. You guys got a nice product here.

matt · February 2, 2005, 5:11pm

I tested the 02-02-2005 nightly build and the LDAP

ssl issue looks to be resolved. Thank you for that!

np

Here’'s a few nice-to-haves that lack from other free

XMPP servers AFAIK. I’'d not consider this a feature

request or anything so presumptuous, just my thoughts

as someone facing a corporate wide IM rollout…

Cool, feedback appreciated. I’'ll add some comments about our current thinking about these issues below…

Multiple Levels of Administrator

This would be breaking up the administrator

strator rights in to sets and assigning to different

roles. This could allow, for example, a user who

could terminate sessions but not restart the whole

server.

Yep, role-based permissions are something we do plan on adding.

Administrator access by LDAP group or

p or attribute

This would prevent me from having to setup

o setup admins individually. Combine with the above

for easy delegation of responsibilities.

Interesting, haven’'t thought about that before.

GUI elements to manage the previous 2

Of course. Could it be a Jive Messenger feature otherwise?

Conversion of Users from Jabber 1.4 to Jive

To preserve presence subscriptions, contact

ntact information and so on.

We’‘re hoping someone in the community will step up and contribute this. We (Jive) don’'t have a big interest in this feature but know that many people do.

easy to implement, bulletproof clustering

Check out: http://www.jivesoftware.org/forums/thread.jspa?threadID=13827

A backup utility for easing migration from one

one server to another.

Not sure if this is necessary with the

th the architecture but if I wanted to move my Jive

installation from hardware A to hardware B it’'d be

nice if there was a handy way to do it that preserved

any/all settings and so on.

It’‘s actually pretty easy already. If using an external database, just move the messenger.xml file over to the new server and point at the same db. If using the embedded database, just copy the embedded-db directory over to the new server. This works across OS’'s too.

Thank you both for the swift and helpful answers.

You guys got a nice product here.

Thanks for your continued feedback!

Regards,

Matt

Ryan_Graham · February 3, 2005, 3:23pm

OK, that sounds reasonable. Certainly the feature

needs to be usable by default in my environment (Psi

and JAJC clients).

I just tried the search plugin with JAJC 0.0.8.112 and it appears to require the discoverable server features. I’'ll be sure to add JAJC to the list of clients to try before officially releasing the search plugin.

Thanks,

Ryan