Problem with spice after upgrade to 2.4.0

brushek · May 7, 2021, 8:45am

Problem:
Spice console stopped working. As seen in picture:

in web development console is info: must set host and port

In spice.js there is a following function:

export function startSpice() {
  const scheme = 'ws://';

  const host = window.location.hostname;
  const port = $('#spice-area').data('port');
  const password = $('#spice-area').data('password');

  if (!host || !port) {
    // eslint-disable-next-line no-console
    console.log(__('must set host and port'));
    return;
  }

$('#spice-area').data('port') should resolve to a port where QEMU SPICE console is running on compute host - this is the console page template:

github.com

theforeman/foreman/blob/2.4.0/app/views/hosts/console/spice.html.erb#L14


      
                               if supports_spice_xpi?
                                 link_to(_("New window"), "#", :id => "disconnect", :class => "btn btn-default", :onclick => 'tfm.spice.connectXPI()', :title => _("Open Spice in a new window"))
                               end,
                               if @host
                                 link_to_if_authorized(_("Back to host"), hash_for_host_path(:id => @host), :title => _("Back to host"), :class => 'btn btn-default')
                               end
                  ),
                  documentation_button("7.1NoVNC",
                    {:id => "troubleshootingButton", :class => "btn btn-default"})
                  ) %>
          <%= content_tag(:div, :id =>'spice-area', :data => spice_data_attributes(@console)) do %>
            <div class="console-status">
              <div id="spice-status" class="col-md-12 label" data-host="<%= @console[:name] %>"><%= _("Connecting (unencrypted) to: %s") % @console[:name] %></div>
            </div>
            <div id="spice-screen" class="console-screen"> </div>
          <% end %>
          
          <script type="text/javascript"> tfm.spice.startSpice() </script>

<%= content_tag(:div, :id =>'spice-area', :data => spice_data_attributes(@console)) do %>

Meanwhile, our instance of foreman does not have any additional datafields at all; it’s just <div id="spice-area"> - it is probably an issue with webpage template rendering where spice_data_attributes values cannot be fetched, or maybe they are not being fetched at all?

Also, after manually adding the port data field and running the SPICE console manually via following commands in Javascript console, a “SecurityError: The operation is insecure” error appears:

document.querySelector('#spice-area').dataset.port = '5910'
tfm.spice.startSpice()

This may be caused by a hardcoded const scheme = 'ws://'; in spice.js instead of wss:// - this needs to be verified after template rendering issue is handled.

Expected outcome:

spice console should be running

Foreman and Proxy versions:

dpkg -l | grep foreman | grep ii
ii  foreman                                2.4.0-1                                         amd64        Systems management web interface
ii  foreman-cli                            2.4.0-1                                         all          metapackage providing hammer CLI for Foreman
ii  foreman-console                        2.4.0-1                                         all          metapackage providing console dependencies for Foreman
ii  foreman-debug                          2.4.0-1                                         all          provides support utility foreman-debug.
ii  foreman-installer                      2.4.0-1                                         all          Automated puppet-based installer for The Foreman
ii  foreman-libvirt                        2.4.0-1                                         all          metapackage providing libvirt dependencies for Foreman
ii  foreman-postgresql                     2.4.0-1                                         all          metapackage providing PostgreSQL dependencies for Foreman
ii  foreman-proxy                          2.4.0-1                                         all          RESTful proxies for DNS, DHCP, TFTP, and Puppet
ii  ruby-foreman-deface                    1.5.3-1                                         all          Foreman Deface Plugin Dependency
ii  ruby-foreman-dhcp-browser              0.0.8-1                                         all          Foreman DHCP browser Plugin
ii  ruby-foreman-discovery                 16.3.4-1                                        all          Foreman Discovery Plugin
ii  ruby-foreman-setup                     6.0.0-1                                         all          Foreman Setup Plugin
ii  ruby-hammer-cli-foreman                2.4.0-1                                         all          Foreman commands for Hammer
ii  ruby-hammer-cli-foreman-discovery      1.0.1-1                                         all          Foreman CLI plugin for managing discovery hosts in foreman

Distribution and version:

Distributor ID: Ubuntu
Description:    Ubuntu 18.04.5 LTS
Release:        18.04
Codename:       bionic

Other relevant data:

Nothing relevant info in logs.

ekohl · May 7, 2021, 9:42am

It’s weird because the hardcoded ws:// part is quite old. Don’t get me wrong, that’s very wrong IMHO but not a recent change.

You also upgraded. What’s the last version where you did see it work?

brushek · May 7, 2021, 11:35am

