IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
the old location has been deprecated for a while, and rustc 1.78 will start to warn about it.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
they then get stripped into their own package anyway, but without this we don't
get debug symbols at all with rustc >= 1.77
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
since under certain circumstances (e.g. using safari < 16) the addon
constructor already throws an exception, not only the loading later.
To allow falling back to the canvas renderer, move it into the try
block after WebGL detection.
This should fix the xterm.js console on Apple's iOS.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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.
0: https://github.com/xtermjs/xterm.js/issues/4574
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This is only used here anyway, and proxmox-sys is one of those monster
crates still awaiting to be split up in more sensible pieces.
This halves (non-release) build times here from 8.5 to 4.1 seconds.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
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>
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>
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>
Avoids that we need to bump all frontends with updated dependencies
and then add them to the proxmox-termproxy's Breaks info.
We can loosen this dependency on the next major release, or when all
users switch to the respective ones (with a versioned Break!).
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
shaves of over 100KB of the final binary and this crate is small
enough to not notice a relevant compile time impact.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
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.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
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>
