This is a discussion on Re: [Samba] many servers and mobile users - "always use the most - Samba ; Gautier, B (Bob) wrote: (...) >>> About a year ago I worked out an architecture in which >> rsync would be >>> used to replicate profiles from location to location (replication >>> being triggered by *logout*, not *login*) but it ...
Gautier, B (Bob) wrote:
>>> About a year ago I worked out an architecture in which
>> rsync would be
>>> used to replicate profiles from location to location (replication
>>> being triggered by *logout*, not *login*) but it never got anywhere
>>> near implementation as far as I am aware. You just have to
>> make sure
>>> you have enough bandwidth so you can move the profiles
>> faster than the
>>> people. :-) Of course rsync helps quite a bit.
>> Hmm, no, using your idea (replication triggered by logout)
>> would mean that user profile would be replicated to cities
>> A-Z, where in reality a given user works only in cities A and B.
> If you are sure the user never actually visits C-Z you can maybe ensure
> you can configure the replication to avoid doing those copies. The
> assumption is that it's low overhead anyway.
It would be a nightmare to manage if you have more than 5 users and
don't really know where they work.
>> Theoretically, it should be easy to do (I assume we're using LDAP):
>> 1) user begins logon
>> 2) some program or a script compares local (branch) and
>> remote (central) NTUSER.DAT - and picks the newest
>> 3) "sambaProfilePath:" is set according to the newest
>> NTUSER.DAT location, ie.
>> a) no "sambaProfilePath:" entry in LDAP, if the local
>> NTUSER.DAT is the newest
>> b) "sambaProfilePath: \\remote\profiles" if the remote
>> NTUSER.DAT is the newest
>> 4) on logout the profile should be saved locally (and perhaps
>> at night, or at some interval, transferred to the central server)
>> Of course setting "sambaProfilePath:" value according to some script
>> exit value or output is the tricky part
> This all sounds more or less feasible but any work you do at logon time
> is (as you pointed out) very time-limited.
Hey, not really.
It's perfectly fine to load a profile for 10 minutes from a remote
server - as long as something happens (the files are being transferred),
it's OK for a Windows workstation.
> I'd also worry about LDAP replication time-lag: you probably can't
> update sambaProfilePath during the logon and expect to see the change
> within the time available.
I wouldn't want to replicate anything.
I'd just fake "sambaProfilePath:" to point to the server containing the
> How about setting sambaProfilePath for a user at logout time, based on
> the location they are logging off from? And updating it if you get
> around to replicating the profile to a central site before they logon
Only half of it is fine. We have two things:
1) user should download the profile from the server with the newest
profile (either local or a remote one)
2) user should upload the profile to the local server *only*
So, it will work only if we can change the "sambaProfilePath:" value to
the local one after user logs in - which is not a problem, but I'm not
sure if the Windows client will respect that (which I'm going to find
> The less work you do at logon time the better, IMHO.
To unsubscribe from this list go to the following URL and read the