Wow, a lot of stuff, I'm just replying to all of it at once.

On Wed, Feb 25, 2004 at 12:13:08PM -0600, Jason A. Pattie wrote:
> Apparently, backup cannot see the volutil command in its PATH.  I'm
> going to hardcode the location, since backup does not by default have
> its PATH set to /usr/sbin... etc., and try again.  I'm also wondering if

Hmm, configure should have tested the location of volutil and
substituted that into the client-src/calcsize.coda.sh.in file.

Maybe configure falls back to simply using 'volutil' if it couldn't find
the binary. In that case you might have the wrong path in the
sendbackup-coda.c binary code as well. Which means that you can now
estimate the size of the backup, but still not dump it.

> the backup user has the correct permissions to be allowed to export
> data, etc. from coda volumes?

That is totally controlled by the 'knowledge' of the contents of
/vice/db/volutil.tk. Simply make it accessible to the same group as the
backup program. I saw that you managed to figure that one out.

(I guess there are some steps that I take for granted that might need
some further documentation here ;)

> Jan, are you perhaps running amanda as root and not as a backup (or
> other) user?  Or had you already done something similar (or completely
> different) to allow the backup user access to volutil information?

    chgrp backup /vice/db/volutil.tk
    chmod 640 /vice/db/volutil.tk

In fact, if the backup server is a separate machine people would have to
copy this file from the actual servers.

On Wed, Feb 25, 2004 at 01:37:44PM -0500, Greg Troxel wrote:
>   Apparently, backup cannot see the volutil command in its PATH.  I'm
>   going to hardcode the location, since backup does not by default have
>   its PATH set to /usr/sbin... etc., and try again.
> 
> [warning: talking without having read all the code]
> I believe that programs like this should have fully qualified paths
> compiled in using $(prefix) from configure time.  But I think debian
> doesn't like this, and there is some notion of run-time moving of
> trees (hence the no-rpath rule).

The configure test defaults to the unqualified 'volutil', it looks like
it searches by default in,
    /bin:/usr/bin:/sbin:/usr/sbin:/usr/ucb:/usr/bsd:/etc:/usr/etc:$libexecdir:$PATH:/usr/local/sbin:/usr/local/bin

Which covers a lot of ground. Most of the other tests for binaries are
using the same search path, but have an empty default substitution. I
guess they use that to disable the related code. f.i. if tar isn't
found, don't allow tar-style backups or something.

>   I'm also wondering if
>   the backup user has the correct permissions to be allowed to export
>   data, etc. from coda volumes?
> 
> backup/volutil seems to want to be root (I haven't managed to get it
> to work, but I only tried for 5 minutes).  If true, the amandaish
> solution is to have a run-codabackup program that is suid - see
> libexec/runtar in amanda's $(prefix).

Nope, just needs access to /vice/db/volutil.tk, which normally is only
accessible by root.


btw. the version number for Debian packages built from what is currently
in CVS should be,

    amanda-2.4.4p2-1.coda

I tested the client code on one server during last night's backups and
that worked. The Coda changes should not be terribly invasive and except
for the configuration file parser and the common-src/protocol.c bugfix
are client-side only.

Jan