[3237] in SIPB-AFS-requests
Re: migrating rosebud to a Sun
daemon@ATHENA.MIT.EDU (Mike Whitson)
Mon Jan 18 19:30:23 1999
To: mhpower@MIT.EDU
Cc: zacheiss@MIT.EDU, sipb-afsreq@MIT.EDU
From: Mike Whitson <mwhitson@MIT.EDU>
Date: 18 Jan 1999 19:30:17 -0500
In-Reply-To: mhpower@MIT.EDU's message of Mon, 18 Jan 1999 05:01:38 -0500
mhpower@MIT.EDU writes:
> Do we now know that /os and /srvd won't fit? In Garry's mail, it
> didn't seem that we knew a second system disk would be necessary:
> > ... One
> >problem here is that the system disk in the SS5 might be big enough to
> >hold one copy of /os and /srvd local (although it would be tight) ...
> Presumably a second system disk could be added at a later time,
> such as during the outage window for the SunOS 5.7 upgrade (if there
> ever is a SunOS 5.7 upgrade on the machine).
Sure, but this doesn't address the fact that (until a UFS backup
system is enacted) it causes installs to be much more laborious. Nor
does it address the problem of the other two SPARCstation fileservers,
which cannot hold a copy of the system packs on their internal disks.
> >/mit/ops/doc/admin/afs/solaris.afs.install
> It references a file /mit/bootkit/solarisinstall/25/README that, as
> far as I can tell, doesn't exist.
Thank you for noticing that; I've fixed it.
> Also, it wasn't clear to me whether the install servers (it appears
> from /mit/bootkit/solarisinstall/README that either solar2 or sunburn
> could be used) would be used to install exactly the software that gets
> loaded onto an Athena workstation for 8.2.15, or whether they would be
> used to install some other configuration of Solaris 2.6. For the
> rest of the message, I'll assume newly installed servers start out
> with the standard 8.2.15 before any mkserv occurs.
See ghudson's mail. To answer your query, all ASO servers start off
running a vanilla athena-client configuration before running mkserv,
either 8.1 or 8.2, depending on which release one chooses to install.
> >Also, the "afs", "ops", and "remote" mkserv services are used.
> I don't think it's appropriate for all of the effects of "mkserv ops"
> to be left in place on the machine.
I concur with all of hartmans' points; I'll not waste time by
restating them. It's worth noting that causing those effects not to
happen can be done easily in one of two ways. We could either create
a standard /var/server/.private file for the SIPB afs servers which
ensured that this was the case, or SIPB could replace "mkserv ops"
with a service of its own devising. It looks like rosebud's Ultrix
incarnation was installed using
/afs/sipb/service/afs/mkserv/sipbops.*; we could do something like
that here as well. The "afs" mkserv service does not depend on "ops"
and "remote".
> However, I do think that the configuration used on ASO servers has
> some difficulties with respect to maintainability and potential
> security risks, and should not be used as-is on sipb afs servers. In
> this sense, I disagree with your statement of "isn't broken".
I believe that here we will simply have to agree to disagree.
hartmans:
> Is there a zephyr-enabled syslogd that accomplishes this? If it
> already works on Solaris, this sounds reasonable; otherwise, it
> doesn't appear to be worthwhile.
I believe one is available for Solaris, either in the Athena system
packs or in the zephyr locker. (I haven't paid too much attention to
the progress of this issue, so my information may be out of date.)
> This is somewhat less critical, but I also think sipb servers should
> move away from relying on either the Sun or Athena inetd due to
> denial-of-service issues.
One of the changes in Athena 8.3 is that the Athena inetd will be
replaced with an inetd providing the same functionality, based on the
NetBSD inetd code base. ASO runs this inetd on a number of servers
where inetd performance is critical, and has had good experiences with
it. I'd have no problem moving to this inetd.
-mike
