[jira] [Resolved] (GUACAMOLE-662) Failing unit tests for guacamole-server not triggering build failure
[
https://issues.apache.org/jira/browse/GUACAMOLE-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper resolved GUACAMOLE-662.
--
Resolution: Fixed
Fix Version/s: 2.0.0
> Failing unit tests for guacamole-server not triggering build failure
>
>
> Key: GUACAMOLE-662
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-662
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Major
> Fix For: 2.0.0
>
>
> The unit test for the "nest" instruction (hopefully soon to be deprecated via
> GUACAMOLE-661) has been failing. Assuming the failure is legitimate, it
> hasn't been a problem in practice since the "nest" instruction has been
> unused for some time, but the fact that this failure has gone unnoticed is
> troubling. The build results currently show the following for {{make check}}:
> {code:none}
> ...
> PASS: test_libguac
>
> Testsuite summary for guacamole-server 1.0.0
>
> # TOTAL: 1
> # PASS: 1
> # SKIP: 0
> # XFAIL: 0
> # FAIL: 0
> # XPASS: 0
> # ERROR: 0
>
> ...
> {code}
> The test log within {{tests/test_libguac.log}} contradicts this, showing that
> there is actually a test failure (not to mention more than one test total):
> {code:none}
> CUnit - A unit testing framework for C - Version 2.1-3
> http://cunit.sourceforge.net/
> Suite: protocol
> Test: base64-decode ...passed
> Test: instruction-parse ...passed
> Test: instruction-read ...passed
> Test: instruction-write ...passed
> Test: nest-write ...FAILED
> 1. protocol/nest_write.c:104 - CU_ASSERT_STRING_EQUAL(buffer,expected)
> Suite: client
> Test: layer-pool ...passed
> Test: buffer-pool ...passed
> Suite: util
> Test: guac-pool ...passed
> Test: guac-unicode ...passed
> Run Summary:Type TotalRan Passed Failed Inactive
> suites 3 3n/a 00
>tests 9 9 8 10
> asserts 11091 11091 11090 1 n/a
> Elapsed time = -0.006 seconds
> {code}
> If "nest" is truly not behaving correctly, it should be corrected. If "nest"
> is correct but the test is wrong, the test should be fixed. Most importantly,
> the testing portion of the build process should be corrected such that:
> # The test report actually captures the correct number of tests passing and
> test failures.
> # A failing test fails the build.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GUACAMOLE-661) Deprecate "nest" instruction
[ https://issues.apache.org/jira/browse/GUACAMOLE-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper resolved GUACAMOLE-661. -- Resolution: Done Fix Version/s: 2.0.0 > Deprecate "nest" instruction > > > Key: GUACAMOLE-661 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-661 > Project: Guacamole > Issue Type: Improvement > Components: Documentation, libguac >Reporter: Michael Jumper >Assignee: Michael Jumper >Priority: Minor > Fix For: 2.0.0 > > > The ["nest" > instruction|http://guacamole.apache.org/doc/0.9.14/gug/protocol-reference.html#nest-stream-instruction] > was created in the early days of the Guacamole protocol as a means of > splitting up large instructions. At the time, this was necessary because > images and audio were transmitted within instructions that required the > entire block of data to be available at once. The "nest" instruction thus > provided a means of streaming data for instructions that otherwise did not > support it. > The Guacamole protocol switched over instructions with actual stream > semantics around the 0.9.0 release (back in 2014). Since that time, the nest > instruction has become unnecessary, and is actually no longer used in > practice. > It's time the instruction and related functions/structures were deprecated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GUACAMOLE-510) Nested socket index is not initialized
[
https://issues.apache.org/jira/browse/GUACAMOLE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper resolved GUACAMOLE-510.
--
Resolution: Fixed
Fix Version/s: 2.0.0
Fixed by GUACAMOLE-662 via commit
[47ad6f4|https://github.com/apache/guacamole-server/pull/208/commits/47ad6f4b59dc861ae8f17e41885c7f2947ff2bad].
> Nested socket index is not initialized
> --
>
> Key: GUACAMOLE-510
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-510
> Project: Guacamole
> Issue Type: Bug
> Components: libguac
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Trivial
> Fix For: 2.0.0
>
>
> Although {{guac_socket_nest()}} takes an index parameter, this parameter is
> never used and the index of the socket is left uninitialized.
> This is not a problem in practice as nested sockets are no longer used (the
> Guacamole protocol has evolved to inherently support streaming large blocks
> of data and no longer needs to nest itself as a workaround). It's likely that
> {{guac_socket_nest()}} and the "nest" instruction should be deprecated, but
> this should be fixed in the meantime.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GUACAMOLE-661) Deprecate "nest" instruction
[ https://issues.apache.org/jira/browse/GUACAMOLE-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper reassigned GUACAMOLE-661: Assignee: Michael Jumper > Deprecate "nest" instruction > > > Key: GUACAMOLE-661 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-661 > Project: Guacamole > Issue Type: Improvement > Components: Documentation, libguac >Reporter: Michael Jumper >Assignee: Michael Jumper >Priority: Minor > > The ["nest" > instruction|http://guacamole.apache.org/doc/0.9.14/gug/protocol-reference.html#nest-stream-instruction] > was created in the early days of the Guacamole protocol as a means of > splitting up large instructions. At the time, this was necessary because > images and audio were transmitted within instructions that required the > entire block of data to be available at once. The "nest" instruction thus > provided a means of streaming data for instructions that otherwise did not > support it. > The Guacamole protocol switched over instructions with actual stream > semantics around the 0.9.0 release (back in 2014). Since that time, the nest > instruction has become unnecessary, and is actually no longer used in > practice. > It's time the instruction and related functions/structures were deprecated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-689) Blank screen after authenticating to remote SSH sessions
[
https://issues.apache.org/jira/browse/GUACAMOLE-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16735911#comment-16735911
]
Michael Jumper commented on GUACAMOLE-689:
--
{quote}
It seems like a rendering issue??
{quote}
It's unlikely: http://guacamole.apache.org/faq/#probably-not-a-bug
What do you see in your guacd and Tomcat logs? What browser? Anything in the
browser's error console?
> Blank screen after authenticating to remote SSH sessions
>
>
> Key: GUACAMOLE-689
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-689
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole
>Affects Versions: 0.9.14
> Environment: Guacamole v 0.9.14
> Ubuntu v16.04 LTS
>Reporter: Steven Chaet
>Priority: Major
>
> I am able to log into the Guacamole interface and choose an SSH session to
> log into from there. It prompts me for my username/password and accepts my
> entries however I just get a blank screen and nothing else. This also happens
> when I try RDP as well.
> It seems like a rendering issue??
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-688) Docker Version ldap-user-search-filter is missing
[
https://issues.apache.org/jira/browse/GUACAMOLE-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16735333#comment-16735333
]
Michael Jumper commented on GUACAMOLE-688:
--
[~HaraldFielker], if you would like to contribute, please open a pull request.
From [https://github.com/apache/guacamole-client/blob/master/CONTRIBUTING]:
{quote}
{code:none}
...
2) Make and test your changes locally
The Guacamole source is maintained in git repositories hosted on GitHub:
https://github.com/apache/guacamole-client
https://github.com/apache/guacamole-manual
https://github.com/apache/guacamole-server
https://github.com/apache/guacamole-website
To make your changes, fork the applicable repositories and make commits
to a topic branch in your fork. Commits should be made in logical units
and must reference the JIRA issue number:
$ git commit -m "GUACAMOLE-123: High-level message describing the changes."
Avoid commits which cover multiple, distinct goals that could (and should)
be handled separately.
If you do not already have an account on GitHub, you will need to create
one before making your changes.
3) Submit your changes via a pull request on GitHub
Once your changes are ready, submit them by creating a pull request for
the corresponding topic branch you created when you began working on your
changes.
The Guacamole team will then review your changes and, if they pass review,
your changes will be merged.
{code}
{quote}
> Docker Version ldap-user-search-filter is missing
> -
>
> Key: GUACAMOLE-688
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-688
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-docker
>Affects Versions: 0.9.14
>Reporter: Harald Fielker
>Priority: Minor
>
> "ldap-user-search-filter" is missing as Enviormnent Variable in
>
> [https://github.com/apache/guacamole-client/blob/78f1ae1b4eac25501d532ddee94fd1d8588e56dc/guacamole-docker/bin/start.sh]
>
> Please add this to the section in the start.sh file
> set_optional_property \
> "ldap-user-search-filter" \
> "$LDAP_USER_SEARCH_FILTER"
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-601) VNC segfault when VNC server restarted
[
https://issues.apache.org/jira/browse/GUACAMOLE-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper updated GUACAMOLE-601:
-
Fix Version/s: (was: 1.0.0)
> VNC segfault when VNC server restarted
> --
>
> Key: GUACAMOLE-601
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-601
> Project: Guacamole
> Issue Type: Bug
> Components: VNC
>Affects Versions: 0.9.14
>Reporter: KokHooi Chew
>Priority: Minor
> Attachments: syslog.3
>
>
> While viewing, try to restart the VNC server, unable to reconnect back to the
> VNC then, continuously getting segfault until restart guacamole server in
> order to solve it
> {code:none}
> Jul 27 21:05:08 TDF-Jasper guacd[1354]: Creating new client for protocol "vnc"
> Jul 27 21:05:08 TDF-Jasper guacd[1354]: Connection ID is
> "$3c02e097-a5a4-4a78-9d75-72531046877d"
> Jul 27 21:05:09 TDF-Jasper guacd[6539]: Cursor rendering: local
> Jul 27 21:05:09 TDF-Jasper guacd[6539]: User
> "@ecba697e-1195-41d4-9b99-71525c58952e" joined connection
> "$3c02e097-a5a4-4a78-9d75-72531046877d" (1 users now present)
> Jul 27 21:05:14 TDF-Jasper guacd[6539]: Connected to VNC repeater, using
> protocol version 0.0
> Jul 27 21:05:15 TDF-Jasper guacd[6539]: VNC server supports protocol version
> 3.8 (viewer 3.8)
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: We have 1 security types to read
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 0) Received security type 1
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: Selecting security type 1 (0/1 in the
> list)
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: Selected Security Scheme 1
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: No authentication needed
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: VNC authentication succeeded
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: Desktop name "Remote control"
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: Connected to VNC server, using
> protocol version 3.8
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: VNC server default format:
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 32 bits per pixel.
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: Least significant byte first in each
> pixel.
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: TRUE colour: max red 255 green 255
> blue 255, shift red 0 green 8 blue 16
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: client2server supported messages (bit
> flags)
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 00: 00ff 0081 -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 08: -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 10: -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 18: -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: server2client supported messages (bit
> flags)
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 00: 001f 0080 -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 08: -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 10: -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 18: -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: Connected to Server "unknown
> (LibVNCServer 0.9.11)"
> Jul 27 21:05:38 TDF-Jasper guacd[1354]: Creating new client for protocol "vnc"
> Jul 27 21:05:38 TDF-Jasper guacd[1354]: Connection ID is
> "$f7648af9-9126-4e69-a6ef-a8b9ac3b7fc3"
> Jul 27 21:05:38 TDF-Jasper guacd[6573]: Cursor rendering: local
> Jul 27 21:05:38 TDF-Jasper guacd[6573]: User
> "@1446482b-becb-495a-9763-a151f6d6079f" joined connection
> "$f7648af9-9126-4e69-a6ef-a8b9ac3b7fc3" (1 users now present)
> Jul 27 21:05:38 TDF-Jasper guacd[6573]: Connected to VNC repeater, using
> protocol version 0.0
> Jul 27 21:05:39 TDF-Jasper guacd[6573]: VNC server closed connection
> Jul 27 21:05:39 TDF-Jasper guacd[6573]: Unable to connect to VNC server.
> Jul 27 21:05:39 TDF-Jasper kernel: [18008.137457] show_signal_msg: 42
> callbacks suppressed
> Jul 27 21:05:39 TDF-Jasper kernel: [18008.137462] guacd[6576]: segfault at 10
> ip 7f3cdcc64f32 sp 7f3cdde71d10 error 4 in
> libguac-client-vnc.so.0.0.0[7f3cdcc5c000+14000]
> Jul 27 21:05:40 TDF-Jasper guacd[6539]: User is not responding.
> Jul 27 21:05:40 TDF-Jasper guacd[6539]: User
> "@ecba697e-1195-41d4-9b99-71525c58952e" disconnected (0 users remain)
> Jul 27 21:05:40 TDF-Jasper guacd[6539]: Last user of connection
> "$3c02e097-a5a4-4a78-9d75-72531046877d" disconnected
> Jul 27 21:05:40 TDF-Jasper guacd[1354]: Connection
> "$f7648af9-9126-4e69-a6ef-a8b9ac3b7fc3" removed.
> Jul 27 21:07:19 TDF-Jasper guacd[1354]: Creating new client for protocol "vnc"
> Jul 27 21:07:19 TDF-Jasper guacd[1354]: Connection ID is
> "$ff22eac4-80d1-4225-a87f-73537e7b569d"
> Jul 27 21:07:19 TDF-Jasper
[jira] [Reopened] (GUACAMOLE-601) VNC segfault when VNC server restarted
[
https://issues.apache.org/jira/browse/GUACAMOLE-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper reopened GUACAMOLE-601:
--
> VNC segfault when VNC server restarted
> --
>
> Key: GUACAMOLE-601
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-601
> Project: Guacamole
> Issue Type: Bug
> Components: VNC
>Affects Versions: 0.9.14
>Reporter: KokHooi Chew
>Priority: Minor
> Fix For: 1.0.0
>
> Attachments: syslog.3
>
>
> While viewing, try to restart the VNC server, unable to reconnect back to the
> VNC then, continuously getting segfault until restart guacamole server in
> order to solve it
> {code:none}
> Jul 27 21:05:08 TDF-Jasper guacd[1354]: Creating new client for protocol "vnc"
> Jul 27 21:05:08 TDF-Jasper guacd[1354]: Connection ID is
> "$3c02e097-a5a4-4a78-9d75-72531046877d"
> Jul 27 21:05:09 TDF-Jasper guacd[6539]: Cursor rendering: local
> Jul 27 21:05:09 TDF-Jasper guacd[6539]: User
> "@ecba697e-1195-41d4-9b99-71525c58952e" joined connection
> "$3c02e097-a5a4-4a78-9d75-72531046877d" (1 users now present)
> Jul 27 21:05:14 TDF-Jasper guacd[6539]: Connected to VNC repeater, using
> protocol version 0.0
> Jul 27 21:05:15 TDF-Jasper guacd[6539]: VNC server supports protocol version
> 3.8 (viewer 3.8)
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: We have 1 security types to read
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 0) Received security type 1
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: Selecting security type 1 (0/1 in the
> list)
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: Selected Security Scheme 1
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: No authentication needed
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: VNC authentication succeeded
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: Desktop name "Remote control"
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: Connected to VNC server, using
> protocol version 3.8
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: VNC server default format:
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 32 bits per pixel.
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: Least significant byte first in each
> pixel.
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: TRUE colour: max red 255 green 255
> blue 255, shift red 0 green 8 blue 16
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: client2server supported messages (bit
> flags)
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 00: 00ff 0081 -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 08: -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 10: -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 18: -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: server2client supported messages (bit
> flags)
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 00: 001f 0080 -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 08: -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 10: -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 18: -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: Connected to Server "unknown
> (LibVNCServer 0.9.11)"
> Jul 27 21:05:38 TDF-Jasper guacd[1354]: Creating new client for protocol "vnc"
> Jul 27 21:05:38 TDF-Jasper guacd[1354]: Connection ID is
> "$f7648af9-9126-4e69-a6ef-a8b9ac3b7fc3"
> Jul 27 21:05:38 TDF-Jasper guacd[6573]: Cursor rendering: local
> Jul 27 21:05:38 TDF-Jasper guacd[6573]: User
> "@1446482b-becb-495a-9763-a151f6d6079f" joined connection
> "$f7648af9-9126-4e69-a6ef-a8b9ac3b7fc3" (1 users now present)
> Jul 27 21:05:38 TDF-Jasper guacd[6573]: Connected to VNC repeater, using
> protocol version 0.0
> Jul 27 21:05:39 TDF-Jasper guacd[6573]: VNC server closed connection
> Jul 27 21:05:39 TDF-Jasper guacd[6573]: Unable to connect to VNC server.
> Jul 27 21:05:39 TDF-Jasper kernel: [18008.137457] show_signal_msg: 42
> callbacks suppressed
> Jul 27 21:05:39 TDF-Jasper kernel: [18008.137462] guacd[6576]: segfault at 10
> ip 7f3cdcc64f32 sp 7f3cdde71d10 error 4 in
> libguac-client-vnc.so.0.0.0[7f3cdcc5c000+14000]
> Jul 27 21:05:40 TDF-Jasper guacd[6539]: User is not responding.
> Jul 27 21:05:40 TDF-Jasper guacd[6539]: User
> "@ecba697e-1195-41d4-9b99-71525c58952e" disconnected (0 users remain)
> Jul 27 21:05:40 TDF-Jasper guacd[6539]: Last user of connection
> "$3c02e097-a5a4-4a78-9d75-72531046877d" disconnected
> Jul 27 21:05:40 TDF-Jasper guacd[1354]: Connection
> "$f7648af9-9126-4e69-a6ef-a8b9ac3b7fc3" removed.
> Jul 27 21:07:19 TDF-Jasper guacd[1354]: Creating new client for protocol "vnc"
> Jul 27 21:07:19 TDF-Jasper guacd[1354]: Connection ID is
> "$ff22eac4-80d1-4225-a87f-73537e7b569d"
> Jul 27 21:07:19 TDF-Jasper
[jira] [Commented] (GUACAMOLE-601) VNC segfault when VNC server restarted
[
https://issues.apache.org/jira/browse/GUACAMOLE-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16735325#comment-16735325
]
Michael Jumper commented on GUACAMOLE-601:
--
If this is fixed on master and staging/1.0.0, I suspect this is another
instance of GUACAMOLE-424.
Though the title and description of GUACAMOLE-424 specifically mention
incorrect VNC passwords, the underlying problem was much more generic and would
have affected any VNC connection that terminates early enough and abnormally.
> VNC segfault when VNC server restarted
> --
>
> Key: GUACAMOLE-601
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-601
> Project: Guacamole
> Issue Type: Bug
> Components: VNC
>Affects Versions: 0.9.14
>Reporter: KokHooi Chew
>Priority: Minor
> Fix For: 1.0.0
>
> Attachments: syslog.3
>
>
> While viewing, try to restart the VNC server, unable to reconnect back to the
> VNC then, continuously getting segfault until restart guacamole server in
> order to solve it
> {code:none}
> Jul 27 21:05:08 TDF-Jasper guacd[1354]: Creating new client for protocol "vnc"
> Jul 27 21:05:08 TDF-Jasper guacd[1354]: Connection ID is
> "$3c02e097-a5a4-4a78-9d75-72531046877d"
> Jul 27 21:05:09 TDF-Jasper guacd[6539]: Cursor rendering: local
> Jul 27 21:05:09 TDF-Jasper guacd[6539]: User
> "@ecba697e-1195-41d4-9b99-71525c58952e" joined connection
> "$3c02e097-a5a4-4a78-9d75-72531046877d" (1 users now present)
> Jul 27 21:05:14 TDF-Jasper guacd[6539]: Connected to VNC repeater, using
> protocol version 0.0
> Jul 27 21:05:15 TDF-Jasper guacd[6539]: VNC server supports protocol version
> 3.8 (viewer 3.8)
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: We have 1 security types to read
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 0) Received security type 1
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: Selecting security type 1 (0/1 in the
> list)
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: Selected Security Scheme 1
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: No authentication needed
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: VNC authentication succeeded
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: Desktop name "Remote control"
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: Connected to VNC server, using
> protocol version 3.8
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: VNC server default format:
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 32 bits per pixel.
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: Least significant byte first in each
> pixel.
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: TRUE colour: max red 255 green 255
> blue 255, shift red 0 green 8 blue 16
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: client2server supported messages (bit
> flags)
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 00: 00ff 0081 -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 08: -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 10: -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 18: -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: server2client supported messages (bit
> flags)
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 00: 001f 0080 -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 08: -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 10: -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: 18: -
>
> Jul 27 21:05:16 TDF-Jasper guacd[6539]: Connected to Server "unknown
> (LibVNCServer 0.9.11)"
> Jul 27 21:05:38 TDF-Jasper guacd[1354]: Creating new client for protocol "vnc"
> Jul 27 21:05:38 TDF-Jasper guacd[1354]: Connection ID is
> "$f7648af9-9126-4e69-a6ef-a8b9ac3b7fc3"
> Jul 27 21:05:38 TDF-Jasper guacd[6573]: Cursor rendering: local
> Jul 27 21:05:38 TDF-Jasper guacd[6573]: User
> "@1446482b-becb-495a-9763-a151f6d6079f" joined connection
> "$f7648af9-9126-4e69-a6ef-a8b9ac3b7fc3" (1 users now present)
> Jul 27 21:05:38 TDF-Jasper guacd[6573]: Connected to VNC repeater, using
> protocol version 0.0
> Jul 27 21:05:39 TDF-Jasper guacd[6573]: VNC server closed connection
> Jul 27 21:05:39 TDF-Jasper guacd[6573]: Unable to connect to VNC server.
> Jul 27 21:05:39 TDF-Jasper kernel: [18008.137457] show_signal_msg: 42
> callbacks suppressed
> Jul 27 21:05:39 TDF-Jasper kernel: [18008.137462] guacd[6576]: segfault at 10
> ip 7f3cdcc64f32 sp 7f3cdde71d10 error 4 in
> libguac-client-vnc.so.0.0.0[7f3cdcc5c000+14000]
> Jul 27 21:05:40 TDF-Jasper guacd[6539]: User is not responding.
> Jul 27 21:05:40 TDF-Jasper guacd[6539]: User
> "@ecba697e-1195-41d4-9b99-71525c58952e" disconnected (0 users remain)
> Jul 27 21:05:40 TDF-Jasper guacd[6539]: Last user of connection
>
[jira] [Updated] (GUACAMOLE-688) Docker Version ldap-user-search-filter is missing
[ https://issues.apache.org/jira/browse/GUACAMOLE-688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-688: - Remaining Estimate: (was: 20m) Original Estimate: (was: 20m) > Docker Version ldap-user-search-filter is missing > - > > Key: GUACAMOLE-688 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-688 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-docker >Affects Versions: 0.9.14 >Reporter: Harald Fielker >Priority: Minor > > "ldap-user-search-filter" is missing as Enviormnent Variable in > > [https://github.com/apache/guacamole-client/blob/78f1ae1b4eac25501d532ddee94fd1d8588e56dc/guacamole-docker/bin/start.sh] > > Please add this to the section in the start.sh file > set_optional_property \ > "ldap-user-search-filter" \ > "$LDAP_USER_SEARCH_FILTER" > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-687) LDAP Failure in 1.0.0-RC1 (official docker hub image guacamole/guacamole)
[
https://issues.apache.org/jira/browse/GUACAMOLE-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734781#comment-16734781
]
Michael Jumper commented on GUACAMOLE-687:
--
Testing against both {{guacamole/guacamole:0.9.14}} and
{{guacamole/guacamole:1.0.0-RC1}} specifying the following:
* {{LDAP_HOSTNAME}} (in my case the IP address of the Docker host)
* An {{LDAP_USER_BASE_DN}} which does not contain the account used for
{{LDAP_SEARCH_BIND_DN}}
* An {{LDAP_USERNAME_ATTRIBUTE}} which is different from the default "uid" (I
used same as your case: "cn")
* An {{LDAP_SEARCH_BIND_DN}} which is outside the {{LDAP_USER_BASE_DN}}
* {{LDAP_SEARCH_BIND_PASSWORD}} containing the password of the account
specified by {{LDAP_SEARCH_BIND_DN}}
I am unable to reproduce the problem described. Logins for all users in the
directory work as expected with both images. No errors in the logs.
> LDAP Failure in 1.0.0-RC1 (official docker hub image guacamole/guacamole)
> -
>
> Key: GUACAMOLE-687
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-687
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-auth-ldap, guacamole-docker
>Affects Versions: 1.0.0
>Reporter: Joshua Landon Key
>Priority: Major
>
> I currently have a system up and running in docker with the following yml
> compose file. I was planning on upgrading to the 1.0.0-RC1 image which was
> made available less than a month ago on the docker hub to I used the
> appropriate tags :1.0.0-RC1 instead of the :latest which is still using
> 0.9.14. The problem that I am encountering is that given the appropriate
> changes to the docker system I am presented with a running instance that
> seems to work in all areas but one. LDAP Authentication fails with a message
> indicating that it can not query the ldap system. when examining the network
> calls through the browser dev tools I notice that it is the call to
> /api/tokens which is failing and returning this failure message via a json
> result. I want to note that the file below (with the *** replaced with the
> appropriate values) works in version 0.9.14 but fails in 1.0.0-RC1. I have
> also confirmed that by simply using the :latest and not the :1.0.0-RC1 that
> the issue resolves itself (the DB has to be recreated but that is due to
> schema differences).
> {code:none|title=Docker Compose YML}
> version: '3.0'
> services:
> guacd:
> image: guacamole/guacd
> volumes:
> - drive:/drive:rw
> - record:/record:rw
> deploy:
> replicas: 1
> postgres:
> environment:
> POSTGRES_DB: **
> POSTGRES_PASSWORD: **
> POSTGRES_USER: **
> image: postgres
> volumes:
> - /usr/share/guac/init:/docker-entrypoint-initdb.d:ro
> deploy:
> replicas: 1
> guacamole:
> depends_on:
> - guacd
> - postgres
> environment:
> GUACD_HOSTNAME: guacd
> POSTGRES_DATABASE: **
> POSTGRES_HOSTNAME: postgres
> POSTGRES_PASSWORD: **
> POSTGRES_USER: **
> EXTENSIONS: auth-ldap
> LDAP_HOSTNAME: ldap.**.com
> LDAP_USER_BASE_DN: OU=Employee,OU=Users,OU=Accounts,DC=**,DC=com
> LDAP_USERNAME_ATTRIBUTE: cn
> LDAP_SEARCH_BIND_DN:
> CN=**,OU=Service,OU=Users,OU=Accounts,DC=**,DC=com
> LDAP_SEARCH_BIND_PASSWORD: **
> image: guacamole/guacamole
> deploy:
> replicas: 1
> volumes:
> drive:
> driver: local
> record:
> driver: local
> data:
> driver: local
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-687) LDAP Failure in 1.0.0-RC1 (official docker hub image guacamole/guacamole)
[
https://issues.apache.org/jira/browse/GUACAMOLE-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734660#comment-16734660
]
Michael Jumper commented on GUACAMOLE-687:
--
{quote}
I was planning on upgrading to the 1.0.0-RC1 image which was made available
less than a month ago on the docker hub to I used the appropriate tags
:1.0.0-RC1 instead of the :latest which is still using 0.9.14.
{quote}
[~KEYJ63], many thanks for testing this, but please keep in mind that this
really shouldn't be considered an "upgrade" until the release is actually out.
As a release candidate, things can be rolled back and changed at any time,
including in a way that breaks compatibility. Anything tagged as a release
candidate is still development code until promoted to release.
{quote}
... LDAP Authentication fails with a message indicating that it can not query
the ldap system. ...
{quote}
As noted by [~nick.couch...@yahoo.com], please provide the error message(s) you
refer to in your description. We really need the actual log messages.
{quote}
{code:none}
...
EXTENSIONS: auth-ldap
...
{code}
{quote}
What's this {{EXTENSIONS}} environment variable about? The Guacamole Docker
images do not use any such variable.
> LDAP Failure in 1.0.0-RC1 (official docker hub image guacamole/guacamole)
> -
>
> Key: GUACAMOLE-687
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-687
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-auth-ldap, guacamole-docker
>Affects Versions: 1.0.0
>Reporter: Joshua Landon Key
>Priority: Major
>
> I currently have a system up and running in docker with the following yml
> compose file. I was planning on upgrading to the 1.0.0-RC1 image which was
> made available less than a month ago on the docker hub to I used the
> appropriate tags :1.0.0-RC1 instead of the :latest which is still using
> 0.9.14. The problem that I am encountering is that given the appropriate
> changes to the docker system I am presented with a running instance that
> seems to work in all areas but one. LDAP Authentication fails with a message
> indicating that it can not query the ldap system. when examining the network
> calls through the browser dev tools I notice that it is the call to
> /api/tokens which is failing and returning this failure message via a json
> result. I want to note that the file below (with the *** replaced with the
> appropriate values) works in version 0.9.14 but fails in 1.0.0-RC1. I have
> also confirmed that by simply using the :latest and not the :1.0.0-RC1 that
> the issue resolves itself (the DB has to be recreated but that is due to
> schema differences).
> {code:none|title=Docker Compose YML}
> version: '3.0'
> services:
> guacd:
> image: guacamole/guacd
> volumes:
> - drive:/drive:rw
> - record:/record:rw
> deploy:
> replicas: 1
> postgres:
> environment:
> POSTGRES_DB: **
> POSTGRES_PASSWORD: **
> POSTGRES_USER: **
> image: postgres
> volumes:
> - /usr/share/guac/init:/docker-entrypoint-initdb.d:ro
> deploy:
> replicas: 1
> guacamole:
> depends_on:
> - guacd
> - postgres
> environment:
> GUACD_HOSTNAME: guacd
> POSTGRES_DATABASE: **
> POSTGRES_HOSTNAME: postgres
> POSTGRES_PASSWORD: **
> POSTGRES_USER: **
> EXTENSIONS: auth-ldap
> LDAP_HOSTNAME: ldap.**.com
> LDAP_USER_BASE_DN: OU=Employee,OU=Users,OU=Accounts,DC=**,DC=com
> LDAP_USERNAME_ATTRIBUTE: cn
> LDAP_SEARCH_BIND_DN:
> CN=**,OU=Service,OU=Users,OU=Accounts,DC=**,DC=com
> LDAP_SEARCH_BIND_PASSWORD: **
> image: guacamole/guacamole
> deploy:
> replicas: 1
> volumes:
> drive:
> driver: local
> record:
> driver: local
> data:
> driver: local
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-687) LDAP Failure in 1.0.0-RC1 (official docker hub image guacamole/guacamole)
[
https://issues.apache.org/jira/browse/GUACAMOLE-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper updated GUACAMOLE-687:
-
Description:
I currently have a system up and running in docker with the following yml
compose file. I was planning on upgrading to the 1.0.0-RC1 image which was made
available less than a month ago on the docker hub to I used the appropriate
tags :1.0.0-RC1 instead of the :latest which is still using 0.9.14. The problem
that I am encountering is that given the appropriate changes to the docker
system I am presented with a running instance that seems to work in all areas
but one. LDAP Authentication fails with a message indicating that it can not
query the ldap system. when examining the network calls through the browser dev
tools I notice that it is the call to /api/tokens which is failing and
returning this failure message via a json result. I want to note that the file
below (with the *** replaced with the appropriate values) works in version
0.9.14 but fails in 1.0.0-RC1. I have also confirmed that by simply using the
:latest and not the :1.0.0-RC1 that the issue resolves itself (the DB has to be
recreated but that is due to schema differences).
{code:none|title=Docker Compose YML}
version: '3.0'
services:
guacd:
image: guacamole/guacd
volumes:
- drive:/drive:rw
- record:/record:rw
deploy:
replicas: 1
postgres:
environment:
POSTGRES_DB: **
POSTGRES_PASSWORD: **
POSTGRES_USER: **
image: postgres
volumes:
- /usr/share/guac/init:/docker-entrypoint-initdb.d:ro
deploy:
replicas: 1
guacamole:
depends_on:
- guacd
- postgres
environment:
GUACD_HOSTNAME: guacd
POSTGRES_DATABASE: **
POSTGRES_HOSTNAME: postgres
POSTGRES_PASSWORD: **
POSTGRES_USER: **
EXTENSIONS: auth-ldap
LDAP_HOSTNAME: ldap.**.com
LDAP_USER_BASE_DN: OU=Employee,OU=Users,OU=Accounts,DC=**,DC=com
LDAP_USERNAME_ATTRIBUTE: cn
LDAP_SEARCH_BIND_DN:
CN=**,OU=Service,OU=Users,OU=Accounts,DC=**,DC=com
LDAP_SEARCH_BIND_PASSWORD: **
image: guacamole/guacamole
deploy:
replicas: 1
volumes:
drive:
driver: local
record:
driver: local
data:
driver: local
{code}
was:
I currently have a system up and running in docker with the following yml
compose file. I was planning on upgrading to the 1.0.0-RC1 image which was made
available less than a month ago on the docker hub to I used the appropriate
tags :1.0.0-RC1 instead of the :latest which is still using 0.9.14. The problem
that I am encountering is that given the appropriate changes to the docker
system I am presented with a running instance that seems to work in all areas
but one. LDAP Authentication fails with a message indicating that it can not
query the ldap system. when examining the network calls through the browser dev
tools I notice that it is the call to /api/tokens which is failing and
returning this failure message via a json result. I want to note that the file
below (with the *** replaced with the appropriate values) works in version
0.9.14 but fails in 1.0.0-RC1. I have also confirmed that by simply using the
:latest and not the :1.0.0-RC1 that the issue resolves itself (the DB has to be
recreated but that is due to schema differences).
Docker Compose YML
---
version: '3.0'
services:
guacd:
image: guacamole/guacd
volumes:
- drive:/drive:rw
- record:/record:rw
deploy:
replicas: 1
postgres:
environment:
POSTGRES_DB: **
POSTGRES_PASSWORD: **
POSTGRES_USER: **
image: postgres
volumes:
- /usr/share/guac/init:/docker-entrypoint-initdb.d:ro
deploy:
replicas: 1
guacamole:
depends_on:
- guacd
- postgres
environment:
GUACD_HOSTNAME: guacd
POSTGRES_DATABASE: **
POSTGRES_HOSTNAME: postgres
POSTGRES_PASSWORD: **
POSTGRES_USER: **
EXTENSIONS: auth-ldap
LDAP_HOSTNAME: ldap.**.com
LDAP_USER_BASE_DN: OU=Employee,OU=Users,OU=Accounts,DC=**,DC=com
LDAP_USERNAME_ATTRIBUTE: cn
LDAP_SEARCH_BIND_DN:
CN=**,OU=Service,OU=Users,OU=Accounts,DC=**,DC=com
LDAP_SEARCH_BIND_PASSWORD: **
image: guacamole/guacamole
deploy:
replicas: 1
volumes:
drive:
driver: local
record:
driver: local
data:
driver: local
> LDAP Failure in 1.0.0-RC1 (official docker hub image guacamole/guacamole)
> -
>
> Key: GUACAMOLE-687
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-687
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-auth-ldap
>Affects Versions: 1.0.0
> Environment: docker
>Reporter: Joshua Landon Key
>Priority: Major
> Labels: LDAP, docker
> Fix For: 1.0.0
>
>
> I currently have a system up and running in docker with the following yml
> compose file. I was planning on upgrading to the
[jira] [Updated] (GUACAMOLE-687) LDAP Failure in 1.0.0-RC1 (official docker hub image guacamole/guacamole)
[
https://issues.apache.org/jira/browse/GUACAMOLE-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper updated GUACAMOLE-687:
-
Environment: (was: docker)
> LDAP Failure in 1.0.0-RC1 (official docker hub image guacamole/guacamole)
> -
>
> Key: GUACAMOLE-687
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-687
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-auth-ldap
>Affects Versions: 1.0.0
>Reporter: Joshua Landon Key
>Priority: Major
> Labels: LDAP, docker
> Fix For: 1.0.0
>
>
> I currently have a system up and running in docker with the following yml
> compose file. I was planning on upgrading to the 1.0.0-RC1 image which was
> made available less than a month ago on the docker hub to I used the
> appropriate tags :1.0.0-RC1 instead of the :latest which is still using
> 0.9.14. The problem that I am encountering is that given the appropriate
> changes to the docker system I am presented with a running instance that
> seems to work in all areas but one. LDAP Authentication fails with a message
> indicating that it can not query the ldap system. when examining the network
> calls through the browser dev tools I notice that it is the call to
> /api/tokens which is failing and returning this failure message via a json
> result. I want to note that the file below (with the *** replaced with the
> appropriate values) works in version 0.9.14 but fails in 1.0.0-RC1. I have
> also confirmed that by simply using the :latest and not the :1.0.0-RC1 that
> the issue resolves itself (the DB has to be recreated but that is due to
> schema differences).
> {code:none|title=Docker Compose YML}
> version: '3.0'
> services:
> guacd:
> image: guacamole/guacd
> volumes:
> - drive:/drive:rw
> - record:/record:rw
> deploy:
> replicas: 1
> postgres:
> environment:
> POSTGRES_DB: **
> POSTGRES_PASSWORD: **
> POSTGRES_USER: **
> image: postgres
> volumes:
> - /usr/share/guac/init:/docker-entrypoint-initdb.d:ro
> deploy:
> replicas: 1
> guacamole:
> depends_on:
> - guacd
> - postgres
> environment:
> GUACD_HOSTNAME: guacd
> POSTGRES_DATABASE: **
> POSTGRES_HOSTNAME: postgres
> POSTGRES_PASSWORD: **
> POSTGRES_USER: **
> EXTENSIONS: auth-ldap
> LDAP_HOSTNAME: ldap.**.com
> LDAP_USER_BASE_DN: OU=Employee,OU=Users,OU=Accounts,DC=**,DC=com
> LDAP_USERNAME_ATTRIBUTE: cn
> LDAP_SEARCH_BIND_DN:
> CN=**,OU=Service,OU=Users,OU=Accounts,DC=**,DC=com
> LDAP_SEARCH_BIND_PASSWORD: **
> image: guacamole/guacamole
> deploy:
> replicas: 1
> volumes:
> drive:
> driver: local
> record:
> driver: local
> data:
> driver: local
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-687) LDAP Failure in 1.0.0-RC1 (official docker hub image guacamole/guacamole)
[
https://issues.apache.org/jira/browse/GUACAMOLE-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper updated GUACAMOLE-687:
-
Flags: (was: Important)
> LDAP Failure in 1.0.0-RC1 (official docker hub image guacamole/guacamole)
> -
>
> Key: GUACAMOLE-687
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-687
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-auth-ldap
>Affects Versions: 1.0.0
>Reporter: Joshua Landon Key
>Priority: Major
> Labels: LDAP, docker
> Fix For: 1.0.0
>
>
> I currently have a system up and running in docker with the following yml
> compose file. I was planning on upgrading to the 1.0.0-RC1 image which was
> made available less than a month ago on the docker hub to I used the
> appropriate tags :1.0.0-RC1 instead of the :latest which is still using
> 0.9.14. The problem that I am encountering is that given the appropriate
> changes to the docker system I am presented with a running instance that
> seems to work in all areas but one. LDAP Authentication fails with a message
> indicating that it can not query the ldap system. when examining the network
> calls through the browser dev tools I notice that it is the call to
> /api/tokens which is failing and returning this failure message via a json
> result. I want to note that the file below (with the *** replaced with the
> appropriate values) works in version 0.9.14 but fails in 1.0.0-RC1. I have
> also confirmed that by simply using the :latest and not the :1.0.0-RC1 that
> the issue resolves itself (the DB has to be recreated but that is due to
> schema differences).
> {code:none|title=Docker Compose YML}
> version: '3.0'
> services:
> guacd:
> image: guacamole/guacd
> volumes:
> - drive:/drive:rw
> - record:/record:rw
> deploy:
> replicas: 1
> postgres:
> environment:
> POSTGRES_DB: **
> POSTGRES_PASSWORD: **
> POSTGRES_USER: **
> image: postgres
> volumes:
> - /usr/share/guac/init:/docker-entrypoint-initdb.d:ro
> deploy:
> replicas: 1
> guacamole:
> depends_on:
> - guacd
> - postgres
> environment:
> GUACD_HOSTNAME: guacd
> POSTGRES_DATABASE: **
> POSTGRES_HOSTNAME: postgres
> POSTGRES_PASSWORD: **
> POSTGRES_USER: **
> EXTENSIONS: auth-ldap
> LDAP_HOSTNAME: ldap.**.com
> LDAP_USER_BASE_DN: OU=Employee,OU=Users,OU=Accounts,DC=**,DC=com
> LDAP_USERNAME_ATTRIBUTE: cn
> LDAP_SEARCH_BIND_DN:
> CN=**,OU=Service,OU=Users,OU=Accounts,DC=**,DC=com
> LDAP_SEARCH_BIND_PASSWORD: **
> image: guacamole/guacamole
> deploy:
> replicas: 1
> volumes:
> drive:
> driver: local
> record:
> driver: local
> data:
> driver: local
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-687) LDAP Failure in 1.0.0-RC1 (official docker hub image guacamole/guacamole)
[
https://issues.apache.org/jira/browse/GUACAMOLE-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper updated GUACAMOLE-687:
-
Labels: (was: LDAP docker)
> LDAP Failure in 1.0.0-RC1 (official docker hub image guacamole/guacamole)
> -
>
> Key: GUACAMOLE-687
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-687
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-auth-ldap, guacamole-docker
>Affects Versions: 1.0.0
>Reporter: Joshua Landon Key
>Priority: Major
> Fix For: 1.0.0
>
>
> I currently have a system up and running in docker with the following yml
> compose file. I was planning on upgrading to the 1.0.0-RC1 image which was
> made available less than a month ago on the docker hub to I used the
> appropriate tags :1.0.0-RC1 instead of the :latest which is still using
> 0.9.14. The problem that I am encountering is that given the appropriate
> changes to the docker system I am presented with a running instance that
> seems to work in all areas but one. LDAP Authentication fails with a message
> indicating that it can not query the ldap system. when examining the network
> calls through the browser dev tools I notice that it is the call to
> /api/tokens which is failing and returning this failure message via a json
> result. I want to note that the file below (with the *** replaced with the
> appropriate values) works in version 0.9.14 but fails in 1.0.0-RC1. I have
> also confirmed that by simply using the :latest and not the :1.0.0-RC1 that
> the issue resolves itself (the DB has to be recreated but that is due to
> schema differences).
> {code:none|title=Docker Compose YML}
> version: '3.0'
> services:
> guacd:
> image: guacamole/guacd
> volumes:
> - drive:/drive:rw
> - record:/record:rw
> deploy:
> replicas: 1
> postgres:
> environment:
> POSTGRES_DB: **
> POSTGRES_PASSWORD: **
> POSTGRES_USER: **
> image: postgres
> volumes:
> - /usr/share/guac/init:/docker-entrypoint-initdb.d:ro
> deploy:
> replicas: 1
> guacamole:
> depends_on:
> - guacd
> - postgres
> environment:
> GUACD_HOSTNAME: guacd
> POSTGRES_DATABASE: **
> POSTGRES_HOSTNAME: postgres
> POSTGRES_PASSWORD: **
> POSTGRES_USER: **
> EXTENSIONS: auth-ldap
> LDAP_HOSTNAME: ldap.**.com
> LDAP_USER_BASE_DN: OU=Employee,OU=Users,OU=Accounts,DC=**,DC=com
> LDAP_USERNAME_ATTRIBUTE: cn
> LDAP_SEARCH_BIND_DN:
> CN=**,OU=Service,OU=Users,OU=Accounts,DC=**,DC=com
> LDAP_SEARCH_BIND_PASSWORD: **
> image: guacamole/guacamole
> deploy:
> replicas: 1
> volumes:
> drive:
> driver: local
> record:
> driver: local
> data:
> driver: local
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-687) LDAP Failure in 1.0.0-RC1 (official docker hub image guacamole/guacamole)
[
https://issues.apache.org/jira/browse/GUACAMOLE-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper updated GUACAMOLE-687:
-
Fix Version/s: (was: 1.0.0)
> LDAP Failure in 1.0.0-RC1 (official docker hub image guacamole/guacamole)
> -
>
> Key: GUACAMOLE-687
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-687
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-auth-ldap, guacamole-docker
>Affects Versions: 1.0.0
>Reporter: Joshua Landon Key
>Priority: Major
>
> I currently have a system up and running in docker with the following yml
> compose file. I was planning on upgrading to the 1.0.0-RC1 image which was
> made available less than a month ago on the docker hub to I used the
> appropriate tags :1.0.0-RC1 instead of the :latest which is still using
> 0.9.14. The problem that I am encountering is that given the appropriate
> changes to the docker system I am presented with a running instance that
> seems to work in all areas but one. LDAP Authentication fails with a message
> indicating that it can not query the ldap system. when examining the network
> calls through the browser dev tools I notice that it is the call to
> /api/tokens which is failing and returning this failure message via a json
> result. I want to note that the file below (with the *** replaced with the
> appropriate values) works in version 0.9.14 but fails in 1.0.0-RC1. I have
> also confirmed that by simply using the :latest and not the :1.0.0-RC1 that
> the issue resolves itself (the DB has to be recreated but that is due to
> schema differences).
> {code:none|title=Docker Compose YML}
> version: '3.0'
> services:
> guacd:
> image: guacamole/guacd
> volumes:
> - drive:/drive:rw
> - record:/record:rw
> deploy:
> replicas: 1
> postgres:
> environment:
> POSTGRES_DB: **
> POSTGRES_PASSWORD: **
> POSTGRES_USER: **
> image: postgres
> volumes:
> - /usr/share/guac/init:/docker-entrypoint-initdb.d:ro
> deploy:
> replicas: 1
> guacamole:
> depends_on:
> - guacd
> - postgres
> environment:
> GUACD_HOSTNAME: guacd
> POSTGRES_DATABASE: **
> POSTGRES_HOSTNAME: postgres
> POSTGRES_PASSWORD: **
> POSTGRES_USER: **
> EXTENSIONS: auth-ldap
> LDAP_HOSTNAME: ldap.**.com
> LDAP_USER_BASE_DN: OU=Employee,OU=Users,OU=Accounts,DC=**,DC=com
> LDAP_USERNAME_ATTRIBUTE: cn
> LDAP_SEARCH_BIND_DN:
> CN=**,OU=Service,OU=Users,OU=Accounts,DC=**,DC=com
> LDAP_SEARCH_BIND_PASSWORD: **
> image: guacamole/guacamole
> deploy:
> replicas: 1
> volumes:
> drive:
> driver: local
> record:
> driver: local
> data:
> driver: local
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-687) LDAP Failure in 1.0.0-RC1 (official docker hub image guacamole/guacamole)
[
https://issues.apache.org/jira/browse/GUACAMOLE-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper updated GUACAMOLE-687:
-
Component/s: guacamole-docker
> LDAP Failure in 1.0.0-RC1 (official docker hub image guacamole/guacamole)
> -
>
> Key: GUACAMOLE-687
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-687
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-auth-ldap, guacamole-docker
>Affects Versions: 1.0.0
>Reporter: Joshua Landon Key
>Priority: Major
> Labels: LDAP, docker
> Fix For: 1.0.0
>
>
> I currently have a system up and running in docker with the following yml
> compose file. I was planning on upgrading to the 1.0.0-RC1 image which was
> made available less than a month ago on the docker hub to I used the
> appropriate tags :1.0.0-RC1 instead of the :latest which is still using
> 0.9.14. The problem that I am encountering is that given the appropriate
> changes to the docker system I am presented with a running instance that
> seems to work in all areas but one. LDAP Authentication fails with a message
> indicating that it can not query the ldap system. when examining the network
> calls through the browser dev tools I notice that it is the call to
> /api/tokens which is failing and returning this failure message via a json
> result. I want to note that the file below (with the *** replaced with the
> appropriate values) works in version 0.9.14 but fails in 1.0.0-RC1. I have
> also confirmed that by simply using the :latest and not the :1.0.0-RC1 that
> the issue resolves itself (the DB has to be recreated but that is due to
> schema differences).
> {code:none|title=Docker Compose YML}
> version: '3.0'
> services:
> guacd:
> image: guacamole/guacd
> volumes:
> - drive:/drive:rw
> - record:/record:rw
> deploy:
> replicas: 1
> postgres:
> environment:
> POSTGRES_DB: **
> POSTGRES_PASSWORD: **
> POSTGRES_USER: **
> image: postgres
> volumes:
> - /usr/share/guac/init:/docker-entrypoint-initdb.d:ro
> deploy:
> replicas: 1
> guacamole:
> depends_on:
> - guacd
> - postgres
> environment:
> GUACD_HOSTNAME: guacd
> POSTGRES_DATABASE: **
> POSTGRES_HOSTNAME: postgres
> POSTGRES_PASSWORD: **
> POSTGRES_USER: **
> EXTENSIONS: auth-ldap
> LDAP_HOSTNAME: ldap.**.com
> LDAP_USER_BASE_DN: OU=Employee,OU=Users,OU=Accounts,DC=**,DC=com
> LDAP_USERNAME_ATTRIBUTE: cn
> LDAP_SEARCH_BIND_DN:
> CN=**,OU=Service,OU=Users,OU=Accounts,DC=**,DC=com
> LDAP_SEARCH_BIND_PASSWORD: **
> image: guacamole/guacamole
> deploy:
> replicas: 1
> volumes:
> drive:
> driver: local
> record:
> driver: local
> data:
> driver: local
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GUACAMOLE-686) HTTP Header Auth ignores LDAP configuration
[ https://issues.apache.org/jira/browse/GUACAMOLE-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper closed GUACAMOLE-686. Resolution: Not A Bug > HTTP Header Auth ignores LDAP configuration > --- > > Key: GUACAMOLE-686 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-686 > Project: Guacamole > Issue Type: Bug >Reporter: zach >Priority: Minor > > My guacamole server uses LDAP and works when logging in using the web portal. > I put a single-sign-on server in front of it which authenticates the users > for me, and then forwards the user to guacamole using HTTP-Header-Auth. When > this header auth successfully logs in, no connections are visible, and no > lookups are performed against my LDAP server. > How do I tell guacamole to use HTTP-Header-Auth for the login, and then > perform LDAP queries to discover connections available to the logged-in user? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (GUACAMOLE-686) HTTP Header Auth ignores LDAP configuration
[ https://issues.apache.org/jira/browse/GUACAMOLE-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper reopened GUACAMOLE-686: -- > HTTP Header Auth ignores LDAP configuration > --- > > Key: GUACAMOLE-686 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-686 > Project: Guacamole > Issue Type: Bug >Reporter: zach >Priority: Minor > > My guacamole server uses LDAP and works when logging in using the web portal. > I put a single-sign-on server in front of it which authenticates the users > for me, and then forwards the user to guacamole using HTTP-Header-Auth. When > this header auth successfully logs in, no connections are visible, and no > lookups are performed against my LDAP server. > How do I tell guacamole to use HTTP-Header-Auth for the login, and then > perform LDAP queries to discover connections available to the logged-in user? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-681) Color palette OSC sequence crashing SSH
[
https://issues.apache.org/jira/browse/GUACAMOLE-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16728460#comment-16728460
]
Michael Jumper commented on GUACAMOLE-681:
--
I believe it is. Assuming the bug is [what I think it
is|https://issues.apache.org/jira/browse/GUACAMOLE-681?focusedCommentId=16722420=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16722420],
the relevant changes which fix the issue were part of GUACAMOLE-470 which is
indeed on staging/1.0.0.
[~Patricol] - please let us know if you can reproduce this against the
staging/1.0.0 branch. If not, we can safely close this issue as fixed in 1.0.0
by GUACAMOLE-470.
> Color palette OSC sequence crashing SSH
> ---
>
> Key: GUACAMOLE-681
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-681
> Project: Guacamole
> Issue Type: Bug
> Components: SSH
>Affects Versions: 0.9.14
> Environment: Newest docker versions of guacd and guacamole, running
> on Unraid. Client is connecting from Chromium on Arch Linux.
>Reporter: Patrick Collins
>Priority: Critical
>
> Based on
> [this|https://issues.apache.org/jira/projects/GUACAMOLE/issues/GUACAMOLE-277]
> issue, it seems Guacamole is supposed to work with Linux console codes.
> I'm getting reliable crashes when printing certain console codes in a
> Guacamole SSH session; notably ones printed by .bashrc in [some
> configurations|https://github.com/dylanaraps/pywal].
> When printed directly on the device, (whether on a tty or a terminal
> emulator,) the codes work.
> When printed in Guacamole, they immediately crash the session; prompting
> reconnection.
> This command is enough to crash the session:
> {code:java}
> echo 1b5d343b0a | xxd -r -p{code}
> (It converts some hex to 'ESC []4;' and prints it.)
>
> Apologies if the priority of this issue is inappropriate; I based it off the
> "crashes" criterion; but I'm not certain to what extent the program has to
> crash to qualify.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GUACAMOLE-682) Add option to build client docker with RADIUS support
[ https://issues.apache.org/jira/browse/GUACAMOLE-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper resolved GUACAMOLE-682. -- Resolution: Done Fix Version/s: 2.0.0 > Add option to build client docker with RADIUS support > - > > Key: GUACAMOLE-682 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-682 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-docker >Affects Versions: 1.0.0 >Reporter: Jörn Lentes >Priority: Minor > Fix For: 2.0.0 > > > To have RADIUS support available in guacamole client docker image currently > manual modification of build script and start script are required. > The build script needs activate the maven profile lgpl-extensions and copy > the RADIUS extention into the destination diractory > The start script needs to link the RADIUS jar file to GUACAMOLE_HOME and pass > RADIUS environment variables into guacamole properties. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-681) Color palette OSC sequence crashing SSH
[
https://issues.apache.org/jira/browse/GUACAMOLE-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16727004#comment-16727004
]
Michael Jumper commented on GUACAMOLE-681:
--
The session is not hanging - the terminal emulator is waiting for the
incomplete OSC sequence to be completed. From the "console_codes" man page:
{code:none}
... These are a few of the OSC control sequences recognized by xterm(1):
ESC ] 0 ; txt STSet icon name and window title to txt.
ESC ] 1 ; txt STSet icon name to txt.
ESC ] 2 ; txt STSet window title to txt.
ESC ] 4 ; num; txt ST Set ANSI color num to txt.
...
{code}
That last sequence there, {{ESC ] 4 ; ...}} is what is sent by the "1b5d343b"
part of that hex sequence. The final 0x0A in the sequence noted above would be
interpreted as the palette number. In the case of Guacamole's terminal
emulator, that non-numeric character would just be ignored and the terminal
emulator would continue to wait for the rest of the sequence. It looks like
other terminal emulators may just bail out at that non-numeric character. I'm
not sure whether either behavior is actually defined/standardized.
> Color palette OSC sequence crashing SSH
> ---
>
> Key: GUACAMOLE-681
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-681
> Project: Guacamole
> Issue Type: Bug
> Components: SSH
>Affects Versions: 0.9.14
> Environment: Newest docker versions of guacd and guacamole, running
> on Unraid. Client is connecting from Chromium on Arch Linux.
>Reporter: Patrick Collins
>Priority: Critical
>
> Based on
> [this|https://issues.apache.org/jira/projects/GUACAMOLE/issues/GUACAMOLE-277]
> issue, it seems Guacamole is supposed to work with Linux console codes.
> I'm getting reliable crashes when printing certain console codes in a
> Guacamole SSH session; notably ones printed by .bashrc in [some
> configurations|https://github.com/dylanaraps/pywal].
> When printed directly on the device, (whether on a tty or a terminal
> emulator,) the codes work.
> When printed in Guacamole, they immediately crash the session; prompting
> reconnection.
> This command is enough to crash the session:
> {code:java}
> echo 1b5d343b0a | xxd -r -p{code}
> (It converts some hex to 'ESC []4;' and prints it.)
>
> Apologies if the priority of this issue is inappropriate; I based it off the
> "crashes" criterion; but I'm not certain to what extent the program has to
> crash to qualify.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-682) Add option to build client docker with RADIUS support
[
https://issues.apache.org/jira/browse/GUACAMOLE-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16726993#comment-16726993
]
Michael Jumper commented on GUACAMOLE-682:
--
Removing 0.9.14 from affected versions as RADIUS was added for 1.0.0. There was
no RADIUS support in 0.9.14 or earlier. See GUACAMOLE-197.
{quote}
To have RADIUS support available in guacamole client docker image currently
manual modification of build script and start script are required.
{quote}
That's certainly one way to do it, but this is not required. The intended
mechanism for adding an extension and additional properties is through the
Docker image's special {{GUACAMOLE_HOME}} environment variable and a volume
mount:
http://guacamole.apache.org/doc/gug/guacamole-docker.html#guacamole-docker-guacamole-home
> Add option to build client docker with RADIUS support
> -
>
> Key: GUACAMOLE-682
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-682
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-docker
>Affects Versions: 1.0.0
>Reporter: Jörn Lentes
>Priority: Minor
>
> To have RADIUS support available in guacamole client docker image currently
> manual modification of build script and start script are required.
> The build script needs activate the maven profile lgpl-extensions and copy
> the RADIUS extention into the destination diractory
> The start script needs to link the RADIUS jar file to GUACAMOLE_HOME and pass
> RADIUS environment variables into guacamole properties.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-682) Add option to build client docker with RADIUS support
[ https://issues.apache.org/jira/browse/GUACAMOLE-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-682: - Component/s: (was: guacamole-client) (was: guacamole-auth-radius) > Add option to build client docker with RADIUS support > - > > Key: GUACAMOLE-682 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-682 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-docker >Affects Versions: 1.0.0 >Reporter: Jörn Lentes >Priority: Minor > > To have RADIUS support available in guacamole client docker image currently > manual modification of build script and start script are required. > The build script needs activate the maven profile lgpl-extensions and copy > the RADIUS extention into the destination diractory > The start script needs to link the RADIUS jar file to GUACAMOLE_HOME and pass > RADIUS environment variables into guacamole properties. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-682) Add option to build client docker with RADIUS support
[ https://issues.apache.org/jira/browse/GUACAMOLE-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-682: - Affects Version/s: (was: 0.9.14) > Add option to build client docker with RADIUS support > - > > Key: GUACAMOLE-682 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-682 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-docker >Affects Versions: 1.0.0 >Reporter: Jörn Lentes >Priority: Minor > > To have RADIUS support available in guacamole client docker image currently > manual modification of build script and start script are required. > The build script needs activate the maven profile lgpl-extensions and copy > the RADIUS extention into the destination diractory > The start script needs to link the RADIUS jar file to GUACAMOLE_HOME and pass > RADIUS environment variables into guacamole properties. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-681) Color palette OSC sequence crashing SSH
[
https://issues.apache.org/jira/browse/GUACAMOLE-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper updated GUACAMOLE-681:
-
Summary: Color palette OSC sequence crashing SSH (was: Console codes
crashing SSH)
> Color palette OSC sequence crashing SSH
> ---
>
> Key: GUACAMOLE-681
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-681
> Project: Guacamole
> Issue Type: Bug
> Components: SSH
>Affects Versions: 0.9.14
> Environment: Newest docker versions of guacd and guacamole, running
> on Unraid. Client is connecting from Chromium on Arch Linux.
>Reporter: Patrick Collins
>Priority: Critical
>
> Based on
> [this|https://issues.apache.org/jira/projects/GUACAMOLE/issues/GUACAMOLE-277]
> issue, it seems Guacamole is supposed to work with Linux console codes.
> I'm getting reliable crashes when printing certain console codes in a
> Guacamole SSH session; notably ones printed by .bashrc in [some
> configurations|https://github.com/dylanaraps/pywal].
> When printed directly on the device, (whether on a tty or a terminal
> emulator,) the codes work.
> When printed in Guacamole, they immediately crash the session; prompting
> reconnection.
> This command is enough to crash the session:
> {code:java}
> echo 1b5d343b0a | xxd -r -p{code}
> (It converts some hex to 'ESC []4;' and prints it.)
>
> Apologies if the priority of this issue is inappropriate; I based it off the
> "crashes" criterion; but I'm not certain to what extent the program has to
> crash to qualify.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-681) Console codes crashing SSH
[
https://issues.apache.org/jira/browse/GUACAMOLE-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16722420#comment-16722420
]
Michael Jumper commented on GUACAMOLE-681:
--
I'm able to reproduce what I think may be the same issue through a slightly
different sequence. The terminal emulator in 0.9.14 will segfault if you
attempt to use that particular OSC sequence to assign a named color that is not
defined. For example, the following will work just fine:
{code:none}
echo -en "\x1B]4;3;blue\x07"
{code}
whereas the following will result in the connection dying:
{code:none}
echo -en "\x1B]4;3;blarb\x07"
{code}
That particular bug was fixed by [~jimnchen] with commit
[03d9c51b5d3e15cac7148e8cc733af7ae8c9f6cc|https://github.com/apache/guacamole-server/commit/03d9c51b5d3e15cac7148e8cc733af7ae8c9f6cc]
for related changes for GUACAMOLE-470 and is part of the upcoming 1.0.0
release. If you can reliably reproduce this with 0.9.14, I suggest trying to
reproduce against the staging/1.0.0 branch and see if this still occurs.
> Console codes crashing SSH
> --
>
> Key: GUACAMOLE-681
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-681
> Project: Guacamole
> Issue Type: Bug
> Components: SSH
>Affects Versions: 0.9.14
> Environment: Newest docker versions of guacd and guacamole, running
> on Unraid. Client is connecting from Chromium on Arch Linux.
>Reporter: Patrick Collins
>Priority: Critical
>
> Based on
> [this|https://issues.apache.org/jira/projects/GUACAMOLE/issues/GUACAMOLE-277]
> issue, it seems Guacamole is supposed to work with Linux console codes.
> I'm getting reliable crashes when printing certain console codes in a
> Guacamole SSH session; notably ones printed by .bashrc in [some
> configurations|https://github.com/dylanaraps/pywal].
> When printed directly on the device, (whether on a tty or a terminal
> emulator,) the codes work.
> When printed in Guacamole, they immediately crash the session; prompting
> reconnection.
> This command is enough to crash the session:
> {code:java}
> echo 1b5d343b0a | xxd -r -p{code}
> (It converts some hex to 'ESC []4;' and prints it.)
>
> Apologies if the priority of this issue is inappropriate; I based it off the
> "crashes" criterion; but I'm not certain to what extent the program has to
> crash to qualify.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-681) Console codes crashing SSH
[
https://issues.apache.org/jira/browse/GUACAMOLE-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16722383#comment-16722383
]
Michael Jumper commented on GUACAMOLE-681:
--
[~Patricol], what Docker images specifically are you using? The latest is
"guacamole/guacd:0.9.14" and I'm not seeing this issue there, nor on local
builds of 0.9.14, master, or staging/1.0.0.
> Console codes crashing SSH
> --
>
> Key: GUACAMOLE-681
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-681
> Project: Guacamole
> Issue Type: Bug
> Components: SSH
>Affects Versions: 0.9.14
> Environment: Newest docker versions of guacd and guacamole, running
> on Unraid. Client is connecting from Chromium on Arch Linux.
>Reporter: Patrick Collins
>Priority: Critical
>
> Based on
> [this|https://issues.apache.org/jira/projects/GUACAMOLE/issues/GUACAMOLE-277]
> issue, it seems Guacamole is supposed to work with Linux console codes.
> I'm getting reliable crashes when printing certain console codes in a
> Guacamole SSH session; notably ones printed by .bashrc in [some
> configurations|https://github.com/dylanaraps/pywal].
> When printed directly on the device, (whether on a tty or a terminal
> emulator,) the codes work.
> When printed in Guacamole, they immediately crash the session; prompting
> reconnection.
> This command is enough to crash the session:
> {code:java}
> echo 1b5d343b0a | xxd -r -p{code}
> (It converts some hex to 'ESC []4;' and prints it.)
>
> Apologies if the priority of this issue is inappropriate; I based it off the
> "crashes" criterion; but I'm not certain to what extent the program has to
> crash to qualify.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-676) Update remote clipboard while menu is open
[ https://issues.apache.org/jira/browse/GUACAMOLE-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-676: - Issue Type: Improvement (was: Bug) > Update remote clipboard while menu is open > -- > > Key: GUACAMOLE-676 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-676 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Affects Versions: 0.9.14 > Environment: Ubuntu 16.04 > vnc4server 4.1.1+xorg4.3.0-37.3ubuntu2 >Reporter: Matt Travers >Priority: Minor > > When using the copy-and-paste feature, when text is entered into the sidebar > text area it is not copied into the remote clipboard until the sidebar is > closed. Only then can the text in the sidebar be pasted into the remote > environment. > It would be nice to be able to paste into the remote environment without > having to close the sidebar. Is it possible to get the remote clipboard > updated without having to press cntrl-alt-shift to close the sidebar? > The remote I am using is Ubuntu 16.04 with vnc4server running. > Thanks! > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-676) Update remote clipboard while menu is open
[ https://issues.apache.org/jira/browse/GUACAMOLE-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-676: - Summary: Update remote clipboard while menu is open (was: Update remote clipboard while sidebar is still open) > Update remote clipboard while menu is open > -- > > Key: GUACAMOLE-676 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-676 > Project: Guacamole > Issue Type: Bug > Components: guacamole >Affects Versions: 0.9.14 > Environment: Ubuntu 16.04 > vnc4server 4.1.1+xorg4.3.0-37.3ubuntu2 >Reporter: Matt Travers >Priority: Minor > > When using the copy-and-paste feature, when text is entered into the sidebar > text area it is not copied into the remote clipboard until the sidebar is > closed. Only then can the text in the sidebar be pasted into the remote > environment. > It would be nice to be able to paste into the remote environment without > having to close the sidebar. Is it possible to get the remote clipboard > updated without having to press cntrl-alt-shift to close the sidebar? > The remote I am using is Ubuntu 16.04 with vnc4server running. > Thanks! > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-676) Update remote clipboard while menu is open
[ https://issues.apache.org/jira/browse/GUACAMOLE-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-676: - Component/s: (was: guacamole-client) guacamole > Update remote clipboard while menu is open > -- > > Key: GUACAMOLE-676 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-676 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Affects Versions: 0.9.14 > Environment: Ubuntu 16.04 > vnc4server 4.1.1+xorg4.3.0-37.3ubuntu2 >Reporter: Matt Travers >Priority: Trivial > > When using the copy-and-paste feature, when text is entered into the sidebar > text area it is not copied into the remote clipboard until the sidebar is > closed. Only then can the text in the sidebar be pasted into the remote > environment. > It would be nice to be able to paste into the remote environment without > having to close the sidebar. Is it possible to get the remote clipboard > updated without having to press cntrl-alt-shift to close the sidebar? > The remote I am using is Ubuntu 16.04 with vnc4server running. > Thanks! > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-676) Update remote clipboard while menu is open
[ https://issues.apache.org/jira/browse/GUACAMOLE-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-676: - Priority: Trivial (was: Minor) > Update remote clipboard while menu is open > -- > > Key: GUACAMOLE-676 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-676 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Affects Versions: 0.9.14 > Environment: Ubuntu 16.04 > vnc4server 4.1.1+xorg4.3.0-37.3ubuntu2 >Reporter: Matt Travers >Priority: Trivial > > When using the copy-and-paste feature, when text is entered into the sidebar > text area it is not copied into the remote clipboard until the sidebar is > closed. Only then can the text in the sidebar be pasted into the remote > environment. > It would be nice to be able to paste into the remote environment without > having to close the sidebar. Is it possible to get the remote clipboard > updated without having to press cntrl-alt-shift to close the sidebar? > The remote I am using is Ubuntu 16.04 with vnc4server running. > Thanks! > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-676) Can't update remote clipboard while sidebar is still open.
[ https://issues.apache.org/jira/browse/GUACAMOLE-676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16722254#comment-16722254 ] Michael Jumper commented on GUACAMOLE-676: -- This is intentional behavior, not a bug. Updating the remote clipboard while the clipboard is being edited would result in O(N^2) data being sent over the course of the edit. For example, while typing "Hello" in the clipboard editor, the following clipboard updates would be sent: # H # He # Hel # Hell # Hello For small amounts of text, this is negligible, but if the content of the clipboard is already relatively large performance takes a noticeable hit. The user needs to take some action to indicate that they are no longer editing the clipboard and the current contents can be safely sent to the remote side. Currently, that action is closing the menu. I can imagine this being modified to including a certain amount of time elapsing since the last edit or mouse events within the display, though whether that actually works in practice will depend on how quickly the remote desktop responds to updated clipboard contents. If the remote desktop handles mouse interaction before finishing its update of the clipboard, the user will unexpectedly paste the old clipboard contents. Assuming doing so doesn't result in inconsistent behavior or performance issues, it's worth making the change. That said, this still seems a bit of a corner case, and with direct clipboard integration continuing to improve (see GUACAMOLE-559), I doubt the clipboard editor in the Guacamole menu will remain a significant part of most users' workflows. > Can't update remote clipboard while sidebar is still open. > -- > > Key: GUACAMOLE-676 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-676 > Project: Guacamole > Issue Type: Bug > Components: guacamole-client >Affects Versions: 0.9.14 > Environment: Ubuntu 16.04 > vnc4server 4.1.1+xorg4.3.0-37.3ubuntu2 >Reporter: Matt Travers >Priority: Minor > > When using the copy-and-paste feature, when text is entered into the sidebar > text area it is not copied into the remote clipboard until the sidebar is > closed. Only then can the text in the sidebar be pasted into the remote > environment. > It would be nice to be able to paste into the remote environment without > having to close the sidebar. Is it possible to get the remote clipboard > updated without having to press cntrl-alt-shift to close the sidebar? > The remote I am using is Ubuntu 16.04 with vnc4server running. > Thanks! > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-676) Update remote clipboard while sidebar is still open
[ https://issues.apache.org/jira/browse/GUACAMOLE-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-676: - Summary: Update remote clipboard while sidebar is still open (was: Can't update remote clipboard while sidebar is still open.) > Update remote clipboard while sidebar is still open > --- > > Key: GUACAMOLE-676 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-676 > Project: Guacamole > Issue Type: Bug > Components: guacamole-client >Affects Versions: 0.9.14 > Environment: Ubuntu 16.04 > vnc4server 4.1.1+xorg4.3.0-37.3ubuntu2 >Reporter: Matt Travers >Priority: Minor > > When using the copy-and-paste feature, when text is entered into the sidebar > text area it is not copied into the remote clipboard until the sidebar is > closed. Only then can the text in the sidebar be pasted into the remote > environment. > It would be nice to be able to paste into the remote environment without > having to close the sidebar. Is it possible to get the remote clipboard > updated without having to press cntrl-alt-shift to close the sidebar? > The remote I am using is Ubuntu 16.04 with vnc4server running. > Thanks! > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GUACAMOLE-677) Compiling guacamole client doesn't produce the .war file
[ https://issues.apache.org/jira/browse/GUACAMOLE-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper closed GUACAMOLE-677. Resolution: Invalid > Compiling guacamole client doesn't produce the .war file > > > Key: GUACAMOLE-677 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-677 > Project: Guacamole > Issue Type: Bug > Components: guacamole-client >Affects Versions: 0.9.14 >Reporter: Stefan Zuban >Priority: Major > > On ubuntu server 18.04, linux 4.15.0-42, java 1.8.0_191, maven 3.6.0, > compiling guacamole-client-0.9.14 ends with success, yet in the target/ > folder, there is no .war file. Instead there is a > guacamole-client-0.9.14.tar.gz file. Please advise. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-677) Compiling guacamole client doesn't produce the .war file
[
https://issues.apache.org/jira/browse/GUACAMOLE-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16721013#comment-16721013
]
Michael Jumper commented on GUACAMOLE-677:
--
>From
>http://guacamole.apache.org/doc/gug/installing-guacamole.html#building-guacamole-client:
{quote}
...
Once the Guacamole web application is built, there will be a .war file in the
{{guacamole/target/}} subdirectory of the current directory (the directory you
were in when you ran mvn), ready to be deployed to a servlet container like
Tomcat.
{quote}
There are multiple subprojects of guacamole-client and the webapp (guacamole)
is one of those. Only the source archive is an artifact of the top-level,
parent project.
> Compiling guacamole client doesn't produce the .war file
>
>
> Key: GUACAMOLE-677
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-677
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-client
>Affects Versions: 0.9.14
>Reporter: Stefan Zuban
>Priority: Major
>
> On ubuntu server 18.04, linux 4.15.0-42, java 1.8.0_191, maven 3.6.0,
> compiling guacamole-client-0.9.14 ends with success, yet in the target/
> folder, there is no .war file. Instead there is a
> guacamole-client-0.9.14.tar.gz file. Please advise.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GUACAMOLE-638) Compile error: 'avcodec_register_all' is deprecated
[
https://issues.apache.org/jira/browse/GUACAMOLE-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper resolved GUACAMOLE-638.
--
Resolution: Fixed
Fix Version/s: 2.0.0
> Compile error: 'avcodec_register_all' is deprecated
> ---
>
> Key: GUACAMOLE-638
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-638
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Affects Versions: 1.0.0
> Environment: Fedora 28
>Reporter: T Gale
>Assignee: Michael Jumper
>Priority: Minor
> Fix For: 2.0.0
>
>
> Compile error with Fedora 28:
> {code:none}
> guacenc.c: In function 'main':
> guacenc.c:79:5: error: 'avcodec_register_all' is deprecated
> [-Werror=deprecated-declarations]
> avcodec_register_all();
> ^~~~
> In file included from guacenc.c:27:
> /usr/include/ffmpeg/libavcodec/avcodec.h:4086:6: note: declared here
> void avcodec_register_all(void);
> ^~~~
> cc1: all warnings being treated as errors
> {code}
> Here's a patch:
> {code:none}
> --- guacenc.c 2018-09-28 02:25:30.0 +0100
> +++ guacenc.c 2018-09-28 15:30:26.849265324 +0100
> @@ -76,7 +76,9 @@
> "version " VERSION);
>
> /* Prepare libavcodec */
> +#if LIBAVCODEC_VERSION_INT < AV_VERSION_INT(58, 9, 100)
> avcodec_register_all();
> +#endif
>
> /* Track number of overall failures */
> int total_files = argc - optind;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GUACAMOLE-675) Unexpected Internal Error when trying to create a new group
[ https://issues.apache.org/jira/browse/GUACAMOLE-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper closed GUACAMOLE-675. Resolution: Invalid > Unexpected Internal Error when trying to create a new group > --- > > Key: GUACAMOLE-675 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-675 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-jdbc-mysql >Affects Versions: 1.0.0 > Environment: Ubuntu 16.04.3 / guacamole 1.0.0 from GitHub / >Reporter: emma >Priority: Minor > Attachments: Groups.png, Groups_CatalinaOut.png, > Groups_Schema_Update1.0.0to1.0.0.png, Guacamole_db_tables.png > > > Hi, > Updating my guacamole test server running with github version 1.0.0. > previously updated few month ago. > I just running a new update with the lastest github version, everything > during the update works fine except one thing i did notice previously during > other github upgrade version from 1.0.0 to 1.0.0. > Upgrade mysql schema database encoutered an error due guacamole table > existing. > So i guess it is link with the problem during New group creation and > "Unexpected Internel Error" cause some table missing in the database. > !Groups.png!!Groups_Schema_Update1.0.0to1.0.0.png! > What i get during my upgrade procedure when i try to update the schema > !Groups_CatalinaOut.png! > In catalina.out log about SQL error. > I am not surprise that some table doesn't exist as i cannot update mysql > database schema still in 1.0.0 (from previous upgrade) so im not sure the > schema upgrade is complete from 1.0.0 to 1.0.0 with Group management ? > !Guacamole_db_tables.png! > It seems guacamole_user_group_attribute table is missing ? > Well im not an expert but group creation not working for now. > Regards -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-675) Unexpected Internal Error when trying to create a new group
[
https://issues.apache.org/jira/browse/GUACAMOLE-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712864#comment-16712864
]
Michael Jumper commented on GUACAMOLE-675:
--
{quote}
Updating my guacamole test server running with github version 1.0.0. previously
updated few month ago.
{quote}
Until a tag is created, a release announcement is made, etc., there is no 1.0.0
release and anything you are building from git is under-development code. The
only exception to this are tags in git which point to the final source of a
release (like the "0.9.14" tag).
{quote}
I just running a new update with the lastest github version, everything during
the update works fine except one thing i did notice previously during other
github upgrade version from 1.0.0 to 1.0.0.
Upgrade mysql schema database encoutered an error due guacamole table existing.
{quote}
If you applied under-development schema changes to your database from months
ago, then your schema no longer matches the schema of any release and you will
need to drop and recreate your database from scratch.
The upgrade scripts are incremental relative to releases. They apply the
necessary schema changes to upgrade the database from the schema used by a
previous release. They do not upgrade from arbitrary points in time between
releases.
> Unexpected Internal Error when trying to create a new group
> ---
>
> Key: GUACAMOLE-675
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-675
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-auth-jdbc-mysql
>Affects Versions: 1.0.0
> Environment: Ubuntu 16.04.3 / guacamole 1.0.0 from GitHub /
>Reporter: emma
>Priority: Minor
> Attachments: Groups.png, Groups_CatalinaOut.png,
> Groups_Schema_Update1.0.0to1.0.0.png, Guacamole_db_tables.png
>
>
> Hi,
> Updating my guacamole test server running with github version 1.0.0.
> previously updated few month ago.
> I just running a new update with the lastest github version, everything
> during the update works fine except one thing i did notice previously during
> other github upgrade version from 1.0.0 to 1.0.0.
> Upgrade mysql schema database encoutered an error due guacamole table
> existing.
> So i guess it is link with the problem during New group creation and
> "Unexpected Internel Error" cause some table missing in the database.
> !Groups.png!!Groups_Schema_Update1.0.0to1.0.0.png!
> What i get during my upgrade procedure when i try to update the schema
> !Groups_CatalinaOut.png!
> In catalina.out log about SQL error.
> I am not surprise that some table doesn't exist as i cannot update mysql
> database schema still in 1.0.0 (from previous upgrade) so im not sure the
> schema upgrade is complete from 1.0.0 to 1.0.0 with Group management ?
> !Guacamole_db_tables.png!
> It seems guacamole_user_group_attribute table is missing ?
> Well im not an expert but group creation not working for now.
> Regards
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GUACAMOLE-671) Regression in CAS Module Redirect
[ https://issues.apache.org/jira/browse/GUACAMOLE-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper closed GUACAMOLE-671. Resolution: Duplicate > Regression in CAS Module Redirect > - > > Key: GUACAMOLE-671 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-671 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-cas >Affects Versions: 1.0.0 >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Blocker > Attachments: Screenshot_2018-12-02_15-47-38.png > > > Current CAS module from the staging/1.0.0 repository does not correctly > redirect to the CAS authentication page and does not display the correct > error message (see attached). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (GUACAMOLE-671) Regression in CAS Module Redirect
[ https://issues.apache.org/jira/browse/GUACAMOLE-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper reopened GUACAMOLE-671: -- Reopening just so I can edit and remove the fix version so this issue doesn't show up in the version reports. > Regression in CAS Module Redirect > - > > Key: GUACAMOLE-671 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-671 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-cas >Affects Versions: 1.0.0 >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Blocker > Attachments: Screenshot_2018-12-02_15-47-38.png > > > Current CAS module from the staging/1.0.0 repository does not correctly > redirect to the CAS authentication page and does not display the correct > error message (see attached). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-671) Regression in CAS Module Redirect
[ https://issues.apache.org/jira/browse/GUACAMOLE-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-671: - Fix Version/s: (was: 1.0.0) > Regression in CAS Module Redirect > - > > Key: GUACAMOLE-671 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-671 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-cas >Affects Versions: 1.0.0 >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Blocker > Attachments: Screenshot_2018-12-02_15-47-38.png > > > Current CAS module from the staging/1.0.0 repository does not correctly > redirect to the CAS authentication page and does not display the correct > error message (see attached). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-526) Update Guacamole-Client Webapp to Angular 1.6.9
[
https://issues.apache.org/jira/browse/GUACAMOLE-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709306#comment-16709306
]
Michael Jumper commented on GUACAMOLE-526:
--
Looking over the CAS source, nothing looks odd to me except for an unnecessary
dependency on {{ngRoute}} with a trailing comma:
https://github.com/apache/guacamole-client/blob/fc457c080d813044e30e1f4e8fe855d6a5900259/extensions/guacamole-auth-cas/src/main/resources/casModule.js#L25
It hurts the eyes, but that shouldn't break anything. I'm not sure what could
be failing to result in the unhandled rejections. Presumably there must be some
exception occurring between when the field HTML is inserted into the DOM and
when the controller is attached (which would cause the redirect to occur), but
I'm not seeing such a failure with OpenID and the two extensions are
essentially identical.
[~nick.couch...@yahoo.com], are you able to see what is failing to result in
the unhandled rejection? An exception of some kind? Maybe enable "pause on
exceptions" in dev tools?
> Update Guacamole-Client Webapp to Angular 1.6.9
> ---
>
> Key: GUACAMOLE-526
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-526
> Project: Guacamole
> Issue Type: Improvement
>Reporter: James Muehlner
>Assignee: James Muehlner
>Priority: Blocker
> Fix For: 1.0.0
>
>
> The client webapp is currently running AngularJS version 1.3.16, which is
> about 3 years old.
> Upgrading to the new typescript-based Angular would be a very involved
> change, but we should at least attempt to upgrade to the most recent version
> of AngularJS, 1.6.9.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-598) Fail cleanly if authentication backend is down / misconfigured
[
https://issues.apache.org/jira/browse/GUACAMOLE-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709267#comment-16709267
]
Michael Jumper commented on GUACAMOLE-598:
--
I did a search for usages of {{requestService.DIE}} and found that almost all
were tied to usages of {{dataSourceService}} which inherently tolerates HTTP
404. The remaining usages were this particular case in {{guacUserMenu}} (which
should really be {{requestService.IGNORE}}) and in admin pages where failure to
load would indeed be fatal.
> Fail cleanly if authentication backend is down / misconfigured
> --
>
> Key: GUACAMOLE-598
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-598
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: guac-generic-error.png
>
>
> Depending on the extension in use, it is possible for a backend
> authentication system (such as a MySQL database, LDAP directory, etc.) to
> become unreachable or to be fatally misconfigured, resulting in an internal
> failure during authentication attempts. Because of the way such internal
> failures are handled, this can cause the Guacamole login screen to fail to
> display entirely, masking any notification that might advise the user of the
> failure.
> The authentication system should fail cleanly. As long as doing so does not
> reveal sensitive information about the system, the fact that an error has
> occurred should be relayed to the user such that they can contact their
> administrator or check the relevant logs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-526) Update Guacamole-Client Webapp to Angular 1.6.9
[ https://issues.apache.org/jira/browse/GUACAMOLE-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709228#comment-16709228 ] Michael Jumper commented on GUACAMOLE-526: -- Just retested with OpenID and I'm not seeing the above. I see a brief "Please wait ..." message, confirmation from the IDP on the website I'm redirected to, and then I'm logged in to Guacamole after confirming. > Update Guacamole-Client Webapp to Angular 1.6.9 > --- > > Key: GUACAMOLE-526 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-526 > Project: Guacamole > Issue Type: Improvement >Reporter: James Muehlner >Assignee: James Muehlner >Priority: Blocker > Fix For: 1.0.0 > > > The client webapp is currently running AngularJS version 1.3.16, which is > about 3 years old. > Upgrading to the new typescript-based Angular would be a very involved > change, but we should at least attempt to upgrade to the most recent version > of AngularJS, 1.6.9. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GUACAMOLE-526) Update Guacamole-Client Webapp to Angular 1.6.9
[
https://issues.apache.org/jira/browse/GUACAMOLE-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707785#comment-16707785
]
Michael Jumper edited comment on GUACAMOLE-526 at 12/4/18 8:39 PM:
---
It appears that the changes in this issue cause a regression where extensions
that rely on redirection to function properly (CAS at least, possibly OpenID)
fail to redirect properly. The impacted modules just hang on the Redirecting
pages and throw the following errors in the JS console:
{quote}
{code:none}
Possibly unhandled rejection: undefined
Possibly unhandled rejection:
{"message":"LOGIN.INFO_CAS_REDIRECT_PENDING","translatableMessage":{"key":"LOGIN.INFO_CAS_REDIRECT_PENDING","variables":null},"statusCode":null,"type":"INSUFFICIENT_CREDENTIALS","expected":[{"name":"ticket","type":"GUAC_CAS_TICKET","authorizationURI":"https://ussalxapps005t.cotyww.com/cas/login?service=https%3A%2F%2F172.21.208.254%3A3443%2Fguacamole"}]}
{code}
{quote}
was (Author: nick.couch...@yahoo.com):
It appears that the changes in this issue cause a regression where extensions
that rely on redirection to function properly (CAS at least, possibly OpenID)
fail to redirect properly. The impacted modules just hang on the Redirecting
pages and throw the following errors in the JS console:
{quote}
Possibly unhandled rejection: undefined
Possibly unhandled rejection:
{"message":"LOGIN.INFO_CAS_REDIRECT_PENDING","translatableMessage":{"key":"LOGIN.INFO_CAS_REDIRECT_PENDING","variables":null},"statusCode":null,"type":"INSUFFICIENT_CREDENTIALS","expected":[{"name":"ticket","type":"GUAC_CAS_TICKET","authorizationURI":"https://ussalxapps005t.cotyww.com/cas/login?service=https%3A%2F%2F172.21.208.254%3A3443%2Fguacamole"}]}
{quote}
> Update Guacamole-Client Webapp to Angular 1.6.9
> ---
>
> Key: GUACAMOLE-526
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-526
> Project: Guacamole
> Issue Type: Improvement
>Reporter: James Muehlner
>Assignee: James Muehlner
>Priority: Blocker
> Fix For: 1.0.0
>
>
> The client webapp is currently running AngularJS version 1.3.16, which is
> about 3 years old.
> Upgrading to the new typescript-based Angular would be a very involved
> change, but we should at least attempt to upgrade to the most recent version
> of AngularJS, 1.6.9.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GUACAMOLE-669) Guacamole Docker Unable To Manage Users
[ https://issues.apache.org/jira/browse/GUACAMOLE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper closed GUACAMOLE-669. Resolution: Duplicate > Guacamole Docker Unable To Manage Users > --- > > Key: GUACAMOLE-669 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-669 > Project: Guacamole > Issue Type: Bug >Affects Versions: 0.9.14 >Reporter: Joe >Priority: Major > > After creating a new quacamole instance I am able to manage users on ubuntu > 18.05 and setup with docker compose and an external MySQL. However after > rebooting or doing docker-compose down and creating a session, all users log > into the same session (ssh) and no administration page/home page/manager is > displayed. > > mysql Ver 14.14 Distrib 5.7.24, for Linux (x86_64) using EditLine wrapper > docker 18.09.0 > docker-compose version 1.23.1, build b02f1306 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-669) Guacamole Docker Unable To Manage Users
[ https://issues.apache.org/jira/browse/GUACAMOLE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709226#comment-16709226 ] Michael Jumper commented on GUACAMOLE-669: -- Guacamole will automatically redirect users to their sole connection if they only have access to one. This behavior was improved with GUACAMOLE-508 for the upcoming 1.0.0 release, only redirecting users to their sole connection if they lack administrative permissions. You can in the meantime access settings as an administrator despite only having one connection by opening the Guacamole menu (Ctrl+Alt+Shift). Once you have more than one connection you will cease being redirected. See: * http://mail-archives.apache.org/mod_mbox/guacamole-user/201803.mbox/%3CCAFjj601ELNVC_CvDQvp%3DDbTStbV36CFOo9j4hY7yjVvQCWLNPw%40mail.gmail.com%3E * http://mail-archives.apache.org/mod_mbox/guacamole-user/201804.mbox/%3CCALKeL-PCcfuk6OdyL3nf6jGykW-aX2HTfs8xprfUPn9FvGUuGQ%40mail.gmail.com%3E > Guacamole Docker Unable To Manage Users > --- > > Key: GUACAMOLE-669 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-669 > Project: Guacamole > Issue Type: Bug >Affects Versions: 0.9.14 >Reporter: Joe >Priority: Major > > After creating a new quacamole instance I am able to manage users on ubuntu > 18.05 and setup with docker compose and an external MySQL. However after > rebooting or doing docker-compose down and creating a session, all users log > into the same session (ssh) and no administration page/home page/manager is > displayed. > > mysql Ver 14.14 Distrib 5.7.24, for Linux (x86_64) using EditLine wrapper > docker 18.09.0 > docker-compose version 1.23.1, build b02f1306 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-598) Fail cleanly if authentication backend is down / misconfigured
[
https://issues.apache.org/jira/browse/GUACAMOLE-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707369#comment-16707369
]
Michael Jumper commented on GUACAMOLE-598:
--
Oops. Sounds like one or more of the promise handlers should be
{{requestService.IGNORE}} instead of {{requestService.DIE}}. I'll take a look -
this should be an easy one.
> Fail cleanly if authentication backend is down / misconfigured
> --
>
> Key: GUACAMOLE-598
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-598
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: guac-generic-error.png
>
>
> Depending on the extension in use, it is possible for a backend
> authentication system (such as a MySQL database, LDAP directory, etc.) to
> become unreachable or to be fatally misconfigured, resulting in an internal
> failure during authentication attempts. Because of the way such internal
> failures are handled, this can cause the Guacamole login screen to fail to
> display entirely, masking any notification that might advise the user of the
> failure.
> The authentication system should fail cleanly. As long as doing so does not
> reveal sensitive information about the system, the fact that an error has
> occurred should be relayed to the user such that they can contact their
> administrator or check the relevant logs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GUACAMOLE-668) Preferring JPEG due to lower CPU usage - controlling guacd behaviour via some kind of preferences
[
https://issues.apache.org/jira/browse/GUACAMOLE-668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper closed GUACAMOLE-668.
Resolution: Won't Do
> Preferring JPEG due to lower CPU usage - controlling guacd behaviour via some
> kind of preferences
> -
>
> Key: GUACAMOLE-668
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-668
> Project: Guacamole
> Issue Type: Wish
> Components: guacd
>Reporter: Andrzej Dorobisz
>Priority: Major
>
> In our HPC center, we observe that guacamole-server (guacd) is generating
> quite high CPU-usage even if only one session is currently processed (it
> reaches 100% when moving window back and forth).
> We have tested that using JPEG instead of PNG in
> "{{__guac_common_surface_flush_}}_" (_src/common/surface.c_) noticeably
> decreases the CPU usage. When WebP is available it performs better than PNG
> but still it's slower (in terms of CPU usage) than JPEG.
> We believe that user running _guacd_ should be able to choose which format is
> preferred - without recompilation. Our first idea was to use _guacd.conf_ for
> passing such a preference, but we see that it is not so simple. We have to
> store such a preference somewhere and then pass it to VNC client which is
> calling {{__guac_common_surface_flush}} function.
> ---
> What do you think about adding such an ability and what would be the best
> approach to implement this? If you provide guidance, I can try to implement
> it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-666) Text pasted through SSH into nano editor
[ https://issues.apache.org/jira/browse/GUACAMOLE-666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700038#comment-16700038 ] Michael Jumper commented on GUACAMOLE-666: -- The "bracketed paste" thing is a bit of a red herring. It may solve the issue you're encountering (assuming Nano implements it), but there is a more fundamental issue that could be solved here without relying on special handling of clipboard within both terminal application and terminal emulator. It's more clearly described here: http://savannah.gnu.org/bugs/?49176 When text containing a newline character is pasted, that newline character is interpreted by Nano as ^J, resulting in weird behavior. Similar to the issue with RDP where the clipboard is expected to contain Windows/DOS-style newline sequences, Guacamole should translate newlines within pasted text to the same character that would be sent for an enter keypress (^M). > Text pasted through SSH into nano editor > > > Key: GUACAMOLE-666 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-666 > Project: Guacamole > Issue Type: Bug > Components: guacamole >Affects Versions: 0.9.14 > Environment: OS Fedora 29 > Chrome 70 or Firefox 63 >Reporter: Pierre Gabriel >Priority: Minor > Attachments: clipboard_content.png, first_paste.png, hexdump.png, > original_text.png, second_paste.png > > > When I try to paste text like : > *_|| test $$_* > *_|| ;_* > into the nano text editor, it doesn't work properly ; (see captured file) ; > The issue doesn't appear when i try this over a direct ssh connection (i.e > from my os terminal) ; > The issue doesn't appear into another text editor like vi ; -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-666) Text pasted through SSH into nano editor
[ https://issues.apache.org/jira/browse/GUACAMOLE-666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699503#comment-16699503 ] Michael Jumper commented on GUACAMOLE-666: -- So far, I can't reproduce this. I do see the Windows -> Linux newline issue, but copying the text from this JIRA issue I see both lines present. > Text pasted through SSH into nano editor > > > Key: GUACAMOLE-666 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-666 > Project: Guacamole > Issue Type: Bug > Components: guacamole >Affects Versions: 0.9.14 > Environment: OS Fedora 29 > Chrome 70 or Firefox 63 >Reporter: GABRIEL >Priority: Minor > Attachments: first_paste.png, original_text.png, second_paste.png > > > When I try to paste text like : > *_|| test $$_* > *_|| ;_* > into the nano text editor, it doesn't work properly ; (see captured file) ; > The issue doesn't appear when i try this over a direct ssh connection (i.e > from my os terminal) ; > The issue doesn't appear into another text editor like vi ; -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-667) Enable loading configuration file from other locations than default
[
https://issues.apache.org/jira/browse/GUACAMOLE-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper updated GUACAMOLE-667:
-
Component/s: (was: guacamole-server)
guacd
> Enable loading configuration file from other locations than default
> ---
>
> Key: GUACAMOLE-667
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-667
> Project: Guacamole
> Issue Type: Improvement
> Components: guacd
>Reporter: Andrzej Dorobisz
>Priority: Minor
>
> Currently, when the guacamole-server daemon starts (_src/guacd/daemon.c_) the
> configuration file is loaded ({{guacd_conf_load()}} in
> _src/guacd/conf-file.c_) but the path to the configuration file is fixed.
> This path is read from {{GUACD_CONF_FILE}} variable, which is set to
> "_/etc/guacamole/guacd.conf_" during ./configure process.
> {code:java}
> ./configure.ac:AC_DEFINE_UNQUOTED([GUACD_CONF_FILE], ["$guacd_conf"], [The
> full path to the guacd config file])
> ./configure: guacd_conf=/etc/guacamole/guacd.conf
> {code}
> We propose to enable loading of the configuration file from the path provided
> (on the program startup) by the user.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-667) Enable loading configuration file from other locations than default
[
https://issues.apache.org/jira/browse/GUACAMOLE-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699483#comment-16699483
]
Michael Jumper commented on GUACAMOLE-667:
--
Can you describe the use case behind this?
> Enable loading configuration file from other locations than default
> ---
>
> Key: GUACAMOLE-667
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-667
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-server
>Reporter: Andrzej Dorobisz
>Priority: Minor
>
> Currently, when the guacamole-server daemon starts (_src/guacd/daemon.c_) the
> configuration file is loaded ({{guacd_conf_load()}} in
> _src/guacd/conf-file.c_) but the path to the configuration file is fixed.
> This path is read from {{GUACD_CONF_FILE}} variable, which is set to
> "_/etc/guacamole/guacd.conf_" during ./configure process.
> {code:java}
> ./configure.ac:AC_DEFINE_UNQUOTED([GUACD_CONF_FILE], ["$guacd_conf"], [The
> full path to the guacd config file])
> ./configure: guacd_conf=/etc/guacamole/guacd.conf
> {code}
> We propose to enable loading of the configuration file from the path provided
> (on the program startup) by the user.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-663) guacd SEGVs intermittently on systems with small(er) thread stack sizes
[ https://issues.apache.org/jira/browse/GUACAMOLE-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16690750#comment-16690750 ] Michael Jumper commented on GUACAMOLE-663: -- Thanks, [~rvs]! If you believe your changes are ready for review, mind opening a pull request? See: https://github.com/apache/guacamole-server/blob/master/CONTRIBUTING http://guacamole.apache.org/open-source/#contribute > guacd SEGVs intermittently on systems with small(er) thread stack sizes > --- > > Key: GUACAMOLE-663 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-663 > Project: Guacamole > Issue Type: Bug > Components: guacd >Affects Versions: 1.0.0 >Reporter: Roman Shaposhnik >Priority: Major > Attachments: GUACAMOLE-663.patch.txt > > > I've observed at least guacd VNC plugin to run out of stack space when > deployed on Alpine Linux with musl libc. This is not limited to Alpine since > quite a few distributions are using musl these days (Void, Bedrock, etc.) and > the list is growing. musl libc is especially popular for distributions meant > to be the base for Docker containers. Hence, I believe addressing this will > be quite important for enabling use of guacd in modern containerized > environments. > The issue itself is well know to Alpine folks: > [https://github.com/voidlinux/void-packages/issues/4147] and they feel > (perhaps for right reasons) that applications requiring large(r) thread > stacksizes should explicitly declare their requirement. There are currently > two ways of accomplishing this: either via a global > pthread_setattr_default_np call > [https://www.openwall.com/lists/musl/2017/01/03/1] or via per-pthread_create > setting of defaults e.g. > [https://github.com/voidlinux/void-packages/commit/5d65448221af12296f7ef2339ced92771bb465b4] > > > I feel that the first option is a better choice for guacd. Attaching a > preliminary patch that makes guacd work fine on Alpine 3.8.x -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GUACAMOLE-510) Nested socket index is not initialized
[
https://issues.apache.org/jira/browse/GUACAMOLE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper reassigned GUACAMOLE-510:
Assignee: Michael Jumper
> Nested socket index is not initialized
> --
>
> Key: GUACAMOLE-510
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-510
> Project: Guacamole
> Issue Type: Bug
> Components: libguac
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Trivial
>
> Although {{guac_socket_nest()}} takes an index parameter, this parameter is
> never used and the index of the socket is left uninitialized.
> This is not a problem in practice as nested sockets are no longer used (the
> Guacamole protocol has evolved to inherently support streaming large blocks
> of data and no longer needs to nest itself as a workaround). It's likely that
> {{guac_socket_nest()}} and the "nest" instruction should be deprecated, but
> this should be fixed in the meantime.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GUACAMOLE-662) Failing unit tests for guacamole-server not triggering build failure
[
https://issues.apache.org/jira/browse/GUACAMOLE-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper reassigned GUACAMOLE-662:
Assignee: Michael Jumper
> Failing unit tests for guacamole-server not triggering build failure
>
>
> Key: GUACAMOLE-662
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-662
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Major
>
> The unit test for the "nest" instruction (hopefully soon to be deprecated via
> GUACAMOLE-661) has been failing. Assuming the failure is legitimate, it
> hasn't been a problem in practice since the "nest" instruction has been
> unused for some time, but the fact that this failure has gone unnoticed is
> troubling. The build results currently show the following for {{make check}}:
> {code:none}
> ...
> PASS: test_libguac
>
> Testsuite summary for guacamole-server 1.0.0
>
> # TOTAL: 1
> # PASS: 1
> # SKIP: 0
> # XFAIL: 0
> # FAIL: 0
> # XPASS: 0
> # ERROR: 0
>
> ...
> {code}
> The test log within {{tests/test_libguac.log}} contradicts this, showing that
> there is actually a test failure (not to mention more than one test total):
> {code:none}
> CUnit - A unit testing framework for C - Version 2.1-3
> http://cunit.sourceforge.net/
> Suite: protocol
> Test: base64-decode ...passed
> Test: instruction-parse ...passed
> Test: instruction-read ...passed
> Test: instruction-write ...passed
> Test: nest-write ...FAILED
> 1. protocol/nest_write.c:104 - CU_ASSERT_STRING_EQUAL(buffer,expected)
> Suite: client
> Test: layer-pool ...passed
> Test: buffer-pool ...passed
> Suite: util
> Test: guac-pool ...passed
> Test: guac-unicode ...passed
> Run Summary:Type TotalRan Passed Failed Inactive
> suites 3 3n/a 00
>tests 9 9 8 10
> asserts 11091 11091 11090 1 n/a
> Elapsed time = -0.006 seconds
> {code}
> If "nest" is truly not behaving correctly, it should be corrected. If "nest"
> is correct but the test is wrong, the test should be fixed. Most importantly,
> the testing portion of the build process should be corrected such that:
> # The test report actually captures the correct number of tests passing and
> test failures.
> # A failing test fails the build.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-662) Failing unit tests for guacamole-server not triggering build failure
[
https://issues.apache.org/jira/browse/GUACAMOLE-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper updated GUACAMOLE-662:
-
Description:
The unit test for the "nest" instruction (hopefully soon to be deprecated via
GUACAMOLE-661) has been failing. Assuming the failure is legitimate, it hasn't
been a problem in practice since the "nest" instruction has been unused for
some time, but the fact that this failure has gone unnoticed is troubling. The
build results currently show the following for {{make check}}:
{code:none}
...
PASS: test_libguac
Testsuite summary for guacamole-server 1.0.0
# TOTAL: 1
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
...
{code}
The test log within {{tests/test_libguac.log}} contradicts this, showing that
there is actually a test failure (not to mention more than one test total):
{code:none}
CUnit - A unit testing framework for C - Version 2.1-3
http://cunit.sourceforge.net/
Suite: protocol
Test: base64-decode ...passed
Test: instruction-parse ...passed
Test: instruction-read ...passed
Test: instruction-write ...passed
Test: nest-write ...FAILED
1. protocol/nest_write.c:104 - CU_ASSERT_STRING_EQUAL(buffer,expected)
Suite: client
Test: layer-pool ...passed
Test: buffer-pool ...passed
Suite: util
Test: guac-pool ...passed
Test: guac-unicode ...passed
Run Summary:Type TotalRan Passed Failed Inactive
suites 3 3n/a 00
tests 9 9 8 10
asserts 11091 11091 11090 1 n/a
Elapsed time = -0.006 seconds
{code}
If "nest" is truly not behaving correctly, it should be corrected. If "nest" is
correct but the test is wrong, the test should be fixed. Most importantly, the
testing portion of the build process should be corrected such that:
# The test report actually captures the correct number of tests passing and
test failures.
# A failing test fails the build.
was:
The unit test for the "nest" instruction (hopefully soon to be deprecated via
GUACAMOLE-611) has been failing. Assuming the failure is legitimate, it hasn't
been a problem in practice since the "nest" instruction has been unused for
some time, but the fact that this failure has gone unnoticed is troubling. The
build results currently show the following for {{make check}}:
{code:none}
...
PASS: test_libguac
Testsuite summary for guacamole-server 1.0.0
# TOTAL: 1
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
...
{code}
The test log within {{tests/test_libguac.log}} contradicts this, showing that
there is actually a test failure (not to mention more than one test total):
{code:none}
CUnit - A unit testing framework for C - Version 2.1-3
http://cunit.sourceforge.net/
Suite: protocol
Test: base64-decode ...passed
Test: instruction-parse ...passed
Test: instruction-read ...passed
Test: instruction-write ...passed
Test: nest-write ...FAILED
1. protocol/nest_write.c:104 - CU_ASSERT_STRING_EQUAL(buffer,expected)
Suite: client
Test: layer-pool ...passed
Test: buffer-pool ...passed
Suite: util
Test: guac-pool ...passed
Test: guac-unicode ...passed
Run Summary:Type TotalRan Passed Failed Inactive
suites 3 3n/a 00
tests 9 9 8 10
asserts 11091 11091 11090 1 n/a
Elapsed time = -0.006 seconds
{code}
If "nest" is truly not behaving correctly, it should be corrected. If "nest" is
correct but the test is wrong, the test should be fixed. Most importantly, the
testing portion of the build process should be corrected such that:
# The test report actually captures the correct number of tests passing and
test failures.
# A failing test fails the build.
> Failing unit tests for guacamole-server not triggering build failure
>
>
> Key: GUACAMOLE-662
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-662
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Reporter: Michael Jumper
>Priority: Major
>
> The unit test for the "nest" instruction (hopefully soon to be deprecated via
> GUACAMOLE-661) has been failing. Assuming the failure is legitimate, it
> hasn't been a
[jira] [Created] (GUACAMOLE-662) Failing unit tests for guacamole-server not triggering build failure
Michael Jumper created GUACAMOLE-662:
Summary: Failing unit tests for guacamole-server not triggering
build failure
Key: GUACAMOLE-662
URL: https://issues.apache.org/jira/browse/GUACAMOLE-662
Project: Guacamole
Issue Type: Bug
Components: guacamole-server
Reporter: Michael Jumper
The unit test for the "nest" instruction (hopefully soon to be deprecated via
GUACAMOLE-611) has been failing. Assuming the failure is legitimate, it hasn't
been a problem in practice since the "nest" instruction has been unused for
some time, but the fact that this failure has gone unnoticed is troubling. The
build results currently show the following for {{make check}}:
{code:none}
...
PASS: test_libguac
Testsuite summary for guacamole-server 1.0.0
# TOTAL: 1
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
...
{code}
The test log within {{tests/test_libguac.log}} contradicts this, showing that
there is actually a test failure (not to mention more than one test total):
{code:none}
CUnit - A unit testing framework for C - Version 2.1-3
http://cunit.sourceforge.net/
Suite: protocol
Test: base64-decode ...passed
Test: instruction-parse ...passed
Test: instruction-read ...passed
Test: instruction-write ...passed
Test: nest-write ...FAILED
1. protocol/nest_write.c:104 - CU_ASSERT_STRING_EQUAL(buffer,expected)
Suite: client
Test: layer-pool ...passed
Test: buffer-pool ...passed
Suite: util
Test: guac-pool ...passed
Test: guac-unicode ...passed
Run Summary:Type TotalRan Passed Failed Inactive
suites 3 3n/a 00
tests 9 9 8 10
asserts 11091 11091 11090 1 n/a
Elapsed time = -0.006 seconds
{code}
If "nest" is truly not behaving correctly, it should be corrected. If "nest" is
correct but the test is wrong, the test should be fixed. Most importantly, the
testing portion of the build process should be corrected such that:
# The test report actually captures the correct number of tests passing and
test failures.
# A failing test fails the build.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GUACAMOLE-661) Deprecate "nest" instruction
Michael Jumper created GUACAMOLE-661: Summary: Deprecate "nest" instruction Key: GUACAMOLE-661 URL: https://issues.apache.org/jira/browse/GUACAMOLE-661 Project: Guacamole Issue Type: Improvement Components: Documentation, libguac Reporter: Michael Jumper The ["nest" instruction|http://guacamole.apache.org/doc/0.9.14/gug/protocol-reference.html#nest-stream-instruction] was created in the early days of the Guacamole protocol as a means of splitting up large instructions. At the time, this was necessary because images and audio were transmitted within instructions that required the entire block of data to be available at once. The "nest" instruction thus provided a means of streaming data for instructions that otherwise did not support it. The Guacamole protocol switched over instructions with actual stream semantics around the 0.9.0 release (back in 2014). Since that time, the nest instruction has become unnecessary, and is actually no longer used in practice. It's time the instruction and related functions/structures were deprecated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GUACAMOLE-220) Implement user groups
[
https://issues.apache.org/jira/browse/GUACAMOLE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper resolved GUACAMOLE-220.
--
Resolution: Done
> Implement user groups
> -
>
> Key: GUACAMOLE-220
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-220
> Project: Guacamole
> Issue Type: Improvement
> Components: Documentation, guacamole, guacamole-auth-jdbc,
> guacamole-auth-ldap, guacamole-ext
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Major
> Fix For: 1.0.0
>
>
> {panel:bgColor=#EE}
> *The description of this issue was copied from
> [GUAC-1073|https://glyptodon.org/jira/browse/GUAC-1073], an issue in the JIRA
> instance used by the Guacamole project prior to its acceptance into the
> Apache Incubator.*
> Comments, attachments, related issues, and history from prior to acceptance
> *have not been copied* and can be found instead at the original issue.
> {panel}
> Guacamole should support tagging of users into logical user groups, such that
> permissions can be managed at a group level, rather than a per-user level.
> These permissions should include all available permission types, not simply
> "READ' as in the current management interface.
> With this in mind, the permission manipulation interface would need to be
> modified to support a more standard ACL-style interface at the connection
> level, allowing users or groups to be added to a connection, rather than
> connections added to a user or group.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-638) Compile error: 'avcodec_register_all' is deprecated
[
https://issues.apache.org/jira/browse/GUACAMOLE-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16684559#comment-16684559
]
Michael Jumper commented on GUACAMOLE-638:
--
According to the FFmpeg API changelog, {{avcodec_register_all()}} has been
deprecated since specifically 58.10.100:
https://github.com/FFmpeg/FFmpeg/blob/23f589e073406f8c9d80092d3ff9ef8c22f27e63/doc/APIchanges#L108
> Compile error: 'avcodec_register_all' is deprecated
> ---
>
> Key: GUACAMOLE-638
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-638
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Affects Versions: 1.0.0
> Environment: Fedora 28
>Reporter: T Gale
>Assignee: Michael Jumper
>Priority: Minor
>
> Compile error with Fedora 28:
> {code:none}
> guacenc.c: In function 'main':
> guacenc.c:79:5: error: 'avcodec_register_all' is deprecated
> [-Werror=deprecated-declarations]
> avcodec_register_all();
> ^~~~
> In file included from guacenc.c:27:
> /usr/include/ffmpeg/libavcodec/avcodec.h:4086:6: note: declared here
> void avcodec_register_all(void);
> ^~~~
> cc1: all warnings being treated as errors
> {code}
> Here's a patch:
> {code:none}
> --- guacenc.c 2018-09-28 02:25:30.0 +0100
> +++ guacenc.c 2018-09-28 15:30:26.849265324 +0100
> @@ -76,7 +76,9 @@
> "version " VERSION);
>
> /* Prepare libavcodec */
> +#if LIBAVCODEC_VERSION_INT < AV_VERSION_INT(58, 9, 100)
> avcodec_register_all();
> +#endif
>
> /* Track number of overall failures */
> int total_files = argc - optind;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GUACAMOLE-637) Compile error: 'strncpy' output may be truncated copying 7 bytes from a string of length 7
[ https://issues.apache.org/jira/browse/GUACAMOLE-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper reassigned GUACAMOLE-637: Assignee: Michael Jumper > Compile error: 'strncpy' output may be truncated copying 7 bytes from a > string of length 7 > -- > > Key: GUACAMOLE-637 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-637 > Project: Guacamole > Issue Type: Bug > Components: guacamole-server >Affects Versions: 1.0.0 > Environment: Fedora 28 >Reporter: T Gale >Assignee: Michael Jumper >Priority: Minor > > Build error on Fedora 28: > CC guac_svc/guacsvc_client_la-svc_service.lo > guac_svc/svc_service.c: In function 'VirtualChannelEntry': > guac_svc/svc_service.c:56:5: error: 'strncpy' output may be truncated copying > 7 bytes from a string of length 7 [-Werror=stringop-truncation] > strncpy(svc_plugin->plugin.channel_def.name, svc->name, > ^~~ > GUAC_RDP_SVC_MAX_LENGTH); > > cc1: all warnings being treated as errors -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-638) Compile error: 'avcodec_register_all' is deprecated
[
https://issues.apache.org/jira/browse/GUACAMOLE-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper updated GUACAMOLE-638:
-
Description:
Compile error with Fedora 28:
{code:none}
guacenc.c: In function 'main':
guacenc.c:79:5: error: 'avcodec_register_all' is deprecated
[-Werror=deprecated-declarations]
avcodec_register_all();
^~~~
In file included from guacenc.c:27:
/usr/include/ffmpeg/libavcodec/avcodec.h:4086:6: note: declared here
void avcodec_register_all(void);
^~~~
cc1: all warnings being treated as errors
{code}
Here's a patch:
{code:none}
--- guacenc.c 2018-09-28 02:25:30.0 +0100
+++ guacenc.c 2018-09-28 15:30:26.849265324 +0100
@@ -76,7 +76,9 @@
"version " VERSION);
/* Prepare libavcodec */
+#if LIBAVCODEC_VERSION_INT < AV_VERSION_INT(58, 9, 100)
avcodec_register_all();
+#endif
/* Track number of overall failures */
int total_files = argc - optind;
{code}
was:
Compile error with Fedora 28:
guacenc.c: In function 'main':
guacenc.c:79:5: error: 'avcodec_register_all' is deprecated
[-Werror=deprecated-declarations]
avcodec_register_all();
^~~~
In file included from guacenc.c:27:
/usr/include/ffmpeg/libavcodec/avcodec.h:4086:6: note: declared here
void avcodec_register_all(void);
^~~~
cc1: all warnings being treated as errors
Here's a patch:
--- guacenc.c 2018-09-28 02:25:30.0 +0100
+++ guacenc.c 2018-09-28 15:30:26.849265324 +0100
@@ -76,7 +76,9 @@
"version " VERSION);
/* Prepare libavcodec */
+#if LIBAVCODEC_VERSION_INT < AV_VERSION_INT(58, 9, 100)
avcodec_register_all();
+#endif
/* Track number of overall failures */
int total_files = argc - optind;
> Compile error: 'avcodec_register_all' is deprecated
> ---
>
> Key: GUACAMOLE-638
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-638
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Affects Versions: 1.0.0
> Environment: Fedora 28
>Reporter: T Gale
>Assignee: Michael Jumper
>Priority: Minor
>
> Compile error with Fedora 28:
> {code:none}
> guacenc.c: In function 'main':
> guacenc.c:79:5: error: 'avcodec_register_all' is deprecated
> [-Werror=deprecated-declarations]
> avcodec_register_all();
> ^~~~
> In file included from guacenc.c:27:
> /usr/include/ffmpeg/libavcodec/avcodec.h:4086:6: note: declared here
> void avcodec_register_all(void);
> ^~~~
> cc1: all warnings being treated as errors
> {code}
> Here's a patch:
> {code:none}
> --- guacenc.c 2018-09-28 02:25:30.0 +0100
> +++ guacenc.c 2018-09-28 15:30:26.849265324 +0100
> @@ -76,7 +76,9 @@
> "version " VERSION);
>
> /* Prepare libavcodec */
> +#if LIBAVCODEC_VERSION_INT < AV_VERSION_INT(58, 9, 100)
> avcodec_register_all();
> +#endif
>
> /* Track number of overall failures */
> int total_files = argc - optind;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-637) Compile error: 'strncpy' output may be truncated copying 7 bytes from a string of length 7
[
https://issues.apache.org/jira/browse/GUACAMOLE-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper updated GUACAMOLE-637:
-
Description:
Build error on Fedora 28:
{code:none}
CC guac_svc/guacsvc_client_la-svc_service.lo
guac_svc/svc_service.c: In function 'VirtualChannelEntry':
guac_svc/svc_service.c:56:5: error: 'strncpy' output may be truncated copying 7
bytes from a string of length 7 [-Werror=stringop-truncation]
strncpy(svc_plugin->plugin.channel_def.name, svc->name,
^~~
GUAC_RDP_SVC_MAX_LENGTH);
cc1: all warnings being treated as errors
{code}
was:
Build error on Fedora 28:
CC guac_svc/guacsvc_client_la-svc_service.lo
guac_svc/svc_service.c: In function 'VirtualChannelEntry':
guac_svc/svc_service.c:56:5: error: 'strncpy' output may be truncated copying 7
bytes from a string of length 7 [-Werror=stringop-truncation]
strncpy(svc_plugin->plugin.channel_def.name, svc->name,
^~~
GUAC_RDP_SVC_MAX_LENGTH);
cc1: all warnings being treated as errors
> Compile error: 'strncpy' output may be truncated copying 7 bytes from a
> string of length 7
> --
>
> Key: GUACAMOLE-637
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-637
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Affects Versions: 1.0.0
> Environment: Fedora 28
>Reporter: T Gale
>Assignee: Michael Jumper
>Priority: Minor
>
> Build error on Fedora 28:
> {code:none}
> CC guac_svc/guacsvc_client_la-svc_service.lo
> guac_svc/svc_service.c: In function 'VirtualChannelEntry':
> guac_svc/svc_service.c:56:5: error: 'strncpy' output may be truncated copying
> 7 bytes from a string of length 7 [-Werror=stringop-truncation]
> strncpy(svc_plugin->plugin.channel_def.name, svc->name,
> ^~~
> GUAC_RDP_SVC_MAX_LENGTH);
>
> cc1: all warnings being treated as errors
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GUACAMOLE-638) Compile error: 'avcodec_register_all' is deprecated
[ https://issues.apache.org/jira/browse/GUACAMOLE-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper reassigned GUACAMOLE-638: Assignee: Michael Jumper > Compile error: 'avcodec_register_all' is deprecated > --- > > Key: GUACAMOLE-638 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-638 > Project: Guacamole > Issue Type: Bug > Components: guacamole-server >Affects Versions: 1.0.0 > Environment: Fedora 28 >Reporter: T Gale >Assignee: Michael Jumper >Priority: Minor > > Compile error with Fedora 28: > guacenc.c: In function 'main': > guacenc.c:79:5: error: 'avcodec_register_all' is deprecated > [-Werror=deprecated-declarations] > avcodec_register_all(); > ^~~~ > In file included from guacenc.c:27: > /usr/include/ffmpeg/libavcodec/avcodec.h:4086:6: note: declared here > void avcodec_register_all(void); > ^~~~ > cc1: all warnings being treated as errors > Here's a patch: > --- guacenc.c 2018-09-28 02:25:30.0 +0100 > +++ guacenc.c 2018-09-28 15:30:26.849265324 +0100 > @@ -76,7 +76,9 @@ > "version " VERSION); > > /* Prepare libavcodec */ > +#if LIBAVCODEC_VERSION_INT < AV_VERSION_INT(58, 9, 100) > avcodec_register_all(); > +#endif > > /* Track number of overall failures */ > int total_files = argc - optind; -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GUACAMOLE-659) Docker Image does not allow default authentication
[
https://issues.apache.org/jira/browse/GUACAMOLE-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper closed GUACAMOLE-659.
Resolution: Invalid
> Docker Image does not allow default authentication
> --
>
> Key: GUACAMOLE-659
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-659
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-client
>Affects Versions: 0.9.14
>Reporter: Tom Kent
>Priority: Major
>
> When starting a docker image, I mount a directory with a guacamole.properties
> and user-mapping.xml:
> {{docker run --name some-guac --link some-guacd:guacd -p 8080:8080 -v
> $PWD/settings:/etc/guacamole guacamole/guacamole}}
> However, when the instance starts up, it immediately fails because there is
> no mysql, postgres, or LDAP authentication.
> {{FATAL: No authentication configured}}
> {{---}}
> {{The Guacamole Docker container needs at least one authentication mechanism
> in}}
> {{order to function, such as a MySQL database, PostgreSQL database, or LDAP}}
> {{directory. Please specify at least the MYSQL_DATABASE or POSTGRES_DATABASE}}
> {{environment variables, or check Guacamole's Docker documentation regarding}}
> {{configuring LDAP and/or custom extensions.}}
> Ideally, there would be a check in
> guacamole-client/guacamole-docker/bin/start.sh to see if user-mapping.xml
> exists in $GUACAMOLE_HOME and allow it to proceed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-659) Docker Image does not allow default authentication
[
https://issues.apache.org/jira/browse/GUACAMOLE-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682938#comment-16682938
]
Michael Jumper commented on GUACAMOLE-659:
--
If you want the Docker image to use a {{GUACAMOLE_HOME}} that comes from a
volume mount (is not entirely derived from environment variables), you need to
explicitly set {{GUACAMOLE_HOME}}. The Docker image has special handling for
this variable that copies things in place, applying your volume mount as a
template.
http://guacamole.apache.org/doc/gug/guacamole-docker.html#guacamole-docker-guacamole-home
See also: GUACAMOLE-281
> Docker Image does not allow default authentication
> --
>
> Key: GUACAMOLE-659
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-659
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-client
>Affects Versions: 0.9.14
>Reporter: Tom Kent
>Priority: Major
>
> When starting a docker image, I mount a directory with a guacamole.properties
> and user-mapping.xml:
> {{docker run --name some-guac --link some-guacd:guacd -p 8080:8080 -v
> $PWD/settings:/etc/guacamole guacamole/guacamole}}
> However, when the instance starts up, it immediately fails because there is
> no mysql, postgres, or LDAP authentication.
> {{FATAL: No authentication configured}}
> {{---}}
> {{The Guacamole Docker container needs at least one authentication mechanism
> in}}
> {{order to function, such as a MySQL database, PostgreSQL database, or LDAP}}
> {{directory. Please specify at least the MYSQL_DATABASE or POSTGRES_DATABASE}}
> {{environment variables, or check Guacamole's Docker documentation regarding}}
> {{configuring LDAP and/or custom extensions.}}
> Ideally, there would be a check in
> guacamole-client/guacamole-docker/bin/start.sh to see if user-mapping.xml
> exists in $GUACAMOLE_HOME and allow it to proceed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GUACAMOLE-658) Launch Kubernetes (X)RDP pods with OpenID Connect injected credentials
[ https://issues.apache.org/jira/browse/GUACAMOLE-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper resolved GUACAMOLE-658. -- Resolution: Invalid > Launch Kubernetes (X)RDP pods with OpenID Connect injected credentials > -- > > Key: GUACAMOLE-658 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-658 > Project: Guacamole > Issue Type: New Feature >Reporter: Bolke de Bruin >Priority: Minor > > Hi, > We would like to leverage Gaucamole to launch secure isolated XRDP pods on > k8s / openshift. > So imagine a user logs in into gaucamole with OpenID connect and is then able > to launch his personal Pod that has his user configured in the Pod. Upon > logout the Pod will be destroyed (configurable). > Configuring the user could happen similary to "cloudinit" where in this case > guacamole would function as a metadata server or by injecting the oauth token > directly into the Pod and then having the pod update itself. > It would require gaucamole to be able to launch, destroy and monitor pods and > maybe function as a metadata server. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GUACAMOLE-611) Selectively fall through to other extensions when authentication fails
[ https://issues.apache.org/jira/browse/GUACAMOLE-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper resolved GUACAMOLE-611. -- Resolution: Done Fix Version/s: 2.0.0 > Selectively fall through to other extensions when authentication fails > -- > > Key: GUACAMOLE-611 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-611 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Reporter: Michael Jumper >Assignee: Michael Jumper >Priority: Minor > Fix For: 2.0.0 > > > Currently, Guacamole's authentication extensions will explicitly fail with > exceptions when upstream server expectations fail, such as when the LDAP > server goes down, the MySQL / PostgreSQL database becomes unavailable, etc. > If this happens, processing of other extensions halts (as any exceptions > aborts the authentication process), and it becomes impossible to log into > Guacamole until the problem is resolved. > While it made sense for LDAP and other extensions to abort authentication > entirely in cases back when Guacamole could only use one authentication > mechanism at a time, there is no need for this to still be the case. Servers > with multiple authentication mechanisms enabled should be able to rely on > remaining mechanisms to succeed if one mechanism goes down. > Specifically: > # Multi-factor authentication extensions (currently Duo and TOTP) should > always either 100% work or block authentication entirely (failure of the > secondary authentication factor shouldn't result in the removal of that > factor, as that would present a security problem). > # If configured to do so, normal authentication extensions (LDAP, MySQL, > PostgreSQL, etc.) should log failures but otherwise behave as if the > extension is not installed, thus allowing other authentication mechanisms to > continue working. If _not_ configured in this way, Guacamole's existing > all-or-nothing behavior should continue as the safe default. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-657) Unexpected behaviour of modifier keys when opening Guacamole menu
[
https://issues.apache.org/jira/browse/GUACAMOLE-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682520#comment-16682520
]
Michael Jumper commented on GUACAMOLE-657:
--
When pressing Ctrl+Alt+Shift (in that order), the following events are sent by
the client:
* Ctrl down
* Alt down
* Shift up
* Ctrl up
* Alt up
This can be confirmed through adding logging to {{sendKeyEvent()}} of
{{Guacamole.Client}} using the browser's dev tools:
!sendkeyevent-ctrl-alt-shift.png!
Testing against VNC, those press and release events are correctly sent from
guacd to the VNC server (note that the Shift release is dropped by the VNC
server as it was not pressed in the first place - this is fine):
!vnc-xev-ctrl-alt-shift.png!
With RDP, again those press and release events are correctly sent from guacd to
the RDP server:
!rdp-key-viewer-ctrl-alt-shift.png!
> Unexpected behaviour of modifier keys when opening Guacamole menu
> -
>
> Key: GUACAMOLE-657
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-657
> Project: Guacamole
> Issue Type: Bug
> Components: RDP
>Affects Versions: 0.9.14
> Environment: Host: macOS Mojave
> Browser: Chrome 70
> Guest: Kali Linux (VirtualBox 5.2.18)
>Reporter: Kaspar Hageman
>Priority: Minor
> Attachments: rdp-key-viewer-ctrl-alt-shift.png,
> sendkeyevent-ctrl-alt-shift.png, vnc-xev-ctrl-alt-shift.png
>
>
> When opening the Guacamole menu, during an RDP session with a VM, with the
> default key combination (Ctrl + Cmd + Shift), the VM does observe key events
> as expected.
> For instance, when pressing Ctrl + Cmd + Shift (in that order), the following
> key events can be observed (using Chrome's developer tools):
> * Ctrl pressed
> * Cmd pressed
> * Shift released
> * Ctrl released
> * Cmd released
> However, in the VM, the following key events can be observed (using xev):
> * Ctrl pressed
> Has been tested with both version 0.9.14 and the current master branch
> (d4f58f2c0d812b05c392e06438e659902e8121f8)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-657) Unexpected behaviour of modifier keys when opening Guacamole menu
[ https://issues.apache.org/jira/browse/GUACAMOLE-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-657: - Attachment: sendkeyevent-ctrl-alt-shift.png > Unexpected behaviour of modifier keys when opening Guacamole menu > - > > Key: GUACAMOLE-657 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-657 > Project: Guacamole > Issue Type: Bug > Components: RDP >Affects Versions: 0.9.14 > Environment: Host: macOS Mojave > Browser: Chrome 70 > Guest: Kali Linux (VirtualBox 5.2.18) >Reporter: Kaspar Hageman >Priority: Minor > Attachments: rdp-key-viewer-ctrl-alt-shift.png, > sendkeyevent-ctrl-alt-shift.png, vnc-xev-ctrl-alt-shift.png > > > When opening the Guacamole menu, during an RDP session with a VM, with the > default key combination (Ctrl + Cmd + Shift), the VM does observe key events > as expected. > For instance, when pressing Ctrl + Cmd + Shift (in that order), the following > key events can be observed (using Chrome's developer tools): > * Ctrl pressed > * Cmd pressed > * Shift released > * Ctrl released > * Cmd released > However, in the VM, the following key events can be observed (using xev): > * Ctrl pressed > Has been tested with both version 0.9.14 and the current master branch > (d4f58f2c0d812b05c392e06438e659902e8121f8) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-657) Unexpected behaviour of modifier keys when opening Guacamole menu
[ https://issues.apache.org/jira/browse/GUACAMOLE-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-657: - Attachment: rdp-key-viewer-ctrl-alt-shift.png vnc-xev-ctrl-alt-shift.png > Unexpected behaviour of modifier keys when opening Guacamole menu > - > > Key: GUACAMOLE-657 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-657 > Project: Guacamole > Issue Type: Bug > Components: RDP >Affects Versions: 0.9.14 > Environment: Host: macOS Mojave > Browser: Chrome 70 > Guest: Kali Linux (VirtualBox 5.2.18) >Reporter: Kaspar Hageman >Priority: Minor > Attachments: rdp-key-viewer-ctrl-alt-shift.png, > vnc-xev-ctrl-alt-shift.png > > > When opening the Guacamole menu, during an RDP session with a VM, with the > default key combination (Ctrl + Cmd + Shift), the VM does observe key events > as expected. > For instance, when pressing Ctrl + Cmd + Shift (in that order), the following > key events can be observed (using Chrome's developer tools): > * Ctrl pressed > * Cmd pressed > * Shift released > * Ctrl released > * Cmd released > However, in the VM, the following key events can be observed (using xev): > * Ctrl pressed > Has been tested with both version 0.9.14 and the current master branch > (d4f58f2c0d812b05c392e06438e659902e8121f8) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-657) Unexpected behaviour of modifier keys when opening Guacamole menu
[ https://issues.apache.org/jira/browse/GUACAMOLE-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-657: - Attachment: (was: image-2018-11-10-08-55-57-411.png) > Unexpected behaviour of modifier keys when opening Guacamole menu > - > > Key: GUACAMOLE-657 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-657 > Project: Guacamole > Issue Type: Bug > Components: RDP >Affects Versions: 0.9.14 > Environment: Host: macOS Mojave > Browser: Chrome 70 > Guest: Kali Linux (VirtualBox 5.2.18) >Reporter: Kaspar Hageman >Priority: Minor > Attachments: rdp-key-viewer-ctrl-alt-shift.png, > vnc-xev-ctrl-alt-shift.png > > > When opening the Guacamole menu, during an RDP session with a VM, with the > default key combination (Ctrl + Cmd + Shift), the VM does observe key events > as expected. > For instance, when pressing Ctrl + Cmd + Shift (in that order), the following > key events can be observed (using Chrome's developer tools): > * Ctrl pressed > * Cmd pressed > * Shift released > * Ctrl released > * Cmd released > However, in the VM, the following key events can be observed (using xev): > * Ctrl pressed > Has been tested with both version 0.9.14 and the current master branch > (d4f58f2c0d812b05c392e06438e659902e8121f8) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-657) Unexpected behaviour of modifier keys when opening Guacamole menu
[ https://issues.apache.org/jira/browse/GUACAMOLE-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-657: - Attachment: (was: image-2018-11-10-08-55-57-362.png) > Unexpected behaviour of modifier keys when opening Guacamole menu > - > > Key: GUACAMOLE-657 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-657 > Project: Guacamole > Issue Type: Bug > Components: RDP >Affects Versions: 0.9.14 > Environment: Host: macOS Mojave > Browser: Chrome 70 > Guest: Kali Linux (VirtualBox 5.2.18) >Reporter: Kaspar Hageman >Priority: Minor > Attachments: rdp-key-viewer-ctrl-alt-shift.png, > vnc-xev-ctrl-alt-shift.png > > > When opening the Guacamole menu, during an RDP session with a VM, with the > default key combination (Ctrl + Cmd + Shift), the VM does observe key events > as expected. > For instance, when pressing Ctrl + Cmd + Shift (in that order), the following > key events can be observed (using Chrome's developer tools): > * Ctrl pressed > * Cmd pressed > * Shift released > * Ctrl released > * Cmd released > However, in the VM, the following key events can be observed (using xev): > * Ctrl pressed > Has been tested with both version 0.9.14 and the current master branch > (d4f58f2c0d812b05c392e06438e659902e8121f8) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-657) Unexpected behaviour of modifier keys when opening Guacamole menu
[ https://issues.apache.org/jira/browse/GUACAMOLE-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-657: - Attachment: image-2018-11-10-08-55-57-362.png > Unexpected behaviour of modifier keys when opening Guacamole menu > - > > Key: GUACAMOLE-657 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-657 > Project: Guacamole > Issue Type: Bug > Components: RDP >Affects Versions: 0.9.14 > Environment: Host: macOS Mojave > Browser: Chrome 70 > Guest: Kali Linux (VirtualBox 5.2.18) >Reporter: Kaspar Hageman >Priority: Minor > Attachments: image-2018-11-10-08-55-57-362.png, > image-2018-11-10-08-55-57-411.png > > > When opening the Guacamole menu, during an RDP session with a VM, with the > default key combination (Ctrl + Cmd + Shift), the VM does observe key events > as expected. > For instance, when pressing Ctrl + Cmd + Shift (in that order), the following > key events can be observed (using Chrome's developer tools): > * Ctrl pressed > * Cmd pressed > * Shift released > * Ctrl released > * Cmd released > However, in the VM, the following key events can be observed (using xev): > * Ctrl pressed > Has been tested with both version 0.9.14 and the current master branch > (d4f58f2c0d812b05c392e06438e659902e8121f8) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-657) Unexpected behaviour of modifier keys when opening Guacamole menu
[ https://issues.apache.org/jira/browse/GUACAMOLE-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-657: - Attachment: image-2018-11-10-08-55-57-411.png > Unexpected behaviour of modifier keys when opening Guacamole menu > - > > Key: GUACAMOLE-657 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-657 > Project: Guacamole > Issue Type: Bug > Components: RDP >Affects Versions: 0.9.14 > Environment: Host: macOS Mojave > Browser: Chrome 70 > Guest: Kali Linux (VirtualBox 5.2.18) >Reporter: Kaspar Hageman >Priority: Minor > Attachments: image-2018-11-10-08-55-57-362.png, > image-2018-11-10-08-55-57-411.png > > > When opening the Guacamole menu, during an RDP session with a VM, with the > default key combination (Ctrl + Cmd + Shift), the VM does observe key events > as expected. > For instance, when pressing Ctrl + Cmd + Shift (in that order), the following > key events can be observed (using Chrome's developer tools): > * Ctrl pressed > * Cmd pressed > * Shift released > * Ctrl released > * Cmd released > However, in the VM, the following key events can be observed (using xev): > * Ctrl pressed > Has been tested with both version 0.9.14 and the current master branch > (d4f58f2c0d812b05c392e06438e659902e8121f8) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-657) Unexpected behaviour of modifier keys when opening Guacamole menu
[
https://issues.apache.org/jira/browse/GUACAMOLE-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682188#comment-16682188
]
Michael Jumper commented on GUACAMOLE-657:
--
{quote}
Mapping the Windows key to Meta would solve this issue? Or is this a deliberate
design choice?
{quote}
It would result in a corresponding key event being received within the remote
desktop for the Command key. That said, I'm concerned that "fixing" the mapping
will result in real strange behavior for Mac users accessing Windows machines
when they reflexively type Command+Anything and end up opening the start menu.
Testing will need to be done before that deceptively minor change can be made
to the keymap.
{quote}
The "Ctrl" key release is not send from the browser to Guacamole as a WebSocket
frame (from what I can observe from the Chrome developer) and therefore will
never reach the VM in the first place. I would assume this is a legitimate bug.
{quote}
If this is true, then yes, but so far I am unable to reproduce what you
describe. Testing with a Mac, I see both a Ctrl press and release. I also don't
see how such a bug could exist given the way the Guacamole menu works - the
code that opens the menu also invokes {{reset()}} on the
{{Guacamole.Keyboard}}, sending release events for absolutely all pressed keys:
https://github.com/apache/guacamole-client/blob/823bbeace11063b249e3f05c2a1e5c5027107b96/guacamole/src/main/webapp/app/client/controllers/clientController.js#L540-L547
If a press event for any key was sent to the remote desktop, a corresponding
release event would then be sent when the menu is opened as a result of that
invocation of {{reset()}}. I'm thinking there must be some other cause behind
what you're seeing (an application within the remote desktop not receiving the
release event for Ctrl) which is not that Guacamole is not sending that event
(I expect it is).
> Unexpected behaviour of modifier keys when opening Guacamole menu
> -
>
> Key: GUACAMOLE-657
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-657
> Project: Guacamole
> Issue Type: Bug
> Components: RDP
>Affects Versions: 0.9.14
> Environment: Host: macOS Mojave
> Browser: Chrome 70
> Guest: Kali Linux (VirtualBox 5.2.18)
>Reporter: Kaspar Hageman
>Priority: Minor
>
> When opening the Guacamole menu, during an RDP session with a VM, with the
> default key combination (Ctrl + Cmd + Shift), the VM does observe key events
> as expected.
> For instance, when pressing Ctrl + Cmd + Shift (in that order), the following
> key events can be observed (using Chrome's developer tools):
> * Ctrl pressed
> * Cmd pressed
> * Shift released
> * Ctrl released
> * Cmd released
> However, in the VM, the following key events can be observed (using xev):
> * Ctrl pressed
> Has been tested with both version 0.9.14 and the current master branch
> (d4f58f2c0d812b05c392e06438e659902e8121f8)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-657) Unexpected behaviour of modifier keys when opening Guacamole menu
[ https://issues.apache.org/jira/browse/GUACAMOLE-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681728#comment-16681728 ] Michael Jumper commented on GUACAMOLE-657: -- The Mac "Command" key is the "Meta" key, but Meta does not have a mapping in RDP and thus will not be sent. You should still see a release event for Ctrl, but will not see the press/release events for Cmd. It might be more correct to modify the mapping to use Meta for the Windows key: https://github.com/apache/guacamole-server/blob/6f491946408224a231324663938df36c756b09d2/src/protocols/rdp/keymaps/base.keymap#L87-L88 I do see at least Chrome mapping the Windows key to Meta within JavaScript key events. > Unexpected behaviour of modifier keys when opening Guacamole menu > - > > Key: GUACAMOLE-657 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-657 > Project: Guacamole > Issue Type: Bug > Components: RDP >Affects Versions: 0.9.14 > Environment: Host: macOS Mojave > Browser: Chrome 70 > Guest: Kali Linux (VirtualBox 5.2.18) >Reporter: Kaspar Hageman >Priority: Major > > When opening the Guacamole menu, during an RDP session with a VM, with the > default key combination (Ctrl + Cmd + Shift), the VM does observe key events > as expected. > For instance, when pressing Ctrl + Cmd + Shift (in that order), the following > key events can be observed (using Chrome's developer tools): > * Ctrl pressed > * Cmd pressed > * Shift released > * Ctrl released > * Cmd released > However, in the VM, the following key events can be observed (using xev): > * Ctrl pressed > Has been tested with both version 0.9.14 and the current master branch > (d4f58f2c0d812b05c392e06438e659902e8121f8) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GUACAMOLE-656) Docker build of guacamole-client broken by recent update to maven:3-jdk-8
[
https://issues.apache.org/jira/browse/GUACAMOLE-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper resolved GUACAMOLE-656.
--
Resolution: Fixed
> Docker build of guacamole-client broken by recent update to maven:3-jdk-8
> -
>
> Key: GUACAMOLE-656
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-656
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-docker
>Affects Versions: 1.0.0
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Blocker
> Fix For: 1.0.0
>
>
> The guacamole-client Docker build uses the {{maven:3-jdk-8}} image as the
> build image. That image is currently broken for any Maven build involving
> tests due to SUREFIRE-1588, a bug in the Maven surefire plugin which results
> in a hard failure due to a bug in the updated version of OpenJDK 8 present on
> this image.
> This will presumably also break the guacamole-client build on any system with
> that version of OpenJDK 8.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-656) Docker build of guacamole-client broken by recent update to maven:3-jdk-8
[
https://issues.apache.org/jira/browse/GUACAMOLE-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16680918#comment-16680918
]
Michael Jumper commented on GUACAMOLE-656:
--
Note that while this issue arose during an automated build of GUACAMOLE-220, it
is not actually a result of those changes. A Docker build of guacamole-client
prior to those changes would still have failed.
> Docker build of guacamole-client broken by recent update to maven:3-jdk-8
> -
>
> Key: GUACAMOLE-656
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-656
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-docker
>Affects Versions: 1.0.0
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Blocker
> Fix For: 1.0.0
>
>
> The guacamole-client Docker build uses the {{maven:3-jdk-8}} image as the
> build image. That image is currently broken for any Maven build involving
> tests due to SUREFIRE-1588, a bug in the Maven surefire plugin which results
> in a hard failure due to a bug in the updated version of OpenJDK 8 present on
> this image.
> This will presumably also break the guacamole-client build on any system with
> that version of OpenJDK 8.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GUACAMOLE-656) Docker build of guacamole-client broken by recent update to maven:3-jdk-8
[
https://issues.apache.org/jira/browse/GUACAMOLE-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper reassigned GUACAMOLE-656:
Assignee: Michael Jumper
> Docker build of guacamole-client broken by recent update to maven:3-jdk-8
> -
>
> Key: GUACAMOLE-656
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-656
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-docker
>Affects Versions: 1.0.0
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Blocker
> Fix For: 1.0.0
>
>
> The guacamole-client Docker build uses the {{maven:3-jdk-8}} image as the
> build image. That image is currently broken for any Maven build involving
> tests due to SUREFIRE-1588, a bug in the Maven surefire plugin which results
> in a hard failure due to a bug in the updated version of OpenJDK 8 present on
> this image.
> This will presumably also break the guacamole-client build on any system with
> that version of OpenJDK 8.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GUACAMOLE-656) Docker build of guacamole-client broken by recent update to maven:3-jdk-8
Michael Jumper created GUACAMOLE-656:
Summary: Docker build of guacamole-client broken by recent update
to maven:3-jdk-8
Key: GUACAMOLE-656
URL: https://issues.apache.org/jira/browse/GUACAMOLE-656
Project: Guacamole
Issue Type: Bug
Components: guacamole-docker
Affects Versions: 1.0.0
Reporter: Michael Jumper
Fix For: 1.0.0
The guacamole-client Docker build uses the {{maven:3-jdk-8}} image as the build
image. That image is currently broken for any Maven build involving tests due
to SUREFIRE-1588, a bug in the Maven surefire plugin which results in a hard
failure due to a bug in the updated version of OpenJDK 8 present on this image.
This will presumably also break the guacamole-client build on any system with
that version of OpenJDK 8.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-654) No suitable keymap for canadian french
[ https://issues.apache.org/jira/browse/GUACAMOLE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-654: - Priority: Minor (was: Blocker) > No suitable keymap for canadian french > -- > > Key: GUACAMOLE-654 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-654 > Project: Guacamole > Issue Type: Bug > Components: guacamole >Affects Versions: 0.9.14 >Reporter: Stanislas Elie >Priority: Minor > > Hello. > > I can't find a suitable keymap to accommodate my french canadian users. The > unicode failsafe keymap does not allow copy/paste using ctrl-c ctrl-v > shortcuts. > I tried to make my own keymap as per > https://issues.apache.org/jira/browse/GUACAMOLE-233 , but I am stumped by the > rdp.json modification requirement. I can find no such file to modify. This > file appears to be part of the Guacamole client, but I only install the > "server" part. There is probably something I don't get. > > Can anyone help? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-654) No suitable keymap for canadian french
[ https://issues.apache.org/jira/browse/GUACAMOLE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-654: - Issue Type: Improvement (was: Bug) > No suitable keymap for canadian french > -- > > Key: GUACAMOLE-654 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-654 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Affects Versions: 0.9.14 >Reporter: Stanislas Elie >Priority: Minor > > Hello. > > I can't find a suitable keymap to accommodate my french canadian users. The > unicode failsafe keymap does not allow copy/paste using ctrl-c ctrl-v > shortcuts. > I tried to make my own keymap as per > https://issues.apache.org/jira/browse/GUACAMOLE-233 , but I am stumped by the > rdp.json modification requirement. I can find no such file to modify. This > file appears to be part of the Guacamole client, but I only install the > "server" part. There is probably something I don't get. > > Can anyone help? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-654) No suitable keymap for canadian french
[ https://issues.apache.org/jira/browse/GUACAMOLE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-654: - Fix Version/s: (was: 0.9.14) > No suitable keymap for canadian french > -- > > Key: GUACAMOLE-654 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-654 > Project: Guacamole > Issue Type: Bug > Components: guacamole >Affects Versions: 0.9.14 >Reporter: Stanislas Elie >Priority: Minor > > Hello. > > I can't find a suitable keymap to accommodate my french canadian users. The > unicode failsafe keymap does not allow copy/paste using ctrl-c ctrl-v > shortcuts. > I tried to make my own keymap as per > https://issues.apache.org/jira/browse/GUACAMOLE-233 , but I am stumped by the > rdp.json modification requirement. I can find no such file to modify. This > file appears to be part of the Guacamole client, but I only install the > "server" part. There is probably something I don't get. > > Can anyone help? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-654) Add RDP keymap for canadian french
[ https://issues.apache.org/jira/browse/GUACAMOLE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-654: - Summary: Add RDP keymap for canadian french (was: No suitable keymap for canadian french) > Add RDP keymap for canadian french > -- > > Key: GUACAMOLE-654 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-654 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Affects Versions: 0.9.14 >Reporter: Stanislas Elie >Priority: Minor > > Hello. > > I can't find a suitable keymap to accommodate my french canadian users. The > unicode failsafe keymap does not allow copy/paste using ctrl-c ctrl-v > shortcuts. > I tried to make my own keymap as per > https://issues.apache.org/jira/browse/GUACAMOLE-233 , but I am stumped by the > rdp.json modification requirement. I can find no such file to modify. This > file appears to be part of the Guacamole client, but I only install the > "server" part. There is probably something I don't get. > > Can anyone help? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-654) Add RDP keymap for canadian french
[
https://issues.apache.org/jira/browse/GUACAMOLE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678900#comment-16678900
]
Michael Jumper commented on GUACAMOLE-654:
--
{quote}
I am missing a few pointers...
{quote}
The d...@guacamole.apache.org list will be a good resource if you wish to give
things a shot:
http://guacamole.apache.org/support/#mailing-lists
If the ultimate goal of the issue you just opened (GUACAMOLE-655) is to allow
people such as yourself to create these keymaps, the mailing list thread
effectively documenting your struggle and learning process will be a good basis
for additional documentation satisfying GUACAMOLE-655.
> Add RDP keymap for canadian french
> --
>
> Key: GUACAMOLE-654
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-654
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole
>Affects Versions: 0.9.14
>Reporter: Stanislas Elie
>Priority: Minor
>
> Hello.
>
> I can't find a suitable keymap to accommodate my french canadian users. The
> unicode failsafe keymap does not allow copy/paste using ctrl-c ctrl-v
> shortcuts.
> I tried to make my own keymap as per
> https://issues.apache.org/jira/browse/GUACAMOLE-233 , but I am stumped by the
> rdp.json modification requirement. I can find no such file to modify. This
> file appears to be part of the Guacamole client, but I only install the
> "server" part. There is probably something I don't get.
>
> Can anyone help?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-655) keymap creation walkthrough
[
https://issues.apache.org/jira/browse/GUACAMOLE-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678897#comment-16678897
]
Michael Jumper commented on GUACAMOLE-655:
--
{quote}
... many key or key combinations do not work with the other keymaps or the
provided failsafe keyboard. This renders Guacamole unusable.
{quote}
If there are key combinations which cannot be typed remotely, despite the
keyboard of the remote desktop server having those keys and being properly set
as the server layout in the connection configuration, then another key map will
not help. The underlying issue preventing that key from being properly sent
needs to be addressed.
As mentioned on GUACAMOLE-654, please keep in mind that the client side of
Guacamole is independent of keyboard layout. It does not matter what keyboard
layout the client side is using. Key events sent through Guacamole are sent
using the identity of the key ("a", "B", etc.) and thus are unaffected by
layout, not the location of the key as RDP would send ("first key in second
row", "fifth key in third row", etc.) which is indeed dependent on layout.
The keymaps you refer to are used strictly on the server side. They tell
Guacamole how to translate each key identity ("a") into the scancode used by
RDP (the numeric equivalent of "first key in second row"). Since the RDP side
of this *does* depend on keyboard layout, Guacamole needs to know ahead of time
what keyboard layout the remote desktop server uses so it can translate.
> keymap creation walkthrough
> ---
>
> Key: GUACAMOLE-655
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-655
> Project: Guacamole
> Issue Type: Improvement
> Components: Documentation
>Reporter: Stanislas Elie
>Priority: Minor
>
> I notice several bug reports on the issue tracker related to missing keymap
> files. I realize it is not a priority for the Guacamole developer community,
> but it is a show stopper for the users affected. For example, I am unable to
> find a proper French Canadian keymap, as many key or key combinations do not
> work with the other keymaps or the provided failsafe keyboard. This renders
> Guacamole unusable.
>
> I would like to have a detailed (very detailed) walkthrough of how one can
> create their own keymap file, put it in the right place in the source tree, a
> list of files that need to be modified to accommodate the new keymap and
> re-build instructions. Such a walkthrough would allow some of us script
> kiddies to contribute a little, and would remove a little of the burden from
> the Guacamole devs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GUACAMOLE-654) Add RDP keymap for canadian french
[ https://issues.apache.org/jira/browse/GUACAMOLE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper closed GUACAMOLE-654. Resolution: Duplicate > Add RDP keymap for canadian french > -- > > Key: GUACAMOLE-654 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-654 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Affects Versions: 0.9.14 >Reporter: Stanislas Elie >Priority: Minor > > Hello. > > I can't find a suitable keymap to accommodate my french canadian users. The > unicode failsafe keymap does not allow copy/paste using ctrl-c ctrl-v > shortcuts. > I tried to make my own keymap as per > https://issues.apache.org/jira/browse/GUACAMOLE-233 , but I am stumped by the > rdp.json modification requirement. I can find no such file to modify. This > file appears to be part of the Guacamole client, but I only install the > "server" part. There is probably something I don't get. > > Can anyone help? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-655) keymap creation walkthrough
[ https://issues.apache.org/jira/browse/GUACAMOLE-655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-655: - Component/s: (was: guacamole) Documentation > keymap creation walkthrough > --- > > Key: GUACAMOLE-655 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-655 > Project: Guacamole > Issue Type: Improvement > Components: Documentation >Reporter: Stanislas Elie >Priority: Minor > > I notice several bug reports on the issue tracker related to missing keymap > files. I realize it is not a priority for the Guacamole developer community, > but it is a show stopper for the users affected. For example, I am unable to > find a proper French Canadian keymap, as many key or key combinations do not > work with the other keymaps or the provided failsafe keyboard. This renders > Guacamole unusable. > > I would like to have a detailed (very detailed) walkthrough of how one can > create their own keymap file, put it in the right place in the source tree, a > list of files that need to be modified to accommodate the new keymap and > re-build instructions. Such a walkthrough would allow some of us script > kiddies to contribute a little, and would remove a little of the burden from > the Guacamole devs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-655) keymap creation walkthrough
[ https://issues.apache.org/jira/browse/GUACAMOLE-655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper updated GUACAMOLE-655: - Priority: Minor (was: Blocker) > keymap creation walkthrough > --- > > Key: GUACAMOLE-655 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-655 > Project: Guacamole > Issue Type: Improvement > Components: Documentation >Reporter: Stanislas Elie >Priority: Minor > > I notice several bug reports on the issue tracker related to missing keymap > files. I realize it is not a priority for the Guacamole developer community, > but it is a show stopper for the users affected. For example, I am unable to > find a proper French Canadian keymap, as many key or key combinations do not > work with the other keymaps or the provided failsafe keyboard. This renders > Guacamole unusable. > > I would like to have a detailed (very detailed) walkthrough of how one can > create their own keymap file, put it in the right place in the source tree, a > list of files that need to be modified to accommodate the new keymap and > re-build instructions. Such a walkthrough would allow some of us script > kiddies to contribute a little, and would remove a little of the burden from > the Guacamole devs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-654) Add RDP keymap for canadian french
[
https://issues.apache.org/jira/browse/GUACAMOLE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678862#comment-16678862
]
Michael Jumper commented on GUACAMOLE-654:
--
{quote}
I appreciate it is a minor thing to the dev community, but it is still a show
stopper for me, hence the "blocker" tag.
{quote}
Well, feel free to mark it as a blocker in your JIRA then. ;) The
community/project JIRA will of course have the community/project priorities.
If it's an extremely high priority for you specifically, working to contribute
the keymap would get things done faster. We can easily merge such a keymap.
Contribution guidelines are on the website and also in the {{CONTRIBUTING}}
file in each repository:
http://guacamole.apache.org/open-source/#contribute
https://github.com/apache/guacamole-server/blob/master/CONTRIBUTING
> Add RDP keymap for canadian french
> --
>
> Key: GUACAMOLE-654
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-654
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole
>Affects Versions: 0.9.14
>Reporter: Stanislas Elie
>Priority: Minor
>
> Hello.
>
> I can't find a suitable keymap to accommodate my french canadian users. The
> unicode failsafe keymap does not allow copy/paste using ctrl-c ctrl-v
> shortcuts.
> I tried to make my own keymap as per
> https://issues.apache.org/jira/browse/GUACAMOLE-233 , but I am stumped by the
> rdp.json modification requirement. I can find no such file to modify. This
> file appears to be part of the Guacamole client, but I only install the
> "server" part. There is probably something I don't get.
>
> Can anyone help?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-654) Add RDP keymap for canadian french
[
https://issues.apache.org/jira/browse/GUACAMOLE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678859#comment-16678859
]
Michael Jumper commented on GUACAMOLE-654:
--
Keep in mind that the client side of Guacamole is actually independent of
keyboard layout. The keymap is only needed to tell Guacamole how to translate
the characters typed on the client side into the scancodes consumed by RDP on
the remote desktop side. All Guacamole needs to know in that case is the
keyboard layout of the *server*. If you know that your users will be primarily
using Canadian French keyboards, selecting a keyboard layout on the server
which has all or most of the same characters should work.
As far as contributing a keymap goes, please feel free to do so. Hopefully the
issue you point to (as well as the various others) are helpful there. You would
indeed need to update {{rdp.json}} so that users of the mainline Guacamole
webapp will be able to select your keymap. If you are only using guacd, that
doesn't affect you, but it's important regardless. Those JSON files are part of
guacamole-ext within guacamole-client.
Closing as duplicate of GUACAMOLE-607.
> Add RDP keymap for canadian french
> --
>
> Key: GUACAMOLE-654
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-654
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole
>Affects Versions: 0.9.14
>Reporter: Stanislas Elie
>Priority: Minor
>
> Hello.
>
> I can't find a suitable keymap to accommodate my french canadian users. The
> unicode failsafe keymap does not allow copy/paste using ctrl-c ctrl-v
> shortcuts.
> I tried to make my own keymap as per
> https://issues.apache.org/jira/browse/GUACAMOLE-233 , but I am stumped by the
> rdp.json modification requirement. I can find no such file to modify. This
> file appears to be part of the Guacamole client, but I only install the
> "server" part. There is probably something I don't get.
>
> Can anyone help?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-220) Implement user groups
[
https://issues.apache.org/jira/browse/GUACAMOLE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16675675#comment-16675675
]
Michael Jumper commented on GUACAMOLE-220:
--
Hopefully some of our fellow committers will swoop in. ;)
> Implement user groups
> -
>
> Key: GUACAMOLE-220
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-220
> Project: Guacamole
> Issue Type: Improvement
> Components: Documentation, guacamole, guacamole-auth-jdbc,
> guacamole-auth-ldap, guacamole-ext
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Major
> Fix For: 1.0.0
>
>
> {panel:bgColor=#EE}
> *The description of this issue was copied from
> [GUAC-1073|https://glyptodon.org/jira/browse/GUAC-1073], an issue in the JIRA
> instance used by the Guacamole project prior to its acceptance into the
> Apache Incubator.*
> Comments, attachments, related issues, and history from prior to acceptance
> *have not been copied* and can be found instead at the original issue.
> {panel}
> Guacamole should support tagging of users into logical user groups, such that
> permissions can be managed at a group level, rather than a per-user level.
> These permissions should include all available permission types, not simply
> "READ' as in the current management interface.
> With this in mind, the permission manipulation interface would need to be
> modified to support a more standard ACL-style interface at the connection
> level, allowing users or groups to be added to a connection, rather than
> connections added to a user or group.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-220) Implement user groups
[
https://issues.apache.org/jira/browse/GUACAMOLE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16675593#comment-16675593
]
Michael Jumper commented on GUACAMOLE-220:
--
I think things should be pretty ready now. Only outstanding documentation is a
new section for user group admin, along with new admin screenshots showing the
user group tab.
* LDAP support for groups: https://github.com/apache/guacamole-client/pull/337
* Correction to wording of group-specific "disabled" attribute:
https://github.com/apache/guacamole-client/pull/338
* Documentation for LDAP group support:
https://github.com/apache/guacamole-manual/pull/102
* Documentation for JDBC group support:
https://github.com/apache/guacamole-manual/pull/99
I'll try to knock out the screenshot/admin doc update today.
> Implement user groups
> -
>
> Key: GUACAMOLE-220
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-220
> Project: Guacamole
> Issue Type: Improvement
> Components: Documentation, guacamole, guacamole-auth-jdbc,
> guacamole-auth-ldap, guacamole-ext
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Major
> Fix For: 1.0.0
>
>
> {panel:bgColor=#EE}
> *The description of this issue was copied from
> [GUAC-1073|https://glyptodon.org/jira/browse/GUAC-1073], an issue in the JIRA
> instance used by the Guacamole project prior to its acceptance into the
> Apache Incubator.*
> Comments, attachments, related issues, and history from prior to acceptance
> *have not been copied* and can be found instead at the original issue.
> {panel}
> Guacamole should support tagging of users into logical user groups, such that
> permissions can be managed at a group level, rather than a per-user level.
> These permissions should include all available permission types, not simply
> "READ' as in the current management interface.
> With this in mind, the permission manipulation interface would need to be
> modified to support a more standard ACL-style interface at the connection
> level, allowing users or groups to be added to a connection, rather than
> connections added to a user or group.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GUACAMOLE-653) Printing in rdp causes guacd to crash
[ https://issues.apache.org/jira/browse/GUACAMOLE-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper resolved GUACAMOLE-653. -- Resolution: Invalid > Printing in rdp causes guacd to crash > - > > Key: GUACAMOLE-653 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-653 > Project: Guacamole > Issue Type: Bug > Components: RDP >Affects Versions: 0.9.9 >Reporter: Robins George >Priority: Major > > Users are unable to consistently print through guacamole > printer(redirection), there are some instances in which the print command > causes guacd to crash. > > The stack trace observed is, > Program terminated with signal 11, Segmentation fault. > #0 0x00271012 in pthread_join () from /lib/libpthread.so.0 > (gdb) bt > #0 0x00271012 in pthread_join () from /lib/libpthread.so.0 > #1 0x008139c5 in guac_rdpdr_process_print_job_close () from > /usr/lib/freerdp/guacdr.so > #2 0x008141a8 in ?? () from /usr/lib/freerdp/guacdr.so > #3 0x00812fa2 in guac_rdpdr_process_device_iorequest () from > /usr/lib/freerdp/guacdr.so > #4 0x00814637 in guac_rdpdr_process_receive () from /usr/lib/freerdp/guacdr.so > #5 0x0031de42 in svc_plugin_process_data_in (arg=0x8493038) at > /builddir/build/BUILD/freerdp-1.0.2/libfreerdp-utils/svc_plugin.c:249 > #6 svc_plugin_thread_func (arg=0x8493038) at > /builddir/build/BUILD/freerdp-1.0.2/libfreerdp-utils/svc_plugin.c:278 > #7 0x00270a49 in start_thread () from /lib/libpthread.so.0 > #8 0x00435afe in clone () from /lib/libc.so.6 > (gdb) > > Have anybody seen this issue before? > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-653) Printing in rdp causes guacd to crash
[
https://issues.apache.org/jira/browse/GUACAMOLE-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16675466#comment-16675466
]
Michael Jumper commented on GUACAMOLE-653:
--
{quote}
Have anybody seen this issue before?
{quote}
No, however you are also using a very old version (0.9.9). Please retest
against the latest version. If you are still encountering this after testing
against the latest, feel free to reopen this issue:
http://guacamole.apache.org/faq/#test-against-latest-version
As an aside, if you've recently upgraded guacamole-server or FreeRDP, that
could easily cause a segfault within one of the FreeRDP plugins built by
guacamole-server like {{guacdr.so}}. I suggest making sure that:
# {{guacdr.so}} and all other FreeRDP plugins built by guacamole-server are
actually the result of your latest build of guacamole-server, not an older
installation.
# If FreeRDP has been updated, rerun {{./configure}}, rebuild, and re-install
guacamole-server to make sure it builds against the version you have installed.
Even if the version number of FreeRDP appears to be essentially the same,
different versions of FreeRDP cannot be relied upon to be binary compatible.
> Printing in rdp causes guacd to crash
> -
>
> Key: GUACAMOLE-653
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-653
> Project: Guacamole
> Issue Type: Bug
> Components: RDP
>Affects Versions: 0.9.9
>Reporter: Robins George
>Priority: Major
>
> Users are unable to consistently print through guacamole
> printer(redirection), there are some instances in which the print command
> causes guacd to crash.
>
> The stack trace observed is,
> Program terminated with signal 11, Segmentation fault.
> #0 0x00271012 in pthread_join () from /lib/libpthread.so.0
> (gdb) bt
> #0 0x00271012 in pthread_join () from /lib/libpthread.so.0
> #1 0x008139c5 in guac_rdpdr_process_print_job_close () from
> /usr/lib/freerdp/guacdr.so
> #2 0x008141a8 in ?? () from /usr/lib/freerdp/guacdr.so
> #3 0x00812fa2 in guac_rdpdr_process_device_iorequest () from
> /usr/lib/freerdp/guacdr.so
> #4 0x00814637 in guac_rdpdr_process_receive () from /usr/lib/freerdp/guacdr.so
> #5 0x0031de42 in svc_plugin_process_data_in (arg=0x8493038) at
> /builddir/build/BUILD/freerdp-1.0.2/libfreerdp-utils/svc_plugin.c:249
> #6 svc_plugin_thread_func (arg=0x8493038) at
> /builddir/build/BUILD/freerdp-1.0.2/libfreerdp-utils/svc_plugin.c:278
> #7 0x00270a49 in start_thread () from /lib/libpthread.so.0
> #8 0x00435afe in clone () from /lib/libc.so.6
> (gdb)
>
> Have anybody seen this issue before?
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-652) Grayscale mode for image data and dynamic control of image quality
[ https://issues.apache.org/jira/browse/GUACAMOLE-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16674554#comment-16674554 ] Michael Jumper commented on GUACAMOLE-652: -- I'm not sure what you're saying about size reduction (the statement that something is 200% smaller does not make sense), but the overall concept behind the optimizer in the server is to balance bandwidth consumption with performance. If what you're suggesting is that Guacamole always send images in grayscale, or that an option be provided to force that behavior, I don't think that would be a good design decision. Automatically reducing quality even of images that would normally be sent in lossless form could make sense, but the decision whether to do so would need to be made carefully, and the heuristics involved would need to be fast enough that making the decision doesn't cancel out the benefit. To clarify, I'm not saying that Guacamole will automatically use grayscale for color images (which would result in an unnecessary reduction in image fidelity), but that an image that is already grayscale will automatically be sent as such. For graphical updates which are truly full color, the image will be sent losslessly preserving the content unless heuristics determine that the image would be better sent using a lossy format. If there is a graphical update that you think Guacamole should have automatically sent with reduced quality or fewer colors, I'd be interested to see the content of that update. > Grayscale mode for image data and dynamic control of image quality > -- > > Key: GUACAMOLE-652 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-652 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Reporter: george >Priority: Major > > Grayscale mode for image is the Magic Wand, when client is behind the poor > internet bandwidth. > The grayscale images up to 2-3 times smaller, but make no discomfort when > work with 90% of tasks, except graphics. > Switch the guacd <> client color and quality mode dynamic at protocol level > will be the super improvement, so client able to analyze bandwidth switch the > best performance mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
