I still don't have time to write anything coherent. So, in lieu of — and as a tip of the hat to — my inability to do so, I give you this:
They didn't study
Via Scribd.
Oh my god that's hilarious.
The Adventures of Systems Boy!
I still don't have time to write anything coherent. So, in lieu of — and as a tip of the hat to — my inability to do so, I give you this:
They didn't study
Via Scribd.
Oh my god that's hilarious.
Hello out there, oh loyal, faithful readers. All three of you.
Just wanted to pop in and say hi. It's been a solid month since I've posted anything, and that's pretty unusual. I've even stopped responding to comments, which is almost unheard of. Unfortunately it's been somewhat out of my control. Both work and life have been insanely busy. I'm not so much making excuses here as posting this so that anyone who might be reading this site knows that:
A) I am not dead (or even injured)
B) I am not planning on discontinuing the blog.
That said, I wanted to just take a moment and explain what's been going on. Our department is getting a face lift. Which is to say that we are completely remodeling our floor. Gut rehab: Power. A/C. Network cabling. Seriously. Everything is being completely redone. It's freaking fantastic. It's also a hell of a lot of work as I'm the one overseeing the entire transition, from a technological standpoint anyway, which, since this is a digital art program, represents a fairly large piece of the pie. So I'm exceptionally busy helping plan the new floor — from actual per-room computer placement, to the power needs and layout of the server room. Much of this is new to me, so I'm being educated quite rapidly and on the fly. And since this is a gut rehab, we'll have to clear off the floor at the end of the semester, so I'm planning that transition as well — from moving staff computers to another floor and setting them up with an ad-hoc LAN, to moving our entire DMZ to said floor along with the requisite internet pipes. It's not easy, and it's very much a concerted effort. Fortunately, everyone here has really pulled together, and we're actually making it happen somehow. And while I'm elated to finally be getting all this done (it's been a long time coming, believe me, and we desperately need it, if for the cabling and power problems alone — don't even get me started on the A/C!) I'm way too overwhelmed to write about any of it intelligently right now. Or much of anything else for that matter.
We have been forging ahead with our various long term projects, however. Most notably, I've started building and testing an authentication server for the external network. So far it's going exceedingly well, and it shouldn't be long before our external network has a single authentication source (hopefully this summer sometime). I've been taking notes, so expect a post sometime when things get back to normal. We've also recently bought and set up a firewall appliance which we're loving. It's now being used to properly host our internal and DMZ networks, and is really making our network management a thousand times easier and more sensible. We'll be using it for limited VPN as well, which will be sweet. Today a friend will be running a demo of Leopard in his class as well. These — along with all the goodies associated with the renovation — are all posts in the pipe. Just as soon as I get some time.
You know — if I may wax reflective for just a second — it's not even so much that I have no time to write. Clearly, I'm able to write this post. The real problem is that writing about technology takes a certain amount of brain power. No, not even brain power. Brain space is maybe more like it. With everything I'm dealing with, I've got plenty to write about, and even some time to write about it. What I'm missing is the time to actually process what I'm experiencing. And before I can write about it, I have to process it. It's not so much that I need time to write as that I need to time to think. And that I just don't have right now.
So that's what's been going on here. This can't all last forever, of course. And I'm sure I'll be posting regularly again soon. Until then, do check back from time to time. I'll try to post small bits of stuff as I can.
Okay then. Back to the trenches. This has been fun.
In the past it's always been possible to save a copy of updates downloaded via Mac OS X's Software Update application.
Recently, however, certain Final Cut Studio updates will only install via the Software Update mechanism. You can download the updater, but it won't install. For instance, the version 5.1.4 update will download several packages to my hard drive.
And I can launch the Final Cut package installer, and it will open in the Installer application. But the splash screen gives me my first hint that something is not right.
I can even navigate to the "Select Destination" screen of the installer, but here I am told that this update can only be installed via Software Update.
To add insult to injury, even though I've already downloaded the installers, Software Update, once quit, needs to download them all over again. Lame. Painful. Awful. Installing this 39 MB update on my 25+ Macs will kill my network. Guaranteed.
The ability to download software updates for later install — or reinstall — is a really wonderful function of Mac's Software Update mechanism, particularly from a systems standpoint. It's sad and more than a little scary to see it not working on certain, specific pieces of software. Here's hoping this trend does not continue.
So today, after downgrading my master server to 10.4.7, I kept getting an error on my replica. So I decided to reset the replica by demoting it to a "Standalone" role, and then re-promoting it to the "Replica" role. But even after doing this, the error message persisted. The message was telling me to check the logs at:
/var/run/openldap-slurp/replica
and doing so did reveal errors like:
ERROR: Type or value exists: modify/add: memberUid: value #0 already exists
The solution was to again demote the replica to standalone status and then archive all the files in:
/var/run/openldap-slurp/replica
to anywhere else. I put them in a folder called "old." Just get 'em out of the way. Once this was done I was able to promote my replica without receiving error messages.
Yay! That wasn't too bad.
Oh, and you may be asking yourself how I knew to do this. Well, to be honest, I don't really remember. I just know that at some point in the past there was a problem I'd had with a replica and it was caused by stale files. So, since my ultimate goal was to start from scratch, I just got everything out of the way. And lo and behold. It worked. Sorry for the voodoo explanation, though. I wish I could be more explicit. Hell, I wish I fully understood what I was dealing with. But I don't. And, though it pains me to say this, I don't have time to figure it out.
But y'know? I'll take the cure even if I don't know what caused the disease.
It's great to finally have something systems-related to post about amidst the endless bureaucracy that fills my days lately. Of course that means that — yup, you guessed it — something broke. But hey, that's what it's all about. Well, that and the fixing of said brokeness, of course.
So we recently discovered that our Windows clients were suddenly, and without explanation, able to greatly exceed their roaming profile quotas. In fact, looking at the roaming profile drive showed users with upwards of 25 GBs in their roaming profiles, which have quota limits of 50 MB. Not only that, but further testing revealed that Windows client machines wouldn't even complain if they went over quota. Any SMB connection to the roaming profile drive could exceed the quota limit without so much as a complaint from server or client. AFP worked. UNIX worked. But quotas were ignored over SMB. What the fuck?
For three days I've been trying to track this problem down, testing all sorts of quota scenarios and SMB configurations in between meetings and meetings and more meetings. Eventually, when I can't make headway on a problem, I start thinking it might just be a bug. So I started poking around in the Apple Discussions, and I found one and only one complaint of a similar nature: 10.4.8 Server with broken quotas on Windows. Had I recently done a system update that perhaps broke quotas?
So I started thinking about what in a system update could break such a thing. How do quotas work? There is no daemon. A colleague suggested that they were part of the kernel. Had I done anything that would have replaced the kernel in the last month or two?
The answer was yes. Over the winter break I had decided to update the server to version 10.4.8. Upon realizing this I began to strongly suspect that Mac OS X Server 10.4.8 contained a bug that broke quotas over SMB. Fortunately, as is often my practice, I'd made a clone of my 10.4.7 server to a portable firewire drive before upgrading. Testing my theory would be a simple matter of booting off the clone.
Sure enough, after booting from the clone, quotas began behaving properly on Windows clients again. Because I had the clone, reverting the 10.4.8 server back to 10.4.7 was a simple matter of cloning the contents of the firewire to the server's internal drive and rebooting. Voilà! Problem solved!
From now on I think I'll hold off on server updates unless I really, really need them. When it comes to servers, I think the old adage is best: If it ain't broke, don't fix it.