"Peter Lister, Cranfield Computer Centre" <[EMAIL PROTECTED]> writes:
> The solution is easy. When booting, everything BEFORE the AFS startup
> is on the local root filesystem. You need a local directory /local_usr,
> which contains a symlink /local_usr/afs -> /var/afs. If any pre-AFS
> stuff has /usr hardcoded in, then bung it in /local_usr as well (the
> AFS dynamic kernel loading for Ultrix needed bits of the linker in here).
>
> Delete /usr (it'll either be a symlink or a directory on the root filesystem)
> Symlink /usr -> /local_usr
> Start bosserver (if this machine IS a server)
> Start afsd
> Wait until you can see /afs/cell/@sys/usr
> Create a directory on the root file system containing links to all the
> directories in /afs/cell/@sys/usr, or copies of symlinks it finds there.
> Delete /usr
> Rename the directory you just made to /usr.
> Continue the rest of the boot sequence.
This is a perfect example of the simple made complex. There is no
reason for this. If you want to, for whatever reason, run AFS cache
managers on production fileservers and, for whatever reason, shave
bits of the filesystem off into /afs, it is simply not neccesary to go
through the contortions you are going through to do so.
You are going to have a /usr on a local filesystem. If it doesn't come
up for whatever reason, the machine will have problems. No way around
it. You shouldn't try to work around this. It should be a local
partition - it should emphatically *never* be a link to AFS. I think
others have succesfully made this point. If you have a /usr
filesystem, you just put all of /usr/afs right there. Quite simple and
straightforward.
Logic would also tend to dictate that you make absolutely nothing
relating to the fileserver aspect of the machine depend on /afs, at
*any* point in the lifetime of the server. In fact, nothing of
critical importance in /etc/rc (or sundry equivalents) on *any*
machine should depend on /afs. You should always be able to log in as
root or boot standalone and accomplish something. What happens if
fsck goes off and nails something like the afsd?
Another important principle we have found that helps us immesureably
here is to be extremely conservative in mucking around the innards of
vendor-supplied procedures. This frees you from a lot re-engineering
and hacking pain when patches and upgrades come. It also minimizes the
hemming and hawing you have to go through when trying to get support
>From the vendor.
This shouldn't be more than a statement of the obvious. I've found
that unless you aggresively apply the KISS principle to everything you
do it is not too long until you have made a system like a house of
cards, just waiting for the slightest breeze from unforseen quarters
to come in and blow everything away. A lot of our work here at andrew
for the last several years has been spent converting from a system
with a million hacks to a (relatively) systemized and supportable
environment. It helps ...
dan
cmu comp services
[EMAIL PROTECTED]
