Kermit Short wrote:
Thanks, Paul, for your helpful responses! As you requested, I've tried
to run the amadmin command but it seems this version doesn't know that
parameter of amadmin:
[EMAIL PROTECTED]:~$ amadmin DailySet1 config
amadmin: unknown command "config"
Oops, my mistake... I meant:
/usr/sbin/amadmin xx version
However, as this is a binary package, I'm not entirely certain of all
the options used to build it. The package notes indicate that the
"Amanda User" is backup with group backup.
And verify if "backup" is indeed what was compiled in the configure
options by the command above.
Then also make sure that "backup" is not a duplicate user in the
password file!
And as general list of things to check, see:
http://wiki.zmanda.com/index.php/Selfcheck_request_failed
The permissions for the amandahosts file are:
-rw-rw---- 1 backup backup 120 2008-01-21 22:06 amandahosts
Better make that 400, instead of 660.
There is indeed a /tmp/amanda directory as follows, but it is empty.
Permissions, as you see, are set correctly.
drwx--S--- 2 backup backup 4096 2008-01-23 00:45 amanda
That is a weird problem!!!
Try to remove that directory. It will be created automatically
next time amandad runs.
Try to run the command "amandad" manually. It should stop
after 30 seconds (unless you type some garbage, and then it stops
immediatly).
Verify if xinetd starts amandad when connected to the port with netcat:
nc -u localhost 10080
and verify in another window if the binary amandad runs. If you
do not type anything amandad will exit after 30 seconds.
Any other messages in the syslog output of xinetd or other places ?
Neither root nor backup users on the system are receiving mail from the
amanda process, failure notices or otherwise. With no helpful logs or
other output, I can't tell where things are failing, so if anyone has
any gotchas, I'd love to hear about it! Thanks for the help Paul!
-Kermit
Paul Bijnens wrote:
On 2008-01-23 04:40, Kermit Short wrote:
Hey gurus!
I've checked many many resources about this error and I've done
just about everything they've asked, but I can't get rid of it, and I
don't really even know if it's a show stopper or not. Here's my
situation:
[...]
backup set name. In installing/configuring the client, I've done the
following:
customized the /etc/amandahosts (symlinked by ~backup/.amandahosts)
especially here: are the permissions of this file correct?
Is that path up top ~backup/.amandahosts secure (not writeable by anone
but root or backup-user?)
customized the /etc/hosts.allow for the amandad, amindexd, and
amidxtaped daemons
customized the /etc/services to register the 3 above daemons as
services for the xinetd superserver
created a drop file in /etc/xinetd.d with the standard recommended
parameters and restarted the xinetd superserver
OK. we have to believe you that you did not make any error in there.
We cannot verify that part of the setup.
something that wasn't mentioned on any of the FAQs and mail lists was
to change the group on the 3 above daemons to the backup group (the
group
"the 3 above daemons???" which ones?
That also seems to imply that you have a discrepancy between the
username that is compiled into the executable ( with the configure
option --with-user=...) and the one that you use to run the set
of programs. They should match!
What is the output of "amadmin xx config"
and look at the expected username, in the configure options.
specified for the backup user which will be the user running amanda)
IPTABLES is not running on this host, so it isn't a firewall issue,
unless the port calls go running about the LAN rather than staying
internal, which I can't imagine is happening.
netstat -a |grep amanda reports the following:
tcp 0 0 *:amandaidx *:*
LISTEN
udp 0 0 zeus.chaos.short:amanda *:*
Obviously the output has concatenated my FQDN, but Iwhat I don't
know, is if those are all the services that should be listening, and
whether those are the correct protocols that they are listening to.
seems ok.
Thus, I've done rather a lot of research to get this running, and
that's not including the many days spent ironing out the kinks in the
server issues. This one has me stumped, as the error logs don't even
make a peep that something in the system is even running, much less
failing...
Any help that anyone could provide would be deeply appreciated.
After all, as they say, backups are like wives...you don't realize
how important they were until you don't have them anymore!
Look at the debug files on the client in /tmp/amanda?
If there are no files at all, then maybe the directory /tmp/amanda
itself is not writeable by the backupuser, e.g. because you once
have run some program as root (and then /tmp/amanda gets created
as user root, making it unwritable for the real backup user).
--
Paul Bijnens, xplanation Technology Services Tel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM Fax +32 16 397.512
http://www.xplanation.com/ email: [EMAIL PROTECTED]
***********************************************************************
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***********************************************************************