In general, Green Screens Server supports connecting to the IBM i server through SSH tunnel using SOCK5, but for this to work fully, JT400 also must support SOCK5 protocol.  In recent posts, we wrote about SOCK5 support for the IBM JT400 library we contributed to. You can find it here...

This time we will show how to create an SSH Tunnel running as a Linux Service and how to use Green Screens Server to connect to the IBM i to make all internal connections secure and encrypted.

Linux side

On the Linux side, we created a new SSH key and a service to run a tunnel in the back. Later, inside the Green Screens Server Admin console, we will create a tunnel configuration and an IBM i server connection configured to use our tunnel.

NOTE: If you already installed Green Screens Server, you should have a greenscreens user already. If there is no user just yet, create it with the following commands...

sudo groupadd greenscreens
sudo useradd -m -s /bin/bash -g greenscreens greenscreens

Switch to the greenscreens user and navigate to the home folder first

su greenscreens

Create new SSH key for a tunnel

To create an SSH key, multiple algorithms are available. We recommend one of the last two from the list.

ssh-keygen -t rsa -b 4096
ssh-keygen -t dsa 
ssh-keygen -t ecdsa -b 521
ssh-keygen -t ed25519

When a command is executed, it will prompt you for a file name output. Enter ibm_tunnel

Once files are created, make sure to apply proper permissions

chmod 700 ~/.ssh
chmod 600 ~/.ssh/ibm_tunnel
chmod 644 ~/.ssh/ibm_tunnel.pub
chmod 600 ~/.ssh/authorized_keys
chmod 644 ~/.ssh/known_hosts
chmod 755 ~                        # ensure home is not writable by others

Create Linux service to run the tunnel

Create a new service file

sudo nano /etc/systemd/system/ssh-socks.service

And paste the following to the file, and save it (CTRL + X). Make sure to set proper IBM i server IP address or domain name instead of demo.ibm.com as shown in example.

[Unit]
Description=SSH SOCKS5 Tunnel
After=network.target
Wants=network-online.target

[Service]
Type=simple
User=greenscreens
StandardOutput=journal
StandardError=journal
Restart=always
RestartSec=5
WorkingDirectory=/home/greenscreens
ExecStart=/usr/bin/ssh -NTq -i /home/greenscreens/.ssh/ibm_tunnel -o ServerAliveInterval=60 -o ServerAliveCountMax=3 -o ExitOnForwardFailure=yes -D 1080 tunnel@ibm.demo.com

[Install]
WantedBy=multi-user.target

At the end, we need to enable and start the service. Before that, go to the next chapter to configure an IBM user, then return here and use these commands to start a tunnel service.

sudo systemctl daemon-reload
sudo systemctl enable ssh-socks
sudo systemctl start ssh-socks
sudo systemctl status ssh-socks

IBM i side

At the IBM i side, we need to create a new limited user with *SIGNOFF flag and apply SSH public key generated at the Linux side so we can connect from remote.

NOTE: If you are using firewall or packet filtering rules, make sure to modify them and allow SSH connections from your Linux server.

CRTUSRPRF USRPRF(TUNNEL) PASSWORD('Secret123')
         USRCLS(*USER)
         INLMNU(*SIGNOFF)
         LMTCPB(*YES)
         HOMEDIR('/home/tunnel')

Then from PASE or QSH, configure user home directory

mkdir -p /home/tunnel
mkdir -p /home/tunnel/.ssh
chown tunnel:tunnel /home/tunnel
chmod 700 /home/tunnel
cp -a /etc/skel/. /home/tunnel
chown -R tunnel:tunnel /home/tunnel

Last step is to copy content from Linux /home/greenscreens/.ssh/ibm_tunnel.pub to the /home/tunnel/.ssh/authorized_keys

ssh-copy-id -i /home/greenscreens/.ssh/ibm_tunnel.pub tunnel@demo.ibm.com

...then try to SSH from Linux to the IBM i server from command line.

ssh -i /home/greenscreens/.ssh/ibm_tunnel tunnel@demo.ibm.com

If that works, you are ready to start SSH-SOCKS service at the Linux side with systemctl commands as shown earlier.

IMPORTANT

For security reasons, make sure your SSH server identification keys are not default ones from installation.

When IBM i OpenSSH & OpenSSL — Licensed Program 5733-SC1 is installed, default SSH keys are installed also which you don't want to use as default. These keys are used to identify server during initial SSH connection handshake and plays important role in MITM protection. For security reasons, one should regenerate these keys as soon as 5733-SC1 is installed. Here is how to do it....

# navigate to SSH config
cd  /QOpenSys/QIBM/UserData/SC1/OpenSSH/etc/

# remove default keys
rm ./ssh_host*

# regenerate all keys
ssh-keygen -A

# remove weak key
rm ssh_host_dsa_key*

#optionally enable stronger keys
# vi sshd_config
# then uncomment ecdsa and ed25519

# restart SSHD
ENDTCPSVR *SSHD
STRTCPSVR *SSHD

# Generate key hashes and output to the console
ssh-keygen -lf /QOpenSys/QIBM/UserData/SC1/OpenSSH/etc/ssh_host_rsa_key.pub
ssh-keygen -lf /QOpenSys/QIBM/UserData/SC1/OpenSSH/etc/ssh_host_ecdsa_key.pub
ssh-keygen -lf /QOpenSys/QIBM/UserData/SC1/OpenSSH/etc/ssh_host_ed25519_key.pub

Hashes generated with the last 3 commands can be used to verify server side response is coming from the real server. A MITM protection. Latest Green Screens Server update coming soon will support these hashes for increased security.

Green Screens Server

Last step is to use the Green Screens Admin console to configure the SSH tunnel. As shown in the image below, use SOCK5 as Type and enter the configuration name. SOCK5 always uses 127.0.0.1 as an interface to connect.

Attach newly created tunnel to the IBM i server configuration. Note that even if the connection points to the IBM i server IP address, actual connection is made locally to the SSH service which internally connects to the IBM i as defined in Linux ssh-sock service. So, address 127.0.0.1 here is local to the SSH daemon running on the IBM i server.

And finally, check the connection... If it is working, it will show a validation response. Validation procedure also verifies if all other types of connections are passing through.

Final note

If validation is successful, but still not able to open a terminal session, make sure IBM i internal firewall or packet filter does not block ports, especially port 23 to connect from localhost. SSH tunnel from remote (IBM i side) will connect to itself at localhost.

