Some History
In the very cross-platform lab where I used to work we were continually on the hunt for the best filesystem solution for users of multiple platforms when they were using external firewire or USB drives. That is, some folks wanted their drives to be accessible from both the Mac OS and Windows. On the surface this can seem like an easy problem to solve — Fat32 (or “MS-DOS” as it’s called in Disk Utility) is readable and writable on both platforms. But it’s not so cut and dry.

The biggest problem for me was video. See, I taught — and continue to teach — a video class in that very same department. We use Final Cut Pro as our editing software, for a variety of reasons, not the least of which is the fact that I prefer to work on the Mac. I require my students to have a firewire drive appropriate to showing in-progress video work in class. But Fat32 has a 4GB file size limit, and video captures can often exceed that limit. What happens when this limit is exceeded is interesting from a systems standpoint, but devastating from a user standpoint.

Video and Fat32
When capturing video in Final Cut Pro to a Fat32 volume, what happens is that the video file gets segmented. That is, the capture file gets written in 4GB chunks. Initially, Final Cut will see these chunks and understand what they are. But after saving the project and quitting the app Final Cut will no longer be able to locate the captured media because it’s in multiple files with different names. The path to the media that FCP relies on is now, essentially, broken. This actually happened to a student of mine some time ago, and we were able to use the cat command to reconstruct the single movie file onto an HFS+ volume and then point FCP at the reconstructed file. Boy was that fun.

NTFS
We’ve often looked to the ever-popular NTFS file system as a possible future solution. It does not have such small file size limits, and it’s readable on Mac and Windows. But the Mac has never been able to write to NTFS. So, in the past, our solution in the lab — our recommendation for users who really needed a dual-format drive with read/write capabilities on Mac and Windows — was to use the HFS+ filesystem on the drive and use MacDrive on Windows to read and write to that drive. Inelegant? Yes. But it mostly worked.

Mac and Windows Partitions
Another potentially attractive alternative to a single, dual-platform volume was the idea of splitting the drive into two partitions and dedicating each partition to a platform/filesystem. This way, even if all your Mac and Windows data wasn’t all mushed together in one volume, you could at least keep it all on one device. This solution would likely work for the vast majority of users. Unfortunately, there was never a particularly straightforward way of doing this. Sure, it was doable. But it wasn’t easy, and it wasn’t something you could tell new students to do. In fact, it was likely to require admin access and command-line heroics, and so just wasn’t a viable solution to anyone but the most die-hard user. Until now.

Without too much mucking around, it’s now possible to create a dual-format external drive that contains a mac-formatted partition and a Windows-formatted one.

MacFUSE and NTFS for Mac OS X
The first step is the only really tricky part, and it’s not even that tricky. If you have need for a dual-format drive, this should be pretty easy for you. You’re going to need to install the MacFUSE and NTFS packages. In a nutshell, MacFUSE is an experimental set of tools for doing unsupported things with filesystems like SSH, FTP and, of course, NTFS on your Mac. And, experimental though it may be, I’ve been using it for quite a while and have not had any problems to speak of. Installing MacFUSE and the NTFS drivers will allow you to mount NTFS volumes with read-write access.

MacFUSE

So, if NTFS can be mounted read-write on the Mac with MacFUSE, and it’s obviously read-write on Windows, and it doesn’t suffer from the file size limitations of Fat32, why not just use NTFS as your über-filesystem and format the whole drive with it? That’s a great question, and I’m glad I asked it!

The thing about getting NTFS read-write access on a Mac with MaFUSE is that it’s very much a hack. Yes, it works, but it has its problems. First and foremost among them is the fact that Final Cut Pro is really not a fan. In fact, FCP might just be the best barometer of a good cross-platform solution as it seems to be so picky about filesystems. So far, the only filesystem I’ve seen work consistently well with Final Cut is HFS+. No surprise there. And on NTFS it gets downright crazy. Files sometimes won’t open. Sometimes they won’t save. It’s a scary mess, and I wouldn’t trust my FCP data on NTFS for any amount of money.

