Discussion:
[Samba] Real-time file synchronisation
Chris Ricks
2004-09-30 19:51:15 UTC
Permalink
Hi all!

I'm looking for a method of doing the following, given that I'm taking care
of a network with a Samba 3.0.6 box (running Mandrake 10.0) acting as a PDC
for about 15 W2K boxes:

. There is a share full of program files and data files on the Samba box
. These files are currently synchronized at logon - all movement is from the
server to the clients via a logon script using XCOPY /D

I want to engineer a solution that would allow updates of the share to have
changes propagated out to clients as the share is updated without the users
being made aware. Essentially, the software vendor is demanding that
everyone run their software from the network share as to ensure consistency,
but I hardly think a 300 MB application with 15 MB (!!) executables (about 8
of them) is really suitable for being "deployed" in that fashion.

All comments appreciated!

Best regards,

Chris
Paul Gienger
2004-09-30 20:09:23 UTC
Permalink
Post by Chris Ricks
everyone run their software from the network share as to ensure consistency,
but I hardly think a 300 MB application with 15 MB (!!) executables (about 8
of them) is really suitable for being "deployed" in that fashion.
Try a 1.1GB app with the main executable being 131MB and run by 60+
users at once. That really is the best way to run this particular app
(Pro/Engineer) as that way the config files all point to the same
license server and other important file paths. If you ever have to run
around and fix it you either change it once and it just works or you
change it, script a push to all the clients, and then run around fixing
the ones that didn't work for some reason, which assumes the users have
permission to replace system executables. I'll pick the network option
personally.
--
Paul Gienger Office: 701-281-1884
Applied Engineering Inc.
Information Systems Consultant Fax: 701-281-1322
URL: www.ae-solutions.com mailto: ***@ae-solutions.com



-----------------------------------------
The information contained in this message is privileged and intended only for the recipient names. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.
Simon Hobson
2004-09-30 20:10:37 UTC
Permalink
Post by Chris Ricks
Hi all!
I'm looking for a method of doing the following, given that I'm taking care
of a network with a Samba 3.0.6 box (running Mandrake 10.0) acting as a PDC
. There is a share full of program files and data files on the Samba box
. These files are currently synchronized at logon - all movement is from the
server to the clients via a logon script using XCOPY /D
I want to engineer a solution that would allow updates of the share to have
changes propagated out to clients as the share is updated without the users
being made aware. Essentially, the software vendor is demanding that
everyone run their software from the network share as to ensure consistency,
but I hardly think a 300 MB application with 15 MB (!!) executables (about 8
of them) is really suitable for being "deployed" in that fashion.
All comments appreciated!
I would say that your vendor is being unreasonable, and that you are
correct to want to run these locally.

A few questions to think about :

How often do you update the application ? If it's only every few
months, then there's no problem.

Do you ever do it while users are working ? Well you shouldn't be !
And what does the vendor propose to do about the problem of changing
a binary whilst it is in use ? Having said that, I have done in-place
upgrades on Unix systems by MOVING the original file and slipping the
new one into place - if it's in use then the system will continue to
use the old file (referenced by inode no, not file name) until it is
closed.

