[1844] in SIPB-AFS-requests
Re: /afs/sipb/service/@sys
daemon@ATHENA.MIT.EDU (mhpower@MIT.EDU)
Fri Mar 3 05:31:43 1995
From: mhpower@MIT.EDU
To: jhawk@MIT.EDU
Cc: sipb-afsreq@MIT.EDU
In-Reply-To: "[1839] in SIPB-AFS-requests"
Date: Fri, 03 Mar 95 05:28:45 EST
>I'd like to request that sgi_52 be created,
I did this. Also, I built vbck for this platform and installed it
there. To test it, I needed to re-setup vbckd on ronald-ann. I took
the files for this from /afs/sipb/machine/ronald-ann (see [1497]).
This setup is, unintentionally, only temporary, in that ronald-ann has
"ops 1.10" in /var/server/.services, and therefore will overwrite
/etc/inetd.conf and /etc/nsyslog.conf with versions derived solely
from the system packs whenever mkserv is next run on the machine. It's
possible to undo this with a .private script that simply copies back
the current /etc/inetd.conf and /etc/nsyslog.conf from some other
directory. I don't think this is the right approach, though: mkserv
ops seems to be designed to put machines into a single, fixed state
that's appropriate for servers managed by DCNS, and could presumably
be changed at any time to overwrite any other configuration files that
should be setup differently on DCNS servers. Rather than having a
.private script trying to undo the effects of mkserv ops, I think
there should be a separate sipbops (or sipbserver, etc.) service that
we use instead. Presumably it'd currently be similar to the ops
service except for the changes to those files and the MRUPDATE=true.
Is there any objection to getting rid of the ops service on the sipb
afs servers and replacing it with another service that can be used to
preserve our current configuration?
> ... and populated with AFS client
>binaries (bos, fs, aklog, etc.).
>Secondly, I'd like to request that i386_linux1 and i386_nbsd1 be
>populated with afs client binaries...
Unfortunately I don't know the best place to find all these binaries.
Matt
