Re: amrecover failing

2014-07-19 Thread Trever L. Adams
On 07/19/2014 01:13 PM, John Hein wrote:
> Trever L. Adams wrote at 05:49 -0600 on Jul 19, 2014:
>  > Hello everyone,
>  >
>  > So, I am not quite sure what is going on. When I try to do an amrecover,
>  > I get the following:
>  >
>  > Load tape normal149 now
>  > Continue [?/Y/n/s/d]? Y
>  > Got no header and data from server, check in amidxtaped.*.debug and
>  > amandad.*.debug files on server
>  >
>  > The logs hold such things as:
>  >
>  > Sat Jul 19 05:45:39 2014: thd-0x1a16a00: amidxtaped: warning: Can't exec
>  > "-eo": No such file or directory at
>  > /usr/lib64/perl5/vendor_perl/Amanda/Process.pm line 176.
>  >
>  > Sat Jul 19 05:45:39 2014: thd-0x1a16a00: amidxtaped: critical (fatal):
>  > -eo pid,ppid,command: No such file or directory at
>  > /usr/lib64/perl5/vendor_perl/Amanda/Process.pm line 176.
>  >
>  > amidxtaped:  -eo pid,ppid,command: No such file or directory at
>  > /usr/lib64/perl5/vendor_perl/Amanda/Process.pm line 176.
>  >
>  > /lib64/libamanda-3.3.3.so(+0x2b727)[0x7f3e7d9d0727]
>  > /lib64/libglib-2.0.so.0(g_logv+0x209)[0x7f3e7d6c9429]
>  > /lib64/libglib-2.0.so.0(g_log+0x8f)[0x7f3e7d6c963f]
>  > 
> /usr/lib64/perl5/vendor_perl/auto/Amanda/MainLoop/libMainLoop.so(+0x4925)[0x7f3e7c5ad925]
>  > /lib64/libglib-2.0.so.0(+0x3f89449e43)[0x7f3e7d6c2e43]
>  > /lib64/libglib-2.0.so.0(g_main_context_dispatch+0x166)[0x7f3e7d6c22a6]
>  > /lib64/libglib-2.0.so.0(+0x3f89449628)[0x7f3e7d6c2628]
>  > /lib64/libglib-2.0.so.0(g_main_loop_run+0x6a)[0x7f3e7d6c2a3a]
>  > 
> /usr/lib64/perl5/vendor_perl/auto/Amanda/MainLoop/libMainLoop.so(_wrap_run_c+0x50)[0x7f3e7c5adca0]
>  > /lib64/libperl.so.5.18(Perl_pp_entersub+0x5c6)[0x3008ec33e6]
>  > /lib64/libperl.so.5.18(Perl_runops_standard+0x2e)[0x3008ebb81e]
>  > /lib64/libperl.so.5.18(perl_run+0x300)[0x3008e52d40]
>  > /usr/bin/perl[0x400d29]
>  > /lib64/libc.so.6(__libc_start_main+0xf5)[0x3f86c21d65]
>  > /usr/bin/perl[0x400d61]
>  >
>  >
>  > This is also not 100% consistent. I got it to do a restore once. Doing
>  > the same steps with the same disk and date will not restore, it is all
>  > the above.
>  >
>  > Any ideas?
>
> Looks like there was some build problem perhaps and $PS is not defined
> in Constants.pm
>
> locate Constants.pm | grep Amanda | xargs grep -i ps
> =head1 SYNOPSIS
> $PS = "/bin/ps";
> $PS_ARGUMENT = "-eo pid,ppid,command";
>
>
Thank you! That was it. I will be filing this with Fedora for a rebuild.

Thanks again,
Trever



signature.asc
Description: OpenPGP digital signature


Re: amrecover failing

