Hey! My Box.net-Shared iCal Calendars Stopped Working

Just a follow-up to a recent, popular post. I recently noticed that my iCal calendars — the ones I share via my Box.net account — stopped publishing, displaying a warning badge over the broadcast icon.


WTF: My Calendar Share Stopped Working!
(click image for larger view)

So I tried seeing if I could still connect to Box.net via the web. Yup. Good to go. Next I checked to see if I could still connect via the Finder and WebDAV. Nope. No go. Just sits and spins. There's the problem: No WebDAV, no calendar share. (I. Can't seem. To stop. Talking in. Short. Truncated. Sentences.)


Connecting to https://www.box.net: Or Not
(click image for larger view)

After having no luck Googling a solution, I decided I'd try to figure things out myself. And after some poking around I found the problem. And solution. The problem is the "s". See it? The one after the "http"? There in the "Connecting To Server" dialog. There you go. That's the culprit. That "s" means you're attempting to connect using a variation on the http protocol (called https, if you can believe) that transmits over a different port (port 443) than that of standard http (port 80), and that uses an additional encryption layer for security. Seems Box.net has stopped using the protocol for WebDAV communications, and is, at least for now, using standard http. Removing the "s" from my calendar shares fixed them right up.

Best way I know to do that is to select the published calendar, choose "Change Location..." from the "Calendar" pull-down menu, and in the field marked "Base URL:" change the "http" in the URL to "https". Hit publish, and everything should be right as rain.


Fixed: Ahh! That's Better!
(click image for larger view)

I'm not sure why the good folks at Box.net decided to change the connection protocol for WebDAV, nor why they failed to inform anyone (as far as I could tell, anyway). WebDAV support is a beta feature at Box.net, apparently, so I suppose we should expect some changes from time to time. Either way I'm sure glad they haven't pulled the service altogether. Hard to get too mad when the price is so nice.

UPDATE:
About five minutes after posting this article I got a comment from someone named Aaron who appears to work at Box.net. Aaron wrote:

"Sorry for the scare. Dav should be back to normal in the next few hours."

That was last night. I'm still having some weirdness, but I have to admit to being far too tired to really do any serious investigating. Thus far, I'm unable to connect to Box.net with the Finder using https or http. Neither seems to work. Oddly, publishing via iCal using http does work, but still not with https. Strange. Not a big deal. Just strange. That's about all I've energy to try. Mainly I wanted to just point out that the Box.net folks seem to really be committed to the whole WebDAV thing, and that's great. And they appear to be listening, which is also great. Thanks, Box.net folks. And thanks, Aaron.

Now off to bed with me.

UPDATE 2:
Not sure when this started working properly, but publishing calendars via the https protocol is functioning normally again. Yay!
(Updated Sept. 4, 2006, 6:30 PM)

Filed Under: Internet Applications MacOSX Server

Three Platforms, One Server Part 9: Replica Problems

This post will be a short one. Promise. We're finishing up this project, and so far it looks like it's going to be a success. We're just adding the last little bits and finishing touches right now, but we've been putting out internal authentication server through it's paces for the past couple of months, and all seems well.

In a few places along the travails of this series I mentioned the need for a fail over in the event our master authentication server goes belly up. The rationale is that, with all our eggs in the one server basket, if our master goes down, no one can log in — not on Windows, not on Mac, not on Linux. Fortunately, Mac OS X Server allows for what's known as a replica. A replica is a read-only copy of your Open Directory data hosted by another server. But it's a bit more than that. The replica also provides what's known as fail over. That is, if the master server goes down, the replica knows to take over and start serving authentication to the clients. The replica, in effect, becomes the master in the event of the master's absence, until said master returns to service, at which point the replica gracefully hands control back to the master. You can actually have multiple replicas for fail over, and for redundancy in the event of slow or separate networks. Brilliant! I've wanted one for a long time. And now I have it.

Setting up a replica is easy as pie: Set the server's "role" to "Replica", point at its master, authenticate and you're off to the races. That is, if you've set everything just perfectly on both your master server and the replica. That's the thing about Mac OS X server, and always has been: if you set it up wrong initially, you're in for a potential world of hurt. As I rediscovered last week.

After building my replica, I next went on the requisite testing spree. The test involved physically pulling the network cable from the master server, and then observing the behavior of the clients. Initially, the replica seemed to do a fine job of picking up right where the master left off. After about two minutes' time, clients could log right back in. But after about 5 minutes' time, nearly every client on our network beachballed indefinitely, and any attempt to login would hang the machine. This hanging was so sudden and so thorough, it actually froze my machine mid-cube-effect as I attempted to fast-user-switch to the login window. Some fail over! Not cool.


