Rustdesk on Fossapup64

[wizard]

Rustdesk is an open source remote desktop (remote control) program similar to Anydesk or Teamviewer.
This topic is a continuation from https://forum.puppylinux.com/viewtopic.php?t=6683 Anydesk topic that was hijacked (my bad).

For reference:
Hardware = Intel quad core
Ram = 4gb
OS = Fossapup64
Installed:
rustdesk-1.1.9.deb
xdotool from PPM

Rustdesk started from terminal opens, but displays a Unsupported display error and will not connect.

[wizard]

@mistfire

Try this, run rustdesk, if connecting to remote fails then read the log files /var/log . It might get some clues why it fails.

Also check if libssl 1.2.1 was installed.

Will report on logs, could not find libssl 1.2.1

Thanks
wizard

[wizard]

@mistfire

Made symlink libssl.so.1.2.1 to libssl.so.1.1
-run rustdesk in terminal and now get password prompt
-enter password and still get error:

x11-2.jpg (9.09 KiB) Viewed 966 times

Here is output in terminal, Warning & Critical lines are generated when trying to connect.

rd-connect-error.jpg (41.09 KiB) Viewed 966 times

Thanks
wizard

[mikeslr]

Ignore what below the -=-=-=--=--=--== line. Not sure how you got into a the hunt for a phantom lib. Started from scratch by downloading the rustdesk 1.1.9.deb, extracting, checking with ldd then built a pet, supplying the newer version of xdotool it being the only missing lib reported under Bionicpup64 (I was using at the time). Started rustdesk via a terminal which reported:

INFO:TIS: scaleFactor 1
INFO:TIS: current platform: Linux
INFO:TIS: is_xfce: false
INFO:TIS: id updated

But, like you got:

rustdesk gui.png (36.53 KiB) Viewed 936 times

Will boot into Fossapup64 and see if there's a difference.

Booted into Fossapup, repeated the above, except that ldd didn't even suggest that a newer xdotool was needed. But got the same results, except that no update to id showed in the terminal output.

Included in the 1.1.9.deb was a control file revealing these dependencies:
Depends: libgtk-3-0, libxcb-randr0, libxdo3, libxfixes3, libxcb-shape0, libxcb-xfixes0, libasound2, libsystemd0, pulseaudio, python3-pip, curl. (Emphasis supplied). ListDD tells nothing about python, and about which I am also clueless.

My other thought is that Fossapup may not employ the same 'infra-structure' as Ubuntu Fossa Focal between X11 and applications. But I would have thought ldd would have noticed that something was missing.

-=-=-=--=--=--==
"Made symlink libssl.so.1.2.1 to libssl.so.1.1" may be the cause of the problem. libs are often backward compatible, but not 'forward' as that requires the compiler to be a prophet.

Don't know who the rust Devs had in mind for their application. Although I didn't check all distributions covered by pkgs.org, a quick scan revealed that no OS was using a libssl 'newer' than libssl.so.1.1 other than:

Fedora 35 & 36 >libssl47-3.4.2-1.x86_64.rpm; and openSUSE Tumbleweed >libssl52-3.5.3-1.3.x86_64.rpm. And while those higher numbers might just have been a difference in the naming conventions used by those distros, a quick check of libssl52-3.5.3-1.3.x86_64.rpm's dependencies revealed among them libc.so.6(GLIBC_2.36)(64bit). IIRC, Fossapup64 employs glibc-2.30, so would not be able to use that library even via a symlink named 1.2.1.

[mikewalsh]

Mm.

In other words, it's an application that's basically "out-of-reach" for any current Puppy/Dog/DPup or derivatives thereof.....because, to the best of my knowledge, none of our 'stable' employ that new a version of the glibc.

This has obviously been built on a cutting-edge distro. My guess is that the devs assume that everybody is always running the very newest of everything, since most computer geeks are paranoid about being 'caught out' by 'nasties'.

A nice-looking application, but not really applicable to us.....unless somebody wants to grab the source code, make 'adjustments' as & where necessary, then compile the entire thing against an older build-environment. I don't know if anybody's really feeling that adventurous, especially when there ARE other alternatives available.

Just my personal thoughts on the matter.....FWIW.

Mike.

[mikeslr]

Mike, you posted before my edits. You should know by now that with a bone between my teeth I don't drop it until I've chewed it a lot and I decided it tastes bad.

[mikewalsh]

Mike, you posted before my edits. You should know by now that with a bone between my teeth I don't drop it until I've chewed it a lot and I decided it tastes bad.

^^^ +1. Heh.

T'other Mike.

[rcrsn51]

In other words, it's an application that's basically "out-of-reach" for any current Puppy/Dog/DPup or derivatives thereof....

Not true.

[mikeslr]

Thanks, rcrsn51, for the link. I note that your instructions were provided for debian-bullseye, specifically for the 'debian-bulleyes dog' created using your Debian-Live Bullseye Starter Kit. Unfortunately, we've been trying to get it to function under Fossapup64. Ubuntu Fossa Focal does not have Rustdesk in its repo. So we've had to start with the 'deb' offered on rustdesk's own website. This has gotten us into searching for missing pieces and, so, some strange places.