In this chapter we will write about advanced JT400 usage with the SOCK5 support added by Green Screens Ltd.

In the beginning, we made a lot of magic to make it work for internal needs of our Green Screen Server. After every JT400 library update we had to repeat the code update process over and over again to support JT400 library updates.

The solution we had was not good enough to go to the public, however, it became easier for us to update the changes required internally by our product after JT400 migrated to GitHub and after some code and build process were refactored. Over time, the solution was polished, optimized and finally shared to the public.

How does it work?

For this solution to work properly, IBM I server must be running SSHD service.

From client side, open SSH tunnel in daemon mode to forward all incoming connections through SSH encrypted channel to the other side.

ssh -D 5000 ibmuser@ibmserver -p22 -gfTN

Command above will start SSH daemon listening on port 500o for SOCK5 protocol connections. Connect to the ibmserver with the user ibmuser and will be running as a background service in daemon mode.

With Green Screen Ltd. contribution to the JT400 library, minimal one-line change is required to use SSH connection in SOCK5 mode.

// localhost is address visible from SSHD runing on IBM i
final AS400 as400 = new AS400("localhost", "demo", "demo");

// localhost here is SOCK5 service runnign at local machine
as400.setSock5Server("localhost:5000");

System.out.println(as400.validateSignon());
as400.close();

Simple example for AS400JPing is similar...

// localhost is address visible from SSHD runing on IBM i
final AS400JPing pingObj = new AS400JPing("localhost", AS400.CENTRAL, false);

// ==>>> easy 
pingObj.setSock5Server("localhost:5000");

pingObj.setPrintWriter(System.out);

pingObj.ping(AS400.CENTRAL);
pingObj.ping(AS400.SIGNON);
pingObj.ping(AS400.COMMAND);
pingObj.ping(AS400.FILE);
pingObj.ping(AS400.PRINT);
pingObj.ping(AS400.RECORDACCESS);

To use AS400JDBCDriver...

// preload and register driver 
Class.forName("com.ibm.as400.access.AS400JDBCDriver");

// Driver url with proxy as sock5
final String jdbcUrl = "jdbc:as400://localhost;use sock5=true;proxy server=localhost:5000";

// final connection
final Connection conn = DriverManager.getConnection(jdbcUrl, "demo", "demo");
... do SQL query

To use AS400JDBCDataSource

// localhost is address visible from SSHD runing on IBM i
AS400JDBCDataSource ds = new AS400JDBCDataSource("localhost");

// the same property is used for proxy and sock5 
ds.setProxyServer("localhost:5000");

// flag to tell how to use proxy value (as sock5 or proxy)
ds.setUseSock5(true);

ds.setUser("demo");
ds.setPassword("demo");

AS_UNIX for UNIX/Linux

Above is just part of the story. We also added support for UNIX/Linux AF_UNIX socket (not fully tested). A type of connection using inter-process communication without using network stack.

For example, many databases allows direct connections for internal services, such as applications written in NodeJS or Go or Rust etc. running as a service connected to the database can utilize AF_UNIX for better performance.

Even SSH itself do not support such approach, Green Screens developed it's own encrypted tunnel, a version of Shadowsocks with SOCK5 and AF_UNIX support for internal needs allowing Green Screen Server to connect to the AS_UNIX process for encrypted tunnel at the other side.

The principle is to start Green Screens Server and Green Screens Tunnel inside a cloud for an example, then a second Green Screens Tunnel at the IBM i server side of the network, to allow encrypted connections. Such system would allow even direct connections with the original unmodified JT400.

Latest JT400 source update with Green Screens Ltd. changes can be found at our JTOpen GitHub repository.

For anyone interested in involvement or comments, please check our pull request at the original IBM JTOpen repository...  Add SOCK5 and UNIX channels support to JT400

In this chapter we will write about advanced JT400 Proxy usage with the help of Green Screens Server.

If you are not familiar with the Green Screens Server for IBM i product, one of the ideas / concepts is to use it as an isolation layer between online end users and IBM server in the background. Especially if the IBM i server is used in the cloud.  

Green Screen Server can be run inside DMZ while IBM i server can be behind the firewall. In case of hackers attacks, attacks will happen only at the Green Screen Server without affecting IBM i.

For Green Screens Server to fully operate as an isolation layer, having an ultra fast web based 5250 terminal is only part of the story. Other commonly used services quite often used in separate client software are relying on JT400 including AS400JDBCDatabaseDriver and AS400JDBCDataSource and many more. To use them in a safe manner, different channels were required.

Not any more. Green Screens Server V6 brings an embedded proxy tunnel directly into the web server without need to use JT400Proxy Server. Utilizing modern +JEE9 Jakarta based servlets with ASYNC support.

To achieve that we needed to update the JT400 library to expose internal class but also a few small changes were added to support custom URL paths which in original code are fixed values not always practical in a custom environment.

Why is this so important?
Green Screens Server supports API token based access per installed service used to control access based on IP address. Additionally, service credentials to access to the IBM i server are supported without sharing credentials to the external service or user.

JT400 can use that feature with absolutely minimal code changes. But, before digging into examples...

Green Screens embedded Proxy Service have 2 URL endpoints (tunnel and token).

Tunnel endpoint is an URL used for the JT400 library to connect to the background IBM i system with access controlled by API key (controlled by IP address). While internally full web server based TLS/SSL encryption is supported along "asynchronous" thread safe +JEE9 servlet processing.

Let's look at the simple example to connect to the IBM i behind DMZ and Green Screens Server.

final String proxy = "https://gsserver.greenscreens.ltd/service.proxy/tunnel?key=88c4bdf1-eb92-423f-8a18-8ee0ba4c6868";

final AS400 as400 = new AS400("ibmserver");
as400.setProxyServer(proxy);

Token endpoint is an URL used to retrieve ProfileTokenCredential generated at the Green Screens Side and can be used independently for direct connection to the IBM i (if required) or through Green Screens Server Proxy tunnel.

Here is a simple pseudo-code example to generate IBM i access token without knowing username or password using Green Screens Server Proxy Service, API key, and token endpoint.  

NOTE: Functions FactoryProxy400.getToken and FactoryProxy400.getCredential are part of Green Screens Client library not published yet.

final String tokenURL = "https://localhost/service.proxy/token?key=88c4bdf1-eb92-423f-8a18-8ee0ba4c6868&proxy=false";

