3 .\" Author: Jean-Louis Martineau <martineau@zmanda.com>
4 .\" Generator: DocBook XSL Stylesheets vsnapshot_8273 <http://docbook.sf.net/>
6 .\" Manual: Miscellanea
7 .\" Source: Amanda 3.1.0
10 .TH "AMANDA\-AUTH" "7" "06/01/2010" "Amanda 3\&.1\&.0" "Miscellanea"
11 .\" -----------------------------------------------------------------
12 .\" * set default formatting
13 .\" -----------------------------------------------------------------
14 .\" disable hyphenation
16 .\" disable justification (adjust text to left margin only)
18 .\" -----------------------------------------------------------------
19 .\" * MAIN CONTENT STARTS HERE *
20 .\" -----------------------------------------------------------------
22 amanda-auth \- Communication/Authentication methods between Amanda server and client
25 Amanda offers 7 methods of communication between Amanda server (sometimes also called the tape server) and clients, each with its own authentication method\&. The desired communication method is specified by the
27 parameter in the amanda\&.conf file (\fBamanda.conf\fR(5)) commonly as a dumptype\&. Valid values to the
37 \fBssh\fR\&. Please note that
39 will be removed in the next release\&. The authentication and communication method is used during the backup process
41 (amdump(8)) as well as the recovery process
44 .SH "COMPILATION AND GENERAL INFORMATION"
46 The communication method and thus type of authentication that will be used by the Amanda server is specified by the
48 parameter in the dumptype for each disklist entry (DLE)\&. The
50 parameter thus may be easily and globally specified in the "global" dumptype\&. If
54 communication method is used\&. See
56 for more information on Amanda configuration and dumptypes, and
58 for more information on disklists\&.
60 On the client side, the Amanda daemon
62 validates the connection depending on the value of the
64 argument passed to it (see Amanda(8))\&. Also, when it comes to recovery, the
66 parameter can be specified in the
67 \fBamanda-client.conf\fR(5)
68 file to specify the communication method to be used by the client to the server\&.
70 When Amanda is being built from source code, desired communication and thus authentication methods (shown as "Authentication") must be specified as configure options at compilation time\&.
73 Authentication Configure option(s)
74 bsd \-\-with\-bsd\-security \-\-with\-amandahosts (pre\-2\&.6)
75 bsdtcp \-\-with\-bsdtcp\-security \-\-with\-amandahosts (pre\-2\&.6)
76 bsdudp \-\-with\-bsdudp\-security \-\-with\-amandahosts (pre\-2\&.6)
77 krb5 \-\-with\-krb5\-security
78 local (always included)
79 rsh \-\-with\-rsh\-security
80 ssh \-\-with\-ssh\-security
83 There are additional configure options for
87 to allow for specifying explicit UDP and TCP port ranges\&.
90 \-\-with\-udpportrange
91 \-\-with\-tcpportrange
92 \-\-with\-low\-tcpportrange
97 below for more information\&.
99 There are additional configure options for Kerberos if you so desire\&. All but the last option are for Kerberos 4\&. Defaults shown in square brackets\&.
102 \-\-with\-server\-principal=ARG server host principal [amanda]
103 \-\-with\-server\-instance=ARG server host instance []
104 \-\-with\-server\-keyfile=ARG server host key file [/\&.amanda]
105 \-\-with\-client\-principal=ARG client host principal [rcmd]
106 \-\-with\-client\-instance=ARG client host instance [HOSTNAME_INSTANCE]
107 \-\-with\-client\-keyfile=ARG client host key file [KEYFILE]
108 \-\-with\-ticket\-lifetime=ARG ticket lifetime [128]
109 \-\-with\-krb4\-security=DIR where libkrb\&.a lives [see below]
110 \-\-with\-krb5\-security=DIR where libkrb\&.a lives [see below]
113 If configuring with \-\-with\-krb4\-security and/or \-\-with\-krb5\-security, the configure script will search under /usr/kerberos/lib, /usr/cygnus/lib, /usr/lib, and /opt/kerberos/lib for the kerberos bits, libkrb\&.a, in this order\&. Kerberos support will not be added if it does not find them\&. If the kerberos bits are found under some other hierarchy, you can specify this via \-\-with\-krb5\-security=DIR and/or \-\-with\-krb4\-security=DIR, where DIR is where the kerberos bits live\&. The configure script will then look in the \'lib\' directory under this hierarchy for libkrb\&.a\&.
117 parameter selects a communication/authentication method to use between the client and the backup server\&. These methods are described each in their own section below\&.
118 .SH "BSD, BSDUDP, AND BSDTCP COMMUNICATION AND AUTHENTICATION"
120 For additional information including example configurations, see http://wiki\&.zmanda\&.com/index\&.php/Configuring_bsd/bsdudp/bsdtcp_authentication\&.
126 communication methods use either UDP, TCP, or both protocols operating as a network service to authenticate and exchange data between server and clients\&.
128 In addition to compilation and general configuration (see
129 \fBCOMPILATION AND GENERAL INFORMATION\fR
130 above), the authentication method that the client is configured to receive is specified by the
132 parameter in the network service configuration for Amanda\&. The authentication method used by an Amanda client to reach the server during recovery is the authentication method specified by the
134 parameter in the client\'s Amanda network service configuration or in its amanda\-client\&.conf file (see amanda\-client\&.conf(5))\&.
136 By default, Amanda use the "amanda" service name and associated port set in /etc/services\&. It can be changed by setting the dumptype
138 option to a different port number or a different service name\&. All examples are for the service name "amanda" that uses the default port 10080\&.
139 .SS "\&.amandahosts file"
141 Servers and clients using the bsd, bsdudp, and bsdtcp authentication methods refer to the \&.amandahosts file to control access\&. Amanda should be compiled for this access control if one of these methods will be used and is the default compilation option for Amanda 2\&.6 (use \-\-with\-amandahosts when compiling pre\-2\&.6 versions of Amanda)\&.
143 Amanda looks for the \&.amandahosts file in the Amanda user\'s home directory, commonly /var/lib/amanda\&.
145 Each authorization is on its own line in the following format
151 \fIservice\&.\&.\&.\fR
156 is ommitted, it defaults to the user running
157 \fBamandad\fR, i\&.e\&. the user listed in the
161 configuration file\&.
163 \fIservice\&.\&.\&.\fR
164 is a space\-delimited list of services the client is authorized to execute:
170 (a shortcut for the previous four services which are required on clients),
172 \fBamidxtaped\fR\&. The last two services are required on a server for clients to connect to it using
175 If service is omitted, it defaults to
176 \fBnoop selfcheck sendsize sendbackup\fR
177 (which is equivalent to
180 Example of the \&.amandahosts file on an Amanda client
183 \fBamandaserver\&.example\&.com amandabackup amdump\fR
186 Example of the \&.amandahosts file on an Amanda server
189 \fBamandaclient1\&.example\&.com root amindexd amidxtaped\fR
191 .SS "bsd communication and authentication"
193 The authentication is done using \&.amandahosts file in the Amanda user\'s home directory\&. The protocol between Amanda server and client is UDP\&. The number of disk list entries (DLEs)\-\-number of Amanda clients\-\-is limited by the UDP packet size\&. This authentication protocol will use a different port for each data stream (see PORT USAGE below)
194 .SS "bsdudp communication and authentication"
196 The authentication is done using \&.amandahosts files in the Amanda user\'s home directory\&. It uses UDP protocol between Amanda server and client for data and hence the number of DLEs is limited by the UDP packet size\&. It uses one TCP port to establish the connection and multiplexes all data streams using one port on the server (see PORT USAGE below)\&.
197 .SS "bsdtcp communication and authentication"
199 The authentication is done using \&.amandahosts files in the backup user\'s (for example: amandabackup) home directory\&. It uses TCP protocol between Amanda server and client\&. On the client, two reserved ports are used\&. On the server, all data streams are multiplexed to one port (see PORT USAGE below)\&.
200 .SS "USING INETD SERVER"
202 Template for Amanda client inetd service entry
205 \fI service_name\fR \fIsocket_type\fR \fIprotocol\fR \fIwait/nowait\fR \fIamanda_backup_user\fR \fIabsolute_path_to_amandad\fR amandad \fIserver_args\fR
208 Client example of using
210 authorization for inetd server given Amanda user is "amandabackup":
213 \fB amanda dgram udp wait amandabackup /path/to/amandad amandad \-auth=bsd amdump\fR
216 The same could be used for
218 if specifying \-auth=bsdudp instead of \-auth=bsd\&.
220 Client example of using
222 authorization for inetd server given Amanda user is "amandabackup":
225 \fB amanda stream tcp nowait amanda /path/to/amandad amandad \-auth=bsdtcp amdump\fR
231 would typically be added at the end of the line as
233 server arguments for an Amanda server\&.
235 Server example of using
237 authorization for inetd server given Amanda user is "amandabackup":
240 \fB amanda stream tcp nowait amanda /path/to/amandad amandad \-auth=bsdtcp amdump amindexd amidxtaped\fR
243 For Amanda version 2\&.5\&.0 and earlier, remember that neither
247 are supported and the Amanda daemon
249 accepts no arguments\&. Because of the latter,
251 as of Amanda version 2\&.5\&.1 is not compatible with 2\&.5\&.0 and earlier servers\&. Thus, servers that are 2\&.5\&.0 or earlier must, in addition to the
257 Amanda services as their own network services, amandaidx and amidxtape, respectively (see below)\&.
259 There are no compatibility issues if server and clients are all 2\&.5\&.0 or earlier\&. If your server is 2\&.5\&.1 or later, you can still have clients that are 2\&.5\&.0 and earlier although you must then use
261 communication/authentication with these clients and must also run
265 Amanda services on the server as their own network services, amandaidx and amidxtape, respectively (see below)\&. If you have a server that is 2\&.5\&.0 and earlier, clients of a later version on which you wish to run
269 instead and, again, the server must be running the amandaidx and amidxtape network services\&.
271 Example of amindexd and amidxtaped Amanda daemon services configured as their own network services for a 2\&.5\&.0 or earlier server or a newer server having 2\&.5\&.0 or earlier clients
274 \fB amandaidx stream tcp nowait amanda /usr/local/libexec/amanda/current/amindexd amindexd\fR
275 \fB amidxtape stream tcp nowait amanda /usr/local/libexec/amanda/current/amidxtaped amidxtaped\fR
277 .SS "USING XINETD SERVER"
279 Template for Amanda client xinetd service file
284 only_from = \fIAmanda server\fR
285 socket_type = \fIsocket type\fR
286 protocol = \fIprotocol\fR
288 user = \fIamanda backup user\fR
289 group = \fIamanda backup user group id\fR
291 server = \fIabsolute path to amandad\fR
292 server_args = \fIamandad server arguments\fR
299 parameter can be used with xinetd but is usually in addition to the primary form of access control via the \&.amandahosts file\&.
301 Client example of using
303 authorization for xinetd server and for Amanda user "amandabackup":
308 only_from = amandaserver\&.example\&.com
315 server = /path/to/amandad
316 server_args = \-auth=bsd amdump
321 The same could be used for
323 if specifying \-auth=bsdudp instead of \-auth=bsd\&.
325 Client example of using
327 authorization for xinetd server and for Amanda user "amandabackup":
332 only_from = amandaserver\&.example\&.com amandaclient\&.example\&.com
339 server = /path/to/amandad
340 server_args = \-auth=bsdtcp amdump
348 would typically be added as additional
351 for an Amanda server\&.
353 For Amanda version 2\&.5\&.0 and earlier, remember that neither
357 are supported and the Amanda daemon
359 accepts no arguments\&. Because of the latter,
361 as of Amanda version 2\&.5\&.1 is not compatible with 2\&.5\&.0 and earlier servers\&. Thus, servers that are 2\&.5\&.0 or earlier must, in addition to the
367 Amanda services as their own network services, amandaidx and amidxtape, respectively (see below)\&.
369 There are no compatibility issues if server and clients are all 2\&.5\&.0 or earlier\&. If your server is 2\&.5\&.1 or later, you can still have clients that are 2\&.5\&.0 and earlier although you must then use
371 communication/authentication with these clients and must also run
375 Amanda services on the server as their own network services, amandaidx and amidxtape, respectively (see below)\&. If you have a server that is 2\&.5\&.0 and earlier, clients of a later version on which you wish to run
379 instead and, again, the server must be running the amandaidx and amidxtape network services\&.
381 Example of amindexd and amidxtaped Amanda daemon services configured as their own network services for a 2\&.5\&.0 or earlier server or a newer server having 2\&.5\&.0 or earlier clients
391 server = /usr/local/libexec/amanda/amindexd
402 server = /usr/local/libexec/amanda/amidxtaped
408 List of TCP/UDP ports used by network service communication methods for Amanda server and client\&.
413 RPpAP = Reserved Port per Amanda Process
414 UPpDLE = Unreserved Port per DLE
415 [\&.\&.] = Configure options that can be used at compile time to define port ranges
417 Authentication Protocol Amanda server Amanda client
418 bsd udp 1 RPpAP [\-\-with\-udpportrange] 10080
419 tcp 1 UP [\-\-with\-tcpportrange] 3 UPpDLE [\-\-with\-tcpportrange]
420 bsdudp udp 1 RPpAP [\-\-with\-udpportrange] 10080
421 tcp 1 UP [\-with\-tcpportrange] 1 UPpDLE [\-\-with\-tcpportrange]
422 bsdtcp tcp 1 RPpAP [\-\-with\-low\-tcpportrange] 10080
425 Amanda server also uses two ports (dumper process) to communicate with the chunker/taper processes\&. These ports are in the range set by \-\-with\-tcpportrange\&.
427 You can override the default port ranges that Amanda was compiled with in each configuration using the
428 \fIreserved\-udp\-port\fR,
429 \fIreserved\-tcp\-port\fR, and
430 \fIunreserved\-tcp\-port\fR
431 parameters in amanda\&.conf and amanda\-client\&.conf configuration files (see
434 \fBamanda-client.conf\fR(5))\&.
435 .SH "KERBEROS COMMUNICATION AND AUTHENTICATION"
437 For more detail, see http://wiki\&.zmanda\&.com/index\&.php/Kerberos_authentication\&.
439 Amanda supports Kerberos 4 and 5 communication methods between Amanda server and client\&. Please note, however, that support for Kerberos 4 will be removed in the next release\&.
441 General information including compilation are given above (see
442 \fBCOMPILATION AND GENERAL INFORMATION\fR
443 above)\&. Below sections give specific Kerberos 4 and 5 information\&.
446 Please note that support for Kerberos 4 will be removed in the next release\&.
448 Kerberos 4 uses UDP protocol and the number of DLEs is limited by UDP packet size\&.
450 The kerberized AMANDA service uses a different port on the client hosts\&. The /etc/services line is:
454 And the /etc/inetd\&.conf line is:
457 kamanda dgram udp wait root /usr/local/libexec/amanda/amandad amandad \-auth=krb4
460 Note that you\'re running this as root, rather than as your dump user\&. AMANDA will set its uid down to the dump user at times it doesn\'t need to read the srvtab file, and give up root permissions entirely before it goes off and runs dump\&. Alternately you can change your srvtab files to be readable by user amanda\&.
462 The following dumptype options apply to krb4:
465 auth "krb4" # use krb4 auth for this host
466 # (you can mingle krb hosts and bsd \&.rhosts in one conf)
467 kencrypt # encrypt this filesystem over the net using the krb4
468 # session key\&. About 2x slower\&. Good for those root
469 # partitions containing your keyfiles\&. Don\'t want to
470 # give away the keys to an ethernet sniffer!
471 # This is currently always enabled\&. There is no
472 # way to disable it\&. This is a bug\&.
476 Kerberos 5 uses TCP and the server uses only one TCP port and data streams are multiplexed to this port\&.
479 The \fBkrb5\fR driver script defaults to:
482 * The lifetime of our tickets in minutes\&.
484 #define AMANDA_TKT_LIFETIME (12*60)
487 * The name of the service in /etc/services\&.
489 #define AMANDA_KRB5_SERVICE_NAME "k5amanda"
491 You can currently only override these by editing the source code\&.
493 The kerberized AMANDA service uses a different port on the client hosts\&. The /etc/services line is:
497 And the /etc/inetd\&.conf line is:
500 k5amanda stream tcp nowait root /usr/local/libexec/amanda/amandad amandad \-auth=krb5
503 Note that you\'re running this as root, rather than as your dump user\&. AMANDA will set its UID down to the dump user at times it doesn\'t need to read the keytab file, and give up root permissions entirely before it goes off and runs dump\&. Alternately you can change your keytab files to be readable by user amanda\&. You should understand the security implications of this before changing the permissions on the keytab\&.
505 The following dumptype options apply to
509 auth "krb5" # use krb5 auth for this host
510 # (you can mingle krb hosts and bsd \&.rhosts in one conf)
513 The principal and keytab files that Amanda uses must be set in the amanda\&.conf file for kerberos 5 dumps to work\&. You can hardcode this in the source code if you really want to (common\-src/krb5\-security\&.c)
523 krb5keytab "/etc/krb5\&.keytab\-amanda"
524 krb5principal "amanda/saidin\&.omniscient\&.com"
527 The principal in the second option must be contained in the first\&. The keytab should be readable by the amanda user (and definitely not world readable!) and is (obviously) on the server\&. In MIT\'s kadmin, the following:
530 addprinc \-randkey amanda/saidin\&.omniscient\&.com
531 ktadd \-k /etc/krb5\&.keytab\-amanda amanda/saidin\&.omniscient\&.com
534 will do the trick\&. You will obviously want to change the principal name to reflect something appropriate for the conventions at your site\&.
536 You must also configure each client to allow the amanda principal in for dumps\&.
538 There are several ways to go about authorizing a server to connect to a client\&.
540 The normal way is via a \&.k5amandausers file or a \&.k5login file in the client user\'s home directory\&. The determination of which file to use is based on the way you ran configure on AMANDA\&. By default, AMANDA will use \&.k5amandahosts, but if you configured with \-\-without\-amandahosts, AMANDA will use \&.k5login\&. (similar to the default for \&.rhosts/\&.amandahosts\-style security)\&. The \&.k5login file syntax is a superset of the default
542 \&.k5login\&. The routines to check it are implemented in amanda rather than using krb5_kuserok because the connections are actually gssapi based\&.
544 This \&.k5amandahosts/\&.k5login is a hybrid of the \&.amandahosts and a \&.k5login file\&. You can just list principal names, as in a \&.k5login file and the principal will be permitted in from any host\&. If you do NOT specify a realm, then there is no attempt to validate the realm (this is only really a concern if you have cross\-realm authentication set up with another realm or something else that allows you multiple realms in your kdc\&. If you do specify a realm, only that principal@realm will be permitted to connect\&.
546 You may prepend this with a hostname and whitespace, and only that principal (with optional realm as above) will be permitted to access from that hostname\&.
548 Here are examples of valid entries in the \&.k5amandahosts:
552 service/amanda@TEST\&.COM
553 dumpmaster\&.test\&.com service/amanda
554 dumpmaster\&.test\&.com service/amanda@TEST\&.COM
557 Rather than using a \&.k5amandahosts or \&.k5login file, the easiest way is to use a principal named after the destination user, (such as amanda@TEST\&.COM in our example) and not have either a \&.k5amandahosts or \&.k5login file in the destination user\'s home directory\&.
559 There is no attempt to verify the realm in this case (only a concern if you have cross\-realm authentication setup)\&.
560 .SH "LOCAL COMMUNICATION"
562 The Amanda server communicates with the client internally versus over the network, ie\&. the client is also the server\&.
564 This is the only method that requires no authentication as it is clearly not needed\&.
565 .SH "RSH COMMUNICATION AND AUTHENTICATION"
567 For more detail, see http://wiki\&.zmanda\&.com/index\&.php/Configuring_rsh_authentication\&.
569 The Amanda server communicates with its client as the Amanda user via the RSH protocol\&.
571 Please note that RSH protocol itself is insecure and should be used with caution especially on any servers and clients with public IPs\&.
573 Each Amanda client communicates with the server using one TCP port and all data streams from the client are multiplexed over one port\&. The number of Amanda clients is limited by the number of reserved ports available on the Amanda server\&. Some versions of RSH do not use reserved ports and, thus, this restriction is not valid\&.
575 General information including compilation is given above (see
576 \fBCOMPILATION AND GENERAL INFORMATION\fR
579 In addition to specifying the
581 field in dumptype definition, it might be required to specify
582 \fIclient_username\fR
585 fields\&. If the backup user name is different on the Amanda client, the user name is specified as
586 \fBclient_username\fR\&. If the location of the Amanda daemon
588 is different on the Amanda client, the location is specified as
594 define dumptype rsh_example {
597 client_username "amandabackup"
598 amandad_path "/usr/lib/exec/amandad"
602 .SH "SSH COMMUNICATION AND AUTHENTICATION"
604 For more detail, see http://wiki\&.zmanda\&.com/index\&.php/How_To:Set_up_transport_encryption_with_SSH\&.
606 Amanda client sends data to the server using SSH\&. SSH keys have to be set up so that Amanda server can communicate with its clients using SSH\&.
608 General information including compilation is given above (see \fBCOMPILATION AND GENERAL INFORMATION\fR above)\&.
610 SSH provides transport encryption and authentication\&. To set up an SSH authentication session, Amanda will run the equivalent of the following to start the backup process\&.
612 \fB /path/to/ssh \-l \fR\fB\fIuser_name\fR\fR\fB client\&.zmanda\&.com $libexecdir/amandad\fR
614 To use SSH, you need to set up SSH keys either by storing the passphrase in cleartext, using ssh\-agent, or using no passphrase at all\&. All of these options have security implications which should be carefully considered before adoption\&.
616 When you use a public key on the client to do data encryption (see http://wiki\&.zmanda\&.com/index\&.php/How_To:Set_up_data_encryption), you can lock away the private key in a secure place\&. Both, transport and storage will be encrypted with such a setup\&. See http://wiki\&.zmanda\&.com/index\&.php/Encryption for an overview of encryption options\&.
618 Enable SSH authentication and set the ssh_keys option in all DLEs for that host by adding the following to the DLE itself or to the corresponding dumptype in amanda\&.conf:
621 ssh_keys "/home/amandabackup/\&.ssh/id_rsa_amdump"
623 \fIssh_keys\fR is the path to the private key on the client\&. If the username to which Amanda should connect is different from the default, then you should also add
625 client_username "otherusername"
627 If your server \fBamandad\fR path and client \fBamandad\fR path are different, you should also add
629 amandad_path "/client/amandad/path"
631 For a marginal increase in security, prepend the keys used for AMANDA in the clients\' authorized_keys file with the following:
634 from="amanda_server\&.your\&.domain\&.com",no\-port\-forwarding,no\-X11\-forwarding,no\-agent\-forwarding,command="/absolute/path/to/amandad \-auth=ssh amdump"
637 This will limit that key to connect only from Amanda server and only be able to execute
640 In the same way, prepend the key used for AMANDA in the server\'s authorized_keys file with:
643 from="amanda_client\&.your\&.domain\&.com",no\-port\-forwarding,no\-X11\-forwarding,no\-agent\-forwarding,command="/absolute/path/to/amandad \-auth=ssh amindexd amidxtaped"
646 You can omit the from=\&.\&. option if you have too many clients to list, although this has obvious security implications\&.
648 Set ssh_keys and any other necessary options in /etc/amanda/amanda_client\&.conf:
652 ssh_keys "/root/\&.ssh/id_rsa_amrecover"
653 client_username "amanda"
654 amandad_path "/server/amandad/path"
657 Besides user keys, SSH uses host keys to uniquely identify each host, to prevent one host from impersonating another\&. Unfortunately, the only easy way to set up these host keys is to make a connection and tell SSH that you trust the identity:
660 $ ssh client1\&.zmanda\&.com
661 The authenticity of host \'client1\&.zmanda\&.com (192\&.168\&.10\&.1)\' can\'t be established\&.
662 RSA key fingerprint is 26:4e:df:a2:be:c8:cb:20:1c:68:8b:cc:c0:3b:8e:9d\&.
663 Are you sure you want to continue connecting (yes/no)?yes
666 As Amanda will not answer this question itself, you must manually make every connection (server to client and client to server) that you expect Amanda to make\&. Note that you must use the same username that Amanda will use (that is, ssh client and ssh client\&.domain\&.com are distinct)\&.
670 \fBamanda.conf\fR(5),
671 \fBamanda-client.conf\fR(5),
677 : http://wiki.zmanda.com/
680 \fBJean\-Louis Martineau\fR <\&martineau@zmanda\&.com\&>
682 Zmanda, Inc\&. (http://www\&.zmanda\&.com)
685 \fBDustin J\&. Mitchell\fR <\&dustin@zmanda\&.com\&>
687 Zmanda, Inc\&. (http://www\&.zmanda\&.com)
690 \fBPaul Yeatman\fR <\&pyeatman@zmanda\&.com\&>
692 Zmanda, Inc\&. (http://www\&.zmanda\&.com)
projects / debian / amanda / blob