But, what the MacFUSE NTFS package does get you is a relatively easy way to format your drive with separate Mac and Windows partitions, and this, at least in my tests seems to work just fine.

NTFS-3G for Mac OS X

The easiest way to get everything you need is to go to the NTFS-3G for Mac OS X website and download the latest package. This package will install the most recent non-beta version of MacFUSE as well as the latest NTFS libraries, and contains everything you need. Once you’ve installed this bundle, you’ll need to reboot your system.

Creating the Dual-Partition Drive
After the reboot you’ll see a new filesystem option when you go to format drives in Disk Utility.

A New Option

Moreover, that option will be available to individual partitions of drives that are otherwise formatted. And that’s what’s new (to me) and what allows the magic to happen. Here’s how you do it.

1. First, if you have any data on the drive that you need to preserve, back it up. This process WILL ERASE YOUR HARD DRIVE.
2. Next, select the drive you want to dual-format and choose the Partition tab.
3. Select a Volume Scheme. I’m just doing the simplest, two-partition scheme, with one Mac and one Windows partition, but you can certainly get more Byzantine with it if you’d like.
   

   Volume Scheme

4. Set the Format for the partition you want to use on the Mac to “Mac OS Extended (Journaled),” give it a name and a size.
   

   Mac Partition

5. Set the Format for the partition you want to use on Windows to “Windows NT Filesystem (NTFS-3G),” give it a name and size.
   

   Windows Partition

6. Under the Options… set the partition scheme to “Master Boot Record.” This is needed for Windows to see your drive.
   

   Partition Scheme

7. Finally, hit the Apply button. You’ll be warned that everything is about to be deleted. Click through, and after a few seconds you will have completed the formatting process and your dual-format drive will be ready for use on Mac and Windows.

Caveats
As I said, so far this has been working really well for my class. You may still want to file it under “experimental” for the time being, at least until you’re sure it’s working safely. But I’m confident enough in this method to recommend it to my video students who also need some external Windows drive love.

It’s also important to keep in mind here that I am not endorsing using the NTFS partition for Mac data of any kind. Doing so is surely unsupported by Apple, and by all reports is fraught with problems.

The other thing to keep in mind is that, unlike with a GUID partition table, you will not be able to resize or split partitions without completely erasing the drive.

Erases Everything

Conclusion
Lastly, I realize that this process is hardly new, nor am I the first to discover it. It was pointed out to me by one of my video students, and I have a feeling the new admins at my old job have been using it for some time. But it’s new to me. This is the first I’ve heard of this and it’s exciting to me from an academic standpoint, in the context of my old job, in the context of my class, as a new option I can offer to whomever might need it, and as a symbol of progress — however small or kludgy — towards cross-platform filesystem solutions. This is just another of the very cool advances made possible by the existence of the MacFUSE (and the original Linux FUSE) effort. It’s very cool to see this sort of thing coming to fruition at last!

Another intriguing extension of the MacFUSE project — and one that I’ve used a bit myself — is MacFusion, which allows for mounting of data over network protocols such as FTP and SSH. I’m sure there are tons of others. I highly recommend folks — particularly SysAdmins — check out and familiarize themselves with MacFUSE in general, as well. As much as has been done since the last time I looked at it, there is still a ton of future potential in the project, and I see it increasingly becoming a part of the admin’s toolbox.

DokuWiki’s front page describes it thusly:

“DokuWiki is a standards compliant, simple to use Wiki, mainly aimed at creating documentation of any kind. It is targeted at developer teams, workgroups and small companies. It has a simple but powerful syntax which makes sure the datafiles remain readable outside the Wiki and eases the creation of structured texts. All data is stored in plain text files – no database is required.”

No Database
That last little bit — the lack of a database — is actually one of the things that makes DokuWiki unique. It is both its strength and its potential weakness, and one of its defining characteristics.

DokuWiki

If you are looking to install a documentation engine for a small to medium-sized workgroup, it’s true: DokuWiki is great. It’s very easy to install and only requires Apache and PHP be running on your server. This means it can be installed on any Mac OS X machine without having to install or configure much beyond Personal Web Sharing. I say, “much” because you will have to activate (not install) PHP, which isn’t too hard for savvy users, but isn’t exactly mom-friendly either. Still, it beats having to also install and enable a database application like MySQL, which most other wikis require. So DokuWiki is relatively easy to setup.