Do you have (or do you ever expect to have, any remote workers ? If
so then there is no way (even on Broadband/ADSL) that you want users
sucking that sort of file size down the pipe.

One way of dealing with the issue is to make all the users log out
and back in again when you upgrade. Another might be to run a
scheduled task that periodically does an XCOPY, but then you'll run
into problems of the program crashing when you change the binary
running (or more likely a file in use error).

Simon
--
Simon Hobson MA MIEE, Technology Specialist
Colony Gift Corporation Limited
Lindal in Furness, Ulverston, Cumbria, LA12 0LD
Tel 01229 461100, Fax 01229 461101

Registered in England No. 1499611
Regd. Office : 100 New Bridge Street, London, EC4V 6JA.
Chris Ricks
2004-09-30 20:15:15 UTC
Permalink
I'm intrigued! What sort of config are you running on your Samba box(es)
(I'm assuming it's served from a Samba box) to support that app?

I'm also curious as to the start-up times you experience compared to locally
installed copies.

I'm not trying to challenge what you've said at all - I'm genuinely
interested in how things perform in your particular situation (given that
the performance in this situation is absolutely shocking when the dopey
thing is run from a share).

Best regards,

Chris

-----Original Message-----
From: Paul Gienger [mailto:***@ae-solutions.com]
Sent: Friday, 1 October 2004 1:08 AM
To: Chris Ricks
Cc: ***@lists.samba.org
Subject: Re: [Samba] Real-time file synchronisation
Post by Chris Ricks
everyone run their software from the network share as to ensure
consistency,
Post by Chris Ricks
but I hardly think a 300 MB application with 15 MB (!!) executables (about
8
Post by Chris Ricks
of them) is really suitable for being "deployed" in that fashion.
Try a 1.1GB app with the main executable being 131MB and run by 60+
users at once. That really is the best way to run this particular app
(Pro/Engineer) as that way the config files all point to the same
license server and other important file paths. If you ever have to run
around and fix it you either change it once and it just works or you
change it, script a push to all the clients, and then run around fixing
the ones that didn't work for some reason, which assumes the users have
permission to replace system executables. I'll pick the network option
personally.
--
Paul Gienger Office: 701-281-1884
Applied Engineering Inc.
Information Systems Consultant Fax: 701-281-1322
URL: www.ae-solutions.com mailto: ***@ae-solutions.com



-----------------------------------------
The information contained in this message is privileged and intended only
for the recipient names. If the reader is not a representative of the
intended recipient, any review, dissemination or copying of this message or
the information it contains is prohibited. If you have received this message
in error, please immediately notify the sender, and delete the original
message and attachments.
Paul Gienger
2004-09-30 20:25:29 UTC
Permalink
Post by Chris Ricks
I'm intrigued! What sort of config are you running on your Samba box(es)
(I'm assuming it's served from a Samba box) to support that app?
Nothing too special for hardware or config files, I don't have real hard
speed numbers on the big installation since that's at a customer's site
and it's not my baby to support them, but they were running on a Quad
cpu E450, now it's a v240 I believe, gigabit network and a decent disk
array. We run a smaller config in our office that is an old Ultra 2
with a really slow disk array but we run only 6 or so users at once.
Oh, sorry, those are all Sun boxes if you didn't know by the numbers.
I've run it off various other things but never for more than a couple of
users. By far the biggest installs *I've* run into are at this client's
site and they don't seem to mind.

This app doesn't run any database or anything, so if you're doing that
then you could be looking at some issues.

I'll check the load up times when I get back into the office. The app
is generally a big hog so the users don't ever complain. I've seen it
use nearly a gig of ram before so you know it's piggy.
--
Paul Gienger Office: 701-281-1884
Applied Engineering Inc.
Information Systems Consultant Fax: 701-281-1322
URL: www.ae-solutions.com mailto: ***@ae-solutions.com



-----------------------------------------
The information contained in this message is privileged and intended only for the recipient names. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.
Jim C.
2004-09-30 20:24:53 UTC
Permalink
Post by Chris Ricks
I'm looking for a method of doing the following, given that I'm taking care
...
Post by Chris Ricks
but I hardly think a 300 MB application with 15 MB (!!) executables (about 8
of them) is really suitable for being "deployed" in that fashion.
rsync is available on both platforms and could be scripted in a bat
script.

Why don't you just set up an application share? I run OpenOffice and MS
Office from a share that I have mapped to network drives on the clients.

Also, I think if you place the files in a directory on the Linux box and
then put links from each user directory to the application directory,
you can even avoid mapping drives. Perms/Ownership might get tricky
though. Should be safe, despite certain Samba bugs, since the link is
from the user's directory to an outside directory rather than vice versa.

Real time synchronization might be a good idea for a VFS module. One
might even use something like that to get around having to set up
re-directed folders etc. Could be a nice way to fool Windows into
functioning a little more like NFS with less setup on the client side.
--
-----------------------------------------------------------------
| I can be reached on the following Instant Messenger services: |
|---------------------------------------------------------------|
| MSN: ***@hotmail.com AIM: WyteLi0n ICQ: 123291844 |
|---------------------------------------------------------------|
| Y!: j_c_llings Jabber: ***@njs.netlab.cz |
-----------------------------------------------------------------
Chris Ricks
2004-09-30 20:32:02 UTC
Permalink
Post by Chris Ricks
-----Original Message-----
Sent: Friday, 1 October 2004 1:23 AM
To: Chris Ricks
Subject: Re: [Samba] Real-time file synchronisation
Post by Chris Ricks
I'm intrigued! What sort of config are you running on your Samba box(es)
(I'm assuming it's served from a Samba box) to support that app?
Nothing too special for hardware or config files, I don't have real hard
speed numbers on the big installation since that's at a customer's site
and it's not my baby to support them, but they were running on a Quad
cpu E450, now it's a v240 I believe, gigabit network and a decent disk
array. We run a smaller config in our office that is an old Ultra 2
with a really slow disk array but we run only 6 or so users at once.
Oh, sorry, those are all Sun boxes if you didn't know by the numbers.
I've run it off various other things but never for more than a couple of
users. By far the biggest installs *I've* run into are at this client's
site and they don't seem to mind.
Admittedly, this place has a sub-optimal network setup; the Samba box and DB
server are plugged into one switch, which has the uplink port from another
switch plugged into it. This second switch has workstations plugged into it
and a cable running from (you guessed it) the uplink port of yet another
switch that services workstations - all connections are 100 Mb.
Post by Chris Ricks
This app doesn't run any database or anything, so if you're doing that
then you could be looking at some issues.
There is a DB server in place, which is one reason I'd prefer to keep the
network traffic low as to not tie the DB server up waiting to send result
sets down the wire. The app does a lot of processing on both the client and
server side, and neither side massively efficient (hint: the DB server and
client-side libraries both come from www.guptaworldwide.com).
Post by Chris Ricks
I'll check the load up times when I get back into the office. The app
is generally a big hog so the users don't ever complain. I've seen it
use nearly a gig of ram before so you know it's piggy.
Sounds like an excellent testimonial to hit clients with that are
considering going with some weird MS server product....
Post by Chris Ricks
--
Paul Gienger Office: 701-281-1884
Applied Engineering Inc.
Information Systems Consultant Fax: 701-281-1322
-----------------------------------------
The information contained in this message is privileged and intended only
for the recipient names. If the reader is not a representative of the
intended recipient, any review, dissemination or copying of this message
or the information it contains is prohibited. If you have received this
message in error, please immediately notify the sender, and delete the
original message and attachments.
Best regards,

Chris
Chris Ricks
2004-09-30 20:35:52 UTC
Permalink
Hi Simon,

My responses are interleaved with your questions.
Post by Chris Ricks
-----Original Message-----
Sent: Friday, 1 October 2004 1:12 AM
Subject: Re: [Samba] Real-time file synchronisation
Post by Chris Ricks
Hi all!
I'm looking for a method of doing the following, given that I'm taking
care
Post by Chris Ricks
of a network with a Samba 3.0.6 box (running Mandrake 10.0) acting as a
PDC
Post by Chris Ricks
. There is a share full of program files and data files on the Samba box
. These files are currently synchronized at logon - all movement is from
the
Post by Chris Ricks
server to the clients via a logon script using XCOPY /D
I want to engineer a solution that would allow updates of the share to
have
Post by Chris Ricks
changes propagated out to clients as the share is updated without the
users
Post by Chris Ricks
being made aware. Essentially, the software vendor is demanding that
everyone run their software from the network share as to ensure
consistency,
Post by Chris Ricks
but I hardly think a 300 MB application with 15 MB (!!) executables
(about 8
Post by Chris Ricks
of them) is really suitable for being "deployed" in that fashion.
All comments appreciated!
I would say that your vendor is being unreasonable, and that you are
correct to want to run these locally.
Funny that - last time I checked, Windows doesn't actually fit with the idea
of thin-client style computing at all! :-)
Post by Chris Ricks
How often do you update the application ? If it's only every few
months, then there's no problem.
"Updates" are done every now and then, but very rarely for binaries. Most
updates take the form of replacing report files (of the order of 100KB).
This sort of update happens every few months.
Post by Chris Ricks
Do you ever do it while users are working ? Well you shouldn't be !
And what does the vendor propose to do about the problem of changing
a binary whilst it is in use ? Having said that, I have done in-place
upgrades on Unix systems by MOVING the original file and slipping the
new one into place - if it's in use then the system will continue to
use the old file (referenced by inode no, not file name) until it is
closed.
An excellent point. They often do such things whilst people are working. If
I recall correctly, Windows' VM model does not horde executable data in swap
space (which is why compressed executables stay compressed or something -
I'd have to look at UPX's docs). Considering it's Windows, I don't like the
idea of trying to move such things around, even if Windows should lock
running executables.


