[903] in NetBSD-Development
Re: Maintenance issues
daemon@ATHENA.MIT.EDU (Matt Braun)
Wed Jul 26 09:34:12 1995
To: Greg Hudson <ghudson@MIT.EDU>
Cc: pc-dialup@MIT.EDU, bug-dialup@MIT.EDU
In-Reply-To: Your message of "Wed, 26 Jul 1995 02:44:11 EDT."
<199507260644.CAA06191@glacier.MIT.EDU>
Date: Wed, 26 Jul 1995 09:32:57 EDT
From: Matt Braun <mhbraun@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 am actually pretty sure that we we want to seperate out the lists. In
addition to the traffic and confusion levels, there are dialup issues that
should not be talked about on a public list with a publicly archived discuss
meeting. As an alternative to yet another list, is that once we know who the
core people on this project are, adding them to bug-dialup (or access for the
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.
I meeting would re reasonable. If by 'tomorrow' you mean wednesday, I am
unavailable from 10am-4pm and after 6pm. I would probably prefer to discuss
things sometime on thursday (maybe thursday evening, since all the full time
staff involved are on weird schedules anyway).
Is there anyone who thinks they should be present that cannot make a meeting
Thursday at say 6 PM ?
>> 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.
I think your proposal is a reasonable compromise. We may want to redraw the
line since (no offense) but Charles is not really affiliated and that could be
potentially probablematic (note: this is not a trust issue....we will trust
Charles for OS source and that is good enough if he wanted to do something)
>> 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.
Karl is correct here....we would want to maintain our own source tree until it
was integrated into the Athena source tree.
>> ...
>> 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.
I agree with this too. We are trying a pilot dialup project here, we don't
want to require other significant IS resources until we have a proof of
concept. If it looks like we will want the trees merged at some point,
it might be a good idea for netbsd-dev and Craig to get together and find out
what netbsd-dev can do to make the integration easier.
>> 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.
We may want to outline different levels of 'testing' and what security
precautions should be taken. Once anyone can use the netbsd dialup, we should
have the majority of the security precautions in place that will be used in
production.
