Just seen this thread - my main wishes in no particular order would be: (I’m on Openfire 3.5.2 / Red Hat EL / Spark 2.5.8)
“Nickname” of manually added contacts to default to the value in openfire.xml - then all contacts would pick up the same naming format, regardless of whether they are from shared groups or are manually added. It’s a bit messy at the moment.
Support for nested groups
Optional writing to AD via the profile would be great - we use a separate app to do this at the moment, tied down to certain fields.
Multi domain / sub domain support
Don’t know if it’s just me but configuring the vCard stuff through the web console just doesn’t seem to work properly. I always have to edit openfire.xml directly to get access to all the fields to make the profile display correctly, which is fine now that I know that - but it would be nice if I didn’t have to.
Otherwise the LDAP connectivity is one of THE major selling points of Openfire, for my org at least…
Don’t know if it’s just me but configuring the vCard stuff through the web console just doesn’t seem to work properly. I always have to edit openfire.xml directly to get access to all the fields to make the profile display correctly, which is fine now that I know that - but it would be nice if I didn’t have to.
This is my biggest complaint too. I have had this issue since I started using openfire. The next biggest issue is there is no way to manually refresh the LDAP list of users/groups.
The “performance” is pretty terrible for my install, but that’s mostly due to a large directory where the users and groups are separate from the root of the tree. When I go in to the users/groups tab in the web admin interface it can take upwards of 3 minutes to pull all the users for the list and get me in the tab… I guess it’s searching through my entire directory trying to find users. The groups sub-tab gets even worse.
The thing I would like to see most in the LDAP piece is the ability to select a base DN from which to pull users and another base DN from which to pull groups. Then I wouldn’t have to point at the root of my directory to get users and groups. Filtering is ok but you still have to query the entire tree to see if items match the filter or not…
Every directory situation is unique, so I’m not sure if most users are seeing the same thing - but it’s something worth considering I hope
someone should really start a new thread/conversation. The original is from '05 and Openfire has change alot since then
I’ve see other posts where people ask to be able to change base dn’s for user and group maping. If you format a good ldap query you shouldn’t have a problem, even with a horrid AD setup (don’t ask me how I know )
I created a new group for IM users, called SparkIM (I call it spark for our support staff, they have no idea what openfire is). then I added users and groups that I want to dispaly as members of the main SparkIM group. Then in the query filters I put:
Groups and user populate without worring about nesting or other AD funniness. It also allows me to just put the root DN for the directory in my configuration and control everything from AD users and computers just by adding the SpakIM group to a entry.
OP is from February of 08… still not a new thread, but not too awfully old. I actually hadn’t noticed the date when I first posted. If I had noticed the date I may not have responded…
Using filters like that works, but the performance hit is what I’m worried about. When you point at the root of your directory openfire will simply query everything in the directory from that point and check it against the filter. You only pull in the users/groups you need, but it takes a lot of extra time when the directory is very large.
Not exactly. If I understand it correctly it works just like any other ldap search. The searching is done on the directory side and only the matches are returned to Openfire.
How many obejects are your returning in your ldap query? LDAP is optimized for searching and unless you’re returning 10k or more entries or running AD on a P1 server, the results be returned in a second or less.
ps. I though the OP was older for some reason. I swear I saw an '05 at the top.
Here’s where I take a step back and say I don’t know the innermost workings of how this is happening … but here’s what I noticed and what I did to test:
I plugged in openfire 3.5.2 to novell eDir. I noticed that when I get into the web admin console and hit the users and groups tab, there’s a few minutes of lag time. Similarly, there’s tons of waiting to get into the groups subtab.
So I checked out the CPU usage on our directory server when I hit the user/groups tab. The eDir process normally hovers around 3-4%, and getting in to the users/groups tab in Openfire skyrockets it up to 70-80%.
I then got in touch with our directory team and we ran a trace of what’s going on. I don’t know if it’s a characteristic of openfire or eDir (with the performance you’ve noted in AD I would suspect eDir is the culprit), but from the trace it definitely looks like each element in the directory is getting looked at. Our directory has far more than 10k entries in it, but between the users and groups I should only be pulling around 3000 entries.
Also… if I forego the groups and point straight at the users container, everything is very speedy.
ah. I don’t have any exp with novell edir. I’ve used openldap many times.
I’ll comonly use openldap tools installed on my Win XP machine to troubleshoot LDAP queries. Have your tried to running the query against the directory from a cli tool and see what you get?
I’d guess that you’re still having a problem with the filter of the query. Did you ask the directory team to check the filter?
3000 entries on any LDAP server should zip out faster than you can blink. It should take more time to write them to a terminal than to complete the query. It’s what directory servers were designed for. Slower to update than an RDB but much faster to query.
Yeah we spent a lot of time troubleshooting through different filters. We were also having issues with aliased users not being read in openfire (hiding our ALIAS container from being read by openfire on the eDir side didn’t even fix that problem…) so between trying to fix that and the performance hit we went through quite a few filter iterations.
I haven’t tried any external tools aside from some softerra tools to troubleshoot. That’s a good idea and I will plan for it, though.