Re: FreeBSD client fails with 'error opening /usr/local/share/amanda/bsdtar'

[Jean-Francois Malouin]

* Jean-Louis Martineau  [20170202 11:10]:
> You can't do a level 1 backup if there is no state file for the level 0 
> (full) backup.
> 
> Force a full backup of the dle with amadmin CONF force HOST DISK

Of course, it makes sense!

Thanks,
jf

> 
> Jean-Louis
> 
> On 02/02/17 11:05 AM, Jean-Francois Malouin wrote:
> > * Jean-Louis Martineau  [20170202 10:52]:
> >> Do amcheck reported an error?
> > amcheck returns fine.
> >
> >> $ man ambsdtar
> >> STATE-DIR
> >>
> >>  The directory where ambsdtar stores the database it uses to
> >>  generate incremental dumps.  The default is set when Amanda is
> >>  built.
> >>
> >>
> >> Create the /usr/local/share/amanda/bsdtar directory of set the property
> >> STATE-DIR to another directory that exists.
> > As I said, the state-dir /usr/local/share/amanda/bsdtar *already* exists
> > on the client but is empty at the moment as I didn't put back the files
> > that amanda/bsdtar created *before* I rebuilt the VM. If I leave the
> > state dir empty, who should own it and what should the permissions be?
> >
> > Right now:
> >
> > # ls -ld /usr/local/share/amanda/bsdtar
> > drwxr-xr-x2 amanda  amanda  512 Feb  2 09:29 
> > /usr/local/share/amanda/bsdtar
> >
> > thanks,
> > jf
> >
> >
> >
> >> Jean-Louis
> >>
> >>
> >> On 02/02/17 10:12 AM, Jean-Francois Malouin wrote:
> >>> Hi,
> >>>
> >>> I've got this VM running FreeBSD-11 and amanda-client-3.3.6 installed on
> >>> it for testing purposes. Server is 3.4.1. Initial tests worked ok
> >>> (backups and restores) but I had to rebuild the VM from scratch for
> >>> whatever reasons. After reinstalling and configuring amanda on it as I
> >>> previously did, the amanda backup run on it fails with this in the
> >>> amreport:
> >>>
> >>>
> >>> FAILED DUMP DETAILS:
> >>> /-- 172.16.10.104 /ifs lev 1 FAILED [missing size line from 
> >>> sendbackup]
> >>> sendbackup: info BACKUP=APPLICATION
> >>> sendbackup: info APPLICATION=ambsdtar
> >>> sendbackup: info 
> >>> RECOVER_CMD=/usr/local/libexec/amanda/application/ambsdtar restore 
> >>> [./file-to-restore]+
> >>> sendbackup: info end
> >>> ? ambsdtar: error opening 
> >>> /usr/local/share/amanda/bsdtar/172.16.10.104_ifs_0: No such file or 
> >>> directory
> >>> ? dumper: strange [missing size line from sendbackup]
> >>> \
> >>>
> >>> client debug file shows:
> >>>
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 
> >>> euid 140 version 3.3.6: start at Wed Feb  1 21:30:32 2017
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: version 3.3.6
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 
> >>> euid 140 version 3.3.6: rename at Wed Feb  1 21:30:32 2017
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: BSDTAR-PATH 
> >>> /usr/bin/bsdtar
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: STATE-DIR 
> >>> /usr/local/share/amanda/bsdtar
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: ONE-FILE-SYSTEM yes
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: SIZE ^ *Total bytes 
> >>> written: [0-9][0-9]*
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory 
> >>> is new$
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory 
> >>> has been renamed
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE file changed 
> >>> as we read it$
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^could not 
> >>> open conf file
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Elapsed time:
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Throughput
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : File .* 
> >>> shrunk by [0-9][0-9]* bytes, padding with zeros
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : Cannot add 
> >>> file .*: No such file or directory$
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : Error exit 
> >>> delayed from previous errors
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: STRANGE : socket 
> >>> ignored$
> >>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: ambsdtar: error 
> >>> opening /usr/local/share/amanda/bsdtar/172.16.10.104_ifs_0: No such file 
> >>> or directory
> >>>
> >>> But /usr/local/share/amanda/bsdtar exists on the client (although empty
> >>> at the moment) and has the ownership and permissions:
> >>>
> >>> # ls -la /usr/local/share/amanda/bsdtar
> >>> total 24
> >>> drwxr-xr-x2 amanda  amanda512 Feb  2 09:29 .
> >>> drwxr-xr-x5 rootwheel 512 Feb  1 16:32 ..
> >>>
> >>> I'm kind of lost as to why this worked in the first place and now
> >>> fails...what should be the ownership and permissions on it?
> >>>
> >>> Looking back at the restores on the server of the successful backups of
> >>> /usr/local on this client I can see the 

