I decided to scrap the existing test setup and reran vice-setup on the SCM. 
This time round, instead of finishing after starting the server, it continued 
and set up a root volume for me. Next I ran vice-setup on the other machine, 
and all ran smoothly. Now I need to read up on Volumes...

I think the script finished early the first time round because the last server 
process failed to start. For some reason the entry in db/servers was 
duplicated, and the process wouldn't start with 2 servers having the same 
identifier. I removed the duplicate, restarted all of the server processes 
and went on to create a root volume using an instruction I found in the list 
archive. I could then connect with clients, and thought everything was 
working. It's quite possible I messed something up as there was some 
undocumented trial and error in getting it going. Now I know the script 
should have done it for me. Time to add to the Wiki.

Thanks for the help

Al
On Thursday 14 April 2005 11:45, Alastair Johnson wrote:
> On Tuesday 12 April 2005 20:40, Jan Harkes wrote:
> > On Tue, Apr 12, 2005 at 11:42:36AM +0100, Alastair Johnson wrote:
> > > Is this the master server, aka the SCM machine? (y/n) n
> > > Enter the hostname of the SCM machine : <scm_hostname>
> > > Enter the update token that matches SCM <scm_hostname>: <my_token>
> > > Fetching needed files from SCM <scm_hostname>.
> > >
> > > Date: Tue 04/12/2005
> > >
> > > 11:25:44 Fetch failed with RPC2_SEFAIL2 (F)
> > >
> > > updatefetch failed with RPC2_SEFAIL2 (F)
> > > Could not fetch prot_users.cdb from SCM.  Make sure SCM is setup
> > > correctly and then rerun /usr/sbin/vice-setup.
> >
> > Interesting, it already managed to fetch several files before it failed
> > on this one. So I guess rpc2portmap and updatesrv are already running on
> > the SCM.
> >
> > Does the file /vice/db/prot_users.cdb exist on the SCM?
> >
> > Jan
>
> Manually running the updatefetch for db/prot_users.cdb fails as in
> vice-setup. Manual fetches for db/volutil.tk and db/files succeed, and
> vice-setup successfully fetches the 4 other files. Of these, 3 have the
> same permissions as prot_users.cdb, though I note they do not retain the
> same permissions when they reach the non-scm machine. This leaves auth2.pw,
> auth2.tk and volutil.tk world-readable on the non-scm which doesn't seem
> good.
>
> The only difference I've found so far is that prot_users.cdb is the only
> file that's in use, mmap'ed by auth2 and codasrv (see below). Assuming this
> is normal, is there some guidance I've missed, like 'Don't put /vice on
> reiserfs'? I presume coda uses a process similar to updatefetch for
> synchronisation, so even if I manually went through the setup process
> manually to get teh non-scm machine running I would likely have
> shnchronisation problems when prot_users.cdb gets updated.
>
> bash-2.05b# fuser /vice/db/prot_users.cdb
> /vice/db/prot_users.cdb: 18765m 18792m
> bash-2.05b# fuser /vice/db/auth2.pw
> bash-2.05b# fuser /vice/db/auth2.tk
> bash-2.05b# fuser /vice/db/auth2.lock
> bash-2.05b# fuser /vice/db/volutil.tk
> bash-2.05b# ps -e |grep 18765
> 18765 ?        00:00:00 auth2
> bash-2.05b# ps -e |grep 18792
> 18792 ?        00:00:00 codasrv
> bash-2.05b# fuser /vice/db/servers
> bash-2.05b# fuser /vice/db/files
> bash-2.05b#