(Illustration by Gaich Muramatsu)
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. JanReceived on 2004-02-25 14:04:40