Further, do you know offhand if the trick you use above carries across the
UNIX-Windows divide that Samba takes care of? I know that Samba will use FDs
to reference things, but SMB is a complicated protocol...
Post by Chris Ricks
Do you have (or do you ever expect to have, any remote workers ? If
so then there is no way (even on Broadband/ADSL) that you want users
sucking that sort of file size down the pipe.
We do have remote workers, and they run the app locally with only queries
and result sets traversing the wire. That said, rsync makes short work of
that problem for keeping remote installs in sync.
Post by Chris Ricks
One way of dealing with the issue is to make all the users log out
and back in again when you upgrade. Another might be to run a
scheduled task that periodically does an XCOPY, but then you'll run
into problems of the program crashing when you change the binary
running (or more likely a file in use error).
I was thinking of using dnotify / FAM and a conditional script. Most of the
DLLs will never change, the same for the executables. How Gupta's products
handle .QRP files changing underfoot will be interesting...
Post by Chris Ricks
Simon
--
Simon Hobson MA MIEE, Technology Specialist
Colony Gift Corporation Limited
Lindal in Furness, Ulverston, Cumbria, LA12 0LD
Tel 01229 461100, Fax 01229 461101
Registered in England No. 1499611
Regd. Office : 100 New Bridge Street, London, EC4V 6JA.
Best regards,

Chris
Simon Hobson
2004-09-30 20:44:49 UTC
Permalink
Post by Chris Ricks
Post by Simon Hobson
How often do you update the application ? If it's only every few
months, then there's no problem.
"Updates" are done every now and then, but very rarely for binaries. Most
updates take the form of replacing report files (of the order of 100KB).
This sort of update happens every few months.
Then I find it hard to see any problem at all.
Post by Chris Ricks
Post by Simon Hobson
Do you ever do it while users are working ? Well you shouldn't be !
And what does the vendor propose to do about the problem of changing
a binary whilst it is in use ? Having said that, I have done in-place
upgrades on Unix systems by MOVING the original file and slipping the
new one into place - if it's in use then the system will continue to
use the old file (referenced by inode no, not file name) until it is
closed.
An excellent point. They often do such things whilst people are working. If
I recall correctly, Windows' VM model does not horde executable data in swap
space (which is why compressed executables stay compressed or something -
I'd have to look at UPX's docs). Considering it's Windows, I don't like the
idea of trying to move such things around, even if Windows should lock
running executables.
Further, do you know offhand if the trick you use above carries across the
UNIX-Windows divide that Samba takes care of? I know that Samba will use FDs
to reference things, but SMB is a complicated protocol...
In principal, but I know Samba has it's own locking mechanism and I
don't know if that works by file name or file id - hopefully one of
the people with knowledge of the internal could answer that one.

As long as the Samba locking uses inodes and not filenames, then I
see no reason it shouldn't work.

Simon
--
Simon Hobson MA MIEE, Technology Specialist
Colony Gift Corporation Limited
Lindal in Furness, Ulverston, Cumbria, LA12 0LD
Tel 01229 461100, Fax 01229 461101

Registered in England No. 1499611
Regd. Office : 100 New Bridge Street, London, EC4V 6JA.
Mike Fedyk
2004-10-02 02:06:53 UTC
Permalink
Post by Simon Hobson
Post by Chris Ricks
Post by Simon Hobson
And what does the vendor propose to do about the problem of changing
a binary whilst it is in use ? Having said that, I have done in-place
upgrades on Unix systems by MOVING the original file and slipping the
new one into place - if it's in use then the system will continue to
use the old file (referenced by inode no, not file name) until it is
closed.
An excellent point. They often do such things whilst people are working. If
I recall correctly, Windows' VM model does not horde executable data in swap
space (which is why compressed executables stay compressed or
something -
I'd have to look at UPX's docs). Considering it's Windows, I don't like the
idea of trying to move such things around, even if Windows should lock
running executables.
Further, do you know offhand if the trick you use above carries across the
UNIX-Windows divide that Samba takes care of? I know that Samba will use FDs
to reference things, but SMB is a complicated protocol...
In principal, but I know Samba has it's own locking mechanism and I
don't know if that works by file name or file id - hopefully one of
the people with knowledge of the internal could answer that one.
As long as the Samba locking uses inodes and not filenames, then I see
no reason it shouldn't work.
I don't know the exact semantics, but samba allows you to change shares
by modifying the config file and sending a HUP signal to the smbd
processes -- or just waiting for it to check the config files during
operation.

My idea is to run an access file from a samba server. The data is kept
on a sql server, so just reports and forms will be in the access file.

o have tow directories share-a and share-b
o smb.conf points to share-a
o change the files in share-b
o change the smb.conf file to point to share-b

I know that at least on logout the user will get the update, and IIRC
when all files are unlocked on the server, or for that share.

Can someone comment on whether this is a implementation quirk that
should not be depended upon on the 3.0.x samba series?

Thanks,

Mike

Umberto Zanatta
2004-10-01 00:07:56 UTC
Permalink
I've read all answers, but you should do it by distribuited file
systems.

You should try AFS; it's easy to install and works well.

uz.
Post by Chris Ricks
Hi all!
I'm looking for a method of doing the following, given that I'm taking care
of a network with a Samba 3.0.6 box (running Mandrake 10.0) acting as a PDC
. There is a share full of program files and data files on the Samba box
. These files are currently synchronized at logon - all movement is from the
server to the clients via a logon script using XCOPY /D
I want to engineer a solution that would allow updates of the share to have
changes propagated out to clients as the share is updated without the users
being made aware. Essentially, the software vendor is demanding that
everyone run their software from the network share as to ensure consistency,
but I hardly think a 300 MB application with 15 MB (!!) executables (about 8
of them) is really suitable for being "deployed" in that fashion.
All comments appreciated!
Best regards,
Chris
Gustavo Lima
2004-10-01 01:06:06 UTC
Permalink
Greetings,

I was able to admin users and machines database via usrmgr.exe in a
samba3.0.7 + ldap server. I was able to set trusting domains too.

After I vampired my ex-PDC NT server usrmgr.exe stop working and trusting
stop to be showed.

usrmgr.exe gives the error:

The tag is invalid. Do you want to select another domain to administer?

And net rpc trustdom list -UAdministrator%passwd gives me:

Trusted domains list:

OTHER-DOM S-1-5-21-136393487-307246644-928725530

Trusting domains list:

[2004/09/30 16:44:16, 0] utils/net_rpc.c:rpc_trustdom_list(3430)
Couldn't enumerate accounts. Error was: NT_STATUS_ACCESS_DENIED

Is this a known error between samba and ldap?

Other tools that I use to administer the users database also can?t show all
imported users. Just about 500. Is this correct?

Any answers will be grate.

Gustavo
Craig White
2004-10-01 02:13:46 UTC
Permalink
Post by Gustavo Lima
Greetings,
I was able to admin users and machines database via usrmgr.exe in a
samba3.0.7 + ldap server. I was able to set trusting domains too.
After I vampired my ex-PDC NT server usrmgr.exe stop working and trusting
stop to be showed.
The tag is invalid. Do you want to select another domain to administer?
----
I have found the following - If you migrate a domain to samba, promote
samba to PDC status, the existing NT4 machine that was the PDC/BDC
doesn't work well and in fact, you have to stop netlogon service to use
it at all. Yours was the type of error I received when running
usrmgr.exe on that machine until I stopped netlogon service.

It is also possible that on your LDAP setup, the machine accounts aren't
being found by samba/LDAP.

User Manager for Domains (usrmgr.exe) does work if you are running it on
a computer attached to the domain and current logon has Domain
Administrator privileges. If it fails to run, one or both of these
issues need to be looked at.
----
Post by Gustavo Lima
OTHER-DOM S-1-5-21-136393487-307246644-928725530
[2004/09/30 16:44:16, 0] utils/net_rpc.c:rpc_trustdom_list(3430)
Couldn't enumerate accounts. Error was: NT_STATUS_ACCESS_DENIED
----
almost sounds like samba is having trouble querying LDAP.
----
Post by Gustavo Lima
Is this a known error between samba and ldap?
----
NO - things can work well when they work
----
Post by Gustavo Lima
Other tools that I use to administer the users database also can?t show all
imported users. Just about 500. Is this correct?
-----
don't know what tools you are talking about but
getent passwd
should give you all of the listings in /etc/passwd first, then all of
the contents in LDAP (similar results for getent group) It is possible
that you can have limits on a return from ldap query but that is beyond
the scope of samba list.

Craig
Gustavo Lima
2004-10-01 02:18:47 UTC
Permalink
The solution was to add a parameter to ldap server.

sizelimit 4000

Everything works fine now.

Thank?s.

Gustavo
Chris Ricks
2004-10-01 04:53:30 UTC
Permalink
Hmm.I can appreciate that AFS is an excellent technology, but I'm a bit
confused as to you suggesting it, given that we're dealing with Windows
boxes on the client side. Could you point me to some info that gives an
example of the solution you're recommending?


Best regards,



Chris



_____

From: Umberto Zanatta [mailto:***@provincia.treviso.it]
Sent: Friday, 1 October 2004 5:01 AM
To: Chris Ricks
Cc: ***@lists.samba.org
Subject: Re: [Samba] Real-time file synchronisation



I've read all answers, but you should do it by distribuited file systems.

You should try AFS; it's easy to install and works well.

uz.

Il giorno ven, 01-10-2004 alle 00:50 +1000, Chris Ricks ha scritto:


Hi all!

I'm looking for a method of doing the following, given that I'm taking care
of a network with a Samba 3.0.6 box (running Mandrake 10.0) acting as a PDC
for about 15 W2K boxes:

. There is a share full of program files and data files on the Samba box
. These files are currently synchronized at logon - all movement is from the
server to the clients via a logon script using XCOPY /D

I want to engineer a solution that would allow updates of the share to have
changes propagated out to clients as the share is updated without the users
being made aware. Essentially, the software vendor is demanding that
everyone run their software from the network share as to ensure consistency,
but I hardly think a 300 MB application with 15 MB (!!) executables (about 8
of them) is really suitable for being "deployed" in that fashion.

All comments appreciated!

Best regards,

Chris
Umberto Zanatta
2004-10-01 14:29:00 UTC
Permalink
I've never tried AFS just CODA filesystem (for fun) some year ago; CODA
worked fine (it was a little bit instable; Linux Server + a few Linux
clients)

AFS is more stable than CODA; last month I read some interesting
articles about AFS; they were written on Italian magazine that does
about
Linux (Linux & C).

In AFS (www.openafs.org) there's a windows port; you'll try and don't
care... remember: AFS must be works up kerberos.

Regards,
Hmm?I can appreciate that AFS is an excellent technology, but I?m a
bit confused as to you suggesting it, given that we?re dealing with
Windows boxes on the client side. Could you point me to some info that
gives an example of the solution you?re recommending?
Best regards,
Chris
______________________________________________________________________
Sent: Friday, 1 October 2004 5:01 AM
To: Chris Ricks
Subject: Re: [Samba] Real-time file synchronisation
I've read all answers, but you should do it by distribuited file systems.
You should try AFS; it's easy to install and works well.
uz.
Hi all!
I'm looking for a method of doing the following, given that I'm taking care
of a network with a Samba 3.0.6 box (running Mandrake 10.0) acting as a PDC
. There is a share full of program files and data files on the Samba box
. These files are currently synchronized at logon - all movement is from the
server to the clients via a logon script using XCOPY /D
I want to engineer a solution that would allow updates of the share to have
changes propagated out to clients as the share is updated without the users
being made aware. Essentially, the software vendor is demanding that
everyone run their software from the network share as to ensure consistency,
but I hardly think a 300 MB application with 15 MB (!!) executables (about 8
of them) is really suitable for being "deployed" in that fashion.
All comments appreciated!
Best regards,
Chris
_______________________
Umberto Zanatta
linuxDidattica

tel: +39 (335) 54 71 385
email: ***@tin.it
web: http://linuxdidattica.org
_______________________
Thomas E. Keiser
2004-10-01 10:31:05 UTC
Permalink
The OpenAFS windows client has finally gotten stable in the past year.
My department here uses the AFS client on windows rather extensively. I
experimented a while ago with software distribution of a large windows
application (Pro/Engineer) over AFS with pretty good results. So, you get
the same local caching benefits that unix clients get for software
distribution. Another major benefit is that cache invalidation only
happens when you release a new version to the read-only replicas. Plus,
clients automatically load-balance across all fileservers containing the
read-only volume replicas they're looking for.

Regards,

Tom Keiser
Post by Chris Ricks
Hmm.I can appreciate that AFS is an excellent technology, but I'm a bit
confused as to you suggesting it, given that we're dealing with Windows
boxes on the client side. Could you point me to some info that gives an
example of the solution you're recommending?
Best regards,
Chris
_____
Sent: Friday, 1 October 2004 5:01 AM
To: Chris Ricks
Subject: Re: [Samba] Real-time file synchronisation
I've read all answers, but you should do it by distribuited file systems.
You should try AFS; it's easy to install and works well.
uz.
Hi all!
I'm looking for a method of doing the following, given that I'm taking care
of a network with a Samba 3.0.6 box (running Mandrake 10.0) acting as a PDC
. There is a share full of program files and data files on the Samba box
. These files are currently synchronized at logon - all movement is from the
server to the clients via a logon script using XCOPY /D
I want to engineer a solution that would allow updates of the share to have
changes propagated out to clients as the share is updated without the users
being made aware. Essentially, the software vendor is demanding that
everyone run their software from the network share as to ensure consistency,
but I hardly think a 300 MB application with 15 MB (!!) executables (about 8
of them) is really suitable for being "deployed" in that fashion.
All comments appreciated!
Best regards,
Chris
--
To unsubscribe from this list go to the following URL and read the
instructions: http://lists.samba.org/mailman/listinfo/samba
Loading...