On Wed, Dec 18, 2002 at 10:46:00AM +0100, jochen wrote:
>   * If the whole architecture does so much rely on the exact IP, the
>     processes should bind only the interface they where assigned. At the
>     moment, all Coda server processes bind 0.0.0.0 instead of their
>     specific interface. If you want to bind 0.0.0.0 but also have to
>     rely on the exact IP being used, you have to bind every interface
>     (like ISC BIND nameserver does for example)

Yes and no. The volume lookup RPC call gets back a single IP-address for
a volume. This is the address that is used to talk to the server. So we
assume a certain network layout where there is one IP-address than can
be used to reach a server whatever network we are connected to.

At some point, someone tried to run multiple servers on a single machine
to get around the 2-3GB per-process VM limitations. However because
servers are identified by just a single IP-address, and there isn't even
a port number, the solution he chose was to bind several aliases to a
single network interface and have each server bind to a specific
interface.

All of this works fine as long as your server only has a single network
it is connected to, but a multi-homed server makes life a lot more
complicated. I've seen so many different multi-homed setups, that I
don't think there even can be a universal solution, how does a client
know which of the possible ip-addresses for the server to use.

f.i. CMU has 802.11 everywhere on campus, so when my laptop is plugged
into the ethernet, I could either use the 11Mb/s wireless network, or
the 100Mb/s wired network. If we use the wired network, we can quickly
reintegrate or hoard files, but we could be disconnected at any point in
time. The wireless network is 10x slower, but it is always on. Now the
user knows whether he is going to be at the same place for a while, but
the Coda client doesn't.

>   * all scripts (startup scripts and especially those for
>   creating/managing volumes) should always use `cat
>   ${vicedir}/hostname` instead of `hostname`, they also should always
>   use ${vicedir} instead of /vice. This is badly mixed even inside
>   scripts

There was a problem with 'hostname'... Ah yes, on some platforms it was
returning something different (either fqdn or the hostname itself) and
it tended to change across upgrades. We had some problems because one
server thought it wasn't the SCM, while some others were convinced it
was.

We should be using ${vicedir} instead of vice, all of the commonly used
scripts should have been updated by now.

>   * the scripts should always pass the hostname option to other
>     scripts/binaries. For example createvol_rep nearly always passes
>     this option to volutil but in one place ... and fails exactly there

createvol_rep should be run on the SCM, and 'volutil' without a hostname
connects to localhost. i.e. the server on SCM.

>   * the coda-client script in your debian package doesn't work. For some
>     reason unknown to me, venus dies immeadially after printing it's
>     version number when invoked with this script.

Noticed that the other day. It can't do setppid or something weird, it
must have something to do with how it is started by start-stop-daemon.

>   * cfs mkmount works but it segfaults and locks the whole system. After
>     rebooting, the mountpoint exists and everything is fine

Never had that happen to me. What linux kernel are you using?

>   * in vice-setup you should be asked to which hostname/ip the server
>     should be bound to

No, because as I explained above binding to specific ip-addresses is not
a normal mode of operation. It is a hack that I don't like to get around
a VM limit. It would have been better to add a port-number to the
GetVolumeInfo RPC2 call (and use a fqdn instead of an ip-address).

Jan