Bugs! Everywhere, Bugs!

Last week I wrote about our purchse of Quad G5 PowerMacs and the theoretical problems with buying Mac Pros for our lab. In that article I wrote:

New Mac hardware tends to have "growing pains" — usually minor, but still sometimes troubling bugs and problems — that I'd just as soon avoid.

Little did I suspect that bugs would also haunt our G5 purchase as well. After unpacking and building our new PowerMacs, we noticed tiny insects crawling around many of the new keyboards. On Thursday, I went to check on the latest Mac we'd built and noticed what appeared to be dirt on the mouse. Upon closer inspection, this "dirt" turned out to be several tiny insects — some very small bugs, and some even smaller "babies" — crawling about the Mighty Mouse. These same bugs could be found swarming all over the Mac's case. Truly disturbing!

I have no idea what sort of bugs these things are, nor from whence they came. Did they come from the manufacturing plant? From the distributer? I couldn't say. But a few hours after discovering the latest batch, they had altogether disappeared. While I wish I'd had a chance to take a picture for reference, I can't say I'm sorry to see them go. Here's hoping they don't reappear in a few months, giant-sized and man-eating.

Just when I thought my job couldn't get any weirder.

PPC VS. Intel Macs: A Buyer's Rationale

Having just bought a batch of Quad-Core PowerMac G5s for my lab, I must admit to a touch of buyer's remorse and defensiveness over said purchase. We knew the Mac Pros were coming, and there was much discussion here about whether or not to wait for them and buy Mac Pros instead of PowerMacs — or to do a half-and-half type scenario somehow. We even drew a pros-and-cons chart on the whiteboard. The bosses were on the fence; the decision was ultimately mine. As I mentioned in my last post, I argued in favor of getting all PowerMacs and waiting two years (which is the length of our lease cycle) to get Intel hardware. As drool-inducing as the Mac Pros look, I stand by my decision. And now I have some additional validation in the form of benchmarks.

My basic rationale for sticking with the PowerPC platform was the following:

• The PowerMac is a known quantity. We know what we're getting here. We know it will be great, and fairly precisely just how great it will be. It's the safe bet.
• This machine, while perhaps maybe not the fastest, will be plenty fast for our needs for the next two years.
• New Mac hardware tends to have "growing pains" — usually minor, but still sometimes troubling bugs and problems — that I'd just as soon avoid. Stability and reliability over speed and novelty. It doesn't matter how fast the machine is if it won't boot or it's in the shop.
• Buying Intel hardware would entail working with, and maintaining, essentially two separate platforms — one Intel, one PPC — each with it's own separate OS, applications, troubleshooting routines and set of software updates. Our lab is heterogeneous enough, thank you. Adding a new platform would only complicate things more in our already complicated lab.
• But perhaps the strongest argument I made was that, for all these potential troubles, we won't see much real-world advantage on the Intel hardware for at least the first year of the lease. Why? Because a large proportion of the applications we use on our Macs won't be Universal Binaries until some time next year. Applications like Maya, the entire Adobe suite (which now includes all former Macromedia apps), and the Microsoft Office suite are all mainstays of our lab. They are, in fact, the apps that get used the most. And they currently run slower on Intel Macs than on PPC. While the performance of Intel-native or UB apps is certainly better on the new Macs, this advantage is largely negated by the performance hit apps running in Rosetta will experience.

The Mac Pro: Be Afraid; Be Very Afraid
(click image for larger view)

After the initial release of the Mac Pro, I started to worry that I'd overestimated that performance hit. But a few sites have already gotten their hands on the new machines and are testing them. They seem to confirm my initial suspicions and my decision to stick with PPC for this lease term. MacWorld raves about the performance of the new Macs. But their tests mainly include native or UB apps. The one exception is the Photoshop test, in which the Quad G5 soundly trounces the Intel. Bare Feats' tests are more comprehensive, and again show the G5 Quad beating the Intel Mac Pro in all non-native applications. This is especially significant for us, since this includes our most commonly used apps. If you really think about it, at worst we break even, and at best come out slightly ahead in the performance game by buying G5s because of the apps we use. And we'll probably come out way ahead on convenience and manageability and all those little lab admin intangibles that mean so much to folks like me.

Finally, while factors like the amazing upgradability of the Mac Pro might influence some users to buy the new machine (and rightfully so — if I were buying for myself I'd probably go Intel), such issues don't concern us. Our machines are leased for two years. We will not be upgrading them. We're mainly interested in a certain level of performance — though not necessarily the absolute best — and stability. We want fast, reliable, easy-to-manage machines. And that's what we got.

In two years the transition to Intel will be truly complete from the standpoint of the end-user, and at that point we'll certainly buy Intel Macs. (We won't have a choice anyway.) But for now I'm pretty confident that I made the right choice in sticking with the G5. And so far, the users love the new Macs. They are great machines.

Except for the one that shot sparks out the bottom and had to be returned. That one, not so great.

A Problem with Managed Preferences

