Coda File System

Re: hoard, disconnected usage advice?

From: Jan Harkes <>
Date: Wed, 12 Nov 2003 14:26:10 -0500
On Wed, Nov 12, 2003 at 01:19:42PM -0500, Richard M Kreuter wrote:
> Jan Harkes <> writes:
> Firstly, thank you for answering my many questions.
> > On Mon, Nov 10, 2003 at 07:57:45PM -0500, Richard M Kreuter wrote:
> >> (1) On my tiny (two host) coda cell, I find I'm not able to hoard as
> >> an unprivileged (non-root) user on the clients.
> >
> > If there is no primaryuser specification, the alternative test is to
> > make whoever is logged into the console the implicit primary user
> > ('console' for all systems, except for Linux where we check 'tty1')
> I guess I'll hoard from tty1 then.  

You just need to log in on tty1. After that your userid should be able
to hoard from anywhere it logs on to the system. Venus only knows your
local userid and then uses the utmp (or wtmp?) file to figure out if
that userid matches the primaryuser and if that wasn't set, happens to
have an active session on tty1.

> > 'df -i /coda' might tell you the number of files that can be cached and
> > such. The client uses a simple formula based on the 'expected average
> > filesize', which is approximately 8000 files for a 200MB venus.cache.
> I was at a loss for how to resize the cache, so I removed and
> reinstalled the client.  For future reference, is it possible to
> resize the cache?

Not without reinitializing RVM, which is close to reinstalling. You can
edit /etc/coda/venus.conf, and then start the client as 'venus -init'
before it picks up a new cachesize.

> > [Re: rebooting a disconnected client] Not sure, I actually rarely
> > restart venus while disconnected because I tend to suspend my
> > laptop, the typical uptime is several weeks at a time (until I boot
> > into a new kernel).
> Unfortunately, the APM on my laptop is reliably lousy, so that's not
> an option for me.
> I've found (and then lost) some hints in the mailing list archives
> (ca. 1998-9) that suggest that venus is supposed to do operate
> disconnectedly in case the servers' FQDN resolves at start time, and
> the servers aren't reachable.  Is this so?  Or was it?

Yeah, I looked at this last night and figured it out.. Pretty stupid of
me. When I implemented realms, I forgot to make sure we remember the
name of the rootvolume.

So the client has a realm and a bunch of volumes, but no idea which
volume should be mounted first.

> Also, how does a disconnected venus deal with token expiry?  I'd hope
> it wouldn't expire a token while I was disconnected.

Well the token it stays around until a server actually rejects it. So as
long as you are disconnected there should be no problem. However we do
not store tokens in recoverable memory, so you would have to store a
copy of the token on a secure device (local disk/floppy/USB dongle),

    clog -tofile /.../mytoken

And once the client is up and running you can reauthenticate without
needing a network,

    clog -fromfile /.../mytoken

> Thanks again for any instruction.  If I can get a handle on things,
> I'll try to submit some patches to the documentation package
> (apparently dropped between 5.x and 6.x).

Not dropped, most things are still the same and it just hasn't been
updated for the couple of new things.

Received on 2003-11-12 14:28:19