Re: FreeBSD client fails with 'error opening /usr/local/share/amanda/bsdtar'

[Jean-Louis Martineau]

You can't do a level 1 backup if there is no state file for the level 0 
(full) backup.

Force a full backup of the dle with amadmin CONF force HOST DISK

Jean-Louis

On 02/02/17 11:05 AM, Jean-Francois Malouin wrote:
> * Jean-Louis Martineau  [20170202 10:52]:
>> Do amcheck reported an error?
> amcheck returns fine.
>
>> $ man ambsdtar
>> STATE-DIR
>>
>>  The directory where ambsdtar stores the database it uses to
>>  generate incremental dumps.  The default is set when Amanda is
>>  built.
>>
>>
>> Create the /usr/local/share/amanda/bsdtar directory of set the property
>> STATE-DIR to another directory that exists.
> As I said, the state-dir /usr/local/share/amanda/bsdtar *already* exists
> on the client but is empty at the moment as I didn't put back the files
> that amanda/bsdtar created *before* I rebuilt the VM. If I leave the
> state dir empty, who should own it and what should the permissions be?
>
> Right now:
>
> # ls -ld /usr/local/share/amanda/bsdtar
> drwxr-xr-x2 amanda  amanda  512 Feb  2 09:29 
> /usr/local/share/amanda/bsdtar
>
> thanks,
> jf
>
>
>
>> Jean-Louis
>>
>>
>> On 02/02/17 10:12 AM, Jean-Francois Malouin wrote:
>>> Hi,
>>>
>>> I've got this VM running FreeBSD-11 and amanda-client-3.3.6 installed on
>>> it for testing purposes. Server is 3.4.1. Initial tests worked ok
>>> (backups and restores) but I had to rebuild the VM from scratch for
>>> whatever reasons. After reinstalling and configuring amanda on it as I
>>> previously did, the amanda backup run on it fails with this in the
>>> amreport:
>>>
>>>
>>> FAILED DUMP DETAILS:
>>> /-- 172.16.10.104 /ifs lev 1 FAILED [missing size line from sendbackup]
>>> sendbackup: info BACKUP=APPLICATION
>>> sendbackup: info APPLICATION=ambsdtar
>>> sendbackup: info 
>>> RECOVER_CMD=/usr/local/libexec/amanda/application/ambsdtar restore 
>>> [./file-to-restore]+
>>> sendbackup: info end
>>> ? ambsdtar: error opening 
>>> /usr/local/share/amanda/bsdtar/172.16.10.104_ifs_0: No such file or 
>>> directory
>>> ? dumper: strange [missing size line from sendbackup]
>>> \
>>>
>>> client debug file shows:
>>>
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 euid 
>>> 140 version 3.3.6: start at Wed Feb  1 21:30:32 2017
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: version 3.3.6
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 euid 
>>> 140 version 3.3.6: rename at Wed Feb  1 21:30:32 2017
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: BSDTAR-PATH 
>>> /usr/bin/bsdtar
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: STATE-DIR 
>>> /usr/local/share/amanda/bsdtar
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: ONE-FILE-SYSTEM yes
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: SIZE ^ *Total bytes 
>>> written: [0-9][0-9]*
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory is 
>>> new$
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory has 
>>> been renamed
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE file changed as 
>>> we read it$
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^could not open 
>>> conf file
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Elapsed time:
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Throughput
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : File .* 
>>> shrunk by [0-9][0-9]* bytes, padding with zeros
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : Cannot add 
>>> file .*: No such file or directory$
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : Error exit 
>>> delayed from previous errors
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: STRANGE : socket 
>>> ignored$
>>> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: ambsdtar: error 
>>> opening /usr/local/share/amanda/bsdtar/172.16.10.104_ifs_0: No such file or 
>>> directory
>>>
>>> But /usr/local/share/amanda/bsdtar exists on the client (although empty
>>> at the moment) and has the ownership and permissions:
>>>
>>> # ls -la /usr/local/share/amanda/bsdtar
>>> total 24
>>> drwxr-xr-x2 amanda  amanda512 Feb  2 09:29 .
>>> drwxr-xr-x5 rootwheel 512 Feb  1 16:32 ..
>>>
>>> I'm kind of lost as to why this worked in the first place and now
>>> fails...what should be the ownership and permissions on it?
>>>
>>> Looking back at the restores on the server of the successful backups of
>>> /usr/local on this client I can see the bsdtar state files in there with
>>> the permissions:
>>>
>>> /restore/sim/share/amanda/bsdtar# ls -la
>>> total 24
>>> drwxr-xr-x 2  140  140 4096 Feb  2 09:25 ./
>>> drwxr-xr-x 5 root root  144 Jan 19 07:57 ../
>>> -rw--- 1  140  140   24 Jan 20 16:33 172.16.20.104_ifs_0
>>> -rw--- 1  140  140   24 Jan 22 16:31 172.16.20.104_ifs_1
>>> 

