[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LDAP (and Asterisk) integration, was: New user question: egroupware
- Subject: Re: LDAP (and Asterisk) integration, was: New user question: egroupware
- From: "Chris Travers" <..hidden..>
- Date: Fri, 17 Nov 2006 10:37:41 -0800
On 11/17/06, Stroller <..hidden..> wrote:
On 17 Nov 2006, at 14:19, Anthony Boyington wrote:
Is egroupware able to use LDAP for storing client details?
In his "SQL-Ledger Wishlist" Naked Ape mentions this:
LDAP integration for customer and vendor tables. Actually, this is
an item for myself, as I started researching it, discovered it was
possible, and never got around to implementing it. With OpenLDAP
2.1, you can build a backend called sql-back that let's you expose
SQL tables through LDAP. It takes writing some queries custom to
the SQL application and building some tables or views to map between
the schema. If I did this, I could reduce the duplication between
having my customers' contact info in my LDAP addressbook and
SQL-Ledger.
http://nakedape.cc/wiki/ApplicationNotes_2fSqlLedgerNotes
FWIW, I have been planning to do this for a while. Will have to wait
until after 1.3 though because I want to wait until after the
customer/vendor info has been stabilized.
Another (possibly better) option would be to have an option to export
LDIF files that could be imported into another OpenLDAP server. The
main advantage here is performance-- the mismatch between the LDAP and
relational models causes a pretty heavy performance penalty.
Of course, LDAP is light-weight only in the sense that OSI X.500 was
not lightweight.
If egroupware can access LDAP then you might be able to "expose" your
SL^h^h L-SMB customer database to it in the same way.
I suspect that at the moment, though, the best option is to use some
sort of db-level syncronization. eGroupware supports MySQL, MaxDB,
PostgreSQL and others. The big issue is how much work one wants to do
against an unstable database schema.
I caught this comment a while back and have always intended to look
more closely at it. I'm pretty sure that Asterisk can do LDAP look-
ups, so it would be nice to have caller ID display the customer's
name when I receive an incoming call.
Asterisk can also do PostgreSQL lookups I believe, and if not, a
little AGI scripting should do the trick.
I have only recently gone live with SL, however, and have not even
started my Asterisk deployment, so it will surely be some months
before I'm able to update.
Certainly it would seem to be a limitation if one's customer database
was access-able only from the web-interface of one's accounting
package... and for me it is currently a duplication of work to
maintain customer details twice.
We are working on this issue. At a minimum, a RESTful web services
interface will expose the data.
Additionally, if the SL customer DB can be accessed via LDAP, then it
could be used by applications such as Apple's iCal server, which has
recently been released under an OSS license.
And practically every email client out there.
LDAP has become the de facto way of exporting address books despite
the fact that for this purpose HESIOD was probably a simpler and more
elegant approach. It is certainly on my radar. Just not sure the
best way to implement it yet. In all likelihood we will just go with
SQL backend for OpenLDAP with the idea that people who want more
scalable/better performing systems can work with us to create other
solutions.
Best Wishes,
Chris Travers