On Tuesday 22 July 2003 16:12, Kurt Yoder wrote:
>Hello list
According to my mailer, you sent this to the owner-amanda-users list,
which is the list admin, so I've added a Cc: to the list itself.
>I just compiled amanda on a SCO Unix machine (uname -a shows "SCO_SV
>shcorp 3.2 5.0.6 i386") and tried to follow instructions to install
>it, instructing amanda to back up both of its disks. Everything
>appears successful, and the machine passes amcheck tests. When I run
>amdump at night, my other linux, freebsd, and windows machines dump
>successfully. However on my SCO machine, I get the message:
>
>shcorp.shc /stand lev FAILED [disk /stand offline on
>shcorp.shcorp.com?]
>shcorp.shc / lev FAILED [disk / offline on shcorp.shcorp.com?]
>
>I've looked in google, and found the following suggestions:
>
>(from faq-o-matic,
>http://amanda.sourceforge.net/fom-serve/cache/10.html)
>
>is disk really offline?
>Answer appears to be no. After all, I'm using this machine
>throughout the day. So I'd assume it should be available for backup,
>since no-one touches the machine at night.
>
>filesystem error?
>Well, I suppose there *could* be. But the fact that it happens on
>both disks seems to indicate that this is not the problem. (I also
>installed the same compiled version on a separate sco machine, and
>it does the exact same thing).
>
>filesystem too large?
>Does not seem to be. /stand is only 15 megabytes, but still fails.
>
>conflicting user name?
>Doesn't seem to be it. I configured with user "backup". This only
>shows up once in the passwd file, and this box does not have any
>external sources for authentication (no nis, ldap, etc)
>
>don't have dump installed?
>This isn't it. I compiled by hand, and the config.log shows that
>amanda found the dump program. I suppose it could conceivably be
>something that amanda doesn't like about SCO's dump program though.
>How can I check if this might be the problem?
>
>(from an archived post:
>http://groups.yahoo.com/group/amanda-users/message/40200)
>permissions on /etc/fstab ok?
>On SCO, the file seems to be /etc/mnttab. It is unix mode 644, so
>this shouldn't be a problem.
>
>
>
>So, I looked at the logs in /tmp/amanda. For the last failed dump, I
>see these logs:
>
>-rw------- 1 root backup 231 Jul 22 00:30
>killpgrp.20030722043007.debug
>-rw------- 1 root backup 231 Jul 22 00:30
>killpgrp.20030722043009.debug
>-rw------- 1 root sys 2108 Jul 22 00:30
>sendsize.20030722003007.debug
>-rw------- 1 root sys 2275 Jul 22 00:30
>amandad.20030722003005.debug
>
>(strange that these are owned by root instead of backup; is this a
>problem?)
Yes, this does look like a problem, at least for this linux user it
would be.
On linux, one should have an unpriveledged user such as 'amanda' (your
'backup' maybe?), who is a member of a high level group such as
'disk' (your 'sys' maybe?).
You should be this user when you unpack, configure and build the
archive so that all the owner:group stuffs are set correct, in my
case to amanda:disk for everything.
Then you become root before typing 'make install', which then sets all
the perms correctly as its being installed.
It is also this user's crontab that the amdump program is run from,
not roots crontab.
How much of this can be directly translated to solaris, I'll leave to
Jon.
Here, in the /usr/local/var/amanda directory where all the indices
from this activity is kept, it is 100% amanda:disk for the
owner:group of all files. Here on my system there was at one time an
'amanda-debug' directory, IIRC in /var, but its apparently no longer
being kept. I found that all files in it were a year+ old, and rm'd
it some time back. Amanda hasn't complained, and its logging names
do not contain the word debug.
It is known that amdump will refuse to run if root tries to run it,
but this doesn't quite walk like that duck to me.
>sendsize ends with
>----------------------------------------------------------------
>sendsize[1383]: time 2.300: child 1388 terminated normally
>sendsize: time 2.300: pid 1383 finish time Tue Jul 22 00:30:10 2003
>----------------------------------------------------------------
>Looks ok to me
>
>amandad ends with
>----------------------------------------------------------------
>amandad: time 4.281: got packet:
>----
>Amanda 2.4 ACK HANDLE 00E-00A00608 SEQ 1058848217
>----
>
>amandad: time 4.281: pid 1382 finish time Tue Jul 22 00:30:10 2003
>----------------------------------------------------------------
>seems fine, or?
>
>first killpgrp
>----------------------------------------------------------------
>killpgrp: debug 1 pid 1386 ruid 19 euid 0: start at Tue Jul 22
>04:30:07 2003
>/usr/local/libexec/killpgrp: version 2.4.4
>killpgrp: error [cannot find user root in passwd file]
>killpgrp: pid 1386 finish time Tue Jul 22 04:30:07 2003
>----------------------------------------------------------------
>
>second killpgrp
>----------------------------------------------------------------
>killpgrp: debug 1 pid 1389 ruid 19 euid 0: start at Tue Jul 22
>04:30:09 2003
>/usr/local/libexec/killpgrp: version 2.4.4
>killpgrp: error [cannot find user root in passwd file]
>killpgrp: pid 1389 finish time Tue Jul 22 04:30:09 2003
>----------------------------------------------------------------
>
>Weird errors here. The root user is definitely in the passwd file.
>Could this be part of the problem?
>
>Thanks for any ideas on fixing this...
Jon? Your turn :)
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.27% 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.
|