final AS400 system = new AS400("ibmserver");
final ObjectNode node = FactoryProxy400.getToken(tokenURL);
final ProfileTokenCredential credential = FactoryProxy400.getCredential(node);

credential.setSystem(system);
system.setProfileToken(credential);

Above example is for retrieving a token to access to the IBM i server directly. To connect through Green Screens Server Proxy Service, code change is minimal.

final String proxy = "https://gsserver.greenscreens.ltd/service.proxy/tunnel?key=88c4bdf1-eb92-423f-8a18-8ee0ba4c6868";

// --> notice proxy=true change
final String tokenURL = "https://localhost/service.proxy/token?key=88c4bdf1-eb92-423f-8a18-8ee0ba4c6868&proxy=true";

final AS400 system = new AS400("ibmserver");
final ObjectNode node = FactoryProxy400.getToken(tokenURL);
final ProfileTokenCredential credential = FactoryProxy400.getCredential(node);

credential.setSystem(system);
system.setProfileToken(credential);

system.setProxy(proxy);	             // <--- redirect though proxy

Once AS400 instance is created, all other type of JT400 connections through encrypted tunnel are available including JT400JDBCDataSource, JT400JDBCDatabaseDriver, JT400FTP, JT400JPing.

To use above proxied connection for JDBC driver, to open a database SQL connection

final AS400JDBCDriver driver = new AS400JDBCDriver();        
final Connection conn = driver.connect(as400);

To use JT400 Database Driver with Driver manager

// preload driver
Class.forName("com.ibm.as400.access.AS400JDBCDriver");

final String proxy = "https://gsserver.greenscreens.ltd/service.proxy/tunnel?key=88c4bdf1-eb92-423f-8a18-8ee0ba4c6868";

final String jdbcUrl = String.format("jdbc:as400://ibmserver;proxy server=%s", proxy);
final Connection conn = DriverManager.getConnection(jdbcUrl, "demo", "demo");

To use JT400 JDBC DataSource

final String proxy = "https://gsserver.greenscreens.ltd/service.proxy/tunnel?key=88c4bdf1-eb92-423f-8a18-8ee0ba4c6868";

final AS400JDBCDataSource ds = new AS400JDBCDataSource("ibmserver");
ds.setProxyServer(proxy);
ds.setUser("demo");
ds.setPassword("demo".toCharArray());

final Connection conn = ds.getConnection();

Latest JT400 library with Green Screens combined changes can be found at our GitHub repository.

And if you have any comments or want to participate - original request for change to add a custom URL path and query parameters to the ProxyClient can be found here.

Many times we saw various developers asking for SOCk5 support to programmatically connect to the IBM i servers with the JT400 through SSH or other network encryption systems supporting SOCK5.

Until now, safe connection to the IBM i  with JT400 was possible in a few ways:

• Using direct SSL connections - possible if IBM server is directly accessible which is a problem for many companies having their system in the cloud.
• Through JT400 embedded simple HTTP server in Proxy mode. This approach still requires direct access to the IBM i. It is  even more complicated as it requires running JT400 ProxyServer on IBM i side of the network.  Channel itself can be hidden behind a proxy and protected with TLS/SSL. Not practical in our case for integration with Green Screens Server.
• By using VPN tunnel and direct connections without proxy. VPN in general is slow, and might create various network drops. Running long tasks with a lot of data transfer can be very problematic.
• By using SSH in port-forwarding mode only. This is problematic as all ports required by JT400 must be reserved and opened in advance. JT400 uses default port 449 to "query" services and their ports making this approach a limited solution. Only one connection is available, making this solution usable in some cases, but not all.

To solve those problems, we added two solutions:

• Part1 (WebProxy)  - Integrated Web Proxy into Green Screens Server with API key access control and IBM i access token without requirement to know IBM user / password.
• Part2 (SOCK5) - Updated JT400 library to support direct access through SSH using SOCK5 either using DDM services, or IBM DB2 database drivers supplied with the JT400.

To find out more details, we created a separated posts for each of provided solutions. Feel free to check them at links above.

Latest JT400 source update with Green Screens Ltd. changes supporting both solutions can be found at our JTOpen GitHub repository.

For anyone interested in involvement or comments, please check our pull request at the original IBM JTOpen repository... links below. Pull requests for code changes are in the review procedure hoping that both enhancements will be accepted and implemented in official JT400.

Add SOCK5 and UNIX channels support to JT400
Add custom URL path and query parameters to ProxyClient

SSO test JSON support

We improved SSO test service for better reporting, and also we added JSON test result output for URL queries with MIME type "application/json".

SSO auto-detect (ldap / kdc discovery)

Networking library updates with DNS improvements to discover LDAP and KDC servers based on local network DNS service. Important feature for other SSO features added within this release. Now, Green Screens Server can detect LDAP / KDS from local DNS network to simplify SSO configuration even more.

SSO auto-configuration

New auto-configuration feature allows to automatically configure and register Green Screens Server for MS AD environments. When a service user with defined SPN is used with auto-configuration wizard, Green Screens Server is able to automatically  generate "keytab.file",  server SPN and all other configs, significantly reducing SSO configuration complexity.  

SSO lite support

There are situation when for various reasons, customers can't implement full Kerberos based SSO. Some older systems use custom made mechanism to achieve terminal SSO based on credentials stored in LDAP.

Thus, we added a new feature - SSO Lite based on LDAP storage. Additionally, we added JMX based plug-in system to allow custom data processors, commonly used for LDAP stored password decryption.

Module is implemented primarily to simplify migration to official Kerberos based protocols (MS AD etc.).

URL sharing flags improvements

We changed URL sharing flag from enable/disable to support multiple protection options. We added IP-Hash and Browser-Fingerprint based control mechanism. IP-Hash is less restrictive and can be useful in specific scenarios such as for SSO Lite support. IP-Hash security is relaying on SSO tokens and client IP address matching, while Browser-Fingerprint mode is very restrictive and allows generated connection  URL to be used only from a browser that initiated session.

Screen sharing improvements

We made some internal optimizations for screen sharing feature making it more performant and more reliable.

Following the recent release of IBM OS400 7.6, which introduced native support for 5250 OTP login, we are pushing the boundaries of security integration even further.

Green Screens Server for IBM i is made with a focus on security and primarily as a Cloud based solution, which drive us to focus on high security standards and security related features.

