authentic-theme
authentic-theme copied to clipboard
webmin
Theme: Interactive Terminal
Hi,
Firstly great work on this theme! Secondly apologies if this has already been answered somewhere (I looked but couldn't find anything).
We have been using Shellinabox to provide a web based shell, but now with the implementation of your Authentic theme to Webmin, we have a shell there too, so am considering dropping Shellinabox altogether.
However, I notice that the Webmin shell is not picking up the default colorization that I currently get via both an SSH session, or via Shellinabox (see screens below). Also the text is quite small and not that easy on the eye (at least mine anyway).
Is there any way I can adjust that. Primarily I would like to enable colorization of the shell, but it would also be nice to increase the font size a little.
SSH session
Shellinabox
Webmin Authentic shell
FWIW it looks like the TERM variable isn't being set. I tried manually setting it within a session, but even if I export it, it doesn't seem to stick?!?
@gnadelwartz ok thanks for that. I have zero perl experience, but I did have a dig in the shell user interface index.cgi file but couldn't really see what is going on there...
Regardless, I'd still imagine that it must be possible to set/update environment variables?! Even if the renderer didn't know what to do with them (so we'd likely get a heap of escape codes instead of colors).
This isn't a showstopper for me, but it would be nice if I could adjust the font and would be super great if it could have colorized output!
Ok, now I'm digging a bit deeper, I'm not sure whether this "pseudo-terminal" shell will be good enough... As it doesn't support interactive commands, I'm looking at other ways to achieve my ends.
I see that there is a shellinabox module (noted at the bottom of this doc page and here is it's directory in the source). I wonder if there is a way that I could leverage that to provide the Authentic theme shell?
I really like everything about the Webmin authentic theme shell, expect the fact that it's not a proper shell. I understand that Webmin is cross platform, but I would imagine that it's most commonly used with Linux (users used to a GUI, managing their Linux servers) so having a "proper" shell would be a huge advantage IMO...
Oh, just noticed that the shellinabox module appears to be abandoned (last commit 2012!). There is an ajaxterm module too, but that is also more-or-less abandoned (and the upstream project definitely appears abandoned)...
That sucks! I may see if I can update the shellinabox one easily (but I doubt it). Otherwise, I think I might just stick with Shellinabox for now so as to have a proper shell...
I had a quick look at the code and unfortunately, I don't see what I would need to do to import an updated version of Shellinabox into Webmin, but it appears that it should be possible. And if that can be done then, I'm pretty sure that we could then replace the current pseudo-shell accessible within Authentic theme with Shellinabox.
But unfortunately, with my lack of perl knowledge and a big todo list, I'm going to need to put this aside for now...
@swelljoe @rostovtsev I didn't find the issue, where we discussed replacing current terminal with a modern and real interactive solution, but we should think about a new try after realease.
Jeremy, hi.
You can easily increase the font of the whole Terminal just by adding to theme's extensions, this CSS code:
.-shell-port- {
zoom: 1.2
}
Note: After saving changes, for now, you would need to refresh the browser's page to get the effect.
What's for interactive shell. We're all looking forward to have it.
I will think more on how it could be done. Fedora Cockpit has it for instance. Shellinabox has unofficial fork. The problem is to make it work on all Linux distros. We could make a build and create AppImage to make sure that it just runs without hassle. After all, I would need to make a port to the UI.
I will mark this issue as an enhancement and will look forward for enrolling it. It will be for sure after the new mail is released, into more or the less stable condition, which estimated to happen around summer 2018.
I absolutely agree, that having proper interactive console is a huge win. I'm making it a second priority after the mail.
this would be ny initail suggestion also, phyton and javascript should be portable
nice, but this adds a new dependency :-/ nodejs may not installed everywhere... at least on embedded systems ...
May be we have to keep actual implementation as fallback.
We could try to make AppImage, just export all of the dependencies into single, self-contenting package.
We could surely keep current implementation as a fall-back.
Yeah, I'd rather not depend on node.js in Webmin. Can the server-side part of this be re-implemented in Perl?
Reimplemented? Technically but not practically. It's very time consuming. Besides, there is implementation in Perl (Shellinabox) already.
I haven't looked very closely yet to make a judgement.
Why we just can't ship AppImage - single, executive file that would contain all dependencies in one. I'm not saying it's the best way, but it looks for now as the fastest solution.
I would also prefer a perl or phyton inplementation (as we currently has).
Is you appimage sulotion is portable or does it depend on OS and CPU architecture?
Requires only an entire new runtime, eh? ;-)
Requiring Node is too much, I think, as it is not commonly installed and is very, very, large. But, then again, the alternatives aren't great either. Python can be expected to be available everywhere, already, but I dunno if there's a WebSockets based back end available that'd work with one of these modern JS terminal implementations. There's one in Go called gotty, but if we shipped a single binary it'd only work on Linux systems (the server-side, obviously the client-side is JS and would work anywhere).
I dunno. We pretty much have to spin up a new back-end webserver, no matter what, as miniserv.pl doesn't support websockets, yet. Python is more readily available than Node (for now), but I don't know of good options for that. I haven't looked at Shell In a Box, I think it predates websockets, though, so I doubt it's the modern approach we'd want.
There is a WebSockets implementation for Perl in Mojo (as well as several compiled ones, but I think Mojo is good as it has fewer dependencies than most), but someone would need to implement the shell backend (I don't know what that entails...we'd basically be porting the backend in Wetty or Gotty to Perl). I'll have a look at those backends and see how much code we're talking about...I think the heavy lifting is on the front, so maybe it wouldn't be so awful to port it to Perl.
As noted above Gate One at least state:
- Gate One works with Python 2.6+, Python 3, and even pypy!
- The daemon that acts as the web server for Gate One is small and light enough to be included in embedded devices.
https://github.com/liftoff/GateOne/
Maybe this: https://github.com/Prajithp/mojo-terminal
wow. seems really small (execpt of require mjojo)
BTW: nice to see all of you active in the same time frame :-)
Great work guys, pumped about all the activity... :smile:
Gate One looks good.
I agree depending on Nodejs is not desirable!
Out of curiosity, why is Shellinabox out of contention? IMO it works quite well. Although it is a little flaky on mobile devices...
mojo-terminal looks very good, if it is in a functional state. It's very light, only has a few dependencies (still checking to see if they are pure-Perl or if there's some compiled bits), and it uses the same frontend as all of the others we're talking about (xterm.js), so it'd be something we could sort of pin to whatever version is current and just perform minor updates based on what upstream does. I think this might be a winner.
A couple of XS dependencies (IO::Tty, though we already use IO::Pty, which is a similar size/complexity dependency, so this is probably not a dealbreaker). I'm looking at the dependencies now to see which ones are already in CentOS/Debian repos, and figuring out if we'd need to package any extra modules. Mojo is not in the CentOS core repositories, but I think it is in EPEL. And, it's pure-Perl and only a couple thousand lines of code, so we could even bundle the damned thing as part of Webmin.
Mojolicious is really an amazing bit of code. It does so much with so little code. I'm in awe of it every time I look at stuff implemented with it.
Out of curiosity, why is Shellinabox out of contention? IMO it works quite well. Although it is a little flaky on mobile devices..
Not out of scope but if we implement a new solution it has to fit some requirements:
modern(e.g. websockets) , futureproof, portable (perl, phyton)...
BTW: cpan Mojolicious works as a charm on my embedded NAS
I don't know that Shellinabox is out of contention...I just know it's really quite old, and I doubt it is a modern implementation. With Websockets, it is now possible to have a very efficient communication between the browser and the server; but it's a relatively recent thing. I think Shellinabox pre-dates it. If it does, the implementation would be poll-based, and also very large compared to these WebSockets-based implementations. The smaller it is the better, because we can probably maintain a few hundred lines of code if it goes abandoned in the future, but we can't realistically maintain or understand or audit thousands of lines of code (and security is a big issue with anything we ship in Webmin).
So...if we can find an implementation of this that is:
- Small. A few hundred lines of code, hopefully.
- Doesn't require a new runtime: Limited to Perl or Python, probably.
- Works with a well-maintained frontend. I think this is just xterm.js, as I don't know of any other frontends that are widely used.
- Has minimal dependencies, preferably no or few binary packages. I suspect any Perl thing will require at least an XS module or two for the IO, but that's probably OK.
Sounds great. Thanks for the explanation, that makes tons of sense. And yes, Shellinabox is old. It died but has been (somewhat) resurrected, but AFAIK no major changes to the codebase (just some updates and bugfixes).
It looks like you guys are all over it.
In the meantime, if I come across anything that fits the bill, I will certainly let you know.
So, for dependencies:
- CentOS core has perl-IO-Tty
- We already use perl-IO-Pty (though I dunno where we get it from, as it's not in core, maybe it's in EPEL or we've got a build of it somewhere in our repos).
- Mojo isn't in either core or EPEL, but the bits we need are pure-Perl, as far as I know, and only a couple thousand lines of code, so we could bundle the damned thing with Webmin (which is several hundred thousand lines of code, so not a big deal).
I think that's realistic. So, I'll need to try it out to make sure it's actually in a usable state...sometimes projects get kinda half finished and the maintainer gets bored and moves on before it's solid.
There will need to be code to spin up the sockets server on demand. I don't know how authentication is handled in the AJAXTerm module (which I think is the closest comparable Webmin module), maybe you actually have to login again...I don't remember. But, we'll have to make sure we get that bit right. Ideally, it wouldn't require logging in again, so I guess we'd need to set a JSON Web Token to authenticate the current session, maybe.
@qooob what are you doing about authentication when you use wetty in this context? Is it requiring a new login or are you setting a token?
Let me know if anything needs testing and/or you want any further feedback.
Mojo isn't in either core or EPEL, but the bits we need are pure-Perl
as long CPAN is working it can simply installed
perl-IO-Tty ... perl-IO-Pty
I see also no problem with this, may be we can unify code to one of them ...
Great work guys, pumped about all the activity...
as you can imagine, we are not really statisfied by current terminal :-)
BTW: what about a picture of a tasmanian devil ;-)
I don't like to rely on CPAN for Perl modules in anything we ship in Webmin core, or in Virtualmin. Jamie is more relaxed about this than I am, but if we can't include it as a dependency in the Webmin package, I wouldn't want to make it part of core Webmin (this means it needs to be available in the core OS repos, which IO::Tty is, and I see it includes IO-Pty).
So, Mojo is the only unresolved dep, I think. One other XS module needed is Encode, but it's also in the core CentOS repos (and I just assume that anything CentOS has, Debian/Ubuntu will have because they have a lot more Perl packages). So...the new terminal module probably just needs to embed Mojo in a directory and add it to the library path when it spins up the server.
We may still want to make this a non-core module that gets installed as part of Virtualmin and Cloudmin. If there are other XS (binary) dependencies hiding in here that I haven't found yet, and they aren't available in the core OS repos so we can depend on them in the Webmin package, I'd want to see this as an external module. But, it looks like that won't be necessary...we can probably ship all the non-core bits we need in the Webmin package.
And, yeah, the current popup terminal in Authentic is awesome, but it's not really a terminal...it's a command shell that looks really cool. It's never been intended to replace an ssh session, but the tech exists to replace ssh sessions (or put them on the web), we just don't have it in Webmin yet.