response 1 of 51:

Jan 26 05:31 UTC 2002

>*giggle*<

<krj stifles himself>

response 3 of 51:

Jan 26 14:58 UTC 2002

(oh my god.  The image of krj giggling is almost too much for my brain this
morning)

response 5 of 51:

Jan 26 18:46 UTC 2002

NFS over Internet == bad idea.

response 9 of 51:

Jan 27 02:02 UTC 2002

Well, I've used AFS on SunOS 4 and 5 boxes, as clients.  UM was looking to
migrate its AFS servers from AIX to Solaris; I don't know that they did,
though.  (I _should_ know, but I don't.  I _think_ they migrated.)

response 11 of 51:

Jan 27 19:50 UTC 2002

There are lots of people who mistrust email as a means of transmitting data.
But if we're talking about Grex conferences, well, ... who are you afraid
might read it?

response 13 of 51:

Jan 28 01:43 UTC 2002

This sort of made sense in the pre-consumer-Internet days when 
it might have been M-net linking with Fish-net in Florida.
But in 2002 I wonder what the point is.

response 15 of 51:

Jan 30 18:03 UTC 2002

Oh come on. Anyone on Mnet who cares anything about Grex is already here 
and vice versa. There is little point in a link. 

response 17 of 51:

Feb 7 03:25 UTC 2002

I agree that no purpose would be served by doing this.

On the technical front:  Fronttalk.

Install the fronttalk client on M-Net and any user will be able to use it
to read and post to (if they have a grex account) the conferences on Grex,
through an interface very similar to Yapp/Picospan.  That's trivial to do.
To be able to read the M-Net conferences via fronttalk (either from M-Net
or Grex) you'd need to install backtalk on M-Net.  This is probably not
extremely difficult, since Backtalk is supposed to be able to co-exist
with Yapp.  However Backtalk's Yapp compatibility isn't fully tested,
and there are likely to be at least some issues to work out there.

Anyone wanting to know more about fronttalk is invited to read the item
in the garage conference.

response 19 of 51:

Feb 24 07:18 UTC 2002

why would data files need to be suid anything?
just install the clients seperately, read/write items to/from a networked
filesystem.  nfs would blow, afs would probably work fine, coda would be cool
except from what i see i can't tell if it's been modified at any time in the
past 5 years or so.  set up ipsec (dunno how easy that would be with the
current grex, although i'm sure it wouldn't be a problem with the move to
sparc/openbsd), mount an m-net volume or m-net mount a grec volume, and poof!
there's a shared filesystem.  the big problem i see is in concurrency: the
lag will be so severe that there's the possibility that something as simple
as a slip might cause a problem, no?  i'm guessing a hack or three to get
around that (if it were to be a problem, even) wouldn't take much effort.

response 21 of 51:

Feb 25 23:34 UTC 2002

right, i know the suid bit applies to executables.  my point is: why would
the executables need to exist within the actual net mounted filesystem?  for
instance, if both machines had a client (yapp, picospan, whatever) residing
in /usr/local/bin, and that client is setuid cfadm, what other binaries would
you need to lie on the shared filesystem?  both clients would store the data
in the same shared filesystem, and that filesystem shouldn't need *any*
executables whatever, right?  plus, even if we were to want to share
executables for whatever reason, binary executables wouldn't be compatible
(sparc <---> x86?  nope...), and shell scripts can't be setuid anything (or
at least that's been the case for a long time...dunno if grex still has setuid
scripts).  and even if there is worry, just mount the thing nosuid.

since no binaries need to reside on the shared filesystem, i see no reason
why we don't just toss that aside as irrelevant.

response 23 of 51:

Feb 26 02:43 UTC 2002

how does the fileserver know what?
that the user accessing files being served actually should be accessing them
and that that user is not really someone pretending to be someone else?  it
doesn't.  it assumes just as a monolithic machine does that the euid of the
running process should actually be that euid and that no one has messed with
it maliciously.  i understand your concern, but a proper exports file along
with a proper ethers file and maybe even some firewall rules will lock things
down enough that you really don't have to worry about some random joe spoofing
m-net's or grex's ip with the goal of accessing a secluded filesystem and
doing damage to it in mind.  a cron job to back up the conference(s) residing
on that filesystem nightly onto a non-nfs-exported filesystem will ensure that
very little data will be lost in the case of a data deletion attack, however
unlikely the success of such an attack might be.

i don't think security is as much of an issue here as is concurrency.  will
the conferencing software be able to handle, say, 10 simultaneous responses
locally and remotely?  how does the software handle locking?  would the
locking semantics be somewhat different if the filesystem it's writing to is
a network filesystem?  how do we deal with time synchronization?  does the
conferencing software work exclusively with locks, or with timestamps, or with
both?