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 [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 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
# default = off
#
# description: Part of the Amanda server package
# This is the list of daemons & such it needs
service amanda
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = amanda
group = disk
groups = yes
server = /usr/local/libexec/amandad
}
service amandaidx
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = amanda
group = disk
groups = yes
server = /usr/local/libexec/amindexd
}
service amidxtape
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = amanda
group = disk
groups = yes
server = /usr/local/libexec/amidxtaped
}
