Software requirements?

Hi,

There are no requirements for RDM on Linux systems. Are you asking this question because you had an issue?

We launched the pre-release for Ubuntu only. This may change in the future and we are glad to know which Linux flavors our customer is using. This will help us choose which platform we could support.

Regards,

Hi,

The only extra step performed by the deb package is generate mono certificates if they are not installed.
What distribution were you trying to run RDM on?

I'm glad to know RDM Linux is mostly covering your needs even in its early stage.
Lets us know if you encounter any bugs or hinderance.

Regards

Hi David,

Yep, and it's working well enough on Ubuntu, although I stopped using that long ago. I'm testing in a Ubuntu VM against any issues I find on my laptop.

Hi Jonathan,

I believe I did that generation, but I'll do it again to be sure. I'm trying to run it on Arch Linux, so I'm aware that most pain I have here is self-inflicted (I've been running RDM in wine and farming out RDP connections to an RDM template that calls the Linux version of xfreerdp, so I'm used to the pain). I also have a Ubuntu VM that I test any bugs I find to see if they exist on the supported platform and have already posted a couple over in the bug forum.

We launched the pre-release for Ubuntu only. This may change in the future and we are glad to know which Linux flavors our customer is using. This will help us choose which platform we could support.

Well that limits my ability to help at the moment. To provide you the Linux flavor I use, it is Fedora right now (though I do use Raspbian on my Raspberry Pi's). My preference would be to see it in the DNF format Fedora/RedHat are moving toward when you do release it for that platform, though YUM would make it backward compliant for the time being (not sure how long YUM will continue to be supported).

I've opened a ticket on our side.
If it's a relatively easy fix, I'll post steps on how to install RDM on any platform by manually extracting the deb package.

Installed on Linux Mint 19.3 and seems to work with a few issues... I don't know if it is related to Mint (Debian/Ubuntu based) but I'm having problems right clicking on a folder to create a new (RDP) entry. Right clicking and adding a session (RDP) works better. (what is the difference?)
Also, I cannot open an RDP session in full screen by Right Click and "Open Full Screen" or setting the session to general/display and selecting external or Undocked. It does not save the change.

Would it be better to test "RDM on Linux" withingn Debian or Ubuntu or should I continue on Linux Mint?

Thanks,

R.

@raphael01
Launching sessions externally is currently not supported. The setting is there to prevent breaking existing configuration and to allow you to change the settings to impact other platforms.
I've opened a ticket on our side to look into the fullscreen issue.

Regards

We launched the pre-release for Ubuntu only. This may change in the future and we are glad to know which Linux flavors our customer is using. This will help us choose which platform we could support.

Well that limits my ability to help at the moment. To provide you the Linux flavor I use, it is Fedora right now (though I do use Raspbian on my Raspberry Pi's). My preference would be to see it in the DNF format Fedora/RedHat are moving toward when you do release it for that platform, though YUM would make it backward compliant for the time being (not sure how long YUM will continue to be supported).

FWIW, I fired up a Fedora 32 VM. Tried installing with alien but that failed. Installed with dpkg threw some errors about not being able to set the security execution context (assuming it can't run the postinst script), but I can still start up RDM. IDK of any additional issues you would run into, but it's further than I got on my Arch system

The post install script generates mono certificated used when accessing https services.
DPS using office365 authentication and dropbox authentication won't work if those certificates cannot be found.

Hi Jonathan,

Yep, that doesn't seem to have been the issue. I'll keep poking it with a couple different tools.

@tmashos
What steps did you use to run RDM on arch?
I tried on Fedora and Manjaro (granted this is not arch but it's arch based) and RDM ran on those platforms.

@tmashos
What steps did you use to run RDM on arch?
I tried on Fedora and Manjaro (granted this is not arch but it's arch based) and RDM ran on those platforms.

Hi Jonthan,

That's encouraging. What I did was extract the files from the deb file and copied them to the locations they were to be installed to (/usr/lib/devolutions and /usr/lib/share/application (and icons)) respectively. Then I changed into the /usr/lib/devolutions/RemoteDesktopManager directory and ran RemoteDesktopManger.

I'll grab a copy of Manjaro and see if it works for me there. I'm guessing I may be missing some environment variable that is making it use the system's mono rather than what appears to be some mono libraries shipped with RDM.

Do you have mono installed?

Hi Jonathan,

Yes I do, that's actually what is spitting out the help text it seems.

Works in a Manjaro live session here, I'll keep plugging away at what this might be.

FWIW, Manjaro doesn't have mono installed.

Thank you for reporting back your findings.

I installed mono on my manjaro vm and started having problems.
Not yours specifically but problems because it tries to load the installed mono instead of the bundled one.

I'm looking into it.

Hi Jonathan,

Likewise, I removed mono from my Arch system and it started working in certain ways.

If I just extract the deb into my home directory (into /home/thomas/RDM/usr/lib/devolutions/RemoteDesktopManager/), cd into that directory and run "./RemoteDesktopManger" it now runs. However if I extract it instead to /usr/lib/devolutions/RemoteDesktopManager, cd into that directory and run "./RemoteDesktopManager" I get the mono help (even though I've uninstalled Mono) as below.

$ ./RemoteDesktopManager
Usage is: mono [options] program [program-options]

Development:
--aot[=<options>] Compiles the assembly to native code
--debug[=<options>] Enable debugging support, use --help-debug for details
--debugger-agent=options Enable the debugger agent
--profile[=profiler] Runs in profiling mode with the specified profiler module
--trace[=EXPR] Enable tracing, use --help-trace for details
--jitmap Output a jit method map to /tmp/perf-PID.map
--help-devel Shows more options available to developers

Runtime:
--config FILE Loads FILE as the Mono config
--verbose, -v Increases the verbosity level
--help, -h Show usage information
--version, -V Show version information
--version=number Show version number
--runtime=VERSION Use the VERSION runtime, instead of autodetecting
--optimize=OPT Turns on or off a specific optimization
Use --list-opt to get a list of optimizations
--attach=OPTIONS Pass OPTIONS to the attach agent in the runtime.
Currently the only supported option is 'disable'.
--llvm, --nollvm Controls whenever the runtime uses LLVM to compile code.
--gc=[sgen,boehm] Select SGen or Boehm GC (runs mono or mono-sgen)
--handlers Install custom handlers, use --help-handlers for details.
--aot-path=PATH List of additional directories to search for AOT images.

Jonathan

Slight correction to my previous message. It seems when I originally extracted it outside of my home directory I did it differently, because if I move it there from my home directory it works fine, unless mono is installed. If mono is installed I'm getting this error, which I assume is what you're getting

Unhandled Exception:
System.TypeInitializationException: The type initializer for 'GLib.Marshaller' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Sys' threw an exception. ---> System.EntryPointNotFoundException: SystemNative_LChflagsCanSetHiddenFlag assembly:<unknown assembly> type:<unknown type> member:(null)

That is indeed the same message I get when mono is installed.
I'll continue working on a fix monday.

Thank you for the tests and letting me know your progress.

Regards

FWIW, I fired up a Fedora 32 VM. Tried installing with alien but that failed. Installed with dpkg threw some errors about not being able to set the security execution context (assuming it can't run the postinst script), but I can still start up RDM. IDK of any additional issues you would run into, but it's further than I got on my Arch system

I am currently running Fedora 31 on the machine I have to test this on, so I will try. Thank you for the information and how you set it up.

@Jonathan - Any word yet on manually creating the certificates? If that is all it does post-install and we can do that manually (if we can); then we should be able to test everything like an Ubuntu setup would be able to.

If you unzip the deb package, the post install script is in the control tarball.
Make sure you have the ca-certificates package installed before executing it.

Jonathan, Is the any way to bulk import the sessions we have in RDM for Windows? even if features are not currently enabled, it would make our life much simpler than to have to recreate everything...

BTW, the page, though old, is not found: https://blog.devolutions.net/2017/08/running-remote-desktop-manager-on-linux
Is there a replacement that might give us some guidance?
Thanks

What data source are you using?

If I am not mistaken, this page used to describe a way to load the android version of RDM on Linux that no longer worked.

I can now confirm I WAS able to get it working on Fedora 31 to the point that it will make connections (I think - I will test connecting via RDP once the kids are done with their school work for the day). Other than that, I tried setting up the CA certs, but it isn't finding the package (even though it is installed). Looks like default location is not the same as expected so I will see what I can learn about that as I work through it today. Not sure what else I can test, however, since I don't use the other connection methods and we only have one windows device in the house to connect to.

The main connection uses I have day to day are SSH and Web, so it will be FAR more useful to me once those are added.

BTW: You were right Jonathan Lafontaine and tmashos, it is a simple thing. All the DEB file seems to be doing is placing the files in the right location and kicking off the certficate script. Everything is working fine when I do the same thing manually (well, not the script as pointed out above, but the application is).

the ca-certificates package should install all the certs in /usr/share/ca-certificates/mozilla/
Is it the case on Fedora?

Hi Jonathan,

No, that doesn't seem to be the case.

Arch
$ pacman -Ql ca-certificates-mozilla
ca-certificates-mozilla /usr/
ca-certificates-mozilla /usr/share/
ca-certificates-mozilla /usr/share/ca-certificates/
ca-certificates-mozilla /usr/share/ca-certificates/trust-source/
ca-certificates-mozilla /usr/share/ca-certificates/trust-source/mozilla.trust.p11-kit

Fedora
[thomas@localhost ~]$ rpm -ql ca-certificates
/etc/pki/ca-trust
/etc/pki/ca-trust/README
/etc/pki/ca-trust/ca-legacy.conf
/etc/pki/ca-trust/extracted
/etc/pki/ca-trust/extracted/README
/etc/pki/ca-trust/extracted/edk2/README
/etc/pki/ca-trust/extracted/edk2/cacerts.bin
/etc/pki/ca-trust/extracted/java
/etc/pki/ca-trust/extracted/java/README
/etc/pki/ca-trust/extracted/java/cacerts
/etc/pki/ca-trust/extracted/openssl
/etc/pki/ca-trust/extracted/openssl/README
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
/etc/pki/ca-trust/extracted/pem
/etc/pki/ca-trust/extracted/pem/README
/etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem
/etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
/etc/pki/ca-trust/source
/etc/pki/ca-trust/source/README
/etc/pki/ca-trust/source/anchors
/etc/pki/ca-trust/source/blacklist
/etc/pki/ca-trust/source/ca-bundle.legacy.crt
/etc/pki/java
/etc/pki/java/cacerts
/etc/pki/tls
/etc/pki/tls/cert.pem
/etc/pki/tls/certs
/etc/pki/tls/certs/ca-bundle.crt
/etc/pki/tls/certs/ca-bundle.trust.crt
/etc/ssl
/etc/ssl/certs
/usr/bin/ca-legacy
/usr/bin/update-ca-trust
/usr/share/man/man8/ca-legacy.8.gz
/usr/share/man/man8/update-ca-trust.8.gz
/usr/share/pki
/usr/share/pki/ca-trust-legacy
/usr/share/pki/ca-trust-legacy/ca-bundle.legacy.default.crt
/usr/share/pki/ca-trust-legacy/ca-bundle.legacy.disable.crt
/usr/share/pki/ca-trust-source
/usr/share/pki/ca-trust-source/README
/usr/share/pki/ca-trust-source/anchors
/usr/share/pki/ca-trust-source/blacklist
/usr/share/pki/ca-trust-source/ca-bundle.trust.p11-kit
[thomas@localhost ~]$

BTW: One thing you may want to consider is distributing it as a SNAP distribution. I don't know how much extra work it is or will prevent (if any); but it is officially supported by Canonical and works across Linux platform differences (supposedly): https://snapcraft.io/

I have used other SNAP projects (mostly Spotify) and it seems to work okay. It is a pain as an end user having so many different repositories and managers to use (YUM/DNF, RPM, PIP, SNAP, NPM, etc), but it works. Just a thought for you....

SNAP would work, Flatpak would probably be better, however deb is fine (and so is just releasing it as a tar.gz). My (and many others) experiences with SNAP is that it's really slow opening, and I'm doubtful this is something that can be fixed since it's been this way for years.

Also, the forum lost one of my posts, which had some screenshots showing the location of the certificates on Arch, although I cannot find them in Fedora in the same format. In Arch, you can find the files in /etc/ssl/certs (files that the post_install is generating such as 02265526.0). IDK what the certs are used for, but I could attempt a symlink and see if that works for them.

True, but I never used the other "universal" formats like flatpak to compare. I just figured having a single repo for all major Linux flavors would prove valuable to the Devolutions team. Personally, I prefer uploading straight to the mainstream distribution channels, but that is me.

Hi Steeladept,

The more I think about how RDM works, the more I think SNAP might actually be a bad way to do it. SNAP publishes updates through the snap store, which IIRC only Canonical runs. That isn't itself an issue, but SNAPs also autoupdate and there's no way to select a specific version (nor a way to roll back), so anytime devolutions pushed an update it would be automatically installed with no way to prevent that from happening. If that update includes a database schema update, you then have to update all of your other users as well that might not be using Linux/SNAPs.

Certs are used when authenticating to DPS or Dropbox.

Packaging is on our todo list and we will evaluate our options for the official release.

@Jonathan
Late replies... Local datasource on windows 10
Page not found... is there a page that is for the new RDM on linux?

Raphael

@raphael01
As we are not officially beta, this is an early access preview build, we do not have a specific Linux page on our website at the moment.
We don't support importing yet but if you are using a xml or sqlite data source, you could simply the file on your Linux os and add it in RDM.