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
newest profile.

> 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
> again?

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
out now).

> The less work you do at logon time the better, IMHO.


Tomasz Chmielewski
To unsubscribe from this list go to the following URL and read the