External Network Unification Part 5: Almost There

It's been quite some time since I've been able to post anything of any substance. This has a lot to do with the fact that I've been super busy relocating our department and participating in the gut renovation of our lab. This has been an immensely stressful process, but in the end I find that I've learned so much from it, I simply can't complain. I'm coming out a far better SysAdmin than I was going in. And that's a remarkably valuable thing to both me and my employers.

But moving and planning the physical aspects of the new lab has only been a portion of what I've been working on. This renovation has been the perfect opportunity to rebuild our network infrastructure, and part of said rebuilding has resulted in the near completion of our authentication unification project. At this point we've gone from eight different authentication servers — that is, anytime we created a new user, we had to do so on eight different systems — all the way on down to two. Which means that now, anytime we create a new user, we do so on two machines.

Our goal is to get it down to one, hopefully before the Fall semester begins. Our mail server is proving to be the most difficult machine to get working with LDAP authentication, mainly because it authenticates mail users through the wonders of some weird combination of authd, Courier and PAM, and we've yet to crack the magical code that gets these all working in tandem via LDAP. Aside from Mail, though, everything is done. So I thought I'd take a bit of my hard-earned vacation and loosely describe to you how it's all working.

Before I start I'd like to just acknowledge all the help I've had from my fellow SysAdmins in the department. I had a huge amount of assistance on the *NIX server side of things, as well as with network infrastructure and even some last-minute PHP finagling without which this project would have taken significantly longer. In fact, all I really had to do was build the authentication servers and clearly articulate what I wanted. I'm extremely grateful to everyone who helped out.

The little bit of network infrastructure I mentioned is our DMZ. We now have a proper — and more importantly, properly secured — DMZ on which to place an authentication server. I won't go into too much detail here, but suffice to say, having a secure DMZ gives us all kinds of options for authentication between internal and external networks, and makes me feel a whole lot better about using Mac OS X Server as our authentication system for both networks.

Yes, we are using Mac OS X Server to authenticate our entire network. The reason is because Mac OS X Server is the most mature and usable implementation of LDAP for user authentication available on the market today. Is it perfect? No. Is it completely secure? Probably not. Is there anything that even comes remotely close to being able to handle the complexities of user management and database redundancy across platforms with such remarkable ease-of-use? Nope. Nothing. We tried building our own custom LDAP server, which would have been excruciating, and would have taken forever. We tried Red Hat's Directory Server, which looks like it will eventually turn into something to match Mac OS X Server, but which just wasn't yet up to snuff. Nothing matched Mac OS X Server, which did everything we wanted it to, right out of the box and with a minimum of fuss. In fact, once the user database is built, building a Mac OS X master or replica authentication server is a complete and total breeze. At the time of our building and testing it was really the only practical option.

So, here in a nutshell, is what we have:

Internal Network
All authentication originates from the internal network. Passwords can only be changed from the internal network at this time, which is by design. Systems on the internal network include:

• Master Authentication Server
  Hosts authentication for... Well... Everything, really. This is essentially the same server we used all last year for all our internal authentication needs for Mac, Linux and Windows workstations. It's now being used to push authentication to the external network as well.
