On 12/7/05, Denis Croombs denis@croombs.org wrote:
On 12/6/05, Jonathan Darton jdarton@ibigroup.com wrote:
I want to build 2 servers (both running samba) to provide file storage to 2 offices (approx 100 miles apart, linked via DSL) but all data writen to 1 server must also be saved to the other server. Both servers would also allow users to access the data via a VPN thus allowing 1 office with a failed server to access the other server via the vpn and still see the data from both offices. I currently have 1 server working but we want to add the second office to the system. (Currently 1 office has 10 users and the second office has 1 user connected via VPN ) but the second office will have 20 within 12
months
and the first will have 35 soon ))
Has anyone done anything like this ?
I am currently synchronizing multiple office locations using a program called unison. Unison (http://www.cis.upenn.edu/~bcpierce/unison/) is a very well written program that can perform 2 way file synchronization. There are many configurable options with unison and I
recommend that you check it out.
In each office I have a PII350 128RAM Fedora or CentOS server running unison and the files are accessed via samba. I also configure samba to hide (veto) all of the temporary files used during synchronization. For redundancy I place a slave server with each master server that backs up all the user data / file system using rsync. This way if one of my $5 PII servers catches fire I can automatically switch over with
no
downtime for the users.
The only downfall I have encountered is with Autocad files not properly reading the synchronized .dwl lock file and more than one user working on the same file. As a work around for this I have configured Unison to keep a backup of the last 20 versions of a file. This way I can always hit my backups to retreive lost data. As a side note, if anyone knows a work around for the stubborn autocad dwl lock
file let me know :))!
In any case my implementation has allowed me to synchronize file systems between 4 offices (3 in Canada, 1 in USA), using recycled hardware that was otherwise going to be donated/trashed.
Let me know if you have any further questions.
I'm about to do a Unison setup on two CentOS servers, so I'm thrilled to
see this response. I also work with Architects >>sometimes, so I'm interested to hear about the dwl lock file issue.
My one compound question: how are you invoking Unison? In batch mode,
with
cron? How often? Wat other options did you
consider before settling on the scheme you use?
I see the project is no longer supported, do you have rpms for it ?
Thanks
It's not that it's no longer supported, really, just that the project that initiated it is not an officially-funded academic project. It has actually been updated since the termination of the project, it looks like.
I haven't installed it on CentOS yet but I got FC4 rpms from fedora extras (I just typed 'yum install unison' and it worked). I think it's in pretty common usage in RHEL too, so it can't be too hard to find for CentOS, right? (But let us know what you turn up :-)).
I created a script that is run by cron every minute. The script creates a lock file for the session, rsyncs the changes to the backup server, synchronizes offices using unison, deletes the lock file. Unison is executed in "batch" and "silent" mode so that no output is generated and mailed by cron. One other thing you need to consider is the size of the file system you are trying to synchronize. I have a very large directory structure in two offices which required running unison a second time splitting up the synchronization into two sessions. This can easily be done by ignoring a certain path/paths and then synchronizing them in the next session. If you are thinking of synchronizing between more than 2 locations, you need to plan the fastest route (ie. A<->B<->C or B<->A<->C). I have had no problems synchronizing between more than two locations.
For all of my implementations using Fedora or CentOS operating systems I have downloaded the unison source, installed the ocaml compiler (easy to find for centos/fedora use google) and compiled from source. I have never had a problem.
Another benefit to the implementation that I have been using is the fact that employees in each office can work on files on the server as long as the internal network is functioning, regardless if the synchronization link / externel connection is working. The synchronization is basically transparent to the user, and if it happens to go down it will pick up where it left off as soon as it can regain a connection.
Let me know if you require any further information.
A. Jonathan Darton, B.COMM CIS System Consultant
Jonathan Darton wrote:
to the user, and if it happens to go down it will pick up where it left off as soon as it can regain a connection.
Let me know if you require any further information.
A. Jonathan Darton, B.COMM CIS System Consultant
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I apologize if this counts as thread hijack, but I have a couple of questions about Unison.
I use rsync to synchronize 4 locations, but I fillow the master/slave route, i.e directories are synchronized only one way, each server holding the master copy of it's data and read-only copies of the other server's data. I would have preferred to use unison for proper synchronization but i need to copy ACLs as well and as I understand this is not possible. Am I wrong about this?
On 12/8/05, Yiorgos Stamoulis yiorgos-lists@272deg.homelinux.net wrote:
Jonathan Darton wrote:
to the user, and if it happens to go down it will pick up where it left off as soon as it can regain a connection.
Let me know if you require any further information.
A. Jonathan Darton, B.COMM CIS System Consultant
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I apologize if this counts as thread hijack, but I have a couple of questions about Unison.
I use rsync to synchronize 4 locations, but I fillow the master/slave route, i.e directories are synchronized only one way, each server holding the master copy of it's data and read-only copies of the other server's data. I would have preferred to use unison for proper synchronization but i need to copy ACLs as well and as I understand this is not possible. Am I wrong about this?
There are options for transferring ownership and perms (-owner and -perms), although I admit I haven't tried them. If they don't work right, but you know how things are supposed to look, you can always run chmod & chown afterward.
On 12/9/05, Matt Morgan minxmertzmomo@gmail.com wrote: [SNIP]
I apologize if this counts as thread hijack, but I have a couple of questions about Unison.
I use rsync to synchronize 4 locations, but I fillow the master/slave route, i.e directories are synchronized only one way, each server holding the master copy of it's data and read-only copies of the other server's data. I would have preferred to use unison for proper synchronization but i need to copy ACLs as well and as I understand this is not possible. Am I wrong about this?
There are options for transferring ownership and perms (-owner and -perms), although I admit I haven't tried them. If they don't work right, but you know how things are supposed to look, you can always run chmod & chown afterward.
rsync also has time tags and you can use them to determine if the file on download side is newere and hence excluded from sync. We do it this way and keep all data as fully functional on three locations.
Some one on another list pointed out tsync but have not had the time to llok it up and test it. No idea about unison, will also put it on list of things to do! Thanks. -- Sudev Barar Learning Linux
There are options for transferring ownership and perms (-owner and -perms), although I admit I haven't tried them. If they don't work right, but you know how things are supposed to look, you can always run chmod & chown afterward.
getfacl can dump an entire tree's permissions to a file -- both UNIX and Extended Attributes (EA) Access Control Lists (ACLs). You could then rsync that file, and run it on the other side. In fact, that's how I deal with the fact I don't want another system login in to SSH as root.
Basically: cd /wherever syncstamp="`date +%Y%m%d%H%M%S`" getfacl -R . > .facl_${syncstamp} rsync -ave "ssh" . reguser@otherserver rm .facl_${syncstamp}
And then a root cronjob on another server basically looks for .facl_* files periodically and runs: cd /whereever set -o noglob for ifacl in .facl_*; do setfacl --restore=${ifacl} rm ${ifacl} done
In fact, since Red Hat insists on not supporting XFS with its xfsdump that maintains EAs, and Ext3's dump does nothing of the sort (and I'm not a huge fan of star), I use getfacl to store the original ACLs with my backup in a file included with the backup.
On Thu, 8 Dec 2005 at 7:19pm, Bryan J. Smith wrote
In fact, since Red Hat insists on not supporting XFS with its xfsdump that maintains EAs, and Ext3's dump does nothing of the sort (and I'm not a huge fan of star), I use getfacl to store the original ACLs with my backup in a file included with the backup.
ext3 dump does EAs now:
https://rhn.redhat.com/errata/RHBA-2005-359.html
Of course, ext3 dump is not, IMO, anywhere near the quality of xfsdump (and ditto your comments on star), but RH now *can* claim full backup support of ext3.
On Fri, 2005-12-09 at 05:10 -0500, Joshua Baker-LePain wrote:
ext3 dump does EAs now: https://rhn.redhat.com/errata/RHBA-2005-359.html Of course, ext3 dump is not, IMO, anywhere near the quality of xfsdump (and ditto your comments on star), but RH now *can* claim full backup support of ext3.
Oh, thanx for correcting my ignorance there.
On Fri, 2005-12-09 at 04:10, Joshua Baker-LePain wrote:
On Thu, 8 Dec 2005 at 7:19pm, Bryan J. Smith wrote
In fact, since Red Hat insists on not supporting XFS with its xfsdump that maintains EAs, and Ext3's dump does nothing of the sort (and I'm not a huge fan of star), I use getfacl to store the original ACLs with my backup in a file included with the backup.
ext3 dump does EAs now:
https://rhn.redhat.com/errata/RHBA-2005-359.html
Of course, ext3 dump is not, IMO, anywhere near the quality of xfsdump (and ditto your comments on star), but RH now *can* claim full backup support of ext3.
The star version included in RH & Centos is years out of date. Has anyone used the current version? Are the EA's used by selinux really posix attributes and does star duplicate them if you back up ext3 and restore to xfs?
Bryan J. Smith wrote:
getfacl can dump an entire tree's permissions to a file -- both UNIX and Extended Attributes (EA) Access Control Lists (ACLs). You could then rsync that file, and run it on the other side. In fact, that's how I deal with the fact I don't want another system login in to SSH as root.
Basically: cd /wherever syncstamp="`date +%Y%m%d%H%M%S`" getfacl -R . > .facl_${syncstamp} rsync -ave "ssh" . reguser@otherserver rm .facl_${syncstamp}
And then a root cronjob on another server basically looks for .facl_* files periodically and runs: cd /whereever set -o noglob for ifacl in .facl_*; do setfacl --restore=${ifacl} rm ${ifacl} done
In fact, since Red Hat insists on not supporting XFS with its xfsdump that maintains EAs, and Ext3's dump does nothing of the sort (and I'm not a huge fan of star), I use getfacl to store the original ACLs with my backup in a file included with the backup.
That 's great Bryan!
Thanx
On 12/9/05, Yiorgos Stamoulis yiorgos-lists@272deg.homelinux.net wrote:
Bryan J. Smith wrote:
getfacl can dump an entire tree's permissions to a file -- both UNIX and Extended Attributes (EA) Access Control Lists (ACLs). You could then rsync that file, and run it on the other side. In fact, that's how I deal with the fact I don't want another system login in to SSH as root.
Basically: cd /wherever syncstamp="`date +%Y%m%d%H%M%S`" getfacl -R . > .facl_${syncstamp} rsync -ave "ssh" . reguser@otherserver rm .facl_${syncstamp}
And then a root cronjob on another server basically looks for .facl_* files periodically and runs: cd /whereever set -o noglob for ifacl in .facl_*; do setfacl --restore=${ifacl} rm ${ifacl} done
In fact, since Red Hat insists on not supporting XFS with its xfsdump that maintains EAs, and Ext3's dump does nothing of the sort (and I'm not a huge fan of star), I use getfacl to store the original ACLs with my backup in a file included with the backup.
That 's great Bryan!
hmmm... would this work for SELinux as well?
-- Leonard Isham, CISSP Ostendo non ostento.
On Sat, 2005-12-10 at 06:35 -0500, Leonard Isham wrote:
hmmm... would this work for SELinux as well?
Unfortunately, no. It only backs up the traditional UNIX and POSIX EA file ACLs, not all POSIX EAs.
That's where you need a good dump of the filesystem that backs up all EAs. According to one person who just recently corrected my ignorance, Ext3 now does this. How well, I can't attest, never used it.
But at least it's now there.
<tangent> It was one of my major gripes about Red Hat not adopting XFS earlier, especially since they are pushing forward on SELinux. I very much agree with the push on SELinux, but to ignore a filesystem that would solve the EA issue and so many other things in 1 swoop almost seems more like a "political" decision.
As much as JFS and ReiserFS users bitch about lack of inclusion, there are major compatibility issues with a lot of their interfaces and things that Red Hat supports. So they can never be included _until_ they address thos. This is not true of XFS, which had quota, POSIX EA/ACL, NFS and countless other support from day 1 in 1999 (and its official 1.0 release in April of 2001) -- things that Ext3 didn't even have (and is still very much lacking in comparison to XFS, especially when it comes to how its dump operates, an on-line repair its fragmentation tool, etc...).
Only now are there issues with 4K stacks and NFS support in kernel 2.6, things that Red Hat could quickly address if it would adopt XFS. I would _never_ use XFS in the stock 2.4 kernel _except_ for the releases that SGI made. </tangent>
On Thu, 2005-12-08 at 20:36, Sudev Barar wrote:
I use rsync to synchronize 4 locations, but I fillow the master/slave route, i.e directories are synchronized only one way, each server holding the master copy of it's data and read-only copies of the other server's data. I would have preferred to use unison for proper synchronization but i need to copy ACLs as well and as I understand this is not possible. Am I wrong about this?
There are options for transferring ownership and perms (-owner and -perms), although I admit I haven't tried them. If they don't work right, but you know how things are supposed to look, you can always run chmod & chown afterward.
rsync also has time tags and you can use them to determine if the file on download side is newere and hence excluded from sync. We do it this way and keep all data as fully functional on three locations.
Some one on another list pointed out tsync but have not had the time to llok it up and test it. No idea about unison, will also put it on list of things to do! Thanks.
Are you trying to sync a directory with activity at both locations? What happens when files are being changed during the sync process or the same file is updated differently in two locations at the same time?
On 12/9/05, Les Mikesell lesmikesell@gmail.com wrote:
On Thu, 2005-12-08 at 20:36, Sudev Barar wrote:
rsync also has time tags and you can use them to determine if the file on download side is newere and hence excluded from sync. We do it this way and keep all data as fully functional on three locations.
Some one on another list pointed out tsync but have not had the time to llok it up and test it. No idea about unison, will also put it on list of things to do! Thanks.
Are you trying to sync a directory with activity at both locations? What happens when files are being changed during the sync process or the same file is updated differently in two locations at the same time?
Fortunately for me the situation of two people editing same file at same time does not happen as each user works only his/her directory. But yes that is a problem that needs some other solution ...NFS & lock..???....but with thin pipes between the offices and the fact that no two users are working on same file at the same time points to this method.
If the file is being worked upon at time of rsync the committed file is synced. The updated file is synced only on next cycle.
-- Sudev Barar Learning Linux
-
Bryan J. Smith -
Jonathan Darton -
Joshua Baker-LePain -
Leonard Isham -
Les Mikesell -
Matt Morgan -
Sudev Barar -
Yiorgos Stamoulis