That lack of a database is nice, in that it makes installation quick and easy. But it’s also a potential drawback, albeit a minor one. DokuWiki writes all its entries to flat files and that could affect scalability, and to some extent performance, if your wiki ever became extremely large. The merits of databases vs. flat files for storing data are debated all over the Internets, but databases usually only offer a significant advantage when dealing with complex, relational data, and that advantage is usually only seen by the developer. For small to mid-sized or even large-ish sites, DokuWiki is great. If you’re worried your wiki might need to grow very large some day (like, to the point where load balancing across multiple servers is required, for instance — we’re talking big!), DokuWiki may not be for you. Otherwise, the flat file system offers additional advantages, like easy-to-parse and repair backups, to name just one.

Wherefore Wiki?
That said, once installed, DokuWiki is very easy to use. It does use its own markup for page layout, but that markup is exceedingly sensible and easy to learn. My biggest stumbling block was getting started: How do you create a page? Well, once you know, it’s pretty simple, but figuring it out took me a minute. The easiest way to create a page, is to navigate to that page. If the page doesn’t exist, DokuWiki allows you to create it. See? Easy! Maybe too easy!

So what’s it for? Well, I’ll tell you, TASB was almost a wiki rather than a blog. While both are types of Content Management Systems (CMSes), and essentially do the same thing — allow a person to easily and rapidly build and read a structured store of text and media data — the difference is intent.

Blogs — and therefore blog engines — are geared toward personal, diaristic, periodic writing. They’re usually organized chronologically, like a diary, and require no special markup when creating entries. Entries, once made, are rarely revised. One of the things I enjoy about writing this blog is that it’s a bit more personal. It’s a record of personal experience as much as, if not more than, documentation. So I stuck with using the blog format. I like to be chatty.

Wikis, on the other hand, are made to be accessed like a reference, like an encyclopedia, for instance. They’re not chronological, but are usually ordered and read alphabetically; and wiki articles are made to be maintained and updated as information changes. Wikipedia is a great example of this. There is also a blog called the Tao of Mac that uses a wiki engine for content management, showing that, in the end, the two types of engines do essentially the same thing. They simply present different capabilities to their users based largely on the purpose of the site.

Conclusion
If you’re looking for a quick, easy-to-use and easy-to-maintain storehouse of information (either for yourself, or for use with others), a wiki is a great thing to have. Need to document a procedure for your workgroup? Put it on the wiki. Need to let everyone know where that essential file is? Put it on the wiki. Just want to jot down some notes for the general use? Put ‘em on the wiki.

After using one for a few days I can already see just how damn handy a wiki is to have. And DokuWiki is super-easy both to install and learn. If you just need something small to document procedures or productions — or if you’re just looking to dip your toe into the world of wikis — DokuWiki is very nice indeed.

UPDATE:
I’ve edited the article for clarity and accuracy regarding the use of flat file systems vs. relational databases. Thanks to DokuWiki’s author for pointing out the error.

Keychain Not Found

The Keychain application also refused to read my keychains. The keychains were there, as they always had been, in ~/Library/Keychains. Keychain.app just refused to see them. Refused to add them — or anything else for that matter — as well. Keychain First Aid reported everything as fine, but the damn things just wouldn’t show up.

Suspecting some sort of weird, post-PHD permissions snafu, I copied the Keychain application to my Desktop and then launched it. This seemed to remedy the problem; the keychains became visible in Keychain.app. But upon re-launching iCal, my keychains became inaccessible again.

Mucking around in Keychain.app, everything looked fine. But I wanted to make sure that my “login” keychain was set to be the default. So I selected another keychain I have, right-clicked it and chose “Make keychain ‘systemsboy’ Default,” then did the same to the login keychain, thus resetting it as the default keychain.

Remaking the Default

