Orginal post.
Hello world,
I have been trying to find a solution for the following problem.
I have decided I need more suggestions.
Problem :
we have a software server (All the software anyone needs is installed here)
and a back up software server. Both servers
are used all day. Two servers are required for load balancing, better
performance and a safety net in case one dies .
SUMMARY :
Most people like RDIST.
Alot of people liked MIRROR
I had one vote for GUARDWARE.
One vote for TRACK..
Rdist seems less secure because it has to have root privilege on the other
machines. IT pushes software . Track pulls it, so it only needs read privilege.
I am going to have to find out about mirror and Guardware.
Gene Rackow had some very good comments....
Thanks to all listed below and the whole list for being there....
Some extracts:
From: kandy@illustra.com (Kandy Simpson)
To: parks@xdiv.LANL.GOV
Subject: Re: How to mirror a software server
Why not use Veritas or On-line Disk Suite? Sun supports both of these utilities
but they are purchase items. If you don't have any money then I suggest rdist.
The rdist utility will be capable of interrupt. By that I mean that it will
be able to be re-iniated and will only do checks until it reaches the point
where it last left off. The copy over problem is not present as long as the
application did not change since it was last rdisted. The disadvantage to
rdist is that the process in manually driven instead automatically driven
in the case of Veritas or On-Line Disk Suite (ODS).
******************************************************************************
Kevin.Sheehan@uniq.com.au (Kevin Sheehan {Consulting Poster Child})
rdist would be better for this, as it knows how to move a file
out of the way gracefully so that anybody still using the vnode (like
an executable) won't lose it.
We also have a product called UPFS that does network replication - file
system mirroring if you will - that will keep 2 or more systems in sync
transparently to the user.
******************************************************************************
From: stanley@oce.orst.edu (John Stanley)
Both rdist and mirror are better options. Both will only update things
that are different.
Rdist requires rlogin/rsh ability. There was a security hole in one of the
sun versions of rdist that could grant root permissions to anyone that could
use it, but I think it has been fixed in later releases.
Mirror requires ftp access to the master copy of software. It can be anonymous
or regular. Mirror is available from
src.doc.ic.ac.uk [146.169.2.1]
directory: computing/archiving/mirror
******************************************************************************
From: Torsten Metzner <tom@plato.uni-paderborn.de>
Hello Parks,
yes rdist would be mucher better. It is "designed" for such a job.
We use it with our software servers and we had no problems.
We are useing rdist version 6.1 and not Sun's original one, because in
old Sun versions there were some security bugs. I don't know what's the
state of Sun's Solaris version of rdist.
BTW:
DESCRIPTION
Rdist is a program to maintain identical copies of files
over multiple hosts. It preserves the owner, group, mode,
and mtime of files if possible and can update programs that
^^^^^^^^^^^^^^^^^^^^^^^^^
are executing.
***************************************************************************
From: Fedor Gnuchev <qwe@ht.eimb.rssi.ru>
archie for mirror - yes that is the name of the package to simplify the job.
it can be run from cron job and you'll have mailed results. It can be
configured to mirror only changes and that will result in significant
performance benifit compared to blind cpio of the whole server.
ftp://mipgsun.mipg.upenn.edu/pub/mirror
*****************************************************************************
From: Gene Rackow <rackow@mcs.anl.gov>
You could use rdist, sup, track, mirror, or any number of other tools.
Using the tracking tools will greatly reduce the problem, but not eliminate
it unless you are really careful. Even then there will be some failures.
The problem being that the user is running some app. He needs that binary
to be there. The app now needs to pull something out of the file on disk,
but that file is no longer there, a new version is. The app becomes
very unhappy Hopefully it will die gracefully, but sometimes they get nasty.
The way to prevent these deaths is to not remove the original app
from disk until you give everyone a chance to stop using the old one.
Don't just replace binaries, "mv app app.orig; mv `src/obj/newapp` app"
to preserve the original file at that inode for some amount of time.
What's happening when you do the "mass" replace on your mirror is that
all the apps are being replaced. I could understand users getting very upset
when the updates occur. What you need to do is set up the tracing system
to mv anything that is being updated to a "to be deleted soon" area on the
same partition as it installs the new version. Then at some point in the
future, determined by how long these jobs may be running, you clean up the
old versions.
-_Gene
Many thanks to: Sorry If I missed someone....
mpless@ljswc.ucsd.edu
kandy@illustra.com (Kandy Simpson)
Kevin.Sheehan@uniq.com.au (Kevin Sheehan {Consulting Poster Child})
From: stanley@oce.orst.edu (John Stanley)
From: Stephen P Richardson <spr@myxa.com>
From: Torsten Metzner <tom@plato.uni-paderborn.de>
From: Fedor Gnuchev <qwe@ht.eimb.rssi.ru>
From: Gene Rackow <rackow@mcs.anl.gov>
From: rob.e.allan@hydro.on.ca (Rob Allan)
From: paul_mcgowan@il.us.swissbank.com (Paul McGowan
From: thenrion@csc.com (Timothy Henrion)
From: Jason Boerner <jboerne@uswest.com>
From: fgreco@lehman.com (Frank Greco)
From: Tom Schmidt <tschmidt@micron.com>
From: poffen@San-Jose.ate.slb.com (Russ Poffenberger)
From: lopez@abqato.scs.philips.com (Robert Lopez)
Thank you.
Regards
****************************************************************************
Parks Fields
MS B218 Internet: parks@lanl.gov
Los Alamos National Laboratory Phone: (505) 667-6872
Los Alamos, NM 87545
****************************************************************************
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:56 CDT