See discussion on mailing list: http://lists.cendio.se/pipermail/thinlinc-technical/2013-July/000344.html Ideas for a solution: 1) Do not check the full path at all, but instead verify root ownership or something similar. 2) Fetch the prefix dynamically. Probably needs this as an argument to get_tl_xvnc_processes then.
(In reply to comment #0) > 2) Fetch the prefix dynamically. Probably needs this as an argument to > get_tl_xvnc_processes then. Fixed in 27873.
(In reply to comment #1) > (In reply to comment #0) > > > 2) Fetch the prefix dynamically. Probably needs this as an argument to > > get_tl_xvnc_processes then. > > Fixed in 27873. Tested using following code: python -c "import thinlinc.ctccommon; print thinlinc.ctccommon.get_tl_xvnc_processes()" The commit fixes the issue partly using prefix.get_tl_prefix() which in its turn returns a hardcoded path to /opt/thinlinc and gives the following warning: 'Warning: -c uses get_tl_prefix() uninitialised' However the main issue is solved and sessions are returned.
> Tested using following code: > > python -c "import thinlinc.ctccommon; print > thinlinc.ctccommon.get_tl_xvnc_processes()" > > The commit fixes the issue partly using prefix.get_tl_prefix() which in its > turn returns a hardcoded path to /opt/thinlinc and gives the following warning: > > 'Warning: -c uses get_tl_prefix() uninitialised' > > However the main issue is solved and sessions are returned. This is good enough now when main issue is solved.
I missed the obvious thing in this bug, tester should test install ThinLinc under another installation prefix, as the orginal issue referenced on mailinglist is about.
There are a lot of other issues preventing ThinLinc from running in a custom path, so it's not meaningful to test that. What should be tested though is that the HTML 5 client works fine after this change.
(In reply to comment #5) > There are a lot of other issues preventing ThinLinc from running in a custom > path, so it's not meaningful to test that. What should be tested though is that > the HTML 5 client works fine after this change. Have been testing the HTML5 client without any issues, so closing this bug.