Re: RESOLVED: Re: Strange failure to connect to client
> Is there a complete list of the ports that amanda will use during the > data transfer? I though I had them all (the client could talk to the > server) as amcheck didn't report any errors. However, I remove all > packet filtering and things start working smoothly... see JRJ attached >From - Sat Jan 26 00:52:51 2002 Return-Path: X-Sieve: cmu-sieve 2.0 Return-path: <[EMAIL PROTECTED]> Envelope-to: [EMAIL PROTECTED] Delivery-date: Sat, 23 Jun 2001 04:57:31 +0200 Received: from ente.berdmann.de ([192.168.1.6] helo=localhost) by ente.berdmann.de with esmtp (Exim 3.16 #2) id 15Ddc2-0006ur-00 for [EMAIL PROTECTED]; Sat, 23 Jun 2001 04:57:30 +0200 X-Flags: Delivered-To: GMX delivery to [EMAIL PROTECTED] Received: from pop.gmx.net [194.221.183.20] by localhost with POP3 (fetchmail-5.5.0) for [EMAIL PROTECTED] (single-drop); Sat, 23 Jun 2001 04:57:30 +0200 (CEST) Received: (qmail 15453 invoked by uid 0); 23 Jun 2001 02:53:52 - Received: from surly.omniscient.com (64.134.101.69) by mx0.gmx.net (mx13) with SMTP; 23 Jun 2001 02:53:52 - Received: (from root@localhost) by surly.omniscient.com (8.11.1/8.11.1) id f5N0bkX199799 for amanda.org.amanda-hackers-list; Sat, 23 Jun 2001 00:37:46 GMT Received: from gandalf.cc.purdue.edu ([EMAIL PROTECTED] [128.210.135.25]) by surly.omniscient.com (8.11.1/8.11.1) with ESMTP id f5N0bgX207608 for <[EMAIL PROTECTED]>; Fri, 22 Jun 2001 20:37:42 -0400 (EDT) Received: from gandalf.cc.purdue.edu (jrj@localhost [127.0.0.1]) by gandalf.cc.purdue.edu (8.9.1/8.9.1) with ESMTP id TAA26259 for <[EMAIL PROTECTED]>; Fri, 22 Jun 2001 19:37:40 -0500 (EST) Message-Id: <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Use of UDP/TCP ports in Amanda document, and amrecover bug Reply-to: [EMAIL PROTECTED] Date: Fri, 22 Jun 2001 19:37:40 -0500 From: "John R. Jackson" <[EMAIL PROTECTED]> Sender: [EMAIL PROTECTED] Precedence: bulk This is yet another of my really long letters. Sorry. I applied a change to amrecover.c a while back to use stream_client() instead of the "by hand" socket setup that was there. This stopped binding the socket to a particular interface which was causing trouble on some systems. Unfortunately, I didn't fully comprehend the interaction between a user port range (e.g. --with-portrange), stream_client() and amrecover. Now, if amrecover is built with --with-portrange, which must be non-privileged (>= 1024) for other parts of Amanda to work, it will fail because amrecover requires a privileged port (to prove to the other side it is who it says it is). Before going into potential solutions, a little more background. If this bores you silly, skip to "Solutions" below. I'm only spelling it out in detail because I'll probably put this in the docs directory (once you nice folks edit it :-) since the issue comes up fairly often. The key questions for the amrecover problem are: * When dumper and taper set up their localhost TCP connection for direct to tape, does the port matter? If NAT, for instance, is also on the machine, will it scramble things? * When not being used for security (non-privileged), does the source port of an incoming TCP connection matter? Amanda doesn't care. Would a firewall or NAT in between cause problems? John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] = How Amanda uses UDP and TCP ports = Amanda uses both UDP and TCP ports during its operation. The amandad service is listening (via inetd/xinetd) at a well known (fixed) port on each client for UDP connections. The amindexd and amidxtaped services are listening (also via inetd/xinetd) at well known ports on the tape server for TCP connections. When a process on the tape server wants to talk to a client amandad, it creates a UDP socket and binds it to a port on its side, then sends the packet to the well known amandad service port on the client. Because security information is being passed, the port bound on the connecting side must be privileged (< 1024). This "proves" to amandad whoever is connecting is running as root, and therefor is trustworthy (there are all sorts of issues with this "trust" that are beyond the scope of this document). A similar sequence of events happens when amrecover on a client wants to contact amindexd or amidxtaped on the tape server. The port that amrecover binds to its TCP socket must be privileged, which is one of the reasons it must be run as root. Amanda also uses TCP connections for transmitting the backup image, messages and (optionally) the index list from a client back to the dumper process on the tape server. A process called sendbackup is started by amandad on the client. It creates two (or three, if indexing is enabled) TCP sockets and sends their port numbers back to dumper in a UDP message. Then dumper creates and binds TCP sockets on its side an
Re: RESOLVED: Re: Strange failure to connect to client
On Tue, 26 Feb 2002 at 11:45am, Graham Dunn wrote > The client I was trying to back up still was filtering some ports that > amanda wanted to use. > > Is there a complete list of the ports that amanda will use during the > data transfer? I though I had them all (the client could talk to the > server) as amcheck didn't report any errors. However, I remove all > packet filtering and things start working smoothly... I posted the sequence a while ago...(search, search), a ha! Doing the estimates: The amanda server sends a UDP sendsize request from a privileged port to port 10080 on the client. The client sends a UDP packet (containg an ACK) from port 10080 to the privileged port on the server. It then sends another one containing the REP (the reply and dump estimate info). Finally, the server sends a UDP ACK from the privileged port to port 10080 on the client. Doing the backups: The amanda server sends a UDP sendbackup request from a privileged port (not necessarily the same one as above) to port 10080 on the client. The amanda client sends a UDP ACK from port 10080 to the originating privileged port on the server. It then sends another one containing the numbers of three (non-privileged) TCP ports to set up the data, message, and index connections. The amanda server sends a UDP ACK from the privileged port to port 10080 on the client. The amanda server then initiates three TCP connections on the ports indicated in the UDP packet from the client. These are on unprivileged ports on both systems. The dumper on the client then proceeds to start sending date over the TCP connections. So clients need to accept on UDP 10080 from UDP<1024, and accept on TCP>1024 from TCP>1024. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
RESOLVED: Re: Strange failure to connect to client
The client I was trying to back up still was filtering some ports that amanda wanted to use. Is there a complete list of the ports that amanda will use during the data transfer? I though I had them all (the client could talk to the server) as amcheck didn't report any errors. However, I remove all packet filtering and things start working smoothly... Graham On Mon, Feb 25, 2002 at 01:13:35PM -0500, Graham Dunn wrote: > Date: Mon, 25 Feb 2002 13:13:35 -0500 > From: Graham Dunn <[EMAIL PROTECTED]> > To: Joshua Baker-LePain <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: Strange failure to connect to client > > On Mon, Feb 25, 2002 at 12:17:23PM -0500, Joshua Baker-LePain wrote: > > Date: Mon, 25 Feb 2002 12:17:23 -0500 (EST) > > From: Joshua Baker-LePain <[EMAIL PROTECTED]> > > To: Graham Dunn <[EMAIL PROTECTED]> > > cc: [EMAIL PROTECTED] > > Subject: Re: Strange failure to connect to client > > > > On Mon, 25 Feb 2002 at 12:06pm, Graham Dunn wrote > > > > > amcheck shows no errors, but the amdump log reports a problem... > > > ideas? > > > > > > FAIL driver oshaberi /usr/local/mailman 0 20020225[could not connect > > > to oshaberi] > > > FAIL driver oshaberi ad0s1a 0 20020225[could not connect to oshaberi] > > > INFO taper tape DailySet103 kb 320 fm 2 [OK] > > > FINISH driver date 20020225 time 366.114 > > > > > > Amanda Backup Client Hosts Check > > > > > > Client check: 3 hosts checked in 0.557 seconds, 0 problems found > > > > > Is there anything in /tmp/amanda/amanda*debug on oshaberi created at the > > time of the amdump attempth? How about sendsize*debug? > > Nothing in there... I'm getting a new error now: > > DISK planner oshaberi ad0s1a > DISK planner oshaberi /usr/local/mailman > START driver date 20020225 > DISK planner axp500 da0a > DISK planner tsuyoi ad0s1a > START planner date 20020225 > INFO planner Adding new disk oshaberi:ad0s1a. > INFO planner Adding new disk oshaberi:/usr/local/mailman. > FINISH planner date 20020225 > STATS driver startup time 0.894 > ERROR taper no-tape [new tape not found in rack] > FAIL driver oshaberi /usr/local/mailman 20020225 0 [can't switch to > incremental > dump] > FAIL driver oshaberi ad0s1a 20020225 0 [can't switch to incremental > dump] > SUCCESS dumper axp500 da0a 20020225 1 [sec 0.267 kb 160 kps 597.3 > orig-kb 160] > SUCCESS dumper tsuyoi ad0s1a 20020225 1 [sec 0.312 kb 130 kps 416.1 > orig-kb 130]FINISH driver date 20020225 time 259.533 > > And I haven't changed anything in the amanda config (I know, I know, I > don't believe that when my users say it either, but seriously) on the > server or client. > > Looking through the FM, I see "can't switch to incremental mode" on a > new filesystem usually means there's something wrong with the tape. Is > this what the "[new tape not found in rack]" error is? > > There's no way the previous tapes are full and in contrast to my > previous message, there's no INFO taper ... line at the end of this > log (/usr/adm/amanda/DailySet1/log.20020225.3). > > Graham