We are thrilled to announce that Green Screens Server for IBM i V6 will enable seamless integration between Kerberos Single Sign-On (SSO) and OTP/PassKey technologies (commonly known as FIDO, WebAuthn, and biometric authentication). This advancement allows users with registered PassKeys (or optionally OTP tokens) to securely access the IBM i terminal without needing to enter or even know their passwords.

Green Screens currently support features such as "Verification" and "Bypass Password" mode. However, the latter is not an ideal solution, which has led us to develop a new feature based on "Kerberos S4U2Self" integration with PassKey. Imagine using a fingerprint reader or physical security keys like YubiKey or Google Key to access the system effortlessly—without needing a password or any desktop installation requirements. This truly exemplifies a cloud-based and secure solution.

Additionally, we made a significant progress toward creating an integrated solution for SAML and OIDC standards for 5250 terminal SSO login. While we recognize that this is a complex journey, we are optimistic that the final solution will support a variety of online password-less multi-factor authentication (MFA) integrations. Currently, our main focus is on finalizing SSO-PassKey-OTP integration, and once that is complete, we will turn our attention to Keycloak integration.

We are excited about these innovations and their potential to enhance security and improve the user experience.

Due to the latest changes in Java ecosystem, from Java JVM to Java EE profiles, encryptions algorithms deprecation etc. our announcement is very important as it depicts the future plans and course of the Green Screens server.

Older versions of GS (1..5) will not be possible to upgrade to never runtimes any more simply as technology used will become obsolete in near future.

New Java 21+ and Jakarta EE API are already replacing long lasting technologies.
With java 21, some encryption algorithms are deprecated and are scheduled for removal from later JVM LTS versions.

Existing server runtimes using older Java EE reached their end of life support.

Some online services such as ACME Let's Encrypt will switch from SHA-1 to SHA-256 or stronger. Some others already made the switch. New TLS certificates will contain (many are already upgraded) more modern and stronger algorithms.

Clustered Nodes Changes

GSv5 and newer support data sharing and syncing when running multiple nodes behind a proxy. Still, the current syncing mechanism is based on external open-source software and file synchronization which is not supported on some platforms such as IBM i preventing multiple GS nodes in a cluster on IBM i servers. Changes in 2025 will bring a new Java native based sync mechanism to overcome this limitation.

Also, synchronization will not be based on files any more but on raw memory data. Currently, we are in the second alpha stage. As many issues have been resolved, and basic shape is finished, further progressing should be faster.

Migration to the newer GS server versions (from GSv5 towards GSv6 / GSv7) will start after the new cluster engine is finished and after required JVM LTS version release.

GSv4 Changes

GSv4 is going to be retired in the beginning of 2025. And will be under the maintenance only mode until all our customers under maintenance contract upgrade their systems to GSv5 or newer.

Customers without maintenance contract will eventually have to buy a new version under product full price if old version stop working due to the technology advances. There will be a moment when JVM will not be upgradable for old versions as some API within JVM are changing also.

GSv5 Changes

GSv5 full retirement is planned for the end of 2026.
GSv5 updates through 2025 and 2026 will be more and more synchronized with GSv6 for easier transition.
GSv5 is going to stay as last version to support older Java technologies and older IBM i releases which does not support modern security algorithms such as ECDH/ECDSA, TLS1.2/TLS1.3, and other.
GSv5 will stay compatible with Java EE and Java EE compliant servers.
GSv5 will stay compatible with Java 11 or 17.
GSv5 will be possible to run in on IBM servers with Java 11 or 17.
GSv5 running on Java 11 will be limited - no multi instance sync support.
GSv5 will stay on server runtime 26.1.3. and will not be compatible to run on newer versions.
GSv5 will stay in maintenance mode only, all existing clients under the maintenance contract running GSv4 will be updated to the GSv5 and later to GSv6.

GSv6 Roadmap

NOTE: GSv6 is ready in pre-release state. Stabilization of new JVM and runtimes are in waiting room.

Incoming GSv6 brings significant security changes and runtime changes.
GSv6 will run on Java 17 (to run on IBM i) and Java 21 (default).
GSv6 will run on IBM i servers supporting Java 17 or future Java 21.
GSv6 will use server Jakarta EE instead of old Java EE.
GSv6 will use newer server releases from version 32.0 or newer.
GSv6 will be transitional version for GSv7.
GSv6 will support only stronger hash algorithms from SHA-256 or stronger.
GSv6 will support only stronger elliptic curves from EC-256 or stronger.
GSv6 will support only stronger RSA key from 2048 bit or stronger.
GSv6 will support only TLS1.2 or TLS 1.3 encrypted protocols.
GSv6 will not support SHA-1 hash algorithm.
GSv6 will not support RSA 1024 keys.
GSv6 will not support SSL, SSLv2, SSLv3, TLS1, TLS1.1 encryption protocols.
GSv6 will not support secure connections to the older IBM i systems without TLSv1.2 or newer.
GSv6 will not support secure telnet sign-on bypass for IBM i systems supporting only DES/SHA-1 scheme.

GSv7 Roadmap

Future GSv7 is planned to run primarily on Java 25 LTS or newer.
Java 25 planned release is September 2025.
GSv7 planned pre-release is December 2025.
GSv7 is GSv6 with internal API changes to support pre-Java 21 API removal and new JVM 25 LTS features.

JVM update

JVM is updated to the latest version which brings important improvements to the Kerberos and SSO integration.

Additional SSO access control feature

A new SSO access control module is added, capable of  detecting SSO user group directly from SPNEGO user token.

Additionally, we added new parameters "admin group" and "user group" definitions to determine which SSO user groups are allowed to use GS server and to access either web admin console or IBM systems in the back.

SSO for Admin Console

We added support for admin console integration within MS AD and Kerberos SSO. Flags are added to control access either as SSO only login, credential login or both.

New network buffer engine

New network buffer engine is introduced to improve performance and stability. The engine itself is completely rewritten from scratch.

New data folder structure

New data folder structure is now compatible with GSv6. After the update GS server will restructure the data folder into a new format automatically. This will simplify future upgrades to the GSv6 (and future GSv7). The new structure is also important for GS server when running as a node in a cluster configuration.

Syncthing support

It is of a crucial importance when GS server are used in a cluster for data to be synchronized between the nodes. Especially for data such as MFA (OTP, WebAuth, etc. ). Thus, we migrated Syncthing (open source file sync) integration module from GSv6 to GSv5.