Fast User Switch: Frozen in Time
(click image for larger view)

So I've spent a great deal of time figuring out the solution. The logs were no help. Google turned out to be a wash. Manuals? Pfft! For the first time in quite a while, it was an Apple Knowledge Base Article that offered the fix. The article was written for people who were having problems getting a 10.4.2 replica to remain a replica. Apparently there was an issue that involved these servers reverting back to "Standalone" roles after being switched from "Replica" to "Standalone" and back again. Though this was not my problem, nor did any of the symptoms reflect what I was seeing, I finally decided to try the recommendations in the article as they seemed fairly universally applicable, and as I was desperate and had tried everything else. The article essentially details methods for cleaning out every part of the master database that references the replica, and then re-promoting the replica to a clean master. Honestly, my master database looked pretty clean to me, but there was one bit of advice that I was not aware of, and it's my suspicion that this was what did the trick for me: The OD Administrator of the replica's database can NOT have the same UID or short name as that of the master. The article recommends creating a separate OD Admin account on the master, and using this separate account when binding the replica to the master. Honestly, I had no fucking idea. Would've been nice if this had been more explicitly mentioned in the manuals. Believe me, I've read the section entitled "Setting Up an Open Directory Replica" numerous times by now. It's not there. Fortunately, it's in that article, and now I know (and knowing's half the battle).

And now you know.

So, in a couple weeks we go live with our unified internal network. I'll let you know how it goes.

UPDATE 1:
Actually, my replica seems to still not be working, at least not very reliably. What happens is that about two minutes after the plug is pulled on the master, the replica picks up. At this point, clients — both Mac and Windows — can successfully log in. Shortly thereafter — maybe four minutes later — we start having problems: the Macs can't log in, or only some can log in; Windows machines log in intermittently — one time it works, the next time it doesn't, it works after a reboot, then it doesn't; and, perhaps strangest of all, network connections to the Macs — ARD, ssh, anything but ping — become all but impossible, hanging at the attempts. This is totally a guess, but it seems to me like the clients are having serious trouble binding to the replica. They keep attempting to do so, with some initial or intermittent success, and in their attempts network connections get locked up and the machines bog down. It's almost like the replica server is saying, "Yes, you can bind to me," and then changing it's mind and saying. "Wait, no you can't. Never mind. Screw you." Again, I'm only guessing. There is nothing clear cut in the logs, and I can't find anything in Apple's Discussion forums or Knowledge Base that specifically addresses my problem. I only pray that it isn't a problem with my master server, but the master works perfectly, and it seems to me that a replica of a perfectly working master should work perfectly. The current replica is running on a Mac mini with limited RAM, and a 10/100 BT NIC, and I want to rule out potential problems that might be caused by the hardware as well as the software set up. So my next step will be to build a new replica from scratch on a G5. I'll let you know if that solves the problem.

Another thing I absolutely should mention: For Windows replication, the replica server must be set up as a Backup Domain Controller (BDC). This is done in the Server Admin application in the Windows section. It's fairly straightforward to set up, so I won't go into detail, but just for the record, it's important to be aware of this, and I wasn't until recently, so I mention it here for completeness' sake.

Having this replica isn't absolutely critical to our plan. That is, we can go forward with this plan without the replica. But having a working replica will provide an important safety net that I'd really like to have working as the semester begins. There's no good way to test it while the semester is in session. So I'm working hard to get it up and running in the final week of the summer.

So much for this post being short. More to come.

UPDATE 2:
I built the new server today. From scratch. On a G5. No joy. I honestly don't know what the problemcould be. I can only guess that something either broke with the latest 10.4.7 update, or that there's something slightly off with my master server and it's causing problems on the replica. But it's weird, because if I bind directly to the replica using Directory Access it works perfectly, which leads me to suspect a problem on the client. But it affects Windows machines as well, so that doesn't quite figure either. I hate to admit it, but I'm stumped. And, unfortunately, I don't have time to worry about it right now. I will revisit this issue at a later date, when I get some time. When I do, I'll probably post a new entry with the solution, that is, if I'm able to find a solution. I hate this kind of thing. Is anyone else having a similar problem? I feel like I'm going nuts. And I can't believe I've spent so much time on something that should be really, really easy. Fuck. What a bummer.

UPDATE 3:
I've pretty much given up on this for now. No time. And no good time to test, what with the students coming back next week. But today I noticed something strange, and it occurred to me it might be related to my replica problems. Today, when trying to make an AFP connection to the master server from a client using a simple "Connect to Server..." I got a Kerberos prompt that refused my admin credentials. Hmmm... Kerberos problems... On the master... Not good... So who knows? I may be rebuilding the master server at some point. But not now. Oh, Lordy, not now.

I'm Back: Thoughts on WWDC 2006

I really shouldn't be writing this. I don't have the time.

That's right, intro-net. I'm back. Sort of. I realize I haven't posted anything in a while. I've been exceptionally busy. And I continue to be. But today, luck, fate and timing have conspired to give me a day that looks to be fairly free. So I'm spending my time writing my first post in almost a month.

Lucky you.

It being my first day back and all, I'm a bit rusty and unfocused. So today's post will a running list of odds and ends — things I've noticed, complaints I've had, maybe even some stuff I've been working on, and then a roundup of my thoughts on this year's WWDC. Here goes.

For starters, where have I been? What have I been doing? Well, actually, I've been on vacation. It hasn't been all fun and games though. This year my vacation was spent working on and playing in a performance at Lincoln Center. It was a long and fairly arduous process from which I'm not completely recovered. I had a dream about it just last night, in fact. But it went well, and it's over. So it was worth it. Lincoln Center, baby! How cool is that?

This has left little time for systems work, hence the lack of posts. And now that I'm back on the job, I'm having trouble throwing myself back into the fray. I always kind of lose track of where I was after vacation. And now, with three weeks left before school starts, it's crunch time. Still, somehow, today I'm the only one here. Everyone else is either sick or off. It's weird.

There were a couple things I stumbled on over the past few weeks. Really little, tiny things but maybe worth a mention. First, the final word, in my opinion, on the whole Repair Permissions saga has just come down from MacWorld. It's fairly pro-repair — or at least not anti-repair — yet Gruber seems pleased. Go figure. It's a very clearly written piece that really demystifies the whole process, and at least to mind, says everything that needs to be said. Read it and then put it out of your mind. Finally.

Second, I discovered a neat little trick in Firefox: Pressing the control button while scrolling with the scroll wheel on your mouse activates forward- and back-page. Control+scroll-up will go back, and control+scroll-down goes forward. Seems backwards to me, but it's still kind of a cool trick. No, wait, you're right... It's dumb...

Finally, I wanted to talk a little bit about the announcements made at this year's WWDC. Overall, I'm a bit underwhelmed, I must admit. Maybe I'm somewhat jaded after all these years of WWDC announcements. Or maybe I really wanted there to be far, far more attention on the Finder. There was none in fact, which only leads me to believe — hope, at least — that improvements to the Finder are in the pipe, and that they were among the "Top Secret" features Steve Jobs mentioned in his presentation of Leopard.

The new Mac Pros look incredibly sweet. But then, each iteration of the pro Mac line looks exponentially sweeter, so I'm not floored. Plus, my now aging PowerMac dual G5 still feels like plenty of computer for anything I need to do. It handles it all without complaint and still feels fast. Underscoring my lack of enthusiasm, Apple now tends to release new pro hardware right after I buy my new Macs for the lab. This is fine, actually. I kind of like to stay just short of the bleeding edge here, preferring stability to speed and novelty. Getting a known quantity (we bought Quad G5s) just makes everyone's life easier. But It's hard to get excited about new hardware when you don't need any. Also, Apple has really been focused on the Intel transition, I think, so we're not really seeing many (any?) new products. Mostly what's been announced lately — and this year's WWDC is no exception — has been product revisions and speed bumps. Fine ones to be sure, but not exactly what I'd call exciting, and nothing that will change my life any time soon. *Yawn*

Some other things I noticed while watching the WWDC keynote:
Phil Schiller said, "Our [Intel] transition is complete." While Apple's transition may be complete, the transition for users is not. Apple is right to be proud of this amazingly swift transition to Intel chips. They're unbelievably good at this sort of thing, and it's one of the aspects of the company that keeps it fresh and alive and constantly moving forward. But make no mistake: the transition for users is still in progress. Many major applications are still PPC-only and must run in Rosetta, negating many of the advantages of buying new, Intel-based hardware for the near-term. And the OS is not yet Universal. This means that, in many ways, we're dealing with two separate platforms when we mix PPC and Intel Macs. Each platform must have a different OS and applications. In a lab setting this complicates matters a great deal. So, I think for users and lab admins the transition is just getting started. Once all apps are Universal and the Universal Leopard is out, then we can start to call this thing done. But as it stands, there is still a lot of work ahead.

