sets the standard for being the most standards based LDAP[?]
directory, you'll be pleased to know that our partners Symas
are keeping everyone updated
about the wonderful world of collaboration in the LDAP world and in the process updating some much needed draft RFCs.
So, when you've got a second have a read of:
Password Policy for LDAP Directories - draft-behera-ldap[?]-password-policy-10.txt
An Approach for Using LDAP as a Network Information Service - draft-howard-rfc2307bis-02.txt
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
Read the full article
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!
W. Michael Petullo
has published a very detailed article for Red Hat Magazine
about using the Asterisk
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
I got back last night, after a somewhat hectic Flybe.com flight (long story).
I really enjoyed the conference
, my first time speaking
at one, bit nervous, but it can only get better
Continue reading "Spring 2008 - a UKUUG Conference Review"
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.
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