How To:Configure bsdtcp authentication
| 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