2014-07-19 Thread John Hein
Trever L. Adams wrote at 05:49 -0600 on Jul 19, 2014:
 > Hello everyone,
 >
 > So, I am not quite sure what is going on. When I try to do an amrecover,
 > I get the following:
 >
 > Load tape normal149 now
 > Continue [?/Y/n/s/d]? Y
 > Got no header and data from server, check in amidxtaped.*.debug and
 > amandad.*.debug files on server
 >
 > The logs hold such things as:
 >
 > Sat Jul 19 05:45:39 2014: thd-0x1a16a00: amidxtaped: warning: Can't exec
 > "-eo": No such file or directory at
 > /usr/lib64/perl5/vendor_perl/Amanda/Process.pm line 176.
 >
 > Sat Jul 19 05:45:39 2014: thd-0x1a16a00: amidxtaped: critical (fatal):
 > -eo pid,ppid,command: No such file or directory at
 > /usr/lib64/perl5/vendor_perl/Amanda/Process.pm line 176.
 >
 > amidxtaped:  -eo pid,ppid,command: No such file or directory at
 > /usr/lib64/perl5/vendor_perl/Amanda/Process.pm line 176.
 >
 > /lib64/libamanda-3.3.3.so(+0x2b727)[0x7f3e7d9d0727]
 > /lib64/libglib-2.0.so.0(g_logv+0x209)[0x7f3e7d6c9429]
 > /lib64/libglib-2.0.so.0(g_log+0x8f)[0x7f3e7d6c963f]
 > /usr/lib64/perl5/vendor_perl/auto/Amanda/MainLoop/libMainLoop.so(+0x4925)[0x7f3e7c5ad925]
 > /lib64/libglib-2.0.so.0(+0x3f89449e43)[0x7f3e7d6c2e43]
 > /lib64/libglib-2.0.so.0(g_main_context_dispatch+0x166)[0x7f3e7d6c22a6]
 > /lib64/libglib-2.0.so.0(+0x3f89449628)[0x7f3e7d6c2628]
 > /lib64/libglib-2.0.so.0(g_main_loop_run+0x6a)[0x7f3e7d6c2a3a]
 > /usr/lib64/perl5/vendor_perl/auto/Amanda/MainLoop/libMainLoop.so(_wrap_run_c+0x50)[0x7f3e7c5adca0]
 > /lib64/libperl.so.5.18(Perl_pp_entersub+0x5c6)[0x3008ec33e6]
 > /lib64/libperl.so.5.18(Perl_runops_standard+0x2e)[0x3008ebb81e]
 > /lib64/libperl.so.5.18(perl_run+0x300)[0x3008e52d40]
 > /usr/bin/perl[0x400d29]
 > /lib64/libc.so.6(__libc_start_main+0xf5)[0x3f86c21d65]
 > /usr/bin/perl[0x400d61]
 >
 >
 > This is also not 100% consistent. I got it to do a restore once. Doing
 > the same steps with the same disk and date will not restore, it is all
 > the above.
 >
 > Any ideas?

Looks like there was some build problem perhaps and $PS is not defined
in Constants.pm

locate Constants.pm | grep Amanda | xargs grep -i ps
=head1 SYNOPSIS
$PS = "/bin/ps";
$PS_ARGUMENT = "-eo pid,ppid,command";



amrecover failing

2014-07-19 Thread Trever L. Adams
Hello everyone,

So, I am not quite sure what is going on. When I try to do an amrecover,
I get the following:

Load tape normal149 now
Continue [?/Y/n/s/d]? Y
Got no header and data from server, check in amidxtaped.*.debug and
amandad.*.debug files on server

The logs hold such things as:

Sat Jul 19 05:45:39 2014: thd-0x1a16a00: amidxtaped: warning: Can't exec
"-eo": No such file or directory at
/usr/lib64/perl5/vendor_perl/Amanda/Process.pm line 176.

Sat Jul 19 05:45:39 2014: thd-0x1a16a00: amidxtaped: critical (fatal): 
-eo pid,ppid,command: No such file or directory at
/usr/lib64/perl5/vendor_perl/Amanda/Process.pm line 176.

amidxtaped:  -eo pid,ppid,command: No such file or directory at
/usr/lib64/perl5/vendor_perl/Amanda/Process.pm line 176.

/lib64/libamanda-3.3.3.so(+0x2b727)[0x7f3e7d9d0727]
/lib64/libglib-2.0.so.0(g_logv+0x209)[0x7f3e7d6c9429]
/lib64/libglib-2.0.so.0(g_log+0x8f)[0x7f3e7d6c963f]
/usr/lib64/perl5/vendor_perl/auto/Amanda/MainLoop/libMainLoop.so(+0x4925)[0x7f3e7c5ad925]
/lib64/libglib-2.0.so.0(+0x3f89449e43)[0x7f3e7d6c2e43]
/lib64/libglib-2.0.so.0(g_main_context_dispatch+0x166)[0x7f3e7d6c22a6]
/lib64/libglib-2.0.so.0(+0x3f89449628)[0x7f3e7d6c2628]
/lib64/libglib-2.0.so.0(g_main_loop_run+0x6a)[0x7f3e7d6c2a3a]
/usr/lib64/perl5/vendor_perl/auto/Amanda/MainLoop/libMainLoop.so(_wrap_run_c+0x50)[0x7f3e7c5adca0]
/lib64/libperl.so.5.18(Perl_pp_entersub+0x5c6)[0x3008ec33e6]
/lib64/libperl.so.5.18(Perl_runops_standard+0x2e)[0x3008ebb81e]
/lib64/libperl.so.5.18(perl_run+0x300)[0x3008e52d40]
/usr/bin/perl[0x400d29]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x3f86c21d65]
/usr/bin/perl[0x400d61]