Even Syncthing supports variety of OS environments, we are working on pure Java implementation to not to depend on 3rd party tools and to have even wider OS environment support for clustered setup.

Detail list of changes can be found here.

First and foremost, several clients and potential customers asked us how do we charge for multiple servers.

Green Screens Servers multiple instances are available only for redundancy purposes and only for customers under the maintenance contract. Number of instances are not limited, customers can run as many instances required without additional charge. Green Screens Servers are licensed per workstation use regardless of how many instances will run in parallel.

While using multiple Green Screens servers instances running behind a load balancer, we are relying to third party products (such as Syncthing) for data synchronization.

For example, when using MFA, when user want to register OTP, or Biometric token, load balancer will redirect all request to a single Green Screens Server instance, still data needs to be updated to other instances in the background. And this is where Syncthing helps.

We made an integration and auto-discovery with mentioned Syncthing - however, that has one drawback. It is not supported on every platform (including IBM i) where Green Screens can be installed limiting OS choice mostly to Linux and MS Windows when using multi instance setting.

With the incoming release, we will introduce a new Java based engine integrated into Green Screens itself. Without need for extra software.

Technology behind is P2P (point-to-point protocol) and DHT (distributed-hash-tables). It is common for cloud based storage or for chat applications such as Signal, WhatsApp and other...

Such products usually requires external Cloud based service, which is not the case with Green Screens Server. New sync engine will be integral part of the Green Screens product, configuration and overall maintenance will be significantly easier without any 3rd aprty dependency for either external tools or cloud services.

New service will be available to all customers under GSv5 or newer, and might be backported to GSv4 for customers under the maintenance contract.

Planned release for GSv5 is mid December 2024. , other versions will follow within few weeks.

Improved processing buffer

We improved network data processing buffer to be more performant, less memory demanding and more robust. New buffer engine should increase data processing by 2-3 times faster.

MS AD integration improvement

SSO integration with MS AD / Kerberos is improved. We changed some SSO mechanism internals making it more reliable.

Multiple KDC support

When multiple Kerberos servers are defined through the DNS, previous version might have problems validating tickets if the first (prioritized) Kerberos server is down. New update fix this issue, now it will automatically switch to a new - first available Kerberos service.

Kerberos test page improvements

Green Screens Server contain a test page used for testing and troubleshooting SSO/Kerberos issues during setup. Updated version will give more information on the page including User Groups (new feature) and many more.

Kerberos/ MS AD user roles support

We added full Kerberos Ticket user group extraction and available user group retrieval from KDC. This allows us more control. Now, there are 2 default user groups "GS User" and "GS Admin" defined. If enabled, will block Kerberos Tickets for users not belonging to mentioned user groups to sign-on.

Web Admin Console SSO

Adding Kerberos User Group feature allowed us to enable SSO web admin access based solely on OS logged in user within domain network without requiring login credentials.

Other updates

Latest update can't work with previous runtime version as we updated JVM to the latest version, server runtime is updated and common libraries were updated. Some of libraries have parts of the API's changed because of which we had to update our code. This is the reason why along the product update, runtime update is also required.

NOTE: GSv4 is a maintenance version, not available to new customers.

JVM Runtime

Java runtime is updated to the latest Eclipse Adoptium Temurin-17.0.11+9 for GSv5 and GSv6, while Eclipse Adoptium Temurin-11.0.23+9 for GSv4.

Server Runtime

Java web server is updated to the latest versions available for specific release.

Libraries

Libraries used across GS server app are updated to the latest versions available.

License installer

New version with improvements is provided across all GS versions.

ACME Service

ACME service is an integration engine for external services such as Let's Encrypt used for server certificate self-registration and activation. Service is significantly improved. (GSv5 and GSv6)

Update engine

Completely new and more robust update engine.

IBM i installation

GS server can run anywhere where Java can run. IBM i is one of such environments. We significantly improved installation scripts. Server versions GSv5 and GSv6 are fully compatible to run on IBM i servers which supports Java 1.8 or newer.

NOTE: GSv6 requires Java 17, while GSv5 requires Java 1.8 or never for older IBM i OS releases.

Central licensing support

Until now, each IBM i partition used through GS server required installation of GS product definition and license code for each partition. We simplified licensing by allowing to use a single partition only. Currently, this is only preparation for next release.

GSv5 specific

Startup sequence is improved including performance improvements, threading improvements and web admin console improvements and bug fixes.

It is specially built version for cloud environments with some advanced features compared to original version.  Server itself is in internal testing stage, but progressing quite fast. What remains to finish are backend services that will be eventually setup on our online servers.

Here are some notable features:

• Automated updates
• Automated license renewal
• Hardware based encryption
• MITM resistant
• Reduced network signaling
• Subscription Based model only
• Telemetry improvements
• Virtual threads

Automated updates

Introduced in GSv5, now even better with integration possibilities with external schedulers or with MS Windows Task Scheduler or Linux Crontab. New features will allow backend teams to customize and control when to update all instances.

Security is also improved with internal IP filter engine, allowing to define triggers  source IP allowed.

Automated license renewal

Automated license renewal module will control license key distribution. Every Green Screens Server instance will connect to our licensing server requesting updated license key and if available will automatically apply to the IBM i server. Cloud backend will not have to worry about license control.

Hardware based encryption

All screens are already "masked" with unique identifiers per single request. If there is a breach, it will be valid only for that specific data block.

With SaaS version, we bring even better security for terminal screen data with hardware backed  strong encryption on session layer for compatible OS/HW combinations. Much harder to break, and even if breach happens, it won't affect other sessions.

MITM resistant

With new set of security features, it makes our data even safer in open Internet which reduce requirement for VPN tunnels and along the path reduce additional cost.

Reduced network signaling

Green Screens Terminal data are in specially encoded and compressed form and in average are smaller than standard 1500 MTU. Around 85%-90% of data is less than 1.5KB compared to competitor products of 8-12KB.

This feature is significant for cloud environments where network data transfer rates apply. Also, it is significant for  end customers as overall feel of responsiveness is high.

Subscription Based model only

With this version we are slowly heading to subscription based model payment only.  Perpetual license keys will not be provided any more once this version goes to the production. Older version will eventually be terminated except for the clients under the maintenance contract. Model will be based on monthly / half-year / or 1-3 years subscription contracts with price discounts and will be all-inclusive model.

Telemetry improvements

OpenTelemetry feature was introduces of GSv5, now improved with more data and in sync with latest SDK version and support for Prometheus and Graphana.

