RE: [Samba] Real-time file synchronisation
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:[EMAIL PROTECTED] Sent: Friday, 1 October 2004 5:01 AM To: Chris Ricks Cc: [EMAIL PROTECTED] 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 -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
RE: [Samba] Real-time file synchronisation
Hi Simon, My responses are interleaved with your questions. > -Original Message- > From: Simon Hobson [mailto:[EMAIL PROTECTED] > Sent: Friday, 1 October 2004 1:12 AM > To: Chris Ricks; [EMAIL PROTECTED] > Subject: Re: [Samba] Real-time file synchronisation > > Chris Ricks wrote: > >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! > > 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! :-) > > 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. "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. > > 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... > > 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. > > 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... > > 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 -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
RE: [Samba] Real-time file synchronisation
> -Original Message- > From: Paul Gienger [mailto:[EMAIL PROTECTED] > Sent: Friday, 1 October 2004 1:23 AM > To: Chris Ricks > Cc: [EMAIL PROTECTED] > Subject: Re: [Samba] Real-time file synchronisation > > > >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. > > 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). > 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 > > -- > Paul Gienger Office: 701-281-1884 > Applied Engineering Inc. > Information Systems Consultant Fax:701-281-1322 > URL: www.ae-solutions.commailto: [EMAIL PROTECTED] > > > > - > 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 -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
RE: [Samba] Real-time file synchronisation
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:[EMAIL PROTECTED] Sent: Friday, 1 October 2004 1:08 AM To: Chris Ricks Cc: [EMAIL PROTECTED] Subject: Re: [Samba] Real-time file synchronisation >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.commailto: [EMAIL PROTECTED] - 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. -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
[Samba] Real-time file synchronisation
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 -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