This is also not 100% consistent. I got it to do a restore once. Doing
the same steps with the same disk and date will not restore, it is all
the above.

Any ideas?

Thank you,
Trever




signature.asc
Description: OpenPGP digital signature


Re: amrecover failing

2004-12-10 Thread Paul Bijnens
Dunc wrote:
John E Hein wrote:
Dunc wrote at 12:08 + on Dec  9, 2004:
 >  > amrestore: could not open /dev/nrsa0: Permission denied
...
 >  > Which completely baffles me because,
 >  > a) the amdump can use the tape drive fine, as can amrestore
 > b) the amanda user is in the operator group, and the operator group 
has  > rw permissions on /dev/nrsa0
 > c) I've tried su'ing to amanda, and trying to access the tape drive 
and  > that is also fine.

You should run amrecover as root so the files get extracted with the
right ownership & permissions.
That said, the permission problem on the tape device is something
else.  You probably aren't accessing the tape drive as the user that
you think you are (which is not necessarily the same user that ran
amrecover).  Look for the amidxtaped entry in /etc/inetd.conf and see
what user you've specified.

I was running amrecover as root.
I checked my xinetd, and I had the index daemons running as the amanda 
user, I swapped them to root instead, and it does work now, many many 
thanks.

I still don't understand why though. As I said before, the amanda user 
is allowed to access the tape drive, I checked that.
The group "operator" is probably not the primary group as found in
/etc/passwd. And you probably forgot the "groups = yes" directive
in the xinetd.conf file for amidxtape.  When omited, you don't have
the additional groups permissions, only the primary group from
/etc/passwd.  Could this have been the problem?
Running as root solves this.
Also, after 
swapping xinetd so that they are run as root from xinetd, when i check 
the process list, it says that amindexd and amidxtaped are both running 
as amanda anyway. So what's going on here?
If the macro FORCE_USERID is defined when compiling, the program does
indeed detect if it is running as root, and switches to amanda itself,
as you noticed.  And when switching itself, it does take the additional
groups into account.
You can see de defs from the compile time with:
$ amadmin x version
...
CLIENT_LOGIN="amanda" FORCE_USERID HAVE_GZIP
...
The only thing that seems to make sense is that they try and switch to 
the amanda user blindly, even if it already is the correct user?
Only when root.
I'd like to know what's going on just for completeness if anyone knows, 
but at least it's working now, and thanks again John :)
--
Paul Bijnens, XplanationTel  +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax  +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, *
* kill -9 1,  Alt-F4,  Ctrl-Alt-Del,  AltGr-NumLock,  Stop-A,  ...*
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out  *
***



Re: amrecover failing

2004-12-09 Thread Dunc
John E Hein wrote:
Dunc wrote at 12:08 + on Dec  9, 2004:
 > I wasn't sure if this was a hackers or users mail, so I sent to to both 
 > lists. Hope this is ok

users
ok

 > But, when I try to use amrecover, it's all fine while I'm doing the 
 > sethost, setdisk etc. I can even browse the virtual FS and see add the 
 > files ready for restore, but when I come to try and run the extract 
 > command, this happens.
 > 
 > Load tape ffhs-daily16 now
 > Continue [?/Y/n/t]?
 > EOF, check amidxtaped.debug file on ngidnoc.
 > amrecover: short block 0 bytes
 > UNKNOWN file
 > amrecover: Can't read file header
 > extract_list - child returned non-zero status: 1
 > Continue [?/Y/n]?
 > amrecover>
 > 
 > I checked the faq-o-matic, and found this error, but it suggests the 
 > tape isn't rewound, and it definately is, because I tried again after 
 > reading that just to make sure.
 > 
 > So, I look in the logfile, and see this:
 > 
 > amrestore: could not open /dev/nrsa0: Permission denied
 > amidxtaped: time 0.096: amrestore terminated normally with status: 2
 > amidxtaped: time 0.097: rewinding tape ...
 > amidxtaped: time 0.097: tape_rewind: tape open: /dev/nrsa0: Permission 
 > denied
 > amidxtaped: time 0.097: pid 85649 finish time Wed Dec  8 17:12:32 2004
 > 
 > Which completely baffles me because,
 > 
 > a) the amdump can use the tape drive fine, as can amrestore
 > b) the amanda user is in the operator group, and the operator group has 
 > rw permissions on /dev/nrsa0
 > c) I've tried su'ing to amanda, and trying to access the tape drive and 
 > that is also fine.

