This month's OPEN For Business! is the second in our LDAP mini-series. The series is about using directory services to make the administration of your network easier, and potentially, how to replace every bit of proprietary software you may have in the network with better Open Source software, plus how to tie it all together. Last month we covered what a directory is, and hinted at what you could do with it. This month we will look at the creation of a single user account base and single sign-on initially across all of your non-Windows systems (Linux, Solaris, MacOSX, FreeBSD, HP-UX, etc).

But first you need your LDAP directory!

The Open Source world is blessed with the simply fantastic OpenLDAP project. Led by Kurt Zeilenga, the author of most of the RFCs that actually define what LDAP is and how it works, the OpenLDAP server and related tools are one of our best-kept secrets. So it's about time we corrected that...

The OpenLDAP server is a full implementation of the LDAP definition, and has such a vast range of features that are soooo technically wonderful I could go on and on and on for ever. Let's just say it's lightning fast, superbly robust, and does simply everything you could ever need a directory server to do - but without the simply obscene price tag the proprietary vendors seem to enjoy attaching to these things. Of course it's Open Source too, which gives it transparency, extensibility, unlimited customisation potential, and it's guaranteed to never deviate from LDAP's defining standards - not like some other Directory products I could actively mention!

So we've got our OpenLDAP server. Let's get on with populating it!

As I mentioned last month, an LDAP Directory enables information about objects to be held in a tree-like organisational structure (a quick tip at this point - the structure you create to hold your users can be anything you like, we recommend you create one that reflects your actual organisational structure). You can then associate key pieces of information with these objects

Time to make this real. The objects that we are interested in creating are users. If I asked you what your users consist of in IT terms, you'd probably tell me the standard stuff - username, password, home directory, access to this, denied access to that, email account with an email address, etc (funny old view we have of people, right?). Take some time right now, and you'll see that you can soon write a list of stuff defining what a user is on your network. So if we create an object in our directory that represents a user from the IT perspective, the attributes this object must have are the ones that are meaningful in an IT sense - and you've just listed them.

All this stuff is well understood, and well thought through. A central notion in the LDAP world is that of 'schemas'. You've probably noticed by now that I like to explain complex stuff in simple terms. I'm aware that there's a million and one subtleties, and my descriptions are not 'precise' in absolute terms, but we'll leave that argument to the pedants, my descriptions are good enough for where we're going. A schema is a big batch of definitions of well understood attributes, things like telephone numbers, email addresses and passwords. By registering a schema with your LDAP server you can then associate its definitions with your objects. Simple, right?

So we start by adding some schemas that represent people (our somewhat odd IT notion of what people look like that is!) and also that represent an account on a UNIX box. You now have a basic directory service, and you're ready to actually do something with it.

Now we need to move on to the boxes you want to authenticate to your shiny new Directory server. As mentioned, we're going to start with your UNIX, GNU/Linux and BSD machines. By default, these machines have a local account database (/etc/passwd) - a legacy from the early days of UNIX. This database is sometimes exactly what you need, but the truth is, in most cases it's a nightmare to manage. Imagine a network of 500 servers, each with its own user database, each of which needs visiting every time a change happens in your user population. Yuck! Traditionally UNIX solved this with systems like NIS, but this is not truly cross-platform in any trivial-to-implement way, and we want to do waaay better than that, especially when we bring our Macs and Windows boxes online!

The answer is Pluggable Authentication Modules, affectionately known as PAM. The notion is simple... Abstract the authentication layer so that your UNIX system can be authenticated by any method which has a PAM module. PAM makes the method look like traditional UNIX authentication. There are plenty of them, including MySQL, Radius, Kerberos and, for our purposes, LDAP.

Simply better software:

