MariaDB support

Hi.

Unfortunately no, but I'll move the priority of mariadb/mysql up the list an will see what we can do.

Regards

Great - thanks :)

Hello,

Would it be right to say that now we can use the MariaDB ?

I did import the parameters (running fine on windows),

All seems to import right, 2FA goes right... but entry are not showing..... BUT ... in the "user Vault entry" are displaying correct.

Am I missing something on my side? or ? Is it due to the difference of Linux and Windows Builds?

Linux : 2020.02.04 vs Windows: 2020.02.19 ?

Thanks for your answer...

Hi,

Yes, MariaDB is supported.
Since you can connect to your user vault, I'd say the problem is probably not your data source configuration.
Could you run RDM in a terminal (execute the remotedesktopmanager command) and see if there's anything other than the couple gtk warning that could help?
Also, you can check RDM's application logs (Application Logs under the help tab in RDM) and see if RDM recorded any error.

Regards

Hi,

thanks for the answer:

here is what i get when i Launch via the remotedesktopmanager command:

tux@vub:~$ remotedesktopmanager

(RemoteDesktopManager:11404): GLib-GObject-CRITICAL **: 16:05:56.699: g_signal_connect_data: assertion 'c_handler != NULL' failed

(RemoteDesktopManager:11404): GLib-GObject-CRITICAL **: 16:05:56.759: g_signal_connect_data: assertion 'c_handler != NULL' failed

(RemoteDesktopManager:11404): GLib-GObject-CRITICAL **: 16:05:56.779: g_signal_connect_data: assertion 'c_handler != NULL' failed

(RemoteDesktopManager:11404): GLib-GObject-CRITICAL **: 16:05:56.798: g_signal_connect_data: assertion 'c_handler != NULL' failed

(RemoteDesktopManager:11404): GLib-GObject-CRITICAL **: 16:05:56.805: g_signal_connect_data: assertion 'c_handler != NULL' failed

(RemoteDesktopManager:11404): GLib-GObject-CRITICAL **: 16:05:56.827: g_signal_connect_data: assertion 'c_handler != NULL' failed

(RemoteDesktopManager:11404): GLib-GObject-CRITICAL **: 16:05:56.842: g_signal_connect_data: assertion 'c_handler != NULL' failed

and the logs of the application does not show anything:


Any idea ?

(PS: are the requierment to use the "mariaDB" the same as for the windows version of RDM ?)

We share most of our data source code with Windows, so requirements should be roughly the same.
Since you are able to access your user vault, RDM was able to access your MariaDB data source.
We also tested all supported data source as part of our tests before the release and had no problem.

My guess is you have an entry that, for some reason, crashes the connection loading process.
Would you be able to test debug builds to help resolve this issue?

No problem... I guess I can give a try to test, without problem.

PS: do not be afraid of being complet in "explanations"... I am a linux enthousiatic, but unfortunately, I am not an expert.

Looking for the debug builds

Hello Jonathan,

Thanks for the link...

Unformtunately, does not seems to reveal much more :-(

(I don't screenshot the log windows, as there is nothing more than the last time)

(RemoteDesktopManager:2525): GLib-GObject-CRITICAL **: 20:41:54.092: g_signal_connect_data: assertion 'c_handler != NULL' failed

(RemoteDesktopManager:2525): GLib-GObject-CRITICAL **: 20:41:54.151: g_signal_connect_data: assertion 'c_handler != NULL' failed

(RemoteDesktopManager:2525): GLib-GObject-CRITICAL **: 20:41:54.209: g_signal_connect_data: assertion 'c_handler != NULL' failed

(RemoteDesktopManager:2525): GLib-GObject-CRITICAL **: 20:41:54.230: g_signal_connect_data: assertion 'c_handler != NULL' failed

(RemoteDesktopManager:2525): GLib-GObject-CRITICAL **: 20:41:54.250: g_signal_connect_data: assertion 'c_handler != NULL' failed

(RemoteDesktopManager:2525): GLib-GObject-CRITICAL **: 20:41:54.288: g_signal_connect_data: assertion 'c_handler != NULL' failed

(RemoteDesktopManager:2525): GLib-GObject-CRITICAL **: 20:41:54.321: g_signal_connect_data: assertion 'c_handler != NULL' failed

Have you an "even more" verbosed version :-D

Thanks again

That only means it didn't crash where I thought it did.
Back to the drawing board.

;-)

Thanks !

In Preferences, Advanced, what is the Logs combobox set to?

aaaaaaaaaaaah, one step forward:
Was set to file... changed it to DB

for info, I have this at the startup after the google 2FA

No idea what the white grey windows at the back says..... :-)

BUT in the logs:

plenty of these:



Might help ! :-D

and as it talk about "whitespace".... could it come from a "folder" with spaces ?

This is my "root"



?

Have a nice evening/night

Would it be possible for you to export the root + first folders?
You can email me the resulting file.
Alternatively, you can import your connection in a new xml data source and remove any sensitive information and send that instead.

