The Suretec Blog

“Guide to Scaling OpenLDAP with MySQL Cluster” on June 24th at 10:00AM PST. Howard Chu, CTO of Symas Corporation, will be the primary technical presenter. This is going to be a repeat of the great pitch we did at the MySQL Conference in Santa Clara. This is a terrific introduction to the OpenLDAP Driver for MySQL Cluster for people interested in this new database technology for LDAP^[?] directory data.

Register here

Suretec^®

Just a quick one to say our partners Symas have written a very nice peice about how to pick your base hardware and operating system for use with OpenLDAP in your Enterprise:

The key to this first factor is that OpenLDAP is the most efficient, most stable, and most suitable LDAP^[?] Directory Service technology for Enterprise production use. Installing it as a new service or an upgrade to an older technology will be the most cost-effective step assuming the capacity is available. In general, replacing an older Directory Technology will reduce the processor load by two to five times. It will also improve the stability of the server(s) making simplification of configurations tuned to frequent server outages possible. Symas OpenLDAP is available under inexpensive annual support subscriptions with no consideration for the number of CPUs in the server or the number of objects/entries in the Directory, too. So, our preference of platform, in general, is put OpenLDAP (Symas OpenLDAP) on what you’ve got!

Read the full article

W. Michael Petullo has published a very detailed article for Red Hat Magazine about using the Asterisk RealTime LDAP^[?] Driver and Fedora Directory Server.

It's well written and a good read, but just so you know, OpenLDAP can easily be used and should have been the first choice as I'm sure our partners in crime Symas would point out too

But hey, it's a Red Hat Magazine so you can't blame them really...

Voice over Internet Protocol (VoIP) has emerged as a popular technology for modern voice communications. Many organizations have replaced their analog or proprietary digital telephone systems with VoIP-based solutions. This allows the consolidation of telephone services into an existing IP infrastructure. In addition, using IP to host voice services lets the organization leverage existing expertise–while retaining all of the network’s management advantages. Though not without its disadvantages, VoIP provides a compelling option to those looking for a telephone solution.

This article will present a simple VoIP solution using Asterisk, an open source private branch exchange (PBX) product. It will show you how to install Asterisk, configure it using its LDAP backend, and connect to it using the Ekiga software VoIP client and a Cisco 7900 Series VoIP telephone to make calls.

The first comment about the article is right though:

In general experienced users from the Asterisk community advise against purchasing Cisco phones for business deployment with Asterisk and recommend Polycom, Aastra or Snom instead. Cisco phones are very expensive, difficult to setup, technical documentation is not easily accessible for the end-user, their SIP firmware has some nasty surprises and as far as I know that cheap SmartNet contract is still quite difficult to get.

The LDIF Schema and normal LDAP schema are available in non-FDS format and are contributed to the Asterisk Project by Suretec and maintained by Suretec.

Thanks,

Gavin.

Outstanding questions for Directory Services Gurus answered completely and convincingly.

Suretec saw a sneak peak before it was out, but we're glad to say it's unchanged and a cracker!

Have a read:

OpenLDAP is unmatched by any other directory service, proprietary or open source. Of all the others available, the proprietary ones are just hiding their dirty laundry and all of them are just a waste of time and money.

Want OpenLDAP for your Enterprise? Then contact the UK Leading OpenLDAP Experts.

Suretec^®

It's been an interesting week to say the least. First we see some very good discussion in the Symas My Old Flame post, then we discover Fedora Directory Server is less stable/desirable as a back end for Red Hat.

Let's put this into context, first Red Hat attack OpenLDAP, but yet they won't eat their own dog food:

We had been basing our application on fedora-ds, during the last year
we've seen great changes in this application and how its packaged. This has
made it less stable/desirable as a back end. All signs point to using
postgres on the back end as being both the easier choice and the more
reliable choice based on what we've seen.

Red Hat do a lot of great things, but why don't they do what they preach and collaborate with a proper LDAP^[?] Project and get real value out of that work and not waste time and money on a dead end project.

Suretec^®