Disclaimer... I know Roaming Profiles are a modern day example of "the emperor?s new cloths". I also know that 2+2=4. Let's think Linux/Unix here a second. Preference files are stored in the user's home dir. A user can log in (text or X) multiple times, they will always get the same home dir. Thus each login instance will share those config files. The same just happens to be true of Windows clients logging into a Linux box ala Samba PDC. So why exactly is the general response to this that it is not working properly and needs to be corrected? I guess maybe I never will understand until I decide to ware rose colored glasses all the time. -- Michael Lueck Lueck Data Systems Remove the upper case letters NOSPAM to contact me directly.
On 9 Dec 2004, at 12:07, Michael Lueck wrote:> Let's think Linux/Unix here a second. Preference files are stored in > the user's home dir. A user can log in (text or X) multiple times, > they will always get the same home dir. Thus each login instance will > share those config files. > > The same just happens to be true of Windows clients logging into a > Linux box ala Samba PDC.The two are not the same. When you log in remotely to a unix-like system, you're using files in the one home directory, on one central file system. If you log in to a workstation that has NFS-mounted the remote directory, the same holds true - the files you edit are those present on the remote/central file system. When you log in to a Microsoft Windows client with roaming profiles enabled, the client will copy all of the files in your "profile" across to the local file system. You edit them in place on the local file system. Then when you log off, the files are copied back to the "profile" directory. There is no rsync or other optimisation - if you have 200MB of files in your profile, that 200MB will be copied back and forth every time you log in and log out. The two approaches have their advantages and disadvantages. In the case of the unix-like with home directories mounted over NFS, you don't want to be using KDE3 and Konqueror (for example), since Konqueror will check it's on-(NFS-)disk cache for the latest version of a file, find it's outdated, download the new file from the web server, save it to the on-(NFS-)disk cache, then display it to the user. Thus the main disadvantages of the remote/central disk method are the dependence (utter and absolute) on the remote hard disk, and the intermediate network. If either of those should stall, all machines on the network will halt as the NFS client waits for responses to NFS I/O. The main disadvantage of the Microsoft Windows approach is the bandwidth wasted while people log in and out. Both methods "need to be fixed" IMHO - a fair middle ground would be to mark some portions of the "profile" as "volatile" (and thus they won't be copied back to the central store on logout), and the actual copying back and forth of non-volatile (I'm not going to use the word "permanent") data should use an optimised copy - something like rsync, which will only copy the changes. This means you can feasibly run a 100-workstation network on 100Mbps Ethernet - no need for Gigabit unless you actually have to transfer tens of thousands of rendered frames of movies across the network (or you absolutely must have sub-millisecond timing on communications, or...) (and assuming that everyone doesn't try to log in at the same second). Alex PS: Of course, there are people out there who will tell you to get diskless workstations, and trust the network and server hardware to up to snuff. But they tend to have more money to spend than I do, and don't seem to care that a local file system is faster than a network mounted file system ;) (it helps to have bug-free chipsets on the servers, too) (and now I don my flame-retardant suit, and bring out the sun lamp) -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 220 bytes Desc: This is a digitally signed message part Url : http://lists.samba.org/archive/samba/attachments/20041209/a454e8b0/PGP.bin
Hmm. Guess I'll try sending this to the right list now. ---------- Forwarded message ---------- From: Eric Lester <eflester@gmail.com> Date: Wed, 8 Dec 2004 21:46:13 -0800 Subject: Re: [Samba] Reality Check -> Roaming Profiles To: taclug mailing list <taclug-general@taclug.org> What I've found useful by way of compromise is to use a logon script to map a drive to the user's share on the Samba server. On the client desktop I point "My Documents" at this drive and use gpedit to prevent the user from changing this target. This keeps users from saving to the "My Documents" directory in Documents and Settings, which makes the profile pretty heavy. Theoretically, you could make the desktop "read only," though I haven't done that. Yet. Furthermore, I set the browser cache limit to 20MB. This is also lockable with the Group Policy editor. And -- Thanks be to Zeus or whoever -- we don't use Outlook. Yet, anyway. If there's gonna be Outlook, though, you can point it to another place on the network (or local drive) to store the .pst. Those buggers can get very big. Or, if you have a lot of Outlook junkies, you can run something like Open Exchange and put all that drek on a database server. With these arrangements I've had a minimal amount of trouble. So far. On Wed, 8 Dec 2004 21:18:50 -0800, Matthew Easton <info@sublunar.com> wrote:> On Wednesday 08 December 2004 18:19, Alex Satrapa wrote: > > On 9 Dec 2004, at 12:07, Michael Lueck wrote: > > > > > The main disadvantage of the Microsoft Windows approach is the > > bandwidth wasted while people log in and out. > > In my experience, samba networks also have more problem with profiles becoming > corrupted and not being able to copy down from the server or back up to it. > I surmise it is differences in Win32 and Linux with respect to permitted > characters and/or path length. > > > Both methods "need to be fixed" IMHO - a fair middle ground would be to > > mark some portions of the "profile" as "volatile" (and thus they won't > > be copied back to the central store on logout), > Windows and samba already do this -- you have an invisible "Local Settings" > file in your Roaming profile where, for example, Outlook stores its .pst > files. It doesn't get copied up to the server. Of course, I'd much rather > email did get copied to the server -- leave the web browser cache behind > instead. > > > and the actual copying > > back and forth of non-volatile (I'm not going to use the word > > "permanent") data should use an optimised copy - something like rsync, > > which will only copy the changes. > > That would certainly be an improvement. > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: http://lists.samba.org/mailman/listinfo/samba >-- All men are frauds. The only difference between them is that some admit it. I myself deny it. -- H. L. Mencken -- All men are frauds. The only difference between them is that some admit it. I myself deny it. -- H. L. Mencken