After doing this I launched iCal and the password complaints were gone; the calendars all loaded properly. Launching Keychain again, however, seemed to break everything. Again! WTF? No matter what I did, Keychain would eventually lose track of my keychains, and this would cause any application that relied on them to screw up. But I did eventually figure it out.

The solution? Well, it’s so simple and so idiotic it’s hardly worth a post. But here you go: I rebooted.

That’s right. A simple reboot and all my troubles were gone.

Remember, kids: reboot, reboot, reboot!

Almost Proper
Wanting to get PHDs working, I decided to try doing things a bit more by the book. I set up our NFS Home Account Server as an NFS Reshare and shared it out over AFP. I also set my home accounts up properly in WGM, using the AFP share as my network home, and a local folder as my local one.

But PHD kept incorrectly syncing things, to the point where I’ve actually now lost some data. Seems PHD, when it syncs, is for some reason using the data on the network drive as the master data set. Files I’ve modified before leaving for work have been reverted back to their old versions — the ones on the network — over night. (Which is weird considering the fact that I was logged out.)

I’m sure this works in a perfectly standard environment, with no existing users and no NFS Reshares, when set up from scratch. But I have to say, I could not be more frustrated with PHDs. So I’m giving up for now and setting my home account back to the local drive. Of course, even reverting back to a non-managed, non-PHD, local account is difficult in this case.

Cache Insanity
The reason for this — and one of the things that’s made testing PHDs so difficult in general — is the insane level of caching the server does with regards to PHDs. Caching is so aggressive that, even after disabling PHDs on the server and restarting the client machine, the SyncAgent on the client continues to attempt to sync my homes. If I try to stop it I get an error that says I can’t stop it because I don’t have a PHD. I’m a big fan of irony, but not in my server software, thank you very much.

No Mobile Account

So now the PHD service is incorrectly syncing my local home account with a network home it shouldn’t even see. Thousands of conflicts are occurring. I’m losing data. Though I’ve disabled the service, the settings persist. This is terrible. Horrible. Godawful.

PHD Conflict Resolution: Why?

And there is no sanctioned, GUI way to stop this from happening.

Freedom!
Eventually I was able to stop the errant syncing by running the ever-trusty:
sudo dscacheutil -flushcache

Jesus! What a kludge!

You can imagine how difficult this has made my testing. I can’t be sure that any change I’ve made on the server is actually happening on the client, so it’s impossible to know where this is failing or what I might be doing wrong without starting from scratch every time I make a configuration change. And starting from scratch is pretty damned difficult as well, as the PHD settings are persistent to a fault.

Is That All There Is?
I’m not sure what to do with PHDs at this point. I don’t think they’re useful for our environment, or for any existing users. Testing them is downright painful. And data loss is a real possibility, and not a risk I’m willing to take with other users’ data.

So, after a couple weeks of some very frustrating testing, I’m afraid I’ll have to pass on PHDs. It’s a nice idea, but not ready for prime time from where I sit.

There’s a slight chance I’ll try PHDs from scratch with a fresh home account, just to see if it works at all. But we’ll see. I’m pretty annoyed at this point.

More annoyed than I ever was with Windows Roaming Profiles. And that’s a feat.

After some water-cooler-side conversation, and some excellent comments by my excellent readers, I’ve decided I might be just be a perfect candidate for something that may offer the best of both worlds.

Portable Home Directories

Portable Home Directories (PHDs), as they’re called by Apple, essentially allow a user to keep and work from a local copy of his network home account. The local account is synced up with the network account using various strategies, which I’ll talk about in a bit. It’s essentially an intelligent implementation of Windows’ crappy Roaming Profiles. The big difference is those strategies I mentioned.

Windows’ Roaming Profiles are problematic, particularly in production environments where users store a lot of data, because Windows simply hard syncs those profiles at login and logout. This means that if you’ve generated a lot of data in any given session, you’re in for a long wait when you log out — and another long wait if you log into another machine — while Windows syncs your local and network profiles. It’s a nice idea — giving you the centrality of a network account and the responsiveness of a local one — but it fails in practice because it is, essentially, dumb, causing the sync process to ruin the experience.

