But, yes, I agree that backups could become more complicated if you’re relying on network homes in this way. We are not in our environment. But this is another issue I’d like to address in a follow-up.

Regarding reinstall/upgrades, I usually prefer keep my user data separate from my system data with the use of partitions for the very same reason you’re talking about.

What’s becoming apparent to me through all of this is the fact that there are many different administration styles, and admins are using network homes for a variety of reasons. This would seem to be yet another argument for a new network home style.

The current options are quite good. But I see room for growth.

-systemsboy

Keeping user data on a central server also makes it trivial to reinstall/upgrade operating systems as necessary, then pull down account data from a central server (I have Linux and Windows machines on my network as well).

“My main problem with this approach is that, in my admittedly limited tests, it doesn’t seem to work very well. I also don’t like the level of management required. The other models, once set, require little if any tweaking whatsoever. But I could see spending a great deal of time and effort getting my Portable Home Directory settings just so.”

That entire paragraph is qualified at the top by admitting my limited ability to test PHDs. I’d hardly call that misinformation. And if that’s what you’re calling it, I think you’re the one who’s being dramatic. It’s simply a statement of my experience.

This is a relatively minor sidebar to the larger idea that this post is about. If you remove everything I’ve said about PHDs and replace it with “PHDs work great, but I have another idea,” I still think there’s a case to be made for SHDs, which is what this article is about:

“But my overarching beef with all these models is that they don’t really jive with the way most people in most of the environments I’ve encountered actually use their computers… All the current models rely on the user’s data being stored on and accessed from a centralized server. But why? Why can’t the server be the user’s main computer?”

At the end of your last comment you write:

“Autofs was brand new in 10.5. NFS homes have never been as well supported as AFP by Apple.”

Boy, you ain’t kidding there, brother, and I actually do a have a good deal of experience with this. But if you ask me, it’s actually just one more argument in favor of the SHD model, which removes the server-as-sharepoint from the equation. Some of us don’t have the luxury of using AFP shares for network homes, myself included. I don’t have a choice in this matter. SHDs, as I’ve proposed them, would solve this problem.

You seem to be bothered mainly by the fact that I’m not as well-versed as you are regarding PHDs. That’s fine and certainly true, and was never in dispute, but it largely misses the point of the article.

If you think I’ve provided some incorrect information about PHDs, fine, just say that and tell me where I went wrong (i.e. “PHDs are not necessarily difficult to implement. In many situations they work quite well and are easy as pie to set up.”) I will be happy to revisit the topic — which I’ve said numerous times that I plan on doing — and correct the record. (The pie reference will help immensely here, BTW.) I do this all the time. I even have a policy that states exactly how all this should go down:
http://systemsboy.com/2001/07/policy.html

In your initial comment you tell me that there is a “great deal of flexibility that [I] seem to be discounting out of hand.” In my response I grant you that, but remark that the flexibility you describe, while it may prove useful, doesn’t do much to convince me that SHDs aren’t still an intriguing idea. That has remained the case throughout this dialog.

Do I need to look harder at the current options, particularly PHDs and HomeSync? Absolutely! But that is not in conflict with anything I’ve written so far. If it turns out that I can get PHDs (or something else) to work in a manner that is acceptable, then I’ll happily post about it.

I’m not sure what more could you possibly want from me (okay, now I’m being dramatic). But if you let me know I will do my best to accommodate you.

-systemsboy

I know Greg quite well, and have the greatest respect for him. Howver in that thread he’s pointed out a specific problem with autofs network home directories and automated backgroun homesync for Mobile Accounts

That’s it. No more, no less.

Let me requote you:

“My main problem with this approach is that, in my admittedly limited tests, it doesn’t seem to work very well. I also don’t like the level of management required. The other models, once set, require little if any tweaking whatsoever. But I could see spending a great deal of time and effort getting my Portable Home Directory settings just so.”

You’re admitted you’ve done very little *testing*, let alone deployment with them, and you’re completely wrong about having to spend a great deal of time on it once set up.

*THIS* is why I have issues with your whole post here. You haven’t even spent time working with the technologies we already have… and you’re misinforming people as to how difficult this stuff is.

My advice is that you set up a pure vanilla OD setup.

Use AFP network home directories.
Set up Mobile Accounts, either via MCX or createmobileaccount from the cli.

Don’t do anything else until you have that working. Once you do, start playing with HomeSync.

Autofs was brand new in 10.5. NFS homes have never been as well supported as AFP by Apple. If you’re not particularly familiar with this area of technology, you should try the most vanilla setup first.

Doesn’t that exactly fulfill your use case?”

Yes, actually, that’s pretty much what I’m talking about.

I’m not talking about transportablity at all. Nor am I talking about doing this from outside the LAN (God, no!). I’m basically talking about making every system on the LAN a mini-authentication and file server, which every system on the LAN already is. My computer can already authenticate me. And it can already serve me all my files. The only thing it can’t do is treat my home account like a shared network home account, allowing other systems to bind to it and mount my share as though it were a network home. Maybe I’m missing something, but it seems like it would be quite feasible, for Apple or a programmer, to implement a system whereby my non-server system could do just that.

Yes, you are absolutely right, I could do this by installing Mac OS X Server on every system on my LAN. I’m proposing an implementation in which that wouldn’t be necessary. Something built directly into Mac OS X Client that might — or, better, might not — require negotiation via Mac OS X Server. But as far as home account data goes, nothing leaves my main machine. The home account data always stays there. And my main machine authenticates the user.