You should run amrecover as root so the files get extracted with the
right ownership & permissions.
That said, the permission problem on the tape device is something
else.  You probably aren't accessing the tape drive as the user that
you think you are (which is not necessarily the same user that ran
amrecover).  Look for the amidxtaped entry in /etc/inetd.conf and see
what user you've specified.

I was running amrecover as root.
I checked my xinetd, and I had the index daemons running as the amanda 
user, I swapped them to root instead, and it does work now, many many 
thanks.

I still don't understand why though. As I said before, the amanda user 
is allowed to access the tape drive, I checked that. Also, after 
swapping xinetd so that they are run as root from xinetd, when i check 
the process list, it says that amindexd and amidxtaped are both running 
as amanda anyway. So what's going on here?

The only thing that seems to make sense is that they try and switch to 
the amanda user blindly, even if it already is the correct user?

I'd like to know what's going on just for completeness if anyone knows, 
but at least it's working now, and thanks again John :)

Cheers,
Dunc


Re: amrecover failing

2004-12-09 Thread Dunc
Hi all,
I wasn't sure if this was a hackers or users mail, so I sent to to both 
lists. Hope this is ok

I've been trying to restore a few files from an amanda backup, amanda 
version 2.4.3b4 on freebsd 4.9

i'm using a SCSI DDS-4 drive
also, i use the comp-root-tar backup method
the dump works fine, and if i use amrestore -p | tar -tvf  I can see 
that the files are indeed there.

But, when I try to use amrecover, it's all fine while I'm doing the 
sethost, setdisk etc. I can even browse the virtual FS and see add the 
files ready for restore, but when I come to try and run the extract 
command, this happens.

Load tape ffhs-daily16 now
Continue [?/Y/n/t]?
EOF, check amidxtaped.debug file on ngidnoc.
amrecover: short block 0 bytes
UNKNOWN file
amrecover: Can't read file header
extract_list - child returned non-zero status: 1
Continue [?/Y/n]?
amrecover>
I checked the faq-o-matic, and found this error, but it suggests the 
tape isn't rewound, and it definately is, because I tried again after 
reading that just to make sure.

So, I look in the logfile, and see this:
amrestore: could not open /dev/nrsa0: Permission denied
amidxtaped: time 0.096: amrestore terminated normally with status: 2
amidxtaped: time 0.097: rewinding tape ...
amidxtaped: time 0.097: tape_rewind: tape open: /dev/nrsa0: Permission 
denied
amidxtaped: time 0.097: pid 85649 finish time Wed Dec  8 17:12:32 2004

Which completely baffles me because,
a) the amdump can use the tape drive fine, as can amrestore
b) the amanda user is in the operator group, and the operator group has 
rw permissions on /dev/nrsa0
c) I've tried su'ing to amanda, and trying to access the tape drive and 
that is also fine.

I'm now completely stumped, and would appreciate any help at all. If you 
need any more info, please let me know.

Cheers,
Dunc


Doh! [was Re: amrecover failing ]

2004-10-18 Thread pll+amanda



I forgot to 'settape'.  For some reason I thought this was 
automatically detected from the amanda conf file, but evidently not.



I could have sworn I set amanda up to automatically use my changer 
for this, and upon inspection of the amana.conf file, it appears I 
started.  However, I just found the Faq-O-Matic answer to this 
question, which appears to imply I set this up incorrectly.

I'll have another go at this, thanks a lot, and I apologize for 
wasting anyone's time.
-- 
Seeya,
Paul

GPG Key fingerprint = 1660 FECC 5D21 D286 F853  E808 BB07 9239 53F1 28EE

 If you're not having fun, you're not doing it right!




Re: amrecover failing

2004-10-18 Thread pll+amanda

Thanks for the replies.  Everyone who did so suggested that the tape 
was not rewound.  Unfortunately, that's not case.  I've made sure to 
eject the tape, reload the tape, and run mt -f /dev/st0 rewind, and 
then mt -f /dev/st0 status which shows:

  $ mt -f /dev/st0 status
  drive type = Generic SCSI-2 tape
  drive status = 1107296256
  sense key error = 0
  residue count = 0
  file number = 0
  block number = 0
  Tape block size 0 bytes. Density code 0x42 (unknown).
  Soft error count since last status=0
  General status bits on (4101):
  BOT ONLINE IM_REP_EN