The experience we’re going for here is, of course, seamlessness. Or as close to it as possible. So: I want to be able to log in to my workstation and have the responsiveness and normalcy of a local account, but I then want to be able to log in to another workstation and have my documents follow me throughout a given facility. Moreover, I want the synchronization of said documents to be as invisible as possible to the user. It should “just work.” With as little waiting and confusion as possible.

This is, of course, easier said than done.

Apple takes a noble stab at this with its Portable Home Directory settings. See, where Microsoft simply syncs account data at login and logout, Apple affords some granularity in what gets synced and at what times. Apple gives you precise control over what gets synced, as well as allowing for not just login and logout syncing, but periodic syncing as well. Smart! And it could make all the difference.

But I’m getting ahead of myself again. Let’s actually step through the process of creating a Portable Home Account. I’ll show where it shines and where it falls apart for me.

Activate Mobility Preferences

• This all starts in Workgroup Manager. So fire that up and navigate to the user you want on Portable Homes.
• Make sure that user’s current home account is a Network Home Account (i.e., it lives on a server somewhere).
• Click the “Preferences” button from the toolbar, and then open the “Mobility” pane. This is where all the action happens.
  

  Mobility Preferences

Set Account Creation Options

• The first thing to set up is how and when the local portable account is created. Click on the Account Creation tab and set Manage: to Always.
• Since I already have a network home account that I’ve been using from an NFS share (on a non-Apple server), I set my user to “Create mobile account when user logs in” using the “default sync settings.” I assumed this would copy everything over from the network account to the local drive and start the ball rolling fresh, but that’s not what happened. More on that in a bit.
  

  Account Creation

• Under Account Creation’s Options tab I set a custom path that pointed to a folder that contained a local version of my home account that I’d rsynced previously. Again, I did this thinking it would speed the initial sync process, but that turned out to not be the case.
  

  Account Creation Options

Set Sync Rules

• Finally it’s time to define how the syncing between local and network homes will behave. This is the real genius behind the Portable Home Directory system, and what distinguishes it from Roaming Profiles.
• First under the Rules tab you have “Login & Logout Sync.” This allows you to set specific items to sync only at login and logout. The suggested defaults for this are mainly your account settings, i.e. your entire ~/Library folder. This is quite sane, and I stuck with this setting.
  

  Login & Logout Rules

• Note the “Merge with user’s settings” checkbox. I initially checked this, but later found it problematic. It was useful on my first sync, but it doesn’t appear to track deletions and such, so I ended up disabling it.
• Also of note is the “Skip items” section. This allows for what rsync users would call exclusions. This also greatly speeds syncing as you can exclude unneeded items such as cache and trash. I stuck with the sane defaults here as well.
• Next up are your Background Sync settings. Again, very sane defaults are provided: We back up your entire home account, periodically, in the background. Skip the usual suspects and don’t merge.
  

  Background Sync Rules

• Finally, under Options, we can set the frequency with which the server will run the background sync.
  

  Background Frequency

• I also set the option to “Show status in menu bar.” This, as you’ll see, becomes quite useful for the way I ultimately ended up using this feature.

Some Disclaimers
Portable Home Directories are actually not specifically intended for the sort of use-case we’re applying them to here. PHDs are actually designed for users with laptops that come and go onto a network that is also populated with stationary workstations. It’s really made to be used in conjunction with network home accounts, allowing laptop users to use network home accounts without being completely tethered to the network.

So to be clear, this is an experiment. I’m doing things a bit outside the norm. (I mean, what fun would it be if I weren’t.) And any problems I had were likely because of this fact. Still, it’s hinted at in the documentation that PHDs can be used for users of non-portable machines to some advantage, so I wanted to see how we could apply them to our (okay, my) particular situation.

I started off a bit outside the realm of the typical first time setup. I had two things at the outset that essentially represented a test of how we might migrate to a PHD-style system: I had a network home account already populated with data, and I had a copy of that data on a local hard drive. This represents our typical user. But I was also hoping that I’d be able to use these to get the Portable Homes process underway more speedily. This was not the case at all.

Initial Experiences
The first thing that happened when I logged into my newly Portable Homes-activated account was that I was greeted with a prompt asking me if I wanted to create a portable home.

