There are three basic methods in use today for hosting home accounts on networks in such a way that users have a single home account that follows them from computer to computer, giving them the same environment no matter where they log in. None of these three strategies works in a way that reflects how most people in the lab I currently work in — nor many of the labs I’ve freelanced for — use their computers and access their data. So I’d like to propose a third strategy that does.
Let’s start with a rundown of the existing approaches.
Roaming Profiles
The approach Windows computers use is called Roaming Profiles. The way Roaming Profiles work is pretty simple. Users’ home account data is stored on a centralizd server. When the user logs in to a client system her data is downloaded from the server to the client machine. She will access her data locally for the duration of the session. When she logs out the data will be synced back up to the server. The advantage of this approach is that the user has local access to her data and isn’t beholden to the network while actually working. This makes data access generally faster and more reliable. The big disadvantage here is that if the user makes any big changes or creates any big files, a large data transfer will happen at log out, and then again at login to subsequent machines that aren’t yet synced to the server. This both slows down the login/logout process and places an often undue burden on the network.
Because of the sorts of environments I tend to work in — data-intensive, video and image oriented facilities that create a lot of data — my experience with Roaming Profiles has been fairly poor. For my uses they’ve required a lot of management and have been somewhat unreliable. But, for the purpose of maintaining a user environment across multiple networked systems, they work well enough if you understand and plan for their inherent limitations.
Network Home Accounts
The method used by *NIX systems, Mac OS X included, for time in memorial, is generally referred to these days as Network Home Accounts. In the Network Home Account model, as with Roaming Profiles, the user’s home account data is stored on a server. But when the user logs in using Network Home Accounts no data transfer occurs. Instead, the home account data is accessed directly from the server: new files are written directly to the server; settings files are read directly from the server; everything happens over the network and the network share that contains the user’s home account data is treated just like a local volume. The speed advantage over Roaming Profiles at login and logout is obvious; there’s simply no lag time as data gets transferred between the client and the server, because there simply is no data transfer. On the other hand, accessing your entire home account over the network can be slower than a local account even on the speediest of networks. And on slower networks, or networks with a great deal of traffic, you’ll definitely notice the slowdown. There are also potential problems due to the constant reliance on the network and server. If the network becomes congested or the share becomes unavailable even for a second you’re liable to feel the pain. If either goes down you’re dead in the water until they’ve returned to service.
As network home account models go, I like this one the best. I’ve used it a great deal in educational settings in which resources are almost completely shared and it’s fairly reliable and usable. But even this model can be frustrating and is less than ideal when compared to working from a local home account.
Portable Home Directories
The final model is called Portable Home Directories. Devised by Apple for laptop computers with occasional — but not constant — access to the network hosting home account data, Portable Home Directories attempts to combine the best of the Roaming Profile and Network Home models by providing finer-grained control over the sync process in what is otherwise a Roaming Profile approach. So, Portable Homes sync to specific data at specified times when they’re on the network. Fine-grained control over what is synced and when is intended to mitigate performance issues at login and logout.
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.
The Problem
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. This makes them use system resources less efficiently and yields a poorer user experience than if they did.
So how do most people work? Well, what I’ve tended to see in the media-based environments in which I’ve worked is that users are generally assigned a single computer. It’s this computer from which they work almost all the time. Indeed, this is how I work in my current job. I’m almost always working from the computer in my cubicle. Almost.
Every now and then, however, I need to work from a different machine, and there are often times when I’m doing this that I realize that it would be extremely handy to have my entire home account — all my environment settings, files and folders — available to me on this other machine. But I don’t. They’re over there, on my cubicle machine. If only I could use the home account on my main computer directly, as thought it were a Network Home Account.
And this is the basic idea behind Satellite Home Accounts.
Satellite Home Directories
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? In the Satellite Home Account model, the user’s primary computer becomes the home account server for any user that sets her account as a Satellite Home Directory.
The way I envision it, it would actually be quite simple to set up. In the Accounts preference for the user would a be a tickbox to activate Satellite Home Directories. Once activated, the user’s system would begin broadcasting Satellite Home Directory information, just like Mac OS X broadcasts Network Home Account info. The user would then work locally as normal, but when logging into another system on the network — a system that’s listening for SHDs — the user would be presented with her home account over the network, shared directly from her primary system rather than from a centralized server. Simple.
Among the great benefits of this system are its simplicity and the fact that it requires no server. But the chief advantage comes from the fact that the Satellite Home Directory system works the way users tend to work. When you’re on your main computer, which you are 99% of the time, you get a fast, responsive, local home account. When you move temporarily to another system, your environment follows you. It’s a bit slower, sure. But hey, it’s only temporary. The network overhead is significantly reduced from the other methods, and the user experience is also enhanced. It’s win-win.
There’s certainly no technical reason an implementation like this would be impossible or even particularly difficult. Most of the technology already exists, either in Mac OS X client or Server. All we need is for someone to program it. And while I doubt there’s likely much interest on Apple’s part to build something like this, I really think it’d be damn sweet.
And a boy can dream, can’t he?
13 Comments
I would have to agree that none of the available options are really satisfying. I wish home folder syncing could be a little more robust like Dropbox.
Yes, Dropbox is wonderful. I particularly like the idea of snapshots and being able to retrieve deleted files. But as a home account solution it’s pretty much like Roaming Profiles (though probably more robust, as you say), which has its own set of issues.
I generally like the Network Home Account model, I just don’t want to use it all the time when I’m on my main computer.
SHDs would fix that.
-systemsboy
I like the idea, the only drawback I see at the moment is that all machines have got the powered on, which could be a problem.
I have to agree with you about the current options. I think in concept Portable Home Directories should work well enough — but don’t. If the syncing with the server was reliable enough, which I have found it isn’t, they would work okay.
I agree that the power issue could be a problem. But in most of the environments I work in computers are left powered on almost all the time. And they’re usually only powered down by the main user of the system. No one, for instance, ever powers down my computer except me, and I would know if I were logged into another computer and would likely not power down if that were the case.
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
I think you’re missing a few things here 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.
Oh, Nigel. You always think I’m missing a few things. I’m starting to wonder if perhaps I’m just a terribly unclear writer.
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
I don’t think you’re unclear.
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.
“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?”
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
Oh come on, now you’re just being dramatic
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.
Nigel, it seems that your entire gripe is with this one paragraph:
“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
SHDs are an interesting idea, sure… but the biggest benefit, to me, of keeping user data on a central server is the ability to back up just that server and not worry about the data on each individual machine. With SHDs, you’d have to either back up all the machines individually or set up syncing back to a server (in which case it’s pretty much just PHDs again).
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).
Yes, one benefit you lose with SHDs is centralized backups. This is definitely true. One strategy I see all the time, though — and it’s certainly one we use here — is that user data is stored locally while production data is stored centrally on a server that is backed up. In a situation like this, the user is responsible for backing up their personal data, while the admins have the crucial production data covered.
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