Re: FreeBSD client fails with 'error opening /usr/local/share/amanda/bsdtar'

[Jean-Francois Malouin]

* Jean-Louis Martineau  [20170202 10:52]:
> Do amcheck reported an error?

amcheck returns fine.

> 
> $ man ambsdtar
> STATE-DIR
> 
> The directory where ambsdtar stores the database it uses to
> generate incremental dumps.  The default is set when Amanda is
> built.
> 
> 
> Create the /usr/local/share/amanda/bsdtar directory of set the property 
> STATE-DIR to another directory that exists.

As I said, the state-dir /usr/local/share/amanda/bsdtar *already* exists
on the client but is empty at the moment as I didn't put back the files
that amanda/bsdtar created *before* I rebuilt the VM. If I leave the
state dir empty, who should own it and what should the permissions be? 

Right now:

# ls -ld /usr/local/share/amanda/bsdtar 
drwxr-xr-x2 amanda  amanda  512 Feb  2 09:29 /usr/local/share/amanda/bsdtar

thanks,
jf



> 
> Jean-Louis
> 
> 
> On 02/02/17 10:12 AM, Jean-Francois Malouin wrote:
> > Hi,
> >
> > I've got this VM running FreeBSD-11 and amanda-client-3.3.6 installed on
> > it for testing purposes. Server is 3.4.1. Initial tests worked ok
> > (backups and restores) but I had to rebuild the VM from scratch for
> > whatever reasons. After reinstalling and configuring amanda on it as I
> > previously did, the amanda backup run on it fails with this in the
> > amreport:
> >
> >
> > FAILED DUMP DETAILS:
> >/-- 172.16.10.104 /ifs lev 1 FAILED [missing size line from sendbackup]
> >sendbackup: info BACKUP=APPLICATION
> >sendbackup: info APPLICATION=ambsdtar
> >sendbackup: info 
> > RECOVER_CMD=/usr/local/libexec/amanda/application/ambsdtar restore 
> > [./file-to-restore]+
> >sendbackup: info end
> >? ambsdtar: error opening 
> > /usr/local/share/amanda/bsdtar/172.16.10.104_ifs_0: No such file or 
> > directory
> >? dumper: strange [missing size line from sendbackup]
> >\
> >
> > client debug file shows:
> >
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 euid 
> > 140 version 3.3.6: start at Wed Feb  1 21:30:32 2017
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: version 3.3.6
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 euid 
> > 140 version 3.3.6: rename at Wed Feb  1 21:30:32 2017
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: BSDTAR-PATH 
> > /usr/bin/bsdtar
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: STATE-DIR 
> > /usr/local/share/amanda/bsdtar
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: ONE-FILE-SYSTEM yes
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: SIZE ^ *Total bytes 
> > written: [0-9][0-9]*
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory is 
> > new$
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory has 
> > been renamed
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE file changed as 
> > we read it$
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^could not open 
> > conf file
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Elapsed time:
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Throughput
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : File .* 
> > shrunk by [0-9][0-9]* bytes, padding with zeros
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : Cannot add 
> > file .*: No such file or directory$
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : Error exit 
> > delayed from previous errors
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: STRANGE : socket 
> > ignored$
> > Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: ambsdtar: error 
> > opening /usr/local/share/amanda/bsdtar/172.16.10.104_ifs_0: No such file or 
> > directory
> >
> > But /usr/local/share/amanda/bsdtar exists on the client (although empty
> > at the moment) and has the ownership and permissions:
> >
> > # ls -la /usr/local/share/amanda/bsdtar
> > total 24
> > drwxr-xr-x2 amanda  amanda512 Feb  2 09:29 .
> > drwxr-xr-x5 rootwheel 512 Feb  1 16:32 ..
> >
> > I'm kind of lost as to why this worked in the first place and now
> > fails...what should be the ownership and permissions on it?
> >
> > Looking back at the restores on the server of the successful backups of
> > /usr/local on this client I can see the bsdtar state files in there with
> > the permissions:
> >
> > /restore/sim/share/amanda/bsdtar# ls -la
> > total 24
> > drwxr-xr-x 2  140  140 4096 Feb  2 09:25 ./
> > drwxr-xr-x 5 root root  144 Jan 19 07:57 ../
> > -rw--- 1  140  140   24 Jan 20 16:33 172.16.20.104_ifs_0
> > -rw--- 1  140  140   24 Jan 22 16:31 172.16.20.104_ifs_1
> > -rw--- 1  140  140   24 Jan 24 16:32 172.16.20.104_ifs_2
> > -rw--- 1  140  140   24 Jan 20 16:32 172.16.20.104_usr_local_0
> > -rw--- 1  140  140   24 Jan 24 16:31 172.16.20.104_usr_local_1
> >
> > 140 is the amanda user UID and GID on the client:
> 

