Oh well, it looks like I spoke too soon -- it seems like some DB sanitization happens when sipXconfig is refreshed. As a result, my "* 15 ? * *" entry in cron_schedule gets reverted back "0 15 ? * *" -- an hourly import. Any suggestions? I'm debating between writing a plugin for the directory server, or trying my hand at java and modifying sipXconfig API to include LDAP....
In terms of users, we currently have about 30 but we're planning on scaling it out to a much larger audience over time. Within the next few months, we plan to have a few hundred people online. We already have user data hosted in other systems, and synchronizing sipXecs with LDAP seemed like the cleanest path to intregration -- but the fact that user permissions, among other options, can't be imported from LDAP makes it tricky. I don't know if others would find that functionality beneficial -- but I'd be happy to add it as a feature request to JIRA as well.... Another challenge I've found with the LDAP integration approach is that the "My Information" tab is still available in the user portal. The user portal is excellent (one of the reasons we went with sipXecs) and we want to provide it to users, but the "My Information" tab allows users to update their information when all of their updates will be overwritten when the next LDAP import is performed. Michael LeBlanc wrote: > Thanks Damian -- I modified the LDAP import entry in the cron_schedule > table, and it seems to have worked. > Nice! How many users do you have? > We were going to schedule these imports to run every 15 minutes. Off > hand, do you know which processes use significant CPU -- is it > sipXconfig, or Postgres? Well - even if it is postgres it's because sipXconfig does not make an honest attempt to optimize DB access during import. > > I've added the LDAP import SOAP API call to JIRA: > > http://track.sipfoundry.org/browse/XCF-3270 thanks - accepted - patches welcomed > > I don't suppose there are any plans to implement real-time LDAP > lookups in sipXecs down the road? It would be an ideal scenario for > our environment.... > As you can imagine sipx needs some extra information associated with each user. Asking people to configure LDAP schema so that is acceptable to all interested parties is more of an organizational than a technical problem. That said sipXconfig is quite modular: It might require some code rearranging but implementing user service backed by the LDAP directly (and not by the DB) is certainly possible and probably would be an interesting experiment. To me LDAP always seemed to be much better at lookups and searches then enumerating and scanning. But it might just be my misguided intuition and I would happily change my mind if real word results would demonstrate that such a solution is viable. D. _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
