Ubuntu 20.04 LTS: Install failure: MoTTY X11 proxy: Unsupported authorisation protocol | OPC UA HistorianProsys Forum

Please consider registering
guest

Forum

OPC UA Historian
sp_ArrowRight

Ubuntu 20.04 LTS: Install failure: MoTTY X11 proxy: Unsupported authorisation protocol

Topic RSS

Ubuntu 20.04 LTS: Install failure: MoTTY X11 proxy: Unsupported authorisation protocol

October 28, 2022
14:55, EEST

AntonioG

New Member

Members

Forum Posts: 2

Member Since:
October 28, 2022

Offline

I’m tring to install Historian (Demo) but fails …
Ubuntu is updated and I’ve install java-sdk and java-jre

ubuntu@mapsfuncont3mono:~$ sudo sh ./prosys-opc-ua-historian-linux-1.1.8-92.sh
Unpacking JRE …
Starting Installer …
MoTTY X11 proxy: Unsupported authorisation protocol
An error occurred:
java.lang.NoClassDefFoundError: Could not initialize class java.awt.GraphicsEnvironment$LocalGE
Error log: /tmp/install4jError9976447411973282778.log
java.lang.NoClassDefFoundError: Could not initialize class java.awt.GraphicsEnvironment$LocalGE
at java.desktop/java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:129)
at java.desktop/sun.awt.X11.XToolkit.(XToolkit.java:231)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:315)
at java.desktop/java.awt.Toolkit$2.run(Toolkit.java:588)
at java.desktop/java.awt.Toolkit$2.run(Toolkit.java:583)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.desktop/java.awt.Toolkit.getDefaultToolkit(Toolkit.java:582)
at java.desktop/javax.swing.ImageIcon.(ImageIcon.java:198)
at java.desktop/javax.swing.ImageIcon.(ImageIcon.java:217)
at com.install4j.runtime.installer.frontend.GUIHelper.loadIcon(GUIHelper.java:195)
at com.install4j.runtime.installer.frontend.GUIHelper.(GUIHelper.java:55)
at com.install4j.runtime.installer.frontend.headless.AbstractHeadlessScreenExecutor.init(AbstractHeadlessScreenExecutor.java:81)
at com.install4j.runtime.installer.frontend.headless.ConsoleScreenExecutor.(ConsoleScreenExecutor.java:24)
at com.install4j.runtime.installer.frontend.headless.InstallerConsoleScreenExecutor.(InstallerConsoleScreenExecutor.java:6)
at com.install4j.runtime.installer.Installer.getScreenExecutor(Installer.java:91)
at com.install4j.runtime.installer.Installer.runInProcess(Installer.java:60)
at com.install4j.runtime.installer.Installer.main(Installer.java:46)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at com.exe4j.runtime.LauncherEngine.launch(LauncherEngine.java:84)
at com.install4j.runtime.launcher.UnixLauncher.start(UnixLauncher.java:66)
at install4j.Installer2473419949.main(Unknown Source)

Any workaround?

October 28, 2022
15:50, EEST

Bjarne Boström

Moderator

Moderators

Forum Posts: 983

Member Since:
April 3, 2012

Offline

Hi,

Locally installed java etc. doesn’t matter as the application does have it’s own (as basically all java applications nowadays do).

Is the machine in question something else than a machine with a monitor and is being accessed locally using that monitor (or a VM)?

In practice the application only works with a GUI. Technically the service part should be runnable without an UI, however all configurations must be made on a separate machine first by installing the application first there and then be copied (and they must point to the same database). Some of the instructions might be a bit old, however that would only apply after an install so it doesn’t affect here.

The install works on desktop Ubuntus 18.04, 20.04 and 22.04 (which I daily-drive).

I also just tested on a 20.04 server (ubuntu-20.04.5-live-server-amd64) on a blank VM, installation works.

Thus, you most likely are doing something different; not sure can we help with that.

October 28, 2022
17:33, EEST

AntonioG

New Member

Members

Forum Posts: 2

Member Since:
October 28, 2022

Offline

Hi
The machine is a VM running in a Openstack system and the xterminal is MobaXterm running into Windows 10.

October 31, 2022
9:41, EET

Bjarne Boström

Moderator

Moderators

Forum Posts: 983

Member Since:
April 3, 2012

Offline

We have not tested that kind of use-case (X11 tunneling/forwarding), thus I sort of would have to say it is outside of the support scope. But I can give 2 ideas:

Google “MoTTY X11 proxy: Unsupported authorisation protocol”, at least this comes up: https://chadrick-kwag.net/x11-proxy-unsupported-authorisation-protocol-error-fix/ (though I do not know what this will imply, thus try on your own risk), so maybe this can just be solved via configuration.

Try opening raw terminal ssh connection (https://docs.openstack.org/horizon/queens/user/launch-instances.html mentions “Connect to your instance by using SSH”), so that there would be no X11 tunneling etc. thus, then the installer should start in cli mode (or most likely it is easier to just start the installer with -c flag, we currently do the installers via install4j, thus these should work: https://www.ej-technologies.com/resources/install4j/help/doc/installers/options.html). However, you will need the configurator UI to configure everything (including the database connection), so it is possible that you run into the same problem. So the intended flow is that you would start the configuration UI, configure database connection, then start the service component, and then configure rest. Once everything is configured, you can just run the service component.

P.S.
Eventually we’ll make some web UIs; those would solve a lot, however at the moment our apps are desktop-based.

All RSS

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 518

Currently Online:
10 Guest(s)

Currently Browsing this Page:
1 Guest(s)