RE: Losing it, need help with amrecover

2015-10-07 Thread Joi L. Ellis 
It sounds like your new empty client is trying to talk to itself instead of 
your amanda server.  You run amrecover on the client, not the server, and the 
client needs to know who the server is.  Also, the server needs to know who the 
client host is, and who the user is running amrecover.

> > > gene@GO704:/etc$ sudo  amrecover -C Daily -h coyote AMRECOVER
> > > Version 3.3.1. Contacting server on localhost ...
> > > NAK: execute access to "/usr/lib/amanda/amindexd" denied

This means the client successfully reached the server, but the server didn't 
want to allow this client to talk to the index service.  It doesn't mean the 
amindexd binary isn't installed on your client--it shouldn't be there on the 
client anyway.  My amanda version is newer than yours and the error message is 
clearer:

NAK: user root from cesonia.pavlovmedia.corp is not allowed to execute the 
service amindexd: Please add the line "cesonia.pavlovmedia.corp root amindexd 
amidxtaped" to /var/backups/.amandahosts on the server

As soon as I fix .amandahosts on the server, I can run amrecover as root on the 
client.  Mine server's .amandahost contains, in part:

cesonia.pavlovmedia.corprootamdump amindexd amidxtaped
cesonia.pavlovmedia.corpbackup  amdump amindexd amidxtaped

