[jira] [Updated] (GUACAMOLE-765) Guacamole Client hangs on Deployment when loading JSR-356 WebSocket Support
[
https://issues.apache.org/jira/browse/GUACAMOLE-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Nohn updated GUACAMOLE-765:
-
Environment:
Ubuntu 18.04.2 LTS
dpkg -l | egrep "(tomcat|java|jdk)"
ii ca-certificates-java 20180516ubuntu1~18.04.1
all Common CA certificates (JKS keystore)
ii java-common0.63ubuntu1~02
all Base package for Java runtimes
ii libatk-wrapper-java0.33.3-20ubuntu0.1
all ATK implementation for Java using JNI
ii libatk-wrapper-java-jni:amd64 0.33.3-20ubuntu0.1
amd64ATK implementation for Java using JNI (JNI bindings)
ii libcommons-collections3-java 3.2.2-1
all Apache Commons Collections - Extended Collections API for Java
ii libcommons-dbcp-java 1.4-5ubuntu2
all Database Connection Pooling Services
ii libcommons-pool-java 1.6-3
all pooling implementation for Java objects
ii libecj-java3.13.3-1
all Eclipse Java compiler (library)
ii libtomcat8-java8.5.30-1ubuntu1.4
all Apache Tomcat 8 - Servlet and JSP engine -- core libraries
ii openjdk-11-jdk:amd64 10.0.2+13-1ubuntu0.18.04.4
amd64OpenJDK Development Kit (JDK)
ii openjdk-11-jdk-headless:amd64 10.0.2+13-1ubuntu0.18.04.4
amd64OpenJDK Development Kit (JDK) (headless)
ii openjdk-11-jre:amd64 10.0.2+13-1ubuntu0.18.04.4
amd64OpenJDK Java runtime, using Hotspot JIT
ii openjdk-11-jre-headless:amd64 10.0.2+13-1ubuntu0.18.04.4
amd64OpenJDK Java runtime, using Hotspot JIT (headless)
ii tomcat88.5.30-1ubuntu1.4
all Apache Tomcat 8 - Servlet and JSP engine
ii tomcat8-common 8.5.30-1ubuntu1.4
all Apache Tomcat 8 - Servlet and JSP engine -- common files
was:
Ubuntu 18.04.2 LTS
{code}
dpkg -l | egrep "(tomcat|java|jdk)"
ii ca-certificates-java 20180516ubuntu1~18.04.1
all Common CA certificates (JKS keystore)
ii java-common0.63ubuntu1~02
all Base package for Java runtimes
ii libatk-wrapper-java0.33.3-20ubuntu0.1
all ATK implementation for Java using JNI
ii libatk-wrapper-java-jni:amd64 0.33.3-20ubuntu0.1
amd64ATK implementation for Java using JNI (JNI bindings)
ii libcommons-collections3-java 3.2.2-1
all Apache Commons Collections - Extended Collections API for Java
ii libcommons-dbcp-java 1.4-5ubuntu2
all Database Connection Pooling Services
ii libcommons-pool-java 1.6-3
all pooling implementation for Java objects
ii libecj-java3.13.3-1
all Eclipse Java compiler (library)
ii libtomcat8-java8.5.30-1ubuntu1.4
all Apache Tomcat 8 - Servlet and JSP engine -- core libraries
ii openjdk-11-jdk:amd64 10.0.2+13-1ubuntu0.18.04.4
amd64OpenJDK Development Kit (JDK)
ii openjdk-11-jdk-headless:amd64 10.0.2+13-1ubuntu0.18.04.4
amd64OpenJDK Development Kit (JDK) (headless)
ii openjdk-11-jre:amd64 10.0.2+13-1ubuntu0.18.04.4
amd64OpenJDK Java runtime, using Hotspot JIT
ii openjdk-11-jre-headless:amd64 10.0.2+13-1ubuntu0.18.04.4
amd64OpenJDK Java runtime, using Hotspot JIT (headless)
ii tomcat88.5.30-1ubuntu1.4
all Apache Tomcat 8 - Servlet and JSP engine
ii tomcat8-common 8.5.30-1ubuntu1.4
all Apache Tomcat 8 - Servlet and JSP engine -- common files{code}
> Guacamole Client hangs on Deployment when loading JSR-356 WebSocket Support
> ---
>
> Key: GUACAMOLE-765
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-765
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-client
>Affects Versions: 1.0.0
> Environment:
[jira] [Closed] (GUACAMOLE-765) Guacamole Client hangs on Deployment when loading JSR-356 WebSocket Support
[
https://issues.apache.org/jira/browse/GUACAMOLE-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman closed GUACAMOLE-765.
---
Resolution: Invalid
> Guacamole Client hangs on Deployment when loading JSR-356 WebSocket Support
> ---
>
> Key: GUACAMOLE-765
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-765
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-client
>Affects Versions: 1.0.0
> Environment: Ubuntu 18.04.2 LTS
> dpkg -l | egrep "(tomcat|java|jdk)"
> ii ca-certificates-java 20180516ubuntu1~18.04.1
> all Common CA certificates (JKS keystore)
> ii java-common0.63ubuntu1~02
> all Base package for Java runtimes
> ii libatk-wrapper-java0.33.3-20ubuntu0.1
> all ATK implementation for Java using JNI
> ii libatk-wrapper-java-jni:amd64 0.33.3-20ubuntu0.1
> amd64ATK implementation for Java using JNI (JNI bindings)
> ii libcommons-collections3-java 3.2.2-1
> all Apache Commons Collections - Extended Collections API for
> Java
> ii libcommons-dbcp-java 1.4-5ubuntu2
> all Database Connection Pooling Services
> ii libcommons-pool-java 1.6-3
> all pooling implementation for Java objects
> ii libecj-java3.13.3-1
> all Eclipse Java compiler (library)
> ii libtomcat8-java8.5.30-1ubuntu1.4
> all Apache Tomcat 8 - Servlet and JSP engine -- core libraries
> ii openjdk-11-jdk:amd64 10.0.2+13-1ubuntu0.18.04.4
> amd64OpenJDK Development Kit (JDK)
> ii openjdk-11-jdk-headless:amd64 10.0.2+13-1ubuntu0.18.04.4
> amd64OpenJDK Development Kit (JDK) (headless)
> ii openjdk-11-jre:amd64 10.0.2+13-1ubuntu0.18.04.4
> amd64OpenJDK Java runtime, using Hotspot JIT
> ii openjdk-11-jre-headless:amd64 10.0.2+13-1ubuntu0.18.04.4
> amd64OpenJDK Java runtime, using Hotspot JIT (headless)
> ii tomcat88.5.30-1ubuntu1.4
> all Apache Tomcat 8 - Servlet and JSP engine
> ii tomcat8-common 8.5.30-1ubuntu1.4
> all Apache Tomcat 8 - Servlet and JSP engine -- common files
>Reporter: Sebastian Nohn
>Priority: Minor
>
> Hangs forever on
> {code}24-Mar-2019 12:36:23.199 INFO [localhost-startStop-1]
> org.apache.catalina.startup.HostConfig.deployWAR Deploying web application
> archive [/var/lib/tomcat8/webapps/guacamole.war]
> 24-Mar-2019 12:36:28.952 INFO [localhost-startStop-1]
> org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned
> for TLDs yet contained no TLDs. Enable debug logging for this logger for a
> complete list of JARs that were scanned but no TLDs were found in them.
> Skipping unneeded JARs during scanning can improve startup time and JSP
> compilation time.
> 12:36:30.375 [localhost-startStop-1] INFO o.a.g.environment.LocalEnvironment
> - GUACAMOLE_HOME is "/etc/guacamole".
> 12:36:30.394 [localhost-startStop-1] INFO o.a.g.environment.LocalEnvironment
> - No guacamole.properties file found within GUACAMOLE_HOME or the classpath.
> Using defaults.
> 12:36:30.732 [localhost-startStop-1] INFO
> o.a.g.rest.auth.HashTokenSessionMap - Sessions will expire after 60 minutes
> of inactivity.
> 12:36:30.974 [localhost-startStop-1] INFO org.apache.guacamole.log.LogModule
> - Loading logback configuration from "/etc/guacamole/logback.xml".
> 12:36:31.153 [localhost-startStop-1] DEBUG o.a.g.e.LanguageResourceService -
> Added language: "nl"
> 12:36:31.156 [localhost-startStop-1] DEBUG o.a.g.e.LanguageResourceService -
> Added language: "en"
> 12:36:31.158 [localhost-startStop-1] DEBUG o.a.g.e.LanguageResourceService -
> Added language: "fr"
> 12:36:31.159 [localhost-startStop-1] DEBUG o.a.g.e.LanguageResourceService -
> Added language: "ru"
> 12:36:31.159 [localhost-startStop-1] DEBUG o.a.g.e.LanguageResourceService -
> Added language: "de"
> 12:36:31.160 [localhost-startStop-1] DEBUG o.a.g.e.LanguageResourceService -
> Added language: "no"
> 12:36:31.160 [localhost-startStop-1] DEBUG o.a.g.e.LanguageResourceService -
> Added language: "es"
> 12:36:31.160 [localhost-startStop-1] DEBUG o.a.g.e.LanguageResourceService -
> Added language: "it"
> 12:36:31.168 [localhost-startStop-1]
[jira] [Created] (GUACAMOLE-766) Allow JDBC URI Configuration
Nick Couchman created GUACAMOLE-766: --- Summary: Allow JDBC URI Configuration Key: GUACAMOLE-766 URL: https://issues.apache.org/jira/browse/GUACAMOLE-766 Project: Guacamole Issue Type: Improvement Components: guacamole-auth-jdbc-mysql, guacamole-auth-jdbc-postgresql, guacamole-auth-jdbc-sqlserver Reporter: Nick Couchman Particularly with the pending addition of the URIGuacamoleProperty in GUACAMOLE-678, it would be nice to be able to have the JDBC modules configured via a URI rather than individual parameters. This is reasonably common in other software packages that connect to a database, and might make configuration of Guacamole both simpler and more flexible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GUACAMOLE-766) Allow JDBC URI Configuration
[ https://issues.apache.org/jira/browse/GUACAMOLE-766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman reassigned GUACAMOLE-766: --- Assignee: Nick Couchman > Allow JDBC URI Configuration > > > Key: GUACAMOLE-766 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-766 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-auth-jdbc-mysql, > guacamole-auth-jdbc-postgresql, guacamole-auth-jdbc-sqlserver >Reporter: Nick Couchman >Assignee: Nick Couchman >Priority: Minor > > Particularly with the pending addition of the URIGuacamoleProperty in > GUACAMOLE-678, it would be nice to be able to have the JDBC modules > configured via a URI rather than individual parameters. This is reasonably > common in other software packages that connect to a database, and might make > configuration of Guacamole both simpler and more flexible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GUACAMOLE-694) guacd docker container can't validate RDP certificate
[
https://issues.apache.org/jira/browse/GUACAMOLE-694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman resolved GUACAMOLE-694.
-
Resolution: Fixed
Package ca-certificates has been added to build.
> guacd docker container can't validate RDP certificate
> -
>
> Key: GUACAMOLE-694
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-694
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-docker
>Affects Versions: 1.0.0
>Reporter: Andrin
>Assignee: Nick Couchman
>Priority: Minor
> Fix For: 1.1.0
>
>
> The guacd docker container marks my certificate as invalid:
> {code:java}
> guacd[5]: INFO: Guacamole proxy daemon (guacd) version 1.0.0 started
> guacd[5]: INFO: Listening on host 0.0.0.0, port 4822
> guacd[5]: INFO: Creating new client for protocol "rdp"
> guacd[5]: INFO: Connection ID is "$8791f12e-0d99-4aac-8ddf-b893c60e387c"
> guacd[7]: INFO: Security mode: ANY
> guacd[7]: INFO: Resize method: display-update
> guacd[7]: INFO: User "@4dae41b2-c439-4175-9543-39509c737706" joined
> connection "$8791f12e-0d99-4aac-8ddf-b893c60e387c" (1 users now present)
> guacd[7]: INFO: Loading keymap "base"
> guacd[7]: INFO: Loading keymap "en-us-qwerty"
> connected to winpc.[domainname].com:3389
> creating directory /root/.config/freerdp
> creating directory /root/.config/freerdp/certs
> creating directory /root/.config/freerdp/server
> certificate_store_open: error opening [/root/.config/freerdp/known_hosts] for
> writing
> guacd[7]: INFO: Certificate validation failed
> tls_connect: certificate not trusted, aborting.
> Error: protocol security negotiation or connection failure
> guacd[7]: ERROR:Error connecting to RDP server
> guacd[7]: INFO: User "@4dae41b2-c439-4175-9543-39509c737706" disconnected (0
> users remain)
> guacd[7]: INFO: Last user of connection
> "$8791f12e-0d99-4aac-8ddf-b893c60e387c" disconnected
> {code}
> However when connected via Windows & Mac client the certificate is shown as
> valid. The same with an Centos 7 installation with OpenSSL:
> {code:java}
> # openssl s_client -showcerts -connect winpc.[domainname].com:3389
> CONNECTED(0003)
> depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited,
> CN = COMODO RSA Certification Authority
> verify return:1
> depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited,
> CN = COMODO RSA Domain Validation Secure Server CA
> verify return:1
> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN =
> winpc.[domainname].com
> verify return:1
> ---
> Certificate chain
> 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=winpc.[domainname].com
>i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA
> Domain Validation Secure Server CA
> -BEGIN CERTIFICATE-
> [Cert Data]
> -END CERTIFICATE-
> 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA
> Domain Validation Secure Server CA
>i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA
> Certification Authority
> -BEGIN CERTIFICATE-
> [Cert Data]
> -END CERTIFICATE-
> ---
> Server certificate
> subject=/OU=Domain Control Validated/OU=PositiveSSL/CN=winpc.[domainname].com
> issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO
> RSA Domain Validation Secure Server CA
> ---
> No client certificate CA names sent
> Peer signing digest: SHA256
> Server Temp Key: ECDH, P-384, 384 bits
> ---
> SSL handshake has read 4333 bytes and written 447 bytes
> ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
> Server public key is 4096 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
> Protocol : TLSv1.2
> Cipher: ECDHE-RSA-AES256-GCM-SHA384
> Session-ID:
> 0131F93A78635295B0F5A5458E9AEC16BF70B72E28052D201B6B8DE6661B
> Session-ID-ctx:
> Master-Key:
> FFFDC45C96C282A330BF878272FD243783425508ED6CB43492C127431492B04089AC8630E509B42DD909DF042286F913
> Key-Arg : None
> Krb5 Principal: None
> PSK identity: None
> PSK identity hint: None
> Start Time: 1547126917
> Timeout : 300 (sec)
> Verify return code: 0 (ok)
> ---
> {code}
> I assume that the ca-certificates package inside the container is missing:
> {code:java}
> root@a218bfbd187e:/# dpkg -l | grep cert
> root@a218bfbd187e:/#
> root@a218bfbd187e:/# ls /etc/ssl/certs/
> ls: cannot access '/etc/ssl/certs/': No such file or directory
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
