X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 429A6388A81F
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1592149096;
	bh=PYamorNradhrtgC0Z03fYNtSjHtJ6plee6rXOWZFxAs=;
	h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	From;
	b=j/cAyc0VGDd+f3HrvAk8rZy5mnxJAhLBV7ctN2rZaIzrnlP7LoBS4IXBRB1CPJoju
	ipDVoDDIpfRyDUqcxtkIwuKuhlJxOZlff0Pxc61V9bK4BoyaxNGDcds1mq6RwPtlCd
	MhHnPVWwRsk4ALKPLyJliZs/0LOTf69Fi/20oiTc=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.3.2 sourceware.org 47F4A383E838
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:cc;
	bh=pbQWrw6XjfDn++MtcCvyMAVPH1IIi6MvLVOqGnHo37U=;
	b=HMZyC6aO4OhP01ML8EgjzQ/YbgBb2/CE+n6KGmTqGLKhNoouKJFJfmidu6bHaiKeNn
	Tpm7uHbO9z8zAA7VaLlske+N3ZDaBWDIJLkCWSmPjl2JYKHnXW3eYE30lYlOLxeJhGMM
	LiuAOSpTWyBSuEi9ECM3zRnYK3jYjYN3AgKyJ99MIB+WxQI+UBgu467nlD4gNcrJJLwG
	xTF7pORrlAg/u8jSJwFHlwsjf4iUYXgOU0t5HioA+qqBsmonVxzGuOTTXAsmldEYfrMH
	/MXbwNS/hT4+6iOsr39iDWN4Y7BUSnrrr3qF6kbcR1DOU/3JSBXFcocV5CZQnVlYoqBm
	cZmg==
X-Gm-Message-State:	AOAM533dLBTn5LEbdX/9cd1zEIDHe9FAxSrcerNekvK62hw8QcvxwPEm
	xku3jEY34Ffnu/e/I9A5z/M7HL0BZL1MPtE+zgk=
X-Google-Smtp-Source:	ABdhPJyK1HJsXtPAqlzkyDf7GG1I06xi54Tn/6lN8Qk2SdbFdl9LOmDDyBM18VUBDbTrTXhbNRA4GRpwevermQjXujw=
X-Received:	by 2002:a05:6808:42:: with SMTP id v2mr6334949oic.56.1592149092548;
	Sun, 14 Jun 2020 08:38:12 -0700 (PDT)
MIME-Version:	1.0
References:	<CAA5t8VqpU2KiQ_Kk5czjLzeCDzf21Gb2iBLu25xB43ZhpfmaPQ AT mail DOT gmail DOT com>
	<b68e371b-4e3d-3ab3-9a0e-2461697d814d AT gmail DOT com>
	<CAA5t8Vpym95FDhvanJSNd910kWssJqK46ZzmF2jckQbY_7YxOw AT mail DOT gmail DOT com>
	<f224a4a9-ea7d-e22c-0285-19d09ebd572f AT gmail DOT com>
In-Reply-To:	<f224a4a9-ea7d-e22c-0285-19d09ebd572f@gmail.com>
Date:	Sun, 14 Jun 2020 08:38:01 -0700
Message-ID:	<CAA5t8Vpanxxop9THkbod115y_Xd2Q2QvYDXvBYOA7N9BqQw-Bw@mail.gmail.com>
Subject:	Re: "kubectl exec" in Cygwin gets "Upgrade request required", but not
	in cmd shell
To:	Marco Atzeri <marco DOT atzeri AT gmail DOT com>
X-Spam-Status:	No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS,
	TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version:	SpamAssassin 3.4.2 (2018-09-13) on
	server2.sourceware.org
X-Content-Filtered-By:	Mailman/MimeDel 2.1.29
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<http://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	David Karr via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	David Karr <davidmichaelkarr AT gmail DOT com>
Cc:	The Cygwin Mailing List <cygwin AT cygwin DOT com>
Sender:	"Cygwin" <cygwin-bounces AT cygwin DOT com>

On Sun, Jun 14, 2020 at 2:25 AM Marco Atzeri wrote:

> On 14.06.2020 08:12, David Karr wrote:
> >
> >
> > On Sat, Jun 13, 2020 at 10:31 PM Marco Atzeri via Cygwin wrote:
> >
> >     On 13.06.2020 20:53, David Karr via Cygwin wrote:
> >      > I've been using kubectl in Cygwin on Windows 10 for quite a
> while, to
> >      > communicate to our in-house k8s clusters. I often use "kubectl
> >     exec" to
> >      > open a shell in a container or directly execute a shell command.
> >     This has
> >      > worked perfectly fine for a long time.
> >      >
> >      > A couple of days ago, I discovered that all of these attempts
> >     were failing
> >      > with "Upgrade request required".  I hadn't upgraded kubectl or
> >     Cygwin in
> >      > quite a while. I doubt our clusters had a k8s upgrade, but it's
> >     entirely
> >      > possible.
> >      >
> >      > A colleague of mine has a very similar desktop configuration
> >     (Windows 10,
> >      > Cygwin), and he's not seeing this symptom.
> >      >
> >      > I noticed that when I ran "kubectl exec" with max verbosity, it
> >     shows the
> >      > resulting "curl" command that it runs. I tried that resulting
> >     command, and
> >      > it results in the same response. I then tried updating my Cygwin
> >     tools and
> >      > retesting, no change.
> >      >
> >      > I then took the entire resulting "kubectl exec" command line and
> >     ran it in
> >      > a "cmd" shell.  No problem at all.  No error.
> >      >
> >      > I know I haven't provided much useful information yet. I wanted
> >     to get an
> >      > initial response before I started providing those diagnostics. Is
> >     there a
> >      > clear issue here that I'm not aware of?
> >      > --
> >
> >     from where is kubectl coming from ?
> >
> >     In cygwin I found only a kubectl.py in the ansible package
> >
> >
> > It's from here:
> >
> https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows
> > .
>
> so it is NOT a cygwin program.
>
> If the warning is coming about curl, it is likely
> that using from cygwin you are using the cygwin curl
> and from CMD the windows one
>
>
> $ which -a curl
> /usr/bin/curl
> /cygdrive/c/WINDOWS/system32/curl
>
>
> $ /cygdrive/c/WINDOWS/system32/curl -V
> curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
> Release-Date: 2017-11-14, security patched: 2019-11-05
> Protocols: dict file ftp ftps http https imap imaps pop3 pop3s smtp
> smtps telnet
>   tftp
> Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL
>
> $ /usr/bin/curl -V
> curl 7.66.0 (x86_64-pc-cygwin) libcurl/7.66.0 OpenSSL/1.1.1f zlib/1.2.11
> brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.0.4)
> libssh/0.8.7/openssl/zlib nghttp2/1.37.0
> Release-Date: 2019-09-11
> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
> pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
> Features: AsynchDNS brotli Debug GSS-API HTTP2 HTTPS-proxy IDN IPv6
> Kerberos Largefile libz Metalink NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP
> TrackMemory UnixSockets
>
>
> the support Forum https://discuss.kubernetes.io/
> is probably the most indicate place for guidance
>
> Regards
> Marco
>

I thought it was obvious that it was not working because it was calling the
Cygwin curl. I wouldn't have posted here if that wasn't obvious to me.

And since I'm well aware of the k8s community, I already posted questions
about this in the appropriate place, before I posted here.

What I was hoping to get here was some indication or thoughts on why a
process using Windows curl doesn't have a problem, but does have a problem
when using Cygwin Curl. This isn't likely something that Cygwin curl is
doing "wrong", it's just that it's doing something different.

If it matters, the following is an elided version of the resulting curl
command:

    curl -k -v -XPOST  -H "User-Agent: kubectl.exe/v1.18.0 (windows/amd64)
kubernetes/9e99141" -H "Authorization: Bearer ..." -H
"X-Stream-Protocol-Version: v4.channel.k8s.io" -H
"X-Stream-Protocol-Version: v3.channel.k8s.io" -H
"X-Stream-Protocol-Version: v2.channel.k8s.io" -H
"X-Stream-Protocol-Version: channel.k8s.io" 'https://
.../api/v1/namespaces/.../pods/.../exec?command=%2Fbin%2Fls&container=...&stderr=true&stdin=true&stdout=true'

I can't tell from the logging what request body it sent. It's possible it
didn't send any.
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -