WebTerminal Over Telnet Is Possible. Should It Born? (v5) Open Discussion.

This post is originally posted on GitHub.

This discussion is open to anyone who use or know about WebTerminal project. It is a result of a long story of the project development, testing and maintaining.

While WebTerminal greatly improves user experience by enhancing standard terminal with additional features, there are numerous issues (#77#92#81#87 and others) showing that it performs not as expected in some cases, and does not support some very basic things (like $ZA/$ZB variables). The reason is in fact that WebTerminal project tries to reimplement Caché TERM behavior over Caché ObjectScript capabilities. And it turns out that it is not always possible (see, for example, #77 or #92). The "built-in" Caché TERM features like programmer mode or debugging are very hard or even impossible to re-implement either.

The one possible solution I am thinking of more and more, is to build WebTerminal over Caché TERM, keeping all WebTerminal's goodies (and, of course, the web part) in place. As one capable approach I see telnet (special thanks to Stephen, who opened #100). I already made some tests and I can confirm that it is possible to transfer WebTerminal engine onto telnet without any changes from the user side.

From the user point of view, nothing will change, except of WebTerminal will start to support all terminal's basic stuff like programmer mode, debugging and correctly process F1-F12 keys as well as others.

From the technical point of view, I see the next workflow: terminal core class will open telnet session to local machine instead of handing all the commands using xecute. In this case WebTerminal code will start work as a middleware between "base" terminal session and a web user interface. All the current WebTerminal features are capable to work with this scenario.

I see the next major pros in WebTerminal "over" telnet:

  • WebTerminal will support everything that terminal session over telnet do:
    • programmer mode;
    • debugging;
    • any programs written for Caché TERM and for the very old systems;
    • etc.
  • WebTerminal will support connecting to Caché instances older than 2014.* via telnet from the web interface.
    • I think it will come as a new WebTerminal's feature, special command /telnet host@user:pass, for example.

But there is a one valuable cons I believe,

  • Telnet service must be turned on.

I am always open to any suggestions and discussions. You can improve the project by sharing your thoughts here! Maybe there is a better "interface" to a Caché TERM rather than telnet, maybe you believe that re-implementing Caché TERM on Caché ObjectScript is not such a hard idea... Please, let us know!

Thank you.

  • + 2
  • 293
  • 23
  • 3

Answers

I still don't get the benefit of exposing terminal functionality through a webpage. Maybe I'm getting old, but all I can see are security nightmares with this ;)
What can one do with the web terminal that one can't do with a ssh session to the server?

At least you can have the benefits of Caché Web terminal itself: 

Code completion (methods, classes, properties, etc), code highlighting, nice SQL shell, endless history, etc.

Once you configure SSL (HTTPS) and choose a strong passwords for Caché users there will be no security concerns. There are already some web applications in Caché, WebTerminal by its means is not different from them. It born to introduce some features people would like to use like Evgeny mentioned.

Nikita is an employee of InterSystems?
If so, then it seems to me that it would be easier and more effective if upgrade a standard Caché Terminal, turning to the achievements of Nikita.

Thanks Nikita Savchenko for the mention. Excellent detail in the article, I really appreciate putting this article out to the community for comments. Interesting note about libssh2.dll/.so. I would love to see an early proof-of-concept of libssh2 working with WebTerminal. I would also like the option to use Telnet or SSH rather than being forced into using one or the other. 

Thank you Stephen for your feedback. I will try my best in finding the way to make it all work together.

Comments

Evgeny already shared a thought that telnet should not be opened on any server. I agree. But what is the main difference of opened local port 23 and management portal, available through the web? Both of this two ask for login and password. What is the security risk here?

Caché telnet service exists only on Windows. On other platforms would you rely on OS-level telnet service? Nowadays on UNIX/Linux it's uncommon to find telnet, and ssh is typical instead.

If there's a concern about passwords travelling in plaintext, remember Caché telnet service can be configured to accept telnet over SSL/TLS.

Windows-only? Hmm. So I am throwing the idea about telnet out. Thanks!

Maybe there are other ways to enter the terminal "programmatically" for all platforms? What else I have read from the internet is csession thing. Maybe we can run this terminal session from COS and somehow take control over its I/O... What do you think?

I think it would be a great thing. 

So in case you have open ssh port, you would be able to work in a handy, good looking, fool functional terminal with class code completion, code highlighting and SQL shell.

Definitely, makes sense to me. 

Via SSH (putty, etc), am I right that you need to call csession <instance> to enter the Caché terminal? If so, there is no talk about SSH at all. I think there should be a talk about of how to run csession programmatically from Caché ObjectScript. But for remote sessions, without WebTerminal's code installed on the system, it makes sense.

Via SSH (putty, etc), am I right that you need to call csession <instance> to enter the Caché terminal? If so, there is no talk about SSH all. 

Caché has got embedded libssh2.dll/.so ages ago. Why not implement internal SSH server which can be a reasonable replacement for outdated (and Windows only) telnet one? It seems that some other projects (besides Web terminal) would take advantage from it.

  

Sounds good. I think I need to do a little research on Caché ssh (internal ssh?) to imagine how this can work. Thank you.

Hi there

I just saw the web terminal running on ensemble 2016 , and i'm trying to install it on Cache 2013.1 server.
What should i do in order to install WebTerminal-2.0.0-beta.7/beta.8 on a Cache 2013.1 server?
At what namespace should i import the xml?
Should i manualy set a web application? if so - what should i define?
 

Thanks, Yuval

Install latest version (we're currently on v4) from here. Installation instructions are there too (just download and import, that's all).

The documentation say that ver 3 and 4 will run on Cache 2014.1+

And i need to run it on Cache 2013.1.

So, Will v4 work on Cache 2013.1?

So, returning to this...

What should i do in order to install WebTerminal-2.0.0-beta.7/beta.8 on a Cache 2013.1 server?
At what namespace should i import the xml?
Should i manualy set a web application? if so - what should i define?

Hello Yuval!

To install WebTerminal 2.0.0-beta.8 on Caché 2013.1,

1. Go to WebTerminal Downloads and download the version 2.0.0-beta.8, which is the XML file. This page also has some instructions about how to set it up.

2. Using Studio or whatever you like, import this XML file into the %SYS namespace and compile all imported classes / CSP pages. If you have the "access error" while importing classes, then you need to temporarily enable write access to CACHELIB database, see here how.

3. Open <host>:<port>/csp/sys/webterminal/index.CSP page in the browser.

The dark part of using v2 is that this version of WebTerminal is very old and have a lot of things that were improved in 2 major releases v3 and v4. Furthermore, despite of it was tested on 2013.1 (some particular version) it may not work there now, as it seems like some changes in WebSockets appeared in InterSystems WebSockets engine, and probably 2013.1 may have a minor release adding them. But anyway, you can try.

Versions 3 and 4 of WebTerminal is not compatible with 2013.1 for the only reason — they use %CSP.REST classes. You can try to port WebTerminal resources onto CSP, but this may not be trivial.

Let me know if this helps! I will add this instructions to the WebTerminal downloads page. Thanks!

Hi @Nikita Savchenko

Thanks for a full install info.

I'm using Cache for Windows (x86-64) 2013.1.1 (Build 501_1_13062) Sun Aug 11 2013 23:20:33 EDT

Step 1 and 2 are going fine, i'm able to downlad ver 2 beta8, and i'm able to import and compile it on the %SYS namespace.

At step 3 i'm getting the login page and after i authenticate i get the Cache WEB Terminal in the title but with an empty body.

At step 3 i used IE 11, using the debugger it throw the next error from terminal.js:

"{if("undefined"==typeof JSON)throw new Error("Browser does not support html5 local storage. Please, update your browser")}"

So i tried step 3 on chrome  and now it's better but i get the following error (It's displayed in the body):

"WebSocket connection error (ws://servername/%25WebTerminal.Engine.cls). Trying to connect again in 10 seconds...
WebSocket connection closed. Code 1006, reson: ." which came from terminal.js

And now finally step 3 is working - using chrome and using the port 57772 (instead of 80)  i'm getting the prompt to %SYS namespace.

 

Thank you very much.

You are welcome! Glad to hear that it works. I hope that functionality WebTerminal v2 has will be enough!