response 107 of 181:

Oct 22 15:16 UTC 2001

Re #98: I think part of janc's point was that you can generally only 
get patches for any particular FreeBSD or OpenBSD release for a year or 
two, but patches are released for older Solaris releases for a long 
time.  This is important if you don't want to be rebuilding the system 
on a new OS version every 12 months.

Re #102, 105: Ugh.  You should never base a production system on CVS 
builds.  I've tinkered with CVS-maintained code, and it inevitably 
breaks from day to day as people submit updates that inadvertantly 
break other people's code, sometimes with severely bad consequences.  
This is why most serious projects do a "code freeze" before they 
release a new version.  There are very few exploits that allow an 
attacker to do an "rm -rf / in seconds", and the few that do tend to 
have work-arounds that can be implemented before the official patch is 
available.  (The last one I can think of that was literally that severe 
was the 'rlogin -froot' vulnerability that was discovered about five 
years ago, though there have probably been one or two since then.)

response 109 of 181:

Oct 22 22:15 UTC 2001

Re #106:

November 3rd, 2001, AD
6:00 PM
607 Ross Street, Ann Arbor, Michigan, USA
Potluck.  If someone or some group would like to bring/order pizza as their
contribution to the potluck, I predict it will be received well.  However,
we can probably flatten other dishes enough to slip them under the door.

response 111 of 181:

Oct 23 01:16 UTC 2001

re 108:  exactly.  thank you.

response 113 of 181:

Oct 23 14:03 UTC 2001

I hereby decline my nomination.  Thanks, though.

response 115 of 181:

Oct 27 09:39 UTC 2001

i'm really looking forward to reading about the results of this meeting.

please remember that at the end of the day (or in this case, the
meeting), agreeing to some workable solution, even if not perfect and
not necessarily ones preferred choice, is the important thing to get
out of the meeting.

response 117 of 181:

Nov 2 10:41 UTC 2001

if so, the below url, when strung together as a single line 
on your location/address bar, (cut-n-paste each line into 
that field leaving NO spaces).
  
provides a nice map in netscrape 4.x

 
http://mapquest.com/cgi-bin/ia_find?link=btwn%2Ftwn-map_results&uid=
uae5r9hdv2pcb2ld%3Ats5fyllu7&SNVData=3mad3-h.fy%2528wal5y2_%2529rba047
%253bpq%257cs9z%2Cp7%253b8aq.hqu%253b%25280uz%252b%2518X%2515G%252bEJ
%2528%2513W%2511%252b%2513%2514VQ%2518%253dED_qr22l%253dbsuu%2528%2511E
%253arl1rzn%253d%253dyx0z82%253d0%2Crb%253b7%253bb5m-r2qfj5m%253be10h
%25284&pcat=&aphoto=0&MAP_AB_LABELS=&WORK=&mouse_mode
=center&map.x=382&map.y=290 

response 119 of 181:

Nov 2 15:28 UTC 2001

For those who are faint of heart, this might be easier to type:

   http://www.valeriemates.com/directions.html

(This was entered by Valerie, with directions, in response 66 to this item.)

response 121 of 181:

Nov 2 16:15 UTC 2001

Reminder that the potluck is TOMORROW NIGHT, November 3rd, 6 PM, 607 Ross.
I will probably bring chili (with meat).

response 123 of 181:

Nov 3 02:05 UTC 2001

Oh, as of today we have a wireless network in the house.  So if you have a
laptop with a wireless network card, it may be possible to use it for quick
net searches to see if FooBSD really does run on massive networks of Sinclair
ZX80's.

response 125 of 181:

Nov 3 07:38 UTC 2001

not 'ir' all goes well....

'rf' all goes well!

response 127 of 181:

Nov 3 20:25 UTC 2001

The university I work for has recently aquired several Sun Enterprise 450
servers from bankrupt dot coms for a mere $10k.  If the discount can be found
at other auctions, perhaps you could pick up a Sun E280R rackmount workgroup
server for around $2k (e450 ~ $100k new, e280 ~ $20k new).  Oops.  This is
in canadian dollars, so multiply all of these figures by 0.62 (even cheaper).
I think it would be much better to take advantage of very high end equipement
being liquidated at rediculously low prices (often the auctioneers don't even
know what it is), than to spend your few dollars on brand new x86 "consumer"
equipment.

response 129 of 181:

Nov 3 21:23 UTC 2001

