On Thu, Apr 14, 2005 at 11:45:37AM +0100, 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:
> > > 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?
> 
> Manually running the updatefetch for db/prot_users.cdb fails as in
> vice-setup. 

The other files that got fetched were all fairly small they probably got
piggybacked on the RPC2 reply. My guess is that this was the first file
that it tried to send with the SFTP side-effect, and this transfer is
initiated by the server side of the connection. There might be some ip
difference.

> 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.

Interesting, I always thought we also copied the permissions over, we
definitely should be doing something like that because the up-to-date
check is done by comparing the timestamps on the files and to avoid
clock skew problems I though we always forced the files on the client to
match the timestamp on the server (instead of using the current time).

> 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 

We should still be able to open it for reading on the SCM, and on the
writing side I thought we first created a temporary file and then moved
that one over the original to make the update somewhat instantaneous.

> 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 

updateclnt, which should be the same as updatefetch, but it stays around
and checks if the file has changed on the SCM.

Jan