In our labs Mac OS X machines bind to a Mac OS X Server for user authentication. But this also affords us the opportunity to control certain aspects of our workstations' behavior en masse as well. And we certainly take advantage of this. The way this works is simple, and, when it works properly, a thing of beauty: Open up Workgroup Manager, create a computer list, add computers to it and then set whatever preferences you want on those systems. Just about anything you can set in System Preferences can be controlled from the server — Login Items, Energy Saver settings, and my personal favorite, Printers, to name just a few. The Open Directory host — your OS X Server — will make sure all the prefs you set in here are managed on the specified machines.

But recently I had a few machines that would simply not allow themselves to be controlled from the server. Binding was working properly, as evidenced by the fact that network logins worked. But any sort of managed preferences would not be sensed by the workstations. This is a perennial problem and historically has had something to do with mcx_cache settings not being reset by the server. But this has gotten much better over the years, to the point where it's not usually an issue. Still I tried everything with regards to cache, and no matter what I did, authentication worked but managed preferences did not. Finally, today I managed to stumble upon the solution.

Turns out there's a little quirk in the Workgroup Manager. Seems if you add the same computer to two different lists, you'll get two separate entries in your OD database — one called "computer" and one called "computer_1." I did this. And then later I deleted the original "computer" entry from the first list, and renamed the "computer_1" entry back to "computer" in the WGM GUI. This is a no-no. And it's what was causing my computer control problems, though there seemed no apparent problem from the standpoint of the standard WGM interface.

Workgroup Manager Preferences: Show Me the Records!
(click image for larger view)

The solution was to enable WGM's "Show 'All Records' tab and inspector" preference, which gives you a much more accurate view of your Open Directory database than does the standard GUI interface. Once the "All Records" tab was enabled I opened it up and looked at the "Computers" list from the pull-down on the right (just below the search field). Lo and behold, there was my "computer_1" record, but no "computer" record. Looks like the server was getting confused as to whether to control "computer" (as set in the GUI) or "computer_1" (as was actually entered in the OD database). So I deleted all references to the machine in the "All Records" inspector, then went back into the GUI and re-added the machine to the appropriate list. Voila! The machine instantly began getting managed preference settings from the server.

So the rules of thumb here are:

1. Avoid adding the same machine to more than one list. You're not supposed to do it, and it can muck things up.
2. The "All Records" tab is your friend. Look here for more accurate views than the standard GUI can provide. Edit with care as necessary.

My lesson for the day.

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.

Three Platforms, One Server Part 8: A Minor Snafu

So far we've hit only one very minor snag in our migration to a single, unified authentication server for Mac, Windows and Linux. Since Mac and Linux behave so similarly with regards to authentication — in fact, I'd say they're practically identical — and since Windows is so utterly, infuriatingly different, you can expect most of our problems to happen on the Windows side. At this point it should go without saying. This latest snag is no exception.

Today we discovered that applications to be used by network users on Windows machines must be installed by a network user, and this network user must be a domain admin. Put another way, if a Windows application is installed by a local administrator, it will not be fully accessible by users who authenticate via the domain hosted by the Authentication Server. Typical.

The solution is fairly easy, albeit kind of a pain. On each client workstation, you must give the network admin user (i.e., a user whose account exists only on the authentication server) full access to the "C" drive. You heard me: On each computer. Giving full access to a user on Windows requires logging in as a local admin and granting the network user full access rights. Windows then changes the access permissions on every file on the machine, which takes a long-ass time. You heard me: long-ass.

If we had to do this on every machine by hand, I'd be grumpy about it (but I'd do it anyway). Fortunately, we'll be building our Windows boxes from clones, which means we only have to do this once on a master build. the change should propagate via the clones after that. So I'm a pretty happy camper. And we're back on track.

Still, Windows, what the fuck?

And just to be clear on this, I honestly don't know enough about Windows or Active Directory to understand why this is happening. All I know is what we've observed, which is that Windows apps fail to run properly for network users when installed by local users. We tried matching the users and groups we'd had on the old Windows Server, but that did no good. Setting full access locally for a networked user was the only thing we could find that worked. It's very possible, however, that there's a better solution than the one we're using. If anyone can enlighten me, I'm all ears.

Oh, and yes, our network user has full access privileges for the directory domain. Confused? Me too.

More to come...

UPDATE: I found a better solution. A network user can be added to the "Administrators" group via the Users and Groups control panel. Doing so is not particularly intuitive, but it works and saves us the trouble of having to modify permissions on the entire "C" drive.

Windows "Advanced" Users and Groups: By "Advanced" I Think They Mean "Annoying"
(click image for larger view)

It essentially requires logging in as a local Administrator, navigating to the "Advanced" window in Users and Groups, and then adding the user to the "Administrator" group.

Group Properties: Do We Really Need This Window?
(click image for larger view)

Windows doesn't see a network user unless she's logged in, so you have to know how to enter a network user. It should look something like this: DOMAIN\user, where "DOMAIN" is your Active Directory Domain, and "user" is the user name.

Add the User Here: Who'd a Thunk It?
(click image for larger view)

You can find more complete instructions here, which is where I got these images.

Fun stuff.