-
December 20th, 2011, 03:14 AM
#1
amrecover issues: partial solution
I am using amanda 3.3.0 as distributed on SuSE Linux 12.1; which includes perl 5.14.2.
I have a partial solution, and then a puzzle. Advice welcomed.
Initial symptoms:
amrecover> extract
Extracting files using tape drive /dev/nst0 on host blah.
The following tapes are needed: TAPE04
Extracting files using tape drive /dev/nst0 on host blah.
Load tape TAPE04 now
Continue [?/Y/n/s/d]? Y
amrecover - can't talk to tape server: service amidxtaped:
As part of a diagnostic activity:
amanda@blah:/usr/lib/amanda> ./amidxtaped
** (process:2985): WARNING **: Use of qw(...) as parentheses is
deprecated at
/usr/lib/perl5/vendor_perl/5.14.2/Amanda/Recovery/Clerk.pm line 231.
** (process:2985): WARNING **: Use of qw(...) as parentheses is
deprecated at
/usr/lib/perl5/vendor_perl/5.14.2/Amanda/Recovery/Clerk.pm line 265.
** (process:2985): WARNING **: Use of qw(...) as parentheses is
deprecated at
/usr/lib/perl5/vendor_perl/5.14.2/Amanda/Recovery/Planner.pm line 231.
** (process:2985): WARNING **: Use of qw(...) as parentheses is
deprecated at
/usr/lib/perl5/vendor_perl/5.14.2/Amanda/Recovery/Planner.pm line 342.
** (process:2985): WARNING **: Use of qw(...) as parentheses is
deprecated at
/usr/lib/perl5/vendor_perl/5.14.2/Amanda/Recovery/Planner.pm line 393.
ERROR did not get security line
Apparently, the problem is that the shift to perl 5.13.5 (and, I guess, beyond) has tightened the necessary syntax, breaking the older working code --- don't blame me, but see: http://blogs.perl.org/users/rurban/2...eprecated.html
So it appears that the following are needed
for my $rq_param qw(dump xfer_src_cb) => for my $rq_param (qw(dump
xfer_src_cb))
for my $rq_param qw(xfer recovery_cb) => for my $rq_param (qw(xfer
recovery_cb))
in /usr/lib64/perl5/vendor_perl/Amanda/Recovery/Clerk.pm
and similar at 231, 342, 393 in
/usr/lib64/perl5/vendor_perl/Amanda/Recovery/Planner.pm
This might explain some issues seen on other threads here, and is a recognised problem:
https://bugzilla.redhat.com/show_bug.cgi?id=757618
However, in my case (having added the necessary parenthesis) I now get:
Extracting files using tape drive /dev/nst0 on host blah.
The following tapes are needed: TAPE04
Extracting files using tape drive /dev/nst0 on host blah.
Load tape TAPE04 now
Continue [?/Y/n/s/d]? Y
Can't open tape device /dev/nst0: Permission denied
I don't understand this. /dev/nst0 is root:tape, and amanda belongs to group tape (as does root, from which I invoked amrecover). Permissions issues are usually straightforward, but I cannot see what is happening here. Can anyone please advise.
-
January 4th, 2012, 01:21 AM
#2
Found a solution to the amrecover "Can't open tape device /dev/nst0: Permission denied" problem. /dev/nst0 was chown root:tape, with chmod 660 --- which I thought should be enough. However, chmod 664 /dev/nst0 removed the unwanted symptom, so now it all works. I'm not sure I like this solution; it suggests there is something "other" invoked by amrecover that neither has the owner root (I invoke amrecover from root), nor is part of group tape to which amanda belongs. It sounds as if there may be security issues. So, is this the _correct_ solution? Advice from you experts wanted, please.
-
January 25th, 2012, 11:03 AM
#3
Thanks this resolved the problems I was having getting the recovery process to work as well.
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules