One of the first things that needs to be done in streamlining an Enterprise is establishing a centralized naming service. Of course there are some fringe reasons not to, but the bottom line is that the IT world is continuously being asked to do more with less. If you need to manually update the passwords for 100 users on 100 systems once each month you are either a great candidate for life in a Skinner box or you are failing to do more with less.
My experience has always been that the risk of someone propagating a catastrophic change across a data center is much lower than that of someone making a subtle manual error that goes undetected for months until it rears its ugly head. When you know that your finger hovers over the big red button that controls the fate of your buddy's on-call pager you get religion fast and become very careful about what you propagate. Centralization and automation are good. Manual effort is bad. So, we've established that we want to do this. So, what is a Solaris site to do next?
There are a few naming services to choose from. In our case, common choices include: File propagation, NIS, NIS+, and LDAP. Within LDAP there are a few different implementations now that the industry has begun to move in that direction. Microsoft's Active Directory, OpenLDAP, and Sun's Java Enterprise System Directory Server. Again, going by experience, the best path is usually the one which aligns with your primary vendor's offerings. If you're running a Windows shop, use AD. If you're running a Solaris shop, use Sun's Directory Server. If you run both, it's a different question altogether, but I would be inclined to create a layered solution involving both AD and Sun DS. But, I digress. Let's take a look at the options...
File propagation isn't as bad as it sounds unless you are doing it manually. There are many bolt-on solutions for implementing the functionality of rdist. It can be done over SSH, and with a surprising degree of control. You can also use SSH with some script-fu to push scripts to be executed, or use a product like CF Engine. While not a bad solution, it tends to be a bit heavier in the maintenance and integration time. It's also somewhat limited in that it can push, but you aren't really centralizing. Systems inevitably get left out or miss pushes which results in more custom coding to make queues, and pretty soon you're on your way to reinventing a management framework. Ugh. File pushing is a good solution within its scope, but I'm not a fan when it comes to a general centralized administration scheme.
NIS is a grand old favorite. The environment I cut my teeth on included a Sparc 10 workstation hooked up to a QIC tape drive which acted as a NIS server for a building full of Sparc IPX workstations. I found it fairly easy to manage, rock solid, and generally a great technology. Unfortunately, it also included a whole new world of security gaps that while acceptable for a non critical workstation environment were totally inappropriate to a world class data center housing mission-critical data. Even if it weren't inherently insecure, Sun announced the EOL of NIS, so the end is near. Given that, I suggest that NIS is probably not the best technology to invest in these days although Linux has a good implementation that will allow it to continue for some time.
Our next option is NIS+. Have you actually supported a NIS+ environment? Yuck. After the joy of NIS I had expected a simple evolution, but it felt more like assuming that if you speak English you can speak Russian. While it fixed the gaps in NIS security, it was always annoying trying to figure out which key was broken and how to get it initialized again. Although Sun has not EOL'd NIS+ yet, it's clear that it is not a technology whose momentum is being maintained. The writing is on the wall. NIS+ again proves to be a non starter.
Finally we arrive at LDAP, and for the reasons above, We look at Sun's Directory Server. I'm currently working on a Directory infrastructure for a large site, and have been both impressed and frustrated with the product. I'll be explaining this dichotomy in more depth in future installments, but a few months into the project, I'm confident that I made the right recommendation.
Why? First of all the updates for this product come from the same place all the other Sun updates come through. Trying to keep track of multiple product update sites is a non-value-add activity. Second, LDAP is insanely flexible. You can store just about anything in a directory, and access it via shell script, OS client, Perl script, and more. Why is this cool? Its much easier than storing anything in an Oracle database because you won't need to gain a new certification in relational databases to take advantage of this new piece of your infrastructure. A systems engineer or advanced admin can do everything they need. Third, DS is part of the Java Enterprise System. JES is a stack of middleware products which are all nicely integrated with the OS and support. By giving us a stack of common and world-class components Sun has given systems engineers the opportunity to start including a deeper application awareness into their scope with an easy product to standardize on. And the final reason to go with DS and JES: It's free to download and use. Before you put it into production, USE it. Put it on your x86 machines, put it on your Sparc machines. Hack it, tweak it, learn it, know it, master it before you go live. Sun has just leveled the playing field. Now you can learn a world class product without capitol investment because Sun's on-line documentation is second to none. One last note: After you've enjoyed Sun's generous new distribution model, buy a production support contract or JES subscription. Don't go into production with unsupported software. You know better, and your customers expect that you'll advise them to do the right thing. Besides, I'm sure you didn't go into production with an unsupported Linux server, right? After all, you were too smart to fall for that whole "Linux is free" story weren't you? Nothing is free.
And for my final act I'd like to mention the paradox that continues to twist my mind into little pretzels. NIS and NIS+ were OS integrated components that were free components of a great Operating Environment. Sun has always been about the large scale net infrastructure, and the integrated NIS servers echoed that intent. With the JES Directory Server Sun has gone beyond the site-scale naming services with a product that can store just about anything and scale it to your wildest dreams. Think consolidation of eBay and Amazon identities and DS isn't breaking a sweat - it's that good. But in the mean time, there's a lot of sites that need a centralized naming service for their tightly secured data centers that will never share identities with the outside world, and never cross 1000 users. That's like having a Ferrari that never gets out of first gear.
What fills the gap between 100 and infinity? Fortunately, from a technical perspective JES DS scales in nice increments, and can deployed for a single site's centralized naming services on reasonably sized hardware. But there's a catch: Support will cost you. Even if all you are doing is Solaris native client support, the DS costs money to obtain a software support contract. Sun, what are you thinking here? Kill NIS and NIS+, tell everyone to go to LDAP, and then neglect to include it in the Operating System support? Crazy! Native OS support should be included with Solaris just as Active Directory is free with the Windows Server support. Charge us more money when we ask you for support outside native clients, but don't' make us pay for what you provide for free with NIS+.
JES is a great product, I'm glad we're using it in our project, but I was really disappointed when I discovered this Dilbertian marketing twist. There's still hope; SRM used to be an expensive add-on that's now a part of the OS. Given enough time, Sun usually does the right thing.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment