[ale] Two offices, one data pool

[JD]

I think you'll find that file locks won't really work. You need a 
document management system with check-out/check-in methods for a number 
of reasons.

Alfresco does the check-in/check-out with a tiny amount of user 
training. You can let the end users see the files as CIFS shares, but 
force check-out/in activities to the master server. CIFS can be ugly on 
a network, however, so other access methods may be preferable.  You can 
setup clusters across both systems, but I'd avoid that for a first 
deployment. There are many scenarios where users open and edit files in 
multiple sessions and aren't always connected, so the share-level file 
locking would probably allow a few accidental overwrites.

If I were "IT", I'd want to be 100% safe and stay out of having any 
possible issues with end users overwriting each others' work. File 
locking at the share level isn't what is needed when people are editing 
documents for multiple hours or days at a time - like happens often for 
spreadsheets and wordprocessing docs.  Knowing that a file is locked by 
someone else in advance is important to keeping users happy.

OTOH, sometimes the simplest answer really is the best one.


On 02/17/2011 10:13 AM, Michael B. Trausch wrote:
> On Thu, 2011-02-17 at 07:40 -0500, Jim Kinney wrote:
>> put the data source where both offices have crappy access speed.
> Well, I had thought about putting something together, but I don't know
> how well it'd do.
>
> What I've been thinking about is some method by which the existing Samba
> infrastructure could be used in order to ensure that both sides have
> locks and such which are shared between them.  For example, if all of
> the data is stored on Amazon's S3 service, and then a VFS plugin was
> written for Samba that would provide access to the data stored on S3 as
> a shared filesystem, I thought it might be possible to use the whole
> thing in a way so as to keep the requirement that two people should not
> be able to attempt to modify the document at once.
>
> For the moment, everything's in one office.  So if someone opens a
> spreadsheet, and then someone else opens the same spreadsheet, the
> second user gets the spreadsheet in read-only mode, because the first
> person has it open and protected against writes by other people.
>
> The other bonus would be that if it's done using Samba's VFS support, it
> would look like it would be possible to support the whole Windows way of
> doing things with relative ease.  Security descriptors and all that jazz
> could be stored as metadata attached to the files, as well as things
> like file locks.
>
> The only other problem that would need to be solved would be that of
> caching; documents that are frequently accessed should be cached locally
> so that round-trips to the Internet can be deferred to an extent.  A
> method for invalidating the cache would also be required; if document X
> is in the local cache in office A, and someone in office B modifies the
> document, there should be some way for the server in office A to become
> aware of that fact and invalidate its copy of it (either fetching the
> updated copy and inserting that into its cache, or just dropping it
> entirely).
>
> I'd (briefly) considered something like DRBD, but I just can't see that
> being functional enough without a leased line being used to make things
> work well.  I've no interest in attempting to resolve issues like the
> offices falling out of sync with each other.  It has to be stupid-easy
> for people to use, and stupid-easy for me to manage.  That's really the
> goal.
>
>> Given the desktop clients they will be using most likely M$office. So
>> "shared data" means word files. To prevent clashes you need a document
>> management tool. Knowlegetree is one. Alfresco is another.
> I will look into both of those.  Do those types of systems have some
> sort of method by which Samba could expose their repositories as shared
> filesystems?
>
>> You _could_ set up a subversion repo and scripts to merge xml
>> docs ....
> Eeeeeeee, no.  bzr, maybe.  :-P
>
> But they're not all XML documents, anyway.  There is an awful lot of
> legacy binary blob document types, and even the newer XML using ones are
> wrapped up in binary files such that automatic merging would become
> problematic, I think.  One would have to have some sort of method for
> really deeply inspecting the document(s) and finding out how to easily
> diff them and all their content with the previous version.  Given the
> number of Office 2003 and earlier versions of documents that are
> present, that would be challenging at best.
>
> 	--- Mike