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.
