How To:Configure bsdtcp authentication: Difference between revisions

From wiki.zmanda.com
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
{{XXX|Dustin|Needs TLC, merging}}
{{XXX|Dustin|Needs TLC, merging}}
These configuration file are valid only Amanda 2.5.1 or later releases.


== Configure amanda to support bsdudp or bsdtcp security==
If wanting to use bsdudp or bsdtcp authentication with Amanda and you are compiling from source, you must specify the configure flag
  --with-bsdudp-security
or
  --with-bsdtcp-security
when compiling.


Otherwise, amcheck will return messages like:
'''Work in Progess'''
  Could not find security driver "bsdtcp" for host "yourhost". auth for this dle is invalid
 
As for network services, commonly inetd or xinetd, the initial version of Amanda used only bsd authentication.  Starting with Amanda 2.5, bsdudp and bsdtcp authentication methods were introduced (for more information, please see [[Server/Client_authentication]]).  Although the bsd authentication method remains to be the default for Amanda source code (Nov 2008), some packaged versions of Amanda come pre-configured to use the newer and preferred bsdtcp authentication method such as the [http://www.zmanda.com/download-amanda.php Zmanda Community Edition] packages.
 
Once you decide which of these authentication methods you will go with, a network service entry for Amandad (Amanda client process) must be configured correctly on each Amanda client for the chosen authentication method.  This configuration is necessary for the backup process [[amdump]] which runs on the Amanda server.
 
This article will progressively march through inetd and xinetd examples of bsd, bsdudp, and bsdtcp authentication methods for Amanda 2.5 and later.  For configuration of a pre-2.5 client (bsd only), please see [[#Backing_up_an_older_Amanda_2.4_client|Backing up an older Amanda 2.4 client]] at the bottom of this page.
 
== .amandahosts file ==
 
It is very common for Amanda to be compiled to use the .amandahosts file to control access on clients and server with bsd, bsdudp, and bsdtcp authentications.
 
The ''.amandahosts'' file is located in the Amanda user's home directory, commonly ''/var/lib/amanda''.  This file should be readable and writable only by the Amanda backup user.


See [[Server/Client_authentication]] for alternate authentication methods.
The format of .amandahosts is


== Changes in the disklist file ==
<amandaserver.example.com> <backup_user> <service(s)>


On the Amanda server the entries in the '''disklist''' need to have the '''auth''' parameter.
The first field is the fully qualified domain name of the server which is being granted access to the local machine as ''backup_user'' to perform ''service(s)''.  


server.example.com    {
Examples:
        comp-user-tar
        auth "bsdtcp"
        }    1


This may also be set globally in the definition of the dumptype in '''amanda.conf'''
The ''.amandahosts'' file on an Amanda client should have
amandaserver.example.com amandabackup amdump


define dumptype comp-user-tar {
The ''.amandahosts'' file on the Amanda server should have
        ...
amandaclient1.example.com root amindexd amidxtaped
        auth "bsdtcp"
        ...
}


Older versions of Amanda client software (2.5.0 or earlier) have only the protocol "bsd"
== bsd ==
available.  (The default protocol is "bsd".)


=== client ===


== xinetd/inetd configuration file changes ==
==== inetd ====
When using ''inetd'', Amanda server access is controlled by the ''hosts.allow'' file on the same machine.
'''Example of using bsd authorization for inetd server assuming Amanda user is "amanda"'''
amanda          dgram  udp    wait    amanda  /usr/lib/amanda/amandad      amandad -auth=bsd amdump amindexd amidxtaped


Amandad (Amanda client process) must be configured correctly as xinetd or inetd server on each Amanda client.  This configuration is necessary for backup process - [[amdump]].
==== xinetd ====
For xinetd, access to your Amanda server is controlled by the ''only_from'' parameter.


'''Template for /etc/xinet.d/amanda file'''
'''Template for Amanda client /etc/xinet.d/amanda file'''
   service amanda
   service amanda
   {
   {
Line 54: Line 57:
   }
   }


'''Example xinetd.d amanda client service file with backup user - amandabackup'''
'''Example xinetd.d amanda client service file with backup user "amandabackup"'''
 
  service amanda
  service amanda
  {
  {
Line 70: Line 72:
  }
  }


Amanda server (tape server) can be also configured to use "bsd" authentication for restore process - [[amrecover]] command.  The ''server_args'' on the xinetd service entry on the server should include ''amindexd'' and ''amidxtaped''.  The ''only_from'' line should include all clients that can do recovery.
=== server===
If an Amanda server (tape server) will also be a backup client to itself using bsd authentication, it will use the same client configuration.  However, as the Amanda server is also the recovery server for all clients via the [[amrecover]] command, the x/inetd service entry on the Amanda server should also include ''amindexd'' and ''amidxtaped'' amandad server arguments.   
 
==== inetd ====
When using ''inetd'', Amanda server access is controlled by the ''hosts.allow'' file on the same machine.
 
'''Example of using bsd authorization for inetd server assuming Amanda user is "amanda"'''
amanda          dgram  udp    wait    amanda  /usr/lib/amanda/amandad      amandad -auth=bsd amdump amindexd amidxtaped
 
If you are using TCP wrappers, your inetd entry may look like this assuming Amanda user is "amanda":
amanda          dgram  udp    wait    amanda  /usr/sbin/tcpd /usr/lib/amanda/amandad -auth=bsd amdump amindexd amidxtaped
 
==== xinetd ====
For xinetd, access to your Amanda server is controlled by the ''only_from'' parameter.


'''Example of xinetd server entry that used bsd and can do both backup as well as recovery'''
'''Example of xinetd server entry that uses bsd for being a backup client to itself as well as a recovery server for all clients'''
  service amanda
  service amanda
  {
  {
         only_from      = amandaserver.example.com amandaclient.example.com
         only_from      = amandaserver.example.com amandaclient1.example.com amandaclient2.example.com
         socket_type    = dgram
         socket_type    = dgram
         protocol        = udp
         protocol        = udp
Line 88: Line 103:




The ''bsdtcp'' authentication requires different xinetd/inetd service entries.  The protocol will be ''tcp''.  An example ''bsdtcp'' authentication xinetd service entry for a machine that can do both backup and recovery (differences with ''bsd'' authentication entry is highlighted):
== bsdudp ==


service amanda
If you want to use bsdudp authentication and are compiling from source code, you must specify the configure flag
{
  --with-bsdudp-security
        only_from      = amandaserver.example.com amandaclient.example.com
otherwise, amcheck will return messages like:
        socket_type    = '''stream'''
  Could not find security driver "bsdudp" for host "yourhost". auth for this dle is invalid
        protocol        = '''tcp'''
 
        wait            = '''no'''
 
        user           = amandabackup
 
        group          = disk
'''Example of inetd service entry using bsdtcp authorization and assuming Amanda user is "amanda"
        groups         = yes
amanda         stream  tcp    nowait  amanda  /usr/lib/amanda/amandad     amandad -auth=bsdtcp amdump amindexd amidxtaped
        server          = /usr/lib/amanda/amandad
        server_args    = -auth='''bsdtcp''' amdump amindexd amidxtaped
        disable        = no
}


The ''bsdudp'' authentication requires minor modification to xinetd service entry. An example showing differences with ''bsd'' authentication entry:
The ''bsdudp'' authentication requires minor modification to xinetd service entry. An example showing differences with ''bsd'' authentication entry:
Line 120: Line 131:
  }
  }


=== inetd.conf example ===
When using ''inetd'', the ''only_from'' variable is controlled by your ''hosts.allow'' file on the local system.


Here is an example of using bsd authorization assuming Amanda user is "amanda"
==bsdtcp==
If you want to use bsdtcp authentication and are compiling from source code, you must specify the configure flag
  --with-bsdtcp-security
otherwise, amcheck will return messages like:
  Could not find security driver "bsdtcp" for host "yourhost". auth for this dle is invalid


amanda          dgram  udp    wait    amanda  /usr/lib/amanda/amandad      amandad -auth=bsd amdump amindexd amidxtaped
On the Amanda server the entries in the '''disklist''' need to have the '''auth''' parameter.


Using bsdudp authorization would be the same except for specifying "-auth=bsdudp" instead.
server.example.com    {
        comp-user-tar
        auth "bsdtcp"
        }    1


Here is an example of using bsdtcp authorization assuming Amanda user is "amanda"
This may also be set globally in the definition of the dumptype in '''amanda.conf'''


  amanda         stream  tcp    nowait  amanda  /usr/lib/amanda/amandad      amandad -auth=bsdtcp amdump amindexd amidxtaped
  define dumptype comp-user-tar {
        ...
         auth "bsdtcp"
        ...
}


When using ssh authorization, no inetd entry is needed.


If you are using TCP wrappers, your inetd entry may look like this assuming Amanda user is "amanda":
The ''bsdtcp'' authentication requires different x/inetd service entries.  The protocol will be ''tcp''.  An example ''bsdtcp'' authentication xinetd service entry for a machine that can do both backup and recovery (differences with ''bsd'' authentication entry is highlighted):
amanda          dgram  udp    wait    amanda  /usr/sbin/tcpd /usr/lib/amanda/amandad -auth=bsd amdump amindexd amidxtaped


== .amandahosts configuration file changes ==
service amanda
{
        only_from      = amandaserver.example.com amandaclient.example.com
        socket_type    = '''stream'''
        protocol        = '''tcp'''
        wait            = '''no'''
        user            = amandabackup
        group          = disk
        groups          = yes
        server          = /usr/lib/amanda/amandad
        server_args    = -auth='''bsdtcp''' amdump amindexd amidxtaped
        disable        = no
}


The ''.amandahosts'' file is located in the home directory of the backup user (For example: ''/var/lib/amanda''). This file should be readable and writable only by the backup user.  
== Backing up an older Amanda 2.4 client ==
 
Older versions of Amanda client software (2.5.0 or earlier) have only the protocol "bsd"
The format of .amandahosts is
available.
 
<FQDN of the server> <backup user> <service(s)>
 
FQDN is fully qualified domain name. The server can contact the local machine as backup server to perform the service(s).
 
Example:
The ''.amandahosts'' file on the Amanda client should have
amandaserver.example.com amandabackup amdump
 
The ''.amandahosts'' file on the Amanda server should have
 
amandaclient1.example.com root amindexd amidxtaped


== Backup an Older amanda 2.4 client ==
An Amanda 2.5 or later server (using user "amandabackup") may still back up an Amanda 2.4 client
An amanda 2.5 server (user "amandabackup") can backup a amanda 2.4 client
(user "amanda").  For this, the server must use a ''auth "bsd"'' for communication, though a global ''auth "bsdtcp"'' entry can be overridden in special dumptype defines for use on older clients.
(user "amanda").  For this the server must use a ''auth "bsd"'' for communication, though a global ''auth "bsdtcp"'' entry can be overridden in special dumptype defines for use on older clients.


'''Example of xinetd server entry that using auth "bsd" on an older amanda 2.4 client (using user "amanda")'''
'''Example of an inetd file entry on an older Amanda 2.4 client (using user "amanda") that only supports bsd authentication (and not as many amandad server arguments)'''
amanda          dgram  udp    wait    amanda  /usr/lib/amanda/amandad      amandad
'''Example of an xinetd file on an older amanda 2.4 client (using user "amanda") that only supports bsd authentication (and not some of the more current parameters such as "server_args")'''
  service amanda
  service amanda
  {
  {
Line 173: Line 192:
         disable        = no  
         disable        = no  
  }
  }
The ".amandahosts" file still will need to specify that the server connection is from a "amandabackup" user.
The client's ".amandahosts" file will need to specify that the server connection is from user "amandabackup".
   amandaclient.example.com amandabackup amdump
   amandaserver.example.com amandabackup amdump

Revision as of 04:03, 14 November 2008

XXX User:Dustin: Needs TLC, merging

Other languages: [[::How To:Configure bsdtcp authentication|English]] {{#ifexist: {{#if: | | {{#if: | :}}How To:Configure bsdtcp authentication}}/Fr |  • {{#if: |français| [[::How To:Configure bsdtcp authentication/Fr|français]]}}|}}

{{#ifexist: {{#if: | | {{#if: | :}}How To:Configure bsdtcp authentication}}/Zh-cn |  • {{#if: |中文（中国大陆）| [[::How To:Configure bsdtcp authentication/Zh-cn|中文（中国大陆）]]}}|}}



Work in Progess

As for network services, commonly inetd or xinetd, the initial version of Amanda used only bsd authentication. Starting with Amanda 2.5, bsdudp and bsdtcp authentication methods were introduced (for more information, please see Server/Client_authentication). Although the bsd authentication method remains to be the default for Amanda source code (Nov 2008), some packaged versions of Amanda come pre-configured to use the newer and preferred bsdtcp authentication method such as the Zmanda Community Edition packages.

Once you decide which of these authentication methods you will go with, a network service entry for Amandad (Amanda client process) must be configured correctly on each Amanda client for the chosen authentication method. This configuration is necessary for the backup process amdump which runs on the Amanda server.

This article will progressively march through inetd and xinetd examples of bsd, bsdudp, and bsdtcp authentication methods for Amanda 2.5 and later. For configuration of a pre-2.5 client (bsd only), please see Backing up an older Amanda 2.4 client at the bottom of this page.

.amandahosts file

It is very common for Amanda to be compiled to use the .amandahosts file to control access on clients and server with bsd, bsdudp, and bsdtcp authentications.

The .amandahosts file is located in the Amanda user's home directory, commonly /var/lib/amanda. This file should be readable and writable only by the Amanda backup user.

The format of .amandahosts is 

<amandaserver.example.com> <backup_user> <service(s)>

The first field is the fully qualified domain name of the server which is being granted access to the local machine as backup_user to perform service(s).

Examples:

The .amandahosts file on an Amanda client should have 

amandaserver.example.com amandabackup amdump

The .amandahosts file on the Amanda server should have 

amandaclient1.example.com root amindexd amidxtaped

bsd

client

inetd

When using inetd, Amanda server access is controlled by the hosts.allow file on the same machine. Example of using bsd authorization for inetd server assuming Amanda user is "amanda" 

amanda          dgram   udp     wait    amanda  /usr/lib/amanda/amandad      amandad -auth=bsd amdump amindexd amidxtaped

xinetd

For xinetd, access to your Amanda server is controlled by the only_from parameter.

Template for Amanda client /etc/xinet.d/amanda file 

 service amanda
 {
       only_from               = <Amanda server>
       socket_type             = dgram
       protocol                = udp
       wait                    = yes
       user                    = <amanda backup user>
       group                   = <amanda backup user group id>
       groups                  = yes
       server                  = <absolute path to amandad>
       server_args             = -auth=bsd amdump
       disable                 = no
 }

Example xinetd.d amanda client service file with backup user "amandabackup" 

service amanda
{
       only_from       = amandaserver.example.com
       socket_type     = dgram
       protocol        = udp
       wait            = yes
       user            = amandabackup
       group           = disk
       groups          = yes
       server          = /usr/lib/amanda/amandad
       server_args     = -auth=bsd amdump
       disable         = no 
}

server

If an Amanda server (tape server) will also be a backup client to itself using bsd authentication, it will use the same client configuration. However, as the Amanda server is also the recovery server for all clients via the amrecover command, the x/inetd service entry on the Amanda server should also include amindexd and amidxtaped amandad server arguments.

inetd

When using inetd, Amanda server access is controlled by the hosts.allow file on the same machine.

Example of using bsd authorization for inetd server assuming Amanda user is "amanda" 

amanda          dgram   udp     wait    amanda  /usr/lib/amanda/amandad      amandad -auth=bsd amdump amindexd amidxtaped

If you are using TCP wrappers, your inetd entry may look like this assuming Amanda user is "amanda": 

amanda          dgram   udp     wait    amanda  /usr/sbin/tcpd /usr/lib/amanda/amandad -auth=bsd amdump amindexd amidxtaped

xinetd

For xinetd, access to your Amanda server is controlled by the only_from parameter.

Example of xinetd server entry that uses bsd for being a backup client to itself as well as a recovery server for all clients 

service amanda
{
       only_from       = amandaserver.example.com amandaclient1.example.com amandaclient2.example.com
       socket_type     = dgram
       protocol        = udp
       wait            = yes
       user            = amandabackup
       group           = disk
       groups          = yes
       server          = /usr/lib/amanda/amandad
       server_args     = -auth=bsd amdump amindexd amidxtaped
       disable         = no 
}


bsdudp

If you want to use bsdudp authentication and are compiling from source code, you must specify the configure flag 

 --with-bsdudp-security

otherwise, amcheck will return messages like: 

 Could not find security driver "bsdudp" for host "yourhost". auth for this dle is invalid


Example of inetd service entry using bsdtcp authorization and assuming Amanda user is "amanda" 

amanda          stream  tcp     nowait  amanda  /usr/lib/amanda/amandad      amandad -auth=bsdtcp amdump amindexd amidxtaped

The bsdudp authentication requires minor modification to xinetd service entry. An example showing differences with bsd authentication entry: 

service amanda
{
       only_from       = amandaserver.example.com amandaclient.example.com
       socket_type     = dgram
       protocol        = udp
       wait            = yes
       user            = amandabackup
       group           = disk
       groups          = yes
       server          = /usr/lib/amanda/amandad
       server_args     = -auth=bsdudp amdump amindexd amidxtaped
       disable         = no 
}


bsdtcp

If you want to use bsdtcp authentication and are compiling from source code, you must specify the configure flag 

 --with-bsdtcp-security

otherwise, amcheck will return messages like: 

 Could not find security driver "bsdtcp" for host "yourhost". auth for this dle is invalid

On the Amanda server the entries in the disklist need to have the auth parameter. 

server.example.com    {
       comp-user-tar
       auth "bsdtcp"
       }    1

This may also be set globally in the definition of the dumptype in amanda.conf 

define dumptype comp-user-tar {
        ...
        auth "bsdtcp"
        ...
}


The bsdtcp authentication requires different x/inetd service entries. The protocol will be tcp. An example bsdtcp authentication xinetd service entry for a machine that can do both backup and recovery (differences with bsd authentication entry is highlighted): 

service amanda
{
       only_from       = amandaserver.example.com amandaclient.example.com
       socket_type     = stream
       protocol        = tcp
       wait            = no
       user            = amandabackup
       group           = disk
       groups          = yes
       server          = /usr/lib/amanda/amandad
       server_args     = -auth=bsdtcp amdump amindexd amidxtaped
       disable         = no 
}

Backing up an older Amanda 2.4 client

Older versions of Amanda client software (2.5.0 or earlier) have only the protocol "bsd" available.

An Amanda 2.5 or later server (using user "amandabackup") may still back up an Amanda 2.4 client (user "amanda"). For this, the server must use a auth "bsd" for communication, though a global auth "bsdtcp" entry can be overridden in special dumptype defines for use on older clients.

Example of an inetd file entry on an older Amanda 2.4 client (using user "amanda") that only supports bsd authentication (and not as many amandad server arguments) 

amanda          dgram   udp     wait    amanda  /usr/lib/amanda/amandad      amandad

Example of an xinetd file on an older amanda 2.4 client (using user "amanda") that only supports bsd authentication (and not some of the more current parameters such as "server_args") 

service amanda
{
       only_from       = amandaserver.example.com
       socket_type     = dgram
       protocol        = udp
       wait            = yes
       user            = amanda
       group           = disk
       groups          = yes
       server          = /usr/lib/amanda/amandad
       disable         = no 
}

The client's ".amandahosts" file will need to specify that the server connection is from user "amandabackup". 

 amandaserver.example.com amandabackup amdump
Retrieved from ‘http://wiki.zmanda.com/index.php?title=How_To:Configure_bsdtcp_authentication&oldid=6412’