Re: FreeBSD client fails with 'error opening /usr/local/share/amanda/bsdtar'

[Jean-Louis Martineau]

Do amcheck reported an error?

$ man ambsdtar
STATE-DIR

The directory where ambsdtar stores the database it uses to
generate incremental dumps.  The default is set when Amanda is
built.


Create the /usr/local/share/amanda/bsdtar directory of set the property 
STATE-DIR to another directory that exists.

Jean-Louis


On 02/02/17 10:12 AM, Jean-Francois Malouin wrote:
> Hi,
>
> I've got this VM running FreeBSD-11 and amanda-client-3.3.6 installed on
> it for testing purposes. Server is 3.4.1. Initial tests worked ok
> (backups and restores) but I had to rebuild the VM from scratch for
> whatever reasons. After reinstalling and configuring amanda on it as I
> previously did, the amanda backup run on it fails with this in the
> amreport:
>
>
> FAILED DUMP DETAILS:
>/-- 172.16.10.104 /ifs lev 1 FAILED [missing size line from sendbackup]
>sendbackup: info BACKUP=APPLICATION
>sendbackup: info APPLICATION=ambsdtar
>sendbackup: info 
> RECOVER_CMD=/usr/local/libexec/amanda/application/ambsdtar restore 
> [./file-to-restore]+
>sendbackup: info end
>? ambsdtar: error opening 
> /usr/local/share/amanda/bsdtar/172.16.10.104_ifs_0: No such file or directory
>? dumper: strange [missing size line from sendbackup]
>\
>
> client debug file shows:
>
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 euid 
> 140 version 3.3.6: start at Wed Feb  1 21:30:32 2017
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: version 3.3.6
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: pid 40453 ruid 0 euid 
> 140 version 3.3.6: rename at Wed Feb  1 21:30:32 2017
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: BSDTAR-PATH 
> /usr/bin/bsdtar
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: STATE-DIR 
> /usr/local/share/amanda/bsdtar
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: ONE-FILE-SYSTEM yes
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: SIZE ^ *Total bytes 
> written: [0-9][0-9]*
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory is 
> new$
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE : Directory has 
> been renamed
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: IGNORE file changed as 
> we read it$
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^could not open 
> conf file
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Elapsed time:
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL ^Throughput
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : File .* shrunk 
> by [0-9][0-9]* bytes, padding with zeros
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : Cannot add file 
> .*: No such file or directory$
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: NORMAL : Error exit 
> delayed from previous errors
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: STRANGE : socket ignored$
> Wed Feb  1 21:30:32 2017: thd-0x800718e00: ambsdtar: ambsdtar: error opening 
> /usr/local/share/amanda/bsdtar/172.16.10.104_ifs_0: No such file or directory
>
> But /usr/local/share/amanda/bsdtar exists on the client (although empty
> at the moment) and has the ownership and permissions:
>
> # ls -la /usr/local/share/amanda/bsdtar
> total 24
> drwxr-xr-x2 amanda  amanda512 Feb  2 09:29 .
> drwxr-xr-x5 rootwheel 512 Feb  1 16:32 ..
>
> I'm kind of lost as to why this worked in the first place and now
> fails...what should be the ownership and permissions on it?
>
> Looking back at the restores on the server of the successful backups of
> /usr/local on this client I can see the bsdtar state files in there with
> the permissions:
>
> /restore/sim/share/amanda/bsdtar# ls -la
> total 24
> drwxr-xr-x 2  140  140 4096 Feb  2 09:25 ./
> drwxr-xr-x 5 root root  144 Jan 19 07:57 ../
> -rw--- 1  140  140   24 Jan 20 16:33 172.16.20.104_ifs_0
> -rw--- 1  140  140   24 Jan 22 16:31 172.16.20.104_ifs_1
> -rw--- 1  140  140   24 Jan 24 16:32 172.16.20.104_ifs_2
> -rw--- 1  140  140   24 Jan 20 16:32 172.16.20.104_usr_local_0
> -rw--- 1  140  140   24 Jan 24 16:31 172.16.20.104_usr_local_1
>
> 140 is the amanda user UID and GID on the client:
>
> # id amanda
> uid=140(amanda) gid=140(amanda) groups=140(amanda),5(operator)
>
> Thanks,
> jf