Regarding #127; I disagree.  x86 equipment is just as reliable as Sun
stuff, performs better, and is a lot cheaper to maintain over the long
run.

Since I can't make it to this meeting, here are my 2c.

That said, I highly recommend that grex go with an x86 machine running
FreeBSD in an SMP configurationm with a lot of RAM, hardware SCSI RAID,
and fast ethernet.  It's the most bang for the buck you can get right
now, it'll be around for a very long time in the future, and can support
a lot of very interesting stuff.  If you can get a used PCI digiboard
serial card, you can hook up all of your modems up to it, too, eliminating
the need for your terminal server.

To address the security issues you'd face, I'd mount everything except
/ nosuid, mkdir -p /suid/{bin,include,lib,sbin} and then get the source
to, and recompile and statically link all the setuid and setgid binaries
you *really* need and put them in /suid/{sbin,bin}.  You could probably
even mount /usr read-only, and possibly do the same with /usr/local if
all the programs that need to write there have some place else to write
(this basically means TeX and maybe emacs; of course, doing this would
make updating things in /usr/local a pain).

For locally written setuid stuff, I'd write a set of highly tested and
vetted libraries that I placed in /suid/lib (headers in /suid/include)
that did things like deal with variable length strings securely, do
IPC and authentication, and so on.

A lot of other security concerns could be mitigated by running recent
versions of such things as OpenSSH, telnetd, ftpd, etc.  The list of
network services grex *really* needs to run is probably pretty small.
I'm guessing:

        finger
        ftp
        http
        ntalk
        smtp
        ssh
        telnet

Servers for these, again, I'd recompile and put into a separate filesystem
(eg, /suid, though at that point, you might want to rename /suid to
/local or something).

Some things I'd rewrite to either use kqueue or sockets (eg, party
would be a good candidate for that; it'd be nice if picospan used
some protocol to talk to its back-end instead of just stashing stuff
into a file structure).  Anyway, by making these things always run as
some user who is dedicated to them (eg, create a user called `party'
to run party), you eliminate the need to make things like part(l) suid.
The party daemon (and others, like the web server) could run in jails
for even more security.

Not many hacks need to be made to the kernel; eg, ipfw already does what
grex needs for firewalling, so the socket based kernel blocks don't need
to be ported.  I question to what extent things like the fork bomb killer
*really* need to be added if the per-user process limit is low enough, and
what facilities to combat this sort of thing does FreeBSD already provide?
At anyrate, it's worth looking into.

Also, using soft metadata updates and aggressive directory caching will
save a lot of I/O hitting grex's disks, which is good, and frees the
staff from having to do hacky things like ordering mkdirs in the home
directory filesystems so that more common directories are searched first.

In userland, If the system is big enough, I don't see a need for
the queuing telnet daemon; one of those other systems (nether.net or
something) doesn't seem to run it, and seems to have plenty of capacity
for letting folks log in at the same time.  SSH can and should be upgraded
to the latest version of OpenSSH, which will fix a lot of the problems
with it on grex.  (Like that weird one-bit-off error message that keeps
popping up when folks log in!).

The functionality of pwd_mkdb can be substituted for what was done with
the shadow password database, which simplifies matters.  I'd set up
Kerberos 5 for authentication (KDC on another machine), and ditch the
grex password algorithm in favor of 3DES.  Failing that, I'd just use
the FreeBSD-esque MD5 support (note: I'd modify the grex software *now*
to do this, whichever way one chooses, so as to be ready when the system
switches over.  Users have to change their passwords once a year anyway,
so this can be done transparantly).

I'd also take the opportunity to ditch sendmail in favor of Postfix,
which has an excellent security track record, is a better performer than
sendmail, and omits a lot of the bells and whistles that grex doesn't
really need.  It can undoubtedly handle hierarchial mail directories.

Also, the BSD ports collection will automate and simplify the installation
of a lot of the services grex wants to offer; for instance, installing
postgres, bash, emacs, etc. is trivial.  A lot of the software that grex
has installed either comes with FreeBSD, or is directly installable via
the ports collection.

The net result would be a machine that was pretty much standard,
yet had most if not all of the functionality of the current grex.
In addition to easing the maintenance hassle for staff, particularly in
the area of upgrades (since their wouldn't be many hacks to worry about
re-implementing), you'd get a much more robust software environment on
some serious capacity hardware.

All in all, with FreeBSD, x86, and Kerberos 5, you can't lose.