Once your LDAP PAM is plugged into your machine, you can authenticate the underlying operating system against your new Directory. One account base across all your UNIX and GNU/Linux servers - how cool is that? Not only that, but FreeBSD (the world's finest web server!) has had PAM capabilities since release 5, and since MacOSX is based on a BSD core, it can participate in this scheme too. There's only one significant OS missing from your new account management paradise... It’s OK. Don't worry, we’re going to hit them next month! I'll show you how to extend your new Directory to enable logons to your Windows servers and desktops. These logons will be with exactly the same accounts you've just set up to enable logons to your UNIX, GNU/Linux and BSD machines. Single identity across all of your platforms - now won't that be nice?

We'll do all this without you having to buy one of those ridiculously expensive directory solutions from one of the proprietary vendors. It'll do it better. And it's all because it's simply better software.

This month's OPEN For Business! is the first in a mini-series. The series is about how to use Directory Services to make the administration of your network simpler and easier. We'll look at how to replace every bit of proprietary software you may have in that network with what we all know is a far faster, far more reliable solution, Open Source software. Then finally, and most importantly, I'll show you how to tie it all together into a network that really delivers, and that really provides, what the business wants and IT's users need.

First of all some background. Let's start with something that's often unpalatable - the truth.

The truth - would you start from where you are?

The truth about almost every network in the world is that it consists of a wild variety of disparate (or is that desperate?) technologies, platforms, operating systems and services. Timescales are always tight so bits have had to be tacked on here, kluged there and patched all over simply to keep pace with the latest business demand or new management strategy. So it’s all grown higgledy-piggledy over the years. Now ask yourself, if you had to do it again would you really want to start from where you are?

Even so-called 'Microsoft shops' rarely consist of a single build of Windows. Indeed, the truth about the Windows platform is that it's just as 'fragmented' as any other - you didn't really believe that Windows 3.1, 3.11, 95, 98, 98SE, 98ME, NT 3.51, NT4, 2000, XP Home, XP Professional, 2003, XP Reloaded (!) were perfectly interoperable or even similar operating systems did you? Then there's the never-ending barrage of Service Packs. It's best not to even think about what they do to the underlying technologies, protocols, or even file systems... Yep, the plain truth is that an operating system monoculture, even if it were desirable, only exists in the proprietary vendors' marketing brochures.

Now, add network services to this already heady cocktail and you've got what most businesses out there have complexity in spades, constant fixes and upgrades, high cost, poor reliability. In short, a mess. Yet a mess that's absolutely crucial to business competitiveness and performance.

So what's a poor IT Director to do?

Well, there's certainly no shortage of vendors happy to 'advise' you, and to help you sort this lot out. Most vendors will tell you that their solution can integrate all of your various platforms, and that if you choose their solution everything will be "roses, roses!". Occasionally they even mean it! More often than not though, what they actually mean is that you have to chuck out all those 'non-industry standard' (this week!) platforms you've been dumb enough to accumulate and 'upgrade' to the best, all time favourite, greatest platform of today. Theirs. But at what cost?

Always remember - it-s only lizards that can grow new arms and legs . . .

A shining light:

So is there any light that Open Source can throw on this issue? And is there a strategy for using Open Source to extend the life of your existing cocktail (if it ain't broke . . .), keep your options open for the future, and maybe even give you a clear roadmap to the future based on Enterprise Class Open Source solutions?

Funny you should ask that . . .

The common element in all IT systems is that your users need to use them. So the logical place to start is with a single source of user information. This is where Directory Services come in. All the vendors know this, this is why Microsoft's Active Directory, Sun's Sun One Directory, or Novell's eDirectory are touted as the cure for all network woes. Now is there a common element to all these products? You bet!, it's called LDAP.

LDAP, or the Lightweight Directory Access Protocol, enables information about objects (most commonly users but also computers, printers, servers, pretty much anything), to be held in a tree-like organisational structure. You can associate key pieces of information with these objects, things like passwords, email addresses, HR information, home directories, and so on. Once you've done this you can use your directory as the basis for managing pretty much everything about your network. It's the Holy Grail!

One of the things Microsoft networks have historically done, and done reasonably well, is to give a form of single signon to the network and all its services (as long as they're Windows of course!). It's the basis of Windows networking's supposed 'ease of use' (along with GUIs for everything!). It comes with a price tag, however - and I don't just mean money. The thing is, if you use a Directory Service that locks you into a single platform (whether it's Sun, Microsoft, Novell, anyone), you've just slapped on a pair of lock-in handcuffs and dramatically reduced your options. And guess what vendors do when you run out of options . . .

Quite simply, for many tasks, non-Windows software does a far better job. But these days it's Open Source software that does the best job of all.

Simply better software:

Over the next few months, OPEN For Business! will show you how to build an entirely Open Source Directory Service. One that will give you options. I will show you how to do this and why you should want to. I will show you how you can integrate what proprietary vendors disparagingly call your 'legacy' systems (even though you appear to be getting perfectly decent service from them!), and how you can weld together multiple platforms, different generations of technologies, servers, services and desktops into a functional whole, without mortgaging your future to a roadmap your vendor tells you is "the one true way".

This is a big subject, so we're going to take several episodes to cover it. Here's a taster of what we'll do:

• Single user account base and single sign on across all of your non-Windows systems (Linux, Solaris, MacOSX, FreeBSD, HP-UX, etc)
• Extending this account base to offer the same accounts, home directories, passwords, etc to your Windows servers and desktops
• Using the same accounts to manage access to key network services (email aliases and routing, Internet access, web server access, FTP, network file systems, the list goes on)
• Extending your directory to represent groups, desktop PCs and workstations, printers and other objects
• Using your directory for a company-wide single address book

It's simple, it's easy to do, it's fast and it's reliable. The business will absolutely love it and your FD will smile all the way to the bank. And all because it's simply better software.

Providing printing for a network is quite different to providing it for a single machine. On a single machine you simply attach a printer to the 'USB port' or 'parallel port'. However, for a network you have a dedicated machine (called a 'print server') that collects print jobs from any machine on the network, holds that job until a specified printer is ready (known as 'spooling'), and then feeds it to that printer. A good print server may also do a number of other useful things - like keeping track of usage statistics for departmental charging purposes, etc.

Printing in this way has a number of advantages. A major one is that it is far, far easier to administer - one or several central print servers are simpler for the IT team to look after than tens, hundreds or even thousands of different printers connected to and controlled by individual PCs all scattered around the building. Another advantage is that it increases the print options available - any user can send their print job to any selected printer (on the network), get back to work, then pick up the printed output later. They are no longer limited to the single printer directly attached to their PC.

What we're replacing:

Walk into any IT department in the country and ask them what their biggest user complaints are. I guarantee two of the TOP complaints will be "email's not working!" and "printing's slow/not working!".

Printing can be an IT support nightmare. Many businesses do it with one of the various flavours of Windows Server Edition, and very often this is at the root of the problem...

Firstly, there are all of the usual Windows issues. Instability, low uptimes, unexplainable crashes that need a reformat and reinstall to 'fix', virus susceptibility, poor security and, not least, the high cost of licences, CALs, support etc. But, more than this, using it to control printers brings loads more! Print jobs get lost or stuck, printers print out gibberish, scalability is dreadful forcing an unnaturally high ratio of servers to printers. And sometimes, perhaps just to keep us on our toes, it just stops printing and needs a reboot.

However, what I find even more worrying is that using Windows as a print server also drives you towards, or locks you further into, a Windows-only infrastructure. Try serving Macintosh or UNIX workstations from a Windows print server - it 'can' be done, but it's not easy, it's slow and it's even more unreliable! And if the business does require print services for Macs, there are no options, you have to purchase the even more expensive Windows Advanced Server (did you know, by the way, even though it's a Mac, once it's connected, you have to pay a Client Access Licence for the privilege! Money and trees spring to mind).

Here's how to change all that and get the fast, reliable, platform neutral print services your business needs plus save a great deal of money while you are at it.

Open Source, simply better software:

Once again, GNU/Linux and Open Source is simply the better business solution. As a print server, an Open Source solution is perfect. Since it is modular software, you only need to use the bits you require. This means you aren't forced to swamp the hardware with all that general purpose Windows code, you install made-for-the-job, fast, reliable, efficient modules that do precisely what you want. The end result? A lean, mean printing system that runs very, very happily on low spec hardware yet that delivers twice the speed of its Windows equivalent and is four times as scalable. And there are no licensing costs whatsoever. Now, won't the business like that!

Samba is the key to all this. After GNU/Linux, Samba is the 'crown jewels' of the Open Source world. You can think of it as an Open Source Windows Advanced Server on steroids. A network full of Windows desktops expects (in practice, demands) to see a Windows Server as its back-end. The genius of Samba is that it shows them one! Samba presents printers to your Windows desktops in exactly the same way as a Windows Server - so, from the user's perspective, it looks and feels like a Windows server. It is so seamless that all they see is that it is faster, it doesn't crash, and there are no viruses taking it out every few weeks.

Configuring Samba is simplicity itself edit a simple text file if you're an 'expert', fire up an easy-to-use GUI if you're not.

To complete the system you also need to install CUPS (the Common Unix Printing System) which handles the physical mechanics of printing. CUPS is a state-of-the-art printing system. Its many developers include HP's finest engineers, and they know a thing or two about printing so it ought to be good! Samba hands over the print jobs it receives from the Windows desktops to CUPS, which then handles the rest. Despite (or maybe because of...) the U for UNIX in the name, CUPS is a superior printing solution whether you're printing from UNIX, Windows or Apple Macintoshes. It is fully cross-platform and uses open protocols (IPP). It can handle any type, shape or breed of printer from lowly Deskjets to big lasers to esoteric poster printers, you name it, it handles it so no more problems with identifying, searching out and downloading drivers that work with the various versions of Windows you have in use. And once again, just like with Samba, configuring CUPS is a doddle text based or through a simple GUI.

So there you have it. A couple of day's work and you have all the printing system you'll ever need. And it really is as easy as that. You've now got a far more reliable, simpler and faster solution. You've eliminated one of the major causes of user complaints. You've reduced your exposure to, and dependency on, Windows technologies and the constant hardware/software upgrade treadmill they force you on. Even more, you've saved the business a great deal of money on hardware, support staff time, software licences and CALs.

And it's not through some kind of magic, it's simply because it's better software.