Virtual threads

Green Screens Server SaaS version is build with modern Java 21+ and supported only on Java 21 or newer. New Java Runtime brings Virtual Threads which practically allows millions of parallel tasks running in highly optimized environment.

This feature reduce memory requirements, improves performance and allows much more parallel terminal sessions across single hardware unit.

It is a major upgrade, not compatible with previous version. There are a lot of new classes and new components added.

Full source code is available at our GitHub pages.

What's new ...

Reactivity and templating
Along Bootstrap CSS, we refactored WebComponents on top of a Lit Elements 3.0 which brings reactivity and fast and memory efficient templating engine - faster than Virtual DOM. Why we did that switch, please read in the second half of the page.

Removal of GS-STYLE and GS-LINK components
Instead, we are using MutationObserver internally, hidden from front-end. Developers can now use standard LINK and STYLE HTML elements only.

Dynamic CSS class
We significantly improved dynamic CSS styles, which some components require. They are faster, and local to the component.

Improved theming support
Bootstrap uses CSS rules for theme switching. We significantly improved our theming module to allow extremely easy theme switching with full support for global and individual component themes, all on the same page.

Data helpers
A new module "helpers" is added. A set of classes to handle raw JSON data, such as Tree and TreeController for handling JSON as a tree structure. Data helpers simplifies development with some combination of MVC and MVVM models.

DataHandler WebComponent
This is a new UI component which purpose is easy activation of JSON data readers. Simply add HTML tag to the page. It simplifies dynamic registration. Can be very useful when creating SPA applications and reduce code writing.

Component storage linking
New WebComponent structure, allowed improved and easier WebComponent-Data-Storage linking and integration. Now ,linking data with tables, trees, lists, menus etc. are easier than ever. In most of the cases, it is enough to add a named gs-data-handler component to the page to activate remote data reader/writer and reference it to the data components. All without a single piece of JavaScript code.

Self-rendering components
Now, all components which elements can be rendered from data can be easily linked for dynamic server side (JSON based) data UI rendering.  It even allows you to create custom components responsible to render other components based on JSON data.  

New GSTreeReader
New data reader which automatically converts JSON data into navigational linked Tree data. Mostly used by GSTreeElement.

New bindable actions
Bindable actions are part of reactivity and WebComponents interlinking and user based interactions. This feature allows rapid creation of UI with minimal JavaScript code.

Bootstrap uses data-bs-* attributes to create user clickable interactions between various elements on the page. We supported that in previous version. Bootstrap attributes support was removed... Instead, we created a powerful GSAttributeHandler, a complete refactoring and distinction from data-bs-* to data-gs-* attributes.

New localization engine
Multi language support is completely refactored and significantly improved. Now, every WebComponent support automatic translation to the selected language.
We added GSLocalization class deeply integrated into WebComponents and responsible for UI translation.

Improved code separation
Implementation of Lit Elements allowed us better code separation through "controller" classes separated from main WebComponent development. Code is cleaner, lighter, easier to understand and finally, much more modular.

Why we introduced additional (but tiny) library Lit Elements is related to our another project - UI Modernization for Web 5250. But let start from beginning...

From the beginning, we had an idea that our product and extendable elements for end users should be easy and simple, but also having in our minds how to do web based 5250 screen modernization in a purest and simplest form so even small teams or individuals at the client side can do their own modification without knowing too much about advanced web development and without need for complex tolling installation at the server side.

We needed something general we can use across the whole web front end, and at the same time not requiring "layer on top of the layer" of technologies just to get the final single JavaScript file.

Several years ago, there were no JavaScript classes (only functions), there were no modules (external libraries such as require.js) etc... And finally, there were no WebComponents, but various frameworks existed which simulated component based development. All such libraries and frameworks were predecessors to today JavaScript natively supported features. Many of them requires complex server side tooling and compilation, transpilation into JavaScript.

We were not satisfied with available technologies, so we decided to develop our own that suits us the best for our needs. It happened in late 2020. It took us about 18 months to create, test and stabilize the framework - now known as Green Screens Web Components.

When you start to develop your own, vanilla JavaScript, and start to dig deeper into the technology, the further and deeper you go with the project, you start to realize that "oh moments" when things get complicated and tricky.

We estimated that the features we wanted to introduce are not important in the moment of initial component development, and some of the features are postponed for some future releases.

One of the features we needed is "reactivity" and another is a fast UI templating engine.  We realize, that implementing reactivity, we would need to do a lot of code refactorings.

In the meanwhile, other frameworks and libraries also improved, bringing exactly what we need, features that did not exist before. So, to not reinvent the wheel, we decided to introduce a 3rd party tiny lib. In October 2023. Lit Elements 3.0 was published. As Lit is covering all our requirements, it was a logical decision to use it.

In a very short period of time, a lot has changed in JavaScript ecosystem world. To keep up with the technology, we needed such a code change. That's how front-end development is live and very active, and sometimes demanding.

Project vanilla-lit

When we were investigating possibilities, Lit Elements 3.0 get our attention. Especially, as it took only a few hours to understand the Lit concept. Clean and easy, with the feel of natural JavaScript instead of fancy languages and tooling. Before we made a final decision, we wanted to learn it deeply, so we simply decided to rewrite Lit Elements 3.0 from TypeScript into vanilla JavaScript.

It took us 1 single day to refactor.

The full source code can be found at our GitHub pages. It is our toy project we do not use internally, but it is fully operational. Actually, Lit Elements 3.0 can be easily replaced with our vanilla-lit, and Green Screens Web Component 2.0 will work out of the box without any additional changes.

We were impressed by simplicity, flexibility and the elegant approach to the WebComponent development. The only currently unsupported part is "decorators" as they are not supported by the browser just yet. When become available, server side source compilation and TypeScript will not be required at all (required only if you plan to use @decorators). It showed us where this is heading in the near future, which was additional confirmation of our choice.

After seeing official videos, and which companies are using Lit, was additional reassurance about our choice. So, we decided to accept Lit as a building block for next generation of Green Screens WebComponents which will be the basis for web based 5250 terminal modernization also.

Project bootstrap-lit

This is a complete rewrite of Green Screens WebComponents into Lit Elements. The code size and complexity was significantly reduced. In the same time, we got WebComponent reactivity support and fast UI rendering for highly interactive elements in a generic form.

How migration was an easy task, lays in a fact that we needed only 6 weeks to migrate something that took us 18 months to develop.

