Coda File System

Re: volume connection timeouts

From: Patrick Walsh <pwalsh_at_esoft.com>
Date: Tue, 03 May 2005 08:47:07 -0600
> A right fix would be to let Apache to write logs as another uid than root.
> A workaround would be to let Apache to write logs on a local file system.
> Then you can copy them over to Coda by a non-root process, periodically,
> say at log rotation (you said such delay is ok).

	We need to leave apache as root, but have made sure all cron jobs are
being run as a special user.  And we're being very careful now with our
other server processes and what uid's they run as.  The periodic copying
of the logs files is a possibility and may yet be a route we take, but
for the moment things seem to be working more-or-less properly.

> > I wonder if venus could detect when the server is on the
> > localhost and then adjust itself to be more patient?  I'm sure it's
> 
> I think it would be wrong to make hooks trying to improve a rare - and anyway
> troublesome - configuration. 

	Probably not so rare and certainly it would be less troublesome if
there was code to accommodate it. :-)

	I was thinking about putting coda on my home linux gateway machine and
using it to share files.  However, my Apple laptop cannot connect to it
(I couldn't get the kernel module to build for my kernel).  So I'd need
to use scp or samba or some alternate method for accessing the coda
filesystem, and that would mean having a client on the server.  

	Of course, I'm far too afraid to try something like that, so it's not
going to happen anytime soon, but you see, there are situations where
having a client and server on the same machine has real benefit.  If
only it worked smoothly.

> Think also that a client can find at most one server on the same host,
> while there is at the same time an indefinite number of [realms and] servers
> on other hosts. It is those we should care about :-)

	Sure, I'm really just talking about when it looks to a realm and picks
an IP that refers to itself.  It's a special case that is, I think,
worth addressing.

	I appreciate all your comments and clarifications, Ivan.

-- 
Patrick Walsh
eSoft Incorporated
303.444.1600 x3350
http://www.esoft.com/

Received on 2005-05-03 10:48:22