1AMANDA-AUTH(7) Miscellanea AMANDA-AUTH(7)
2
6 amanda-auth - Communication/Authentication methods between Amanda
7 server and client
8
10 Amanda offers 7 methods of communication between Amanda server
11 (sometimes also called the tape server) and clients, each with its own
12 authentication method. The desired communication method is specified by
13 the auth parameter in the amanda.conf file (amanda.conf(5)) commonly as
14 a dumptype. Valid values to the auth parameter are bsd, bsdudp, bsdtcp,
15 krb5, local, rsh, and ssh. The authentication and communication method
16 is used during the backup process amdump (amdump(8)) as well as the
17 recovery process amrecover (amrecover(8)).
18
20 The communication method and thus type of authentication that will be
21 used by the Amanda server is specified by the auth parameter in the
22 dumptype for each disklist entry (DLE). The auth parameter thus may be
23 easily and globally specified in the "global" dumptype. If auth is not
24 specified, the bsdtcp communication method is used. See amanda.conf(5)
25 for more information on Amanda configuration and dumptypes, and
26 disklist(5) for more information on disklists.
27 On the client side, the Amanda daemon amandad validates the connection
29 depending on the value of the auth argument passed to it (see
30 Amanda(8)). Also, when it comes to recovery, the auth parameter can be
31 specified in the amanda-client.conf(5) file to specify the
32 communication method to be used by the client to the server.
33 When Amanda is being built from source code, desired communication and
35 thus authentication methods (shown as "Authentication") must be
36 specified as configure options at compilation time.
37 Authentication Configure option(s)
39 bsd --with-bsd-security --with-amandahosts (pre-2.6)
40 bsdtcp --with-bsdtcp-security --with-amandahosts (pre-2.6)
41 bsdudp --with-bsdudp-security --with-amandahosts (pre-2.6)
42 krb5 --with-krb5-security
43 local (always included)
44 rsh --with-rsh-security
45 ssh --with-ssh-security
46 There are additional configure options for bsd, bsdudp, and bsdtcp to
48 allow for specifying explicit UDP and TCP port ranges.
49 --with-udpportrange
51 --with-tcpportrange
52 --with-low-tcpportrange
53 See PORT USAGE below for more information.
55 There are additional configure options for Kerberos if you so desire.
57 All but the last option are for Kerberos 4. Defaults shown in square
58 brackets.
59 --with-server-principal=ARG server host principal [amanda]
61 --with-server-instance=ARG server host instance []
62 --with-server-keyfile=ARG server host key file [/.amanda]
63 --with-client-principal=ARG client host principal [rcmd]
64 --with-client-instance=ARG client host instance [HOSTNAME_INSTANCE]
65 --with-client-keyfile=ARG client host key file [KEYFILE]
66 --with-ticket-lifetime=ARG ticket lifetime [128]
67 --with-krb5-security=DIR where libkrb.a lives [see below]
68 If configuring with --with-krb5-security, the configure script will
70 search under /usr/kerberos/lib, /usr/cygnus/lib, /usr/lib, and
71 /opt/kerberos/lib for the kerberos bits, libkrb.a, in this order.
72 Kerberos support will not be added if it does not find them. If the
73 kerberos bits are found under some other hierarchy, you can specify
74 this via --with-krb5-security=DIR where DIR is where the kerberos bits
75 live. The configure script will then look in the 'lib' directory under
76 this hierarchy for libkrb.a.
77 The auth parameter selects a communication/authentication method to use
79 between the client and the backup server. These methods are described
80 each in their own section below.
81 Usernames
83 When Amanda is built, a username is specified with the --with-user
84 option. Most Amanda processes run under this user's identity, to
85 minimize security risks. In binary distributions, this username is
86 usually one of 'amanda', 'amandabackup', or 'backup'. The examples
87 below use 'amandabackup' since it is unambiguous. You may need to
88 adjust accordingly for your system.
89 Authenticated Peer Hostnames
91 Amanda's authentication mechanisms provide an authenticated hostname of
92 the system on the other end of the connection, which is used to
93 restrict access to only particular hosts. The degree of
94 "authentication" performed on this hostname varies with the
95 authentication mechanism, and is discussed below.
96
98 For additional information including example configurations, see
99 http://wiki.zmanda.com/index.php/Configuring_bsd/bsdudp/bsdtcp_authentication.
100 The bsd, bsdudp, and bsdtcp communication methods use either UDP, TCP,
102 or both protocols operating as a network service to authenticate and
103 exchange data between server and clients.
104 The authentication proceeds as follows: for a new, incoming connection,
106 Amanda verifies that the source port is in the reserved range (less
107 than 1024), which for UNIX hosts suggests that the remote user has root
108 privileges. Amanda then verifies that the reverse DNS for the remote
109 address matches the forward DNS; that is, that the address maps to a
110 hostname which maps back to the same address. Finally, the remote
111 system must provide a username that matches the username in
112 .amandahosts.
113 In addition to compilation and general configuration (see COMPILATION
115 AND GENERAL INFORMATION above), the authentication method that the
116 client is configured to receive is specified by the auth parameter in
117 the network service configuration for Amanda. The authentication method
118 used by an Amanda client to reach the server during recovery is the
119 authentication method specified by the auth parameter in the client's
120 Amanda network service configuration or in its amanda-client.conf file
121 (see amanda-client.conf(5)).
122 By default, Amanda use the "amanda" service name and associated port
124 set in /etc/services. It can be changed by setting the dumptype
125 client-port option to a different port number or a different service
126 name. All examples are for the service name "amanda" that uses the
127 default port 10080.
128 .amandahosts file
130 Servers and clients using the bsd, bsdudp, and bsdtcp authentication
131 methods refer to the .amandahosts file to control access. Amanda should
132 be compiled for this access control if one of these methods will be
133 used and is the default compilation option for Amanda 2.6 (use
134 --with-amandahosts when compiling pre-2.6 versions of Amanda).
135 Amanda looks for the .amandahosts file in the Amanda user's home
137 directory, commonly /var/lib/amanda.
138 Each authorization is on its own line in the following format
140 hostname [ username [ service... ] ]
142 If username is ommitted, it defaults to the user running amandad, i.e.
144 the user listed in the inetd or xinetd configuration file.
145 service... is a space-delimited list of services the client is
147 authorized to execute: noop, selfcheck, sendsize, sendbackup, amdump (a
148 shortcut for the previous four services which are required on clients),
149 amindexd, and amidxtaped. The last two services are required on a
150 server for clients to connect to it using amrecover.
151 If service is omitted, it defaults to noop selfcheck sendsize
153 sendbackup (which is equivalent to amdump).
154 Example of the .amandahosts file on an Amanda client, where
156 'amandabackup' is the Amanda dumpuser.
157 amandaserver.example.com amandabackup amdump
159 Example of the .amandahosts file on an Amanda server
161 amandaclient1.example.com root amindexd amidxtaped
163 bsd communication and authentication
165 The authentication is done using .amandahosts file in the Amanda user's
166 home directory. The protocol between Amanda server and client is UDP.
167 The number of disk list entries (DLEs)--number of Amanda clients--is
168 limited by the UDP packet size. This authentication protocol will use a
169 different port for each data stream (see PORT USAGE below)
170 bsdudp communication and authentication
172 The authentication is done using .amandahosts files in the Amanda
173 user's home directory. It uses UDP protocol between Amanda server and
174 client for data and hence the number of DLEs is limited by the UDP
175 packet size. It uses one TCP port to establish the connection and
176 multiplexes all data streams using one port on the server (see PORT
177 USAGE below).
178 bsdtcp communication and authentication
180 The authentication is done using .amandahosts files in the backup
181 user's (for example: amandabackup) home directory. It uses TCP protocol
182 between Amanda server and client. On the client, two reserved ports are
183 used. On the server, all data streams are multiplexed to one port (see
184 PORT USAGE below).
185 USING INETD SERVER
187 Template for Amanda client inetd service entry
188 service_name socket_type protocol wait/nowait amanda_backup_user absolute_path_to_amandad amandad server_args
190 Client example of using bsd authorization for inetd server given Amanda
192 user is "amandabackup":
193 amanda dgram udp wait amandabackup /path/to/amandad amandad -auth=bsd amdump
195 The same could be used for bsdudp if specifying -auth=bsdudp instead of
197 -auth=bsd.
198 Client example of using bsdtcp authorization for inetd server given
200 Amanda user is "amandabackup":
201 amanda stream tcp nowait amandabackup /path/to/amandad amandad -auth=bsdtcp amdump
203 amindexd and amidxtaped would typically be added at the end of the line
205 as amandad server arguments for an Amanda server.
206 Server example of using bsdtcp authorization for inetd server given
208 Amanda user is "amandabackup":
209 amanda stream tcp nowait amandabackup /path/to/amandad amandad -auth=bsdtcp amdump amindexd amidxtaped
211 For Amanda version 2.5.0 and earlier, remember that neither bsdudp nor
213 bsdtcp are supported and the Amanda daemon amandad accepts no
214 arguments. Because of the latter, amrecover as of Amanda version 2.5.1
215 is not compatible with 2.5.0 and earlier servers. Thus, servers that
216 are 2.5.0 or earlier must, in addition to the amanda service, run
217 amindexd and amidxtaped Amanda services as their own network services,
218 amandaidx and amidxtape, respectively (see below).
219 There are no compatibility issues if server and clients are all 2.5.0
221 or earlier. If your server is 2.5.1 or later, you can still have
222 clients that are 2.5.0 and earlier although you must then use bsd
223 communication/authentication with these clients and must also run
224 amindexd and amidxtaped Amanda services on the server as their own
225 network services, amandaidx and amidxtape, respectively (see below). If
226 you have a server that is 2.5.0 and earlier, clients of a later version
227 on which you wish to run amrecover must use amoldrecover instead and,
228 again, the server must be running the amandaidx and amidxtape network
229 services.
230 Example of amindexd and amidxtaped Amanda daemon services configured as
232 their own network services for a 2.5.0 or earlier server or a newer
233 server having 2.5.0 or earlier clients
234 amandaidx stream tcp nowait amandabackup /usr/local/libexec/amanda/current/amindexd amindexd
236 amidxtape stream tcp nowait amandabackup /usr/local/libexec/amanda/current/amidxtaped amidxtaped
237 USING XINETD SERVER
239 Template for Amanda client xinetd service file
240 service amanda
242 {
243 only_from = Amanda server
244 socket_type = socket type
245 protocol = protocol
246 wait = yes/no
247 user = amanda backup user
248 group = amanda backup user group id
249 groups = yes
250 server = absolute path to amandad
251 server_args = amandad server arguments
252 disable = no
253 }
254 The only_from parameter can be used with xinetd but is usually in
256 addition to the primary form of access control via the .amandahosts
257 file.
258 Client example of using bsd authorization for xinetd server and for
260 Amanda user "amandabackup":
261 service amanda
263 {
264 only_from = amandaserver.example.com
265 socket_type = dgram
266 protocol = udp
267 wait = yes
268 user = amandabackup
269 group = disk
270 groups = yes
271 server = /path/to/amandad
272 server_args = -auth=bsd amdump
273 disable = no
274 }
275 The same could be used for bsdudp if specifying -auth=bsdudp instead of
277 -auth=bsd.
278 Client example of using bsdtcp authorization for xinetd server and for
280 Amanda user "amandabackup":
281 service amanda
283 {
284 only_from = amandaserver.example.com amandaclient.example.com
285 socket_type = stream
286 protocol = tcp
287 wait = no
288 user = amandabackup
289 group = disk
290 groups = yes
291 server = /path/to/amandad
292 server_args = -auth=bsdtcp amdump
293 disable = no
294 }
295 amindexd and amidxtaped would typically be added as additional amandad
297 server_args for an Amanda server.
298 For Amanda version 2.5.0 and earlier, remember that neither bsdudp nor
300 bsdtcp are supported and the Amanda daemon amandad accepts no
301 arguments. Because of the latter, amrecover as of Amanda version 2.5.1
302 is not compatible with 2.5.0 and earlier servers. Thus, servers that
303 are 2.5.0 or earlier must, in addition to the amanda service, run
304 amindexd and amidxtaped Amanda services as their own network services,
305 amandaidx and amidxtape, respectively (see below).
306 There are no compatibility issues if server and clients are all 2.5.0
308 or earlier. If your server is 2.5.1 or later, you can still have
309 clients that are 2.5.0 and earlier although you must then use bsd
310 communication/authentication with these clients and must also run
311 amindexd and amidxtaped Amanda services on the server as their own
312 network services, amandaidx and amidxtape, respectively (see below). If
313 you have a server that is 2.5.0 and earlier, clients of a later version
314 on which you wish to run amrecover must use amoldrecover instead and,
315 again, the server must be running the amandaidx and amidxtape network
316 services.
317 Example of amindexd and amidxtaped Amanda daemon services configured as
319 their own network services for a 2.5.0 or earlier server or a newer
320 server having 2.5.0 or earlier clients
321 service amandaidx
323 {
324 socket_type = stream
325 protocol = tcp
326 wait = no
327 user = amanda
328 group = disk
329 server = /usr/local/libexec/amanda/amindexd
330 disable = no
331 }
332 service amidxtape
334 {
335 socket_type = stream
336 protocol = tcp
337 wait = no
338 user = amanda
339 group = disk
340 server = /usr/local/libexec/amanda/amidxtaped
341 disable = no
342 }
343 PORT USAGE
345 List of TCP/UDP ports used by network service communication methods for
346 Amanda server and client.
347 Key:
349 UP = Unreserved Port
350 RPpAP = Reserved Port per Amanda Process
351 UPpDLE = Unreserved Port per DLE
352 [..] = Configure options that can be used at compile time to define port ranges
353 Authentication Protocol Amanda server Amanda client
355 bsd udp 1 RPpAP [--with-udpportrange] 10080
356 tcp 1 UP [--with-tcpportrange] 3 UPpDLE [--with-tcpportrange]
357 bsdudp udp 1 RPpAP [--with-udpportrange] 10080
358 tcp 1 UP [-with-tcpportrange] 1 UPpDLE [--with-tcpportrange]
359 bsdtcp tcp 1 RPpAP [--with-low-tcpportrange] 10080
360 Amanda server also uses two ports (dumper process) to communicate with
362 the chunker/taper processes. These ports are in the range set by
363 --with-tcpportrange.
364 You can override the default port ranges that Amanda was compiled with
366 in each configuration using the reserved-udp-port, reserved-tcp-port,
367 and unreserved-tcp-port parameters in amanda.conf and
368 amanda-client.conf configuration files (see amanda.conf(5) and amanda-
369 client.conf(5)).
370 Authenticated Peer Hostnames with BSD Authentications
372 The BSD authentication mechanisms only verify that the remote host's
373 DNS is configured correctly and that the remote user has access to
374 reserved ports. As such, the peer hostname should only be trusted to
375 the extent that the local DNS service is trusted.
376
378 For more detail, see
379 http://wiki.zmanda.com/index.php/Kerberos_authentication.
380 Amanda supports Kerberos 5 communication methods between Amanda server
382 and client.
383 General information including compilation are given above (see
385 COMPILATION AND GENERAL INFORMATION above).
386 Kerberos 5 uses TCP and the server uses only one TCP port and data
388 streams are multiplexed to this port.
389 The krb5 driver script defaults to:
392 /*
393 * The lifetime of our tickets in minutes.
394 */
395 #define AMANDA_TKT_LIFETIME (12*60)
396 /*
398 * The name of the service in /etc/services.
399 */
400 #define AMANDA_KRB5_SERVICE_NAME "k5amanda"
401 You can currently only override these by editing the source code.
404 The kerberized AMANDA service uses a different port on the client
406 hosts. The /etc/services line is:
407 k5amanda 10082/tcp
408 And the /etc/inetd.conf line is:
410 k5amanda stream tcp nowait root /usr/local/libexec/amanda/amandad amandad -auth=krb5
412 Note that you're running this as root, rather than as your dump user.
414 AMANDA will set its UID down to the dump user at times it doesn't need
415 to read the keytab file, and give up root permissions entirely before
416 it goes off and runs dump. Alternately you can change your keytab files
417 to be readable by user amanda. You should understand the security
418 implications of this before changing the permissions on the keytab.
419 The following dumptype options apply to krb5:
421 auth "krb5" # use krb5 auth for this host
423 # (you can mingle krb hosts and bsd .rhosts in one conf)
424 The principal and keytab files that Amanda uses must be set in the
426 amanda.conf file for kerberos 5 dumps to work. You can hardcode this in
427 the source code if you really want to (common-src/krb5-security.c)
428 krb5keytab
430 krb5principal
431 For example:
433 krb5keytab "/etc/krb5.keytab-amanda"
435 krb5principal "amanda/saidin.omniscient.com"
436 The principal in the second option must be contained in the first. The
438 keytab should be readable by the amanda user (and definitely not world
439 readable!) and is (obviously) on the server. In MIT's kadmin, the
440 following:
441 addprinc -randkey amanda/saidin.omniscient.com
443 ktadd -k /etc/krb5.keytab-amanda amanda/saidin.omniscient.com
444 will do the trick. You will obviously want to change the principal name
446 to reflect something appropriate for the conventions at your site.
447 You must also configure each client to allow the amanda principal in
449 for dumps.
450 There are several ways to go about authorizing a server to connect to a
452 client.
453 The normal way is via a .k5amandausers file or a .k5login file in the
455 client user's home directory. The determination of which file to use is
456 based on the way you ran configure on AMANDA. By default, AMANDA will
457 use .k5amandahosts, but if you configured with --without-amandahosts,
458 AMANDA will use .k5login. (similar to the default for
459 .rhosts/.amandahosts-style security). The .k5login file syntax is a
460 superset of the default krb5 .k5login. The routines to check it are
461 implemented in amanda rather than using krb5_kuserok because the
462 connections are actually gssapi based.
463 This .k5amandahosts/.k5login is a hybrid of the .amandahosts and a
465 .k5login file. You can just list principal names, as in a .k5login file
466 and the principal will be permitted in from any host. If you do NOT
467 specify a realm, then there is no attempt to validate the realm (this
468 is only really a concern if you have cross-realm authentication set up
469 with another realm or something else that allows you multiple realms in
470 your kdc. If you do specify a realm, only that principal@realm will be
471 permitted to connect.
472 You may prepend this with a hostname and whitespace, and only that
474 principal (with optional realm as above) will be permitted to access
475 from that hostname.
476 Here are examples of valid entries in the .k5amandahosts:
478 service/amanda
480 service/amanda@TEST.COM
481 dumpmaster.test.com service/amanda
482 dumpmaster.test.com service/amanda@TEST.COM
483 Rather than using a .k5amandahosts or .k5login file, the easiest way is
485 to use a principal named after the destination user, (such as
486 amanda@TEST.COM in our example) and not have either a .k5amandahosts or
487 .k5login file in the destination user's home directory.
488 There is no attempt to verify the realm in this case (only a concern if
490 you have cross-realm authentication setup).
491 Authenticated Peer Hostnames with Kerberos Authentication
493 When accepting a new incoming connection, the Kerberos authentication
494 mechanism performs a similar check to that done by the BSD
495 authentications: the forward and reverse DNS entries for the remote
496 host must match. As such, while Kerberos authentication can
497 cryptographically ensure that the remote system is recognized (since it
498 has a ticket), its assurances about the remote host's identity are
499 weaker and depend on the integrity of the DNS.
500
502 The Amanda server communicates with the client internally versus over
503 the network, ie. the client is also the server.
504 This is the only method that requires no authentication as it is
506 clearly not needed.
507 The authenticated peer hostname for this authentication is always
509 "localhost".
510
512 For more detail, see
513 http://wiki.zmanda.com/index.php/Configuring_rsh_authentication.
514 The Amanda server communicates with its client as the Amanda user via
516 the RSH protocol.
517 Please note that RSH protocol itself is insecure and should be used
519 with caution especially on any servers and clients with public IPs.
520 Each Amanda client communicates with the server using one TCP port and
522 all data streams from the client are multiplexed over one port. The
523 number of Amanda clients is limited by the number of reserved ports
524 available on the Amanda server. Some versions of RSH do not use
525 reserved ports and, thus, this restriction is not valid.
526 General information including compilation is given above (see
528 COMPILATION AND GENERAL INFORMATION above).
529 In addition to specifying the auth field in dumptype definition, it
531 might be required to specify client-username and amandad fields. If the
532 backup user name is different on the Amanda client, the user name is
533 specified as client-username. If the location of the Amanda daemon
534 amandad is different on the Amanda client, the location is specified as
535 amandad-path field value.
536 For example:
538 define dumptype rsh_example {
539 ...
540 auth "rsh"
541 client-username "amandabackup"
542 amandad-path "/usr/lib/exec/amandad"
543 ...
544 }
545 Authenticated Peer Hostnames with RSH Authentication
547 The RSH authentication mechanism does not provide an authenticated peer
548 hostname.
549
551 For more detail, see
552 http://wiki.zmanda.com/index.php/How_To:Set_up_transport_encryption_with_SSH.
553 Amanda client sends data to the server using SSH. SSH keys have to be
555 set up so that Amanda server can communicate with its clients using
556 SSH.
557 General information including compilation is given above (see
559 COMPILATION AND GENERAL INFORMATION above).
560 SSH provides transport encryption and authentication. To set up an SSH
562 authentication session, Amanda will run the equivalent of the following
563 to start the backup process.
564 /path/to/ssh -l user_name client.zmanda.com $libexecdir/amandad
566 To use SSH, you need to set up SSH keys either by storing the
568 passphrase in cleartext, using ssh-agent, or using no passphrase at
569 all. All of these options have security implications which should be
570 carefully considered before adoption.
571 When you use a public key on the client to do data encryption (see
573 http://wiki.zmanda.com/index.php/How_To:Set_up_data_encryption), you
574 can lock away the private key in a secure place. Both, transport and
575 storage will be encrypted with such a setup. See
576 http://wiki.zmanda.com/index.php/Encryption for an overview of
577 encryption options.
578 Enable SSH authentication and set the ssh-keys option in all DLEs for
580 that host by adding the following to the DLE itself or to the
581 corresponding dumptype in amanda.conf:
582 auth "ssh"
584 ssh-keys "/home/amandabackup/.ssh/id_rsa_amdump"
585 ssh-keys is the path to the private key on the client. If the username
587 to which Amanda should connect is different from the default, then you
588 should also add
589 client-username "otherusername"
591 If your server amandad path and client amandad path are different,
593 you should also add
594 amandad-path "/client/amandad/path"
596 For a marginal increase in security, prepend the keys used for AMANDA
598 in the clients' authorized_keys file with the following:
599 from="amanda_server.your.domain.com",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/absolute/path/to/amandad -auth=ssh amdump"
601 This will limit that key to connect only from Amanda server and only be
603 able to execute amandad(8).
604 In the same way, prepend the key used for AMANDA in the server's
606 authorized_keys file with:
607 from="amanda_client.your.domain.com",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/absolute/path/to/amandad -auth=ssh amindexd amidxtaped"
609 You can omit the from=.. option if you have too many clients to list,
611 although this has obvious security implications.
612 Set ssh-keys and any other necessary options in
614 /etc/amanda/amanda_client.conf:
615 auth "ssh"
617 ssh-keys "/root/.ssh/id_rsa_amrecover"
618 client-username "amanda"
619 amandad-path "/server/amandad/path"
620 Besides user keys, SSH uses host keys to uniquely identify each host,
622 to prevent one host from impersonating another. Unfortunately, the only
623 easy way to set up these host keys is to make a connection and tell SSH
624 that you trust the identity:
625 $ ssh client1.zmanda.com
627 The authenticity of host 'client1.zmanda.com (192.168.10.1)' can't be established.
628 RSA key fingerprint is 26:4e:df:a2:be:c8:cb:20:1c:68:8b:cc:c0:3b:8e:9d.
629 Are you sure you want to continue connecting (yes/no)?yes
630 As Amanda will not answer this question itself, you must manually make
632 every connection (server to client and client to server) that you
633 expect Amanda to make. Note that you must use the same username that
634 Amanda will use (that is, ssh client and ssh client.domain.com are
635 distinct).
636 Authenticated Peer Hostnames with SSH Authentication
638 When accepting an incoming conneciton, the SSH daemon gives Amanda
639 information about the remote system in the $SSH_CONNECTION environment
640 variable. Amanda parses this information to determine the remote
641 address, and then performs a similar check to that done by the BSD
642 authentications: the forward and reverse DNS entries for the remote
643 host must match. As such, while SSH authentication can
644 cryptographically ensure that the remote system is recognized (since it
645 had a recognized secret key), its assurances about the remote host's
646 identity are weaker and depend on the integrity of the DNS.
647
649 amanda(8), amanda.conf(5), amanda-client.conf(5), disklist(5),
650 amdump(8), amrecover(8)
651 The Amanda Wiki: : http://wiki.zmanda.com/
653
655 Jean-Louis Martineau <martineau@zmanda.com>
656 Zmanda, Inc. (http://www.zmanda.com)
657 Dustin J. Mitchell <dustin@zmanda.com>
659 Zmanda, Inc. (http://www.zmanda.com)
660 Paul Yeatman <pyeatman@zmanda.com>
662 Zmanda, Inc. (http://www.zmanda.com)
663Amanda 3.3.3 01/10/2013 AMANDA-AUTH(7)