Here is a list of changes:

28 base modules (no migration needed)
63 components (complete rewrite)
30 components (new)
12 property definitions (new)
17 controllers (new)
7 data helpers (new)
3 directive (new)
8 components (removed)

That is about 160 modules, out of which 65 new modules and 62 completely rewritten. Production ready build and gziped script is only 60KB.  Accompanying resources: Lit engine 10KB, Bootstrap 30KB and custom theme 4KB.

Project Facelift

Facelift Engine is Green Screens Web 5250 terminal UI modernization engine we are currently working on. It will be based on this new Green Screens WebComponents 2.0.

One of the biggest benefits of Green Web Components 2.0 is support for self rendering from JSON data and extremely easy UI updating based on native "Object.assign" function. Additionally, with support for bindable actions between components will make the whole process quite easy.

Our goal is that our end customers can easily use, develop, extend or create new 5250 UI WebComponents without requiring complicated installations, complex tooling setup etc.

We want that our customers can use simple pure vanilla JavaScript but not to be in a technology lock-in for a specific vendor if they want to use a different approach. We simply want this to be as painless as possible to all parties involved.

The best part is that, once when ready, The project Facelift will be open-sourced.  Until then, stay tuned and keep watching our online channels for updates.

Introduction

If your answer is "yes", then you know how complicated it is to use JNI (Java Native Interface) mechanism.

Luckily, there is a 3rd party open source project JNA (Java Native Access) which significantly simplifies the process.

However, it is not without limitations. This library requires deploying specially build native libraries aka "wrappers" for JNI and are integral part of the JNA itself. What might happen with JNA is that native wrappers might not be available for your OS.

For example, there is no support for IBM i.

Actually, all that is history now with arrival of Java 21 which introduces Panama project - JEP 454: Foreign Function & Memory API also called FFM API.

We estimate that after IBM introduce Java 21 for IBM i OS, there will be an explosion of projects being able to link to native IBM i libraries creating very interesting future solutions for that platform.

Java FFM API basics

NOTE: For better understanding the concept, we will use some terminology not common to Java, such as "pointers" and "exposed memory location". Even, the reality is a little bit different, we assume this terminology will be easier to grasp the "Java concept".

Java FFM API is a native Java JVM implementation of a mechanism used for code constructs to link Java virtual code with external library functions. It also relies on Java reflection replacement based on MethodHandle (also known as Invoke Dynamic).

More about this can be found here and JEP 416: Reimplement Core Reflection with Method Handles.

As Java does not have a "pointer" concept, while OS native libraries are all about pointers, MethodHandle and MemorySegment classes are "kind of" representation of pointers. Where MethodHandle is internal to the Java itself, a replacement for Reflection API and MemorySegment are for foreign functions in external native libraries.

When using FFM API, all data that flows between Java are either primitive types such as byte, char, int, long, float, double, boolean, or "pointer" types represented as
MemorySegment class. So, any other Java Class type including callbacks in form of a MethodHandle (kind of Java "pointer") must be converted into MemorySegment (kind of native lib pointer - out of Java).

While MethodHandle is a replacement for Java Reflection API which brings better performance, and can be considered Java internal "pointer" to methods to be called, when used as a callback to foreign functions, they also must be converted into MemorySegment - let's call them "remote pointers".

For example, imagine that we have a C/C++ external library "compression.dll" with a function...

Processing = function(int percentage)
*byte[] compress(int level, *byte[] data, *Processing callback)

The question is how to call this from Java with FFM API ? Here is how we would create a Java method...

interface ForeignCompression {
 
 MemorySegment compress(int level, MemorySegment data, MemorySegment callback)  
 
}

As you can see, primitive type can be passed directly to the external library. Other parameters, as they are pointers in C/C++ library, we can pass only as MemorySegment.

In this particular case, as "data" is a pointer to a byte array, we need to pass "exposed" memory location where data to be compressed is located. In other hand, to pass a callback, we need to define a MemorySegment where Java internal MethodHandle resides, so we can pass it to the external library.

Here we have three Java concepts used:

1. Use of FFM API to load data from "Java side" into "exposed" memory. Data will be used as arguments for remote function.
2. Use Java MethodHandle, created from Java Method, and then converted into a "pointer" - MemorySegment, so we can pass it to remote function.
3. Use of FFM API to get remote function "pointer", then convert "pointer" into Java method signature - MethodHandle - used to call remote functions from Java.

Lets' see how to convert data to a "pointer"

import import java.lang.foreign.Arena;
import java.lang.foreign.MemorySegment;

byte[] data = {... SOME BYTES TO COMPRESS ...};
Arena arena = Arena.ofAuto();
MemorySegment data_pointer = arena.allocateArray(OfByte.JAVA_BYTE, data);

Before we create a callback "pointer", we need to create a MethodHandle for the Java method used as a callback. Let's say we have a class with a method of a signature equal to the C/C++ callback function.

class Handler {
  public static void callback(int percentage) {
    System.out.printline(String.format("Processed: %s%", percentage));  
  }
}

So, we need to create a MethodHandle first...

import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodHandles.Lookup;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

  // Java Method class representing reflected class method
  Method method  = Stream.of(Handler.class.getMethods())
                  .filter(m-> "callback".equal(m.getname()))
                  .findFirst().get();
  
  // convert Method to MethodHandle
  MethodHandle handle = MethodHandles.lookup().unreflect(method)

In the next step, we need to convert the method handle to a "pointer"...

import java.lang.foreign.FunctionDescriptor;
import java.lang.foreign.Linker;

// we must describe callback method signature
FunctionDescriptor descriptor = FunctionDescriptor.ofVoid(ValueLayout.JAVA_INT);

// then, we create a pointer for a MethodHandle, 
MemorySegment callback_pointer = Linker.nativeLinker()
                                 .upcallStub(handle, descriptor, arena);

Now, we have both pointers, data_pointer and callback_pointer, so we are ready to make a call to an external function.

import java.lang.foreign.Arena;
import java.lang.foreign.SymbolLookup;

// initialize external library
Arena arena = Arena.ofShared();
SymbolLookup library =  SymbolLookup.libraryLookup("compression.dll", arena);

// find foreign funcion and return "pointer" within loaded library
MemorySegment remote_function_pointer = library.find("compress").orElseThrow();