Initial Prompt

I chose to do so (“Yes”), since that was pretty much what I was here to do. And upon login I was greeted, not with my previously set up network home account nor my rsynced local account, but rather with the standard boilerplate skel account you see when creating a new user. Worse, the server seemed to get confused as to where my home account should be placed on the local drive. Though I had defined it on my server as a custom path, it seemed to want to go in a folder called “User” on the specified drive, no matter what I entered for the custom path. Apparently, for me anyway, the custom path — and my hopes of speeding the sync process — just plain old didn’t work.

Default Login Environment: Not What I was Hoping For

After this I decided to try again. I moved my custom folder off the local drive and, in Mobility Preferences, simply defined the drive I wanted to use for my Portable Home. I also chose to “Merge with user’s settings” for this go ’round under the Rules section of the Mobility prefs. The thought was that this should pull down my network home account and create a local version from it. And this is exactly what happened. And for a time life was good and I thought I was done. I thought I’d found my magic settings. But the next day I logged in to find that once again my account had reverted back to the default, first-login settings. Yikes!

Portable Homes Weirdness

(Here I’d just like to point out the benefits of having a backup of your entire home account if you’re going to play around with this. Or just use a spare, dummy account. I actually did lose data numerous times during my testing, as you’ll see in Part 2.)

After poking around a bit I discovered that my machine had logged me into my network home. Or at least that’s where the Finder went when I hit Command-Shift-H. But my home account settings were the defaults, not my network home account settings. WTF? Logging out and logging back in I found myself in what I considered to be the right local location, and all my custom settings had returned. But this was clearly getting weird and flaky. And no matter how I configured things, the weirdness persisted. The biggest problem, though, was the fact that my local and network home accounts never synced in the background. And that was sort of the most important part.

Manual Sync
For a time I used Portable Home Directories the only way I could get it to work for me. Remember that tickbox to “Show status in menu bar?” Well, it turns out that you can use this menubar widget to manually sync your local and network home accounts. And manual syncing actually worked okay for me. In fact, it was the only way I could get my network and local data in sync.

Menubar Icon

During this time I pretty much using the default Mobility settings, but my account was on my Work drive. Portable Homes had placed it at:
/Volumes/Work/systemsboy.xahomes
for some strange reason, but I could live with that. Every so often — particularly if I thought I might be going to another machine and logging in as myself — I’d hit “Sync Home Now” in the Menubar pulldown.

Sync Home Now

This would begin the Home Sync process. The process is far from immediate, but it’s not too slow. It takes a few minutes. Once it’s done I can verify that my network and local homes are synced up.

Home Sync Status

Conflicts that the service couldn’t resolve were handled similarly to iPhone-to-AddressBook conflicts, though, with the usual PHD flakiness: often conflicts occurred where they shouldn’t have.

PHD Conflict Resolution

But the biggest problem with Manual Sync was that logging in to another computer failed. A popup alert appeared telling me I was unable to log in at this time because “an error occurred.” Great.

I was really hoping for this to be seamless, of course. But it just may not be possible with this particular setup. The best I can get out of Portable Homes so far is not much better than a glorified rsync script with a pretty GUI for running it and some semblance of conflict resolution. And it completely breaks my ability to log into other computers.

Conclusion (For Now)
In the end I decided that my troubles were likely due to the fact that I was not working in the typical Mac OS X idiom. It’s my guess that Portable Homes failed for me in this instance mainly because my network home account is on a completely different, non-Apple server, one that my Mac Server is not set up to share as a network home location. I would venture that if you set Portable Homes up just like it says in the manual, using Apple kit and AFP and the like (possibly AFP reshares would work), Portable Homes works like a charm. But if you don’t you’ll get some strangeness like I did. Ah, the joys of the bleeding edge!

On my first shot at Portable Homes I experienced a number of surprises and inconsistencies. While Portable Homes is a great idea, and in theory looks to be perfect for someone like me, there are major pitfalls in a complex, multi-platform environment that prevent it from being usable for much of anything. But Portable Homes has potential and I plan to delve more into how to get it working for us in our complex environment. In our next installment I’ll be trying a setup more closely aligned with the Apple-sanctioned method for implementing PHDs. We’ll see how it goes.

