On Wednesday 12 April 2006 06:27, stan wrote:
>On Wed, Apr 12, 2006 at 12:40:32AM -0400, Gene Heskett wrote:
>> On Tuesday 11 April 2006 18:04, stan wrote:
>> >On Tue, Apr 11, 2006 at 04:46:38PM -0400, Gene Heskett wrote:
>> >> On Tuesday 11 April 2006 13:23, stan wrote:
>> >> >On Tue, Apr 11, 2006 at 12:34:17PM -0400, Gene Heskett wrote:
>> >> >> On Tuesday 11 April 2006 11:59, stan wrote:
>> >> >> >I'm setting up a new Ubuntu box as my next generation Amanda
>> >> >> > server. Somehow the /etc/hosts file for this machine was
>> >> >> > created looking like this:
>> >>
>> >> FQDN's or addresses, but see below.
>> >>
>> >> >BTW, hostname returns "amanda", not the FQDN. I geuss I could
>> >> > change /etc/hostname to the FQDN if needed.
>> >>
>> >> Yes, 'hostname' should return the FQDN.  Here I don't use a dns
>> >> server for local stuff, just the /etc/hosts files on all
>> >> machines. And each FQDN also has a one word alias that works just
>> >> fine for such things as disklist entries.  It also works for that
>> >> script of mine, but I cleaned that up for public comsumption as
>> >> its not always going to work for everyone if they're using a dns
>> >> & no hosts file.
>> >>
>> >> FWIW my tar isn't that one either, I'm using a locally built
>> >> 1.15-1 installed in /usr/local/bin, with that line suitably
>> >> modifed.
>> >
>> >OK, I corected my /etc/hosts file as shown above. Now, when I run a
>> > dump it seems to go OK (went to hloding disk, but when it finishes
>> > I expect to find a tape name problem.
>> >
>> >However, on the Amanda server itself / was backed up, but to other
>> > partions in the disklist failed to estimate. and amcheck claims it
>> > can't read the gnutar exclude file. Permissions on all of these
>> > seem OK, and were working before I messed with /etchosts, the
>> > first time.
>> >
>> >Sugestions?
>>
>> You did build amanda as a unpriviledged (uid>500) user, and then
>> become root to install her, followed by a run of ldconfig, also as
>> root?  This sound like a permissions problem, and not doing the
>> above is probably 90% of the permissions problems genesis moment. 
>> This unpriviledged user, and I use amanda for that, also needs to be
>> a member of the group 'disk' or possibly 'backup' in order to
>> function nominally.
>
>Again, I've never done that in the past. I've just made ceratin that
> the amanda user exists, and done the build/make install as root.
> Permissions have alwasy been fine.

They should not have been, ever, when doing it that way.

>Having sad that, I'll rebuild the whole thing today using FQDB's, and
> building as amanda, then installing as root.
>
>BTW, speaking of rebuilding amanda, it would be nice if there were a
> "make no-overwrite confgis" option.

It doesn't ever overwrite your existing amanda.conf, nor any other file 
in your /config/ directory.

Now if you are refering to the arguments passed to the ./configure 
program, thats another story, best carved into a script you execute to 
do the ./configure and make steps.  I use one here, it hasn't changed 
in over a year now, and I posted it here just in the past week in case 
someone needed a template to use as an example.  Because configuration 
arguments CAN be forgotten, and WILL be forgotten, the script method is 
a serious butt saver and I wouldn't consider doing without it.

>I'll bet you lunch this does not fix my problem though. But it's worth
> a try.

I'm reminded of the lines displayed rather prominantly on the cover of 
the manual of what was pretty close to the first *decent* consumer 
audio tape recorder marketed in the middle 1950's here in the states, 
the Bell RT-7, where it said:

   PLEASE try our way first!

:-)

-- 
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules.  I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.