NetBSD Problem Report #57039

From root@ptah.zabrico.com  Fri Sep 30 16:13:29 2022
Return-Path: <root@ptah.zabrico.com>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 694A11A923C
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 30 Sep 2022 16:13:29 +0000 (UTC)
Message-Id: <20220930145404.29A82117CD2@ptah.zabrico.com>
Date: Fri, 30 Sep 2022 10:54:04 -0400 (EDT)
From: louis@zabrico.com
Reply-To: louis@zabrico.com
To: gnats-bugs@NetBSD.org
Subject: nycdn.netbsd.org redirects to URL without hostname
X-Send-Pr-Version: 3.95

>Number:         57039
>Category:       misc
>Synopsis:       nycdn.netbsd.org redirects to URI without hostname
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    misc-bug-people
>State:          open
>Class:          support
>Submitter-Id:   net
>Arrival-Date:   Fri Sep 30 16:15:00 +0000 2022
>Last-Modified:  Fri Sep 30 17:10:02 +0000 2022
>Originator:     Louis Guillaume
>Release:        NetBSD 9.3_STABLE
>Organization:
>Environment:
System: NetBSD ptah.zabrico.com 9.3_STABLE NetBSD 9.3_STABLE (XEN3_DOMU) #0: Wed Aug 17 16:43:50 UTC 2022 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/xen/compile/XEN3_DOMU amd64
Architecture: x86_64
Machine: amd64
>Description:
	While attempting to automate retrieval of nightly binaries from nycdn.netbsd.org,
        I noticed that my script, which uses "tnftp", fails to retrieve the nightly
	kernels because the web server redirects (302) to a URL that does not include the
	protocol, host or port. Only the path URI is included.
	I'm not sure what is normally expected of the HTTP client but tnftp does not
	reassemble the URL with the original host:port when it's missing in the redirect
	path. Maybe this is actually a tnftp or libfetch bug??
>How-To-Repeat:
	Attempt to retrieve a kernel using "ftp" on a netbsd machine. e.g.:
	# ftp -a http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/amd64/binary/kernel/netbsd-INSTALL_XEN3_DOMU.gz
	Trying [2a04:4e42:31::262]:80 ...
	ftp: Can't connect to `2a04:4e42:31::262:80': No route to host
	Trying 151.101.209.6:80 ...
	Requesting http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/amd64/binary/kernel/netbsd-INSTALL_XEN3_DOMU.gz
	Redirected to /pub/NetBSD-daily/netbsd-9/202209281530Z/amd64/binary/kernel/netbsd-INSTALL_XEN3_DOMU.gz
	ftp: Can't lookup `/pub/NetBSD-daily/netbsd-9/202209281530Z/amd64/binary/kernel/netbsd-INSTALL_XEN3_DOMU.gz:ftp': Non-recoverable failure in name resolution
	ftp: Can't connect or login to host `/pub/NetBSD-daily/netbsd-9/202209281530Z/amd64/binary/kernel/netbsd-INSTALL_XEN3_DOMU.gz:?'
>Fix:

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: misc/57039: nycdn.netbsd.org redirects to URL without hostname
Date: Fri, 30 Sep 2022 19:06:26 +0200

 On Fri, Sep 30, 2022 at 04:15:01PM +0000, louis@zabrico.com wrote:
 > 	Attempt to retrieve a kernel using "ftp" on a netbsd machine. e.g.:
 > 	# ftp -a http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/amd64/binary/kernel/netbsd-INSTALL_XEN3_DOMU.gz
 > 	Trying [2a04:4e42:31::262]:80 ...
 > 	ftp: Can't connect to `2a04:4e42:31::262:80': No route to host
 > 	Trying 151.101.209.6:80 ...
 > 	Requesting http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/latest/amd64/binary/kernel/netbsd-INSTALL_XEN3_DOMU.gz
 > 	Redirected to /pub/NetBSD-daily/netbsd-9/202209281530Z/amd64/binary/kernel/netbsd-INSTALL_XEN3_DOMU.gz

 The server is correct, this is a bug in the ftp(1) client on NetBSD.
 It has been fixed on all active branches some time ago.

 To work around it you need to manually update base.tgz once, e.g. when
 you see your above output, construct an absolute url from it:

   ftp -a http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-9/202209281530Z/amd64/binary/base.tgz

 (note base, not kern.tgz), then extract that manually, like

   # cd / && tar xpzf /tmp/base.tgz

 and after that your new ftp(1) binary will work with the relative redirects.

 This is a safe thing to do on release branches at least, for -current
 you might want to do the same trick for kernel first (but there has
 been no userland relevant change in months, so it is almost safe in
 -current to).

 Martin

Home	PR Database Search