Along these lines, as yet there has been no Intel-compatible version of Mac OS X Server. But I noticed that you can configure your new Mac Pro with Server — and the new Intel Xserves surely come with it — so apparently the Intel version exists. Where is this software? Are there two separate versions — a PPC and an Intel one, as with client — or is it Universal? The answer appears to lie at the Apple Store. Clicking "Buy Now" on the OS X Server page takes me to the store (I can't seem to get there from the Apple Store directly) where it's revealed that Mac OS X Server 10.4 is a Universal application. I'm not sure when this happened (did I miss it somehow?), but something tells me my old copy of Server won't be running on my new Intel Mac mini. I wonder if there's an upgrade path to the Universal version?


Mac OS X Server 10.4: Universal? Really? Since When?
(click image for larger view)

Another thing that struck me this summer is the fact that this is the first year I don't have to upgrade my lab systems. Sure, I'm running Software Update and updating various apps. But there is no new version of the OS, and there won't be for a while. This, as it turns out, is a godsend. With my promotion, and all the various new responsibilities and projects it entails, the last thing I need to be doing right now is testing a new — and, let's face it, probably buggy — Mac OS, and worrying about implementing it before summer's end. I have to say, the slowdown of new Apple OS releases couldn't have come at a better time for me.

The one thing that really did get to me this year was Time Machine. Time Machine looks amazing. It looks like magic. It looks like... Well, it kind of looks like a toy, actually. It's almost deceptive how childlike Apple has made some thing that, for many users, is an essential yet often vexing task. While I think the UI for Time Machine is ultra-cheesy (though no less so than Dashboard), I also think it's immediately and intuitively understandable. And for something like backups, that's no small feat. It may be somewhat garish-looking, but I think it's about twelve billion times more attractive and user-friendly than something like Retrospect. It's a look I could learn to love for it's personality. Here's hoping it works as well as it appeared to in the the presentation. No one but Apple could make backups so intuitive, so appealing and so fun. Yes, fun. Makes me almost want to lose some documents.

Time Machine: Powerful and... Fun?...
(click image for larger view)

And speaking of cheesy graphics, Core Animation looks great. I've little doubt that Core Animation will be used to great success. I've also little doubt it will be abused by bad UI designers. Can I just say? Brace yourselves for the cheese.

Spaces also looks cool. I've never been a big virtual desktops kind of guy. But once it's baked into the OS, I may end up taking advantage of it after all. It looks like Apple's done a great job with it. One thing: Some folks are complaining that Apple tends to steal existing ideas from small software developers and put them in OS revisions. I don't really think this is always fair. Here's how I see it: Apple puts out the OS. Things — like, oh, I don't know, Finder labels, for instance — are missing. In the interim, some enterprising software developer comes along to fill the void with a program that brings labels to the Finder. The people are happy. In the next OS release, Apple then adds labels to the Finder, thus effectively ending the need for the third-party solution. Suddenly people are accusing Apple of stealing the idea and putting developers out of business. But the fact is, Apple had labels in Mac OS 9, which is why people wanted them in the first place. If anyone stole the idea, it was the developer who implemented the third-party label solution. But the fact is, no one stole anything. These ideas — Finder labels, tabbed chats, virtual desktops — are out there already. Software developers know this. They know it's risky to develop apps that could someday be implemented by Apple themselves. In fact, unless you're idea is fairly original — i.e. not a web page creation tool, not system modification, not a browser — you should expect some competition. Whether that competition comes from Apple or another third-party developer makes little difference in my book. Spaces is just Apple's implementation of an idea that's been around for a very long time.

The vague demonstration of Spotlight's new features has me worried, as I always am when it comes to Spotlight. The big new feature of Spotlight (well, aside from the boolean functionality, which is great) is it's ability to search network drives. Yes, this worries me immensely. One of Spotlight's biggest issues, in my book, is the problems it has returning relevant results. When Spotlight searches my huge store of files and folders, the results I get are usually not very useful. There's just too much stuff there, and its relevance is determined — well, I don't know how it's determined, but it doesn't seem to be very accurate for most of my needs. I have chalked this up to the fact that I have a very large amount of data. Users with less data seem to like Spotlight more than I do. So my worry is, what happens when you add to this already burgeoning local data, the data of all the machines on your LAN, which in my case is about 30 Macs? Surely the boolean functions will help aggregate more sensible results, but I worry that the accuracy and speed gains of the new version will be negated by all that extra data. What I was really hoping for from Spotlight was more ways to customize and configure the app. It's possible that wish will still come true. I hope it does.

Finally, one other thing I noticed in the keynote speech. It's something I've noticed in previous keynotes, actually. Steve Jobs, at least when he's onstage, always uses point-and-click to navigate the Mac. He always uses the mouse. Now I can say with a fair degree confidence that I'm a power user. That is, I know a great number of keyboard shortcuts, and I tend to use the keyboard for as much navigation as I can. I would guess Jobs is, like, the uber-power user. And yet he always uses the mouse for presentations. You never see him use a keyboard shortcut. Never. And I just wonder why. I assume it's for presentation's sake. I assume it's to show the average, mouse-encumered user how to do things. I assume it's also just more visually interesting. But who knows? Maybe Jobs is just a freakishly prodigious mouse user.


Steve Jobs: King of the Mouse
(click image for larger view)

Anyway, as I said at the top, we're in crunch mode here, getting ready for the return of students to the lab. I'll post when I can, but expect things to be lean here for a bit longer as I actually try to do some real work.

UPDATE 1:
I've found some more information on Mac OS X Server for Intel hardware. Seems if you want to run Server on your Intel Mac you need to buy the latest, shrink-wrapped, 10.4.7 version from Apple. That version is Universal. Previous versions are not. As far as I can tell, there is no upgrade path.

UPDATE 2:
A fellow blogger tells me that the coolest stuff in Leopard is the stuff not mentioned in the WWDC keynote. This is being confirmed by other reports. I'm a bit baffled by Apple's decision not to include this stuff in the keynote. Did they think it was too low-profile? Not consumer-friendly enough? I thought this conference was for developers. And I'm not the only one who seems as, if not more, impressed by some of the unannounced features than the announced ones. Makes me really wish I had the time to attend WWDC, but it'd be a hard sell to the bosses, I can t

ell you. The timing is just terrible. Oh well.

Tiger's Inspector: A Persistent Complaint

For those who don't already know, the Inspector is a variation on the "Get Info" window that appears when you select a file and choose "Get Info" from the File menu (or press "command-i"). To call the Inspector, add the "option" key to the Get Info call — in File->Get Info, holding "option" will cause the text to change to "Show Inspector," or you can simply press "command-option-i." The Inspector differs from the Get Info window in that it shows dynamic information based on whatever file you select. That is to say, Get Info will only show you information about the file you just selected, but the Inspector will update the information dynamically as other files are selected. It's unbelievably handy. Or at least it was.

The Inspector: Once Very Handy
(click image for larger view)

There has been a bug in Tiger's Inspector that has persisted right up until the latest 10.4.7 release. In Tiger, the Inspector updates its display to show the information for any given file as normal, but the permissions information — the owner and read/write access of a given file — is not updated and remains the same as the originally selected file. The only way to get an accurate view of the permissions is to close and then reopen the Inspector on the given file, which sort of defeats the whole purpose of the Inspector in the first place. I've written about this bug since the inception of 10.4. I've filed bug reports and feedback to Apple. Yet the bug remains, and it looks like it's here to stay. With Mac OS X 10.5 right around the corner and Tiger in its final stages I hold little hope that this bug will ever get fixed.

Inspector: Incorrect Values
(click image for larger view)

It's a real shame. Permissions inspection has been a remarkably helpful tool for me in the GUI, and I miss it a lot. But it also speaks to Apple's lack of quality control in Tiger, and particularly in the Finder. I've been bitching about the Tiger Finder for over a year now. It was one of the initial impetuses for this blog, in fact. I'm more than a little surprised and disappointed to find that a bug perhaps not of major importance to most users, but still one of significance, particularly to power users and admins — an inaccurate view of data — persists in the Tiger Finder to this day, over one year later. I can only hope things improve in 10.5.


Inspector: How It's Supposed to Look
(click image for larger view)

Strangely, I've heard very few people on the Big Bad Internet weigh in on this issue. I'm curious to know if anyone out there besides me has a problem with this. Am I the only one who uses — or attempts to use — this feature? Am I the only one who's bothered by the broken Inspector? Am I the only one complaining about this?

Feel free to sound off in the comments.

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.