On Wed, Feb 18, 2009 at 3:06 PM, stan <stanb AT panix DOT com> wrote:
> OK, now we have uncovered what is probably the root cause of my problems:

Yay!

> It exists and seems to have a set of permissions that I would think would
> work.

Try running 'ldd' on it -- perhaps it cannot find the amanda libraries
it links against?

> Can I also register a concern? In the past, we have done work where we created
> our own perl modules. One of the problems with that is that when you
> upgrade perl, you have to go back and recreate all your own perl modules,
> because perl puts these in a directory that is specific to the version. So,
> for example on the Ubuntu server, I may accidently break Amanda, just by
> doing an apt-get upgrade to isntall a fixed perl :-(

Yeah, this is something we've put some thought into.  This is the sort
of problem that package-management systems should, and have, solved.
If you are installing with debs, then the Amanda deb will depend on
the version of perl you have installed.  If you upgrade that, you'll
need to upgrade your Amanda package, too.  If you're installing from
source, you can use --with-amperldir to put the Amanda perl libraries
elsewhere, although I don't know how reliably
forward-binary-compatible perl is.

> Also, we have clients with no perl installed on them. Is the use of perl
> confined to the server? Some of the clients are old versions of Solaris,
> HP-UX, etc. and we can't change them because they are production machines
> in an industrial manufacturing environment. If they won't work with 2.6.1
> we might have to backtrack to 2.5.2 (or 2.5.1).

You'll need to stick to older versions of Amanda for such systems, or
install a "private" copy of perl against which you build Amanda.

Dustin

-- 
Storage Software Engineer
http://www.zmanda.com