The dumper must be installed suid root.
What's in the dumper.<timestamps>.debug file?

Jean-Louis

Charles Sprickman wrote:

Any ideas on this one?  Should I just consider it a bug?

I'm not clear at all on why the server is picking a port over 1024, but that does seem to be clearly happening, and then the client is rejecting it (which does seem to be by design). FWIW, I *cannot* reproduce it when firing off one host at a time - only during an actual full run where all hosts are backed up. Perhaps it's trying to do too much in parallel? The server box is not doing anything odd that would eat up priv ports. Additionally the problem did not exist in the old version of amanda we used.

Thanks,

Charles

On Wed, 25 Apr 2007, Charles Sprickman wrote:

Hi all,

This is my last problem for the time being...

Server side reports this (amdump.1):

driver: result time 2126.498 from dumper2: TRY-AGAIN 02-00009 "NAK: host h-74-0-x-28.phlapafg.covad.net: port 1026 not secure"

The IP address there is the amanda server.

Client side reports this (amandad.debug):

security_handleinit(handle=0x8052000, driver=0x28094900 (BSDTCP))
security_streaminit(stream=0x8058000, driver=0x28094900 (BSDTCP))

security_seterror(handle=0x8052000, driver=0x28094900 (BSDTCP) error=host h-74-0-x-28.phlapafg.covad.net: port 1026 not secure) amandad: time 0.002: accept error: host h-74-0-x-28.phlapafg.covad.net: port 1026 not secure

amandad: time 0.002: sending NAK pkt:
<<<<<
ERROR host h-74-0-x-28.phlapafg.covad.net: port 1026 not secure

If I'm reading this right, the client is listening via inetd, it accepts a connection FROM the server, but it does not like that the server is connecting to it from a port above 1024.

The check appears to be in common-src/security-util.c:

       /*
        * Request packets must come from a reserved port
        */
       if (ntohs(rh->peer.sin_port) >= IPPORT_RESERVED) {
           security_seterror(&rh->sech,
               "host %s: port %d not secure", rh->hostname,
               ntohs(rh->peer.sin_port));
           amfree(service);
           amfree(security_line);
           return (-1);
       }

But that doesn't tell me much about what controls what port the server decides to bind to when contacting the client.

I saw a FAQ entry about this error when running amcheck without the suid root bit, but this happens during amdump and amcheck. It seems fairly random.

Any ideas?

Thanks,

Charles