RE: FreeBSD client

[John Clement]

 John Clement wrote:
  Some of you might remember I'm piecing together a previous, 
  non-working, installation of amanda.  The help I've 
 received off here 
  has been great, so thanks again!  The next piece in this 
 puzzle is a 
  FreeBSD (5.4) machine that appears to have amanda already installed.
 
 John, let us know the/some background of your mission.
 
 Seems you're the one to keep the wheels reelin'
 ... after someone else has left the building.
 

Yes indeed, I am rather picking up the pieces.  The background to this
one is it seems every time a new sys ad starts they install their own
flavour of OS, so we've got various versions of RH, some BSD, Solaris,
Windows.  Most of the clients have been installed, and its now at the
point where they're nearly all working, except the FreeBSD one.

However, results are now needed so rather than getting the few remaining
BSD machines working too, I want to get something in place so we're
actually backing stuff up.  So, on to my next post and I'll be picking
this one up again soon.

Thanks for the help,


John


 Your puzzle is ours, as it seem ;-)
 
 Regards, Stefan.
 

Re: FreeBSD client

[Olivier Nicole]

 Some of you might remember I'm piecing together a previous, non-working,
 installation of amanda.  The help I've received off here has been great,
 so thanks again!  The next piece in this puzzle is a FreeBSD (5.4)
 machine that appears to have amanda already installed.

First question is how was it installed? From the ports or from the
source?

If it si from the ports, it should be reported by pkg_info|grep amanda

 I can't find any documentation on getting the client working on BSD so
 started going by all the information I've gleened troubleshooting the
 Linux machines here.  I can't find a .amandahosts file, do I need to
 create this and if so where?  Or should this information go somewhere
 else?

