[900] in NetBSD-Development
Maintenance issues
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Jul 26 02:44:12 1995
Date: Wed, 26 Jul 1995 02:44:11 -0400
From: Greg Hudson <ghudson@MIT.EDU>
To: pc-dialup@MIT.EDU, bug-dialup@MIT.EDU
[Admin note: I'm not sure netbsd-dev wants to get and archive all the
traffic the pc-dialup list is going to get. Maybe we should take it
off and make a separate discuss meeting.]
I think it's important at this point that we agree on some of the
issues relating to maintenance of the dialup once it goes operational.
We should have a meeting of at least some of the interested parties at
some point (I'll be around E40 tomorrow), but I'd like to raise some
of the issues here so that people can think about them, since they
don't all have obvious answers.
All of these concerns are looking to the point where we make the
dialup user-visible and operational, not the near future. In general,
my recommendations favor a developmental approach while the dialup is
in production as a test dialup, and a more isolated, operational
approach later on.
Developer access
----------------
Charles has suggested that we can get significantly better turnaround
time on solving problems if we give him (as a NetBSD developer) root
access to the machine so he can easily look at it when things go
wrong. The same situation holds for people like me and jhawk who have
significant experience with NetBSD but aren't working for system
support. My experience with IS is that operations employees like to
limit developer access to machines (because developers tend to have a
bit less respect for keeping records of how things got to be in the
state they are and for not risking outages).
My recommendation: since this is a pilot project, let developer-types
have root access to the machine, but tell them not to change anything
without clearing it with system support. (This is similar to how I
have root access on the Zephyr servers, and it hasn't caused a problem
there.) If we consider the pilot project to be successful, and we
purchase more server machines, we can designate one as a testing
machine which developers have access to.
OS source tree maintenance
--------------------------
SIPB maintains a source tree by remote CVS to the NetBSD source tree
(requires Charles or myself to perform updates, since we are the ones
with access to the NetBSD CVS tree). SIPB also maintains a set of
system packs and an installation server. Karl has indicated that
system support might want to want to keep their own OS source tree, so
that they will know precisely what sources various binaries were built
from.
My recommendation: we are at a stage in NetBSD development where the
1.0 release is too far behind on features and bug fixes, so we need to
be using the -current source tree (which, although very stable for a
development source tree, is also a moving target, and at any given
time there are usually minor problems). I think it's in system
support's interest to leverage off SIPB's resources in the early
stages of production, and mirror the NetBSD source tree when the 1.1
release is made. (No, there is no projected date on the 1.1 release.)
SIPB used the 1.0 NetBSD release for a long time after the 1.0
release, integrating important bug-fixes into the source tree by hand.
It wasn't until important features like Linux emulation reached the
-current source tree that we began migrating to -current. Since the
dialup doesn't have the same hardware support concerns as MIT users
do, we can probably hold onto using the 1.1 release with manual
integration of bugfixes until the 1.2 NetBSD release is made, just as
we do with vendor systems.
As for tracking down problems with individual binaries, we can use
"ident" and Charles's or my CVS access during the early stages of
production. I think such problems won't be very common.
Athena source tree maintenance
------------------------------
There's been a fair amount of talk of integrating the SIPB-Athena
changes into the main Athena source tree and doing a real Athena build
for the dialups, especially looking towards the future where we might
someday have NetBSD-Athena workstations in the clusters.
I think if we try to do this immediately, we will find that this is
too much work right now while the SGI integration needs to take place
and DCNS-dev has essentially only one release-engineering worker with
way too many time commitments.
My recommendation: I think we should rely on the sipb-athena source
tree for the moment (mirroring should be unnecessary; changes are
relatively infrequent), and do the integration at Craig's convenience.
Security
--------
Given Matt's desire for security over operational convenience, we
should probably run at securelevel 2 (this will require bringing the
system down single-user to newfs a partition). The only problem I
know of with securelelel 2 is that root can open /dev/mem read-write
and get I/O privileges (this is how the X server works). Since we
won't be running an X server, we can conditionalize that in the kernel
somehow if and when it becomes important.
We can also make a bunch of files immutable so that an intruder who
gains root can't modify the system significantly, but I think we
should wait on that until the system goes into production as a
non-pilot machine before we do that.