While the instructions here, https://www.linuxcapable.com/how-to-in ... debian-11/ are also for debian bullseye (albeit the 'standard OS') they may be useful to those running Fossapup64. Certainly curl is already to be found in Fossapup64. So the instructions to run from a terminal:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

may move things forward.

Alternatively, perhaps this is a job for pkg-cli or pkg-cli2

For anyone still interested, read the entire thread rcrsn51 referenced. In particular, note "with newer hardware, RustDesk works extremely well" but that a computer having the SSE4 instruction set may be required.

[wizard]

@mikeslr

Not sure how you got into a the hunt for a phantom lib.

It came from the original post here: https://forum.puppylinux.com/viewtopic.php?t=6683 Mistfire was helping and he reported Rustdesk as working in Quickpup64.

@mikewalsh The subject of remote desktop (remote control) comes up frequently and many potential programs have been discussed including:
-Teamviewer
-VNC
-Anydesk
-Google Remote Desktop
-No Machine
-XRDP
-X2Go
-Rustdesk
-BackSeatDriver

Know you've had BSD working, I've tried most of the others and only Anydesk and VNC seem to work consistently with Puppy's for me, Others just won't work at all and some require a great deal of effort to implement.

I thought Rustdesk was promising since it is open source, but not looking good at this point.

Thanks
wizard

[mikeslr]

There's a substantial divide between debian/Ubuntu and Slackware. Sometimes it doesn't matter and libs from one can be used in the other. And sometimes a lib from another proves to be an invitation to 'go down the rabbit hole'.

A good reason to learn compiling if you can get your head around it.

[mikewalsh]

@rcrsn51 :-

In other words, it's an application that's basically "out-of-reach" for any current Puppy/Dog/DPup or derivatives thereof....

Not true.

Hm. Interesting, Bill.....especially about the Core2Duo machine. RustDesk would appear, therefore, to need some of the more advanced instruction sets which come with newer-gen CPUs; having just purchased a re-furbished Dell Latitude, I know the Core2Duos "top-out" at SSSE3.

As for PulseAudio; I suspect we'll eventually need to bite the bullet and start including it OOTB. It IS pretty much the expected industry standard, and has been for quite some years.

@wizard :- Don't forget, Wiz, that BackSeatDriver only really works for two Puppy/Dog/FatDog-related machines. At least, that's according to its creator, Grant (smokey01), who originally envisaged it as a remote-assistance/tuition kind of tool.....

Mike.

[wizard]

@mikewalsh
Yes, I remember our discussion from several years ago after Teamviewer pulled the plug on its older versions that cut Puppy out. We looked at BSD, but decided Anydesk might be a better choice since it was cross platform. I like to include both VNC and Anydesk in all my remasters like Friendly Fossa and Friendly Bionic

Thanks
wizard

[mistfire]

@wizard

Did you try connect on Windows PC remotely using RustDesk? Yes connecting to remote windows PC using Rustdesk works on QuickPup64

[wizard]

@mistfire

Downloaded rustdesk-1.1.9-windows_x64-portable.zip and ran on W10 x64. Puppy Rustdesk client connected without issue. Does Quickpup64 work for both host and local?

Thanks
wizard

[mistfire]

Does Quickpup64 work for both host and local?

@wizard
What do you mean?

I just install rustdesk on my QuickPup64 then connect and control windows computer remotely using rustdesk

[wizard]

@mistfire

What do you mean?

Can you use Rustdesk on two Quickpup64 computers, one controlling the other?

Thanks
wizard

[mistfire]

Can you use Rustdesk on two Quickpup64 computers, one controlling the other?

Thanks
wizard

I haven't tried yet

[mistfire]

When I read the source code of RustDesk on github. That UNSUPPORTED DISPLAY error message was caused by Rustdesk being dependent on systemd-logind or elogind for detecting display server session

[mikewalsh]

When I read the source code of RustDesk on github. That UNSUPPORTED DISPLAY error message was caused by Rustdesk being dependent on systemd-logind or elogind for detecting display server session

Huh. Yah, THAT explains everything. It's exactly the same reason we had all that trouble with Skype a while back, not remembering log-ins, etc, and generally refusing to behave itself. Systemd strikes again..!

I'm beginning to think Puppy is going to have to include it OOTB in future.....because almost every piece of software out there these days - written for Linux - expects its presence. Or at the very least, elogind.....this being the systemd-login piece of code, extracted to run as a standalone daemon. Yet - and I don't know if this is by design, or just the fault of individual developers - it seems to give nothing in the way of terminal feedback when it doesn't work.

And that seems 'counterproductive'. Or are the RedHat dev team who cooked all this stuff up - Lennart Poettering & co - attempting to create a Linux version of Crapple's "walled garden"? Makes no sense, otherwise....

As I understand it, elogind permits logging-in as a specific user when creating an Xorg X11 session..... Apparently, RustDesk expects this.

Mike.

[mistfire]

@mikewalsh

I couldn't figured out how to run elogind. It always threw "NO SESSIONS" message on loginctl. That means elogind was unable to create session