In my old job, there were basically two and-a-half SysAdmins running the whole show. And since I was the front man, most requests got funneled through me. So I was pretty much dealing with everything.

In my new job, on the other hand, I am one member of a much larger team that deals with a whole wide range of technologies — from SANs to fibre connections to video playback devices. In some respects my job description is fairly generalized. All the SysAdmins on the team essentially share the same set of responsibilities, but as usually happens, each of us has our unique talents and proclivities, and since our team is comprised of a bunch of people, we each have a chance to specialize to some extent as well. We each get to focus more on stuff we’re good at — which is to say, stuff we like — and worry less about stuff we don’t like.

Case in point: last week we got a new printer. Not only did I have nothing to do with spec-ing, purchasing or installing the printer, I wasn’t even aware of the fact that we’d gotten one until the part of the crew that installs printers had installed the damn thing.

Printer Prefs

People in my old job all knew how much I hate printers. I truly despise them. I despise the hardware — it’s large, cumbersome, ugly and resource intensive. I despise the software — the drivers are always a pain to find and install (especially Epson’s) and the bundled software is ugly and unintuitive. I even despise the act of printing itself, which is often problematic, wasteful and eco-unfriendly, particularly when dealing with inkjet technology. Prints themselves I find generally useless as they’re not searchable. And, of course, troubleshooting printer problems is a nightmare that’s usually best dealt with by simply getting a new printer.

In the past it was my job to deal with every aspect of any printer purchase and installation. Needless to say, It was one of my least favorite duties. So to never have to deal with any aspect of the printer pipeline is a dream come true. When I saw the guys setting up a printer I almost laughed out loud when I realized that I’d had nothing to do with it.

Well, I did have to add the printer to the lab systems. But that’s the best part. And that was it.

Back to building servers. Fantastic.

There are certainly situations in which local home accounts are preferable. Generally speaking, they tend to be the way to go if you can swing it. They’re usually a bit more responsive, and of course they don’t rely on a functioning network, proper network settings, authentication servers and home account servers to work. They are the de facto, the default, and they’re what most people are used to. And if your users ever only use their one computer, local home accounts are likely to be all you’ll ever need.

But in environments that involve numerous shared (network) resources, or in which people are moving from computer to computer on a regular basis and need some semblance of consistency among machines, a centrally-located, accessible-from-everywhere home account can be a real blessing. In order to sell this system at my new job (on the Mac side — Linux was already using network homes), I needed to prove its reliability, so I threw myself on the grenade, as it were: I started using a networked home account. And you know what? I really like it.

There are, as alluded, certain inconveniences with such a scheme. For one, login tends to be a bit slower as the system needs additional time to locate and coordinate with the necessary network resources. Also, there is no Trash folder for a network home, and deleting files is immediate on a Mac when done over the network. So every time I try to throw something away I get this alert:

No Trash!

And the file is deleted for good. This is probably the worst part of the networked home. No Trash. But the advantages are so great that I plan to stick with my networked home, despite the minor annoyances.

At some point not too long ago I decided that the reliability test had been a success, and that I could finally revert back to my local home account. So I synced everything back to the local drive, and changed my home account location on the server (I use server-based authentication either way), and logged in. I worked locally for a while, and then I needed to do something on a Linux machine. I logged into that machine — which uses networked home accounts — and got my old, outdated, network home. And that’s when I realized: you can’t have it both ways. You either need to go local-only, in which case you need to really only use one machine, or you need to go networked. Otherwise your data’s all out of sync. And that’s way worse than any network dependencies or minor performance hits. So I immediately switched back to my networked home. And I plan to stay there.

And speaking of having it both ways, I suppose it is possible. At my old job I had a local account on my office computer and a networked account everywhere else. This was okay, but created all sorts of problems — particularly permissions problems — any time I wanted to share data with, uh, myself. Long story short, it was a real pain in the ass. Doable, but kinda sucky. Avoid if possible.