-- 
Seeya,
Paul

GPG Key fingerprint = 1660 FECC 5D21 D286 F853  E808 BB07 9239 53F1 28EE

 If you're not having fun, you're not doing it right!




Re: amrecover failing

2004-10-18 Thread Frank Smith
--On Monday, October 18, 2004 13:26:24 -0400 [EMAIL PROTECTED] wrote:

> Debian/stable (2.4.22 kernel)
> Amanda-2.4.4p2
> tar (GNU tar) 1.13.25
> 
> Hi all,
> 
> I'm trying to use amrecover to restore a users homedir, and keep 
> getting the following error when I answer 'Y' to the 'Load tape now'
> question:
> 
> EOF, check amidxtaped..debug file on space-monster.permabit.com.
> amrecover: short block 0 bytes
> UNKNOWN file
> amrecover: Can't read file header
> extract_list - child returned non-zero status: 1
> 
> At first I thought maybe I had a bad tape, but I've tried on several 
> tapes, all with the same results.  I just did an 'amtape  update'
> and that was able to correctly read the amanda labels off all of the 
> tapes.
> 
> Any ideas?

Have you tried an 'mt rewind' before you press 'Y' ?  Also be aware
that sometimes even after you get your prompt back from the rewind
command, the drive isn't ready yet for another command and will error
on a read right afterwards.   Try to rewind the tape and wait a few
seconds after the activity light goes out before doing anything.
  If you can't see the light, then just try doing an 'mt status' and
make sure that returns ok and shows BOT before you hit 'Y' in amrecover.

Frank

> 
> Thanks,
> -- 
> Seeya,
> Paul
> 
> GPG Key fingerprint = 1660 FECC 5D21 D286 F853  E808 BB07 9239 53F1 28EE
> 
>If you're not having fun, you're not doing it right!
> 

-- 
Frank Smith  [EMAIL PROTECTED]
Sr. Systems Administrator   Voice: 512-374-4673
Hoover's Online   Fax: 512-374-4501





Re: amrecover failing

2004-10-18 Thread Brandon D. Valentine
On Mon, Oct 18, 2004 at 01:26:24PM -0400, [EMAIL PROTECTED] wrote:
> I'm trying to use amrecover to restore a users homedir, and keep 
> getting the following error when I answer 'Y' to the 'Load tape now'
> question:
> 
> EOF, check amidxtaped..debug file on space-monster.permabit.com.
> amrecover: short block 0 bytes
> UNKNOWN file
> amrecover: Can't read file header
> extract_list - child returned non-zero status: 1

Whenever I have seen this error from amrecover it is because the tape
you are restoring from has not been rewound prior to running amrecover.
Load the correct tape and then use 'mt -f /dev/tapedevice rewind' to
make sure the tape is rewound before letting amrecover run and see if
that helps you.

HTH,

Brandon
-- 
Pseudo-Random Googlism:  fall is a good time to focus on herd health


amrecover failing

2004-10-18 Thread pll+amanda
Debian/stable (2.4.22 kernel)
Amanda-2.4.4p2
tar (GNU tar) 1.13.25

Hi all,

I'm trying to use amrecover to restore a users homedir, and keep 
getting the following error when I answer 'Y' to the 'Load tape now'
question:

EOF, check amidxtaped..debug file on space-monster.permabit.com.
amrecover: short block 0 bytes
UNKNOWN file
amrecover: Can't read file header
extract_list - child returned non-zero status: 1

At first I thought maybe I had a bad tape, but I've tried on several 
tapes, all with the same results.  I just did an 'amtape  update'
and that was able to correctly read the amanda labels off all of the 
tapes.

Any ideas?

Thanks,
-- 
Seeya,
Paul

GPG Key fingerprint = 1660 FECC 5D21 D286 F853  E808 BB07 9239 53F1 28EE

 If you're not having fun, you're not doing it right!




amrecover failing, Unexpected EOF

2003-03-17 Thread Hal Lynch
after a successful:
amcheck Daily_1
amdump Daily_1
from my.amanda.server.
From my.amanda.client:
	amrecover -C Daily_1 -s my. amanda.server -t my.amanda.server -d 
/dev/nrsa0
	fails with the following message:
	amrecover: Unexpected end of file, check amindexd*debug on
	server my.amanda.server

There is no amindexd*debug on the server?!

However when I run the above sequence using the server as client also
all is well including the debug file.
Does anyone have any words of wisdom?

hal