• Internal Replica Authentication Server
  This provides replication of the Master. Should the master fail, the Replica is intended to pick up services (though this doesn't always work perfectly).
• File Servers
  We have two file servers on the internal network — a Mac and a Linux box — both of which authenticate directly against the Master.
• Workstations
  We have about 30 Mac, Windows and Linux machines all authenticating to the Master.

DMZ
The DMZ sits between the Big Bad Internet (BBI) and the internal network. It has its own firewall that is fairly strict about what can get in from the BBI. All DMZ authentication originates from the internal network, but is provided by a single server which sits on the DMZ. Systems on the DMZ include:

• External Authentication Server
  This server is also a replica of our Master, but it's not intended as a failsafe. Rather, it provides authentication services to the entire DMZ. It gets its user database, of course, from the Master. But for other systems to bind to an LDAP server, its role must either be "Master" or "Replica." Setting the role to "Connected to a Directory Server" won't work. In addition to sitting on our DMZ, which is properly firewalled against the harsh realities of the Big Bad Internet (BBI), this system also makes use of its own strict local firewall for an extra added layer of security. Also, all replication communication between Replica (DMZ) and Master (Internal) is encrypted.
• Data Server
  In addition to unifying authentication, we've also consolidated data storage and access wherever possible. In the past, for instance, movies streamed from the Quicktime Server were stored on that machine's local drive. Web sites were stored on our web server. So, building a web site that used Quicktime Streaming required users to log into two separate machines — the Web Server and the Quicktime Streaming Server. Now we're storing all user-generated content on a separate, dedicated machine — our Data Server — and sharing that machine out to the various servers via NFS. Centralizing this data store means users have only to log on to one server for anything they ever want to do. And also that only that server needs to authenticate users. And yes, that server authenticates them via LDAP on our External Authentication Server. All neat and tidy. Internal and external home account data is still segregated, however — users still have separate internal and external data storage. Though, if we could figure out how to do it securely, this could change.
• Quicktime Streaming Server
  This machine also uses its own local firewall. It gets its user database from our External Authentication Server over secure channels using the "Connected to a Directory System" as its role currently. Ultimately, however, because of the Data Server, this machine will not need to authenticate users. We are leaving the ability open temporarily to accommodate legacy users.
• Drupal CMS
  Our new Community site is built on the Drupal engine. We're using the LDAP module to authenticate to the External Authentication Server. Drupal's LDAP module is simple and easy to set up, as is the Drupal system as a whole. So far we're very happy with it.
• Computer Reservations System
  This is a custom web app built long ago by a former student. We've (and by "we" I mean my colleague) basically hacked the PHP code to authenticatevia LDAP rather than MySQL.
• Mail Server
  Currently not authenticating to the External Authentication Server. We're working on this and hope to have it working by the beginning of the school year.

The Future
Yes, there's more we want to do. It's always amazing how, once you've completed something, you immediately start seeing ways to make it better.

• More Redundancy
  Ultimately, in addition to the Replica, I would also like to automate a clone of the Master's boot drive to an external firewire drive as sort of an ultimate safety. Should anything ever go wrong with the Master, I simply plug the firewire clone into virtually any Mac system on the internal network and I'm back on my feet. It might also be wise to have some sort of failsafe for external authentication as well.
• More Security
  while our setup is fairly secure right now, there are a few areas I'd like to beef up even more when I get a chance. In particular, our CMS connection is not as secure as I'd like it to be. And ultimately I'd like to harden every machine on the DMZ to the best of my ability.
• More Unification
  Anything else we can unify — and at this point that's mostly internal and external data — I'm open to considering. It's going to be really interesting for me to look critically at what we've done so far and find the flaws and refine the system. But I'll constantly be looking at ways to simplify our current setup even further without compromising security. The easier our network is to use, the more useful it becomes. We've come a long way, but I'm sure we can find even better ways to do things.
• More Services
  Now that we have an infrastructure in place for user creation, we can add services freely to our network without the worry of creating users for said services. New services need only the ability to authenticate via LDAP. We're already planning an equipment checkout system, and possibly some calendaring systems.

So, I've just finalized the master authentication server. It's done. Built. Finished. Kaput. The rest of our servers are still in various states of finality, and we have until September to lock them down. But right now, unified authentication is, for all intents and purposes (and with the exception of mail), working. And we couldn't be happier. The ultimate test will be, of course, letting users loose on this new infrastructure. I'm betting they'll like it almost as much as we do. At least the ones who know the old system. New users will be none the wiser. Ain't that always the way?

*Sigh*

External Network Unification Part 4: The CMS Goes Live

NOTE: This is the latest article in the External Network Unification project series. It was actually penned, and was meant to be posted several weeks ago, but somehow got lost in the shuffle. In any case, it's still relavant, and rather than rewrite it accounting for the time lapse, I present it here in it's original form, with a follow-up at the end.
-systemsboy

Last Thursday, August 10th, 2006 marked a milestone in the External Network Unification project: We've migrated our CMS to Joomla and are using external authentication for the site. Though it was accomplished somewhat differently than I had anticipated, accomplished it was, nonetheless, and boy we're happy. Here's the scoop.

Last time I mentioned I'd built a test site — a copy of our CMS on a different machine — and had some success, and that the next step was to build a test site on the web server itself and test the LDAP Hack on the live server authenticating to a real live, non-Mac OSX LDAP server. Which is what I did.

Building the Joomla port on the web server was about as easy as it was on the test server. I just followed the same set of steps and was done in no time. Easy. And this time I didn't have to worry about recreating any of the MySQL databases since, on the web server, they were already in place as we want them and were working perfectly. So the live Joomla port was exceedingly simple.

LDAP, on the other hand, is not. I've been spoiled by Mac OS X's presentation of LDAP in its server software. Apple has done a fantastic job of simplifying what, I recently discovered, is a very complicated, and at times almost primitive, database system. Red Hat has also made ambitious forays into the LDAP server arena, and I look forward to trying out their offerings. This time out my LDAP server was built by another staff systems admin. He did a great job in a short space of time on what I can only imagine was, at times, a trying chore. The LDAP server he built, though, worked and was, by all standards, quite secure. Maybe too secure.

When trying to authenticate our Joomla CMS port with the LDAP hack, nothing I did worked. And I tried everything. Our LDAP server does everything over TLS for security, and requires all transactions to be encrypted, and I'm guessing that the LDAP Hack we were using for the CMS just couldn't handle that. In some configurations login information was actually printed directly to the browser window. Not cool!

Near the point of giving up, I thought I'd just try some other stuff while I had this port on hand. The LDAP Hack can authenticate via two other sources, actually: IMAP and POP. Got a mail server? The LDAP Hack can authenticate to it just like your mail client does. I figured it was worth a shot, so I tried it. And it worked! Perfectly! And this gave me ideas.

The more I thought about it, the more I realized that our LDAP solution is nowhere near ready for prime-time. I still believe LDAP will ultimately be the way to go for our user databases. But for now what we want to do with it is just too complicated. The mere act of user creation on the LDAP server, as it's built now anyway, will require some kind of scripting solution. I also now realize that we will most likely need a custom schema for the LDAP server, as it will be hosting authentication and user info for a variety of other servers. For instance, we have a Quicktime Streaming Server, and home accounts reside in a specific directory on that machine. But on our mail server, the home account location is different. This, if I am thinking about it correctly, will need to be handled by some sort of custom LDAP schema that can supply variable data with regards to home account locations based on the machine that is connecting to it. There are other problems too. Ones that are so abstract to me right now I can't even begin to think about writing about them. Suffice to say, with about two-and-a-half solid weeks before school starts, and a whole list of other projects that must get done in that time frame, I just know we won't have time to build and test specialized LDAP schemas. To do this right, we need more time.

By the same token, I'm still stuck — fixated, even — on the idea of reducing as many of the authentication servers and databases, and thus a good deal of the confusion, as I possibly can. Authenticating to our mail server may just be the ticket, if only temporarily.

The mail server, it turns out, already hosts authentication for a couple other servers. And it can — and is now — hosting authentication for our CMS. That leaves only two other systems independently hosting user data on the external network: the reservations system (running on it's own MySQL user database) and the Quicktime Streaming server, which hosts local Netinfo accounts. Reservations is a foregone conclusion for now. It's a custom system, and we won't have time to change it before the semester starts. (Though it occurs to me that it might be possible for Reservations to piggyback on the CMS and use the CMS's MySQL database for authentication — which of course now uses the mail server to build itself — rather than the separate MySQL database it currently uses. But this will take some effort.) But if I can get the Quicktime Streaming Server to authenticate to the mail server — and I'm pretty hopeful here — I can reduce the number of authentication systems by one more. This would effectively reduce by more than half the total number of authentication systems (both internal ones — which are now all hosted by a Mac OS X server — and external ones) currently in use.

Right now — as of Thursday, August 10th, 2006 — we've gone live with the new CMS, and that brings our total number from eight authentication systems down to four. That's half what we had. That awesome. If I can get it down to three, I'll be pleased as punch. If I can get it down to two, I'll feel like a super hero. So in the next couple weeks I'll be looking at authenticating our Quicktime server via NIS. I've never done it, but I think it's possible, either through the NIS plugin in Directory Access, or by using a cron-activated shell script. But if not, we're still in better shape than we were.

Presenting the new system to the users this year should be far simpler than it's ever been, and new user creation should be a comparative cakewalk to years past. And hopefully by next year we can make it even simpler.

FOLLOW-UP:
It's been several weeks since I wrote this article, and I'm happy to report that all is well with our Joomla port and the hack that allows us to use our mail server for authentication. It's been running fine, and has given us no problems whatsoever. With the start of the semester slamming us like a sumo wrestler on crack, I have not had a chance to test any other servers against alternative authentication methods. There's been way too much going on, from heat waves to air conditioning and power failures. It's been a madhouse around here, I tell ya. A madhouse! So for now, this project is on hold until we can get some free time. Hopefully we can pick up with it again when things settle, but that may not be until next summer. In any case, the system we have now is worlds better than what we had just a few short months ago. And presenting it to the users was clearer than it's ever been. I have to say, I'm pretty pleased with how it's turing out.

External Network Unification Part 3: Migrating to Joomla

When last we visited this issue I had just gotten the venerable Joomla CMS to authenticate to our LDAP server. I decided to build a replica of our existing CMS, which is based on the Mambo core, and do some testing to see how easy it would be to port to our LDAP-saavy Joomla core. The Joomla site gives instructions for doing this, and frankly it sounded drop-dead simple.

It turns out it is drop-dead simple. The hard part is successfully replicating the existing Mambo site and all its requisite databases and components. To do this, I first copied all the files over to the test server. This is easy of course. Then I had to get the MySQL databases over. This was a bit more challenging. Using the command mysqldump was the way to go, but I encountered numerous errors when attempting this with the standard options. After some research I discovered that I needed to apply the --skip-opt option to the command. My final command looked something like this:

mysqldump --skip-opt -u mambosql -p -B TheDatabase > TheDatabase.bak.sql

I honestly don't remember why the --skip-opt flag was necessary, or even if it was the right approach, only that it seemed to do the trick: the dump completed without errors. So I copied the database over and set everything up on my test server exactly as it was on the original server, putting the Mambo site in the proper web root, and importing the databases on the test system. After some fidgeting — specifically, making sure the Mambo config file was edited to use the new server — I was able to get the test site working. The only problem was (and still is) that the admin pages don't work. No matter what I do, I can 't login and I'm told that my username and password are wrong, though they work on the front end. I suspect a problem with my dump. It's also possible that the admin pages require a different user — one I'm unaware of — than the front-end for access. Since I didn't build the original server, I can't be sure. But whatever.

The next part of this test was to try and port the Mambo install to the Joomla engine with the LDAP hack enabled. This turned out to be fairly straightforward: Install and configure Joomla (v.1.0.8 — later versions do not work with the LDAP hack) to authenticate to LDAP; copy over all the custom Mambo files to the new Joomla site (without overwriting any Joomla stuff); copy the Mambo config file over and edit it for the new site root; trash the "Installation" folder (we won't be needing it); and that was it. My old Mambo site was now running on an LDAP-enabled Joomla engine.

There were some major snags here though. Because I could not get into the admin pages (a problem that persisted even with the new Joomla engine), I could not configure user authentication. I was able to directly access the MySQL database, however, with phpMyAdmin. Here I was able to edit my user account to use LDAP rather than using the password stored in the MySQL database by entering "@LDAP" into the password field. This worked well in fact.

One feature, however — automatic user creation — did not work so well. That is, if a new user logs in — a user that doesn't yet exist in the MySQL database, but does exist on the LDAP server — what the LDAP Hack does is create the new user in the MySQL database with a flag that says, "Get this user's password from the LDAP database." Logging in as a new user on my test Joomla server produced erratic results. I'm assuming that this had something to do with the lack of admin access to the MySQL database.

Still, we've accomplished some things here. For one, we've figured out a method for porting our current Mambo CMS to an LDAP-enabled Joomla engine. Secondly, we've shown, at least in theory, that this system can work with LDAP. The next step will be to try all this out on a copy of our live Mambo CMS on the actual web server. Hopefully, when we do that, access to the admin pages will function normally and the LDAP hack can be configured so that new users are properly added at login. If all goes well, our CMS will be authenticating to LDAP in the next post in this series.

If all goes well.

External Network Unification Part 2: CMS LDAP Connections

So I've been examining what we have, and thinking about what we want, and thinking about how to get there with regards to external network unification.

Here's what we have:

• A mail server running FreeBSD and getting user info from it's own, local DB
• A web and FTP server running same, getting user info (I believe) from the mail server
• A community site running the Mambo CMS, running on the same BSD machine as the web/FTP server, getting its user data from MySQL
• A custom-built online computer reservations system, also running on the web/FTP server, getting its user data from a second MySQL database
• A Quicktime Streaming Server running Mac OSX Server, getting user info from the local NetInfo database

Here's what we want:

• An LDAP server with all user information
• A mail server running FreeBSD, getting user info from LDAP
• A web and FTP server running same, getting user info from LDAP
• A community site running Mambo (or similar) getting user info from LDAP
• A custom-built (or prefab, if available) online computer reservations system getting user info from LDAP
• A Quicktime Streaming Server running Mac OSX Server, getting user info from LDAP

Are you sensing a pattern? Did you notice how much easier the second list is to read and understand? Boy I sure did. Extrapolate.

So, porting some of these systems — particularly the BSD machines that rely on local databases of users — shouldn't be too bad: build the LDAP server, point the BSD boxes at it, and, bam! we're done. I'm almost not worried about those. They're standard *NIX boxes, and LDAP support is built in and fairly easy to set up, at least in terms of getting user data. Same with the Quicktime Server: Mac OS X has stupid-simple support for authenticating to LDAP, and there's tons of good documentation on the subject. So I've been concentrating on our web apps, which promise to be much tougher, and recently I had what I think will turn out to be a real breakthrough.

When last I wrote about this topic I was experimenting with setting up my first FreeBSD server, and also with some simple PHP/MySQL-driven web apps that purported to authenticate against LDAP. The one I finally got to work was a freebie called MRBS. MRBS is great. We may even modify it and use it for certain staff-centered scheduling tasks. It's great that it works with LDAP, and it's pretty easy to get set up, after some trial and error and help from AFP548. It's given me a way to go with certain other proposed web-apps in the future. And, most importantly, it's allowed me to demonstrate proof-of-concept. But if MRBS is our future, what about our present?

We have a whole lot of time and effort invested in our current Mambo site. Not so much that it would kill us to move to a new system, but enough so that moving would be painful, and we'd better have a plan and damn good reasons to do so before making the attempt. So for the past however many weeks now, I've been building and testing a multitude of CMS systems. In doing so, I've been primarily concerned with two things: 1) Will this system authenticate to LDAP? 2) Does it have all the functionality (or more) that we currently enjoy on our Mambo site?

I figured the easiest thing to do — and a good place to start — would be to get our current Mambo site to work with LDAP. This would save us the trouble of setting up and learning a whole new system and porting over all our content — again, not the end of the world, but not exactly desirable either. Turns out there is an LDAP hack available for Mambo, but the hack is only supported under older versions of Mambo. I tried installing every version of Mambo I could, and every version of the hack, and every combination of these, as well as hacks to the hack I'd found in forums. No luck. I simply could not get the Mambo LDAP hack to work.

It was at this point I began to turn my attention to other CMSes that might support LDAP. After hunting around I stumbled upon Plone, which looked like a worthy contender, and which supposedly supported LDAP authentication. The thing I liked about Plone from the get-go was that it is ported to Mac OS X, which is what I'm testing all this on, so installation was a breeze. Plone even installs in its own folder in /Applications, and it's here that, somehow, the Plone site root lives. The system itself is very nicely structured as well. The interface is clean and easy to understand, and even fairly easy to modify, in minor cosmetic ways. But getting Plone to authenticate to LDAP turned out to be a little scary and labor intensive for my tastes. Plone runs on Python and MySQL (as opposed to Mambo's PHP/MySQL engine), so Python is responsible for making calls to LDAP. According to the LDAP module READ ME, LDAP authentication in Plone requires the python-ldap module to be installed. Installing this looked to be a pain, and no one in my organization (myself included) knows the first thing about Python, so it was at this point I bailed and began to start thinking about another approach. So much for Plone.

The next system I tried was Drupal. Drupal was also supposed to have LDAP support, though I never got around to really looking into it. I really liked Drupal: It's fast and simple, and the interface is sharp and clean. And Drupal has great user management with support for custom roles and permissions. But Drupal doesn't come with much out of the box, and I never really got around to figuring out how to install additional components. In fact, though I guess you could install one, Drupal does not come with a WYSIWYG HTML editor, which is one of the main reasons we're using a CMS in the first place. So I moved on despite some of the really nice things I saw in Drupal.

Some time later I was talking to a fellow sysadmin about all this, and he said, "What about Joomla?" and I said, "I thought that cost money." and he said, "No, it's the new Mambo." And I thought, "Hmmm... The new Mambo, eh?..."

Needless to say, the next day I'd installed my first Joomla install. I liked what I saw. It has a very similar look and feel to Mambo, particularly on the back-end. In fact, it's almost exactly the same because Joomla is developed by the former developers of Mambo. I'm not (yet) sure what went down, but apparently the bulk of the Mambo team jumped ship and began their own, separate CMS project. So Joomla really is the new Mambo.

Joomla also claimed to support LDAP, and according to their documentation, LDAP would be built in to the next release. This is apparently true, as Joomla 1.1 Alpha includes a built-in LDAP plugin. I installed the Beta and gave it a whirl, but no joy. I couldn't get the Joomla beta to authenticate to LDAP. Reading around some more led me to a new variant of the Mambo LDAP hack that's made to work with the latest stable version of Joomla, version 1.0.8. I also read what I believe was a comment in the Joomla forums from the originator of that hack who swears allegiance to the Joomla team, which probably explains why there are no new versions for Mambo.

Last week I installed Joomla 1.0.8 and the ported LDAP hack for Joomla 1.0.8 and guess what? After weeks of scrounging and searching and hoping and praying and cursing and installing CMS after CMS, it worked!

It fucking god damn worked.

This is great. Not only was installing the hack easy as pie, but setting up the LDAP authentication — for the first time since I dug in on this — was a breeze and worked completely as I'd hoped and expected it to. Not only that, but migrating our Mambo site to Joomla should be a fairly easy task since Joomla is built on the Mambo core. The Joomla site even provides instructions on how to do this, and they don't sound terribly difficult at all. The bonus is that the built-in Joomla LDAP authentication looks promising and, down the line, will hopefully eliminate the need for a "hacked" solution. But until then, the hack works great for our purposes.

This is a huge milestone for the External Network Unification project. Getting our CMS — really, our most complex web application — to work with LDAP was one of my biggest concerns. Going with Joomla gives us the LDAP stuff we need, maintains consistent usability on both the front- and back-ends, makes migrating a whole mess easier, and provides good scalability in terms of development and support for the future. Joomla's developer team appears to be solid, the third-party developer community seems very active, and the LDAP support looks to be headed in the right direction and available in the near term. While it's by no means a done deal, this looks very promising.

Next on the list:

• Getting our custom computer reservations system to work with LDAP (or finding/building a replacement)
• Learning and building an LDAP server on FreeBSD (not Mac OSX)

I'm going in. Wish me luck.

External Network Unification Part 1: Research and Development

"Systems Boy! Where are you?"

I realize posting has been lean, lo these past couple weeks. This seems to be a trend in the Mac-blog world. I think some of this has to do with the recent dearth of interesting Mac-related news. In my case, however, it's also due to a shocking lack of time brought on by my latest project.

You may or may not remember, or for that matter even care, about my ongoing Three Platforms, One Server series which deals with my efforts to unify network user authentication across Mac, Windows and Linux systems in my lab. Well, that project is all but done, except for the implementation, which we won't really get to do until the Summer, when students are sparse, time is plentiful, and love is in the air. (Sorry, but if you manage a student lab, you'll probably understand how I might romanticize the Summer months a bit.) Anyway, we've got our master plan for user authentication on our internal network pretty much down, so I've turned my attention to the external network, which is what I've been sweatily working on for the last two weeks.

Our external network (which, for the record, has only recently come under my purview) is made up of a number of servers and web apps to which our users have varying degrees of access. Currently it includes:

1. A mail server
2. A web host and file server
3. A Quicktime Streaming Server
4. A community site built on the Mambo CMS
5. An online computer reservations system

In addition to these five systems, additional online resources are being proposed. The problem with the way all this works right now is that, as with our internal network, each of these servers and web apps relies on separate and distinct databases of users for its authentication. This is bad for a number of reasons:

1. Creating users has to be done on five different systems for each user, which is far more time consuming and error prone than it should be
2. Users cannot easily change their passwords across all systems
3. The system is not in any way scalable because adding new web apps means adding new databases, which compounds the above problems
4. Users often find this Byzantine system confusing and difficult to use, so they use it less and get less out of it

The goal here, obviously, is to unify our user database and thereby greatly simplify the operation, maintenance, usability and scalability of this system. There are a number of roadblocks and issues here that don't exist on the internal network:

1. There are many more servers to unify
2. Some of the web apps we use are MySQL/PHP implementations, which is technology I don't currently know well at all
3. Security is a much bigger concern
4. There is no one on staff, myself included (although I'm getting there), with a thorough global understanding of how this should be implemented, and these servers, databases and web apps are maintained and operated by many different people on staff, each with a different level of understanding of the problem
5. All of these systems have been built piecemeal over the years by several different people, many of whom are no longer around, so we also don't completely understand quite how things are working now

All of these issues have led me down the path upon which I currently find myself. First and foremost, an overarching plan was needed. What I've decided on, so far, is this:

1. The user database should be an LDAP server running some form of BSD, which should be able to host user info for our servers without too much trouble
2. The web apps can employ whatever database system we want, so long as that system can get user information from LDAP; right now we're still thinking along the lines of MySQL and PHP, but really it doesn't matter as long as it can consult LDAP
3. Non-user data (i.e. computers or equipment, for instance) can be held in MySQL (or other) databases; our LDAP server need only be responsible for user data

That's the general plan. An LDAP server for hosting user data, and a set of web apps that rely on MySQL (or other) databases for web app-specific data, with the stipulation that these web apps must be able to use LDAP authentication. This, to me, sounds like it should scale quite well: Want to add a new web app? Fine. You can either add to the current MySQL database, or if necessary, build another database, so long as it can get user data from LDAP, as user data is always redundant and should always be consistent. It's important to remember that the real Holy Grail here is the LDAP connection. If we can crack that nut (and we have, to some extent) we're halfway home.

This plan is a good first step toward figuring out what we need to do in order to move forward with this in any kind of meaningful way. As I mentioned, one of the hurdles here is the fact that this whole thing involves a number of different staff members with various talents and skill sets, so I now at least have a clear, if general, map that I can give them, as well as a fairly clear picture in my mind of how this will ultimately be implemented. Coming up with a plan involved talking to a number of people, and trying out a bunch of things. Once I'd gathered enough information about who knew what and how I might best proceed, I started with what I knew, experimenting with a Mac OSX server and some web apps I downloaded from the 'net. But I quickly realized that this wasn't going to cut it. If I'm going to essentially be the manager for this project, it's incumbent upon me to have a much better understanding of the underlying technologies, in particular: MySQL, PHP, Apache and BSD, none of which I'd had any experience with before two weeks ago.

So, to better understand the server technology behind all this, I've gone and built a FreeBSD server. On it I've installed MySQL, PHP and OpenLDAP. I've configured it as a web server running a MySQL database with a PHP-based front-end, a web app called MRBS. It took me a week, but I got it running, and I learned an incredible amount. I have not set up the LDAP database on that machine as yet, however. Learning LDAP will be a project unto itself, I suspect. To speed up the process of better understanding MySQL and PHP (and foregoing learning LDAP for the time being), I also installed MRBS on a Tiger Server with a bunch of LDAP users in the Open Directory database. MRBS is capable of authenticating to LDAP, and there's a lovely article at AFP548 that was immensely helpful getting me started. After much trial and error I was able to get it to work. I now have a web application that keeps data accessed via PHP in a MySQL database, but that gets its user data from the LDAP database on the Tiger Server. I have a working model, and this is invaluable. For one, it gives me something concrete to show the other systems admins, something they can use as a foundation for this project, and a general guide for how things should be set up. For two, it gives us a good idea of how this all works, and something we can learn from and modify our own code with. A sort of Rosetta stone, if you will. And, finally, it proves that this whole undertaking is, indeed, quite possible.

So far, key things I've learned are:

1. MySQL is a database (well, I knew that, but now I really know it)
2. PHP is a scripting/programming language that can be used to access d atabases
3. MySQL is not capable of accessing external authentication databases (like LDAP)
4. PHP, however, does feature direct calls to LDAP, and can be used to authenticate to LDAP servers
5. PHP will be the bridge between our MySQL-driven web apps and our LDAP user database

So that is, if you've been wondering, what I've been doing and thinking about and working on for the past two weeks. Whew! It's been a lot of challenging but rewarding work.

This is actually a much bigger, much harder project than our internal network unification. For one, I'm dealing with technologies with which I'm largely unfamiliar and about which I must educate myself. For two, there are concerns — like security in particular — which are much more important to consider on an external network. Thirdly, there are a great many more databases and servers that need to be unified. Fourth, scalability is a huge issue, so the planning must be spot on. And lastly, this is a team effort. I can't do this all myself. So a lot of coordination among a number of our admins is required. In addition to being a big technical challenge for me personally, this is a managerial challenge as well. So far it's going really well, and I'm very lucky to have the support of my superiors as well as excellent co-systems administrators to work with. This project will take some time. But I really think it will ultimately be a worthwhile endeavor that makes life better for our student body, faculty, systems admins and administrative staff alike.