I have to say, since committing to my network home account, I’ve been pretty darned happy with it. Most times I’m completely unaware that I’m even on the network. And it’s great to have the same environment across every machine in the lab. It’s also great to finally be able to say definitively that this approach is not only valid, but actually pretty great in instances in which it’s appropriate.

Go me!

Um… No it doesn’t…

Mr. Welch raises some good points in his article, the main premise of which is that Apple is, indeed, not an enterprise company, an idea I fully agree with. But the fact is that it’s certainly possible to worry that Apple will abandon the enterprise without thinking of them as an enterprise company. And that’s because Apple makes enterprise products that some of us have come to rely on.

Mac Server: I'll Miss You When You're Gone

I don’t think many IT folk — Mac or otherwise — think of Apple as an enterprise company. In fact, I’d venture to say that we worry that Apple will abandon us because we know know full well that Apple is not such a company at heart, and that their connections to enterprise are tenuous at best. But some of us do actually appreciate the design and ease-of-use of their server products. In my case, I’ve come to rely fairly heavily on Mac OS X Server for cross-platform authentication, among other things. I get flack for this sometimes, but the plain fact is that no one has integrated authentication for Mac, Windows and Linux in one spot in such an easy-to-build package as Mac OS X Server. Could I do this with a Windows server? Sure. Could I do it on Linux? Yes, of course I could. But I’ll spend twice as long building it, and twice as much time maintaining it, when Mac OS X Server does it out of the box with ease and grace. I suppose I could punch myself in the face over and over again as well. Do I want to? Not particularly.

I often worry that Apple will someday leave the server market altogether. I sometimes even worry that Apple will stop building high-end workstations. Hell, who knows? Maybe Apple will stop selling computers one day. But I don’t worry about these things because I think Apple is one kind of company or another. I worry about them because these are products that I enjoy using on a daily basis, and I would like to keep using them for as long as they’re the best tool for the job.

Disk Utility Partition Styles: Lies!

In fact, my Mac is a G5, but all the new hardware is, of course, Intel-based. And I’m trying to create a master build image for setting up new machines. Generally the way I do this is by making a test build on a firewire partition. I can boot into this build and tweak it until it’s perfect. And when it is, I image it to an ASR disk image for NetBooting. I was worried that architecture limitations would make this painful — that booting into my test build partition would be impossible on my PPC Mac because of these restrictions. Glad to know I can just use the old reliable APM for everything and it’ll do what I need.

Not sure when or how they worked this out, or why the language in Disk Utility has gone unchanged. That fact does give me pause. But so far booting Intel Macs from APM partitions has worked perfectly for me on multiple machines.

UPDATE:
More info at Apple’s Secrets of the GPT Tech Note, via Jeff in the comments.

In Tiger a simple defaults command could be used to modify a user’s umask (a setting that controls the default permissions for newly created files and folders). Leopard, however, changes the way this is done. Leopard instead uses a launchd configuration file. To create a custom umask for all users of a system (i.e. all user-level processes):

1. Create a file called launchd-user.conf.
2. Place the file in /etc/
3. Enter the property, then the umask setting in the file, like so:
umask 002
4. Restart the machine.

The restart may not be necessary, but if I recall it was the only way I could get it to work. If you don’t want to reboot, you’ll at least need to restart launchd and any application or process you want to use the new setting. Rebooting, though, is a nice catch-all.

Some additional info: if you want virtually all applications (i.e. system-level processes) to use a custom umask, you can leave the “user” off the file name. Using /etc/launchd.conf will have said affect, but it is not recommended by Apple (or me for that matter).

Setting a custom umask in general isn’t something I recommend either, but it’s damn handy in certain file sharing environments in which multiple users need access to the same stuff, but where ACLs — the preferred method for setting up complex file sharing permission sets — aren’t an option. Creating a common group for the users and setting up their umask to create files and folders that are group-writable is an acceptable workaround in many scenarios. Which, by the way, is what the above setting will do. A umask of 002 will create files with permissions of 775 (the opposite of 002 — it’s a mask, silly).

Okay then. Happy umasking!