Cleints are working the same way on Linux or on FreeBSD (that is if
you know how to install a cleint by hand).

Assuming that amanda has been build with user amanda and group
amanda...

.amandahosts should go in the home directory of the user amanda on the
client. It should be chown'ed to amanda:amanda and contains a line
saying something like

server.you.domain.com amanda

banyanroot: ls -l .amandahosts
-rw-r--r--  1 amanda  amanda  31 Oct 31  2005 .amandahosts

if amanda on your server was compiled for the user amanda.

In /etc you need to create an empty file called amandadates

banyanroot: ls -l /etc/amandates 
-rw-r--r--  1 amanda  amanda  494 May  2 01:29 /etc/amandates
 
It should belongs to amanda:amanda

In /etc/inetd.conf you must have a line saying

amanda  dgram   udp waitamanda  /usr/local/libexec/amanda/amandad 
amandad

with the correct path to amandad.

You must make sure inetd is running (disabled by default on some
security models, re-enable it in /etc/rc.conf)

In /usr/local/var create amanda directory and in /usr/local/var/amanda
create gnu-tar directory. Everything chown'ed to amanda:amanda

 I assume /tmp/amanda should exist on the machine and be writable and
 ownder by operator:operator (operator being the default username the
 client seems to install by, and operator being BSD's equiv of 'disk'
 group), is this so?

/tmp/amanda is created automatically by the first run of amanda.

That's all IO can think about right now.

Bests,

olivier

Re: FreeBSD client

[Toomas Aas]

John Clement wrote:

I can't find any documentation on getting the client working on BSD so 
started going by all the information I've gleened troubleshooting the 
Linux machines here.  


Getting the client working on FreeBSD is nothing special :) Just install 
the client (I understand that's already done) and add the amandad entry 
to /etc/inetd.conf.


 I can't find a .amandahosts file, do I need to create this and if so
 where?  Or should this information go somewhere else?

This file needs to be in the home directory of the amanda user (in your 
case, operator). You can find out what this directory is by running

chsh operator.

I believe the default home directory for operator on FreeBSD is /

Generally when installing Amanda on FreeBSD I prefer to not use operator 
but still create a special 'amanda' user and add this user to group 
'operator'. Operator's standard home directory being / is one of the 
reasons - I don't like the idea of amanda files living directly under /. 
The alternative is to change the home directory of operator to somewhere 
else, which I also don't like. I *have* done it on some machines, 
though, and they have been running for several years without problems.


I assume /tmp/amanda should exist on the machine and be writable and 
ownder by operator:operator (operator being the default username the 
client seems to install by, and operator being BSD's equiv of 'disk' 
group), is this so?


Yes. But this directory should be created automatically by Amanda.

Re: FreeBSD client

[Kevin Till]

John Clement wrote:
Some of you might remember I'm piecing together a previous, non-working, 
installation of amanda.  The help I've received off here has been great, 
so thanks again!  The next piece in this puzzle is a FreeBSD (5.4) 
machine that appears to have amanda already installed.
 
I can't find any documentation on getting the client working on BSD so 
started going by all the information I've gleened troubleshooting the 
Linux machines here.  I can't find a .amandahosts file, do I need to 
create this and if so where?  Or should this information go somewhere else?
 
I assume /tmp/amanda should exist on the machine and be writable and 
ownder by operator:operator (operator being the default username the 
client seems to install by, and operator being BSD's equiv of 'disk' 
group), is this so?



do amadmin test version

the output of the above command tells how it's configured and
where the log will be kept and etc.

--
Thank you!
Kevin Till

Amanda documentation: http://wiki.zmanda.com
Amanda forums:http://forums.zmanda.com

Re: FreeBSD client

[Stefan G. Weichinger]

John Clement wrote:
 Some of you might remember I'm piecing together a previous, non-working,
 installation of amanda.  The help I've received off here has been great,
 so thanks again!  The next piece in this puzzle is a FreeBSD (5.4)
 machine that appears to have amanda already installed.

John, let us know the/some background of your mission.

Seems you're the one to keep the wheels reelin'
... after someone else has left the building.

Your puzzle is ours, as it seem ;-)

Regards, Stefan.