// create Java signature for remote function
// return type byte[]*, 1st arg Java int, 2nd arg byte[]*, 3rd arg callback 
FunctionDescriptor descriptor = FunctionDescriptor.of(ValueLayout.ADDRESS, ValueLayout.JAVA_INT, ValueLayout.ADDRESS, ValueLayout.ADDRESS);

// createa Java method signature from pointer
MethodHandle remote_function = Linker.nativeLinker()
                         .downcallHandle(remote_function_pointer, descriptor);

Ufff... looks complicated ? Not so much when you get the idea. But we won't stop here. As general principle is extremely simple, the whole process can be automated without all that manual work.

Actually, we can use "java.lang.reflect.Proxy" to wrap an "interceptor" around Java Interface that will do all the work. So, all programmer has to do is to create a proper interface methods for external library and simply to register that interface into a Proxy handler.

We did that already, and full source code can be found on our GitHub here...

It is generic enough to use any standard external library. The concept is the same as mentioned JNA library, but much smaller and without any native build dependencies.

Provided demo code showing how to use our JNA replacement is for widely used (and unfortunately abandoned) project WKHTMLTOX which can render web content into a PDF or multiple image formats.

What is not supported are complex structures, for which you will have to create your own MemorySegment structures. But, hey, this is just the first version. For one of the next releases, we might actually add that support also, so stay tuned to our blog and online channels.

And, happy coding... !!!

This update is also significant for future versions coming next year. We made several internal changes (preparation) for arrival of Java 21. Why this is so important?! Java 21 brings Virtual Threads, which brings significant performance and memory improvements, especially for Java server environments. Exact release depends on Java server runtime environments adoptions. Once implemented, already high performant Green Screens Server will be even better with even less memory usage.

Java EE 10

Major changes are made by switching from "javax" namespace to "jakarta". From this update and onward, only Java EE 10 certified servers will be supported. The previous version supported servlet-only containers, which is not the case anymore. This change required complete library and package namespace replacement and hundreds of hours of testing, however it is the first step stone to open the path for new Java features incoming in new Java LTS releases which will allow even better and faster Green Screens Terminal for IBM i.

Java Runtime

For MS Windows environments, Java Runtime is updated to the latest security patch Eclipse Temurin-17.0.8+7. Version 6 of Green Screens Terminal for IBM i is still Java 11 fully compatible and can run on any hardware supporting Java 11 including IBM i. Our commitment is to always support 2 LTS releases behind the current one. However, we are slowly introducing Java 17 and soon a new Java 21 LTS.

Server certificates improvements

Many improvements were made to the certificate generation and overall certificate security. We added support for OCSP/CRL certificate verification at the Green Screens Sever side, CA authority URL support for certificate auto download; better linking between signing-certificates and end-certificates; intermediate certificate support, and many more small improvements.

Security improvements

In previous versions, we used RSA for encryption key exchange used to encrypt data flows. Introducing GSv6, we started to replace RSA with ECDH/ECDSA. In this release, we fully replaced RSA with new more modern, more secure and more performant ECDH/ECDSA. Also, we developed our own WebAssembly based Crypto API as a fallback mechanism for browsers native API. Full source code used as a base for Web Crypto API polyfill can be found at our Github Repo.

OCSP Reponder service

OCSP is part of Digital certificate specification for certificate online verification. Green Screens Server now fully supports OCSP protocol for certificate validation.

CRL service

CRL (Certificate Revocation Lists) is a standard older than OCSP, but we added full support for it. CRLs are automatically updated when intermediate, server or client certificates are regenerated.

Software License updates

We improved product Software license to make it more clear about warranties, liability, 3rd party modules and many more.

Product reinstallation improvement

We improved reinstallation procedure on MS Windows platform to keep some server settings, allowing faster server startups after reinstall.

Reintroduced new modern key bar

New modern key bar based on Green Screens WebComponents is reintroduced into the Web 5250 Terminal to better support tablet devices.

Inter context messaging channel

Messaging channel for inter context communication is part of a new browser API allowing to easily exchange structural JSON messaged between Green Screens Terminal and other browser tabs or IFRAMES. This will simplify integration and automation with other web products such as CRM's and other portal system, future modernization UI engine for GSv6 and other 3rd party tools.

WebSocket channel stability

In some proxies or load balancers, WebSocket channels (used for full-duplex 5250 web terminal) might stay stalled also keeping licensing locked due to the networking, security or improper configurations issues, or even possible bugs in such products. We improved signaling and network issues detection mechanism to better recognize such situations and to prevent stalled channels or locked workstation licenses.

WebComponents updates

All Web UI interfaces are updated with the latest Green Screens WebComponents for Bootstrap. Fixing small issues, and adding better support for touch devices. Parts of WebComponents are significantly rewritten while keeping backward compatibility with previous version. The biggest change relates to the data engine that connects various components such as GSTable/GSStore and others. Another notable feature added is JSON object node path for input fields to be able to use structural multilevel JSON data as data input.

Quark Engine v6.0.0

Our Quark Engine is an open source Java to Web RPC framework for fast server-to-web API development with simplicity and security as main focus. Versions 6 and 5 are significantly improved, bringing even better performance. Internal workings are switched from Reflection API to InvokeVirtual improving performance by factor of ~5. Intern API descriptors are optimized, and anonymized. While doing a call, all data is in new GS binary format without explicit virtualized class and method names sent.  Security is fully upgraded to ECDH and AES derived key, with performance of about 2million transactions / second on a single core.  No matter if TLS is used or not, data remains encrypted, protecting from MITM attacks. Because of excellent, superb encryption performance, and almost nonexistent influence to overall system performance, such double-layered protection can satisfy even the most demanding tasks.

Mobile app updates

Android version of Green Screens Terminal for IBM i  is updated to support latest Android devices, including future Android 14. A few small non-critical bugs are fixed, and full support for Green Screens Server 6 is finally added.

For last +4 years, Green Screens Terminal for Android is based on a multimodule packaging allowing segmented installation only from Google Play platform. This technology brings faster, and lighter updates tailored for targeted device.

However, there were cases of 3rd party non-certified sideload installations causing errors and crashes by misuse. Please, install our Android app Green Screens Terminal for IBM i only from Google Play.

In the latest release, we introduced a new Google API flag which should prevent such installations of Green Screens Terminal for Android into virtual environments. This is still experimental Google technology and will be most likely ignored by older Android versions. However, you might expect that manually installed Android Greens Screen Terminal for IBM i might not work on more modern versions of Android devices.