Slashdot Mirror
Moving Outlook/vCards to an LDAP Address Book?
T-Suit asks: "I'm looking for a way to move 1000+ vCards (the result of painful consolidation after going through our sales' team personal Outlook contacts) into OpenLDAP, so that we can access them from all plaftorms. I've looked at Dawn, but its LDIF export is too crufty for ldapadd and it doesn't solve the issue of how to update those records easily, so I'd also need some kind of 'master GU' to edit them remotely. Along the way, I must say I am amazed at the lack of good LDAP-only contact manager apps for Windows, Linux and Mac OS X. Besides Evolution (which behaves strangely for me and doesn't show all the fields Outlook entries have), all 'nice' 'shared address book' tools I see are limited, web-based or rely on a SQL database. LDAP Management apps (such as diradmin) allow me to edit all fields, but are not for casual users (or available on Windows). Any suggestions on how to both import and maintain this data?"
If I were you, I'd take advantage of the glut of unemployed coders and have someone make you a web-based frontend to a perl or C based backend solution for this problem. Perl would probably work fine. It's kinda what it's designed for. Something like this would be pretty damn easy actually. Then you could/would have an application that does exactly what you want it to do, and the source to make modifications down the road if you need it.
For every annoying gentoo user, are three even more annoying anti-gentoo crybabies. Take Yosh from #Gimp for example.
SunOne/IPlanet/Netscape directory server has a nice gooey GUI for adding/searching/modifying. Searches can be done via web-browser...
So, just make an OU for contacts, dump the contacts in with Perl, create accounts for your salesy people and give them admin privilege of the contacts ou. It'll take a little time to get all the bugs worked out and lusers trained, but it will be functional from the start. I think.
Then you hire someone to come in and write a couple of little Perl CGI's using the PerlDap module or the variety of others available. I've been messing around with one that allows lusers to update a few of their records via Apache (perl modules CGI, PerLdap; Apache module mod_auth_ldap). Not too hard.
"You may all go to hell and I will go to Texas"
Sen. Davy Crocket to US Congress, Nov. 1, 1835
I'd advise not! I administer a 20 server GroupWise 6.x system. The GroupWise design is a terrible kludge, and I wouldnt recommend it to anyone...
My own experience with GroupWise's LDAP tools, are the the server will abend under any kind of load above around 10 computers hitting the LDAP daemon at the same time.
About GroupWise itself:
- They lock everything up in proprietary encrypted databases, and provide only Win32 tools for administring it.
- Their email client (which is required for accessing the database/emails) is generally flaky.
- They dont have STABLE standards support (IMAP, POP3, iCal, etc...).
- They still havent integrated GroupWise's username/password database into Novell's famed eDirectory/NDS database (the database which is supposed to be the be-all-to-end-all...).
- You have very little administrative control over the mailboxes.
- The backup solutions are poorly designed and implemented (you MUST shutdown the email system to get a reliable backup). No, the GWTSA's dont cut it (based on my personal experiences, and statements from senior techs at Novell)...
- Novell has POOR support for automated administration and report generation out of GroupWise - GWCheck just does not cut it...
- There's a current denial-of-service vulnerablity in GroupWise - where the database fails to cleanup deleted emails (ie: the database just keeps growing, with no way to shrink it). Its been in GroupWise since the early 5.1 days, and Novell still has not been able to resolve it...
- And the list goes on...
These things alone make GroupWise very difficult to administer in an enterprise enviroment...