It is true that I have not had the sort of time I once did to spend testing out all the various capabilities of all the latest incarnations of Mac OS X. I’m not even sure when I’ll have a chance to try out Snow Leopard Server. My job has changed quite a bit. If the article is vague, it is probably due to that fact, and a general lack of time. Perhaps I also need to be a bit more detailed in my description of how all this would work. And maybe there’s some big piece of the puzzle I’m missing. But, so far, I haven’t heard anything to convince me that the concept isn’t sound.

I have updated the article to link to a too-brief series I did a while back on Portable Home Directories that details all the problems I had. I received many comments from others who had similar problems. In the end I got feedback from Greg Neagle, who appears to be an expert on the situation. He offered some suggestions which I hope to try some day, but which ultimately seem to indicate that PHDs can in fact be quite problematic, at least in environments such as mine. My experiments with them have left me gunshy.

As I said, I intend to follow up on all of this. It may turn out that there is a way to do what I want using OS X Server (but not installed on every computer on the LAN). If that is the case, that would be terrific and I’ll certainly report about it. It may also be the case that what I propose wouldn’t be technically feasible without some sort of server negotiation. Hell, maybe it turns out the whole idea is totally ridiculous. I don’t think so, but it’s possible. If so I’ll report that too.

If you have thoughts about any of this, or along the way, I’d love to hear them. In the meantime I’ll be poking and prodding at the idea and seeing what else I can come up with as my schedule permits.

-systemsboy

I just don’t think you’ve really looked into what is possible now.

You can’t just magically have user accounts be transportable from one machine to another. How on earth would you enforce POSIX permissions to start with? How do you suggest that the client on your satellite machine actually authenticates you?

You *need* something that is the definitive source for user information, and that’s a remote directory service such as LDAP or AD or Novell or NIS or whatever.

You could do what you’re talking about now simply by using OS X Server as your main machine, and exporting the shares to the other machines and binding them to the directory.

Doesn’t that exactly fulfill your use case?

If you’re talking about doing this outside a local network, just look at how much trouble people have with network homes and performance on a *LAN*… let alone a WAN.

External accounts remove the requirement for your primary machine to be the authoritative source of account info and home directory data.

Instead, you’ve moved both the account, and the home, to a portable device, without compromising security.

Machine specific MCX sync allows you to be selective about what syncs up/down on different machines, whether you sync at all, and whether you use a Mobile Account at all, all with the *same* account information and home directory data.

Mobile Accounts are trivial, and I’d like to see what you vague mention of problems actually refers to…

HomeSync is slightly more complex, but again, is something deployed across hundreds of thousands of machines globally. It’s not rocket science to set up, but I’m not denying that sync conflicts can be annoying. I don’t see how what you’re proposing would make the somewhat difficult problem of syncing any better?

Apple do have a solution for all of this with consumers.

For data, it’s called .Mac. As far as the user is concerned, there is no “server in the middle”.

For authentication, it’s the LKDC.

I enjoy reading your blog, and this isn’t personal at all, but this article is vague and doesn’t really indicate that you’ve spent enough time working with the relevant technologies that Apple already provide, and that many of us are running at already, from small to large scales.

Actually, you’re right, I’m not very familiar with External Accounts used in conjunction with Mobile Accounts, nor machine-specific HomeSync. I’m not sure either quite accomplishes what I’d like to see though.

External Accounts would appear to require a home account on an external drive, which seems like an awfully strange extra step if you’re looking for the sort of simple functionality I’m describing in my article.

Also, I’ve had untold trouble getting Mobile Accounts to work properly, so for now at least, I’m not really willing to mess with them too much (I did a series of posts about them a while back, though, and I’d like to revisit the matter some day).

Machine-specific HomeSync prefs sounds like it’s going to require even more management than out-of-the-box Mobile Accounts.

Look, it’s not that there aren’t some good solutions out there — and I’ve certainly used some of them quite a bit (and others less so, obviously) — but, based on my experiences, I think there’s room for another one that favors users who use local accounts 90% of the time and who only occasionally or temporarily need a network-based home. All today’s solutions require some kind of server in the middle. I think it would be immensely cool if that were not the case.

In the SHD model, 90% of the time I’m on a single machine — my machine — and I want my data to be local to that machine. The 10% of the time I’m on another machine, my home account data comes not from a server, but right off my main computer, shared right over its network connection to the remote computer. No server required.

I’m not saying that this is better than what’s currently offered. What I am saying is that A) it reflects how a lot of users I know work better than any of the current implementations, and B) I think it would be an insanely cool feature that might even, now that I think about it, have uses in the consmer market.

That said, I certainly don’t consider this issue closed. I’ve received some great feedback from friends about the idea, and I’m currently looking into possible server-based ways to accompish the basic behavior I’m talking about. So your thoughts are much appreciated. I’ll be reading up on these matters over the coming weeks and months, hoping to follow up on the article, and any additional info I can find will be immensely useful.

-systemsboy

a) External Accounts. These are essentially Mobile Accounts where the home and the account live on an external drive. So long as any machine you’re logging into knows about the original account in the remote directory node, you can login, without having to sync everything to that local computer.

b) Machine specific HomeSync prefs via MCX. You can do this via dslocal MCX, computer MCX, etc.

Both of these allow your data to be backed up at the server, which has significant advantages.

Remember you can set MCX for specific computers to specify whether users have network accounts/homes, Mobile accounts, fine grained control over HomeSync, whether external accounts are enabled, etc etc.

There is a great deal of flexibility there that you seem to be discounting out of hand.

Beyond that, the problem could largely be mitigated by an alert that appears on the host system when powering down if someone is using the SHD feature.

-systemsboy