From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 4EB2178D41 for ; Thu, 30 Jun 2022 13:51:17 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 3C12B2E9AF for ; Thu, 30 Jun 2022 13:50:47 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Thu, 30 Jun 2022 13:50:46 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 56DA043D83; Thu, 30 Jun 2022 13:50:46 +0200 (CEST) Message-ID: <14c7b0c7-f379-6a97-6e4a-21e103690b40@proxmox.com> Date: Thu, 30 Jun 2022 13:50:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.0 Content-Language: en-US From: Dominik Csapak To: Proxmox VE development discussion , Dietmar Maurer Reply-To: Proxmox VE development discussion References: <212652737.3945.1656586923044@webmail.proxmox.com> <725dbe83-2a4c-7eab-a053-3f87f2be5f51@proxmox.com> In-Reply-To: <725dbe83-2a4c-7eab-a053-3f87f2be5f51@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.100 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [wsproxy.py, qemu.pm] Subject: Re: [pve-devel] vncpropxy question X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2022 11:51:17 -0000 On 6/30/22 13:25, Dominik Csapak wrote: > On 6/30/22 13:02, Dietmar Maurer wrote: >> in qemu-server, I wonder why we set $ENV{LC_PVE_TICKET} conditionally? Does not make any sense to >> me, because it make all other connection failing... >> >> >> diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm >> index 99b426e..c6a3ac1 100644 >> --- a/PVE/API2/Qemu.pm >> +++ b/PVE/API2/Qemu.pm >> @@ -2102,7 +2102,7 @@ __PACKAGE__->register_method({ >>              } else { >> -               $ENV{LC_PVE_TICKET} = $password if $websocket; # set ticket with "qm vncproxy" >> +               $ENV{LC_PVE_TICKET} = $password; >>                  $cmd = [@$remcmd, "/usr/sbin/qm", 'vncproxy', $vmid]; >> >> > > AFAICS, this is a remnant of old code where we would start wsproxy.py instead of our >  'qm vncproxy' > > i think we could remove the whole websocket parameter as it doesn't > do anything here > > so we could do > 1. remove the use of $websocket here > 2. remove the websocket=1 parameter in novnc > 3. remove the websocket parameter completely (in 8.0, since it's a breaking api change) > addendum: 'it doesn't do anything here' is not completely correct for 'regular' vm displays it just does not set the ticket which breaks the connection for use with a serial terminal in the vm, we also set '-notls' and '-listen localhost' for vncterm if we'd drop the parameter anyway (with 8.0) and use always '-notls -listen localhost' i think we could drop the custom libvncserver package in vncterm and use the debian packaged one (since we'd never use tls then anyway) we could even go a step further and remove support for terminals over vnc completely, since we have support for that in the browser with xterm.js since quite some time