Thomas Lamprecht [Thu, 25 Jul 2024 15:25:02 +0000 (17:25 +0200)]
termproxy: avoid gluing words together in CLI option names
Separate auth-port and auth-socket with a minus to make them easier to
read. Fallback to the old style for `authport` which is pre-existing
and used by, e.g. PBS. As the second option, now named `auth-socket`,
got only introduced very recently and was not shipped in any package,
we can ignore backwards compat for it.
Update and slightly rework the usage output too.
Note that even though this is an internal tool the cost doing so is
small and it can only help, e.g. on using this manually and/or during
debugging.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
While commit d8e9c1a ("termproxy: fix the command line help text")
corrected the usage text to match the behavior and was a good stop-gap
it simply is to easy to make this work as most CLI tools do and most
user expect.
Switch to parsing all options first and only then get the free-form
listen-port(-or-fd) argument.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Dominik Csapak [Wed, 25 Oct 2023 09:08:59 +0000 (11:08 +0200)]
xtermjs: try to detect hardware support for webgl2
With the new WebGL renderer, chrome/chromium has buggy software
support for emulating this (see [0]), so we have to detect that
manually and prevent loading the add-on. This fixes the issue that on
chrome without HW-support, it would not always render every character.
Firefox does not have support for a software renderer and the
loading/detection throws an exception, falling back to the default
renderer.
Thomas Lamprecht [Fri, 20 Oct 2023 04:08:47 +0000 (06:08 +0200)]
termproxy: switch from clap to pico-args for CLI argument handling
Not that clap is bad or anything the like, but for one it's rather
over engineered, and it has to be as long as it wants to provide a
dozen wildly different way to do things.
And the second, more important reason: it's still undergoing a lot of
churn every year or so. Each upgrade to a major version needs like
two hours of understanding what's going on, at least if one wants to
Do It Right™.
Termproxy, otoh., is a small and internal tool that doesn't need an
overly fancy CLI targetting humans, as it will be only called by the
API anyway.
So, to reduce the time required to constantly catch up, and remove
some complexity, switch over to pico-args. That one provides a few
small interfaces for the most common things, does it right and uses
OsString as main type and has exactly zero dependencies on its own.
In other words, perfect for such internal tools (and possibly also
most others).
Copy over the help output from the clap based tool for convenience,
pico-args really doesn't bother with such things, and introduce an
Options struct to have a, well, more structured way of handling CLI
arguments/options.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Tue, 17 Oct 2023 12:57:03 +0000 (14:57 +0200)]
termproxy: fix port/fd range check
The valid upper range was swapped, while at it switch from i32::Max to
RawFd::Max, while currently RawFd is a type alias to i32, it's easier
to grasp what's going on and might even change in the future.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Tue, 17 Oct 2023 08:02:17 +0000 (10:02 +0200)]
termproxy: install to usr/libexec directory
this is not a standard CLI tool that should be exposed to all users,
but an internal binary, so move it to /usr/libexec/proxmox.
That location was chosen over a multiarch path
/usr/lib/<triplet>/proxmox to make resolving the path easier for the
caller, as the standard ways to get the multiarch triplet (e.g.,
"x86_64-linux-gnu") involve CC and are not easily/cheaply available in
perl – we would basically create an architecture specific package that
provides a path resolution with multiarch triplet resolved at "build"
time of that module; as we probably do not ever install termproxy
multiple times targeting different arch's on the same system, this is
just to much complexity.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
split upstream and our native into different source packages
We should have never added a upstream repackage and some custom tools
in the same source package, let alone binary package. Finally resolve
that tech debt and do a split.
This commit does a bit more than I'd like at once, but it's really not
trivial to make a clean split while keeping all sanely buildable in
multiple commits.
What roughly happens is:
- two complete separate source packages
- one for xterm.js, we keep this purely to the xterm.js and our
local additions and modifications that are relevant directly to
xterm.js itself
- one for termproxy, where only the rust-based tool is shipped.
This also reduces churn, as the termproxy doesn't sees lots of
updates, so no point in building it on every xterm.js update.
- drop debcargo, which while great for library source code packages
for build dependencies, is just a PITA for binary packages
shipping actual compiled rust code, it adds almost nothing there
but provides lots of special handling to get the correct result.
- rename `termproxy` to `proxmox-termproxy` but keep a backward
compat link for now, termproxy is way to general a name.
Maybe we should also move this away from /bin in general, into the
/lib/<arch-qualifier>/proxmox/ directory like we do for
proxmox-backup.
- clean ups all over the place
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
since xterm.js 5.0.0, the previous default canvas renderer is not
built-in anymore and only recommended as a fallback. The new recommended
renderer is this webgl one, so use it with a fallback to the default
built-in dom renderer (which is slower, but still functional).
to use it we have to load the addon after `terminal.open` so move the
`open` call to before the addon loading. While we're touching that line,
remove the superfluous second 'true' parameter that did not do anything.
Thomas Lamprecht [Tue, 23 May 2023 11:44:33 +0000 (13:44 +0200)]
buildsys: avoid debcargo and dh-cargo on build
debcargo package requires all dependencies to be installed, even if
we basically just use it for d/control generation, which makes it a
bad choice for build dir generation here (i.e., with a native
package) as the DSC should be buildable without requiring all build
dependencies.
Add a target to update d/control manually (not much tested) and move
the build away from dh-cargo
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Thomas Lamprecht [Wed, 26 Jan 2022 17:56:16 +0000 (18:56 +0100)]
use anyhow for result/error
it's in out dependency chain anyway through proxmox-sys or -time and
it makes life a bit easier. FWIW, I got slightly pressured into this
by the future switch from curl to ureq, as the latter brings their
own Error type.
instead of just poll. the manual tracking of elapsed across loop
iterations is to avoid underflows - can be replaced with a
saturating_sub call once that becomes stable.
Dominik Csapak [Mon, 1 Feb 2021 07:55:18 +0000 (08:55 +0100)]
termproxy: rewrite read_ticket_line
since we cannot accept a std TcpStream from a mio::net::TcpListener
anymore, we cannot use set_read_timeout here
instead implement the readloop as a mio poll loop similar
to listen_and_accept, otherwise termproxy will busy loop and
consume 100% of a single core during authentication
Dominik Csapak [Mon, 1 Feb 2021 07:55:17 +0000 (08:55 +0100)]
update to mio 0.7
notable changes:
* all polls in mio are now edge triggered, so no need for PollOpt, etc.
* functionality of UnixReady is now in the mio::Event directly
(UnixReady::is_hup -> event.is_read_closed())
* TcpListener::from_std() is not a result anymore
* EventedFd -> SourceFd
* mio::net::TcpListener cannot accept_std anymore, so convert
everywhere to mio::net::TcpStream, drop set_read_timeout
(this warrants another patch)
by splitting the msg and code, and only showing the existing parts
also actually read the msg/code from the event by giving it from
tryReconnect to stopTerminal
projects / pve-xtermjs.git / log