On Tuesday 01 July 2003 22:59, Michael D. Schleif wrote:
>Also sprach Jay Lessert (Tue 01 Jul 02003 at 07:45:50PM -0700):
>> On Tue, Jul 01, 2003 at 09:08:33PM -0500, Michael D. Schleif wrote:
>> > Of course, I have tried every combination of hostname and
>> > address in disklist, and also made certain that that name there
>> > is the _same_ as that used in amandahosts:
>> >
>> > # bragi.private.network sda1 comp-root
>> > # bragi.private.network sda4 comp-user
>> > 192.168.123.150 sda1 comp-root
>> > 192.168.123.150 sda4 comp-user
>> > # localhost sda1 comp-root
>> > # localhost sda4 comp-user
>>
>> Report the problem using a single configuration that you believe
>> should work. In this case, I'm not sure what what would be.
>
>OK, I understand your perplexity; however, I started with the
> default localhost, moved to simply bragi, then
> bragi.private.network, and finally to it ip address -- *ALL*
> exhibited identical behaviour, as far as I can see.
>
>So, please, help me by telling me which configuration that you want
> to see documented, and what output you want to see from that
> configuration. I will gladly supply the data, if you can help me
> resolve this problem.
>
>> Do you really have a DNS server that resolves ".network" as a TLD?
>
>Yes, I run tinydns on this private network.
>
>> > # ping bragi
>> > PING Bragi.private.network (192.168.123.150): 56 data bytes
>>
>> ^
>> -------- Is the "Bragi" (not "bragi") real, or some sort of typo?
>
>OK, bragi is Bragi in dns; but, name resolution, by rfc, is case
>insensitive.
>
>> > Everywhere, I see the strong warnings against using localhost.
>> > With Debian, localhost is the default used in disklist. Why
>> > this adversity for localhost?
>>
>> It is a bad idea IMO, 1) because the reverse lookup will often
>> fail, 2) because "localhost" in the amanda records is not very
>> self-documenting.
>>
>> There are lots of things in default setups that are bad.
>
>Yes, of course. Nevertheless, some newbies want to know the reason
> why . . .
>
>P.S., Is there some reason that you do not want your participation
> in this thread posted to the mailing list?
Somewhere back up the line in this thread I noticed 2 things, first it
appears that you may be running a prebuilt binary since all the
messages in that amandad.dateofrun.debug file you posted some of seem
to indicate an erroniously configured build, particularly its use of
localhost. Backed up by the fact that its by now a fairly old
version.
While there is nothing to prevent your use of 'backup' as a user,
there may be side effects that I'm not aware of because I've not
personally tried that. The user who runs amanda is IMO, best as
amanda, so one really should add such a user, just to reduce
interactions by making the amanda user unique. And to give that
user the perms it needs, it should be a member of group 'backup' or
'disk', depending on which exists on your system in the /etc/group
file.
So let me suggest you remove that installation and do this:
'adduser amanda' & give her some password you can remember, but since
you will always come from root, that might be the last time you use
it.
That line in /etc/passwd should look something like this:
amanda:x:33:6:Amanda user:/home/amanda:/bin/bash
If you make amanda a member of the group 'disk' then that line in
/etc/group should resemble this:
disk:x:6:amanda,root
Go to www.amanda.org, and pull down to the bottom of the page where
you can find the link to the latest snapshots, click on it and get
the amanda-2.4.4p1-20030627.tar.gz package, having your browser put
it in /home/amanda.
'cd /home/amanda'
'su amanda'
'tar xzvf amanda-2.4.4p1-20030627.tar.gz'
save the attached 'gh.cf' file to /home/amanda
Edit this file to substitute your servers FQDN, and fix anything else
that might need fixed for your site, like the path to the config
directory. Rename it so its "your".cf. This then becomes the
permanent master configuration for amanda, useable till the sun runs
out of hydrogen unless the authors really do change things a lot.
Now, cp it into the directory created by the archive unpacking, using
cp so you leave that permenent copy behind for the next snapshots
build.
'cd amanda-2.4.4p1-20030627'
'./your.cf'
which will run thru the configuration and building of amanda for your
site. It takes maybe 5 minutes on my machine.
'exit'
which will take you back to root.
cd amanda-2.4.4p1-20030627
'make install'
Now you should have an amanda install that isn't boRken, and can be
adjusted with amanda.conf, the disklist, etc to be fully functional.
Since amanda's default dir is /usr/local/etc/amanda for the configs
dir, and /usr/local/var/amanda for the records, you may want to
adjust this, or just move your older configs to this new location if
you ran the script without editing that.
Now, /etc/inetd. I've not had a linux old enough to use that in what,
2 years? So you may have to adjust the paths and users in those
lines of inetd to be the correct path and user now. I'm also not too
sure that I'd use the tcpd wrapper for the local stuffs either, based
on that, in amandas case, is just something else to have to fool
with.
If you were to be using xinetd, then the attached 'amanda' file placed
in /etc/xinetd.d would be how its done.
Fix your /home/amanda/.amandahosts file to use the FQDN's of the
server and clients, one per line. On the clients, I *think* all they
need is the servers FQDN and user. And there you will need a line
for localhost too for recovery useages. The proper perms for this
file are said to be 0600. It will work with more open settings,
thats just for security. It should of course be owned by amanda:disk
if using that user:group.
If all that has been done, then you really should be ready to do:
"su amanda -c 'amcheck configname'"
Ignore the notes, and fix the errors till there aren't anymore.
At that point, you should be able to 'su amanda', 'crontab -e', and
install the line that actually runs amanda every night or whatever
schedule you want.
When first starting amanda, give her scheduler some help by
restricting the disklist to only a tapes worth, then add that much
more before it runs again the next night, etc till the disklist is
fully enabled. Amanda will send you email telling you how she did
after she is done.
I hope this helps. I don't normally go into this much detail, partly
because there really is more than one way to skin that cat, but you
are fighting with a broken build, and this one 'works a treat' here.
Running as I type in fact, its that time of the night.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.26% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
gh.cf
Description: application/shellscript
amanda
Description: Text document
|