(Many sample Amanda configurations I've seen only list amdump in here, not
all three... which is fine for doing backups but then you can't restore.)

Your new empty client needs to have the amanda-client package installed on it, 
not the amanda-server package.  You then need to configure the 
amanda-client.conf file on the new empty client to contain the info needed to 
identify your amanda backup server, the index server, etc.  

On my clients the minimal setup is:

conf"DailySet1"
index_server"Macropus.pavlovmedia.corp"
tape_server "Macropus.pavlovmedia.corp"
auth"bsd"

Macropus is my amanda server.  

If this new empty client is using a new hostname or IP from the dead host, you 
need to update the server's .amandahosts file to identify the name of the new 
empty client or its IP, and the name of the account running Amanda on that 
client (backup in my case because mine are Ubuntu.)

To summarize:
On the amanda server:
  * tweak .amandahosts to allow the new empty client to connect to amandad.

On the new empty client:
  * edit amanda-client.conf to point it at the amanda server
  * if this client is running a firewall, configure it to allow amanda, 
including if-conntrack-amanda if that module is provided for your kernel.

You want to run amrecover as user root, otherwise you won't have the privs 
necessary to restore most of the files under /.  I almost always do this from 
/, because I want to recover just a few files and want them written to the same 
place.  If you don't want to do this, just make a temporary directory in /tmp, 
cd there, and then run amrecover.  The recovered files will be placed in the 
temporary directory and its then up to you to move them where they belong.


> -Original Message-
> From: owner-amanda-us...@amanda.org [mailto:owner-amanda-us...@amanda.org]
> On Behalf Of Gene Heskett
> Sent: Tuesday, October 6, 2015 10:36 AM
> To: amanda-users@amanda.org
> Subject: Re: Losing it, need help with amrecover
> 
> On Tuesday 06 October 2015 09:54:41 Jean-Louis Martineau wrote:
> 
> > On 06/10/15 09:20 AM, Gene Heskett wrote:
> > > Greetings all;
> > >
> > > I have been following the recomendations spit out by amcheck as I am
> > > needing to restore a machine after the machine in that spot failed.
> > >
> > > I am now down to this error, and apparently something in the
> > > installer did setup the amanda-client correctly.
> > >
> > > gene@GO704:/etc$ sudo  amrecover -C Daily -h coyote AMRECOVER
> > > Version 3.3.1. Contacting server on localhost ...
> > > NAK: execute access to "/usr/lib/amanda/amindexd" denied
> >
> > Is it contacting the correct server??? localhost
> >
> > > What are the correct user:group and access rights to this file?
> > >
> > > Better question yet, why does it not exist?
> > >
> > > Because on that machine, with 3.3.1 amanda-client and amanda-common
> > > freshly installed, that file is not there.
> >
> > Because you need amanda-server
> 
> Its now installed on the client (GO704.coyote.den) I am trying to recover.
> 
> > But maybe you need to add '-s coyote -t coyote' to the amrecover
> > command line if 'coyote' is the amanda server.
> 
> > Or you can put them in amanda-client.conf
> 
> On which machine?
> 
> Humm:  Might be a step in the right direction.
> 
> root@GO704:/lib/firmware/hm2# su amanda -c "amrecover -C Daily -s coyote -
> t coyote"
> No passwd entry for user 'amanda'
> 
> At least on that machine.
> 
> Next?
> 
> I also tried by using backup as the user since that is in passwd here:
> 
> root@GO704:/lib/firmware/hm2# su backup -c "amrecover -C Daily -s coyote -
> t coyote"
> X11 connection rejected because of wrong

Re: Losing it, need help with amrecover

2015-10-07 Thread Gene Heskett 
On Wednesday 07 October 2015 18:39:27 Joi L. Ellis wrote:

> It sounds like your new empty client is trying to talk to itself
> instead of your amanda server.  You run amrecover on the client, not
> the server, and the client needs to know who the server is.  Also, the
> server needs to know who the client host is, and who the user is
> running amrecover.
>
> > > > gene@GO704:/etc$ sudo  amrecover -C Daily -h coyote AMRECOVER
> > > > Version 3.3.1. Contacting server on localhost ...
> > > > NAK: execute access to "/usr/lib/amanda/amindexd" denied
>
> This means the client successfully reached the server, but the server
> didn't want to allow this client to talk to the index service.  It
> doesn't mean the amindexd binary isn't installed on your client--it
> shouldn't be there on the client anyway.  My amanda version is newer
> than yours and the error message is clearer:
>
> NAK: user root from cesonia.pavlovmedia.corp is not allowed to execute
> the service amindexd: Please add the line "cesonia.pavlovmedia.corp
> root amindexd amidxtaped" to /var/backups/.amandahosts on the server
>
> As soon as I fix .amandahosts on the server, I can run amrecover as
> root on the client.  Mine server's .amandahost contains, in part:
>
> cesonia.pavlovmedia.corprootamdump amindexd amidxtaped
> cesonia.pavlovmedia.corpbackup  amdump amindexd amidxtaped
>
> (Many sample Amanda configurations I've seen only list amdump in here,
> not all three... which is fine for doing backups but then you can't
> restore.)
>
> Your new empty client needs to have the amanda-client package
> installed on it, not the amanda-server package.  You then need to
> configure the amanda-client.conf file on the new empty client to
> contain the info needed to identify your amanda backup server, the
> index server, etc.
>
> On my clients the minimal setup is:
>
>   conf"DailySet1"
>   index_server"Macropus.pavlovmedia.corp"
>   tape_server "Macropus.pavlovmedia.corp"
>   auth"bsd"
>
> Macropus is my amanda server.
>
> If this new empty client is using a new hostname or IP from the dead
> host, you need to update the server's .amandahosts file to identify
> the name of the new empty client or its IP, and the name of the
> account running Amanda on that client (backup in my case because mine
> are Ubuntu.)
>
> To summarize:
> On the amanda server:
>   * tweak .amandahosts to allow the new empty client to connect to
> amandad.
>
> On the new empty client:
>   * edit amanda-client.conf to point it at the amanda server
>   * if this client is running a firewall, configure it to allow
> amanda, including if-conntrack-amanda if that module is provided for
> your kernel.
>
> You want to run amrecover as user root, otherwise you won't have the
> privs necessary to restore most of the files under /.  I almost always
> do this from /, because I want to recover just a few files and want
> them written to the same place.  If you don't want to do this, just
> make a temporary directory in /tmp, cd there, and then run amrecover. 
> The recovered files will be placed in the temporary directory and its
> then up to you to move them where they belong.
>
> > -Original Message-
> > From: owner-amanda-us...@amanda.org
> > [mailto:owner-amanda-us...@amanda.org] On Behalf Of Gene Heskett
> > Sent: Tuesday, October 6, 2015 10:36 AM
> > To: amanda-users@amanda.org
> > Subject: Re: Losing it, need help with amrecover
> >
> > On Tuesday 06 October 2015 09:54:41 Jean-Louis Martineau wrote:
> > > On 06/10/15 09:20 AM, Gene Heskett wrote:
> > > > Greetings all;
> > > >
> > > > I have been following the recomendations spit out by amcheck as
> > > > I am needing to restore a machine after the machine in that spot
> > > > failed.
> > > >
> > > > I am now down to this error, and apparently something in the
> > > > installer did setup the amanda-client correctly.
> > > >
> > > > gene@GO704:/etc$ sudo  amrecover -C Daily -h coyote AMRECOVER
> > > > Version 3.3.1. Contacting server on localhost ...
> > > > NAK: execute access to "/usr/lib/amanda/amindexd" denied
> > >
> > > Is it contacting the correct server??? localhost
> > >
> > > > What are the correct user:group and access rights to this file?
> > > >
> > > > Better question yet, why does it not exist?
> > > >
> > > > Because on that machine, with 3.3.1 amanda-client and
> > > > amanda-common freshly installed, that file is not there.
> > >
> > > Because you need amanda-server
> >
> > Its now installed on the client (GO704.coyote.den) I am trying to
> > recover.
> >
> > > But maybe you need to add '-s coyote -t coyote' to the amrecover
> > > command line if 'coyote' is the amanda server.
> > >
> > > Or you can put them in amanda-client.conf
> >
> > On which machine?
> >
> > Humm:  Might be a step in the right direction.
> >
> > root@GO704:/lib/firmware/hm2# su amanda -c "amrecover -C Daily -s
> > coyote - t coyote"
> > No passwd entry for user 'amanda'
> >
> > At least

RE: Losing it, need help with amrecover

2015-10-07 Thread Joi L. Ellis 


[snip]

> 
> Which is sort of what I did Joi.
> 
> amrecover bothers me because that is no apparent way to strip the leading
> part of the path from what you want to recover, and from the messages it
> presents, if you don't just give up and use a scratch directory, then move
> what it recovers, I am sure not about to let it destroy everything in my
> home dir just to recover the linuxcnc subdir.  It may be capable of doing
> that, but the "are you sure" messages just warn that the /home/gene
> directory will be nuked.
> 

What backup method is your DLE using?  Gnutar strips the leading / off 
automatically when you extract from a tarball, so it won't just overwrite your 
real stuff automatically.  The only way it will overwrite original anything is 
if you're sitting in / when you run amrecover.  

You don't have to recover a whole tree of stuff to test, just select one 
unimportant file, and see where it writes it.

If you tell amrecover you only want the linuxcnc directory, that is all it will 
extract, it won't touch anything else.

It doesn't delete the target directory and then restore into it, if that's what 
you're thinking... it will just overwrite the current file(s) in that target 
with what you extract from the backup, if the paths are exact matches.

> Thanks Joi.
> 
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page

Re: Losing it, need help with amrecover

2015-10-07 Thread Jon LaBadie 
On Thu, Oct 08, 2015 at 12:04:34AM +, Joi L. Ellis wrote:
> 
> 
> [snip]
> 
> > 
> > Which is sort of what I did Joi.
> > 
> > amrecover bothers me because that is no apparent way to strip the leading
> > part of the path from what you want to recover, and from the messages it
> > presents, if you don't just give up and use a scratch directory, then move
> > what it recovers, I am sure not about to let it destroy everything in my
> > home dir just to recover the linuxcnc subdir.  It may be capable of doing
> > that, but the "are you sure" messages just warn that the /home/gene
> > directory will be nuked.
> > 
> 
> What backup method is your DLE using?  Gnutar strips the leading / off
> automatically when you extract from a tarball, so it won't just overwrite
> your real stuff automatically.  The only way it will overwrite original
> anything is if you're sitting in / when you run amrecover.  
> 
Joi,
In this case "/" is the "root" of the DLE, not the file system.  Gene's
DLE is of /home.  So if he were to recover his home directory "gene"
while sitting in the file system root, I think it would make "/gene"
as a new directory rather than overwriting "/home/gene".

jl
-- 
Jon H. LaBadie j...@jgcomp.com
 11226 South Shore Rd.  (703) 787-0688 (H)
 Reston, VA  20190  (703) 935-6720 (C)

Re: Losing it, need help with amrecover

2015-10-07 Thread Gene Heskett 
On Wednesday 07 October 2015 20:04:34 Joi L. Ellis wrote:

> [snip]
>
> > Which is sort of what I did Joi.
> >
> > amrecover bothers me because that is no apparent way to strip the
> > leading part of the path from what you want to recover, and from the
> > messages it presents, if you don't just give up and use a scratch
> > directory, then move what it recovers, I am sure not about to let it
> > destroy everything in my home dir just to recover the linuxcnc
> > subdir.  It may be capable of doing that, but the "are you sure"
> > messages just warn that the /home/gene directory will be nuked.
>
> What backup method is your DLE using?  Gnutar strips the leading / off
> automatically when you extract from a tarball, so it won't just
> overwrite your real stuff automatically.  The only way it will
> overwrite original anything is if you're sitting in / when you run
> amrecover.
>
> You don't have to recover a whole tree of stuff to test, just select
> one unimportant file, and see where it writes it.
>
> If you tell amrecover you only want the linuxcnc directory, that is
> all it will extract, it won't touch anything else.
>
> It doesn't delete the target directory and then restore into it, if
> that's what you're thinking... it will just overwrite the current
> file(s) in that target with what you extract from the backup, if the
> paths are exact matches.
>
The are you sure messages says otherwise. I thought I was doing good when 
I extracted the contents of the linuxcnc directory while locally cd'd 
to /home/gene/linuxcnc (which I had to create) but when the extraction 
was finished, I had a sybdir tree of

/home/gene/linuxcnc/gene/linuxcnc/*

So I just mv'd them to where they belonged, nuking empty dirs as they 
emptied out.

So it all worked out.  This was with deb of what I believe is 3.3.1p1 on 
the clients, 3 of them, and a locally built 3.3.7p1 on this server.  The 
last several times I tried to build a 4.something was a disaster, so I 
got out of the "canary in the coal mine" business when my comments about 
the failures were ignored.

I don't mind bleeding a little when the bleeding is stopped by the next 
tarball download & build.  But that hasn't happened for about 2 years 
now.

Thanks Joi.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page