Hi,

Sorry,been busy @ customer this morning.

Unfortunately, I am not able to export (don't have the right)

BUT .... I will try removing the space in folder on the first "folders"....

I'll keep you posted

So, my RDM admin told me we won't be able to export the whole thing.... :-(

Couldn't this help? (it's a bit light, I admit :-D )

Since yesterday, the "_outils_Internes" has been renamed: it was "_Outils Internes", so, the "_" as been added.

Is the "_" not a special typo that linux does not like?



and just in case: the error


:-)

again Thanks for your help.

Based on the error, I don't think any of your folders' name is the problem here.
Looks like we have a problem loading the root node's parameters.
Would he be comfortable only sharing this part of the exported file?

Hi jonathan,

I do not forget you AT ALL ... but did not managed to have the exported file yet... still I have some hope !

Have a nice weekend

Hello Jonathan,

I did get some info today:

So, the answer is "no" he won't send any kind of exported datas...... BUT ..... cause yes, I did get a "BUT" .....

Would it help to have some kind of "remote" connexion (Teamviewer) to have a look directly? (on the DB Admin part, I mean)

Let me know if it's the kind of things that could be "think of"...

Hi,

Thanks for the offer but I don't think that would help much in this case.
I will dig some more and try to reproduce your error on my side.

Hey....

Your crypted ready version did the trick ... !!!!!!!!!!!!!! THANKS !

At least, the entries show up...

So seems that was it: good deduction !

now, I'll try to open entries.... (so far, 2 entries clicked, and 2 "crashes" :-D)

We'll get there.

what type of entries and do you have a stack trace in the terminal?

For the record: I am sorry for the wasted time, I was not aware of the "crypted database" :-)

But, for my "troubles"..... we have configured all the "ssh" entries, for exemple, to log..... to a destination....... ----> C:\logs ..... might cause trouble ??? until now, we were on windows only.....


So, I open 2 ssh entries, and when i close 1 of them: application freeze....

1 of those 2 entries at the time works fine....

=================================================================

Native Crash Reporting

=================================================================

Got a SIGSEGV while executing native code. This usually indicates

a fatal error in the mono runtime or one of the native libraries

used by your application.

=================================================================

=================================================================

Native stacktrace:

=================================================================

0x5575cb9bf229 - ./RemoteDesktopManager :

0x5575cb9bf5a9 - ./RemoteDesktopManager :

0x5575cb96b7c4 - ./RemoteDesktopManager :

0x5575cb9b8be5 - ./RemoteDesktopManager :

0x7fe6db517f55 - /lib/x86_64-linux-gnu/libgdk-3.so.0 :

0x7fe6db518584 - /lib/x86_64-linux-gnu/libgdk-3.so.0 :

0x7fe6db4f5f4d - /lib/x86_64-linux-gnu/libgdk-3.so.0 :

0x7fe6dace5e8e - /lib/x86_64-linux-gnu/libglib-2.0.so.0 : g_main_context_dispatch

0x7fe6dace6240 - /lib/x86_64-linux-gnu/libglib-2.0.so.0 :

0x7fe6dace6533 - /lib/x86_64-linux-gnu/libglib-2.0.so.0 : g_main_loop_run

0x7fe6db81837d - /lib/x86_64-linux-gnu/libgtk-3.so.0 : gtk_main

0x408a6089 - Unknown

=================================================================

Telemetry Dumper:

=================================================================

Could not exec mono-hang-watchdog, expected on path '/etc/../bin/mono-hang-watchdog' (errno 2)

Pkilling 0x140627582396160x from 0x140629634973632x

Pkilling 0x140629222336256x from 0x140629634973632x

Pkilling 0x140629218133760x from 0x140629634973632x

Pkilling 0x140629509650176x from 0x140629634973632x

Pkilling 0x140627590244096x from 0x140629634973632x

Pkilling 0x140627584497408x from 0x140629634973632x

Pkilling 0x140626673792768x from 0x140629634973632x

/usr/bin/remotedesktopmanager: line 4: 8165 Segmentation fault (core dumped) ./RemoteDesktopManager

tux@vub:~$

Unable to open "web browser (http/https)" entries created under windows....... also, try to create a new one...... did not found were to enter the URL :-D

I have firefox, chrome and opera installed on the linux machine...

(but, is it the right "tread" to talk about these kind of things ?)

You absolutely did not waste my time.
There was a bug and now, we have one less :)

For the SSH entry, that looks like a native crash.
Hard to tell from the crash log but I will assume our native ssh lib didn't quite like something.
Are you able to list the options the session is configured with and the kind of server accessed?

For the Web browser entries created on Windows, you press the open button but nothing happens?
Are you running Ubuntu? And could you check if you have xdg-open installed?
And if it is, what 'xdg-open https://www.google.com' does?

As for creating new web browser entries, we don't yet support the web browser session entry but you can use the website data entry (right click -> Add -> Add Information)

You could start a new thread for each problem, that could make it easier for people in the same situation you hopefully find the answer.