It was 2.1, when it was working for sure - but then I did upgrades from 2.1->2.2->2.3 -> 2.4 without checking this particular thing. Earlier we did upgrade from 1.24 -> 2.0 -> 2.1.

Maybe some regeneration of this file should do the job ? How to do it correctly without braking anything ?
some foreman-rake (assets:clobber|assets:precompile|webpack:compile) is ok ?

ekohl · May 7, 2021, 11:54am

The source is:

github.com

theforeman/foreman/blob/develop/webpack/assets/javascripts/spice.js

/* eslint-disable jquery/no-data */
/* eslint-disable jquery/no-attr */
/* eslint-disable jquery/no-class */
/* eslint-disable jquery/no-text */

import $ from 'jquery';
import {
  SpiceMainConn,
  sendCtrlAltDel as _sendCtrlAltDel,
} from '@spice-project/spice-html5';
import { sprintf, translate as __ } from './react_app/common/I18n';

let sc = null;

export function startSpice() {
  const scheme = $('#spice-area').data('encrypt') ? 'wss' : 'ws';
  const host = window.location.hostname;
  const port = $('#spice-area').data('port');
  const password = $('#spice-area').data('password');

This file has been truncated. show original

The offending line was changed in:

That commit was part of 1.23.0 already. If you look at it closely, it was already hardcoded to ws:// in this commit:

That was part of 1.2.0. So I really think it never was able to use wss://. That’s why I’m confused it ever worked. Perhaps your browser is now stricter?

Fun fact: I already raised that concern here:

It links back to Bug #22801: Spice connection with websockets encryption - Foreman.

As for fixing it, it should respect the setting websockets_encrypt and use wss:// if needed. I went ahead and submitted this:

Right now I don’t have a setup to verify it. I’ll see about setting that up.

pjakuszew · May 7, 2021, 12:23pm

Thank you for looking into the ws:// schema issue - I did some initial investigation that was provided by @brushek and I thought that this could be the cause of SecurityError appearing when tfm.spice.startSpice() was manually triggered after modifying the #spice-area div in browser.

Do you have any pointers about how we can make Foreman properly render the console page? As described in original post, SPICE console does not start at all due to data-port missing from #spice-area div and we have some issues with tracking down the cause of this problem. From what I gathered, the console port is probably dynamically fetched from compute resource, but I cannot find why it does not end up in console page div.

pjakuszew · May 7, 2021, 12:41pm

Sorry for the double posting, but I cannot edit the previous post anymore - here is a screenshot that should clarify the problem:

noVNC console works, and it has additional attributes like data-port, while the SPICE console does not have any attributes at all - it seems like the data from spice_data_attributes is not propagated into SPICE console ERB template.

ekohl · May 7, 2021, 3:53pm

I dove deeper and it looks like the port is missing in develop. Looks like it changed from proxy_port to port in but the spice console wasn’t modified.

That was included in 2.2.0.

I opened Bug #32566: Spice console no longer sets the port - Foreman

The fix is changing proxy_port to port here:

github.com

theforeman/foreman/blob/b6b6ffc01ca7065182571a221d4a02e1baa25127/app/helpers/compute_resources_vms_helper.rb#L54


      
            end
          end
          
          def supports_spice_xpi?
            user_agent = request.env['HTTP_USER_AGENT']
            user_agent =~ /linux/i && user_agent =~ /firefox/i
          end
          
          def spice_data_attributes(console)
            options = {
              :port     => console[:proxy_port],
              :password => console[:password],
            }
            if supports_spice_xpi?
              options.merge!(
                :address     => console[:address],
                :secure_port => console[:secure_port],
                :subject     => console[:subject],
                :title       => _("%s - Press Shift-F12 to release the cursor.") % console[:name]
              )
            end

Then systemctl restart foreman. I’m submitting a patch.

ekohl · May 7, 2021, 4:49pm

This should be the patch:

github.com/theforeman/foreman

Fixes #32566 - Fix port setting for spice consoles

theforeman:develop ← ekohl:32566-fix-spice-ports

opened 04:44PM - 07 May 21 UTC

ekohl

+1 -1

In 508776ea6dfc7defce8a4e466408629f494da0cf the WsProxy output was changed from …proxy_port to port but this was not updated. The result was that it wasn't passed to the UI and no spice connection could be set up. This means it's a regression fix that should be cherry picked to all supported versions (since 2.2.0 is affected).

pjakuszew · May 10, 2021, 10:01am

Thank you for looking into this! We have tested the suggested patches and they fixed the issue. Thanks again!