On Sat, Nov 10, 2001 at 09:15:52AM +0800, Jeremy Malcolm wrote:
> Ivan Popov wrote:
> > 
> > It would be very interesting to get an estimation of the resources
> > (person*month) needed for making Coda usable "in the wild":
> > 
> > 1. Make it robust (may be we are already there? :)

No, I can still easily crash both clients and servers. It's getting
better. Also the code itself isn't terribly robust yet. Even when we
reach a point where the system appears stable, a simple compiler,
filesystem or VM change in the operating system can lead to new (or
covered up) bugs.

> > 2. Relax server file number limitation to say 500Gb of 10k-files
> >    (even if by a cute configuration utility creating 10 servers at once?)

Hard problem, still implementing parts of the solution, such as the
changes to decrease memory usage during reintegration that went into
5.3.16/7 and hashing out ideas of where we want to end up and how to
get there.

> > 3. Create a working client solution (client, gateway, samba setup,
> >    anything) for Win2k & similar

I could tell you how far Phil got over the summer, but someone would
have to kill you. In any case, we have some licensing issues to resolve
before we can make any claims in this area.

> > 4. Introduce real encryption and make both the server and clients
> >    basically resistant against spoofing, buffer overflows and other
> >    evident types of attack

Buffer overflows, we're pretty safe as far as RPC2 is concerned. However
it is still possible to send arguments along with an RPC2 call that do
not overflow any buffers but will still cause some headaches for servers
that want to process the packet.

> > 5. Support (and may be -hint-hint- standardize) multiple mount points
> >    like afs and dfs do, even if it would rely on dns-names only

Got some ideas here, we don't need to change anything in the servers, it
is just how a client would interpret the 'magic symlinks' that indicate
a volume mountpoint. i.e. currently I would mount a volume in the same
cell as
    cfs mkm /coda/usr/jaharkes vmm:u.jaharkes

and at some point I'd like to allow,
    cfs mkm /coda/usr/jaharkes-in-yourcell users/jaharkes_at_yourcell

Simple rules to interpret the volume names, if there is no @ in the
volume name, assume the volume is in the same cell as the parent volume.
Whenever there is an @ the tail indicates a cell/realm identifying name
(DNS?), if there is nothing in the tail use the client's configured
default cell. If there is nothing in front of the @, a ViceGetRootVolume
rpc (or perhaps ViceGetPublicRoot?) is made to the cell to obtain the
volume name to be mounted. Ofcourse we need multiple user identities
(e.g. clog jaharkes_at_yourcell), but the volume/vsg/mgrp changes have
cleaned up a lot to make it easier to do this.

Ofcourse we still need to find a way to map the cell name to the list of
rootservers for that cell. Simplest solution, a plaintext file in
/etc/coda, other solutions would be DNS lookups, ldap. Maybe we can
simply fork off an helper application that can do such mapping in
whatever way it pleases to. Perhaps having an informal policy on volume
names will help coordinating cross realm mounting f.i. everyone could
have a public volume that can be used as a cross-realm entry point.

So /coda would implicitly be the same as "@" (default cell, and use a
ViceGetRootVolume lookup to find the volume name). An AFS style layout
could be created by populating /coda with 'cfs mkm cs.cmu.edu
@cs.cmu.edu', 'cfs mkm andrew.cmu.edu @andrew.cmu.edu', etc.
Or 'cfs mkm your-own-local-spamdir tmp@'. Ah well, I guess you got the
point and otherwise more examples wouldn't help.

> 6. Easier, one-step setup.  Most of the mistakes that people seem to
>    make and most of the problems they encounter seem to be because they
>    made a mistake (some mistakes quite reasonable) in setting it up.

But then again, Coda is a complex system. Very different from existing
network filesystems, even compared to AFS. And we're doing too much
ourselves, such as the authentication. Ever set up a kerberos realm?
That's not a one-step setup either.

Most mistakes are commonly not even related to Coda, but were already
there, people simply never noticed that their routing/DNS is so messed
up they can't even do 'telnet mylogin_at_thishost' because typically no one
needs to telnet to the local machine once they are already logged in and
applications tend to use unix domain sockets or the loopback interface
of the machine. Another common problem is when gethostbyname("server1")
on server1 returns 127.0.0.1, and the server happily tells any client
that are interested clients that they can reach him by talking to their
own loopback interface.

> 7. GUI (eg. GTK) interface to resolve reintegration conflicts, a la
>    Win2K.  "The file X was changed on your computer (date Y, size Z) 
>    and on the server (date A, size B) while you were offline.  Choose an
>    option: [ ] overwrite server [ ] overwrite client [ ] keep both".

Wow, since when does Win2K have reintegration conflicts??

In any case, for me conflicts tend to be of the category "when it rains,
it pours" and having a commandline based interface makes it a lot easier
to fix them en-masse (find . -type l -exec repair {} /tmp/fix)

> 8. Fix the problem with two replicated servers that I and at least a
>    couple of other people are having (gory details in the archives).

Right. I'm not sure whether it is a bug in Coda at all. Especially since
we've been running doubly and triply replicated servers here for ages
and in an attempt to reproduce the reported problems I have tried
setting up several doubly replicated servers from scratch both in their
own 'cell' and as part of our existing setup. All of which worked
without any problems.

Perhaps the combination of actual useable logging of 5.3.17 and the new
/usr/bin/getvolinfo program that basically only does a ViceGetVolumeInfo
calls and pretty prints all the (non)sense the server is sending back as
a result might help us find it this time.

Jan