You ([EMAIL PROTECTED]) write:
>1)  I want to replicate the volume mounted at /afs/mycell/usr/local/sws.
>    What non-obvious things do I need to consider?

        It is very useful to have an "image" machine for testing.
Its /usr/local for your cell would point to

/afs/.mycell/usr/local

rather than

/afs/mycell/usr/local

Actually, I don't quite understand why "usr" is in the path.

        Also, if you plan to distribute software for campus and other
system administrators are using the software, consider picking a name
other than /usr/local.  We use /usr/pubsw.  Same number of letters,
and that comes in handy for binary edits.

>2)  This volume's contents change occasionally.  Is there any way to automate
>    the release of changes to its ReadOnly clones?  Do I really have to do
>    "vos release" after editing any file?

        It's not really a big deal to release a volume or set of
volumes.  Keep a list of the main volumes that change or write
a script to generate them, and script your most common releases.

[EMAIL PROTECTED] (John Hascall) writes:
+       We use cron to do this at regular intervals (we still sometimes
+       do it manually when we are in a hurry).

        Do you always have your volumes in a releasable state?
It's rather nice to be able to install and test software without
it being released.

=Jeffrey Hutzelman <[EMAIL PROTECTED]>
=Many cells take advantage of this behaviour to allow coordinated releases
=of lots of files (for example, an entire software package).  This means
=you can be installing a new version without affecting the old until the
=last minute.  Beware, though, that if you replace a binary and then
=release that volume, copies of that program running on a client will
=almost certainly crash.

        Save the old copy for critical items (shared
libraries or often-used programs), install the new items, and
release the volume.  Nothing crashes.  A week later or whenever
you can then blow away the old item.
        If you install all the software in separate packages
and then link in the software, then you don't have to even worry
about this -- the inode for the old files doesn't disappear when
you upgrade to a newer package.

                    Yours,
                            Larry Schwimmer
                            [EMAIL PROTECTED]

Reply via email to