[jira] [Commented] (GUACAMOLE-1026) Add support for FreeRDP 3.0.0
[
https://issues.apache.org/jira/browse/GUACAMOLE-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845462#comment-17845462
]
Mike Jumper commented on GUACAMOLE-1026:
{quote}
Are there any plans to support FreeRdP 3.0
{quote}
[~ajayk] Yes, that's what this JIRA issue was created for.
> Add support for FreeRDP 3.0.0
> -
>
> Key: GUACAMOLE-1026
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1026
> Project: Guacamole
> Issue Type: Improvement
> Components: RDP
>Reporter: Mike Jumper
>Priority: Major
>
> The nightly CI build testing that guacamole-server builds against the FreeRDP
> {{master}} branch started failing on 2020-04-10 due to the version bump to
> 3.0.0. It's currently unclear whether the API has changed, as well.
> The guacamole-server build should be adjusted such that it recognizes FreeRDP
> 3.0.0. If further code changes are necessary for this to work, those changes
> should probably also be made now before things get too hairy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1528) [Docker Version] SAML extension validating
[ https://issues.apache.org/jira/browse/GUACAMOLE-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper closed GUACAMOLE-1528. -- Resolution: Invalid > [Docker Version] SAML extension validating > --- > > Key: GUACAMOLE-1528 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1528 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-saml >Affects Versions: 1.4.0 > Environment: Docker >Reporter: Bryce Prutsos >Priority: Minor > Labels: SAML > > I am trying to configure SAML but the error it gives doesn't really help. > Specifically error [https-openssl-nio-8080-exec-7] WARN > o.a.g.a.s.a.AssertionConsumerServiceResource - Authentication attempted with > an invalid SAML response: SAML response did not pass validation: Signature > validation failed. SAML Response rejected. > > I am guessing it has to do with the x509 cert between the idp and guacamole > but there is nowhere to specify settings. > for the I have the following > > extension-priority: *, saml > saml-debug: true > saml-strict: false > saml-idp-url: https://login.localhost.com/sso/go.ashx > saml-entity-id: https://guac.localhost.com:8080/ > saml-callback-url: https://guac.localhost.com:8080 > mysql-auto-create-accounts: true > > LOGS BELOW > > 05:31:21.596 [main] INFO o.a.g.extension.ExtensionModule - Extension "SAML > Authentication Extension" (saml) loaded. > > 05:31:21.694 [main] INFO o.a.g.t.w.WebSocketTunnelModule - Loading JSR-356 > WebSocket support... > > 05:31:22.103 [main] WARN o.g.jersey.server.wadl.WadlFeature - JAXBContext > implementation could not be found. WADL feature is disabled. > > 03-Feb-2022 05:31:22.308 INFO [main] > org.apache.catalina.startup.HostConfig.deployWAR Deployment of web > application archive [/usr/local/tomcat/webapps/ROOT.war] has finished in > [3,099] ms > > 03-Feb-2022 05:31:22.312 INFO [main] org.apache.coyote.AbstractProtocol.start > Starting ProtocolHandler ["https-openssl-nio-8080"] > > 03-Feb-2022 05:31:22.342 INFO [main] > org.apache.catalina.startup.Catalina.start Server startup in [3171] > milliseconds > > 05:31:43.515 [https-openssl-nio-8080-exec-5] INFO > com.onelogin.saml2.util.Util - Found a deprecated algorithm > http://www.w3.org/2000/09/xmldsig#rsa-sha1 related to the Signature element, > consider requesting a more robust algorithm > > 05:31:43.518 [https-openssl-nio-8080-exec-5] ERROR > c.onelogin.saml2.authn.SamlResponse - Signature validation failed. SAML > Response rejected > > 05:31:43.518 [https-openssl-nio-8080-exec-5] WARN > o.a.g.a.s.a.AssertionConsumerServiceResource - Authentication attempted with > an invalid SAML response: SAML response did not pass validation: Signature > validation failed. SAML Response rejected > > 05:31:53.360 [https-openssl-nio-8080-exec-7] INFO > com.onelogin.saml2.util.Util - Found a deprecated algorithm > http://www.w3.org/2000/09/xmldsig#rsa-sha1 related to the Signature element, > consider requesting a more robust algorithm > > 05:31:53.360 [https-openssl-nio-8080-exec-7] ERROR > c.onelogin.saml2.authn.SamlResponse - Signature validation failed. SAML > Response rejected > > 05:31:53.360 [https-openssl-nio-8080-exec-7] WARN > o.a.g.a.s.a.AssertionConsumerServiceResource - Authentication attempted with > an invalid SAML response: SAML response did not pass validation: Signature > validation failed. SAML Response rejected -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-374) Installing Guacamole with Docker improvements
[
https://issues.apache.org/jira/browse/GUACAMOLE-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840180#comment-17840180
]
Mike Jumper commented on GUACAMOLE-374:
---
Automatic initialization of the database can be accomplished by mounting the
init scripts within the directory used by the relevant database container. For
example, a {{docker-compose.yml}} that uses PostgreSQL and initializes
everything automatically (reading the database admin password from
{{DB_PASSWORD}} environment variable supplied to {{docker compose}}) would be:
{code:none}
version: "3"
services:
guacamole:
image: guacamole/guacamole
restart: unless-stopped
depends_on:
- guacd
- db
environment:
GUACD_HOSTNAME: "guacd"
POSTGRESQL_HOSTNAME: "db"
POSTGRESQL_DATABASE: "guacamole_db"
POSTGRESQL_USERNAME: "guacamole_user"
POSTGRESQL_PASSWORD_FILE: "/run/secrets/database_password"
volumes:
- "initdb:/opt/guacamole/postgresql/schema:ro"
secrets:
- database_password
db:
image: postgres
restart: unless-stopped
environment:
POSTGRES_DB: "guacamole_db"
POSTGRES_USER: "guacamole_user"
POSTGRES_PASSWORD_FILE: "/run/secrets/database_password"
volumes:
- "initdb:/docker-entrypoint-initdb.d:ro"
secrets:
- database_password
guacd:
image: guacamole/guacd
restart: unless-stopped
volumes:
initdb:
secrets:
database_password:
environment: DB_PASSWORD
{code}
The magic here is the way an {{initdb}} volume has been declared and shared
between both {{guacamole}} and {{db}} containers.
> Installing Guacamole with Docker improvements
> -
>
> Key: GUACAMOLE-374
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-374
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-docker
> Environment: sven@fangorn:~$ docker version
> Client:
> Version: 17.06.1-ce
> API version: 1.30
> Go version: go1.8.3
> Git commit: 874a737
> Built:Thu Aug 17 22:51:12 2017
> OS/Arch: linux/amd64
> Server:
> Version: 17.06.1-ce
> API version: 1.30 (minimum version 1.12)
> Go version: go1.8.3
> Git commit: 874a737
> Built:Thu Aug 17 22:50:04 2017
> OS/Arch: linux/amd64
> Experimental: false
>Reporter: Sven Gottwald
>Assignee: Mike Jumper
>Priority: Minor
>
> I installed guacamole as docker container for the first time. Great software!
> I followed the guide on
> [https://guacamole.incubator.apache.org/doc/gug/guacamole-docker.html]. There
> is a lot of unnecessary work to get the container up and running, here are
> some suggestions to improve the documentation:
> # The link flag is a deprecated legacy feature of Docker. It may eventually
> be removed. [Legacy container links
> |https://docs.docker.com/engine/userguide/networking/default_network/dockerlinks/].
> It is no problem to get guacamole running with a user defined network.
> # The database should be generated automatically on first run. The user and
> database could be automatically created by
> [mariadb|https://hub.docker.com/_/mariadb/].
> # ...You should add mariadb as possible backend.
> # Due to its complexity (three services) you should provide a
> {{docker-compose.yml}} file for use with
> [docker-compose|https://docs.docker.com/compose/]. This also creates an user
> defined network.
> Here is an example {{docker-compose.yml}} for use with mariadb:
> {noformat}
> version: '3'
> services:
> guacd:
> image: guacamole/guacd
> depends_on:
> - db
> guac:
> image: guacamole/guacamole
> ports:
> - 8080:8080
> depends_on:
> - db
> - guacd
> environment:
> - GUACD_HOSTNAME=guacd
> - MYSQL_PASSWORD=x
> - MYSQL_DATABASE=guacamole_db
> - MYSQL_USER=guacamole_user
> - MYSQL_HOSTNAME=db
> db:
> image: mariadb
> volumes:
> - /srv/docker/guacamole-mysql:/var/lib/mysql
> environment:
> - MYSQL_ROOT_PASSWORD=x
> - MYSQL_PASSWORD=x
> - MYSQL_DATABASE=guacamole_db
> - MYSQL_USER=guacamole_user
> {noformat}
> I don't know why, but {{GUACD_HOSTNAME}} and {{MYSQL_HOSTNAME}} are needed
> (maybe a bug?)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GUACAMOLE-374) Installing Guacamole with Docker improvements
[
https://issues.apache.org/jira/browse/GUACAMOLE-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper reassigned GUACAMOLE-374:
-
Assignee: Mike Jumper
> Installing Guacamole with Docker improvements
> -
>
> Key: GUACAMOLE-374
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-374
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-docker
> Environment: sven@fangorn:~$ docker version
> Client:
> Version: 17.06.1-ce
> API version: 1.30
> Go version: go1.8.3
> Git commit: 874a737
> Built:Thu Aug 17 22:51:12 2017
> OS/Arch: linux/amd64
> Server:
> Version: 17.06.1-ce
> API version: 1.30 (minimum version 1.12)
> Go version: go1.8.3
> Git commit: 874a737
> Built:Thu Aug 17 22:50:04 2017
> OS/Arch: linux/amd64
> Experimental: false
>Reporter: Sven Gottwald
>Assignee: Mike Jumper
>Priority: Minor
>
> I installed guacamole as docker container for the first time. Great software!
> I followed the guide on
> [https://guacamole.incubator.apache.org/doc/gug/guacamole-docker.html]. There
> is a lot of unnecessary work to get the container up and running, here are
> some suggestions to improve the documentation:
> # The link flag is a deprecated legacy feature of Docker. It may eventually
> be removed. [Legacy container links
> |https://docs.docker.com/engine/userguide/networking/default_network/dockerlinks/].
> It is no problem to get guacamole running with a user defined network.
> # The database should be generated automatically on first run. The user and
> database could be automatically created by
> [mariadb|https://hub.docker.com/_/mariadb/].
> # ...You should add mariadb as possible backend.
> # Due to its complexity (three services) you should provide a
> {{docker-compose.yml}} file for use with
> [docker-compose|https://docs.docker.com/compose/]. This also creates an user
> defined network.
> Here is an example {{docker-compose.yml}} for use with mariadb:
> {noformat}
> version: '3'
> services:
> guacd:
> image: guacamole/guacd
> depends_on:
> - db
> guac:
> image: guacamole/guacamole
> ports:
> - 8080:8080
> depends_on:
> - db
> - guacd
> environment:
> - GUACD_HOSTNAME=guacd
> - MYSQL_PASSWORD=x
> - MYSQL_DATABASE=guacamole_db
> - MYSQL_USER=guacamole_user
> - MYSQL_HOSTNAME=db
> db:
> image: mariadb
> volumes:
> - /srv/docker/guacamole-mysql:/var/lib/mysql
> environment:
> - MYSQL_ROOT_PASSWORD=x
> - MYSQL_PASSWORD=x
> - MYSQL_DATABASE=guacamole_db
> - MYSQL_USER=guacamole_user
> {noformat}
> I don't know why, but {{GUACD_HOSTNAME}} and {{MYSQL_HOSTNAME}} are needed
> (maybe a bug?)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1732) Balanced apps with NLA and no username/password go into timeout
[
https://issues.apache.org/jira/browse/GUACAMOLE-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper closed GUACAMOLE-1732.
--
Fix Version/s: 1.5.5
Resolution: Fixed
Updating to reflect that changes addressing this were included in 1.5.5.
> Balanced apps with NLA and no username/password go into timeout
>
>
> Key: GUACAMOLE-1732
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1732
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole
>Affects Versions: 1.4.0
> Environment: Ubuntu 20.04.3 LTS
>Reporter: Giorgio Gianfriglia
>Priority: Minor
> Fix For: 1.5.5
>
> Attachments: balanced.png
>
>
> if you create a balanced app group, and the apps are configured in NLA
> security mode without username and password (or only without password), the
> balancing goes into timeout, not asking for login information.
> Instead, clicking on individual apps prompts for the username and/or password.
> If you set username and password in NLA security mode in the apps, the
> balanced group works, even using the variables ${GUAC_USERNAME} and
> ${GUAC_PASSWORD}.
> Thank you.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1938) Try other servers for load balancing group if a server times out/other connectivity event
[
https://issues.apache.org/jira/browse/GUACAMOLE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834107#comment-17834107
]
Mike Jumper commented on GUACAMOLE-1938:
{quote}
it appears the Guacamole "load balancing" algorithm ... does not try other
connections if a particular connection does not work (such as an invalid
connection address or timeout because it is down).
{quote}
It does, actually:
https://github.com/apache/guacamole-client/blob/83f0f193bd08f328fe43147bbe6787d721628509/extensions/guacamole-auth-jdbc/modules/guacamole-auth-jdbc-base/src/main/java/org/apache/guacamole/auth/jdbc/tunnel/AbstractGuacamoleTunnelService.java#L703
Perhaps it's just not patient enough while waiting for those failures?
> Try other servers for load balancing group if a server times out/other
> connectivity event
> -
>
> Key: GUACAMOLE-1938
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1938
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-auth-jdbc
>Affects Versions: 1.5.4
>Reporter: sbcbus
>Priority: Trivial
> Attachments: Screenshot 2024-04-04 at 3.04.23 PM.png
>
>
> Apologies if this issue exists somewhere, but I searched and posted on the
> mailing list.
> From trying myself with some test cases, receiving issue reports via my
> users, and discussions on the mailing list, it appears the Guacamole "load
> balancing" algorithm only handles the state where other users are connected
> and* does not try other connections if a particular connection does not work
> (such as an invalid connection address or timeout because it is down).*
> I would love for this functionality to exist to greatly reduce scenarios such
> as when one machine out of many is down and users seem to always get routed
> to that machine (either via affinity, or the LB algorithm – which as another
> request it would be nice if that could be a bit randomized to avoid always
> being taken to the same machine) even if many other working ones exist.
> In the scenario with a machine that isn't responding, I get a "connection is
> closed because server is taking too long to respond", but others are not
> tried.
> Screenshot is attached, and in the logs I get this:
> {noformat}
> Exception in thread "Thread-3" java.lang.IllegalStateException: Message will
> not be sent because the WebSocket session has been closed
> at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.writeMessagePart(WsRemoteEndpointImplBase.java:449)
> at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:307)
> at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:249)
> at
> org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:191)
> at
> org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:36)
> at
> org.apache.guacamole.websocket.GuacamoleWebSocketTunnelEndpoint.sendInstruction(GuacamoleWebSocketTunnelEndpoint.java:152)
> at
> org.apache.guacamole.websocket.GuacamoleWebSocketTunnelEndpoint.sendInstruction(GuacamoleWebSocketTunnelEndpoint.java:172)
> at
> org.apache.guacamole.websocket.GuacamoleWebSocketTunnelEndpoint.access$100(GuacamoleWebSocketTunnelEndpoint.java:53)
> at
> org.apache.guacamole.websocket.GuacamoleWebSocketTunnelEndpoint$2.run(GuacamoleWebSocketTunnelEndpoint.java:238)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-990) Enforce rate limit on authentication attempts
[
https://issues.apache.org/jira/browse/GUACAMOLE-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834022#comment-17834022
]
Mike Jumper commented on GUACAMOLE-990:
---
Yep, that's correct.
I don't recall whether we already added Docker environment variables around the
new extension's properties, but perhaps now would be a good time to switch
things around and leverage {{enable-environment-properties}} to avoid having to
manually update the images every time new properties are added. I made some
experimental changes implementing that, and it seems to work well (and deletes
a bunch of code).
> Enforce rate limit on authentication attempts
> -
>
> Key: GUACAMOLE-990
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-990
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-auth-totp
>Reporter: Graham
>Assignee: Mike Jumper
>Priority: Trivial
> Fix For: 1.6.0
>
>
> Google's [libpam
> module|https://github.com/google/google-authenticator-libpam/blob/master/man/google-authenticator.1.md]
> has a rate limit option to prevent brute forcing.
> Does Guacamole's TOTP have anything built-in that's introducing any
> sleep/delay in the code input loop?
> It _seems_ like it doesn't from my clumsy attempts at testing this by just
> hammering the keyboard :)
> If that's true then it seems like this would potentially be easier to bypass
> than even the password itself. I might be butchering the napkin math here,
> but with a possible number range of 1 million (6 digits) and 30 seconds,
> assuming a WAN latency per attempt of 7ms, that would mean that on average,
> once a hacker broke a password, they could then break through the TOTP
> segment over a scripted 233 login attempts or so.
> If there was even a plain old unconfigurable 1 second sleep/delay (or better
> yet, a continually increasing delay of n*1second based on past failure count
> in the current cycle) built in to the code input loop between attempts
> without even any added guacamole.properties options being introduced, I think
> this would basically handle the problem by pushing the possible average
> breakthrough time into unreasonable timelines.
> Also, though this would be another issue, it seemed that incrementing
> totp-digits with v1.1.0 to 8 didn't result in 8 digits being displayed when I
> scanned the resulting barcode in google authenticator. The introductory user
> bit did specify 8 digits - just not the resulting google authenticator entry.
> That may just be a bug in google authenticator however - not sure as I
> haven't tested any other TOTP apps, but I thought I'd mention it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1937) The user is disconnected after a period of time, and the buff/cache is not released
[
https://issues.apache.org/jira/browse/GUACAMOLE-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833659#comment-17833659
]
Mike Jumper commented on GUACAMOLE-1937:
There isn't. The {{buff/cache}} entry displayed by {{free}} has nothing to do
with the memory consumed by applications. It's memory used by the kernel for
disk cache.
See: https://unix.stackexchange.com/a/521493
> The user is disconnected after a period of time, and the buff/cache is not
> released
> ---
>
> Key: GUACAMOLE-1937
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1937
> Project: Guacamole
> Issue Type: Bug
> Components: guacd
>Affects Versions: 1.5.4
>Reporter: CaoShulin
>Priority: Minor
> Attachments: image-2024-04-03-17-59-27-491.png,
> image-2024-04-03-18-00-25-010.png
>
>
> Local host: Windows host
> Remote host: Windows host
> guacamole version: 1.5.4
> Protocol: rdp
> guacd：EulerOS 2.9 64bit | 4vCPUs | 8GiB
> To test the guacamole, use free -h to see the initial memory of the guacd
> server, as shown in Figure 1. With the continuous access of users, about 100
> people were connected for 2 hours. The memory of the guacd server was
> checked, and it was found that the memory of the guacd server was
> continuously increased. However, after the connection was disconnected, the
> memory occupied by buff/cache was not released, as shown in Figure 2. Please
> help analyze whether guacd has memory leakage problem.
> Figure 1:
> !image-2024-04-03-17-59-27-491.png!
> Figure 2:
> !image-2024-04-03-18-00-25-010.png!
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1937) The user is disconnected after a period of time, and the buff/cache is not released
[ https://issues.apache.org/jira/browse/GUACAMOLE-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper closed GUACAMOLE-1937. -- Resolution: Invalid > The user is disconnected after a period of time, and the buff/cache is not > released > --- > > Key: GUACAMOLE-1937 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1937 > Project: Guacamole > Issue Type: Bug > Components: guacd >Affects Versions: 1.5.4 >Reporter: CaoShulin >Priority: Minor > Attachments: image-2024-04-03-17-59-27-491.png, > image-2024-04-03-18-00-25-010.png > > > Local host: Windows host > Remote host: Windows host > guacamole version: 1.5.4 > Protocol: rdp > guacd：EulerOS 2.9 64bit | 4vCPUs | 8GiB > To test the guacamole, use free -h to see the initial memory of the guacd > server, as shown in Figure 1. With the continuous access of users, about 100 > people were connected for 2 hours. The memory of the guacd server was > checked, and it was found that the memory of the guacd server was > continuously increased. However, after the connection was disconnected, the > memory occupied by buff/cache was not released, as shown in Figure 2. Please > help analyze whether guacd has memory leakage problem. > Figure 1: > !image-2024-04-03-17-59-27-491.png! > Figure 2: > !image-2024-04-03-18-00-25-010.png! > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1936) Finnish keyboard input
[ https://issues.apache.org/jira/browse/GUACAMOLE-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper closed GUACAMOLE-1936. -- Resolution: Invalid > Finnish keyboard input > -- > > Key: GUACAMOLE-1936 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1936 > Project: Guacamole > Issue Type: Bug >Reporter: zhenfa zhao >Priority: Major > > When the local computer uses the Finnish keyboard and the RDP is set to the > Finnish keyboard, the symbols cannot be entered accurately > Corresponding keyboard keys: > / ; ' [ ] \ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1936) Finnish keyboard input
[ https://issues.apache.org/jira/browse/GUACAMOLE-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832246#comment-17832246 ] Mike Jumper commented on GUACAMOLE-1936: The keyboard layout for the connection and the keyboard layout within the remote desktop must match for Guacamole to be able to supply the RDP server with the correct events. If you connect to an RDP connection and then subsequently change the keyboard layout inside that RDP connection, Guacamole cannot know that you have done this and continues expecting that the remote keyboard layout is as originally set for the remote desktop session. It continues sending scancodes that would be correct for the original keyboard layout, but are no longer correct for the new layout. See: https://guacamole.apache.org/faq/#does-guacamole-support-my-keyboard-layout You don't typically need to set the keyboard layout within the RDP session, as Guacamole will automatically translate key presses that are missing from the RDP layout into Unicode events, allowing typing to work consistently regardless of the remote layout. If you wish to use a Finnish keyboard to type in Guacamole, you need to: # Set the Finnish keyboard _on the client machine only_. # Change nothing on the RDP server. # Change nothing in the RDP connection settings. ... and that's it. Guacamole will automatically translate the key events as long as you don't touch the _remote_ keyboard layout after connecting. > Finnish keyboard input > -- > > Key: GUACAMOLE-1936 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1936 > Project: Guacamole > Issue Type: Bug >Reporter: zhenfa zhao >Priority: Major > > When the local computer uses the Finnish keyboard and the RDP is set to the > Finnish keyboard, the symbols cannot be entered accurately > Corresponding keyboard keys: > / ; ' [ ] \ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1905) Update dependencies to latest stable and compatible versions
[
https://issues.apache.org/jira/browse/GUACAMOLE-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper closed GUACAMOLE-1905.
--
Resolution: Done
I think we're good to go now, with the exception of the version of Bouncy
Castle used by {{cas-client-core}} (difficult to verify that this is safe to
override - see [https://github.com/apache/guacamole-client/pull/964]).
> Update dependencies to latest stable and compatible versions
>
>
> Key: GUACAMOLE-1905
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1905
> Project: Guacamole
> Issue Type: Task
>Reporter: Nick Couchman
>Assignee: Mike Jumper
>Priority: Minor
> Fix For: 1.5.5
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (GUACAMOLE-1905) Update dependencies to latest stable and compatible versions
[
https://issues.apache.org/jira/browse/GUACAMOLE-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper reopened GUACAMOLE-1905:
Assignee: Mike Jumper (was: Nick Couchman)
There are a couple dependencies that recently got new versions that look like
they should be compatible, so I'm going to give bumping those a try:
* Jackson has released 2.17.0
* Kotlin has released 1.9.23
Additionally, it _looks_ like the version of Bouncy Castle used by CAS is
upgradable from 1.70 to 1.77, but doesn't currently show up as such because the
Maven dependency changed artifact IDs from {{bcpkix-jdk15on}} to
{{bcpkix-jdk15to18}}. If I can confirm this is compatible, I'll bump that, too.
> Update dependencies to latest stable and compatible versions
>
>
> Key: GUACAMOLE-1905
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1905
> Project: Guacamole
> Issue Type: Task
>Reporter: Nick Couchman
>Assignee: Mike Jumper
>Priority: Minor
> Fix For: 1.5.5
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1930) ssh host verification not working | docker
[
https://issues.apache.org/jira/browse/GUACAMOLE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827183#comment-17827183
]
Mike Jumper commented on GUACAMOLE-1930:
{quote}
I followed your documentation, how to put a known_hosts record into the
connection profile (Public host key (Base64)), tried following:
{code:none}
testpc.test.com ssh-ed25519 XXXABCDEFGHNVjaOK+MgqlZSHPoNHHpuptJAOxYW6o
ssh-ed25519 XXXABCDEFGHNVjaOK+MgqlZSHPoNHHpuptJAOxYW6o
{code}
{quote}
To clarify, you tried each of the above lines individually (ie: two different
test attempts)?
That leading "XXXABCDEFGH" looks off. Are the public key values shown above
placeholders and not the true values that you used?
{quote}
I also tried increasing log verbosity with
{code:none}
-e LOGBACK_LEVEL=DEBUG
{code}
{quote}
The relevant container for the issue at hand would be the guacd container, and
that container's log level is set with the {{GUACD_LOG_LEVEL}} environment
variable. This also goes for the {{/etc/guacamole/ssh_known_hosts}} file, which
would need to be present in the guacd container (not the guacamole container)
to be read by guacd.
> ssh host verification not working | docker
> --
>
> Key: GUACAMOLE-1930
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1930
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole
>Affects Versions: 1.5.4
> Environment: host os: Debian GNU/Linux 12 (bookworm)
> Docker version 25.0.3, build 4debf41
> Containers:
> guacamole/guacd
> guacamole/guacamole
>Reporter: Tomas
>Priority: Minor
>
> I've installed guacamole - your docker version, but I've got problems logging
> into ssh sessions with any kind of host verification.
> docker config:
> {code:java}
> docker run \
> -d \
> --net brig \
> --ip 10.0.0.6 \
> -p 4822:4822 \
> --name guacamole-guacd \
> --restart always \
> guacamole/guacd
> docker run \
> -d \
> --net brig \
> --ip 10.0.0.7 \
> -p 8001:8080 \
> --name apache-guacamole \
> --restart always \
> -e TZ=Europe/Prague \
> -e GUACD_HOSTNAME=10.0.0.6 \
> -e GUACD_PORT=4822 \
> -e MYSQL_HOSTNAME=10.0.0.5 \
> -e MYSQL_PORT=3306 \
> -e MYSQL_DATABASE=aguacamole \
> -e MYSQL_USER=aguacamole \
> -e MYSQL_PASSWORD=mypw \
> -v
> /media/AppData/volumes/aguacamole_volume/_data/home-guacamole:/home/guacamole
> \
> guacamole/guacamole
> {code}
> I followed your documentation, how to put a known_hosts record into the
> connection profile (Public host key (Base64)), tried following:
> {code:java}
> testpc.test.com ssh-ed25519 XXXABCDEFGHNVjaOK+MgqlZSHPoNHHpuptJAOxYW6o
> ssh-ed25519 XXXABCDEFGHNVjaOK+MgqlZSHPoNHHpuptJAOxYW6o{code}
> however the result has been always:
> {code:java}
> guacd[1531]: INFO: User "@03827a1f-b013-4d5c-afdb-6cb08f19e56b" joined
> connection "$2df823fa-d766-40e8-8f1f-f7dae923dc2d" (1 users now present)
> guacd[1531]: ERROR: Host key not found for testpc.test.com.
> guacd[1531]: ERROR: Host key did not match any provided known host keys.
> guacd[1531]: INFO: User "@03827a1f-b013-4d5c-afdb-6cb08f19e56b" disconnected
> (0 users remain)
> guacd[1531]: INFO: Last user of connection
> "$2df823fa-d766-40e8-8f1f-f7dae923dc2d" disconnected{code}
> I tried to put also "ssh_known_hosts" file into GUACAMOLE_HOME with the same
> records, however, the file gets ignored... and it's same as if I don't setup
> any key. They connection establishes, but without any verification.
> {code:java}
> guacd[72]: INFO: User "@ba02fef7-0ba5-4871-a7a9-2cd1964b580d" joined
> connection "$addd82d3-df83-4485-9baa-8af059817a4d" (1 users now present)
> guacd[72]: WARNING: No known host keys provided, host identity will not be
> verified.
> guacd[72]: WARNING: Unable to set the timezone: SSH server refused to set
> "TZ" variable.
> guacd[72]: WARNING: No known host keys provided, host identity will not be
> verified.
> guacd[72]: INFO: SSH connection successful.{code}
> Is there a way to fix this please? I also tried increasing log verbosity with
> {code:java}
> -e LOGBACK_LEVEL=DEBUG
> {code}
> on guacd container, but it did not make what it was supposed to do. Thank
> you, any advice apreciated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1906) Bump versions to 1.5.5
[
https://issues.apache.org/jira/browse/GUACAMOLE-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824849#comment-17824849
]
Mike Jumper commented on GUACAMOLE-1906:
You can create it, yep. That would just be a branch off of {{patch}}.
> Bump versions to 1.5.5
> --
>
> Key: GUACAMOLE-1906
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1906
> Project: Guacamole
> Issue Type: Task
>Reporter: Nick Couchman
>Assignee: Nick Couchman
>Priority: Blocker
> Fix For: 1.5.5
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1928) Log hints/notes for suspected causes of third-party library failures
[
https://issues.apache.org/jira/browse/GUACAMOLE-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper updated GUACAMOLE-1928:
---
Component/s: guacamole
(was: guacamole-auth-jdbc-mysql)
> Log hints/notes for suspected causes of third-party library failures
>
>
> Key: GUACAMOLE-1928
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1928
> Project: Guacamole
> Issue Type: Wish
> Components: guacamole
> Environment: AlmaLinux 9, Tomcat 9.0.62-37.el9_3.1, guacd
> 1.5.4-1.el9, mariadb-java-client-3.3.3.jar, Extension: mysql, ldap
>Reporter: Stefan Bluhm
>Priority: Minor
>
> The information logging of the MySQL/MariaDB extention is not sufficient and
> should show more reasons of connection failures.
> Example: When the DB server has an expired SSL certificate, Guacamole only
> logs:
>
> {quote}Mar 04 19:29:52 server.example.com server[972]: 19:29:52.465
> [http-nio-8080-exec-10] WARN o.a.g.e.AuthenticationProviderFacade - The
> "mysql" authentication provider has encountered an internal error which will
> halt the authentication process. If this is unexpected or you are the
> developer of this authentication provider, you may wish to enable debug-level
> logging. If this is expected and you wish to ignore such failures in the
> future, please set "skip-if-unavailable: mysql" within your
> guacamole.properties.
> Mar 04 19:29:52 server.example.com server[972]: 19:29:52.468
> [http-nio-8080-exec-10] ERROR o.a.g.rest.RESTExceptionMapper - Unexpected
> internal error:
> Mar 04 19:29:52 server.example.com server[972]: ### Error querying database.
> Cause: com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications
> link failure
> Mar 04 19:29:52 server.example.com server[972]: The last packet sent
> successfully to the server was 0 milliseconds ago. The driver has not
> received any packets from the server.
> Mar 04 19:29:52 server.example.com server[972]: ### The error may exist in
> org/apache/guacamole/auth/jdbc/user/UserMapper.xml
> Mar 04 19:29:52 server.example.com server[972]: ### The error may involve
> org.apache.guacamole.auth.jdbc.user.UserMapper.selectOne
> Mar 04 19:29:52 server.example.com server[972]: ### The error occurred while
> executing a query
> Mar 04 19:29:52 server.example.com server[972]: ### Cause:
> com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link
> failure
> Mar 04 19:29:52 server.example.com server[972]: The last packet sent
> successfully to the server was 0 milliseconds ago. The driver has not
> received any packets from the server.
> {quote}
>
> The DB Server only phrases that that the connection has been closed by the
> client.
>
> Debug mode gave more information:
> {quote}{{Mar 5 12:06:45 server.example.com server[62724]: Caused by:
> javax.net.ssl.SSLHandshakeException: NotAfter: Sat Jan 13 17:21:58 CET 2024}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:360)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:303)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:298)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1357)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(CertificateMessage.java:1232)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(CertificateMessage.java:1175)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:183)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)}}
> {{Mar 5 12:06:45 server.example.com server[62724]:
[jira] [Comment Edited] (GUACAMOLE-1928) Log hints/notes for suspected causes of third-party library failures
[
https://issues.apache.org/jira/browse/GUACAMOLE-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823819#comment-17823819
]
Mike Jumper edited comment on GUACAMOLE-1928 at 3/6/24 1:09 AM:
It might be possible within the webapp to inspect the various causing
exceptions of errors that make it to that level, adding helpful notes if the
cause is of a known type (like SSL validation failures).
This wouldn't solve the underlying issue (the JDBC driver lacking helpful
information in its error message), but it would at least help users of
Guacamole diagnose errors when a library has less-than-helpful messaging
without having to resort to debug-level logging and wading through strack
traces.
was (Author: mike.jumper):
It might be possible within the webapp to inspect the various causing
exceptions of errors that make it to that level, adding helpful notes of the
cause is of a known type (like SSL validation failures).
This wouldn't solve the underlying issue (the JDBC driver lacking helpful
information in its error message), but it would at least help users of
Guacamole diagnose errors when a library has less-than-helpful messaging
without having to resort to debug-level logging and wading through strack
traces.
> Log hints/notes for suspected causes of third-party library failures
>
>
> Key: GUACAMOLE-1928
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1928
> Project: Guacamole
> Issue Type: Wish
> Components: guacamole-auth-jdbc-mysql
> Environment: AlmaLinux 9, Tomcat 9.0.62-37.el9_3.1, guacd
> 1.5.4-1.el9, mariadb-java-client-3.3.3.jar, Extension: mysql, ldap
>Reporter: Stefan Bluhm
>Priority: Minor
>
> The information logging of the MySQL/MariaDB extention is not sufficient and
> should show more reasons of connection failures.
> Example: When the DB server has an expired SSL certificate, Guacamole only
> logs:
>
> {quote}Mar 04 19:29:52 server.example.com server[972]: 19:29:52.465
> [http-nio-8080-exec-10] WARN o.a.g.e.AuthenticationProviderFacade - The
> "mysql" authentication provider has encountered an internal error which will
> halt the authentication process. If this is unexpected or you are the
> developer of this authentication provider, you may wish to enable debug-level
> logging. If this is expected and you wish to ignore such failures in the
> future, please set "skip-if-unavailable: mysql" within your
> guacamole.properties.
> Mar 04 19:29:52 server.example.com server[972]: 19:29:52.468
> [http-nio-8080-exec-10] ERROR o.a.g.rest.RESTExceptionMapper - Unexpected
> internal error:
> Mar 04 19:29:52 server.example.com server[972]: ### Error querying database.
> Cause: com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications
> link failure
> Mar 04 19:29:52 server.example.com server[972]: The last packet sent
> successfully to the server was 0 milliseconds ago. The driver has not
> received any packets from the server.
> Mar 04 19:29:52 server.example.com server[972]: ### The error may exist in
> org/apache/guacamole/auth/jdbc/user/UserMapper.xml
> Mar 04 19:29:52 server.example.com server[972]: ### The error may involve
> org.apache.guacamole.auth.jdbc.user.UserMapper.selectOne
> Mar 04 19:29:52 server.example.com server[972]: ### The error occurred while
> executing a query
> Mar 04 19:29:52 server.example.com server[972]: ### Cause:
> com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link
> failure
> Mar 04 19:29:52 server.example.com server[972]: The last packet sent
> successfully to the server was 0 milliseconds ago. The driver has not
> received any packets from the server.
> {quote}
>
> The DB Server only phrases that that the connection has been closed by the
> client.
>
> Debug mode gave more information:
> {quote}{{Mar 5 12:06:45 server.example.com server[62724]: Caused by:
> javax.net.ssl.SSLHandshakeException: NotAfter: Sat Jan 13 17:21:58 CET 2024}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:360)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:303)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:298)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1357)}}
> {{Mar 5 12:06:45 server.example.com server[62724]:
[jira] [Updated] (GUACAMOLE-1928) Log hints/notes for suspected causes of third-party library failures
[
https://issues.apache.org/jira/browse/GUACAMOLE-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper updated GUACAMOLE-1928:
---
Summary: Log hints/notes for suspected causes of third-party library
failures (was: Show better error description in logs on MySQL authentication
failure)
> Log hints/notes for suspected causes of third-party library failures
>
>
> Key: GUACAMOLE-1928
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1928
> Project: Guacamole
> Issue Type: Wish
> Components: guacamole-auth-jdbc-mysql
> Environment: AlmaLinux 9, Tomcat 9.0.62-37.el9_3.1, guacd
> 1.5.4-1.el9, mariadb-java-client-3.3.3.jar, Extension: mysql, ldap
>Reporter: Stefan Bluhm
>Priority: Minor
>
> The information logging of the MySQL/MariaDB extention is not sufficient and
> should show more reasons of connection failures.
> Example: When the DB server has an expired SSL certificate, Guacamole only
> logs:
>
> {quote}Mar 04 19:29:52 server.example.com server[972]: 19:29:52.465
> [http-nio-8080-exec-10] WARN o.a.g.e.AuthenticationProviderFacade - The
> "mysql" authentication provider has encountered an internal error which will
> halt the authentication process. If this is unexpected or you are the
> developer of this authentication provider, you may wish to enable debug-level
> logging. If this is expected and you wish to ignore such failures in the
> future, please set "skip-if-unavailable: mysql" within your
> guacamole.properties.
> Mar 04 19:29:52 server.example.com server[972]: 19:29:52.468
> [http-nio-8080-exec-10] ERROR o.a.g.rest.RESTExceptionMapper - Unexpected
> internal error:
> Mar 04 19:29:52 server.example.com server[972]: ### Error querying database.
> Cause: com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications
> link failure
> Mar 04 19:29:52 server.example.com server[972]: The last packet sent
> successfully to the server was 0 milliseconds ago. The driver has not
> received any packets from the server.
> Mar 04 19:29:52 server.example.com server[972]: ### The error may exist in
> org/apache/guacamole/auth/jdbc/user/UserMapper.xml
> Mar 04 19:29:52 server.example.com server[972]: ### The error may involve
> org.apache.guacamole.auth.jdbc.user.UserMapper.selectOne
> Mar 04 19:29:52 server.example.com server[972]: ### The error occurred while
> executing a query
> Mar 04 19:29:52 server.example.com server[972]: ### Cause:
> com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link
> failure
> Mar 04 19:29:52 server.example.com server[972]: The last packet sent
> successfully to the server was 0 milliseconds ago. The driver has not
> received any packets from the server.
> {quote}
>
> The DB Server only phrases that that the connection has been closed by the
> client.
>
> Debug mode gave more information:
> {quote}{{Mar 5 12:06:45 server.example.com server[62724]: Caused by:
> javax.net.ssl.SSLHandshakeException: NotAfter: Sat Jan 13 17:21:58 CET 2024}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:360)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:303)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:298)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1357)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(CertificateMessage.java:1232)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(CertificateMessage.java:1175)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:183)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
>
[jira] [Reopened] (GUACAMOLE-1928) Show better error description in logs on MySQL authentication failure
[
https://issues.apache.org/jira/browse/GUACAMOLE-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper reopened GUACAMOLE-1928:
It might be possible within the webapp to inspect the various causing
exceptions of errors that make it to that level, adding helpful notes of the
cause is of a known type (like SSL validation failures).
This wouldn't solve the underlying issue (the JDBC driver lacking helpful
information in its error message), but it would at least help users of
Guacamole diagnose errors when a library has less-than-helpful messaging
without having to resort to debug-level logging and wading through strack
traces.
> Show better error description in logs on MySQL authentication failure
> -
>
> Key: GUACAMOLE-1928
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1928
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-auth-jdbc-mysql
> Environment: AlmaLinux 9, Tomcat 9.0.62-37.el9_3.1, guacd
> 1.5.4-1.el9, mariadb-java-client-3.3.3.jar, Extension: mysql, ldap
>Reporter: Stefan Bluhm
>Priority: Minor
>
> The information logging of the MySQL/MariaDB extention is not sufficient and
> should show more reasons of connection failures.
> Example: When the DB server has an expired SSL certificate, Guacamole only
> logs:
>
> {quote}Mar 04 19:29:52 server.example.com server[972]: 19:29:52.465
> [http-nio-8080-exec-10] WARN o.a.g.e.AuthenticationProviderFacade - The
> "mysql" authentication provider has encountered an internal error which will
> halt the authentication process. If this is unexpected or you are the
> developer of this authentication provider, you may wish to enable debug-level
> logging. If this is expected and you wish to ignore such failures in the
> future, please set "skip-if-unavailable: mysql" within your
> guacamole.properties.
> Mar 04 19:29:52 server.example.com server[972]: 19:29:52.468
> [http-nio-8080-exec-10] ERROR o.a.g.rest.RESTExceptionMapper - Unexpected
> internal error:
> Mar 04 19:29:52 server.example.com server[972]: ### Error querying database.
> Cause: com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications
> link failure
> Mar 04 19:29:52 server.example.com server[972]: The last packet sent
> successfully to the server was 0 milliseconds ago. The driver has not
> received any packets from the server.
> Mar 04 19:29:52 server.example.com server[972]: ### The error may exist in
> org/apache/guacamole/auth/jdbc/user/UserMapper.xml
> Mar 04 19:29:52 server.example.com server[972]: ### The error may involve
> org.apache.guacamole.auth.jdbc.user.UserMapper.selectOne
> Mar 04 19:29:52 server.example.com server[972]: ### The error occurred while
> executing a query
> Mar 04 19:29:52 server.example.com server[972]: ### Cause:
> com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link
> failure
> Mar 04 19:29:52 server.example.com server[972]: The last packet sent
> successfully to the server was 0 milliseconds ago. The driver has not
> received any packets from the server.
> {quote}
>
> The DB Server only phrases that that the connection has been closed by the
> client.
>
> Debug mode gave more information:
> {quote}{{Mar 5 12:06:45 server.example.com server[62724]: Caused by:
> javax.net.ssl.SSLHandshakeException: NotAfter: Sat Jan 13 17:21:58 CET 2024}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:360)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:303)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:298)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1357)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(CertificateMessage.java:1232)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(CertificateMessage.java:1175)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)}}
> {{Mar 5 12:06:45
[jira] [Updated] (GUACAMOLE-1928) Show better error description in logs on MySQL authentication failure
[
https://issues.apache.org/jira/browse/GUACAMOLE-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper updated GUACAMOLE-1928:
---
Issue Type: Wish (was: Improvement)
> Show better error description in logs on MySQL authentication failure
> -
>
> Key: GUACAMOLE-1928
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1928
> Project: Guacamole
> Issue Type: Wish
> Components: guacamole-auth-jdbc-mysql
> Environment: AlmaLinux 9, Tomcat 9.0.62-37.el9_3.1, guacd
> 1.5.4-1.el9, mariadb-java-client-3.3.3.jar, Extension: mysql, ldap
>Reporter: Stefan Bluhm
>Priority: Minor
>
> The information logging of the MySQL/MariaDB extention is not sufficient and
> should show more reasons of connection failures.
> Example: When the DB server has an expired SSL certificate, Guacamole only
> logs:
>
> {quote}Mar 04 19:29:52 server.example.com server[972]: 19:29:52.465
> [http-nio-8080-exec-10] WARN o.a.g.e.AuthenticationProviderFacade - The
> "mysql" authentication provider has encountered an internal error which will
> halt the authentication process. If this is unexpected or you are the
> developer of this authentication provider, you may wish to enable debug-level
> logging. If this is expected and you wish to ignore such failures in the
> future, please set "skip-if-unavailable: mysql" within your
> guacamole.properties.
> Mar 04 19:29:52 server.example.com server[972]: 19:29:52.468
> [http-nio-8080-exec-10] ERROR o.a.g.rest.RESTExceptionMapper - Unexpected
> internal error:
> Mar 04 19:29:52 server.example.com server[972]: ### Error querying database.
> Cause: com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications
> link failure
> Mar 04 19:29:52 server.example.com server[972]: The last packet sent
> successfully to the server was 0 milliseconds ago. The driver has not
> received any packets from the server.
> Mar 04 19:29:52 server.example.com server[972]: ### The error may exist in
> org/apache/guacamole/auth/jdbc/user/UserMapper.xml
> Mar 04 19:29:52 server.example.com server[972]: ### The error may involve
> org.apache.guacamole.auth.jdbc.user.UserMapper.selectOne
> Mar 04 19:29:52 server.example.com server[972]: ### The error occurred while
> executing a query
> Mar 04 19:29:52 server.example.com server[972]: ### Cause:
> com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link
> failure
> Mar 04 19:29:52 server.example.com server[972]: The last packet sent
> successfully to the server was 0 milliseconds ago. The driver has not
> received any packets from the server.
> {quote}
>
> The DB Server only phrases that that the connection has been closed by the
> client.
>
> Debug mode gave more information:
> {quote}{{Mar 5 12:06:45 server.example.com server[62724]: Caused by:
> javax.net.ssl.SSLHandshakeException: NotAfter: Sat Jan 13 17:21:58 CET 2024}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:360)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:303)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:298)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1357)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(CertificateMessage.java:1232)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(CertificateMessage.java:1175)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:183)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
>
[jira] [Commented] (GUACAMOLE-1928) Show better error description in logs on MySQL authentication failure
[
https://issues.apache.org/jira/browse/GUACAMOLE-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823815#comment-17823815
]
Mike Jumper commented on GUACAMOLE-1928:
This is not possible - the messaging for the error in question is controlled by
the JDBC driver, not by Guacamole.
Within Guacamole, we intentionally do not include stack traces within the logs
at any level except debug, as they are nearly always too noisy and lacking in
actionable information. It's unfortunate that the JDBC driver in question does
not specifically log the nature of the error _except_ buried deep inside a
stack trace, but I would hope that changes in a future release of that driver.
I suggest opening a request with the maintainer of the JDBC driver for
improving the error messaging beyond, simply:
{code:none}
Communications link failure
{code}
> Show better error description in logs on MySQL authentication failure
> -
>
> Key: GUACAMOLE-1928
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1928
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-auth-jdbc-mysql
> Environment: AlmaLinux 9, Tomcat 9.0.62-37.el9_3.1, guacd
> 1.5.4-1.el9, mariadb-java-client-3.3.3.jar, Extension: mysql, ldap
>Reporter: Stefan Bluhm
>Priority: Minor
>
> The information logging of the MySQL/MariaDB extention is not sufficient and
> should show more reasons of connection failures.
> Example: When the DB server has an expired SSL certificate, Guacamole only
> logs:
>
> {quote}Mar 04 19:29:52 server.example.com server[972]: 19:29:52.465
> [http-nio-8080-exec-10] WARN o.a.g.e.AuthenticationProviderFacade - The
> "mysql" authentication provider has encountered an internal error which will
> halt the authentication process. If this is unexpected or you are the
> developer of this authentication provider, you may wish to enable debug-level
> logging. If this is expected and you wish to ignore such failures in the
> future, please set "skip-if-unavailable: mysql" within your
> guacamole.properties.
> Mar 04 19:29:52 server.example.com server[972]: 19:29:52.468
> [http-nio-8080-exec-10] ERROR o.a.g.rest.RESTExceptionMapper - Unexpected
> internal error:
> Mar 04 19:29:52 server.example.com server[972]: ### Error querying database.
> Cause: com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications
> link failure
> Mar 04 19:29:52 server.example.com server[972]: The last packet sent
> successfully to the server was 0 milliseconds ago. The driver has not
> received any packets from the server.
> Mar 04 19:29:52 server.example.com server[972]: ### The error may exist in
> org/apache/guacamole/auth/jdbc/user/UserMapper.xml
> Mar 04 19:29:52 server.example.com server[972]: ### The error may involve
> org.apache.guacamole.auth.jdbc.user.UserMapper.selectOne
> Mar 04 19:29:52 server.example.com server[972]: ### The error occurred while
> executing a query
> Mar 04 19:29:52 server.example.com server[972]: ### Cause:
> com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link
> failure
> Mar 04 19:29:52 server.example.com server[972]: The last packet sent
> successfully to the server was 0 milliseconds ago. The driver has not
> received any packets from the server.
> {quote}
>
> The DB Server only phrases that that the connection has been closed by the
> client.
>
> Debug mode gave more information:
> {quote}{{Mar 5 12:06:45 server.example.com server[62724]: Caused by:
> javax.net.ssl.SSLHandshakeException: NotAfter: Sat Jan 13 17:21:58 CET 2024}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:360)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:303)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:298)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1357)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(CertificateMessage.java:1232)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(CertificateMessage.java:1175)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
>
[jira] [Closed] (GUACAMOLE-1928) Show better error description in logs on MySQL authentication failure
[
https://issues.apache.org/jira/browse/GUACAMOLE-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper closed GUACAMOLE-1928.
--
Resolution: Invalid
> Show better error description in logs on MySQL authentication failure
> -
>
> Key: GUACAMOLE-1928
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1928
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-auth-jdbc-mysql
> Environment: AlmaLinux 9, Tomcat 9.0.62-37.el9_3.1, guacd
> 1.5.4-1.el9, mariadb-java-client-3.3.3.jar, Extension: mysql, ldap
>Reporter: Stefan Bluhm
>Priority: Minor
>
> The information logging of the MySQL/MariaDB extention is not sufficient and
> should show more reasons of connection failures.
> Example: When the DB server has an expired SSL certificate, Guacamole only
> logs:
>
> {quote}Mar 04 19:29:52 server.example.com server[972]: 19:29:52.465
> [http-nio-8080-exec-10] WARN o.a.g.e.AuthenticationProviderFacade - The
> "mysql" authentication provider has encountered an internal error which will
> halt the authentication process. If this is unexpected or you are the
> developer of this authentication provider, you may wish to enable debug-level
> logging. If this is expected and you wish to ignore such failures in the
> future, please set "skip-if-unavailable: mysql" within your
> guacamole.properties.
> Mar 04 19:29:52 server.example.com server[972]: 19:29:52.468
> [http-nio-8080-exec-10] ERROR o.a.g.rest.RESTExceptionMapper - Unexpected
> internal error:
> Mar 04 19:29:52 server.example.com server[972]: ### Error querying database.
> Cause: com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications
> link failure
> Mar 04 19:29:52 server.example.com server[972]: The last packet sent
> successfully to the server was 0 milliseconds ago. The driver has not
> received any packets from the server.
> Mar 04 19:29:52 server.example.com server[972]: ### The error may exist in
> org/apache/guacamole/auth/jdbc/user/UserMapper.xml
> Mar 04 19:29:52 server.example.com server[972]: ### The error may involve
> org.apache.guacamole.auth.jdbc.user.UserMapper.selectOne
> Mar 04 19:29:52 server.example.com server[972]: ### The error occurred while
> executing a query
> Mar 04 19:29:52 server.example.com server[972]: ### Cause:
> com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link
> failure
> Mar 04 19:29:52 server.example.com server[972]: The last packet sent
> successfully to the server was 0 milliseconds ago. The driver has not
> received any packets from the server.
> {quote}
>
> The DB Server only phrases that that the connection has been closed by the
> client.
>
> Debug mode gave more information:
> {quote}{{Mar 5 12:06:45 server.example.com server[62724]: Caused by:
> javax.net.ssl.SSLHandshakeException: NotAfter: Sat Jan 13 17:21:58 CET 2024}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:360)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:303)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:298)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1357)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(CertificateMessage.java:1232)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(CertificateMessage.java:1175)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:443)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:183)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)}}
> {{Mar 5 12:06:45 server.example.com server[62724]: #011at
>
[jira] [Commented] (GUACAMOLE-1905) Update dependencies to latest stable and compatible versions
[
https://issues.apache.org/jira/browse/GUACAMOLE-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822243#comment-17822243
]
Mike Jumper commented on GUACAMOLE-1905:
[~vnick]: Yep! We have automatic scanning defined in the main {{pom.xml}} - you
just need to enable that part of the build. There are other things to check,
though. In all:
* Java dependencies (via Maven)
* JavaScript dependencies (via NPM)
* Docker image dependencies (these are mostly automatic, but the JDBC drivers
need to be manually updated when new compatible versions are available)
h3. Checking Maven dependencies
Set the {{checkDependencies}} property to {{true}} to enable automatic checks:
{code:none}
mvn -DcheckDependencies=true clean package
{code}
The build will then additionally:
# Check for dependencies that have new versions that are likely compatible
(excluding transitive and build-only dependencies), saving the results in the
{{target/}} directory of each project (including the top-level guacamole-client
project) as {{dependency-update-report.txt}}.
# Check for dependencies that have known security issues (_including_
transitive dependencies), saving the results in the {{target/}} directory of
each project (including the top-level guacamole-client project) as an HTML
report called {{dependency-check-report.html}}.
Both of these checks tend to produce false positives, so that's as far as the
automation goes, but it does help. I usually use {{find}} to locate and check
each of these.
h3. Checking JavaScript dependencies
For JavaScript libraries that are part of the webapp, you'll need to check
those separately by changing to the {{guacamole/src/main/frontend/}} directory
and running:
{code:none}
npm outdated
{code}
and:
{code:none}
npm audit
{code}
Many of these dependencies are build-time only. Others are not, but cannot be
updated without migrating to Webpack v5 (which the closure compiler plugin
doesn't support).
h3. Checking Docker dependencies
The _only_ dependencies that need checking within the Docker image are the JDBC
drivers, each defined with build args:
https://github.com/apache/guacamole-client/blob/4c24bfd18d7e5c5717c6c1fbf7b851083b2b17c8/Dockerfile#L53-L56
> Update dependencies to latest stable and compatible versions
>
>
> Key: GUACAMOLE-1905
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1905
> Project: Guacamole
> Issue Type: Task
>Reporter: Nick Couchman
>Priority: Minor
> Fix For: 1.5.5
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1920) When the cumulative number of user connections reaches a certain amount, guacd will report an error. "RDP server closed/refused connection: Security negotiation failed
[
https://issues.apache.org/jira/browse/GUACAMOLE-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper closed GUACAMOLE-1920.
--
Resolution: Fixed
> When the cumulative number of user connections reaches a certain amount,
> guacd will report an error. "RDP server closed/refused connection: Security
> negotiation failed (wrong security type?)”
> ---
>
> Key: GUACAMOLE-1920
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1920
> Project: Guacamole
> Issue Type: Bug
> Components: guacd
>Affects Versions: 1.5.4
>Reporter: CaoShulin
>Assignee: James Muehlner
>Priority: Minor
> Fix For: 1.5.5
>
>
> || Local host: | Windows host |
> || Remote host: | Windows host |
> || Guacamole version: | 1.5.4 |
> || Protocol: | rdp |
> When the cumulative number of user connections reaches a certain amount,
> guacd will report an error: "RDP server closed/refused connection: Security
> negotiation failed (wrong security type?)"
> {code:none}
> Feb 4 16:51:48 host-172-31-0-14 guacd[2038]: Creating new client for
> protocol "rdp"
> Feb 4 16:51:48 host-172-31-0-14 guacd[2038]: Connection ID is
> "$514ed1c3-2756-4d9f-8153-6388354873cc"
> Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Security mode: RDP
> Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Resize method: reconnect
> Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: No clipboard line-ending
> normalization specified. Defaulting to preserving the format of all line
> endings.
> Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: User
> "@5259dffd-eb02-42df-9b82-18de1b87457f" joined connection
> "$8ea080a2-1da5-4221-a828-823160906743" (1 users now present)
> Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Loading keymap "base"
> Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Loading keymap "en-us-qwerty"
> Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Security mode: RDP
> Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Resize method: reconnect
> Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: No clipboard line-ending
> normalization specified. Defaulting to preserving the format of all line
> endings.
> Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: User
> "@3814f8a9-f362-4b1e-9eb1-30fe6ed7c62b" joined connection
> "$514ed1c3-2756-4d9f-8153-6388354873cc" (1 users now present)
> Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Loading keymap "base"
> Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Loading keymap "en-us-qwerty"
> Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: RDP server closed/refused
> connection: Security negotiation failed (wrong security type?)
> {code}
> When you try to access again, an error occurs: "segfault at 20 ip
> 7ff86708f848 sp 7ff83affc9c0 error 4 in
> libdl-2.28.so[7ff86708f000+1000]"
> {code:none}
> Feb 4 11:16:51 host-172-31-0-14 guacd[2507120]: Creating new client for
> protocol "rdp"
> Feb 4 11:16:51 host-172-31-0-14 guacd[2507120]: Connection ID is
> "$35290a32-8188-4bbb-9d7d-5e181be83e25"
> Feb 4 11:16:51 host-172-31-0-14 audit[3804338]: ANOM_ABEND auid=0 uid=0
> gid=0 ses=8 pid=3804338 comm="guacd" exe="/usr/local/sbin/guacd" sig=11 res=1
> Feb 4 11:16:51 host-172-31-0-14 kernel: [143626.086546] guacd[3804338]:
> segfault at 85 ip 7f5a1d96a77d sp 7f5951f929c0 error 4 in
> libdl-2.28.so[7f5a1d96a000+1000]
> Feb 4 11:16:51 host-172-31-0-14 kernel: [143626.086550] Code: c3 0f 84 96 00
> 00 00 8b 53 04 48 8b 43 18 85 d2 0f 84 9d 00 00 00 48 85 c0 74 1f 48 8d 3d a2
> 08 00 00 b9 0e 00 00 00 48 89 c6 a6 0f 85 7b 01 00 00 48 c7 43 18 00 00
> 00 00 48 8b 04 24 e9 63
> Feb 4 11:16:51 host-172-31-0-14 guacd[2507120]: Connection
> "$35290a32-8188-4bbb-9d7d-5e181be83e25" removed.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1920) When the cumulative number of user connections reaches a certain amount, guacd will report an error. "RDP server closed/refused connection: Security negotiation fai
[
https://issues.apache.org/jira/browse/GUACAMOLE-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821022#comment-17821022
]
Mike Jumper commented on GUACAMOLE-1920:
[~aylin] - the fix has been merged to git. If you want to try making use of it
now, you can build from source and test.
{quote}
We hope to be able to use Guacamole version 1.5.4 soon.
{quote}
1.5.4 is a point in time - it's unchanging. The fix for this and any other
issue in 1.5.4 would be a future release. In this case, the fix is part of
upcoming 1.5.5. There is no specific timeline for 1.5.5 except that it is
nearing completion and expected soon.
> When the cumulative number of user connections reaches a certain amount,
> guacd will report an error. "RDP server closed/refused connection: Security
> negotiation failed (wrong security type?)”
> ---
>
> Key: GUACAMOLE-1920
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1920
> Project: Guacamole
> Issue Type: Bug
> Components: guacd
>Affects Versions: 1.5.4
>Reporter: CaoShulin
>Assignee: James Muehlner
>Priority: Minor
> Fix For: 1.5.5
>
>
> || Local host: | Windows host |
> || Remote host: | Windows host |
> || Guacamole version: | 1.5.4 |
> || Protocol: | rdp |
> When the cumulative number of user connections reaches a certain amount,
> guacd will report an error: "RDP server closed/refused connection: Security
> negotiation failed (wrong security type?)"
> {code:none}
> Feb 4 16:51:48 host-172-31-0-14 guacd[2038]: Creating new client for
> protocol "rdp"
> Feb 4 16:51:48 host-172-31-0-14 guacd[2038]: Connection ID is
> "$514ed1c3-2756-4d9f-8153-6388354873cc"
> Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Security mode: RDP
> Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Resize method: reconnect
> Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: No clipboard line-ending
> normalization specified. Defaulting to preserving the format of all line
> endings.
> Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: User
> "@5259dffd-eb02-42df-9b82-18de1b87457f" joined connection
> "$8ea080a2-1da5-4221-a828-823160906743" (1 users now present)
> Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Loading keymap "base"
> Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Loading keymap "en-us-qwerty"
> Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Security mode: RDP
> Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Resize method: reconnect
> Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: No clipboard line-ending
> normalization specified. Defaulting to preserving the format of all line
> endings.
> Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: User
> "@3814f8a9-f362-4b1e-9eb1-30fe6ed7c62b" joined connection
> "$514ed1c3-2756-4d9f-8153-6388354873cc" (1 users now present)
> Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Loading keymap "base"
> Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Loading keymap "en-us-qwerty"
> Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: RDP server closed/refused
> connection: Security negotiation failed (wrong security type?)
> {code}
> When you try to access again, an error occurs: "segfault at 20 ip
> 7ff86708f848 sp 7ff83affc9c0 error 4 in
> libdl-2.28.so[7ff86708f000+1000]"
> {code:none}
> Feb 4 11:16:51 host-172-31-0-14 guacd[2507120]: Creating new client for
> protocol "rdp"
> Feb 4 11:16:51 host-172-31-0-14 guacd[2507120]: Connection ID is
> "$35290a32-8188-4bbb-9d7d-5e181be83e25"
> Feb 4 11:16:51 host-172-31-0-14 audit[3804338]: ANOM_ABEND auid=0 uid=0
> gid=0 ses=8 pid=3804338 comm="guacd" exe="/usr/local/sbin/guacd" sig=11 res=1
> Feb 4 11:16:51 host-172-31-0-14 kernel: [143626.086546] guacd[3804338]:
> segfault at 85 ip 7f5a1d96a77d sp 7f5951f929c0 error 4 in
> libdl-2.28.so[7f5a1d96a000+1000]
> Feb 4 11:16:51 host-172-31-0-14 kernel: [143626.086550] Code: c3 0f 84 96 00
> 00 00 8b 53 04 48 8b 43 18 85 d2 0f 84 9d 00 00 00 48 85 c0 74 1f 48 8d 3d a2
> 08 00 00 b9 0e 00 00 00 48 89 c6 a6 0f 85 7b 01 00 00 48 c7 43 18 00 00
> 00 00 48 8b 04 24 e9 63
> Feb 4 11:16:51 host-172-31-0-14 guacd[2507120]: Connection
> "$35290a32-8188-4bbb-9d7d-5e181be83e25" removed.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1927) firefox chinese input
[
https://issues.apache.org/jira/browse/GUACAMOLE-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821018#comment-17821018
]
Mike Jumper commented on GUACAMOLE-1927:
{quote}
h3. firefox chinese input
use firefox to login win, enter two Chinese characters, finally enter four
Chinese characters
{quote}
I'm not sure what you're saying is happening vs. what you are expecting to
happen. Can you clarify?
Is the input method you're using _inside_ the remote desktop? Or is it on the
local computer (the computer accessing Guacamole with a browser)?
> firefox chinese input
> -
>
> Key: GUACAMOLE-1927
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1927
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole
> Environment: firefox
>Reporter: hanzhijun
>Priority: Major
> Attachments: chinese input.png
>
>
> use firefox to login win, enter two Chinese characters, finally enter four
> Chinese characters
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1864) Shared drive file transfer slow when RD gateway is in use
[ https://issues.apache.org/jira/browse/GUACAMOLE-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818980#comment-17818980 ] Mike Jumper commented on GUACAMOLE-1864: [~aresli]: No, there is no timeline. That JIRA issue would be: GUACAMOLE-1026 It's not known that the issue you are having is reproducible, nor whether it might be related to any other issue, including anything FreeRDP-specific. > Shared drive file transfer slow when RD gateway is in use > - > > Key: GUACAMOLE-1864 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1864 > Project: Guacamole > Issue Type: Bug > Components: guacamole >Affects Versions: 1.4.0 >Reporter: Ares >Priority: Minor > > Hi Team, > > A noticeable file transfer speed difference was captured from a project that > I have been working on via Guacamole. However, this is not happening while > using Microsoft RDP client on Windows or Mac. > > Specifically, when we transfer a 20mb file from a shared drive to a local > hard disk, the same server with RD Gateway took over 3mins whereas 20s > without the gateway. (Robocopy was used for benchmarking in this test.) > > It has been verified that the specs of the server is not the bottle neck and > we don't have additional security scanning going one during the test. > > > All the different security mode have been tested but none of them made a > difference. > > Please let me know if there are any settings or solutions that can help with > this. > > Thank you, > Ares -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1910) TLS sockets are not synchronized
[ https://issues.apache.org/jira/browse/GUACAMOLE-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper closed GUACAMOLE-1910. -- Fix Version/s: 1.5.5 Resolution: Fixed > TLS sockets are not synchronized > > > Key: GUACAMOLE-1910 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1910 > Project: Guacamole > Issue Type: Bug > Components: guacamole-server >Affects Versions: 1.5.4 >Reporter: Christopher Speck >Priority: Trivial > Fix For: 1.5.5 > > > Sockets created from socket-fd.c have lock and unlock handlers to synchronize > writing to the file descriptor. The sockets from socket-ssl.c do not have > similar handlers and results in mangled guacamole streams when there are > multiple connections. > > Adding a mutex in similar fashion to socket-fd resolves the concurrency > issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GUACAMOLE-1714) Update guacenc for FFmpeg 5.0 API
[
https://issues.apache.org/jira/browse/GUACAMOLE-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper reassigned GUACAMOLE-1714:
--
Assignee: (was: Mike Jumper)
> Update guacenc for FFmpeg 5.0 API
> -
>
> Key: GUACAMOLE-1714
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1714
> Project: Guacamole
> Issue Type: Task
> Components: guacenc
>Reporter: Mike Jumper
>Priority: Minor
> Fix For: 1.5.5, 1.6.0
>
>
> Recent versions of FFmpeg have switched to {{const}} arguments and return
> values for several functions, resulting in the following build failure:
> {code:none}
> ...
> CC guacenc-video.o
> video.c: In function 'guacenc_video_alloc':
> video.c:63:22: error: assignment discards 'const' qualifier from pointer
> target type [-Werror=discarded-qualifiers]
>63 | container_format = container_format_context->oformat;
> | ^
> video.c:66:22: error: initialization discards 'const' qualifier from pointer
> target type [-Werror=discarded-qualifiers]
>66 | AVCodec* codec = avcodec_find_encoder_by_name(codec_name);
> | ^~~~
> cc1: all warnings being treated as errors
> make[2]: *** [Makefile:1126: guacenc-video.o] Error 1
> {code}
> As suggested by [guacamole-server PR
> #379|https://github.com/apache/guacamole-server/pull/379/files], {{const}}
> should be added as necessary to satisfy the build.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (GUACAMOLE-1714) Update guacenc for FFmpeg 5.0 API
[
https://issues.apache.org/jira/browse/GUACAMOLE-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper reopened GUACAMOLE-1714:
> Update guacenc for FFmpeg 5.0 API
> -
>
> Key: GUACAMOLE-1714
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1714
> Project: Guacamole
> Issue Type: Task
> Components: guacenc
>Reporter: Mike Jumper
>Assignee: Mike Jumper
>Priority: Minor
> Fix For: 1.6.0
>
>
> Recent versions of FFmpeg have switched to {{const}} arguments and return
> values for several functions, resulting in the following build failure:
> {code:none}
> ...
> CC guacenc-video.o
> video.c: In function 'guacenc_video_alloc':
> video.c:63:22: error: assignment discards 'const' qualifier from pointer
> target type [-Werror=discarded-qualifiers]
>63 | container_format = container_format_context->oformat;
> | ^
> video.c:66:22: error: initialization discards 'const' qualifier from pointer
> target type [-Werror=discarded-qualifiers]
>66 | AVCodec* codec = avcodec_find_encoder_by_name(codec_name);
> | ^~~~
> cc1: all warnings being treated as errors
> make[2]: *** [Makefile:1126: guacenc-video.o] Error 1
> {code}
> As suggested by [guacamole-server PR
> #379|https://github.com/apache/guacamole-server/pull/379/files], {{const}}
> should be added as necessary to satisfy the build.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1714) Update guacenc for FFmpeg 5.0 API
[
https://issues.apache.org/jira/browse/GUACAMOLE-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817130#comment-17817130
]
Mike Jumper commented on GUACAMOLE-1714:
Absolutely.
> Update guacenc for FFmpeg 5.0 API
> -
>
> Key: GUACAMOLE-1714
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1714
> Project: Guacamole
> Issue Type: Task
> Components: guacenc
>Reporter: Mike Jumper
>Assignee: Mike Jumper
>Priority: Minor
> Fix For: 1.6.0
>
>
> Recent versions of FFmpeg have switched to {{const}} arguments and return
> values for several functions, resulting in the following build failure:
> {code:none}
> ...
> CC guacenc-video.o
> video.c: In function 'guacenc_video_alloc':
> video.c:63:22: error: assignment discards 'const' qualifier from pointer
> target type [-Werror=discarded-qualifiers]
>63 | container_format = container_format_context->oformat;
> | ^
> video.c:66:22: error: initialization discards 'const' qualifier from pointer
> target type [-Werror=discarded-qualifiers]
>66 | AVCodec* codec = avcodec_find_encoder_by_name(codec_name);
> | ^~~~
> cc1: all warnings being treated as errors
> make[2]: *** [Makefile:1126: guacenc-video.o] Error 1
> {code}
> As suggested by [guacamole-server PR
> #379|https://github.com/apache/guacamole-server/pull/379/files], {{const}}
> should be added as necessary to satisfy the build.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1714) Update guacenc for FFmpeg 5.0 API
[
https://issues.apache.org/jira/browse/GUACAMOLE-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper updated GUACAMOLE-1714:
---
Fix Version/s: 1.5.5
> Update guacenc for FFmpeg 5.0 API
> -
>
> Key: GUACAMOLE-1714
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1714
> Project: Guacamole
> Issue Type: Task
> Components: guacenc
>Reporter: Mike Jumper
>Assignee: Mike Jumper
>Priority: Minor
> Fix For: 1.5.5, 1.6.0
>
>
> Recent versions of FFmpeg have switched to {{const}} arguments and return
> values for several functions, resulting in the following build failure:
> {code:none}
> ...
> CC guacenc-video.o
> video.c: In function 'guacenc_video_alloc':
> video.c:63:22: error: assignment discards 'const' qualifier from pointer
> target type [-Werror=discarded-qualifiers]
>63 | container_format = container_format_context->oformat;
> | ^
> video.c:66:22: error: initialization discards 'const' qualifier from pointer
> target type [-Werror=discarded-qualifiers]
>66 | AVCodec* codec = avcodec_find_encoder_by_name(codec_name);
> | ^~~~
> cc1: all warnings being treated as errors
> make[2]: *** [Makefile:1126: guacenc-video.o] Error 1
> {code}
> As suggested by [guacamole-server PR
> #379|https://github.com/apache/guacamole-server/pull/379/files], {{const}}
> should be added as necessary to satisfy the build.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[
https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816477#comment-17816477
]
Mike Jumper commented on GUACAMOLE-1325:
{quote}
Maybe it's a good time to move to Tomcat 10 with Guacamole 2.0 ?
{quote}
I agree. This plus the migration away from AngularJS would be great choices for
2.0.
> Apache Tomcat 10.0 Servlet API incompatibility
> --
>
> Key: GUACAMOLE-1325
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1325
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole, guacamole-common, guacamole-ext
>Affects Versions: 1.3.0, 1.4.0
>Reporter: Mathias
>Priority: Minor
>
> Guacamole client 1.3.0 is not working with Apache Tomcat 10. Apache Tomcat
> 10.0.x requires a new Servlet 5.0 API. The Java package has changed from
> javax.servlet to jakarta.servlet.
> [Migrating from Tomcat 9.0 to 10.0|http://tomcat.apache.org/migration-10.html]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1920) When the cumulative number of user connections reaches a certain amount, guacd will report an error. "RDP server closed/refused connection: Security negotiation faile
[
https://issues.apache.org/jira/browse/GUACAMOLE-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper updated GUACAMOLE-1920:
---
Description:
|| Local host: | Windows host |
|| Remote host: | Windows host |
|| Guacamole version: | 1.5.4 |
|| Protocol: | rdp |
When the cumulative number of user connections reaches a certain amount, guacd
will report an error: "RDP server closed/refused connection: Security
negotiation failed (wrong security type?)"
{code:none}
Feb 4 16:51:48 host-172-31-0-14 guacd[2038]: Creating new client for protocol
"rdp"
Feb 4 16:51:48 host-172-31-0-14 guacd[2038]: Connection ID is
"$514ed1c3-2756-4d9f-8153-6388354873cc"
Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Security mode: RDP
Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Resize method: reconnect
Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: No clipboard line-ending
normalization specified. Defaulting to preserving the format of all line
endings.
Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: User
"@5259dffd-eb02-42df-9b82-18de1b87457f" joined connection
"$8ea080a2-1da5-4221-a828-823160906743" (1 users now present)
Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Loading keymap "base"
Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Loading keymap "en-us-qwerty"
Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Security mode: RDP
Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Resize method: reconnect
Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: No clipboard line-ending
normalization specified. Defaulting to preserving the format of all line
endings.
Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: User
"@3814f8a9-f362-4b1e-9eb1-30fe6ed7c62b" joined connection
"$514ed1c3-2756-4d9f-8153-6388354873cc" (1 users now present)
Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Loading keymap "base"
Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Loading keymap "en-us-qwerty"
Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: RDP server closed/refused
connection: Security negotiation failed (wrong security type?)
{code}
When you try to access again, an error occurs: "segfault at 20 ip
7ff86708f848 sp 7ff83affc9c0 error 4 in
libdl-2.28.so[7ff86708f000+1000]"
{code:none}
Feb 4 11:16:51 host-172-31-0-14 guacd[2507120]: Creating new client for
protocol "rdp"
Feb 4 11:16:51 host-172-31-0-14 guacd[2507120]: Connection ID is
"$35290a32-8188-4bbb-9d7d-5e181be83e25"
Feb 4 11:16:51 host-172-31-0-14 audit[3804338]: ANOM_ABEND auid=0 uid=0 gid=0
ses=8 pid=3804338 comm="guacd" exe="/usr/local/sbin/guacd" sig=11 res=1
Feb 4 11:16:51 host-172-31-0-14 kernel: [143626.086546] guacd[3804338]:
segfault at 85 ip 7f5a1d96a77d sp 7f5951f929c0 error 4 in
libdl-2.28.so[7f5a1d96a000+1000]
Feb 4 11:16:51 host-172-31-0-14 kernel: [143626.086550] Code: c3 0f 84 96 00
00 00 8b 53 04 48 8b 43 18 85 d2 0f 84 9d 00 00 00 48 85 c0 74 1f 48 8d 3d a2
08 00 00 b9 0e 00 00 00 48 89 c6 a6 0f 85 7b 01 00 00 48 c7 43 18 00 00 00
00 48 8b 04 24 e9 63
Feb 4 11:16:51 host-172-31-0-14 guacd[2507120]: Connection
"$35290a32-8188-4bbb-9d7d-5e181be83e25" removed.
{code}
was:
Local host: Windows host
Remote host: Windows host
guacamole version: 1.5.4
Protocol: rdp
When the cumulative number of user connections reaches a certain amount, guacd
will report an error. "RDP server closed/refused connection: Security
negotiation failed (wrong security type?)”
Feb 4 16:51:48 host-172-31-0-14 guacd[2038]: Creating new client for protocol
"rdp"
Feb 4 16:51:48 host-172-31-0-14 guacd[2038]: Connection ID is
"$514ed1c3-2756-4d9f-8153-6388354873cc"
Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Security mode: RDP
Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Resize method: reconnect
Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: No clipboard line-ending
normalization specified. Defaulting to preserving the format of all line
endings.
Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: User
"@5259dffd-eb02-42df-9b82-18de1b87457f" joined connection
"$8ea080a2-1da5-4221-a828-823160906743" (1 users now present)
Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Loading keymap "base"
Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Loading keymap "en-us-qwerty"
Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Security mode: RDP
Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Resize method: reconnect
Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: No clipboard line-ending
normalization specified. Defaulting to preserving the format of all line
endings.
Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: User
"@3814f8a9-f362-4b1e-9eb1-30fe6ed7c62b" joined connection
"$514ed1c3-2756-4d9f-8153-6388354873cc" (1 users now present)
Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Loading keymap "base"
Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Loading keymap "en-us-qwerty"
Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: RDP server closed/refused
connection:
[jira] [Updated] (GUACAMOLE-1920) When the cumulative number of user connections reaches a certain amount, guacd will report an error. "RDP server closed/refused connection: Security negotiation faile
[ https://issues.apache.org/jira/browse/GUACAMOLE-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper updated GUACAMOLE-1920: --- Fix Version/s: 1.5.5 > When the cumulative number of user connections reaches a certain amount, > guacd will report an error. "RDP server closed/refused connection: Security > negotiation failed (wrong security type?)” > --- > > Key: GUACAMOLE-1920 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1920 > Project: Guacamole > Issue Type: Bug > Components: guacd >Affects Versions: 1.5.4 >Reporter: CaoShulin >Assignee: James Muehlner >Priority: Minor > Fix For: 1.5.5 > > > Local host: Windows host > Remote host: Windows host > guacamole version: 1.5.4 > Protocol: rdp > When the cumulative number of user connections reaches a certain amount, > guacd will report an error. "RDP server closed/refused connection: Security > negotiation failed (wrong security type?)” > Feb 4 16:51:48 host-172-31-0-14 guacd[2038]: Creating new client for > protocol "rdp" > Feb 4 16:51:48 host-172-31-0-14 guacd[2038]: Connection ID is > "$514ed1c3-2756-4d9f-8153-6388354873cc" > Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Security mode: RDP > Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Resize method: reconnect > Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: No clipboard line-ending > normalization specified. Defaulting to preserving the format of all line > endings. > Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: User > "@5259dffd-eb02-42df-9b82-18de1b87457f" joined connection > "$8ea080a2-1da5-4221-a828-823160906743" (1 users now present) > Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Loading keymap "base" > Feb 4 16:51:48 host-172-31-0-14 guacd[991760]: Loading keymap "en-us-qwerty" > Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Security mode: RDP > Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Resize method: reconnect > Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: No clipboard line-ending > normalization specified. Defaulting to preserving the format of all line > endings. > Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: User > "@3814f8a9-f362-4b1e-9eb1-30fe6ed7c62b" joined connection > "$514ed1c3-2756-4d9f-8153-6388354873cc" (1 users now present) > Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Loading keymap "base" > Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: Loading keymap "en-us-qwerty" > Feb 4 16:51:48 host-172-31-0-14 guacd[991764]: RDP server closed/refused > connection: Security negotiation failed (wrong security type?) > > When you try to access again, an error occurs. "segfault at 20 ip > 7ff86708f848 sp 7ff83affc9c0 error 4 in > libdl-2.28.so[7ff86708f000+1000]" > Feb 4 11:16:51 host-172-31-0-14 guacd[2507120]: Creating new client for > protocol "rdp" > Feb 4 11:16:51 host-172-31-0-14 guacd[2507120]: Connection ID is > "$35290a32-8188-4bbb-9d7d-5e181be83e25" > Feb 4 11:16:51 host-172-31-0-14 audit[3804338]: ANOM_ABEND auid=0 uid=0 > gid=0 ses=8 pid=3804338 comm="guacd" exe="/usr/local/sbin/guacd" sig=11 res=1 > Feb 4 11:16:51 host-172-31-0-14 kernel: [143626.086546] guacd[3804338]: > segfault at 85 ip 7f5a1d96a77d sp 7f5951f929c0 error 4 in > libdl-2.28.so[7f5a1d96a000+1000] > Feb 4 11:16:51 host-172-31-0-14 kernel: [143626.086550] Code: c3 0f 84 96 00 > 00 00 8b 53 04 48 8b 43 18 85 d2 0f 84 9d 00 00 00 48 85 c0 74 1f 48 8d 3d a2 > 08 00 00 b9 0e 00 00 00 48 89 c6 a6 0f 85 7b 01 00 00 48 c7 43 18 00 00 > 00 00 48 8b 04 24 e9 63 > Feb 4 11:16:51 host-172-31-0-14 guacd[2507120]: Connection > "$35290a32-8188-4bbb-9d7d-5e181be83e25" removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1918) Multitouch attribute not correctly synced for guac_common_surface
[
https://issues.apache.org/jira/browse/GUACAMOLE-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper closed GUACAMOLE-1918.
--
Fix Version/s: 1.5.5
Resolution: Fixed
> Multitouch attribute not correctly synced for guac_common_surface
> -
>
> Key: GUACAMOLE-1918
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1918
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Reporter: Mike Jumper
>Assignee: Mike Jumper
>Priority: Minor
> Fix For: 1.5.5
>
>
> The {{guac_common_surface_dup()}} function currently contains the following
> code for syncing the multitouch support attribute for a layer:
> {code:none}
> /* Synchronize layer-specific properties if applicable */
> if (surface->layer->index > 0) {
> /* Synchronize opacity */
> guac_protocol_send_shade(socket, surface->layer, surface->opacity);
> /* Synchronize location and hierarchy */
> guac_protocol_send_move(socket, surface->layer,
> surface->parent, surface->x, surface->y, surface->z);
> /* Synchronize multi-touch support level */
> guac_protocol_send_set_int(surface->socket, surface->layer,
> GUAC_PROTOCOL_LAYER_PARAMETER_MULTI_TOUCH,
> surface->touches);
> }
> {code}
> This is incorrect because:
> * The multitouch attribute applies only to the default layer (layer 0), but
> this {{if}} ensures that's exactly the only layer this function _won't_ send
> that attribute for.
> * The wrong {{guac_socket}} is referenced (it should be sent to the socket
> supplied to the {{guac_common_surface_dup()}} call, not the surface's socket.
> Depending on timing of any call to {{guac_common_surface_set_multitouch()}},
> this can result in multitouch support not having any effect.
> Instead, the multitouch attribute should be sent for only the default layer
> and to the correct socket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1917) Updates to clipboard contents may be delayed due to lack of flush
[
https://issues.apache.org/jira/browse/GUACAMOLE-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper closed GUACAMOLE-1917.
--
Resolution: Fixed
> Updates to clipboard contents may be delayed due to lack of flush
> -
>
> Key: GUACAMOLE-1917
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1917
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Reporter: Mike Jumper
>Assignee: Mike Jumper
>Priority: Minor
> Fix For: 1.5.5
>
>
> All protocols currently implemented by {{guacamole-server}} rely on
> {{guac_common_clipboard}} to maintain and resend the contents of the remote
> clipboard, however the {{guac_common_clipboard_send()}} function lacks a call
> to {{guac_socket_flush()}} after the clipboard has been sent. Depending on
> the size of data copied, this can result in connected clients not actually
> receiving the changed clipboard data until something else happens to flush
> the socket, such as the end of a frame.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GUACAMOLE-1917) Updates to clipboard contents may be delayed due to lack of flush
[
https://issues.apache.org/jira/browse/GUACAMOLE-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper reassigned GUACAMOLE-1917:
--
Assignee: Mike Jumper
> Updates to clipboard contents may be delayed due to lack of flush
> -
>
> Key: GUACAMOLE-1917
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1917
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Reporter: Mike Jumper
>Assignee: Mike Jumper
>Priority: Minor
> Fix For: 1.5.5
>
>
> All protocols currently implemented by {{guacamole-server}} rely on
> {{guac_common_clipboard}} to maintain and resend the contents of the remote
> clipboard, however the {{guac_common_clipboard_send()}} function lacks a call
> to {{guac_socket_flush()}} after the clipboard has been sent. Depending on
> the size of data copied, this can result in connected clients not actually
> receiving the changed clipboard data until something else happens to flush
> the socket, such as the end of a frame.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GUACAMOLE-1918) Multitouch attribute not correctly synced for guac_common_surface
[
https://issues.apache.org/jira/browse/GUACAMOLE-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper reassigned GUACAMOLE-1918:
--
Assignee: Mike Jumper
> Multitouch attribute not correctly synced for guac_common_surface
> -
>
> Key: GUACAMOLE-1918
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1918
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Reporter: Mike Jumper
>Assignee: Mike Jumper
>Priority: Minor
>
> The {{guac_common_surface_dup()}} function currently contains the following
> code for syncing the multitouch support attribute for a layer:
> {code:none}
> /* Synchronize layer-specific properties if applicable */
> if (surface->layer->index > 0) {
> /* Synchronize opacity */
> guac_protocol_send_shade(socket, surface->layer, surface->opacity);
> /* Synchronize location and hierarchy */
> guac_protocol_send_move(socket, surface->layer,
> surface->parent, surface->x, surface->y, surface->z);
> /* Synchronize multi-touch support level */
> guac_protocol_send_set_int(surface->socket, surface->layer,
> GUAC_PROTOCOL_LAYER_PARAMETER_MULTI_TOUCH,
> surface->touches);
> }
> {code}
> This is incorrect because:
> * The multitouch attribute applies only to the default layer (layer 0), but
> this {{if}} ensures that's exactly the only layer this function _won't_ send
> that attribute for.
> * The wrong {{guac_socket}} is referenced (it should be sent to the socket
> supplied to the {{guac_common_surface_dup()}} call, not the surface's socket.
> Depending on timing of any call to {{guac_common_surface_set_multitouch()}},
> this can result in multitouch support not having any effect.
> Instead, the multitouch attribute should be sent for only the default layer
> and to the correct socket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1917) Updates to clipboard contents may be delayed due to lack of flush
[
https://issues.apache.org/jira/browse/GUACAMOLE-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper updated GUACAMOLE-1917:
---
Fix Version/s: 1.5.5
> Updates to clipboard contents may be delayed due to lack of flush
> -
>
> Key: GUACAMOLE-1917
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1917
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Reporter: Mike Jumper
>Priority: Minor
> Fix For: 1.5.5
>
>
> All protocols currently implemented by {{guacamole-server}} rely on
> {{guac_common_clipboard}} to maintain and resend the contents of the remote
> clipboard, however the {{guac_common_clipboard_send()}} function lacks a call
> to {{guac_socket_flush()}} after the clipboard has been sent. Depending on
> the size of data copied, this can result in connected clients not actually
> receiving the changed clipboard data until something else happens to flush
> the socket, such as the end of a frame.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GUACAMOLE-1918) Multitouch attribute not correctly synced for guac_common_surface
Mike Jumper created GUACAMOLE-1918:
--
Summary: Multitouch attribute not correctly synced for
guac_common_surface
Key: GUACAMOLE-1918
URL: https://issues.apache.org/jira/browse/GUACAMOLE-1918
Project: Guacamole
Issue Type: Bug
Reporter: Mike Jumper
The {{guac_common_surface_dup()}} function currently contains the following
code for syncing the multitouch support attribute for a layer:
{code:none}
/* Synchronize layer-specific properties if applicable */
if (surface->layer->index > 0) {
/* Synchronize opacity */
guac_protocol_send_shade(socket, surface->layer, surface->opacity);
/* Synchronize location and hierarchy */
guac_protocol_send_move(socket, surface->layer,
surface->parent, surface->x, surface->y, surface->z);
/* Synchronize multi-touch support level */
guac_protocol_send_set_int(surface->socket, surface->layer,
GUAC_PROTOCOL_LAYER_PARAMETER_MULTI_TOUCH,
surface->touches);
}
{code}
This is incorrect because:
* The multitouch attribute applies only to the default layer (layer 0), but
this {{if}} ensures that's exactly the only layer this function _won't_ send
that attribute for.
* The wrong {{guac_socket}} is referenced (it should be sent to the socket
supplied to the {{guac_common_surface_dup()}} call, not the surface's socket.
Depending on timing of any call to {{guac_common_surface_set_multitouch()}},
this can result in multitouch support not having any effect.
Instead, the multitouch attribute should be sent for only the default layer and
to the correct socket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1918) Multitouch attribute not correctly synced for guac_common_surface
[
https://issues.apache.org/jira/browse/GUACAMOLE-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper updated GUACAMOLE-1918:
---
Component/s: guacamole-server
> Multitouch attribute not correctly synced for guac_common_surface
> -
>
> Key: GUACAMOLE-1918
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1918
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Reporter: Mike Jumper
>Priority: Minor
>
> The {{guac_common_surface_dup()}} function currently contains the following
> code for syncing the multitouch support attribute for a layer:
> {code:none}
> /* Synchronize layer-specific properties if applicable */
> if (surface->layer->index > 0) {
> /* Synchronize opacity */
> guac_protocol_send_shade(socket, surface->layer, surface->opacity);
> /* Synchronize location and hierarchy */
> guac_protocol_send_move(socket, surface->layer,
> surface->parent, surface->x, surface->y, surface->z);
> /* Synchronize multi-touch support level */
> guac_protocol_send_set_int(surface->socket, surface->layer,
> GUAC_PROTOCOL_LAYER_PARAMETER_MULTI_TOUCH,
> surface->touches);
> }
> {code}
> This is incorrect because:
> * The multitouch attribute applies only to the default layer (layer 0), but
> this {{if}} ensures that's exactly the only layer this function _won't_ send
> that attribute for.
> * The wrong {{guac_socket}} is referenced (it should be sent to the socket
> supplied to the {{guac_common_surface_dup()}} call, not the surface's socket.
> Depending on timing of any call to {{guac_common_surface_set_multitouch()}},
> this can result in multitouch support not having any effect.
> Instead, the multitouch attribute should be sent for only the default layer
> and to the correct socket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1917) Updates to clipboard contents may be delayed due to lack of flush
[
https://issues.apache.org/jira/browse/GUACAMOLE-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper updated GUACAMOLE-1917:
---
Component/s: guacamole-server
> Updates to clipboard contents may be delayed due to lack of flush
> -
>
> Key: GUACAMOLE-1917
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1917
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Reporter: Mike Jumper
>Priority: Minor
>
> All protocols currently implemented by {{guacamole-server}} rely on
> {{guac_common_clipboard}} to maintain and resend the contents of the remote
> clipboard, however the {{guac_common_clipboard_send()}} function lacks a call
> to {{guac_socket_flush()}} after the clipboard has been sent. Depending on
> the size of data copied, this can result in connected clients not actually
> receiving the changed clipboard data until something else happens to flush
> the socket, such as the end of a frame.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GUACAMOLE-1917) Updates to clipboard contents may be delayed due to lack of flush
Mike Jumper created GUACAMOLE-1917:
--
Summary: Updates to clipboard contents may be delayed due to lack
of flush
Key: GUACAMOLE-1917
URL: https://issues.apache.org/jira/browse/GUACAMOLE-1917
Project: Guacamole
Issue Type: Bug
Reporter: Mike Jumper
All protocols currently implemented by {{guacamole-server}} rely on
{{guac_common_clipboard}} to maintain and resend the contents of the remote
clipboard, however the {{guac_common_clipboard_send()}} function lacks a call
to {{guac_socket_flush()}} after the clipboard has been sent. Depending on the
size of data copied, this can result in connected clients not actually
receiving the changed clipboard data until something else happens to flush the
socket, such as the end of a frame.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1916) Provide notification, jump-to-top of page for a clone operation
[ https://issues.apache.org/jira/browse/GUACAMOLE-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812842#comment-17812842 ] Mike Jumper commented on GUACAMOLE-1916: Yes, I agree jumping back up to the top would be an improvement in UX. > Provide notification, jump-to-top of page for a clone operation > --- > > Key: GUACAMOLE-1916 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1916 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Affects Versions: 1.5.4 >Reporter: sbcbus >Priority: Trivial > > Minor thing, but think it would be more user friendly to know if a "clone" of > an object was successful before editing the fields if perhaps a notification > "toast" could say something like "clone successful" and jump to the top of > the page. At least on my systems using Chrome, clicking clone changes the URL > but otherwise doesn't change anything else so it can be a bit confusing > without checking. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1916) Provide notification, jump-to-top of page for a clone operation
[ https://issues.apache.org/jira/browse/GUACAMOLE-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17812507#comment-17812507 ] Mike Jumper commented on GUACAMOLE-1916: FYI: There is no operation to verify as successful/failed after you click "Clone". All clicking "Clone" actually does is prepopulate the fields for a new object with values from an existing object. Nothing is touched as a result of clicking "Clone" until you finish making any changes and click "Save". > Provide notification, jump-to-top of page for a clone operation > --- > > Key: GUACAMOLE-1916 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1916 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Affects Versions: 1.5.4 >Reporter: sbcbus >Priority: Trivial > > Minor thing, but think it would be more user friendly to know if a "clone" of > an object was successful before editing the fields if perhaps a notification > "toast" could say something like "clone successful" and jump to the top of > the page. At least on my systems using Chrome, clicking clone changes the URL > but otherwise doesn't change anything else so it can be a bit confusing > without checking. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1914) attempt to ssh to macos sonoma m1 (arm64) , SSH handshake failed
[
https://issues.apache.org/jira/browse/GUACAMOLE-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper closed GUACAMOLE-1914.
--
Resolution: Invalid
We can't investigate issues with a third-party Docker image under the
assumption that the issue is due to a bug in Guacamole. If you suspect this is
a bug in Guacamole, not just in the third-party image, please reproduce the
issue with the standard images we provide ({{guacamole/guacamole}} and
{{guacamole/guacd}}).
> attempt to ssh to macos sonoma m1 (arm64) , SSH handshake failed
>
>
> Key: GUACAMOLE-1914
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1914
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-docker, guacd-docker, SSH
>Affects Versions: 1.5.4
> Environment: mac m1, os sonoma 14.0
>Reporter: sam detweiler
>Priority: Blocker
> Labels: arm64, macOS, ssh
>
> using docker container built from here
> [https://github.com/jwetzell/docker-guacamole,] adding ping and ssh client.
> on arm64
> the container uses libssh2 which fixed a similar problem last year with
> AES-GCM, but it is using the libssh2 with the fix (1.11.0)
>
> when I use guac I get
> h1. SSH handshake failed
>
> the docker container is running on the host target of the ssh
> manual ssh from the container to the host works.
>
> I didn't see any similar issues open or closed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GUACAMOLE-1901) RDP keyboard layout in Hebrew
[
https://issues.apache.org/jira/browse/GUACAMOLE-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804423#comment-17804423
]
Mike Jumper edited comment on GUACAMOLE-1901 at 1/8/24 6:51 PM:
I don't think we have a document covering the keyboard layout file format.
[~daniel_azulay9], please take a look at an established keymap and let us know
if you have any specific questions. The mapping files are each essentially
easier-to-maintain shorthand describing which Windows scancodes are equivalent
to which X11 keysyms, with optional modifier states if a keysym is equivalent
to a certain scancode only when certain modifiers are held/released.
For example, [the following excerpt from
de_de_qwertz.keymap|https://github.com/apache/guacamole-server/blob/94a755c90a7511969884774dbca2ef2ab5958ba6/src/protocols/rdp/keymaps/de_de_qwertz.keymap#L35]:
{code:none}
map -caps -altgr +shift 0x1E..0x28 0x2B ~ "ASDFGHJKLÖÄ'"
{code}
means "the scancodes 0x1E through 0x28 inclusive, and the scancode 0x2B, map
respectively to the X11 keysyms for the characters in the string 'ASDFGHJKLÖÄ',
so long as Caps Lock is not enabled, AltGr is released, and Shift is held".
Another example:
{code:none}
map +altgr -shift 0x09 ~ "["
{code}
Means "the scancode 0x09 maps to the X11 keysym for the character '[', so long
as AltGr is held and Shift is released".
For cases where the X11 keysym does not correspond to a character, you can
specify it numerically. For example, [from the base
keymap|https://github.com/apache/guacamole-server/blob/94a755c90a7511969884774dbca2ef2ab5958ba6/src/protocols/rdp/keymaps/base.keymap#L80-L82]:
{code:none}
# Modifiers
map 0x2A ~ 0xffe1 # Shift_L
map 0x36 ~ 0xffe2 # Shift_R
{code}
The important thing is that the full context of each scancode is spelled out,
so that Guacamole can accurately translate between whatever keyboard layout the
user is using locally and the keyboard layout of the server. Guacamole will
automatically set/clear modifiers within the RDP session to ensure that the
identity of keys is maintained, but can't do this if it doesn't know which
modifiers impact the identity if each key in the layout.
was (Author: mike.jumper):
I don't think we have a document covering the keyboard layout file format.
[~daniel_azulay9], please take a look at an established keymap and let us know
if you have any specific questions. The mapping files are each essentially
easier-to-maintain shorthand describing which Windows scancodes are equivalent
to which X11 keysyms, with optional modifier states if a keysym is equivalent
to a certain scancode only when certain modifiers are held/released.
For example, [the following excerpt from
de_de_qwertz.keymap|https://github.com/apache/guacamole-server/blob/94a755c90a7511969884774dbca2ef2ab5958ba6/src/protocols/rdp/keymaps/de_de_qwertz.keymap#L35]:
{code:none}
map -caps -altgr +shift 0x1E..0x28 0x2B ~ "ASDFGHJKLÖÄ'"
{code}
Means "the scancodes 0x1E through 0x28 inclusive, and the scancode 0x2B, map
respectively to the X11 keysyms for the characters in the string 'ASDFGHJKLÖÄ',
so long as Caps Lock is not enabled, AltGr is released, and Shift is held".
Another example:
{code:none}
map +altgr -shift 0x09 ~ "["
{code}
Means "the scancode 0x09 maps to the X11 keysym for the character '[', so long
as AltGr is held and Shift is released".
For cases where the X11 keysym does not correspond to a character, you can
specify it numerically. For example, [from the base
keymap|https://github.com/apache/guacamole-server/blob/94a755c90a7511969884774dbca2ef2ab5958ba6/src/protocols/rdp/keymaps/base.keymap#L80-L82]:
{code:none}
# Modifiers
map 0x2A ~ 0xffe1 # Shift_L
map 0x36 ~ 0xffe2 # Shift_R
{code}
The important thing is that the full context of each scancode is spelled out,
so that Guacamole can accurately translate between whatever keyboard layout the
user is using locally and the keyboard layout of the server. Guacamole will
automatically set/clear modifiers within the RDP session to ensure that the
identity of keys is maintained, but can't do this if it doesn't know which
modifiers impact the identity if each key in the layout.
> RDP keyboard layout in Hebrew
> -
>
> Key: GUACAMOLE-1901
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1901
> Project: Guacamole
> Issue Type: Improvement
> Components: RDP
>Reporter: Daniel Azulay
>Priority: Minor
> Attachments: Screen Recording 2024-01-08 at 12.05.48 PM.mov
>
>
> Hello,
> I'm using both the guac client & server for RDP usage.
> When my keyboard layout is set to `en-us-qwerty` on the RDP, and I switch to
> a Hebrew keyboard and press ",", I get a different char "ת" (Hebrew letter).
>
> Any idea if it's by design? is it a bug?
> is
[jira] [Commented] (GUACAMOLE-1901) RDP keyboard layout in Hebrew
[
https://issues.apache.org/jira/browse/GUACAMOLE-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804423#comment-17804423
]
Mike Jumper commented on GUACAMOLE-1901:
I don't think we have a document covering the keyboard layout file format.
[~daniel_azulay9], please take a look at an established keymap and let us know
if you have any specific questions. The mapping files are each essentially
easier-to-maintain shorthand describing which Windows scancodes are equivalent
to which X11 keysyms, with optional modifier states if a keysym is equivalent
to a certain scancode only when certain modifiers are held/released.
For example, [the following excerpt from
de_de_qwertz.keymap|https://github.com/apache/guacamole-server/blob/94a755c90a7511969884774dbca2ef2ab5958ba6/src/protocols/rdp/keymaps/de_de_qwertz.keymap#L35]:
{code:none}
map -caps -altgr +shift 0x1E..0x28 0x2B ~ "ASDFGHJKLÖÄ'"
{code}
Means "the scancodes 0x1E through 0x28 inclusive, and the scancode 0x2B, map
respectively to the X11 keysyms for the characters in the string 'ASDFGHJKLÖÄ',
so long as Caps Lock is not enabled, AltGr is released, and Shift is held".
Another example:
{code:none}
map +altgr -shift 0x09 ~ "["
{code}
Means "the scancode 0x09 maps to the X11 keysym for the character '[', so long
as AltGr is held and Shift is released".
For cases where the X11 keysym does not correspond to a character, you can
specify it numerically. For example, [from the base
keymap|https://github.com/apache/guacamole-server/blob/94a755c90a7511969884774dbca2ef2ab5958ba6/src/protocols/rdp/keymaps/base.keymap#L80-L82]:
{code:none}
# Modifiers
map 0x2A ~ 0xffe1 # Shift_L
map 0x36 ~ 0xffe2 # Shift_R
{code}
The important thing is that the full context of each scancode is spelled out,
so that Guacamole can accurately translate between whatever keyboard layout the
user is using locally and the keyboard layout of the server. Guacamole will
automatically set/clear modifiers within the RDP session to ensure that the
identity of keys is maintained, but can't do this if it doesn't know which
modifiers impact the identity if each key in the layout.
> RDP keyboard layout in Hebrew
> -
>
> Key: GUACAMOLE-1901
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1901
> Project: Guacamole
> Issue Type: Improvement
> Components: RDP
>Reporter: Daniel Azulay
>Priority: Minor
> Attachments: Screen Recording 2024-01-08 at 12.05.48 PM.mov
>
>
> Hello,
> I'm using both the guac client & server for RDP usage.
> When my keyboard layout is set to `en-us-qwerty` on the RDP, and I switch to
> a Hebrew keyboard and press ",", I get a different char "ת" (Hebrew letter).
>
> Any idea if it's by design? is it a bug?
> is it because the Hebrew keyboard layout is not supported?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1847) Improve Mobile Touch and Mouse Functionality
[
https://issues.apache.org/jira/browse/GUACAMOLE-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802277#comment-17802277
]
Mike Jumper commented on GUACAMOLE-1847:
{quote}
What would help with the zoom feature is not having the window fit to the
browser each time. I find myself always having to zoom in slightly when logging
in from a mobile device. Perhaps having a static setting on a per connection
basis or even global basis for a zoom percent? I’m not sure what the best would
be.
{quote}
IMHO, changing the fit-to-screen behavior such that it instead zooms only as
necessary to cover the available area would be best (at least when on a mobile
device in an orientation that differs from the remote display). For example, if
using a mobile device in portait mode, this would mean that traditional
landscape displays would fill the screen vertically, and you would scroll
around horizontally to see the rest of the display.
> Improve Mobile Touch and Mouse Functionality
>
>
> Key: GUACAMOLE-1847
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1847
> Project: Guacamole
> Issue Type: Improvement
>Affects Versions: 1.5.4
> Environment: FreeBSD 13 with the guacamole-client and
> guacamole-server ports
>Reporter: Victor Tschetter
>Priority: Minor
> Labels: mouse
>
> There are 2 issues I am facing with mobile usability that I would like to
> bring to attention.
>
> # Can a zoom function be implemented when using mouse mode?
> # Can the touch sensitivity be adjusted when using touch mode?
> # Can a scroll function be added for mobile?
> Double-clicking is hard to accomplish on mobile unless zoomed in so the touch
> registers on the same location. If number 2 could work properly, the number 1
> wouldn't be as important.
> Something along the lines of the RealVNC app would be what I am looking for.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1847) Improve Mobile Touch and Mouse Functionality
[
https://issues.apache.org/jira/browse/GUACAMOLE-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802272#comment-17802272
]
Mike Jumper commented on GUACAMOLE-1847:
{quote}
Scroll while in absolute mode.
{quote}
I'm not sure that's possible without conflicting with the zoom gesture.
{quote}
Zoom without having to enter the menu while in mouse mode (less important)
{quote}
I don't think this would make sense - the interface for this exists in the menu
specifically to avoid UI elements intruding on the display or taking control of
mouse/keyboard shortcuts that should be passed through to the remote desktop.
{quote}
Double click properly in absolute mode.
{quote}
So you're looking for the touch support to ignore differences in tap locations
so long as they're in quick succession and relatively close to each other?
> Improve Mobile Touch and Mouse Functionality
>
>
> Key: GUACAMOLE-1847
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1847
> Project: Guacamole
> Issue Type: Improvement
>Affects Versions: 1.5.4
> Environment: FreeBSD 13 with the guacamole-client and
> guacamole-server ports
>Reporter: Victor Tschetter
>Priority: Minor
> Labels: mouse
>
> There are 2 issues I am facing with mobile usability that I would like to
> bring to attention.
>
> # Can a zoom function be implemented when using mouse mode?
> # Can the touch sensitivity be adjusted when using touch mode?
> # Can a scroll function be added for mobile?
> Double-clicking is hard to accomplish on mobile unless zoomed in so the touch
> registers on the same location. If number 2 could work properly, the number 1
> wouldn't be as important.
> Something along the lines of the RealVNC app would be what I am looking for.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1847) Improve Mobile Touch and Mouse Functionality
[
https://issues.apache.org/jira/browse/GUACAMOLE-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17802263#comment-17802263
]
Mike Jumper commented on GUACAMOLE-1847:
{quote}
1. Can a zoom function be implemented when using mouse mode?
...
3. Can a scroll function be added for mobile?
{quote}
Both of these have been supported for years:
* You can zoom in using the zoom controls in the Guacamole menu. These controls
are available regardless of whether you are using a touch device. If you are
using a touch device and the absolute (touchscreen) mouse emulation mode, you
can additionally zoom in/out with pinch gestures.
* You can scroll on touch devices by using the relative (touchpad) mouse
emulation mode and dragging three fingers up or down. The three-finger drag
gesture maps to the emulated mouse scroll wheel.
{quote}
2. Can the touch sensitivity be adjusted when using touch mode?
{quote}
What sensitivity are you referring to specifically?
> Improve Mobile Touch and Mouse Functionality
>
>
> Key: GUACAMOLE-1847
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1847
> Project: Guacamole
> Issue Type: Improvement
>Affects Versions: 1.5.4
> Environment: FreeBSD 13 with the guacamole-client and
> guacamole-server ports
>Reporter: Victor Tschetter
>Priority: Minor
> Labels: mouse
>
> There are 2 issues I am facing with mobile usability that I would like to
> bring to attention.
>
> # Can a zoom function be implemented when using mouse mode?
> # Can the touch sensitivity be adjusted when using touch mode?
> # Can a scroll function be added for mobile?
> Double-clicking is hard to accomplish on mobile unless zoomed in so the touch
> registers on the same location. If number 2 could work properly, the number 1
> wouldn't be as important.
> Something along the lines of the RealVNC app would be what I am looking for.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1897) Error javadoc on compile guacamole client
[
https://issues.apache.org/jira/browse/GUACAMOLE-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper closed GUACAMOLE-1897.
--
Resolution: Invalid
> Error javadoc on compile guacamole client
> -
>
> Key: GUACAMOLE-1897
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1897
> Project: Guacamole
> Issue Type: Bug
>Affects Versions: 1.5.4
>Reporter: Pascal
>Priority: Major
>
> Hi
> When I try to compile guacamole-client 1.5.4 on Debian 12.4, I have the
> following issue :
> {*}ERROR{*}] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.2.0:jar (attach-javadocs) on
> project guacamole-common: *MavenReportException: Error while generating
> Javadoc: Unable to find javadoc command: The environment variable JAVA_HOME
> is not correctly set*
> My jdk version :
> Package: openjdk-17-jdk
> Version: 17.0.9+9-1~deb12u1
> Regards
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1897) Error javadoc on compile guacamole client
[
https://issues.apache.org/jira/browse/GUACAMOLE-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799593#comment-17799593
]
Mike Jumper commented on GUACAMOLE-1897:
[~piris], again this is not a bug and has nothing to do with Guacamole itself.
You simply do not have a properly-configured Java build environment. As noted
by Maven in the error message:
{quote}
The environment variable JAVA_HOME is not correctly set
{quote}
You need to correctly set {{JAVA_HOME}}.
If you have further questions on this, please don't use the bug tracker as a
means of requesting help with build issues. That is what the
u...@guacamole.apache.org mailing list is for:
https://guacamole.apache.org/support/#mailing-lists
You will need to subscribe to the list before you can post.
> Error javadoc on compile guacamole client
> -
>
> Key: GUACAMOLE-1897
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1897
> Project: Guacamole
> Issue Type: Bug
>Affects Versions: 1.5.4
>Reporter: Pascal
>Priority: Major
>
> Hi
> When I try to compile guacamole-client 1.5.4 on Debian 12.4, I have the
> following issue :
> {*}ERROR{*}] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.2.0:jar (attach-javadocs) on
> project guacamole-common: *MavenReportException: Error while generating
> Javadoc: Unable to find javadoc command: The environment variable JAVA_HOME
> is not correctly set*
> My jdk version :
> Package: openjdk-17-jdk
> Version: 17.0.9+9-1~deb12u1
> Regards
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1895) Compile guacamole client
[
https://issues.apache.org/jira/browse/GUACAMOLE-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799133#comment-17799133
]
Mike Jumper commented on GUACAMOLE-1895:
We have CI builds that verify this, but I've retried manually and can confirm
that the build definitely succeeds, including on Debian 12. If you're still
having trouble, please subscribe and post to the u...@guacamole.apache.org
mailing list, and folks can assist:
http://guacamole.apache.org/support/#mailing-lists
My guess is you just don't have the JDK installed (ie: you have {{java}} but no
{{javac}}).
> Compile guacamole client
>
>
> Key: GUACAMOLE-1895
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1895
> Project: Guacamole
> Issue Type: Bug
>Affects Versions: 1.5.4
>Reporter: Pascal
>Priority: Major
>
> Hi
> My config :
> Debian 12.4
> tomcat10 (can not install tomcat9)
> The guacamole-client 1.5.4 compiled do not work with tomcat10
>
> I downloaded the no compiled guacamole-client 1.5.4 and try to compile it :
> mvn package
>
> Issue :
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project guacamole-common: Compilation failure -> [Help 1]
>
> My java version :
> openjdk version "17.0.9" 2023-10-17
> OpenJDK Runtime Environment (build 17.0.9+9-Debian-1deb12u1)
> OpenJDK 64-Bit Server VM (build 17.0.9+9-Debian-1deb12u1, mixed mode, sharing)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1895) Compile guacamole client
[ https://issues.apache.org/jira/browse/GUACAMOLE-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper closed GUACAMOLE-1895. -- Resolution: Invalid > Compile guacamole client > > > Key: GUACAMOLE-1895 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1895 > Project: Guacamole > Issue Type: Bug >Affects Versions: 1.5.4 >Reporter: Pascal >Priority: Major > > Hi > My config : > Debian 12.4 > tomcat10 (can not install tomcat9) > The guacamole-client 1.5.4 compiled do not work with tomcat10 > > I downloaded the no compiled guacamole-client 1.5.4 and try to compile it : > mvn package > > Issue : > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile > (default-compile) on project guacamole-common: Compilation failure -> [Help 1] > > My java version : > openjdk version "17.0.9" 2023-10-17 > OpenJDK Runtime Environment (build 17.0.9+9-Debian-1deb12u1) > OpenJDK 64-Bit Server VM (build 17.0.9+9-Debian-1deb12u1, mixed mode, sharing) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1894) Alpine 3.19 Removed OpenSSL 1.1
[
https://issues.apache.org/jira/browse/GUACAMOLE-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper closed GUACAMOLE-1894.
--
Resolution: Duplicate
> Alpine 3.19 Removed OpenSSL 1.1
> ---
>
> Key: GUACAMOLE-1894
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1894
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Affects Versions: 1.5.4
>Reporter: Jason Bean
>Priority: Major
>
> I'm trying to build my all-in-one container for Guacamole 1.5.4. I'm getting
> the error from apk when I try to install the dependencies from the pre-built
> guacamole-server container:
> {code:java}
> 1.318 ERROR: unable to select packages:
> 1.318 libcrypto1.1 (no such package):
> 1.318 required by: world[libcrypto1.1]
> 1.318 libssl1.1 (no such package):
> 1.318 required by: world[libssl1.1] {code}
> If I change the alpine tag from "latest" to "3.18.5" it builds correctly.
> I've verified on the Alpine Packages site that the OpenSSL 1.1 packages are
> no longer available for Alpine 3.19.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1893) Selecting a connection from the all connections list produces 'paste' pop-up in Safari
[
https://issues.apache.org/jira/browse/GUACAMOLE-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796960#comment-17796960
]
Mike Jumper commented on GUACAMOLE-1893:
No, there are no options controlling whether the webapp attempts to read the
local clipboard. The {{disable-copy}} and {{disable-paste}} parameters only
affect whether the remote clipboard can be read/written respectively.
> Selecting a connection from the all connections list produces 'paste' pop-up
> in Safari
> --
>
> Key: GUACAMOLE-1893
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1893
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole
> Environment: Safari 17.1.2 on MacOS 14.1.2
>Reporter: Stephen Young
>Priority: Minor
> Attachments: Screenshot 2023-12-14 at 14.58.28.png, Screenshot
> 2023-12-14 at 14.59.14.png
>
>
> When selecting a connection from the 'ALL CONNECTIONS' list, a 'paste' pop-up
> appears and halts the connection. If the paste pop-up is clicked, the
> connection is successful.
> When connected, opening the guacamole clipboard/display/etc menu also has the
> same issue with a 'paste' pop-up halting the slide out until the pop-up is
> clicked.
> Screenshots attached.
> Tested with RDP, VNC and SSH connections with same result.
> Browser is Safari 17.1.2
> MacOS 14.1.2
> Apple M2
> Works as expected in Chrome, Firefox and Edge in MacOS
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1893) Selecting a connection from the all connections list produces 'paste' pop-up in Safari
[ https://issues.apache.org/jira/browse/GUACAMOLE-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17796947#comment-17796947 ] Mike Jumper commented on GUACAMOLE-1893: This sounds like it may be a bug in Safari. Guacamole automatically attempts to read from the local clipboard to synchronize local/remote clipboard contents, but the browser shouldn't be showing a popup that blocks page execution, let alone one with just the word "Paste" and no context. > Selecting a connection from the all connections list produces 'paste' pop-up > in Safari > -- > > Key: GUACAMOLE-1893 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1893 > Project: Guacamole > Issue Type: Bug > Components: guacamole > Environment: Safari 17.1.2 on MacOS 14.1.2 >Reporter: Stephen Young >Priority: Minor > Attachments: Screenshot 2023-12-14 at 14.58.28.png, Screenshot > 2023-12-14 at 14.59.14.png > > > When selecting a connection from the 'ALL CONNECTIONS' list, a 'paste' pop-up > appears and halts the connection. If the paste pop-up is clicked, the > connection is successful. > When connected, opening the guacamole clipboard/display/etc menu also has the > same issue with a 'paste' pop-up halting the slide out until the pop-up is > clicked. > Screenshots attached. > Tested with RDP, VNC and SSH connections with same result. > Browser is Safari 17.1.2 > MacOS 14.1.2 > Apple M2 > Works as expected in Chrome, Firefox and Edge in MacOS -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1893) Selecting a connection from the all connections list produces 'paste' pop-up in Safari
[ https://issues.apache.org/jira/browse/GUACAMOLE-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper updated GUACAMOLE-1893: --- Environment: Safari 17.1.2 on MacOS 14.1.2 (was: CentOS 7 with libguac 1.5.2 and guacamole.war 1.4.0, 1.5.2 and .15.4. The libguac is from EPEL repo. The guacamole.war files are downloaded from guacamole.apache.org) > Selecting a connection from the all connections list produces 'paste' pop-up > in Safari > -- > > Key: GUACAMOLE-1893 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1893 > Project: Guacamole > Issue Type: Bug > Components: guacamole > Environment: Safari 17.1.2 on MacOS 14.1.2 >Reporter: Stephen Young >Priority: Minor > Attachments: Screenshot 2023-12-14 at 14.58.28.png, Screenshot > 2023-12-14 at 14.59.14.png > > > When selecting a connection from the 'ALL CONNECTIONS' list, a 'paste' pop-up > appears and halts the connection. If the paste pop-up is clicked, the > connection is successful. > When connected, opening the guacamole clipboard/display/etc menu also has the > same issue with a 'paste' pop-up halting the slide out until the pop-up is > clicked. > Screenshots attached. > Tested with RDP, VNC and SSH connections with same result. > Browser is Safari 17.1.2 > MacOS 14.1.2 > Apple M2 > Works as expected in Chrome, Firefox and Edge in MacOS -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1893) Selecting a connection from the all connections list produces 'paste' pop-up in Safari
[ https://issues.apache.org/jira/browse/GUACAMOLE-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper updated GUACAMOLE-1893: --- Priority: Minor (was: Major) > Selecting a connection from the all connections list produces 'paste' pop-up > in Safari > -- > > Key: GUACAMOLE-1893 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1893 > Project: Guacamole > Issue Type: Bug > Components: guacamole > Environment: CentOS 7 with libguac 1.5.2 and guacamole.war 1.4.0, > 1.5.2 and .15.4. The libguac is from EPEL repo. The guacamole.war files are > downloaded from guacamole.apache.org >Reporter: Stephen Young >Priority: Minor > Attachments: Screenshot 2023-12-14 at 14.58.28.png, Screenshot > 2023-12-14 at 14.59.14.png > > > When selecting a connection from the 'ALL CONNECTIONS' list, a 'paste' pop-up > appears and halts the connection. If the paste pop-up is clicked, the > connection is successful. > When connected, opening the guacamole clipboard/display/etc menu also has the > same issue with a 'paste' pop-up halting the slide out until the pop-up is > clicked. > Screenshots attached. > Tested with RDP, VNC and SSH connections with same result. > Browser is Safari 17.1.2 > MacOS 14.1.2 > Apple M2 > Works as expected in Chrome, Firefox and Edge in MacOS -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1893) Selecting a connection from the all connections list produces 'paste' pop-up in Safari
[ https://issues.apache.org/jira/browse/GUACAMOLE-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper updated GUACAMOLE-1893: --- Component/s: (was: guacamole-common-js) > Selecting a connection from the all connections list produces 'paste' pop-up > in Safari > -- > > Key: GUACAMOLE-1893 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1893 > Project: Guacamole > Issue Type: Bug >Affects Versions: 1.4.0, 1.5.2, 1.5.4 > Environment: CentOS 7 with libguac 1.5.2 and guacamole.war 1.4.0, > 1.5.2 and .15.4. The libguac is from EPEL repo. The guacamole.war files are > downloaded from guacamole.apache.org >Reporter: Stephen Young >Priority: Major > Attachments: Screenshot 2023-12-14 at 14.58.28.png, Screenshot > 2023-12-14 at 14.59.14.png > > > When selecting a connection from the 'ALL CONNECTIONS' list, a 'paste' pop-up > appears and halts the connection. If the paste pop-up is clicked, the > connection is successful. > When connected, opening the guacamole clipboard/display/etc menu also has the > same issue with a 'paste' pop-up halting the slide out until the pop-up is > clicked. > Screenshots attached. > Tested with RDP, VNC and SSH connections with same result. > Browser is Safari 17.1.2 > MacOS 14.1.2 > Apple M2 > Works as expected in Chrome, Firefox and Edge in MacOS -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1893) Selecting a connection from the all connections list produces 'paste' pop-up in Safari
[ https://issues.apache.org/jira/browse/GUACAMOLE-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper updated GUACAMOLE-1893: --- Affects Version/s: (was: 1.4.0) (was: 1.5.2) (was: 1.5.4) > Selecting a connection from the all connections list produces 'paste' pop-up > in Safari > -- > > Key: GUACAMOLE-1893 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1893 > Project: Guacamole > Issue Type: Bug > Environment: CentOS 7 with libguac 1.5.2 and guacamole.war 1.4.0, > 1.5.2 and .15.4. The libguac is from EPEL repo. The guacamole.war files are > downloaded from guacamole.apache.org >Reporter: Stephen Young >Priority: Major > Attachments: Screenshot 2023-12-14 at 14.58.28.png, Screenshot > 2023-12-14 at 14.59.14.png > > > When selecting a connection from the 'ALL CONNECTIONS' list, a 'paste' pop-up > appears and halts the connection. If the paste pop-up is clicked, the > connection is successful. > When connected, opening the guacamole clipboard/display/etc menu also has the > same issue with a 'paste' pop-up halting the slide out until the pop-up is > clicked. > Screenshots attached. > Tested with RDP, VNC and SSH connections with same result. > Browser is Safari 17.1.2 > MacOS 14.1.2 > Apple M2 > Works as expected in Chrome, Firefox and Edge in MacOS -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1893) Selecting a connection from the all connections list produces 'paste' pop-up in Safari
[ https://issues.apache.org/jira/browse/GUACAMOLE-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper updated GUACAMOLE-1893: --- Component/s: guacamole > Selecting a connection from the all connections list produces 'paste' pop-up > in Safari > -- > > Key: GUACAMOLE-1893 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1893 > Project: Guacamole > Issue Type: Bug > Components: guacamole > Environment: CentOS 7 with libguac 1.5.2 and guacamole.war 1.4.0, > 1.5.2 and .15.4. The libguac is from EPEL repo. The guacamole.war files are > downloaded from guacamole.apache.org >Reporter: Stephen Young >Priority: Major > Attachments: Screenshot 2023-12-14 at 14.58.28.png, Screenshot > 2023-12-14 at 14.59.14.png > > > When selecting a connection from the 'ALL CONNECTIONS' list, a 'paste' pop-up > appears and halts the connection. If the paste pop-up is clicked, the > connection is successful. > When connected, opening the guacamole clipboard/display/etc menu also has the > same issue with a 'paste' pop-up halting the slide out until the pop-up is > clicked. > Screenshots attached. > Tested with RDP, VNC and SSH connections with same result. > Browser is Safari 17.1.2 > MacOS 14.1.2 > Apple M2 > Works as expected in Chrome, Firefox and Edge in MacOS -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1880) Updates and corrections to Catalan translation
[ https://issues.apache.org/jira/browse/GUACAMOLE-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper closed GUACAMOLE-1880. -- Resolution: Done Closing this as the changes have already been released. If there are problems with the Catalan translation, those would need to be a new JIRA issue. > Updates and corrections to Catalan translation > -- > > Key: GUACAMOLE-1880 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1880 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Reporter: Albert >Priority: Minor > Fix For: 1.5.4 > > > Updated catalan translation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1140) Starting/joining an RDP connection may segfault depending on timing of underlying RDP/SFTP connection(s)
[
https://issues.apache.org/jira/browse/GUACAMOLE-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper updated GUACAMOLE-1140:
---
Summary: Starting/joining an RDP connection may segfault depending on
timing of underlying RDP/SFTP connection(s) (was: Joining an RDP connection
may segfault if underlying RDP connection is not yet established)
> Starting/joining an RDP connection may segfault depending on timing of
> underlying RDP/SFTP connection(s)
>
>
> Key: GUACAMOLE-1140
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1140
> Project: Guacamole
> Issue Type: Bug
> Components: RDP
>Affects Versions: 1.2.0, 1.5.4
>Reporter: Thomas Kruse
>Priority: Major
> Attachments: core.lzma
>
>
> If a user joins an RDP connection leveraging Guacamole's session sharing
> functionality, but the underlying connection to the RDP server has not yet
> been established, a segfault may occur while handling the join operation:
> {code:none}
> #1 0x55da270e5de9 in guac_common_list_lock (list=) at
> list.c:75
> #2 0x7f8bb956c5cb in guac_rdp_pipe_svc_send_pipes
> (user=user@entry=0x7f8bac00d5e0) at channels/pipe-svc.c:49
> #3 0x7f8bb957a0cb in guac_rdp_user_join_handler (user=0x7f8bac00d5e0,
> argc=, argv=) at user.c:92
> #4 0x7f8bbb1d134a in guac_client_add_user
> (client=client@entry=0x7f8b280060e0, user=user@entry=0x7f8bac00d5e0,
> argc=argc@entry=76,
> argv=) at client.c:286
> #5 0x7f8bbb1d8bea in guac_user_handle_connection
> (user=user@entry=0x7f8bac00d5e0, usec_timeout=usec_timeout@entry=1500)
> at user-handshake.c:337
> #6 0x55da270e5a96 in guacd_user_thread (data=0x7f8b280ad010) at proc.c:98
> #7 0x7f8bbade2fa3 in start_thread (arg=) at
> pthread_create.c:486
> #8 0x7f8bba71f4cf in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> {code}
> This is because the relevant structure ({{rdp_client->available_svc}}) is not
> actually allocated until later in the RDP-specific connection initialization
> process, which occurs in its own thread spawned by the connection owner. If
> that allocation has not yet occurred, the attempt to synchronize the
> newly-joined user with the current session state will result in a segfault.
> Original context:
> {quote}
> I am running guacd from docker on an Ubuntu 20.04 host. Connections to guacd
> are from a custom backend using the official guacamole-common 1.1.0 maven
> artifact with a websocket.
> To demonstrate stuff (teaching) multiple connections (10-12) are opened as
> shared sessions with the read-only property set after a leading session is
> opened and the connection id is propagated. The shared connections are all
> opened simultaneously - and closed (more or less) simultaneously, often
> together with the leading session.
> Shared drive is disabled.
> Most of the time it works flawlessly, until guacd segfaults.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1140) Joining an RDP connection may segfault if underlying RDP connection is not yet established
[
https://issues.apache.org/jira/browse/GUACAMOLE-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper updated GUACAMOLE-1140:
---
Affects Version/s: 1.5.4
> Joining an RDP connection may segfault if underlying RDP connection is not
> yet established
> --
>
> Key: GUACAMOLE-1140
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1140
> Project: Guacamole
> Issue Type: Bug
> Components: RDP
>Affects Versions: 1.2.0, 1.5.4
>Reporter: Thomas Kruse
>Priority: Major
> Attachments: core.lzma
>
>
> If a user joins an RDP connection leveraging Guacamole's session sharing
> functionality, but the underlying connection to the RDP server has not yet
> been established, a segfault may occur while handling the join operation:
> {code:none}
> #1 0x55da270e5de9 in guac_common_list_lock (list=) at
> list.c:75
> #2 0x7f8bb956c5cb in guac_rdp_pipe_svc_send_pipes
> (user=user@entry=0x7f8bac00d5e0) at channels/pipe-svc.c:49
> #3 0x7f8bb957a0cb in guac_rdp_user_join_handler (user=0x7f8bac00d5e0,
> argc=, argv=) at user.c:92
> #4 0x7f8bbb1d134a in guac_client_add_user
> (client=client@entry=0x7f8b280060e0, user=user@entry=0x7f8bac00d5e0,
> argc=argc@entry=76,
> argv=) at client.c:286
> #5 0x7f8bbb1d8bea in guac_user_handle_connection
> (user=user@entry=0x7f8bac00d5e0, usec_timeout=usec_timeout@entry=1500)
> at user-handshake.c:337
> #6 0x55da270e5a96 in guacd_user_thread (data=0x7f8b280ad010) at proc.c:98
> #7 0x7f8bbade2fa3 in start_thread (arg=) at
> pthread_create.c:486
> #8 0x7f8bba71f4cf in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> {code}
> This is because the relevant structure ({{rdp_client->available_svc}}) is not
> actually allocated until later in the RDP-specific connection initialization
> process, which occurs in its own thread spawned by the connection owner. If
> that allocation has not yet occurred, the attempt to synchronize the
> newly-joined user with the current session state will result in a segfault.
> Original context:
> {quote}
> I am running guacd from docker on an Ubuntu 20.04 host. Connections to guacd
> are from a custom backend using the official guacamole-common 1.1.0 maven
> artifact with a websocket.
> To demonstrate stuff (teaching) multiple connections (10-12) are opened as
> shared sessions with the read-only property set after a leading session is
> opened and the connection id is propagated. The shared connections are all
> opened simultaneously - and closed (more or less) simultaneously, often
> together with the leading session.
> Shared drive is disabled.
> Most of the time it works flawlessly, until guacd segfaults.
> {quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1892) Build fails with "undefined reference to 'timer_create'"
[
https://issues.apache.org/jira/browse/GUACAMOLE-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper updated GUACAMOLE-1892:
---
Affects Version/s: 1.5.4
> Build fails with "undefined reference to 'timer_create'"
>
>
> Key: GUACAMOLE-1892
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1892
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Affects Versions: 1.5.4
>Reporter: Mike Jumper
>Priority: Minor
>
> When attempting to build guacamole-server on Ubuntu 20.04.6, the build fails
> with the following errors:
> {code:none}
> /usr/bin/ld: .../src/libguac/.libs/libguac.so: undefined reference to
> `timer_delete'
> /usr/bin/ld: .../src/libguac/.libs/libguac.so: undefined reference to
> `timer_settime'
> /usr/bin/ld: .../src/libguac/.libs/libguac.so: undefined reference to
> `timer_create'
> {code}
> This is because the {{timer_create()}}, {{timer_settime()}}, and
> {{timer_delete()}} functions are defined in a separate library on Ubuntu
> 20.04 ({{librt}}). A configure test likely needs to be added to recognize
> whether {{librt}} needs to be linked in.
> *NOTE:* Users encountering this error can work around the problem by
> performing the build with the {{LDFLAGS}} environment variable set to
> {{"-lrt"}}. For example, when running {{configure}} for a fresh build:
> {code:none}
> LDFLAGS="-lrt" ./configure
> {code}
> Running {{make}}, etc. should then succeed as normal.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GUACAMOLE-1892) Build fails with "undefined reference to 'timer_create'"
Mike Jumper created GUACAMOLE-1892:
--
Summary: Build fails with "undefined reference to 'timer_create'"
Key: GUACAMOLE-1892
URL: https://issues.apache.org/jira/browse/GUACAMOLE-1892
Project: Guacamole
Issue Type: Bug
Reporter: Mike Jumper
When attempting to build guacamole-server on Ubuntu 20.04.6, the build fails
with the following errors:
{code:none}
/usr/bin/ld: .../src/libguac/.libs/libguac.so: undefined reference to
`timer_delete'
/usr/bin/ld: .../src/libguac/.libs/libguac.so: undefined reference to
`timer_settime'
/usr/bin/ld: .../src/libguac/.libs/libguac.so: undefined reference to
`timer_create'
{code}
This is because the {{timer_create()}}, {{timer_settime()}}, and
{{timer_delete()}} functions are defined in a separate library on Ubuntu 20.04
({{librt}}). A configure test likely needs to be added to recognize whether
{{librt}} needs to be linked in.
*NOTE:* Users encountering this error can work around the problem by performing
the build with the {{LDFLAGS}} environment variable set to {{"-lrt"}}. For
example, when running {{configure}} for a fresh build:
{code:none}
LDFLAGS="-lrt" ./configure
{code}
Running {{make}}, etc. should then succeed as normal.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1892) Build fails with "undefined reference to 'timer_create'"
[
https://issues.apache.org/jira/browse/GUACAMOLE-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper updated GUACAMOLE-1892:
---
Component/s: guacamole-server
> Build fails with "undefined reference to 'timer_create'"
>
>
> Key: GUACAMOLE-1892
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1892
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Reporter: Mike Jumper
>Priority: Minor
>
> When attempting to build guacamole-server on Ubuntu 20.04.6, the build fails
> with the following errors:
> {code:none}
> /usr/bin/ld: .../src/libguac/.libs/libguac.so: undefined reference to
> `timer_delete'
> /usr/bin/ld: .../src/libguac/.libs/libguac.so: undefined reference to
> `timer_settime'
> /usr/bin/ld: .../src/libguac/.libs/libguac.so: undefined reference to
> `timer_create'
> {code}
> This is because the {{timer_create()}}, {{timer_settime()}}, and
> {{timer_delete()}} functions are defined in a separate library on Ubuntu
> 20.04 ({{librt}}). A configure test likely needs to be added to recognize
> whether {{librt}} needs to be linked in.
> *NOTE:* Users encountering this error can work around the problem by
> performing the build with the {{LDFLAGS}} environment variable set to
> {{"-lrt"}}. For example, when running {{configure}} for a fresh build:
> {code:none}
> LDFLAGS="-lrt" ./configure
> {code}
> Running {{make}}, etc. should then succeed as normal.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GUACAMOLE-1891) guacamole-server Docker image no longer builds as of Alpine 3.19
Mike Jumper created GUACAMOLE-1891:
--
Summary: guacamole-server Docker image no longer builds as of
Alpine 3.19
Key: GUACAMOLE-1891
URL: https://issues.apache.org/jira/browse/GUACAMOLE-1891
Project: Guacamole
Issue Type: Bug
Components: guacd-docker
Reporter: Mike Jumper
The guacamole-server Docker image now fails to build as of the release of
Alpine 3.19 earlier this month (December 2023), as the
{{openssl1.1-compat-dev}} package is no longer present:
{code:none}
1.005 fetch
https://dl-cdn.alpinelinux.org/alpine/v3.19/main/x86_64/APKINDEX.tar.gz
1.430 fetch
https://dl-cdn.alpinelinux.org/alpine/v3.19/community/x86_64/APKINDEX.tar.gz
2.136 ERROR: unable to select packages:
2.136 openssl1.1-compat-dev (no such package):
2.136 required by: world[openssl1.1-compat-dev]
{code}
It's possible to still build the image by manually overriding the base image to
Alpine 3.18 using {{--build-arg="ALPINE_BASE_IMAGE=3.18"}} when building.
*NOTE:* Full EOL date for Alpine 3.18 is 2025-05-09.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1890) Segfault in RDP Connection Pending Join Handler
[
https://issues.apache.org/jira/browse/GUACAMOLE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794510#comment-17794510
]
Mike Jumper commented on GUACAMOLE-1890:
I think this is GUACAMOLE-1140, now broadened by the migration to
{{join_pending_handler}}.
> Segfault in RDP Connection Pending Join Handler
> ---
>
> Key: GUACAMOLE-1890
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1890
> Project: Guacamole
> Issue Type: Bug
> Components: RDP
>Affects Versions: 1.5.4
>Reporter: Nick Couchman
>Priority: Major
>
> Well, this makes me really happy - all the development and banging on various
> revisions of 1.5.4, and I run into this bug shortly after approving/merging
> the website release.
> I've managed to hit just the right combination of...something...to run into a
> segfault during RDP connections using the 1.5.4 code. The segfault appears to
> be related to the new join handler/synchronization code:
> {code}
> #0 0x76fead00 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1 0x00404fa9 in guac_common_list_lock (list=) at
> list.c:95
> #2 0x70d5b8a8 in guac_rdp_pipe_svc_send_pipes (client= out>, socket=0x7fffec0135a0) at channels/pipe-svc.c:51
> #3 0x70d62440 in guac_rdp_join_pending_handler
> (client=0x7fffec0145a0) at client.c:126
> #4 0x77bc12bd in guac_client_promote_pending_users (data=...) at
> client.c:197
> #5 0x739edf5f in timer_sigev_thread () from /lib64/librt.so.1
> #6 0x76fe8ea5 in start_thread () from /lib64/libpthread.so.0
> #7 0x758e4b0d in clone () from /lib64/libc.so.6
> {code}
> At the moment, it seems to impact RDP connections where I've also enabled
> SFTP. If I disable the SFTP component, I am able to complete the RDP
> connection. So, seems like maybe there's some sort of race condition that the
> SSH/SFTP connection is introducing that causes it to attempt to lock the list
> prior to it being initialized.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GUACAMOLE-1890) Segfault in RDP Connection Pending Join Handler
[
https://issues.apache.org/jira/browse/GUACAMOLE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794509#comment-17794509
]
Mike Jumper edited comment on GUACAMOLE-1890 at 12/8/23 4:10 AM:
-
This sounds to me like a race condition in the allocation of
{{rdp_client->available_svc}}, where enabling SFTP makes the connection process
take _just_ long enough to cause {{guac_rdp_pipe_svc_send_pipes()}} to be
called too early. There is an overall lock on {{rdp_client}} - I'm not sure why
we're not locking that in {{guac_rdp_join_pending_handler}}. [~jmuehlner], do
you remember if there was a reason we can't acquire the lock?
Either way, there should probably be a {{NULL}} check around
{{rdp_client->available_svc}} ... either within
{{guac_rdp_pipe_svc_send_pipes()}} or within the join pending handler.
was (Author: mike.jumper):
This sounds to me like a race condition in the allocation of
{{rdp_client->available_svc}}, where enabling SFTP makes the connection process
take _just_ long enough to cause {{guac_rdp_pipe_svc_send_pipes()}} to be
called too early. There is an overall lock on {{rdp_client}} - I'm not sure why
we're not locking that in {{guac_rdp_join_pending_handler}}. [~jmuehlner], do
you remember if there was a reason we can't acquire the lock?
Either way, there should probably be a {{NULL}} check around
{{rdp_client->available_svc}} ... either within
{{guac_rdp_pipe_svc_send_pipes()}} or within the join pending handler.
> Segfault in RDP Connection Pending Join Handler
> ---
>
> Key: GUACAMOLE-1890
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1890
> Project: Guacamole
> Issue Type: Bug
> Components: RDP
>Affects Versions: 1.5.4
>Reporter: Nick Couchman
>Priority: Major
>
> Well, this makes me really happy - all the development and banging on various
> revisions of 1.5.4, and I run into this bug shortly after approving/merging
> the website release.
> I've managed to hit just the right combination of...something...to run into a
> segfault during RDP connections using the 1.5.4 code. The segfault appears to
> be related to the new join handler/synchronization code:
> {code}
> #0 0x76fead00 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1 0x00404fa9 in guac_common_list_lock (list=) at
> list.c:95
> #2 0x70d5b8a8 in guac_rdp_pipe_svc_send_pipes (client= out>, socket=0x7fffec0135a0) at channels/pipe-svc.c:51
> #3 0x70d62440 in guac_rdp_join_pending_handler
> (client=0x7fffec0145a0) at client.c:126
> #4 0x77bc12bd in guac_client_promote_pending_users (data=...) at
> client.c:197
> #5 0x739edf5f in timer_sigev_thread () from /lib64/librt.so.1
> #6 0x76fe8ea5 in start_thread () from /lib64/libpthread.so.0
> #7 0x758e4b0d in clone () from /lib64/libc.so.6
> {code}
> At the moment, it seems to impact RDP connections where I've also enabled
> SFTP. If I disable the SFTP component, I am able to complete the RDP
> connection. So, seems like maybe there's some sort of race condition that the
> SSH/SFTP connection is introducing that causes it to attempt to lock the list
> prior to it being initialized.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1890) Segfault in RDP Connection Pending Join Handler
[
https://issues.apache.org/jira/browse/GUACAMOLE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17794509#comment-17794509
]
Mike Jumper commented on GUACAMOLE-1890:
This sounds to me like a race condition in the allocation of
{{rdp_client->available_svc}}, where enabling SFTP makes the connection process
take _just_ long enough to cause {{guac_rdp_pipe_svc_send_pipes()}} to be
called too early. There is an overall lock on {{rdp_client}} - I'm not sure why
we're not locking that in {{guac_rdp_join_pending_handler}}. [~jmuehlner], do
you remember if there was a reason we can't acquire the lock?
Either way, there should probably be a {{NULL}} check around
{{rdp_client->available_svc}} ... either within
{{guac_rdp_pipe_svc_send_pipes()}} or within the join pending handler.
> Segfault in RDP Connection Pending Join Handler
> ---
>
> Key: GUACAMOLE-1890
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1890
> Project: Guacamole
> Issue Type: Improvement
> Components: RDP
>Affects Versions: 1.5.4
>Reporter: Nick Couchman
>Priority: Major
>
> Well, this makes me really happy - all the development and banging on various
> revisions of 1.5.4, and I run into this bug shortly after approving/merging
> the website release.
> I've managed to hit just the right combination of...something...to run into a
> segfault during RDP connections using the 1.5.4 code. The segfault appears to
> be related to the new join handler/synchronization code:
> {code}
> #0 0x76fead00 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1 0x00404fa9 in guac_common_list_lock (list=) at
> list.c:95
> #2 0x70d5b8a8 in guac_rdp_pipe_svc_send_pipes (client= out>, socket=0x7fffec0135a0) at channels/pipe-svc.c:51
> #3 0x70d62440 in guac_rdp_join_pending_handler
> (client=0x7fffec0145a0) at client.c:126
> #4 0x77bc12bd in guac_client_promote_pending_users (data=...) at
> client.c:197
> #5 0x739edf5f in timer_sigev_thread () from /lib64/librt.so.1
> #6 0x76fe8ea5 in start_thread () from /lib64/libpthread.so.0
> #7 0x758e4b0d in clone () from /lib64/libc.so.6
> {code}
> At the moment, it seems to impact RDP connections where I've also enabled
> SFTP. If I disable the SFTP component, I am able to complete the RDP
> connection. So, seems like maybe there's some sort of race condition that the
> SSH/SFTP connection is introducing that causes it to attempt to lock the list
> prior to it being initialized.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1890) Segfault in RDP Connection Pending Join Handler
[
https://issues.apache.org/jira/browse/GUACAMOLE-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper updated GUACAMOLE-1890:
---
Issue Type: Bug (was: Improvement)
> Segfault in RDP Connection Pending Join Handler
> ---
>
> Key: GUACAMOLE-1890
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1890
> Project: Guacamole
> Issue Type: Bug
> Components: RDP
>Affects Versions: 1.5.4
>Reporter: Nick Couchman
>Priority: Major
>
> Well, this makes me really happy - all the development and banging on various
> revisions of 1.5.4, and I run into this bug shortly after approving/merging
> the website release.
> I've managed to hit just the right combination of...something...to run into a
> segfault during RDP connections using the 1.5.4 code. The segfault appears to
> be related to the new join handler/synchronization code:
> {code}
> #0 0x76fead00 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #1 0x00404fa9 in guac_common_list_lock (list=) at
> list.c:95
> #2 0x70d5b8a8 in guac_rdp_pipe_svc_send_pipes (client= out>, socket=0x7fffec0135a0) at channels/pipe-svc.c:51
> #3 0x70d62440 in guac_rdp_join_pending_handler
> (client=0x7fffec0145a0) at client.c:126
> #4 0x77bc12bd in guac_client_promote_pending_users (data=...) at
> client.c:197
> #5 0x739edf5f in timer_sigev_thread () from /lib64/librt.so.1
> #6 0x76fe8ea5 in start_thread () from /lib64/libpthread.so.0
> #7 0x758e4b0d in clone () from /lib64/libc.so.6
> {code}
> At the moment, it seems to impact RDP connections where I've also enabled
> SFTP. If I disable the SFTP component, I am able to complete the RDP
> connection. So, seems like maybe there's some sort of race condition that the
> SSH/SFTP connection is introducing that causes it to attempt to lock the list
> prior to it being initialized.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1859) Update webapp dependencies to latest stable and compatible versions
[ https://issues.apache.org/jira/browse/GUACAMOLE-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper closed GUACAMOLE-1859. -- Resolution: Done > Update webapp dependencies to latest stable and compatible versions > --- > > Key: GUACAMOLE-1859 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1859 > Project: Guacamole > Issue Type: Task > Components: guacamole-client >Affects Versions: 1.5.4 >Reporter: Mike Jumper >Assignee: Mike Jumper >Priority: Minor > Fix For: 1.5.4 > > > Some Guacamole dependencies have updates available. As part of our usual > release housekeeping, these dependencies should be updated if doing so does > not break things. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (GUACAMOLE-1859) Update webapp dependencies to latest stable and compatible versions
[ https://issues.apache.org/jira/browse/GUACAMOLE-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper reopened GUACAMOLE-1859: Reopening to apply further updates that happened since the RC1 vote started. > Update webapp dependencies to latest stable and compatible versions > --- > > Key: GUACAMOLE-1859 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1859 > Project: Guacamole > Issue Type: Task > Components: guacamole-client >Affects Versions: 1.5.4 >Reporter: Mike Jumper >Assignee: Mike Jumper >Priority: Minor > Fix For: 1.5.4 > > > Some Guacamole dependencies have updates available. As part of our usual > release housekeeping, these dependencies should be updated if doing so does > not break things. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1888) The clipboard of the RDP protocol is unable to fully copy long texts
[ https://issues.apache.org/jira/browse/GUACAMOLE-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791819#comment-17791819 ] Mike Jumper commented on GUACAMOLE-1888: As noted on GUACAMOLE-739, there is an intentional upper bound on the size of the clipboard. > The clipboard of the RDP protocol is unable to fully copy long texts > > > Key: GUACAMOLE-1888 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1888 > Project: Guacamole > Issue Type: Bug > Components: guacamole, guacamole-client >Affects Versions: 1.5.3 >Reporter: rysinal >Priority: Minor > > When I copy the content of a locally stored document with a size of 539KB and > send it to a remote RDP desktop using Guacamole, the content gets truncated > to only 132KB. However, when I tried using Microsoft Remote Desktop software, > it does not truncate the large text -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1888) The clipboard of the RDP protocol is unable to fully copy long texts
[ https://issues.apache.org/jira/browse/GUACAMOLE-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper closed GUACAMOLE-1888. -- Resolution: Not A Bug > The clipboard of the RDP protocol is unable to fully copy long texts > > > Key: GUACAMOLE-1888 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1888 > Project: Guacamole > Issue Type: Bug > Components: guacamole, guacamole-client >Affects Versions: 1.5.3 >Reporter: rysinal >Priority: Minor > > When I copy the content of a locally stored document with a size of 539KB and > send it to a remote RDP desktop using Guacamole, the content gets truncated > to only 132KB. However, when I tried using Microsoft Remote Desktop software, > it does not truncate the large text -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1860) Typo in environment variables for Dockerfile
[ https://issues.apache.org/jira/browse/GUACAMOLE-1860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper closed GUACAMOLE-1860. -- > Typo in environment variables for Dockerfile > > > Key: GUACAMOLE-1860 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1860 > Project: Guacamole > Issue Type: Bug > Components: guacamole-auth-jdbc-sqlserver, guacamole-docker >Affects Versions: 1.5.3 >Reporter: Mazlum >Priority: Trivial > Fix For: 1.5.4 > > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > In the > `[guacamole-docker/bin/start.sh|https://github.com/apache/guacamole-client/blob/e75c79f57c642c36c2cff06bacd42aaee7af01f0/guacamole-docker/bin/start.sh#L563C1-L563C1]`, > there is a typo for the SQL Server Settings, when set with environment > variables. > > > $SQLSERVERQL_AUTO_CREATE_ACCOUNTS" > > $SQLSERVERQL_INSTANCE > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1886) Bump version numbers to 1.5.4
[ https://issues.apache.org/jira/browse/GUACAMOLE-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper closed GUACAMOLE-1886. -- Resolution: Done > Bump version numbers to 1.5.4 > - > > Key: GUACAMOLE-1886 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1886 > Project: Guacamole > Issue Type: Task > Components: Documentation, guacamole-client, guacamole-server >Reporter: Mike Jumper >Assignee: Mike Jumper >Priority: Blocker > Fix For: 1.5.4 > > > The version numbers of all components within guacamole-client and > guacamole-server need to be bumped to 1.5.4. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1887) Projects outside scope of 1.5.4 fail to build following merge of version number bump
[ https://issues.apache.org/jira/browse/GUACAMOLE-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper closed GUACAMOLE-1887. -- Resolution: Fixed > Projects outside scope of 1.5.4 fail to build following merge of version > number bump > > > Key: GUACAMOLE-1887 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1887 > Project: Guacamole > Issue Type: Bug > Components: guacamole-client >Reporter: Mike Jumper >Assignee: Mike Jumper >Priority: Blocker > Fix For: 1.6.0 > > > The "guacamole-auth-ban", "guacamole-display-statistics", and > "guacamole-auth-sso-ssl" extensions, all not part of 1.5.4, no longer build > as they haven't been updated to point to the proper parent project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1886) Bump version numbers to 1.5.4
[ https://issues.apache.org/jira/browse/GUACAMOLE-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper updated GUACAMOLE-1886: --- Component/s: Documentation > Bump version numbers to 1.5.4 > - > > Key: GUACAMOLE-1886 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1886 > Project: Guacamole > Issue Type: Task > Components: Documentation, guacamole-client, guacamole-server >Reporter: Mike Jumper >Assignee: Mike Jumper >Priority: Blocker > Fix For: 1.5.4 > > > The version numbers of all components within guacamole-client and > guacamole-server need to be bumped to 1.5.4. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (GUACAMOLE-1886) Bump version numbers to 1.5.4
[ https://issues.apache.org/jira/browse/GUACAMOLE-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper reopened GUACAMOLE-1886: Oops - good catch. > Bump version numbers to 1.5.4 > - > > Key: GUACAMOLE-1886 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1886 > Project: Guacamole > Issue Type: Task > Components: guacamole-client, guacamole-server >Reporter: Mike Jumper >Assignee: Mike Jumper >Priority: Blocker > Fix For: 1.5.4 > > > The version numbers of all components within guacamole-client and > guacamole-server need to be bumped to 1.5.4. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1886) Bump version numbers to 1.5.4
[ https://issues.apache.org/jira/browse/GUACAMOLE-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper closed GUACAMOLE-1886. -- Resolution: Done > Bump version numbers to 1.5.4 > - > > Key: GUACAMOLE-1886 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1886 > Project: Guacamole > Issue Type: Task > Components: guacamole-client, guacamole-server >Reporter: Mike Jumper >Assignee: Mike Jumper >Priority: Blocker > Fix For: 1.5.4 > > > The version numbers of all components within guacamole-client and > guacamole-server need to be bumped to 1.5.4. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GUACAMOLE-1887) Projects outside scope of 1.5.4 fail to build following merge of version number bump
[ https://issues.apache.org/jira/browse/GUACAMOLE-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper reassigned GUACAMOLE-1887: -- Assignee: Mike Jumper > Projects outside scope of 1.5.4 fail to build following merge of version > number bump > > > Key: GUACAMOLE-1887 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1887 > Project: Guacamole > Issue Type: Bug > Components: guacamole-client >Reporter: Mike Jumper >Assignee: Mike Jumper >Priority: Blocker > Fix For: 1.6.0 > > > The "guacamole-auth-ban", "guacamole-display-statistics", and > "guacamole-auth-sso-ssl" extensions, all not part of 1.5.4, no longer build > as they haven't been updated to point to the proper parent project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GUACAMOLE-1887) Projects outside scope of 1.5.4 fail to build following merge of version number bump
Mike Jumper created GUACAMOLE-1887: -- Summary: Projects outside scope of 1.5.4 fail to build following merge of version number bump Key: GUACAMOLE-1887 URL: https://issues.apache.org/jira/browse/GUACAMOLE-1887 Project: Guacamole Issue Type: Bug Components: guacamole-client Reporter: Mike Jumper Fix For: 1.6.0 The "guacamole-auth-ban", "guacamole-display-statistics", and "guacamole-auth-sso-ssl" extensions, all not part of 1.5.4, no longer build as they haven't been updated to point to the proper parent project. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1880) Updates and corrections to Catalan translation
[ https://issues.apache.org/jira/browse/GUACAMOLE-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper updated GUACAMOLE-1880: --- Component/s: guacamole (was: guacamole-client) > Updates and corrections to Catalan translation > -- > > Key: GUACAMOLE-1880 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1880 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Reporter: Albert >Priority: Minor > Fix For: 1.5.4 > > > Updated catalan translation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1880) Updates and corrections to Catalan translation
[ https://issues.apache.org/jira/browse/GUACAMOLE-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper closed GUACAMOLE-1880. -- Resolution: Done > Updates and corrections to Catalan translation > -- > > Key: GUACAMOLE-1880 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1880 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Reporter: Albert >Priority: Minor > Fix For: 1.5.4 > > > Updated catalan translation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GUACAMOLE-1886) Bump version numbers to 1.5.4
[ https://issues.apache.org/jira/browse/GUACAMOLE-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper reassigned GUACAMOLE-1886: -- Assignee: Mike Jumper > Bump version numbers to 1.5.4 > - > > Key: GUACAMOLE-1886 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1886 > Project: Guacamole > Issue Type: Task > Components: guacamole-client, guacamole-server >Reporter: Mike Jumper >Assignee: Mike Jumper >Priority: Blocker > Fix For: 1.5.4 > > > The version numbers of all components within guacamole-client and > guacamole-server need to be bumped to 1.5.4. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GUACAMOLE-1886) Bump version numbers to 1.5.4
Mike Jumper created GUACAMOLE-1886: -- Summary: Bump version numbers to 1.5.4 Key: GUACAMOLE-1886 URL: https://issues.apache.org/jira/browse/GUACAMOLE-1886 Project: Guacamole Issue Type: Task Components: guacamole-client, guacamole-server Reporter: Mike Jumper Fix For: 1.5.4 The version numbers of all components within guacamole-client and guacamole-server need to be bumped to 1.5.4. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (GUACAMOLE-1658) Unable to compile guacamole server with --enable-ssh-agent
[
https://issues.apache.org/jira/browse/GUACAMOLE-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788535#comment-17788535
]
Mike Jumper edited comment on GUACAMOLE-1658 at 11/21/23 8:10 PM:
--
OK - while the main build error is pretty straightforward, the others aren't.
Once you get past the basic things like the renamed headers and functions, you
quickly get into old code that needs to manually sign things with keys, yet
that's exactly the code that was removed when {{ssh_key.h}} was removed:
{code:none}
...
ssh_agent.c: In function 'ssh_auth_agent_sign':
ssh_agent.c:42:5: error: unknown type name 'ssh_key'
42 | ssh_key* key = agent->identity;
| ^~~
ssh_agent.c:42:20: error: initialization of 'int *' from incompatible pointer
type 'guac_common_ssh_key *' [-Werror=incompatible-pointer-types]
42 | ssh_key* key = agent->identity;
|^
ssh_agent.c:51:15: error: implicit declaration of function 'ssh_key_sign'
[-Werror=implicit-function-declaration]
51 | sig_len = ssh_key_sign(key, data, data_length, (u_char*) sig);
|
...
{code}
There's probably functions now provided by libssh2 that we can use instead, but
this is looking more like "re-implement the SSH agent support that's been
broken since 0.9.8" and less like "fix the trivial build failure".
I think we should probably pull this from 1.5.4.
was (Author: mike.jumper):
OK - while the main build error is pretty straightforward, the others aren't.
Once you get past the basic things like the renamed headers and functions, you
quickly get into old code that needs to manually sign things with keys, yet
that's exactly the code that was removed when {{ssh_key.h}} was removed:
{code:none}
...
ssh_agent.c: In function 'ssh_auth_agent_sign':
ssh_agent.c:42:5: error: unknown type name 'ssh_key'
42 | ssh_key* key = agent->identity;
| ^~~
ssh_agent.c:42:20: error: initialization of 'int *' from incompatible pointer
type 'guac_common_ssh_key *' [-Werror=incompatible-pointer-types]
42 | ssh_key* key = agent->identity;
|^
ssh_agent.c:51:15: error: implicit declaration of function 'ssh_key_sign'
[-Werror=implicit-function-declaration]
51 | sig_len = ssh_key_sign(key, data, data_length, (u_char*) sig);
|
...
{code}
There's probably functions now provided by libssh2 that we can use instead, but
this is looking more like a "re-implement the SSH agent support that's been
broken since 0.9.8" and less like "fix the trivial build failure".
I think we should probably pull this from 1.5.4.
> Unable to compile guacamole server with --enable-ssh-agent
> --
>
> Key: GUACAMOLE-1658
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1658
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Affects Versions: 1.4.0
> Environment: Rocky Linux 8.6 on x64, the latest libssh2 from remi
> repository, guacamole server version 1.4.0.
>Reporter: Pavel Kuzel
>Assignee: Nick Couchman
>Priority: Minor
> Labels: guacamole-server, ssh-agent
> Fix For: 1.5.4
>
>
> Hello there,
> a compilation of guacamole-server on Rocky Linux 8.6 with
> "--enable-ssh-agent" fails on the missing ssh_key.h header file. Please see
> the detail below:
> _make[2]: Entering directory
> '/home/guacamole/guacamole-server/src/protocols/ssh'_
> _CC libguac_client_ssh_la-argv.lo_
> _In file included from ssh.h:33,_
> _from argv.c:22:_
> _ssh_agent.h:26:10: fatal error: ssh_key.h: No such file or directory_
> _#include "ssh_key.h"_
> _^~~_
> _compilation terminated._
> Just for the record, I use the latest version of libssh2 (1.10.0) and I'd
> like to use the agent forwarding functionality within the guacamole server.
> Is there any way how to get it running in the current version of
> guacamole-server?
> Regards,
> Pavel
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1658) Unable to compile guacamole server with --enable-ssh-agent
[
https://issues.apache.org/jira/browse/GUACAMOLE-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788535#comment-17788535
]
Mike Jumper commented on GUACAMOLE-1658:
OK - while the main build error is pretty straightforward, the others aren't.
Once you get past the basic things like the renamed headers and functions, you
quickly get into old code that needs to manually sign things with keys, yet
that's exactly the code that was removed when {{ssh_key.h}} was removed:
{code:none}
...
ssh_agent.c: In function 'ssh_auth_agent_sign':
ssh_agent.c:42:5: error: unknown type name 'ssh_key'
42 | ssh_key* key = agent->identity;
| ^~~
ssh_agent.c:42:20: error: initialization of 'int *' from incompatible pointer
type 'guac_common_ssh_key *' [-Werror=incompatible-pointer-types]
42 | ssh_key* key = agent->identity;
|^
ssh_agent.c:51:15: error: implicit declaration of function 'ssh_key_sign'
[-Werror=implicit-function-declaration]
51 | sig_len = ssh_key_sign(key, data, data_length, (u_char*) sig);
|
...
{code}
There's probably functions now provided by libssh2 that we can use instead, but
this is looking more like a "re-implement the SSH agent support that's been
broken since 0.9.8" and less like "fix the trivial build failure".
I think we should probably pull this from 1.5.4.
> Unable to compile guacamole server with --enable-ssh-agent
> --
>
> Key: GUACAMOLE-1658
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1658
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Affects Versions: 1.4.0
> Environment: Rocky Linux 8.6 on x64, the latest libssh2 from remi
> repository, guacamole server version 1.4.0.
>Reporter: Pavel Kuzel
>Assignee: Nick Couchman
>Priority: Minor
> Labels: guacamole-server, ssh-agent
> Fix For: 1.5.4
>
>
> Hello there,
> a compilation of guacamole-server on Rocky Linux 8.6 with
> "--enable-ssh-agent" fails on the missing ssh_key.h header file. Please see
> the detail below:
> _make[2]: Entering directory
> '/home/guacamole/guacamole-server/src/protocols/ssh'_
> _CC libguac_client_ssh_la-argv.lo_
> _In file included from ssh.h:33,_
> _from argv.c:22:_
> _ssh_agent.h:26:10: fatal error: ssh_key.h: No such file or directory_
> _#include "ssh_key.h"_
> _^~~_
> _compilation terminated._
> Just for the record, I use the latest version of libssh2 (1.10.0) and I'd
> like to use the agent forwarding functionality within the guacamole server.
> Is there any way how to get it running in the current version of
> guacamole-server?
> Regards,
> Pavel
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1658) Unable to compile guacamole server with --enable-ssh-agent
[ https://issues.apache.org/jira/browse/GUACAMOLE-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788512#comment-17788512 ] Mike Jumper commented on GUACAMOLE-1658: I'm really curious whether this will already just work. I'm going to try making the minimal changes to match the agent forwarding support included in libssh2 1.11.0. If it does work and the changes are truly minimal, then I think it's probably fine to keep it in 1.5.4. > Unable to compile guacamole server with --enable-ssh-agent > -- > > Key: GUACAMOLE-1658 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1658 > Project: Guacamole > Issue Type: Bug > Components: guacamole-server >Affects Versions: 1.4.0 > Environment: Rocky Linux 8.6 on x64, the latest libssh2 from remi > repository, guacamole server version 1.4.0. >Reporter: Pavel Kuzel >Assignee: Nick Couchman >Priority: Minor > Labels: guacamole-server, ssh-agent > Fix For: 1.5.4 > > > Hello there, > a compilation of guacamole-server on Rocky Linux 8.6 with > "--enable-ssh-agent" fails on the missing ssh_key.h header file. Please see > the detail below: > _make[2]: Entering directory > '/home/guacamole/guacamole-server/src/protocols/ssh'_ > _CC libguac_client_ssh_la-argv.lo_ > _In file included from ssh.h:33,_ > _from argv.c:22:_ > _ssh_agent.h:26:10: fatal error: ssh_key.h: No such file or directory_ > _#include "ssh_key.h"_ > _^~~_ > _compilation terminated._ > Just for the record, I use the latest version of libssh2 (1.10.0) and I'd > like to use the agent forwarding functionality within the guacamole server. > Is there any way how to get it running in the current version of > guacamole-server? > Regards, > Pavel > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (GUACAMOLE-1658) Unable to compile guacamole server with --enable-ssh-agent
[
https://issues.apache.org/jira/browse/GUACAMOLE-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788214#comment-17788214
]
Mike Jumper edited comment on GUACAMOLE-1658 at 11/21/23 6:49 PM:
--
I think this also depended on a patched version of libssh2 that had more broad
SSH agent support via a {{LIBSSH2_CALLBACK_AUTH_AGENT}} callback which
otherwise does not exist in libssh2. It looks like something along these lines
was added via:
https://github.com/libssh2/libssh2/commit/bc4e619e76071393e466c29220fc4ef5764c2820
which is indeed part of libssh2 1.11.0. I'm not sure whether there are
additional code changes necessary beyond simply switching from
{{LIBSSH2_CALLBACK_AUTH_AGENT}} to {{LIBSSH2_CALLBACK_AUTHAGENT}}. If things do
work now without patching libssh2, we can probably get rid of the need to
manually add {{--enable-ssh-agent}} and just test for whether
{{LIBSSH2_CALLBACK_AUTHAGENT}} is declared.
(Correction: Agent forwarding is _not _ part of libssh2 1.10.0. It's part of
libssh2 1.11.0.)
was (Author: mike.jumper):
I think this also depended on a patched version of libssh2 that had more broad
SSH agent support via a {{LIBSSH2_CALLBACK_AUTH_AGENT}} callback which
otherwise does not exist in libssh2. It looks like something along these lines
was added via:
https://github.com/libssh2/libssh2/commit/bc4e619e76071393e466c29220fc4ef5764c2820
which is indeed part of libssh2 1.10.0. I'm not sure whether there are
additional code changes necessary beyond simply switching from
{{LIBSSH2_CALLBACK_AUTH_AGENT}} to {{LIBSSH2_CALLBACK_AUTHAGENT}}. If things do
work now without patching libssh2, we can probably get rid of the need to
manually add {{--enable-ssh-agent}} and just test for whether
{{LIBSSH2_CALLBACK_AUTHAGENT}} is declared.
> Unable to compile guacamole server with --enable-ssh-agent
> --
>
> Key: GUACAMOLE-1658
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1658
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Affects Versions: 1.4.0
> Environment: Rocky Linux 8.6 on x64, the latest libssh2 from remi
> repository, guacamole server version 1.4.0.
>Reporter: Pavel Kuzel
>Assignee: Nick Couchman
>Priority: Minor
> Labels: guacamole-server, ssh-agent
> Fix For: 1.5.4
>
>
> Hello there,
> a compilation of guacamole-server on Rocky Linux 8.6 with
> "--enable-ssh-agent" fails on the missing ssh_key.h header file. Please see
> the detail below:
> _make[2]: Entering directory
> '/home/guacamole/guacamole-server/src/protocols/ssh'_
> _CC libguac_client_ssh_la-argv.lo_
> _In file included from ssh.h:33,_
> _from argv.c:22:_
> _ssh_agent.h:26:10: fatal error: ssh_key.h: No such file or directory_
> _#include "ssh_key.h"_
> _^~~_
> _compilation terminated._
> Just for the record, I use the latest version of libssh2 (1.10.0) and I'd
> like to use the agent forwarding functionality within the guacamole server.
> Is there any way how to get it running in the current version of
> guacamole-server?
> Regards,
> Pavel
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GUACAMOLE-1658) Unable to compile guacamole server with --enable-ssh-agent
[
https://issues.apache.org/jira/browse/GUACAMOLE-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788214#comment-17788214
]
Mike Jumper edited comment on GUACAMOLE-1658 at 11/21/23 6:49 PM:
--
I think this also depended on a patched version of libssh2 that had more broad
SSH agent support via a {{LIBSSH2_CALLBACK_AUTH_AGENT}} callback which
otherwise does not exist in libssh2. It looks like something along these lines
was added via:
https://github.com/libssh2/libssh2/commit/bc4e619e76071393e466c29220fc4ef5764c2820
which is indeed part of libssh2 1.11.0. I'm not sure whether there are
additional code changes necessary beyond simply switching from
{{LIBSSH2_CALLBACK_AUTH_AGENT}} to {{LIBSSH2_CALLBACK_AUTHAGENT}}. If things do
work now without patching libssh2, we can probably get rid of the need to
manually add {{--enable-ssh-agent}} and just test for whether
{{LIBSSH2_CALLBACK_AUTHAGENT}} is declared.
(Correction: Agent forwarding is _not_ part of libssh2 1.10.0. It's part of
libssh2 1.11.0.)
was (Author: mike.jumper):
I think this also depended on a patched version of libssh2 that had more broad
SSH agent support via a {{LIBSSH2_CALLBACK_AUTH_AGENT}} callback which
otherwise does not exist in libssh2. It looks like something along these lines
was added via:
https://github.com/libssh2/libssh2/commit/bc4e619e76071393e466c29220fc4ef5764c2820
which is indeed part of libssh2 1.11.0. I'm not sure whether there are
additional code changes necessary beyond simply switching from
{{LIBSSH2_CALLBACK_AUTH_AGENT}} to {{LIBSSH2_CALLBACK_AUTHAGENT}}. If things do
work now without patching libssh2, we can probably get rid of the need to
manually add {{--enable-ssh-agent}} and just test for whether
{{LIBSSH2_CALLBACK_AUTHAGENT}} is declared.
(Correction: Agent forwarding is _not _ part of libssh2 1.10.0. It's part of
libssh2 1.11.0.)
> Unable to compile guacamole server with --enable-ssh-agent
> --
>
> Key: GUACAMOLE-1658
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1658
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Affects Versions: 1.4.0
> Environment: Rocky Linux 8.6 on x64, the latest libssh2 from remi
> repository, guacamole server version 1.4.0.
>Reporter: Pavel Kuzel
>Assignee: Nick Couchman
>Priority: Minor
> Labels: guacamole-server, ssh-agent
> Fix For: 1.5.4
>
>
> Hello there,
> a compilation of guacamole-server on Rocky Linux 8.6 with
> "--enable-ssh-agent" fails on the missing ssh_key.h header file. Please see
> the detail below:
> _make[2]: Entering directory
> '/home/guacamole/guacamole-server/src/protocols/ssh'_
> _CC libguac_client_ssh_la-argv.lo_
> _In file included from ssh.h:33,_
> _from argv.c:22:_
> _ssh_agent.h:26:10: fatal error: ssh_key.h: No such file or directory_
> _#include "ssh_key.h"_
> _^~~_
> _compilation terminated._
> Just for the record, I use the latest version of libssh2 (1.10.0) and I'd
> like to use the agent forwarding functionality within the guacamole server.
> Is there any way how to get it running in the current version of
> guacamole-server?
> Regards,
> Pavel
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-1658) Unable to compile guacamole server with --enable-ssh-agent
[
https://issues.apache.org/jira/browse/GUACAMOLE-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788214#comment-17788214
]
Mike Jumper commented on GUACAMOLE-1658:
I think this also depended on a patched version of libssh2 that had more broad
SSH agent support via a {{LIBSSH2_CALLBACK_AUTH_AGENT}} callback which
otherwise does not exist in libssh2. It looks like something along these lines
was added via:
https://github.com/libssh2/libssh2/commit/bc4e619e76071393e466c29220fc4ef5764c2820
which is indeed part of libssh2 1.10.0. I'm not sure whether there are
additional code changes necessary beyond simply switching from
{{LIBSSH2_CALLBACK_AUTH_AGENT}} to {{LIBSSH2_CALLBACK_AUTHAGENT}}. If things do
work now without patching libssh2, we can probably get rid of the need to
manually add {{--enable-ssh-agent}} and just test for whether
{{LIBSSH2_CALLBACK_AUTHAGENT}} is declared.
> Unable to compile guacamole server with --enable-ssh-agent
> --
>
> Key: GUACAMOLE-1658
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1658
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-server
>Affects Versions: 1.4.0
> Environment: Rocky Linux 8.6 on x64, the latest libssh2 from remi
> repository, guacamole server version 1.4.0.
>Reporter: Pavel Kuzel
>Assignee: Nick Couchman
>Priority: Minor
> Labels: guacamole-server, ssh-agent
> Fix For: 1.5.4
>
>
> Hello there,
> a compilation of guacamole-server on Rocky Linux 8.6 with
> "--enable-ssh-agent" fails on the missing ssh_key.h header file. Please see
> the detail below:
> _make[2]: Entering directory
> '/home/guacamole/guacamole-server/src/protocols/ssh'_
> _CC libguac_client_ssh_la-argv.lo_
> _In file included from ssh.h:33,_
> _from argv.c:22:_
> _ssh_agent.h:26:10: fatal error: ssh_key.h: No such file or directory_
> _#include "ssh_key.h"_
> _^~~_
> _compilation terminated._
> Just for the record, I use the latest version of libssh2 (1.10.0) and I'd
> like to use the agent forwarding functionality within the guacamole server.
> Is there any way how to get it running in the current version of
> guacamole-server?
> Regards,
> Pavel
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1867) Add libguac convenience functions for memory management
[
https://issues.apache.org/jira/browse/GUACAMOLE-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper closed GUACAMOLE-1867.
--
Resolution: Done
> Add libguac convenience functions for memory management
> ---
>
> Key: GUACAMOLE-1867
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1867
> Project: Guacamole
> Issue Type: Wish
> Components: libguac
>Reporter: Mike Jumper
>Assignee: Mike Jumper
>Priority: Minor
> Fix For: 1.5.4
>
>
> As it's common throughout the Guacamole codebase to need to allocate memory
> involving multiple factors, such as width/stride, height, and bytes per
> pixel, or bits per sample, samples per second, and seconds per packet, it
> would be nice to provide convenience functions that make these allocations
> and associated calculations easy and verifiable.
> Adding our own memory allocation functions would also allow us to smooth over
> platform-specific behavior of {{malloc()}} / {{calloc()}}, would allow for
> easy insertion of headers/footers around memory blocks if necessary for
> memory debugging, etc., and would open up the possibility of additional
> safeguards and sanity checks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1859) Update webapp dependencies to latest stable and compatible versions
[ https://issues.apache.org/jira/browse/GUACAMOLE-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper closed GUACAMOLE-1859. -- Resolution: Done > Update webapp dependencies to latest stable and compatible versions > --- > > Key: GUACAMOLE-1859 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1859 > Project: Guacamole > Issue Type: Task > Components: guacamole-client >Affects Versions: 1.5.4 >Reporter: Mike Jumper >Assignee: Mike Jumper >Priority: Minor > Fix For: 1.5.4 > > > Some Guacamole dependencies have updates available. As part of our usual > release housekeeping, these dependencies should be updated if doing so does > not break things. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (GUACAMOLE-1885) Add result paging support to LDAP auth extension
[ https://issues.apache.org/jira/browse/GUACAMOLE-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Jumper closed GUACAMOLE-1885. -- Resolution: Duplicate > Add result paging support to LDAP auth extension > > > Key: GUACAMOLE-1885 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1885 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-auth-ldap >Affects Versions: 1.5.3 >Reporter: sbcbus >Priority: Minor > > We as a group have run into the max groups of 1000 via default Active > Directory settings (via > https://docs.libraesva.com/knowledgebase/ldap-query-returns-only-1000-entries-and-ldap-sync-return-error-sizelimit-exceeded/ > ), despite having filters as much as has been easily feasible. Despite the > ldap-max-search-results Guacamole setting, we still are reliant on the LDAP > server restrictions as well. > Not everyone can or will get permission to adjust the default paging at an > LDAP level, so I would love to see paging support used in Guacamole as it > will still retrieve all results and is already supported by Apache LDAP. > https://nightlies.apache.org/directory/api/2.0.1/apidocs/org/apache/directory/api/ldap/model/message/controls/PagedResults.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
