Missing features and current limitations

Comprehensive software stack

We have provided a basic software stack that should satisfy the intended use of the platform (System overview - Linux Virtual Desktop VDI), but some software packages or libraries you have used in the past may not be present. If that is the case, let us know by reporting as a "Problem on computing" through the ECMWF Support Portal mentioning "Linux VDI" in the summary.

Included software stack is listed here Software stack - Linux Virtual Desktop VDI

Local printing

At the moment the only printing services available from Linux VDI are those in the Shinfield Park offices. Print outs will be redirected to those printers, with the option of using a printer installed in the host running the Horizon Client not being available just yet, even if it is planned for the future. The current workaround is to print as a PDF file and then transfer it to the local system, for example via OneDrive (see How to configure and mount OneDrive - Linux Virtual Desktop VDI FAQ)

Host names of the VDI hosts will keep changing

The host names names of the VDI workstations could change every time the workstation is re-created, like for example with the monthly updates. This could have an impact for scripts that use the workstation host name, like the DISPLAY variables, allow lists or any other host-related information.

Trying to restart or shutdown the VDI host from the Gnome menus get a password dialogue which does not work

The password requested is the "root" password so the feature is not available to users. Please see for an alternative procedure How can I restart or shutdown my virtual desktop - Linux Virtual Desktop VDI FAQ

Gnome keyring not in sync with the user's password

We won't need a keyring for most Gnome applications, but sadly some of them (such as mysql-workbench) require it to encrypt and store passwords to other systems.

When the gnome "login" keyring is created, it will set a first-time password, which may or not be in sync with the user's ECMWF password. When our ECMWF password changes, the keyring password will not be updated automatically. This is a problem related to our authentication and password changes not taking place internally in the VM but in different systems external to VDI.

This is a problem very difficult to solve, if solvable at all. But, for now, at least there's a workaround:

1. Open seahorse:
   1. seahorse &
2. Check if you have a "login" keyring in the left pane
3. If you can see it:
   1. Close seahorse
   2. Relaunch the keyring daemon:
      1. gnome-keyring-daemon -r
   3. Open seahorse again
4. Try to unlock your "login" keyring. Right-click over "login", then "unlock"
5. Try your login password first, other old passwords if it doesn't work
6. If you managed to unlock it using your username and password, and you want to sync its password with your ECMWF one, change it: Right-click, "change password"
7. Otherwise (you couldn't find the right password that would unlock your keyring):
   1. Delete the keyring. Right-click, "delete"
   2. Go back to step 3

MySQL Workbench crashes when trying to connect directly to a MySQL / MariaDB database

This error, accompanied by a long backtrace that doesn't help very much, can be caused by:

• Wrong credentials
• Port 3306 not reachable (try to telnet to the destination using this port, see if the connection can be established). If this is the case, issue a ticket to NETSEC detailing the source and destination networks (all VDI to <SUBNET>:3306)
• Database with incompatible features. This is the most likely cause for this error. If you try to connect directly, it will crash. This is the solution:
  Go to Database -> Manage Connections
  New -> Enter the connection details

Click "test connection". It will show a warning if you are connecting to an incompatible version. Carry on.

If your credentials are OK, the port 3306 is open in the destination host, and the given user is set to connect from any host, then a success message will appear.

From now on, mysql-workbench shouldn’t crash.

Possible explanation: It seems that connecting directly to an incompatible DB halts the application because it tries to expose full features to an incompatible DB and they forgot to capture this exception in their code.

However, after doing the above test, workbench identifies the limitations of the destination DB and then it can deal with them along the way.

Kate crashes when trying to configure it

A required configuration file doesn't exist. Kate fails to create a new one, the exception is not captured and it crashes.

Oddly enough, if you just open kate, resize its window and then go to "File - Exit", it generates that file, so the next time it's open it won't segfault when going to "Settings - Configure kate".