[jira] [Commented] (GUACAMOLE-283) HA in Guacamole
[ https://issues.apache.org/jira/browse/GUACAMOLE-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16738133#comment-16738133 ] Nick Couchman commented on GUACAMOLE-283: - [~Rajesh35] The status on this JIRA issue has not changed, so nothing has been done with this, yet. If you have a question about configuring Guacamole, the mailing lists are the better place to have those discussions. > HA in Guacamole > --- > > Key: GUACAMOLE-283 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-283 > Project: Guacamole > Issue Type: New Feature > Components: guacamole-client, guacamole-server >Reporter: Thiago dos Santos Nunes >Priority: Minor > > A great feature for guacamole would be high availability both on the client > (mainly) and on the server. > In the client the ideal would be to be able to at least be able to block by > the number of simultaneous connections even having an environment with > several vms or containers. > I currently have an environment with 3 guacamole servers with Tomcat 8 > running behind a HAPROXY. But I lose the block by simultaneous connection (I > charge my clients for simultaneous connection) and I can not give up having > more than one vm, because if one falls I lose all. It would also be great if > the user does not need to log in again if they go to another server (session > permanence). Today I work with hundreds of simultaneous users from different > places. > It would also be very good to be able to separate the client from the server > and be able to work on HA on the server as well. > My Environment: > 3x Guacamole server and client: 0.9.12 > Database and Authentication: MySQL (another vm) > File Server: SFTP (another vm) > I alread commented this on: > https://issues.apache.org/jira/browse/GUACAMOLE-189 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[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 ] Nick Couchman updated GUACAMOLE-688: Priority: Minor (was: Major) > 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 > Original Estimate: 20m > Remaining Estimate: 20m > > "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-600) Allow specifying connection timeout
[ https://issues.apache.org/jira/browse/GUACAMOLE-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16734996#comment-16734996 ] Nick Couchman commented on GUACAMOLE-600: - FWIW, I'm ont sure this is going to be feasible in VNC and RDP connections. SSH and Telnet are pretty straight-forward, as they use the standard socket library for opening the connections, and there are methods available for handling timeouts with those libraries. Because the VNC and RDP connections abstract this to their respective libraries, there isn't really much way to control this. It also seems that, with FreeRDP specifically, the developers have rejected requests to allow timeout to be specified: https://github.com/FreeRDP/FreeRDP/issues/4723 We could try to integrate this timeout support into the auto-reconnect, but since Guacamole Client handles that internally, I'm not sure there's really much point? > Allow specifying connection timeout > --- > > Key: GUACAMOLE-600 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-600 > Project: Guacamole > Issue Type: New Feature > Components: RDP, SSH, Telnet, VNC >Reporter: Nick Couchman >Priority: Minor > > This came up in a mailing list discussion, specifically related to SSH > connections, but seems like it would be useful across all of the protocols to > allow the connection to specify the timeout in making the connection. For > environments where connections are expected to happen rapidly this can reduce > delays if something is wrong; for environments that may experience larger > delays it can avoid errors when the connection is expected to take a longer > amount of time to establish. -- 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=16734317#comment-16734317 ] Nick Couchman commented on GUACAMOLE-687: - Would be helpful to know what failure result is being returned? Also would be useful to see the error messages from the Guacamole Client container (catalina.out messages). > 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 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 -- 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 ] Nick Couchman updated GUACAMOLE-687: Labels: LDAP docker (was: LDAP bug 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 > 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 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 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[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=16732652#comment-16732652
]
Nick Couchman commented on GUACAMOLE-601:
-
[~khchew80] Any update on this?
> 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
>
[jira] [Closed] (GUACAMOLE-620) User input thread automatically exit with an instruction parse error
[
https://issues.apache.org/jira/browse/GUACAMOLE-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman closed GUACAMOLE-620.
---
Resolution: Invalid
> User input thread automatically exit with an instruction parse error
>
>
> Key: GUACAMOLE-620
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-620
> Project: Guacamole
> Issue Type: Bug
> Components: libguac
>Affects Versions: 0.9.14
>Reporter: Changkun Ou
>Priority: Minor
> Attachments: connection.pcap, read-log.txt, write-log.txt
>
>
> Remote desktop protocol: RDP
> User experience:
> A user operates a few minutes, then the desktop display froze. A browser
> refresh can connect to the server desktop again.
> Under the hood:
> Observed `guacd` log shows the user is disconnected.
> A warning level log shows that {{guac_user_input_thread}} automatically exit
> with an instruction parser error:
> {code}
> Guacamole connection failure: Instruction parse error
> {code}
> Here is a happening context captured in a browser, where the server sends
> {{10.disconnect}} since last {{sync}} instruction:
>
> {code}
> server: 4.sync,8.24744179;
> client: 4.sync,8.24744179;
> client: 5.mouse,3.667,3.459,1.1;
> client: 5.mouse,3.627,3.470,1.1;
> client: 5.mouse,3.597,3.470,1.1;
> client: 5.mouse,3.493,3.442,1.1;
> server: 4.copy,1.0,3.241,3.368,3.617,3.355,2.14,1.0,1.0,3.377;
> server: 4.copy,1.0,3.241,3.366,3.616,1.2,2.14,1.0,1.0,3.375;
> server: 4.copy,1.0,3.241,3.365,3.615,1.1,2.14,1.0,1.0,3.374;
> server: 4.copy,1.0,3.241,3.364,3.613,1.1,2.14,1.0,1.0,3.373;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.220,3.364;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.284,3.364;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.348,3.364;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.412,3.364;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.476,3.364;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.540,3.364;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.604,3.364;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.668,3.364;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.732,3.364;
> server: 4.copy,4.-113,1.0,1.0,2.58,1.1,2.14,1.0,3.796,3.364;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.218,3.365;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.282,3.365;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.346,3.365;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.410,3.365;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.474,3.365;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.538,3.365;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.602,3.365;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.666,3.365;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.730,3.365;
> server: 4.copy,4.-114,1.0,1.0,2.62,1.1,2.14,1.0,3.794,3.365;
> server: 4.copy,3.-26,1.0,1.0,2.64,1.2,2.14,1.0,3.217,3.366;
> server: 4.copy,3.-26,1.0,1.0,2.64,1.2,2.14,1.0,3.281,3.366;
> server: 4.copy,3.-26,1.0,1.0,2.64,1.2,2.14,1.0,3.345,3.366;
> server: 4.copy,3.-26,1.0,1.0,2.64,1.2,2.14,1.0,3.409,3.366;
> server: 4.copy,3.-26,1.0,1.0,2.64,1.2,2.14,1.0,3.473,3.366;
> server: 4.copy,3.-26,1.0,1.0,2.64,1.2,2.14,1.0,3.537,3.366;
> server: 4.copy,3.-26,1.0,1.0,2.64,1.2,2.14,1.0,3.601,3.366;
> server: 4.copy,3.-26,1.0,1.0,2.64,1.2,2.14,1.0,3.665,3.366;
> server: 4.copy,3.-26,1.0,1.0,2.64,1.2,2.14,1.0,3.729,3.366;
> server: 4.copy,3.-26,1.0,1.0,2.64,1.2,2.14,1.0,3.793,3.366;
> server: 4.copy,4.-594,1.0,1.0,2.64,1.5,2.14,1.0,3.216,3.368;
> server: 4.copy,4.-594,1.0,1.0,2.64,1.5,2.14,1.0,3.280,3.368;
> server: 4.copy,4.-594,1.0,1.0,2.64,1.5,2.14,1.0,3.344,3.368;
> server: 4.copy,4.-594,1.0,1.0,2.64,1.5,2.14,1.0,3.408,3.368;
> server: 4.copy,4.-594,1.0,1.0,2.64,1.5,2.14,1.0,3.472,3.368;
> server: 4.copy,4.-594,1.0,1.0,2.64,1.5,2.14,1.0,3.536,3.368;
> server: 4.copy,4.-594,1.0,1.0,2.64,1.5,2.14,1.0,3.600,3.368;
> server: 4.copy,4.-594,1.0,1.0,2.64,1.5,2.14,1.0,3.664,3.368;
> server: 4.copy,4.-594,1.0,1.0,2.64,1.5,2.14,1.0,3.728,3.368;
> server: 4.copy,4.-594,1.0,1.0,2.64,1.5,2.14,1.0,3.792,3.368;
> server: 3.img,1.3,2.14,1.0,9.image/png,3.856,3.368;
> server:
> 4.blob,1.3,112.iVBORw0KGgoNSUhEUgIFAQMAAABVfa/fA1BMVEUQIDF/BroyC0lEQVQImWNggAEAAAoAAWeL7ekASUVORK5CYII=;
> server: 3.end,1.3;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.613,3.373;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.677,3.373;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.741,3.373;
> server: 4.copy,4.-634,1.0,1.0,2.53,1.1,2.14,1.0,3.805,3.373;
> server: 4.copy,4.-634,1.0,1.0,2.53,1.1,2.14,1.0,3.805,3.373;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.679,3.374;
> server: 4.copy,3.-25,1.0,1.0,2.64,1.1,2.14,1.0,3.743,3.374;
> server: 4.copy,4.-635,1.0,1.0,2.51,1.1,2.14,1.0,3.807,3.374;
> server:
[jira] [Commented] (GUACAMOLE-643) Filter should not hide connection group
[ https://issues.apache.org/jira/browse/GUACAMOLE-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732645#comment-16732645 ] Nick Couchman commented on GUACAMOLE-643: - The connection groups are being hidden because there are no visible connections under those groups, so the groups do not apply anymore. Is there a reason you want to list the connection groups when no applicable connections are present? > Filter should not hide connection group > --- > > Key: GUACAMOLE-643 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-643 > Project: Guacamole > Issue Type: Wish > Components: guacamole >Reporter: Claudio Signorini >Priority: Minor > > Hi! > Is there a way (or can be implemented) to configure a connection group that > filters do not hide even if the name does not match? > Example... I use connection group to group connection by environment: > * development > ** abc1.cow.it > ** abc2.cow.it > * production > ** abc3.cow.it > When I type "abc" in the filter, the two connection groups hide. And I can't > understand the environment of the connection. I would like the connection > group won't hide. > Thanks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-429) RDP may join on invalid thread during disconnect
[
https://issues.apache.org/jira/browse/GUACAMOLE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732638#comment-16732638
]
Nick Couchman commented on GUACAMOLE-429:
-
Are you getting the Segfault when you try to run those connections, or is it a
different error?
> RDP may join on invalid thread during disconnect
>
>
> Key: GUACAMOLE-429
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-429
> Project: Guacamole
> Issue Type: Bug
> Components: RDP
>Affects Versions: 0.9.12-incubating
> Environment: GNU Linux x86_64
>Reporter: James He
>Priority: Minor
>
> Open 100 RDP connections at the same time with the below python script on
> Windows.
> {code:none}
> import webbrowser
> for i in range(100):
>
> webbrowser.open_new_tab('http://10.148.38.170:8080/guacamole-0.9.13-incubating/#/client/cmRwAGMAZGVmYXVsdA==')
> {code}
> Some connections disconnected and observed the below core dump of guacd.
> {code:none}
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 pthread_join (threadid=0, thread_return=0x0) at pthread_join.c:47
> 47 pthread_join.c: No such file or directory.
> (gdb) bt
> #0 pthread_join (threadid=0, thread_return=0x0) at pthread_join.c:47
> #1 0x2fb6826c in guac_rdp_client_free_handler
> (client=0x2aaad4007990) at client.c:96
> #2 0x2af45815 in guac_client_free (client=0x2aaad4007990) at
> client.c:193
> #3 0x00404d72 in guacd_exec_proc (proc=0x2aaad4007970,
> protocol=0x2aaad400bda3 "rdp") at proc.c:191
> #4 0x00404f3e in guacd_create_proc (protocol=0x2aaad400bda3 "rdp")
> at proc.c:253
> #5 0x00403bb8 in guacd_route_connection (map=0x2aad7010,
> socket=0x2aaad4005890)
> at connection.c:299
> #6 0x00403dc0 in guacd_connection_thread (data=0xe12b10) at
> connection.c:394
> #7 0x2b8521a4 in start_thread (arg=0x2aab0a023700) at
> pthread_create.c:309
> #8 0x2bd5965d in clone () from /lib64/libc.so.6
> (gdb) frame 1
> #1 0x2fb6826c in guac_rdp_client_free_handler
> (client=0x2aaad4007990) at client.c:96
> 96 pthread_join(rdp_client->client_thread, NULL);
> (gdb) p rdp_client->client_thread
> $5 = 0
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-343) Recording option should get a checkbox to enable/disable recording
[ https://issues.apache.org/jira/browse/GUACAMOLE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732094#comment-16732094 ] Nick Couchman commented on GUACAMOLE-343: - Could make the checkbox disable recording, and have it record if there is a value in the path, and the box is *not* checked?? > Recording option should get a checkbox to enable/disable recording > -- > > Key: GUACAMOLE-343 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-343 > Project: Guacamole > Issue Type: Wish > Components: guacamole, guacamole-ext, guacamole-server >Reporter: Peter M. >Priority: Minor > > The "Screen Recording" and "Typescript (Text Session Recording) option should > receive a checkbox to enable/disable recording. Currently recording is > enabled by configuring a recording or typescript path and name. > Currently it is not possible to setup the recording path and name without > automatically starting to record. An additional checkbox like > [ ] Enable Recording > would be nice. So you could then preconfigure the paths, filenames per > connection, easily clone or preconfigure them. When recording is needed you > just need to enable the checkbox. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-429) RDP may join on invalid thread during disconnect
[
https://issues.apache.org/jira/browse/GUACAMOLE-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16732087#comment-16732087
]
Nick Couchman commented on GUACAMOLE-429:
-
[~sanhex] Any idea if this issue still occurs in either 0.9.14 or the current
code in the git repo?
> RDP may join on invalid thread during disconnect
>
>
> Key: GUACAMOLE-429
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-429
> Project: Guacamole
> Issue Type: Bug
> Components: RDP
>Affects Versions: 0.9.12-incubating
> Environment: GNU Linux x86_64
>Reporter: James He
>Priority: Minor
>
> Open 100 RDP connections at the same time with the below python script on
> Windows.
> {code:none}
> import webbrowser
> for i in range(100):
>
> webbrowser.open_new_tab('http://10.148.38.170:8080/guacamole-0.9.13-incubating/#/client/cmRwAGMAZGVmYXVsdA==')
> {code}
> Some connections disconnected and observed the below core dump of guacd.
> {code:none}
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 pthread_join (threadid=0, thread_return=0x0) at pthread_join.c:47
> 47 pthread_join.c: No such file or directory.
> (gdb) bt
> #0 pthread_join (threadid=0, thread_return=0x0) at pthread_join.c:47
> #1 0x2fb6826c in guac_rdp_client_free_handler
> (client=0x2aaad4007990) at client.c:96
> #2 0x2af45815 in guac_client_free (client=0x2aaad4007990) at
> client.c:193
> #3 0x00404d72 in guacd_exec_proc (proc=0x2aaad4007970,
> protocol=0x2aaad400bda3 "rdp") at proc.c:191
> #4 0x00404f3e in guacd_create_proc (protocol=0x2aaad400bda3 "rdp")
> at proc.c:253
> #5 0x00403bb8 in guacd_route_connection (map=0x2aad7010,
> socket=0x2aaad4005890)
> at connection.c:299
> #6 0x00403dc0 in guacd_connection_thread (data=0xe12b10) at
> connection.c:394
> #7 0x2b8521a4 in start_thread (arg=0x2aab0a023700) at
> pthread_create.c:309
> #8 0x2bd5965d in clone () from /lib64/libc.so.6
> (gdb) frame 1
> #1 0x2fb6826c in guac_rdp_client_free_handler
> (client=0x2aaad4007990) at client.c:96
> 96 pthread_join(rdp_client->client_thread, NULL);
> (gdb) p rdp_client->client_thread
> $5 = 0
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-686) HTTP Header Auth ignores LDAP configuration
[ https://issues.apache.org/jira/browse/GUACAMOLE-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16731721#comment-16731721 ] Nick Couchman commented on GUACAMOLE-686: - You can't - this configuration won't work, for a couple of reasons. The LDAP module uses LDAP's built-in security and access control to determine what connections a user has access to. In order to accomplish this, the LDAP module first authenticates with the search user specified in the configuration (if applicable), and then authenticates with the information (username and password) of the user who is logging in. It uses the search to attempt to locate the user DN in the LDAP tree, and, failing that, computes the DN of the user based on the username and the user base DN. Because the LDAP module functions this way, it _requires_ the password to be present during authentication, and, if you're using the Header authentication module, the password is not available to Guacamole because the authentication is being done outside of Guacamole and Guacamole is trusting the authentication provided outside of the module. Even with another module, like CAS, that can provide the password back to Guacamole (CAS uses a feature called ClearPass to do this), I don't believe this configuration would work, because the user is already authenticated prior to the LDAP module being called, so the LDAP module will not attempt to bind under that user account due to the prior successful authentication. > 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] [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 ] Nick Couchman closed GUACAMOLE-686. --- Resolution: Won't Fix > 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] [Created] (GUACAMOLE-685) Allow Guacamole Server to Maintain Disconnected Sessions
Nick Couchman created GUACAMOLE-685: --- Summary: Allow Guacamole Server to Maintain Disconnected Sessions Key: GUACAMOLE-685 URL: https://issues.apache.org/jira/browse/GUACAMOLE-685 Project: Guacamole Issue Type: Improvement Components: guacd Reporter: Nick Couchman I'm proposing a change to Guacamole, particularly guacd, to allow for disconnecting sessions in such a way that guacd maintains the sessions in the background and allows those sessions to be resumed later. This would allow for overall session persistence, even with connections that don't natively support it (pretty much everything but RDP). This would, at a minimum, require some sort of signaling between the Guacamole Client and guacd stating that a session is being disconnected, or, perhaps, a change in the default behavior such that sessions are maintained by guacd unless they are explicitly shut down by the client. The API and guacd already support joining an existing session, so the support should already be in place to allow for joining the existing session, so long as it is maintained by guacd. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-684) Insufficient Credentials Should Take Precedence over Invalid Credentials
[ https://issues.apache.org/jira/browse/GUACAMOLE-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-684: Fix Version/s: (was: 1.0.0) > Insufficient Credentials Should Take Precedence over Invalid Credentials > > > Key: GUACAMOLE-684 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-684 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Affects Versions: 1.0.0 >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Minor > > The implementation of several modules that support 2FA/MFA has resulted in > some scenarios where "GuacamoleInsufficientCredentialsException" exceptions > are override by "GuacamoleInvalidCredentialsException" exceptions. Due to > the way the AuthenticationService class currently handles those exceptions, > there is no precedence - the first exception thrown is the one that is > returned. This behavior should be changed such that > GuacamoleInsufficientCredentialsException takes precedence over > GuacamoleInvalidCredentialsException so that modules requesting additional > credentials are not overriden or failed by modules that completely fail > authentication. This will resolve some issues with the order of stacked > modules mattering for whether authentication fails or prompts for additional > credentials. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-684) Insufficient Credentials Should Take Precedence over Invalid Credentials
[ https://issues.apache.org/jira/browse/GUACAMOLE-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-684: Priority: Minor (was: Major) > Insufficient Credentials Should Take Precedence over Invalid Credentials > > > Key: GUACAMOLE-684 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-684 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Affects Versions: 1.0.0 >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Minor > > The implementation of several modules that support 2FA/MFA has resulted in > some scenarios where "GuacamoleInsufficientCredentialsException" exceptions > are override by "GuacamoleInvalidCredentialsException" exceptions. Due to > the way the AuthenticationService class currently handles those exceptions, > there is no precedence - the first exception thrown is the one that is > returned. This behavior should be changed such that > GuacamoleInsufficientCredentialsException takes precedence over > GuacamoleInvalidCredentialsException so that modules requesting additional > credentials are not overriden or failed by modules that completely fail > authentication. This will resolve some issues with the order of stacked > modules mattering for whether authentication fails or prompts for additional > credentials. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GUACAMOLE-684) Insufficient Credentials Should Take Precedence over Invalid Credentials
Nick Couchman created GUACAMOLE-684: --- Summary: Insufficient Credentials Should Take Precedence over Invalid Credentials Key: GUACAMOLE-684 URL: https://issues.apache.org/jira/browse/GUACAMOLE-684 Project: Guacamole Issue Type: Improvement Components: guacamole Affects Versions: 1.0.0 Reporter: Nick Couchman Assignee: Nick Couchman Fix For: 1.0.0 The implementation of several modules that support 2FA/MFA has resulted in some scenarios where "GuacamoleInsufficientCredentialsException" exceptions are override by "GuacamoleInvalidCredentialsException" exceptions. Due to the way the AuthenticationService class currently handles those exceptions, there is no precedence - the first exception thrown is the one that is returned. This behavior should be changed such that GuacamoleInsufficientCredentialsException takes precedence over GuacamoleInvalidCredentialsException so that modules requesting additional credentials are not overriden or failed by modules that completely fail authentication. This will resolve some issues with the order of stacked modules mattering for whether authentication fails or prompts for additional credentials. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-678) And new UriGuacamoleProperty
[ https://issues.apache.org/jira/browse/GUACAMOLE-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-678: Summary: And new UriGuacamoleProperty (was: Add new GuacamoleURLProperty) > And new UriGuacamoleProperty > > > Key: GUACAMOLE-678 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-678 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-ext >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Trivial > > Implement a new property type, GuacamoleURLProperty, that takes a string and > generates a URL object, validating the URL in the process. With the > increased number of extensions that take URLs as configuration parameters > this will allow for more central validation of the URL before it gets used by > the module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-678) And new UriGuacamoleProperty
[ https://issues.apache.org/jira/browse/GUACAMOLE-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-678: Description: Implement a new property type, UriGuacamoleProperty, that takes a string and generates a URI object, validating the URI in the process. With the increased number of extensions that take URIs as configuration parameters this will allow for more central validation of the URI before it gets used by the module. (was: Implement a new property type, GuacamoleURLProperty, that takes a string and generates a URL object, validating the URL in the process. With the increased number of extensions that take URLs as configuration parameters this will allow for more central validation of the URL before it gets used by the module.) > And new UriGuacamoleProperty > > > Key: GUACAMOLE-678 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-678 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-ext >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Trivial > > Implement a new property type, UriGuacamoleProperty, that takes a string and > generates a URI object, validating the URI in the process. With the > increased number of extensions that take URIs as configuration parameters > this will allow for more central validation of the URI before it gets used by > the module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (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
]
Nick Couchman closed GUACAMOLE-681.
---
Resolution: Invalid
> 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) Color palette OSC sequence crashing SSH
[
https://issues.apache.org/jira/browse/GUACAMOLE-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16728532#comment-16728532
]
Nick Couchman commented on GUACAMOLE-681:
-
Tested against the 1.0.0-RC1 tag for both client and server (on CentOS 7), and
it does not crash. Going to close this out as resolved with GUACAMOLE-470.
[~Patricol], if for some reason you're able to reproduce on the staging/1.0.0
branch or 1.0.0-RC1 tag, please feel free to re-open this issue.
> 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) Color palette OSC sequence crashing SSH
[
https://issues.apache.org/jira/browse/GUACAMOLE-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16727479#comment-16727479
]
Nick Couchman commented on GUACAMOLE-681:
-
Ah, that makes sense. So, I would say that the bug referenced in this
particular issue is already fixed, at least in the master branch. I already
cannot remember which versions I tested against, so I don't know if it's fixed
in the staging/1.0.0 branch.
> 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] [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 ] Nick Couchman updated GUACAMOLE-682: Priority: Minor (was: Major) > 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-auth-radius, guacamole-client, guacamole-docker >Affects Versions: 0.9.14, 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] [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=16722546#comment-16722546
]
Nick Couchman commented on GUACAMOLE-681:
-
If I run the command mentioned in the original post it doesn't crash the
session, but it does seem to hang it.
> 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=16722370#comment-16722370
]
Nick Couchman commented on GUACAMOLE-681:
-
I was just curious. I'll try to give it a shot sometime soon with both the
master branch and the staging/1.0.0 branch.
> 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=16722361#comment-16722361
]
Nick Couchman commented on GUACAMOLE-681:
-
Have you, by chance, tested this with either of the versions available in the
git repo - either the master branch or the staging/1.0.0 branch?
> 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-680) Rearrange How Logouts are Handled
[ https://issues.apache.org/jira/browse/GUACAMOLE-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16722329#comment-16722329 ] Nick Couchman commented on GUACAMOLE-680: - dev@ mailing list discussion on issue. > Rearrange How Logouts are Handled > - > > Key: GUACAMOLE-680 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-680 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-client >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Minor > > Rearrange how the AngularJS application handles logouts, firing a warning > event before the logout occurs and then one after the logout (token deletion) > has happened. This is to prep for changes that will allow Single-Sign > Out/Single Log-out to happen correctly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GUACAMOLE-679) Allow Header Module to Call Logout URL
Nick Couchman created GUACAMOLE-679: --- Summary: Allow Header Module to Call Logout URL Key: GUACAMOLE-679 URL: https://issues.apache.org/jira/browse/GUACAMOLE-679 Project: Guacamole Issue Type: New Feature Components: guacamole-auth-header Reporter: Nick Couchman Assignee: Nick Couchman The guacamole-auth-header module could add support for the ability to call a URL to trigger a logout, similar to Single Sign Out for CAS and OpenID. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GUACAMOLE-678) Add new GuacamoleURLProperty
Nick Couchman created GUACAMOLE-678: --- Summary: Add new GuacamoleURLProperty Key: GUACAMOLE-678 URL: https://issues.apache.org/jira/browse/GUACAMOLE-678 Project: Guacamole Issue Type: Improvement Components: guacamole-ext Reporter: Nick Couchman Assignee: Nick Couchman Implement a new property type, GuacamoleURLProperty, that takes a string and generates a URL object, validating the URL in the process. With the increased number of extensions that take URLs as configuration parameters this will allow for more central validation of the URL before it gets used by the module. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (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:all-tabpanel ] Nick Couchman updated GUACAMOLE-676: Priority: Minor (was: Major) > 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] [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=16717517#comment-16717517
]
Nick Couchman commented on GUACAMOLE-675:
-
{quote}
Just supposed someone using that 1.0.0 version as production server, it means
database will have to be drop and recreate as you mentionned !
{quote}
Since 1.0.0 hasn't been released, using it for production would be ill-advised,
at least if you're not prepared to do exactly that. There's a reason it hasn't
been released, because it's still in development.
> 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] [Updated] (GUACAMOLE-579) Allow CAS attributes to be used as tokens
[ https://issues.apache.org/jira/browse/GUACAMOLE-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-579: Fix Version/s: 2.0.0 > Allow CAS attributes to be used as tokens > - > > Key: GUACAMOLE-579 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-579 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-auth-cas >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Trivial > Fix For: 2.0.0 > > > Similar to changes in GUACAMOLE-524 that introduced the ability for user > attributes to be used as tokens, this will allow that same capability, but > from the CAS module instead of the LDAP module. CAS has the capability to > provide user attributes in its SSO responses, so pulling those out and making > them available as tokens should be relatively easy to do. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-617) Extract Permission Management from JDBC Authentication Module
[ https://issues.apache.org/jira/browse/GUACAMOLE-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-617: Fix Version/s: (was: 2.0.0) > Extract Permission Management from JDBC Authentication Module > - > > Key: GUACAMOLE-617 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-617 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-client >Reporter: Michael Jumper >Priority: Minor > > With some of the recent developments to authentication extensions, it seems > to be good time and idea to extract a bunch of the permissions management > features from the JDBC module such that they are available to other modules. > These could either be relocated to the existing guacamole-ext module, or into > some other, to-be-name, module that deals strictly in access control and > permission management. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-234) Migrate from JLDAP to Apache Directory LDAP API
[ https://issues.apache.org/jira/browse/GUACAMOLE-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16714009#comment-16714009 ] Nick Couchman commented on GUACAMOLE-234: - Took a new stab at this, PR is ready for review and testing. > Migrate from JLDAP to Apache Directory LDAP API > --- > > Key: GUACAMOLE-234 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-234 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-auth-ldap >Reporter: Michael Jumper >Assignee: Nick Couchman >Priority: Minor > Fix For: 2.0.0 > > > The LDAP support currently uses [JLDAP|http://www.openldap.org/jldap/], but > that library has been unmaintained for several years now (no changes > whatsoever since 2009). Migrating away from such a library might be a good > idea. The Apache Directory project has produced an LDAP client API which > could serve as a replacement: > http://directory.apache.org/api/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-234) Migrate from JLDAP to Apache Directory LDAP API
[ https://issues.apache.org/jira/browse/GUACAMOLE-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-234: Fix Version/s: 2.0.0 > Migrate from JLDAP to Apache Directory LDAP API > --- > > Key: GUACAMOLE-234 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-234 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-auth-ldap >Reporter: Michael Jumper >Assignee: Nick Couchman >Priority: Minor > Fix For: 2.0.0 > > > The LDAP support currently uses [JLDAP|http://www.openldap.org/jldap/], but > that library has been unmaintained for several years now (no changes > whatsoever since 2009). Migrating away from such a library might be a good > idea. The Apache Directory project has produced an LDAP client API which > could serve as a replacement: > http://directory.apache.org/api/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GUACAMOLE-674) Pass-through LDAP member attribute env variable in Docker start script
[ https://issues.apache.org/jira/browse/GUACAMOLE-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman resolved GUACAMOLE-674. - Resolution: Implemented Fix Version/s: 2.0.0 > Pass-through LDAP member attribute env variable in Docker start script > -- > > Key: GUACAMOLE-674 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-674 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-docker >Affects Versions: 1.0.0 >Reporter: Jörn Lentes >Priority: Minor > Fix For: 2.0.0 > > > The docker start script guacamole-docker/bin/start.sh does not set the > optional property for the LDAP member attribute value. > This should be read from the environment similar to LDAP_USERNAME_ATTRIBUTE. > The environment variable should be: LDAP_MEMBER_ATTRIBUTE > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (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:all-tabpanel ] Nick Couchman resolved GUACAMOLE-598. - Resolution: Fixed > 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-673) Create automatically needed directory for file transfer
[ https://issues.apache.org/jira/browse/GUACAMOLE-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman closed GUACAMOLE-673. --- Resolution: Invalid Working as expected in current code. > Create automatically needed directory for file transfer > --- > > Key: GUACAMOLE-673 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-673 > Project: Guacamole > Issue Type: Improvement > Components: guacd, RDP >Affects Versions: 0.9.14 >Reporter: Dejan Milovanovic >Priority: Minor > Labels: features > > When the user login to a remote machine he needs to open transfer network > drive once before the corresponding directory is created in the guacd fs. > That means if you have linked that network folder to somewhere and try to > copy into it, it would not work until you open the network drive once before > starting the copy. This is happening even if the "create-drive-path" property > is set to true. Solution would be to create guacd fs directory on connect if > the "create-drive-path" is set to true. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (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:all-tabpanel ] Nick Couchman resolved GUACAMOLE-526. - Resolution: Fixed > 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: Nick Couchman >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] [Updated] (GUACAMOLE-354) Add Swiss-German keymap for RDP
[
https://issues.apache.org/jira/browse/GUACAMOLE-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman updated GUACAMOLE-354:
Fix Version/s: 2.0.0
> Add Swiss-German keymap for RDP
> ---
>
> Key: GUACAMOLE-354
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-354
> Project: Guacamole
> Issue Type: Improvement
> Components: RDP
>Reporter: Reto Schelbert
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: ch-de-qwertz.keymap
>
>
> Would it also be possible to implement the Swiss-German (DE_ch) keyboard
> layout?
> The corresponding FreeRDP layout constant would be
> {code:java}
> KBD_SWISS_GERMAN
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-354) Add Swiss-German keymap for RDP
[
https://issues.apache.org/jira/browse/GUACAMOLE-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman updated GUACAMOLE-354:
Component/s: (was: guacamole)
> Add Swiss-German keymap for RDP
> ---
>
> Key: GUACAMOLE-354
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-354
> Project: Guacamole
> Issue Type: Improvement
> Components: RDP
>Reporter: Reto Schelbert
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: ch-de-qwertz.keymap
>
>
> Would it also be possible to implement the Swiss-German (DE_ch) keyboard
> layout?
> The corresponding FreeRDP layout constant would be
> {code:java}
> KBD_SWISS_GERMAN
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (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:all-tabpanel ] Nick Couchman reassigned GUACAMOLE-526: --- Assignee: Nick Couchman (was: James Muehlner) > 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: Nick Couchman >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-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=16709438#comment-16709438 ] Nick Couchman commented on GUACAMOLE-526: - Well, it was either the trailing comma or the ngRoute include, but cleaning that up seems to have resolved the issue! Submitting a PR. > 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-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=16709417#comment-16709417 ] Nick Couchman commented on GUACAMOLE-526: - Thanks for looking, Mike. I'll take a look at the errors in the JS console and see if there's any other clues. Not sure why this is being problematic. The only other exception I see is this: jquery.min.js:2 - [Violation] 'setTimeout' handler took 91ms > 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] [Updated] (GUACAMOLE-673) Create automatically needed directory for file transfer
[ https://issues.apache.org/jira/browse/GUACAMOLE-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-673: Priority: Minor (was: Major) > Create automatically needed directory for file transfer > --- > > Key: GUACAMOLE-673 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-673 > Project: Guacamole > Issue Type: Improvement > Components: guacd, RDP >Affects Versions: 0.9.14 >Reporter: Dejan Milovanovic >Priority: Minor > Labels: features > > When the user login to a remote machine he needs to open transfer network > drive once before the corresponding directory is created in the guacd fs. > That means if you have linked that network folder to somewhere and try to > copy into it, it would not work until you open the network drive once before > starting the copy. This is happening even if the "create-drive-path" property > is set to true. Solution would be to create guacd fs directory on connect if > the "create-drive-path" is set to true. -- 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 ] Nick Couchman closed GUACAMOLE-671. --- Resolution: Duplicate Issue is a result of changes introduced by GUACAMOLE-526. Reopened that issue to track fixed there. > 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 > Fix For: 1.0.0 > > 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] [Resolved] (GUACAMOLE-670) Regressions in Logging in CAS and RADIUS Modules
[ https://issues.apache.org/jira/browse/GUACAMOLE-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman resolved GUACAMOLE-670. - Resolution: Fixed > Regressions in Logging in CAS and RADIUS Modules > > > Key: GUACAMOLE-670 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-670 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-cas, guacamole-auth-radius >Affects Versions: 1.0.0 >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Blocker > Fix For: 1.0.0 > > > Some regressions have occurred in the CAS and RADIUS modules due to SLF4J > being pulled in by other dependencies. Some pom.xml fixes are needed to > correct those. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (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:all-tabpanel ] Nick Couchman updated GUACAMOLE-526: Priority: Blocker (was: Minor) > 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] [Reopened] (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:all-tabpanel
]
Nick Couchman reopened GUACAMOLE-526:
-
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: Minor
> 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=16707376#comment-16707376 ] Nick Couchman commented on GUACAMOLE-598: - Based on the fact that it happens either on the Home Screen or when you activate the Ctrl-Alt-Shift menu, I'm guessing this is the one that's failing: https://github.com/apache/guacamole-client/blob/fc457c080d813044e30e1f4e8fe855d6a5900259/guacamole/src/main/webapp/app/navigation/directives/guacUserMenu.js#L98-L114 Not sure if there are other places. > 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] [Reopened] (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:all-tabpanel
]
Nick Couchman reopened GUACAMOLE-598:
-
Changes from this issue introduce a regression in modules that do not provide a
userContext. For such modules (Header, CAS, RADIUS), the call to
/api/session/data//user/ returns a 404 error. Prior to
these changes, that error was silently ignored by the web front-end - after
these changes the 404 results in the generic error message.
The specific commit that introduced the regression is:
{quote}
5866c7e251f05c9345f77215713d4549575db2df is the first bad commit
commit 5866c7e251f05c9345f77215713d4549575db2df
Author: Michael Jumper
Date: Tue Jun 26 22:49:06 2018 -0700
GUACAMOLE-598: Abort rendering of pages if critical data fails to load
(data without which the page is non-functional).
{quote}
> 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-672) Error retrieving user session data
[ https://issues.apache.org/jira/browse/GUACAMOLE-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman closed GUACAMOLE-672. --- Resolution: Duplicate This is a regression introduced by GUACAMOLE-598 - reopened that issue and closing this one. > Error retrieving user session data > -- > > Key: GUACAMOLE-672 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-672 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-header, guacamole-auth-radius >Reporter: Nick Couchman >Priority: Major > Attachments: Screenshot_2018-12-03_08-29-08.png > > > In the current git master branch, if you log in with modules like RADIUS and > Header (and probably others), when the interface tries to retrieve > information about the user from the module, it receives a 404 from the > module, which causes the web interface to display an error message. > Screenshot of error along with Developer Console is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GUACAMOLE-672) Error retrieving user session data
Nick Couchman created GUACAMOLE-672: --- Summary: Error retrieving user session data Key: GUACAMOLE-672 URL: https://issues.apache.org/jira/browse/GUACAMOLE-672 Project: Guacamole Issue Type: Bug Components: guacamole-auth-header, guacamole-auth-radius Reporter: Nick Couchman Attachments: Screenshot_2018-12-03_08-29-08.png In the current git master branch, if you log in with modules like RADIUS and Header (and probably others), when the interface tries to retrieve information about the user from the module, it receives a 404 from the module, which causes the web interface to display an error message. Screenshot of error along with Developer Console is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GUACAMOLE-671) Regression in CAS Module Redirect
Nick Couchman created GUACAMOLE-671: --- Summary: 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 Fix For: 1.0.0 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] [Created] (GUACAMOLE-670) Regressions in Logging in CAS and RADIUS Modules
Nick Couchman created GUACAMOLE-670: --- Summary: Regressions in Logging in CAS and RADIUS Modules Key: GUACAMOLE-670 URL: https://issues.apache.org/jira/browse/GUACAMOLE-670 Project: Guacamole Issue Type: Bug Components: guacamole-auth-radius, guacamole-auth-cas Affects Versions: 1.0.0 Reporter: Nick Couchman Assignee: Nick Couchman Fix For: 1.0.0 Some regressions have occurred in the CAS and RADIUS modules due to SLF4J being pulled in by other dependencies. Some pom.xml fixes are needed to correct those. -- 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=16699481#comment-16699481 ] Nick Couchman commented on GUACAMOLE-666: - What client are you using? It appears to me that this probably has to do with the difference between line terminators between Windows and Linux, so I'm curious if your copy/paste operations are between two different platforms (Windows and Linux) or the same (Linux and Linux, Windows and Windows, etc.)? > 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
]
Nick Couchman updated GUACAMOLE-667:
Priority: Minor (was: Major)
> 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] [Updated] (GUACAMOLE-666) Text pasted through SSH into nano editor
[ https://issues.apache.org/jira/browse/GUACAMOLE-666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-666: Priority: Minor (was: Major) > 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-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:all-tabpanel ] Nick Couchman updated GUACAMOLE-663: Priority: Minor (was: Major) > 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: Minor > 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] [Commented] (GUACAMOLE-665) Feature Request - add Admin ability to force all Users to change Password
[ https://issues.apache.org/jira/browse/GUACAMOLE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698313#comment-16698313 ] Nick Couchman commented on GUACAMOLE-665: - [~bmullan] That's a fair point. > Feature Request - add Admin ability to force all Users to change Password > - > > Key: GUACAMOLE-665 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-665 > Project: Guacamole > Issue Type: New Feature > Components: guacamole >Reporter: brian mullan >Priority: Minor > > I've been thinking about this and would like to ask if there had been any > thought to an Admin option/command to Force all users to change their > Guacamole Passwords on next login? > Given all the site hacking events reported every month it _would seem to be a > good idea for Guacamole in the event a large Guacamole installation was > compromised somehow._ > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-354) Add Swiss-German keymap for RDP
[
https://issues.apache.org/jira/browse/GUACAMOLE-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698311#comment-16698311
]
Nick Couchman commented on GUACAMOLE-354:
-
[~andrin-jost] Awesome, thank you for the contribution!
> Add Swiss-German keymap for RDP
> ---
>
> Key: GUACAMOLE-354
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-354
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole, RDP
>Reporter: Reto Schelbert
>Priority: Minor
> Attachments: ch-de-qwertz.keymap
>
>
> Would it also be possible to implement the Swiss-German (DE_ch) keyboard
> layout?
> The corresponding FreeRDP layout constant would be
> {code:java}
> KBD_SWISS_GERMAN
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-664) Unable to use microphone with the 0.9.14 release
[ https://issues.apache.org/jira/browse/GUACAMOLE-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698309#comment-16698309 ] Nick Couchman commented on GUACAMOLE-664: - It seems like this might be related to (or duplicate of) GUACAMOLE-296? > Unable to use microphone with the 0.9.14 release > > > Key: GUACAMOLE-664 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-664 > Project: Guacamole > Issue Type: Bug > Components: guacamole >Affects Versions: 0.9.14 >Reporter: Umesh >Priority: Minor > Attachments: Microphone not working.png > > > Hi, > I am using 0.9.14 release on Cent OS 7/Ubuntu 16.04 and trying to use > microphone support but not able to do so after trying for long. > Microphone is showing under remote Windows Server "Recording" but it doesn't > detect any sound from my microphone. Some of details about my environment is > as following. > # Guacamole server on Cent OS 7 and Ubuntu 16.04 > # Guacamole - 0.9.14 release with default Freerdp version > # Using https (with self signed certificate) in Chrome browser > # Used Tomcat 7 servlet container > # Selected "enable audio input (microphone)" in settings guacamole > connection settings > # Tested with Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 > Standard and Windows 2016 Datacenter edition. Did following configuration in > Windows servers. > ## Installed Remote Desktop Session Host > ## Dektop Experience > ## Media Foundation > ## Disabled NLA > ## Enabled Remote Desktop Services > Need some inputs to resolve this issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-664) Unable to use microphone with the 0.9.14 release
[ https://issues.apache.org/jira/browse/GUACAMOLE-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-664: Priority: Minor (was: Major) > Unable to use microphone with the 0.9.14 release > > > Key: GUACAMOLE-664 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-664 > Project: Guacamole > Issue Type: Bug > Components: guacamole >Affects Versions: 0.9.14 >Reporter: Umesh >Priority: Minor > Attachments: Microphone not working.png > > > Hi, > I am using 0.9.14 release on Cent OS 7/Ubuntu 16.04 and trying to use > microphone support but not able to do so after trying for long. > Microphone is showing under remote Windows Server "Recording" but it doesn't > detect any sound from my microphone. Some of details about my environment is > as following. > # Guacamole server on Cent OS 7 and Ubuntu 16.04 > # Guacamole - 0.9.14 release with default Freerdp version > # Using https (with self signed certificate) in Chrome browser > # Used Tomcat 7 servlet container > # Selected "enable audio input (microphone)" in settings guacamole > connection settings > # Tested with Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 > Standard and Windows 2016 Datacenter edition. Did following configuration in > Windows servers. > ## Installed Remote Desktop Session Host > ## Dektop Experience > ## Media Foundation > ## Disabled NLA > ## Enabled Remote Desktop Services > Need some inputs to resolve this issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-665) Feature Request - add Admin ability to force all Users to change Password
[
https://issues.apache.org/jira/browse/GUACAMOLE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16693659#comment-16693659
]
Nick Couchman commented on GUACAMOLE-665:
-
I'm not necessarily opposed to some way to accomplish this in the admin
interface, but I will point out that it should be very doable via a SQL script
- basically just:
{code}
UPDATE guacamole_users SET expired='t';
{code}
would effectively accomplish this.
> Feature Request - add Admin ability to force all Users to change Password
> -
>
> Key: GUACAMOLE-665
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-665
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole
>Reporter: brian mullan
>Priority: Minor
>
> I've been thinking about this and would like to ask if there had been any
> thought to an Admin option/command to Force all users to change their
> Guacamole Passwords on next login?
> Given all the site hacking events reported every month it _would seem to be a
> good idea for Guacamole in the event a large Guacamole installation was
> compromised somehow._
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GUACAMOLE-547) Add support for the "none" SSH authentication method
[
https://issues.apache.org/jira/browse/GUACAMOLE-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman reassigned GUACAMOLE-547:
---
Assignee: Nick Couchman
> Add support for the "none" SSH authentication method
>
>
> Key: GUACAMOLE-547
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-547
> Project: Guacamole
> Issue Type: New Feature
> Components: SSH
> Environment: Linux 4.13.0-1012-azure #15-Ubuntu SMP Thu Mar 8
> 10:47:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: David Hauk
>Assignee: Nick Couchman
>Priority: Minor
> Attachments: guacd_debug_fail.txt, openssh_verbose_successful
> connection.txt
>
>
> When connecting to embedded devices that implicitly allow SSH access guacd
> fails when the authentication method is (none). The devices permit any SSH
> user with no password access to the console, and then provide authentication
> internally via their interactive shell.
> Test cases:
> # no username and no password configured: Guacamole requests both, then
> fails to connect.
> # username but no password: Guacamole requests password, and then fails to
> connect.
> # username and password: Guacamole asks for no input, and then fails to
> connect.
> I've attached guacd debug logs from the failed connection attempts, plus
> OpenSSH (-vv) logs from a successful connection. (Files have been suitably
> redacted). The bit they share in common is they both state "Authentication
> (none)" but OpenSSH proceeds with the connection, while guacd terminates the
> connection:
> Guacd:
> {code:java}
> guacd[100079]: DEBUG: Successfully connected to host 192.168.233.20, port 22
> guacd[100079]: DEBUG: Supported authentication methods: (null)
> guacd[100066]: INFO: Connection "$abc52848-a11c-4397-a657-7c2d4bfdb5e9"
> removed.{code}
> OpenSSH:
> {code:java}
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentication succeeded (none).
> Authenticated to 192.168.233.20 ([192.168.233.20]:22).
> debug1: channel 0: new [client-session]
> debug2: channel 0: send open
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (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 ] Nick Couchman updated GUACAMOLE-658: Priority: Minor (was: Major) > 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] [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 ] Nick Couchman updated GUACAMOLE-657: Priority: Minor (was: Major) > 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-220) Implement user groups
[
https://issues.apache.org/jira/browse/GUACAMOLE-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16675604#comment-16675604
]
Nick Couchman commented on GUACAMOLE-220:
-
Cool...I'm trying to get through reviewing some of the pull requests, but my
free time has been really small lately...
> 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-597) Allow fine-grained control of terminal output redirection via pipe streams
[
https://issues.apache.org/jira/browse/GUACAMOLE-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16668925#comment-16668925
]
Nick Couchman commented on GUACAMOLE-597:
-
{quote}
If it's possible to rearrange release/branching procedures to allow
non-breaking changes to be released in a patch release, that may be worth doing
in the future. Not sure what that would be, though it would presumably involve
a number of active development branches (multiple staging branches), each
dedicated to an upcoming release.
{quote}
Yeah, I was thinking maybe we should create active development branches for the
next major, minor, and patch release, and then we can apply changes to those
the way we do the staging releases, and roll up to the appropriate places
(patch gets rolled to major, minor, and master, minor gets rolled to major and
master, major gets rolled to master). It's going to add some complexity into
managing versions, so we probably should keep it pretty simple, but it would be
nice post-2.0.0 to be able to apply changes in such a way that development
efforts can continue in a more parallel fashion.
> Allow fine-grained control of terminal output redirection via pipe streams
> --
>
> Key: GUACAMOLE-597
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-597
> Project: Guacamole
> Issue Type: New Feature
> Components: Terminal
>Reporter: Michael Jumper
>Assignee: Michael Jumper
>Priority: Major
> Fix For: 2.0.0
>
>
> While Guacamole's terminal emulator allows output to be redirected to a pipe
> stream for the benefit of client-side JavaScript (see GUACAMOLE-17), doing so
> currently has caveats:
> * Redirecting output to a pipe stream results in _all_ output going solely to
> that stream. No output is displayed on the terminal while the pipe stream
> remains open. This is not always desirable.
> * Data sent to the pipe stream is buffered. This works well for
> non-interactive bulk transfers of data, but any client-side JavaScript
> expecting to monitor output in real-time will be disappointed, particularly
> code which must deal with the output of interactive commands.
> There should be some option to allow output to go to both the pipe stream and
> the terminal, and some option to allow the output to be automatically
> flushed, whether that be through a new OSC code or through
> backward-compatible modifications to the existing code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GUACAMOLE-646) No LDAP user mappings in Guacamole database
[ https://issues.apache.org/jira/browse/GUACAMOLE-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman closed GUACAMOLE-646. --- Resolution: Invalid Please post your question to the mailing list - this is not a support forum, it is for bugs and improvement requests. After you have used the mailing list, if you determine there is a bug or improvement needed, you can open the issue, here. > No LDAP user mappings in Guacamole database > --- > > Key: GUACAMOLE-646 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-646 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-auth-jdbc-mysql, guacamole-auth-ldap >Affects Versions: 0.9.14 > Environment: OS: Ubuntu 16.04.5 > Guacamole Version: 0.9.14 > Web server: Apache Tomcat 8 >Reporter: Norwalk Technology >Priority: Critical > > We have Apache Guacamole 0.9.14 installed on an Ubuntu 16.04.5 server. It's > bound to an Active Directory security group. Members of that group are able > to log in but have no connections. When we log in as an admin we can't see > the AD users listed. Not sure where to go from here. We'd like to > authenticate users in multiple groups to various connections in Guacamole. > How should we proceed? > > Thanks in advance for any assistance you would offer! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-645) Support xterm.js/ttyd/gotty as a Guacamole Connection
[
https://issues.apache.org/jira/browse/GUACAMOLE-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653934#comment-16653934
]
Nick Couchman commented on GUACAMOLE-645:
-
{quote}
...but it is limited in it's ability to copy/paste from the host...
{quote}
How so?
{quote}
...and also experiences some lag.
{quote}
Really? If it does this is likely more due to network factors than it is to
Guacamole - I don't experience any lag in my environment, but I'm primarily
using Guacamole on a local network to connect to servers the next room over,
both RDP and SSH, so I'm sure lag would exist connecting across a WAN/VPN.
However, I don't think this is something that Xterm.js, et al., is going to
impact - for better or worse.
Getting back to the original request...
{quote}
Hi, I think it would be awesome to support an xterm.js client in guacamole.
{quote}
Could you elaborate on what you mean by this? It looks to me like xterm.js is,
itself, a terminal emulator written in JavaScript, that can then connect to
some other backend. Looking at the other resources you provided - ttyd and
gotty - it seems like their purpose is to provide a web interface for a local
TTY so that you can share your terminal. While there are some similarities
between Guacamole and these three items, I'm not sure they're entirely
compatible, nor does it make sense to actually provide support for Guacamole to
connect to them. The biggest reason I'd cite is that those tools seem to
already be providing a web-based interface, and Guacamole is not a reverse
proxy - it is designed specifically to facilitate remote desktop connections,
but is not designed to proxy other web-based connections.
[~mike.jumper] Other thoughts, here?
> Support xterm.js/ttyd/gotty as a Guacamole Connection
> -
>
> Key: GUACAMOLE-645
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-645
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole, guacamole-common-js, guacamole-server
>Reporter: Jim
>Priority: Minor
>
> Hi, I think it would be awesome to support an xterm.js client in guacamole.
> For authentication, Guacamole would need to handle Basic Authentication which
> is supported by both ttyd/gotty. Gotty also supports using certificates. The
> ssh connection is pretty awesome, but it is limited in it's ability to
> copy/paste from the host and also experiences some lag. Xterm.js is a very
> popular front end for remote connections and I think it would be pretty cool
> to support this interface through guacamole.
> I'm unfamiliar with creating tickets for Jira so please let me know if I'm
> out of place in submitting this request or if you would like
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-527) Add parameter for specifying known SSH/SFTP server host key
[ https://issues.apache.org/jira/browse/GUACAMOLE-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16652144#comment-16652144 ] Nick Couchman commented on GUACAMOLE-527: - [~mike.jumper] Can you confirm that the changes you just merged for me correct the issue you were seeing? > Add parameter for specifying known SSH/SFTP server host key > --- > > Key: GUACAMOLE-527 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-527 > Project: Guacamole > Issue Type: New Feature > Components: Documentation, RDP, SSH, VNC >Reporter: Michael Jumper >Assignee: Nick Couchman >Priority: Major > Fix For: 1.0.0 > > > Guacamole's SSH support (used for both SSH terminal connections and SFTP) > currently does not provide a mechanism for verifying the identity of the SSH > server. In case Guacamole is used to access computers across untrusted > networks (or using hostnames queried from untrusted DNS), additional > parameters should be provided allowing the administrator to explicitly > specify the known key fingerprint of the SSH server. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-527) Add parameter for specifying known SSH/SFTP server host key
[ https://issues.apache.org/jira/browse/GUACAMOLE-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16651744#comment-16651744 ] Nick Couchman commented on GUACAMOLE-527: - Okay, I think I figured out the issue and submitted a PR to correct it. > Add parameter for specifying known SSH/SFTP server host key > --- > > Key: GUACAMOLE-527 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-527 > Project: Guacamole > Issue Type: New Feature > Components: Documentation, RDP, SSH, VNC >Reporter: Michael Jumper >Assignee: Nick Couchman >Priority: Major > Fix For: 1.0.0 > > > Guacamole's SSH support (used for both SSH terminal connections and SFTP) > currently does not provide a mechanism for verifying the identity of the SSH > server. In case Guacamole is used to access computers across untrusted > networks (or using hostnames queried from untrusted DNS), additional > parameters should be provided allowing the administrator to explicitly > specify the known key fingerprint of the SSH server. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-527) Add parameter for specifying known SSH/SFTP server host key
[ https://issues.apache.org/jira/browse/GUACAMOLE-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16651576#comment-16651576 ] Nick Couchman commented on GUACAMOLE-527: - I'll try to do some triage today and see what I can figure out. > Add parameter for specifying known SSH/SFTP server host key > --- > > Key: GUACAMOLE-527 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-527 > Project: Guacamole > Issue Type: New Feature > Components: Documentation, RDP, SSH, VNC >Reporter: Michael Jumper >Assignee: Nick Couchman >Priority: Major > Fix For: 1.0.0 > > > Guacamole's SSH support (used for both SSH terminal connections and SFTP) > currently does not provide a mechanism for verifying the identity of the SSH > server. In case Guacamole is used to access computers across untrusted > networks (or using hostnames queried from untrusted DNS), additional > parameters should be provided allowing the administrator to explicitly > specify the known key fingerprint of the SSH server. -- 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=16650025#comment-16650025
]
Nick Couchman commented on GUACAMOLE-220:
-
[~pasik] There are no official images, yet, since it hasn't been released. You
can build the docker images by checking out the git source and using a normal
docker build command, and test that way.
> 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=16649540#comment-16649540
]
Nick Couchman commented on GUACAMOLE-220:
-
Sounds good - I'll be happy to review docs once those are ready. If there's
anything specific for regression testing that I can help with let me know.
> 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-96) Two factor authentication with Google Authenticator
[ https://issues.apache.org/jira/browse/GUACAMOLE-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16649539#comment-16649539 ] Nick Couchman commented on GUACAMOLE-96: Documentation merged for this. > Two factor authentication with Google Authenticator > --- > > Key: GUACAMOLE-96 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-96 > Project: Guacamole > Issue Type: New Feature > Components: Documentation, guacamole-client >Reporter: L.J. van Ruiten >Assignee: Michael Jumper >Priority: Major > Fix For: 1.0.0 > > Attachments: guacamole-auth-totp-01-enroll-01-details-hidden.png, > guacamole-auth-totp-01-enroll-02-details-shown.png, > guacamole-auth-totp-01-enroll.png, guacamole-auth-totp-02-verify.png > > > We have a few critical systems that are accessible through Guacamole and we > have had some clients requesting a safer way to login. Two factor > authentication is probably the best and easiest way to improve on the current > username/password login, and I can imagine that this is something that other > companies using Guacamole would also be interesting in this feature. > I already did some tinkering myself and I found that Google Auhtenticator is > simple to use, does not require any configuration (like you would with SMS > codes) easy to implement and the "client" side of the authentication (the > part that generates the codes) is easily integrated into existing apps. > So far I have got Google Authenticator "kinda working". What I did is: > - Started with guacamole-auth-jdbc as base > - Added a secret key to a user account that is randomly generated upon > creation. Also added a boolean field to indicate wether TFA is required for > loggin in. > - Used the GuacamoleInsufficientCredentialsException to redirect the user the > a second screen asking for a TFA code after loggin in with the username and > password. > However as said before this only "kinda works" because: > I have only gotten the TFA enable button to appear in the user's managing > page, so it can only be enabled by administrators and that's also where I put > the secret key shows up, so users can't find it themself. > For as far as I could find the previous point cannot be done with just the > guacamole-ext api. Even with the new API that enables you to insert HTML > parts, you would also need an API endpoint to provide the secret key or > ideally generate a QR code that Google Auhtenticator can read to bind a > device to the account (I would like it to appear in the user's preference > page). > So in summary if other people are interested I would be willing to contribute > this, but I would need some directions and I have a few questions: > - Am I right that it is currently not possible to add an API endpoint just > using guacamole-ext to provide the QR codes? > - What would be the way to implement this? Personally I thought that adding > these options to the user's page would be the easiest. > - Is this a feature you would like me to work on and contribute? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-643) Filter should not hide connection group
[ https://issues.apache.org/jira/browse/GUACAMOLE-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-643: Priority: Minor (was: Major) > Filter should not hide connection group > --- > > Key: GUACAMOLE-643 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-643 > Project: Guacamole > Issue Type: Wish > Components: guacamole >Reporter: Claudio Signorini >Priority: Minor > > Hi! > Is there a way (or can be implemented) to configure a connection group that > filters do not hide even if the name does not match? > Example... I use connection group to group connection by environment: > * development > ** abc1.cow.it > ** abc2.cow.it > * production > ** abc3.cow.it > When I type "abc" in the filter, the two connection groups hide. And I can't > understand the environment of the connection. I would like the connection > group won't hide. > Thanks -- 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=16645612#comment-16645612
]
Nick Couchman commented on GUACAMOLE-220:
-
[~mike.jumper] Documentation in the works, here? Anything I can help with?
> 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-96) Two factor authentication with Google Authenticator
[ https://issues.apache.org/jira/browse/GUACAMOLE-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16645610#comment-16645610 ] Nick Couchman commented on GUACAMOLE-96: [~mike.jumper] Are you working on documentation for this? I probably could work on it, but I don't have it installed anywhere at the moment. I can do that if it would help - let me know. > Two factor authentication with Google Authenticator > --- > > Key: GUACAMOLE-96 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-96 > Project: Guacamole > Issue Type: New Feature > Components: Documentation, guacamole-client >Reporter: L.J. van Ruiten >Assignee: Michael Jumper >Priority: Major > Fix For: 1.0.0 > > Attachments: guacamole-auth-totp-01-enroll-01-details-hidden.png, > guacamole-auth-totp-01-enroll-02-details-shown.png, > guacamole-auth-totp-01-enroll.png, guacamole-auth-totp-02-verify.png > > > We have a few critical systems that are accessible through Guacamole and we > have had some clients requesting a safer way to login. Two factor > authentication is probably the best and easiest way to improve on the current > username/password login, and I can imagine that this is something that other > companies using Guacamole would also be interesting in this feature. > I already did some tinkering myself and I found that Google Auhtenticator is > simple to use, does not require any configuration (like you would with SMS > codes) easy to implement and the "client" side of the authentication (the > part that generates the codes) is easily integrated into existing apps. > So far I have got Google Authenticator "kinda working". What I did is: > - Started with guacamole-auth-jdbc as base > - Added a secret key to a user account that is randomly generated upon > creation. Also added a boolean field to indicate wether TFA is required for > loggin in. > - Used the GuacamoleInsufficientCredentialsException to redirect the user the > a second screen asking for a TFA code after loggin in with the username and > password. > However as said before this only "kinda works" because: > I have only gotten the TFA enable button to appear in the user's managing > page, so it can only be enabled by administrators and that's also where I put > the secret key shows up, so users can't find it themself. > For as far as I could find the previous point cannot be done with just the > guacamole-ext api. Even with the new API that enables you to insert HTML > parts, you would also need an API endpoint to provide the secret key or > ideally generate a QR code that Google Auhtenticator can read to bind a > device to the account (I would like it to appear in the user's preference > page). > So in summary if other people are interested I would be willing to contribute > this, but I would need some directions and I have a few questions: > - Am I right that it is currently not possible to add an API endpoint just > using guacamole-ext to provide the QR codes? > - What would be the way to implement this? Personally I thought that adding > these options to the user's page would be the easiest. > - Is this a feature you would like me to work on and contribute? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GUACAMOLE-642) Port Forwarding
[ https://issues.apache.org/jira/browse/GUACAMOLE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman closed GUACAMOLE-642. --- Resolution: Invalid > Port Forwarding > > > Key: GUACAMOLE-642 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-642 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Affects Versions: 0.9.14 >Reporter: Roger Paesani >Priority: Minor > > > > > > I have guacamole version 0.9.14 installed in Centos 7, using KVM I have > virtualized several Windows 7, on that Windows 7 we run an SAP client to > invoice, to this session of Windows 7 we access it through Raspberry Pi 3, > where we have a POS printer to print the invoice. We need to know how we can > connect the COM port of Windows with the COM port of the Raspberry where the > POS printer is connected. > Thanks for the help. > Roger. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-642) Port Forwarding
[ https://issues.apache.org/jira/browse/GUACAMOLE-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16643771#comment-16643771 ] Nick Couchman commented on GUACAMOLE-642: - Please redirect your question to the mailing list - this is not a support forum, but a place to either report bugs or request features. http://guacamole.apache.org/support/ > Port Forwarding > > > Key: GUACAMOLE-642 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-642 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Affects Versions: 0.9.14 >Reporter: Roger Paesani >Priority: Minor > > > > > > I have guacamole version 0.9.14 installed in Centos 7, using KVM I have > virtualized several Windows 7, on that Windows 7 we run an SAP client to > invoice, to this session of Windows 7 we access it through Raspberry Pi 3, > where we have a POS printer to print the invoice. We need to know how we can > connect the COM port of Windows with the COM port of the Raspberry where the > POS printer is connected. > Thanks for the help. > Roger. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GUACAMOLE-640) Guacamole doesn't work in Chrome 69
[ https://issues.apache.org/jira/browse/GUACAMOLE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman closed GUACAMOLE-640. --- Resolution: Invalid > Guacamole doesn't work in Chrome 69 > --- > > Key: GUACAMOLE-640 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-640 > Project: Guacamole > Issue Type: Bug > Components: guacamole, guacamole-client >Affects Versions: 0.9.14 >Reporter: Felix Wolfheimer >Priority: Major > Attachments: image-2018-10-04-17-27-26-450.png, > image-2018-10-04-17-30-02-466.png > > > In the most recent update of Google Chrome, the guacamole client doesn't work > anymore. The behavior is as follows: > Login works fine. Then, a blank page is shown with a connection error message: > !image-2018-10-04-17-27-26-450.png! > In the Chrome development tools one can see the following errors: > !image-2018-10-04-17-30-02-466.png! > If I connect to this same instance using either Chrome 68, Firefox 62, or > Internet Explorer, everything works fine. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-422) Timezone Redirection
[ https://issues.apache.org/jira/browse/GUACAMOLE-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-422: Fix Version/s: 2.0.0 > Timezone Redirection > > > Key: GUACAMOLE-422 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-422 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-client, guacamole-server, RDP, SSH >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Minor > Fix For: 2.0.0 > > > It would be nice to support full timezone redirection from the browser client > through to a RDP server. There are a few challenges to making this work: > - Detect timezone at browser and pass that through to the servlet side, > somewhere. > - Handle timezone on servlet side and pass through to guacd > - Allow guacd to process the timezone and add it to the RDP connection. > For browser side, there is a JavaScript library, jstz, that can do the > detection and provide the timezone. Handling it on the servlet side, > however, requires some way to pass it in during the connection. This could > be done as a parameter at login time, or a separate api call. > Once it is into the servlet, there has to be a way to process it as a > parameter to a connection. I'm thinking maybe a token, but not sure that's > the right way to go. Once it's on the connection it can pass through to > guacd. > The biggest issue, I think, is then getting guacd to be able to add it to a > FreeRDP connection. From my looking at the current FreeRDP source code > (stable-1.1 branch), FreeRDP currently detects the timezone on the system > where it's running, first using the TZ variable, then looking at > /etc/localtime and/or /etc/TZ on the system. This means that it's always > going to redirect the timezone of the system where guacd is running, and not > the timezone of the browser. Unfortunately there don't seem to be any > available functions for sending FreeRDP a string representation of a timezone > and having it process it that way, and all of the timezone information is > located in the FreeRDP .c file, making it difficult to write a method for > handling this without duplicating a lot of code and all of the timezone > tables. So, not entirely sure the best route on that angle at this point, > but we'll see. > Any input on whether this is a reasonable thing to address, or a corner-case > not worth handling? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GUACAMOLE-524) Allow LDAP attributes to be used as token
[
https://issues.apache.org/jira/browse/GUACAMOLE-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman reassigned GUACAMOLE-524:
---
Assignee: Nick Couchman
> Allow LDAP attributes to be used as token
> -
>
> Key: GUACAMOLE-524
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-524
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-auth-ldap
>Reporter: Jared Frees
>Assignee: Nick Couchman
>Priority: Minor
> Fix For: 2.0.0
>
>
> Add support for using LDAP attributes as tokens for connection configuration.
> For example, map the attribute 'workstationName' of the current logged on
> user to a token USER_WORKSTATION that could then be used in a connection
> profile. This would allow using a single connection and for the destination
> to be determined by the LDAP attribute. This mapping should be configurable
> and could be used in a connection definition such as the following:
>
> dn: cn=Example Connection,ou=groups,dc=example,dc=net
> objectClass: guacConfigGroup
> objectClass: groupOfNames
> cn: Example Connection
> guacConfigProtocol: rdp
> guacConfigParameter: hostname=${USER_WORKSTATION}
> guacConfigParameter: username=${GUAC_USERNAME}
> guacConfigParameter: password=${GUAC_PASSWORD}
> member: cn=user1,ou=people,dc=example,dc=net
> member: cn=user2,ou=people,dc=example,dc=net
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GUACAMOLE-524) Allow LDAP attributes to be used as token
[
https://issues.apache.org/jira/browse/GUACAMOLE-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16634828#comment-16634828
]
Nick Couchman commented on GUACAMOLE-524:
-
{quote}
It universally allows arbitrary attributes to be set even though those
attributes are not supported nor persisted. The specification for
setAttributes() requires that this not be done so that extensions can detect
whether a custom attribute has been successfully set.
{quote}
To clarify what you're saying, in order to use the Attributes interface as its
designed (contracted), we would have to specifically identify "Supported"
attributes within the LDAP authentication extension that we intend to
allow/support. If I'm reading this correctly, we actually cannot use the
Attributes interface for arbitrary (that is, admin-configured) attributes?
Or would it be possible to read in from guacamole.properties the
user-configured attribute names and define those as the "Supported" attributes
dynamically, and then modify the getAttributes() and setAttributes() parameters
to handle appropriately?
{quote}
All attributes within the map are replaced with each call to setAttributes().
The specification for setAttributes() explicitly states that attributes not
within the given map must be left untouched.
{quote}
Depending on the answer to the first item, this may be moot, but assuming we
can read in the user-configured attribute names as "Supported" attributes and
still use this interface, this would mean that setAttributes() would need to go
through and add each of these attributes to the map. I'm guessing this would
be similar to the code that was used in some of the other modules to do things
like store TOTP extension information in JDBC?
> Allow LDAP attributes to be used as token
> -
>
> Key: GUACAMOLE-524
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-524
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-auth-ldap
>Reporter: Jared Frees
>Priority: Minor
> Fix For: 2.0.0
>
>
> Add support for using LDAP attributes as tokens for connection configuration.
> For example, map the attribute 'workstationName' of the current logged on
> user to a token USER_WORKSTATION that could then be used in a connection
> profile. This would allow using a single connection and for the destination
> to be determined by the LDAP attribute. This mapping should be configurable
> and could be used in a connection definition such as the following:
>
> dn: cn=Example Connection,ou=groups,dc=example,dc=net
> objectClass: guacConfigGroup
> objectClass: groupOfNames
> cn: Example Connection
> guacConfigProtocol: rdp
> guacConfigParameter: hostname=${USER_WORKSTATION}
> guacConfigParameter: username=${GUAC_USERNAME}
> guacConfigParameter: password=${GUAC_PASSWORD}
> member: cn=user1,ou=people,dc=example,dc=net
> member: cn=user2,ou=people,dc=example,dc=net
--
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 ] Nick Couchman updated GUACAMOLE-637: Priority: Minor (was: Major) > 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: Tony Gale >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 ] Nick Couchman updated GUACAMOLE-638: Priority: Minor (was: Major) > 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: Tony Gale >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] [Commented] (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:comment-tabpanel=16633940#comment-16633940 ] Nick Couchman commented on GUACAMOLE-637: - [~TonyGeeUK] As with GUACAMOLE-638, we definitely appreciate the patch and would love it if you'd be willing to do a pull request on the code and contribute to the project! Overall contribution guidelines are here: http://guacamole.apache.org/open-source/ Basically you'd just need to fork the code, create a branch for the changes, make the changes, and then create a pull request. You'll want to make sure that the Pull Request and commits follow the contribution guidelines (they should reference this JIRA issue), and that the code style is consistent with the style used throughout the project. > 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: Tony Gale >Priority: Major > > 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] [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=16633938#comment-16633938 ] Nick Couchman commented on GUACAMOLE-638: - [~TonyGeeUK] Definitely appreciate the patch - we would love it if you'd be willing to do a pull request on the code and contribute to the project! Overall contribution guidelines are here: http://guacamole.apache.org/open-source/ Basically you'd just need to fork the code, create a branch for the changes, make the changes, and then create a pull request. You'll want to make sure that the Pull Request and commits follow the contribution guidelines (they should reference this JIRA issue), and that the code style is consistent with the style used throughout the project. > 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: Tony Gale >Priority: Major > > 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] [Commented] (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:comment-tabpanel=16633935#comment-16633935 ] Nick Couchman commented on GUACAMOLE-637: - You selected version 1.0.0 - are you checking this out from the git repo? Just want to verify... > 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: Tony Gale >Priority: Major > > 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] [Commented] (GUACAMOLE-296) RDP audio input cause disconnection on Windows Server 2012 / 2016
[
https://issues.apache.org/jira/browse/GUACAMOLE-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16633550#comment-16633550
]
Nick Couchman commented on GUACAMOLE-296:
-
{quote}
Just to update this ticket... the Makefile fix discussed above still appears to
be needed in v0.9.14.
{quote}
Yeah, there's still something going on. I haven't had time to figure out what
it is, but, yes, something is still broken.
{quote}
However as an FYI... with 2016, I was forced to supply credentials and use
security mode NLA with "Ignore server certificate" checked.
{quote}
Yes, with either 2012 or 2016 Windows started requiring NLA and disabling the
old-style encryption. So this is not unexpected.
{quote}
I don't know if the 2016 issue is related to the Makefile change but I'm still
looking into in. 2016 works with rdesktop in Linux (unencrypted and you can
type in the credentials you want without supplying them on the command line as
usual) so there is something else going on.
{quote}
No, this has nothing to do with it. rdesktop on Linux, when it prompts on the
command line, has already negotiated NLA-based authentication with the remote
server, and is prompting for credentials on the command line in order to
complete the NLA-based authentication. Unless you're actually explicitly
disabling authentication on the command line (/sec:none)?
> RDP audio input cause disconnection on Windows Server 2012 / 2016
> -
>
> Key: GUACAMOLE-296
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-296
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole
>Affects Versions: 0.9.12-incubating
>Reporter: Hisham
>Priority: Major
> Labels: audio
>
> I know this problem was discussed in resolved thread, but it is a bit
> different, please help me, I tried every thing I was able to find about the
> topic.
> On Windows Server 2012 R2: Audio playback works, but the minute I start
> Sound settings in the "Recording" tab the connection gets disconnected
> immediately. After that it is impossible to connect to the VM with guacamole,
> because it keeps disconnecting immediately, the only why is using a RDP
> client, and closing the Audio settings.
> this are the log info:
> May 8 10:19:27 ip-172-31-20-3 guacd[14887]: Loading keymap "base"
> May 8 10:19:27 ip-172-31-20-3 guacd[14887]: Loading keymap "de-de-qwertz"
> May 8 10:19:27 ip-172-31-20-3 guacd[14887]: guacsnd connected.
> May 8 10:19:27 ip-172-31-20-3 guacd[14887]: guacdr connected.
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Connected to RDPDR 1.12 as
> client 0x0002
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set
> type=0x0001, length=44
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set
> type=0x0002, length=8
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set
> type=0x0003, length=8
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set
> type=0x0004, length=8
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Ignoring server capability set
> type=0x0005, length=8
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Sending capabilities...
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Capabilities sent.
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Client ID confirmed
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: User logged on
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Sending filesystem
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Registered device 0 (Guacamole
> Filesystem)
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: All supported devices sent.
> May 8 10:19:28 ip-172-31-20-3 guacd[14887]: Device 0 (Guacamole Filesystem)
> connected successfully
> May 8 10:19:37 ip-172-31-20-3 guacd[1183]: Connection
> "$70610038-ba7e-4e1d-9103-1b870c0cb079" removed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-580) Missing null check in LDAP AuthenticationProviderService
[ https://issues.apache.org/jira/browse/GUACAMOLE-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-580: Affects Version/s: (was: 1.0.1) > Missing null check in LDAP AuthenticationProviderService > > > Key: GUACAMOLE-580 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-580 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-ldap >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Minor > Fix For: 2.0.0 > > > Recent changes introduced by GUACAMOLE-524 are missing a check for a null > object, leading to a potential for a NullPointerException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-593) Make Member attribute customizable
[ https://issues.apache.org/jira/browse/GUACAMOLE-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-593: Fix Version/s: (was: 1.0.1) 2.0.0 > Make Member attribute customizable > -- > > Key: GUACAMOLE-593 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-593 > Project: Guacamole > Issue Type: Wish > Components: guacamole-auth-ldap >Affects Versions: 0.9.14 >Reporter: Alex Duarte >Assignee: Nick Couchman >Priority: Minor > Fix For: 2.0.0 > > > Currently, Guacamole looks for the Member attribute within LDAP to identify > what users are members of a group. I would like to request that this is made > a customizable field. I run guacamole on Fedora and we are primarily a Fedora > shop. With that said we use 389-DS and 389-DS does not have a member field by > default. The name of the field is uniquemember. Due to this, even after > adding someone to the LDAP group, I need to modify the group's attributes, > add a Member Attribute and manually add in the member values. This is less > than ideal as it would be nice to be able to add people to the group and call > it a day. Thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-580) Missing null check in LDAP AuthenticationProviderService
[ https://issues.apache.org/jira/browse/GUACAMOLE-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-580: Fix Version/s: (was: 1.0.1) 2.0.0 > Missing null check in LDAP AuthenticationProviderService > > > Key: GUACAMOLE-580 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-580 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-ldap >Affects Versions: 1.0.1 >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Minor > Fix For: 2.0.0 > > > Recent changes introduced by GUACAMOLE-524 are missing a check for a null > object, leading to a potential for a NullPointerException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-585) Dead code in JavaScript formField module
[
https://issues.apache.org/jira/browse/GUACAMOLE-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman updated GUACAMOLE-585:
Fix Version/s: (was: 1.0.1)
2.0.0
> Dead code in JavaScript formField module
>
>
> Key: GUACAMOLE-585
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-585
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole
>Affects Versions: 0.9.14
>Reporter: Nick Couchman
>Assignee: Nick Couchman
>Priority: Minor
> Fix For: 2.0.0
>
>
> Reported by Coverity:
> {quote}
>
> *** CID 1436956: Control flow issues (DEADCODE)
> /guacamole/src/main/webapp/app/form/directives/formField.js: 125 in
> $scope.getFieldOption()
> 119$scope.getFieldOption = function getFieldOption(value) {
> 120
> 121// If no field, or no value, then no corresponding
> translation string
> 122if (!$scope.field || !$scope.field.name || !value)
> 123return '';
> 124
> >>>CID 1436956: Control flow issues (DEADCODE)
> >>>Execution cannot reach the expression ""EMPTY"" inside this statement:
> >>> "return translationStringSer...".
> 125return
> translationStringService.canonicalize($scope.namespace || 'MISSING_NAMESPACE')
> 126+ '.FIELD_OPTION_' +
> translationStringService.canonicalize($scope.field.name)
> 127+ '_' +
> translationStringService.canonicalize(value || 'EMPTY');
> 128
> 129};
> 130
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-441) guacd ssh plugin segfault when copy text to clipboard
[
https://issues.apache.org/jira/browse/GUACAMOLE-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman updated GUACAMOLE-441:
Fix Version/s: (was: 1.0.1)
2.0.0
> guacd ssh plugin segfault when copy text to clipboard
> -
>
> Key: GUACAMOLE-441
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-441
> Project: Guacamole
> Issue Type: Bug
> Components: SSH, Terminal
>Affects Versions: 0.9.13-incubating, 0.9.14, 1.0.0
> Environment: GNU Linux x86_64
>Reporter: James He
>Assignee: Michael Jumper
>Priority: Minor
> Fix For: 2.0.0
>
>
> This segfault can be replicated each time when do the below steps.
> - Login to any SSH server from guacamole.
> - Try a command with much output e.g. "ps aux".
> - Select the output text of the above command.
> - SSH connection will be terminated immediately.
> - Core dump of guacd will be generated.
> {code:none}
> Core was generated by `/sbin/guacd -f'.
> Program terminated with signal SIGABRT, Aborted.
> #0 0x2bca8437 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0 0x2bca8437 in raise () from /lib64/libc.so.6
> #1 0x2bca9818 in abort () from /lib64/libc.so.6
> #2 0x2bce6574 in ?? () from /lib64/libc.so.6
> #3 0x2bcebdae in ?? () from /lib64/libc.so.6
> #4 0x2bcecab6 in ?? () from /lib64/libc.so.6
> #5 0x2db6b160 in __guac_terminal_send_mouse (term=0x2aaab401bf60,
> user=0x2aaab0002920, x=703, y=921,
> mask=0) at terminal.c:1715
> #6 0x2db6b2b5 in guac_terminal_send_mouse (term=0x2aaab401bf60,
> user=0x2aaab0002920, x=703, y=921, mask=0)
> at terminal.c:1753
> #7 0x2db5c532 in guac_ssh_user_mouse_handler (user=0x2aaab0002920,
> x=703, y=921, mask=0) at input.c:41
> #8 0x2af4dc2e in __guac_handle_mouse (user=0x2aaab0002920, argc=3,
> argv=0x2aaab000adc0)
> at user-handlers.c:134
> #9 0x2af4d3ea in guac_user_handle_instruction (user=0x2aaab0002920,
> opcode=0x2aaab0012b29 "mouse", argc=3,
> argv=0x2aaab000adc0) at user.c:178
> #10 0x004055e7 in guacd_user_input_thread (data=0x2f353d20) at
> user.c:127
> #11 0x2b8521a4 in start_thread (arg=0x2aab0d029700) at
> pthread_create.c:309
> #12 0x2bd5965d in clone () from /lib64/libc.so.6
> (gdb) frame 5
> #5 0x2db6b160 in __guac_terminal_send_mouse (term=0x2aaab401bf60,
> user=0x2aaab0002920, x=703, y=921,
> mask=0) at terminal.c:1715
> warning: Source file is more recent than executable.
> 1715guac_common_clipboard_reset(term->clipboard,
> "text/plain");
> (gdb) p term->clipboard->length
> $6 = 9500
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-146) Finer control of the tomcat context path in Docker
[
https://issues.apache.org/jira/browse/GUACAMOLE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman updated GUACAMOLE-146:
Fix Version/s: (was: 1.0.1)
2.0.0
> Finer control of the tomcat context path in Docker
> --
>
> Key: GUACAMOLE-146
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-146
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-docker
>Reporter: Emmanuel Frecon
>Assignee: Nick Couchman
>Priority: Minor
> Fix For: 2.0.0
>
>
> The current auto-deployment of the guacamole within tomcat leads to having
> the regular tomcat startup page mapped on {{/}} and guacamole mapped to
> {{/guacamole}}. Being able to control where guacamole gets to be deployed and
> served by tomcat would provide an increased flexibility when guacamole is
> fitted to existing architectures. For example, most docker-based deployments
> will use reverse-proxying to provide scalability and security.
> An initial fix for this is
> [available|https://github.com/apache/incubator-guacamole-client/pull/97/commits/1386239d3c12987daa774ed387a41c1471444f87].
> However, this does not provide full flexibility. As
> [described|https://github.com/apache/incubator-guacamole-client/pull/97#issuecomment-268341268],
> using an environment variable to control the context path would be a much
> better solution as it would provide full flexibility while still maintaining
> backwards compabitibility.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-569) Add translation for Simplified Chinese
[ https://issues.apache.org/jira/browse/GUACAMOLE-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-569: Fix Version/s: (was: 1.0.1) 2.0.0 > Add translation for Simplified Chinese > -- > > Key: GUACAMOLE-569 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-569 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-client >Reporter: Freddie Wu >Priority: Minor > Fix For: 2.0.0 > > > Add support for Simplified Chinese translation (zh). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GUACAMOLE-572) guacamole-server README says "test-based protocol" instead of "text-based protocol"
[ https://issues.apache.org/jira/browse/GUACAMOLE-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-572: Fix Version/s: (was: 1.0.1) 2.0.0 > guacamole-server README says "test-based protocol" instead of "text-based > protocol" > --- > > Key: GUACAMOLE-572 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-572 > Project: Guacamole > Issue Type: Bug > Components: Documentation >Reporter: Liron Newman >Priority: Trivial > Fix For: 2.0.0 > > > [guacamole-server > README|https://github.com/apache/guacamole-server/blob/master/README] says > "test-based protocol" instead of "text-based protocol". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
