Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]
Hi Mike,
I appreciate your efforts. I will be more diligent and do more debugging
and testing before reporting any bug on JIRA.
Thanks Mike for helping and guiding me out.
I have done the following changes :-
guac_rdpdr_send_client_name_request(rdpdr, "Guacamole RDP"); to
guac_rdpdr_send_client_name_request(rdpdr, "Cloud Storage"); in
*rdpdr_messages.c*
*and *
*/***
* * Name of the filesystem.*
* */*
*#define GUAC_FILESYSTEM_NAME "G\0u\0a\0c\0a\0m\0o\0l\0e\0\0\0"*
*#define GUAC_FILESYSTEM_NAME_LENGTH 20*
*/***
* * Label of the filesystem.*
* */*
*#define GUAC_FILESYSTEM_LABEL "G\0U\0A\0C\0F\0I\0L\0E\0"*
*#define GUAC_FILESYSTEM_LABEL_LENGTH 16*
to
*/***
* * Name of the filesystem.*
* */*
*#define GUAC_FILESYSTEM_NAME "C\0L\0O\0U\0D\0\0\0"*
*#define GUAC_FILESYSTEM_NAME_LENGTH 12*
*/***
* * Label of the filesystem.*
* */*
*#define GUAC_FILESYSTEM_LABEL "C\0L\0O\0U\0D\0"*
*#define GUAC_FILESYSTEM_LABEL_LENGTH 10*
> *So you have apparently changed the UTF-16 string
> ("G\0u\0a\0c\0a\0m\0o\0l\0e\0\0\0") to something which is not encoded in
> UTF-16 ("ClouStorage"). Because RDP requires this to be UTF-16, it
> interprets it as such.*
Where do I have to encode it ?
Is there anything else I have to do along with the above.
Thanks and Regards,
Amarjeet Singh
On Fri, Feb 23, 2018 at 6:35 AM, Mike Jumper
wrote:
> On Thu, Feb 22, 2018 at 4:35 PM, Mike Jumper
> wrote:
>
>> ...
>>
>> ... the name of the redirected drive is not correct. ... NOTE : - I have
>>> changed the name of the drive from Guacamole to Cloud Drive in
>>> guacamole-server [ Is it is the reason ? ]
>>>
>>
>> Yes. You have changed the name from a correctly-encoded value to
>> something which is not correctly encoded.
>>
>>
> FYI, regarding your modifications, your screenshot shows the following
> text:
>
> 汃畯瑓牯条e
>
> Breaking that down as Unicode, we get:
>
> U+6C43 = 汃
> U+756F = 畯
> U+7453 = 瑓
> U+726F = 牯
> U+6761 = 条
> U+0065 = e
>
> The UTF-16 equivalent for this in the byte order used by RDP would be:
>
> 43 6C 6F 75 53 74 6F 72 61 67 65 00
>
> Which is the equivalent of the string:
>
> "ClouStorage"
>
> So you have apparently changed the UTF-16 string
> ("G\0u\0a\0c\0a\0m\0o\0l\0e\0\0\0") to something which is not encoded in
> UTF-16 ("ClouStorage"). Because RDP requires this to be UTF-16, it
> interprets it as such.
>
> - Mike
>
>
AW: LDAP Auth error
Hi Ok i solved by myselve when pulling the docker image from guacamole/gaucamole instead of mjumper/guacamole rg Christian Christian Kraus Inhaber CKC IT Consulting & Solutions e.U. Kirschenallee 22 2120 OBERSDORF Österreich Telefon: +43 (0) 680 2062952 Fax:+43 820 220262992 E-mail: christian.kr...@ckc-it.at -Ursprüngliche Nachricht- Von: Mike Jumper Gesendet: Freitag 23 Februar 2018 00:56 An: user@guacamole.apache.org Betreff: Re: LDAP Auth error On Thu, Feb 22, 2018 at 1:02 PM, Christian Kraus mailto:christian.kr...@ckc-it.at> > wrote: Hi, I'm getting the following error on version 0.9.14 with ldap backend: INFO o.a.g.r.auth.AuthenticationService - User "administrator" successfully authenticated from [192.168.10.12, 172.17.42.1]. 20:51:20.129 [http-nio-8080-exec-5] ERROR o.a.g.rest.RESTExceptionWrapper - Unexpected internal error: org.apache.guacamole.auth.ldap.LDAPAuthenticationProvider.decorate(Lorg/apache/guacamole/net/auth/UserContext;Lorg/apache/guacamole/net/auth/AuthenticatedUser;Lorg/apache/guacamole/net/auth/Credentials;)Lorg/apache/guacamole/net/auth/UserContext; 22-Feb-2018 20:51:20.130 SEVERE [http-nio-8080-exec-5] com.sun.jersey.spi.container.ContainerResponse.logException Mapped exception to response: 500 (Internal Server Error) org.apache.guacamole.rest.APIException Are you mixing builds from git with 0.9.14 release binaries? The decorate() function referenced here is a recent addition to the API and was not part of 0.9.14. Though the version number displayed within git will still say "0.9.14" (version numbers are not bumped until immediately before release), the extension API on git is not compatible with the version of the API present in the actual 0.9.14 release. - Mike
AW: LDAP Auth error
I did a pull of the docker images from mjumper/guacamole and the auth file from https://guacamole.apache.org/releases/0.9.14/ is this wrong ? Where should i download the auth file ? rg Christian Christian Kraus Inhaber CKC IT Consulting & Solutions e.U. Kirschenallee 22 2120 OBERSDORF Österreich Telefon: +43 (0) 680 2062952 Fax:+43 820 220262992 E-mail: christian.kr...@ckc-it.at -Ursprüngliche Nachricht- Von: Mike Jumper Gesendet: Freitag 23 Februar 2018 00:56 An: user@guacamole.apache.org Betreff: Re: LDAP Auth error On Thu, Feb 22, 2018 at 1:02 PM, Christian Kraus mailto:christian.kr...@ckc-it.at> > wrote: Hi, I'm getting the following error on version 0.9.14 with ldap backend: INFO o.a.g.r.auth.AuthenticationService - User "administrator" successfully authenticated from [192.168.10.12, 172.17.42.1]. 20:51:20.129 [http-nio-8080-exec-5] ERROR o.a.g.rest.RESTExceptionWrapper - Unexpected internal error: org.apache.guacamole.auth.ldap.LDAPAuthenticationProvider.decorate(Lorg/apache/guacamole/net/auth/UserContext;Lorg/apache/guacamole/net/auth/AuthenticatedUser;Lorg/apache/guacamole/net/auth/Credentials;)Lorg/apache/guacamole/net/auth/UserContext; 22-Feb-2018 20:51:20.130 SEVERE [http-nio-8080-exec-5] com.sun.jersey.spi.container.ContainerResponse.logException Mapped exception to response: 500 (Internal Server Error) org.apache.guacamole.rest.APIException Are you mixing builds from git with 0.9.14 release binaries? The decorate() function referenced here is a recent addition to the API and was not part of 0.9.14. Though the version number displayed within git will still say "0.9.14" (version numbers are not bumped until immediately before release), the extension API on git is not compatible with the version of the API present in the actual 0.9.14 release. - Mike
Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]
On Thu, Feb 22, 2018 at 4:35 PM, Mike Jumper
wrote:
> ...
>
> ... the name of the redirected drive is not correct. ... NOTE : - I have
>> changed the name of the drive from Guacamole to Cloud Drive in
>> guacamole-server [ Is it is the reason ? ]
>>
>
> Yes. You have changed the name from a correctly-encoded value to something
> which is not correctly encoded.
>
>
FYI, regarding your modifications, your screenshot shows the following text:
汃畯瑓牯条e
Breaking that down as Unicode, we get:
U+6C43 = 汃
U+756F = 畯
U+7453 = 瑓
U+726F = 牯
U+6761 = 条
U+0065 = e
The UTF-16 equivalent for this in the byte order used by RDP would be:
43 6C 6F 75 53 74 6F 72 61 67 65 00
Which is the equivalent of the string:
"ClouStorage"
So you have apparently changed the UTF-16 string
("G\0u\0a\0c\0a\0m\0o\0l\0e\0\0\0") to something which is not encoded in
UTF-16 ("ClouStorage"). Because RDP requires this to be UTF-16, it
interprets it as such.
- Mike
Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]
On Thu, Feb 22, 2018 at 6:30 AM, Amarjeet Singh wrote: > Hi Mike, > > Amarjeet, please avoid duplicating your threads across multiple locations. Emailing both JIRA and the user@ list creates both a comment in JIRA and a new thread on user@. ... the name of the redirected drive is not correct. ... NOTE : - I have > changed the name of the drive from Guacamole to Cloud Drive in > guacamole-server [ Is it is the reason ? ] > Yes. You have changed the name from a correctly-encoded value to something which is not correctly encoded. Amarjeet ... please try to be more diligent. The verification which was ultimately done on GUACAMOLE-512 (the verification that revealed the problem was not in Guacamole) is something that should have been done before the issue was opened in the first place. This goes double if you have made modifications to the source: if you wish to report a problem with Guacamole, you need to actually be using Guacamole, not your own modified software. - Mike
Re: LDAP Auth error
On Thu, Feb 22, 2018 at 1:02 PM, Christian Kraus wrote: > Hi, > > > I'm getting the following error on version 0.9.14 with ldap backend: > > > INFO o.a.g.r.auth.AuthenticationService - User "administrator" > successfully authenticated from [192.168.10.12, 172.17.42.1]. > 20:51:20.129 [http-nio-8080-exec-5] ERROR o.a.g.rest.RESTExceptionWrapper > - Unexpected internal error: org.apache.guacamole.auth.ldap. > LDAPAuthenticationProvider.decorate(Lorg/apache/guacamole/net/auth/ > UserContext;Lorg/apache/guacamole/net/auth/AuthenticatedUser;Lorg/apache/ > guacamole/net/auth/Credentials;)Lorg/apache/guacamole/net/auth/ > UserContext; > 22-Feb-2018 20:51:20.130 SEVERE [http-nio-8080-exec-5] > com.sun.jersey.spi.container.ContainerResponse.logException Mapped > exception to response: 500 (Internal Server Error) > org.apache.guacamole.rest.APIException > > > Are you mixing builds from git with 0.9.14 release binaries? The decorate() function referenced here is a recent addition to the API and was not part of 0.9.14. Though the version number displayed within git will still say "0.9.14" (version numbers are not bumped until immediately before release), the extension API on git is not compatible with the version of the API present in the actual 0.9.14 release. - Mike
Re: printing issues (non-ASCII job name)
Excellent. Good to know. When you determine what specifically is wrong with your Nginx settings, please be sure to post your findings here. It would be beneficial to other users who encounter the same issues. - Mike On Thu, Feb 22, 2018 at 1:35 PM, Евгений Н. Жуков wrote: > Yep, I'm already found, the problem is in nginx settings. Directly with > tomcat works fine. > > 2018-02-23 0:32 GMT+03:00 Mike Jumper : > >> On Thu, Feb 22, 2018 at 12:39 PM, Евгений Н. Жуков < >> eugene.zhu...@gmail.com> wrote: >> >>> Yes, tried nginx and apache2 >>> >>> >> Have you tried connecting to Tomcat directly, to eliminate proxy >> configuration as a possible cause? >> >> - Mike >> >> > > > -- > Евгений Жуков > +79534155676 <+7%20953%20415-56-76> skype: xrt_nn >
Re: printing issues (non-ASCII job name)
Yep, I'm already found, the problem is in nginx settings. Directly with tomcat works fine. 2018-02-23 0:32 GMT+03:00 Mike Jumper : > On Thu, Feb 22, 2018 at 12:39 PM, Евгений Н. Жуков < > eugene.zhu...@gmail.com> wrote: > >> Yes, tried nginx and apache2 >> >> > Have you tried connecting to Tomcat directly, to eliminate proxy > configuration as a possible cause? > > - Mike > > -- Евгений Жуков +79534155676 skype: xrt_nn
Re: printing issues (non-ASCII job name)
On Thu, Feb 22, 2018 at 12:39 PM, Евгений Н. Жуков wrote: > Yes, tried nginx and apache2 > > Have you tried connecting to Tomcat directly, to eliminate proxy configuration as a possible cause? - Mike
LDAP Auth error
Hi, I'm getting the following error on version 0.9.14 with ldap backend: INFO o.a.g.r.auth.AuthenticationService - User "administrator" successfully authenticated from [192.168.10.12, 172.17.42.1]. 20:51:20.129 [http-nio-8080-exec-5] ERROR o.a.g.rest.RESTExceptionWrapper - Unexpected internal error: org.apache.guacamole.auth.ldap.LDAPAuthenticationProvider.decorate(Lorg/apache/guacamole/net/auth/UserContext;Lorg/apache/guacamole/net/auth/AuthenticatedUser;Lorg/apache/guacamole/net/auth/Credentials;)Lorg/apache/guacamole/net/auth/UserContext; 22-Feb-2018 20:51:20.130 SEVERE [http-nio-8080-exec-5] com.sun.jersey.spi.container.ContainerResponse.logException Mapped exception to response: 500 (Internal Server Error) org.apache.guacamole.rest.APIException does anyone have a hint for me what the source of this can be ? rg Christian Christian Kraus Inhaber CKC IT Consulting & Solutions e.U. Kirschenallee 22 2120 OBERSDORF Österreich Telefon: +43 (0) 680 2062952 Fax:+43 820 220262992 E-mail: christian.kr...@ckc-it.at
Re: printing issues (non-ASCII job name)
Yes, tried nginx and apache2 x.x.x.x - - [22/Feb/2018:23:35:16 +0300] "GET /api/session/tunnels/21ab8066-0e7d-4085-bf26-7ff9fb6aa9f9/streams/0/%3CD2E0E1EBE8F7EDFBE920E4EEEAF3ECE5EDF2%3E.pdf?token=DF441F3D3B8197AC78AD677CC1DFCC5FCE5899FAE829A76F18AE30BEF28CD6C4 HTTP/1.1" 400 5 "https://nr34.com/"; "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36" "-" 2018-02-22 23:25 GMT+03:00 Mike Jumper : > All parts of the download URL should be correctly encoded: > > https://github.com/apache/guacamole-client/blob/0.9.14/ > guacamole/src/main/webapp/app/rest/services/tunnelService.js#L192-L198 > > Are you able to grab the HTTP request that's failing (ie: from the Tomcat > access logs)? It should be a GET request with "api/session/tunnels/" and > "/streams/" within the path. > > Is there any sort of proxy between your browser and Tomcat which might be > handling the request incorrectly? > > - Mike > > > On Thu, Feb 22, 2018 at 12:04 PM, Евгений Н. Жуков < > eugene.zhu...@gmail.com> wrote: > >> I found error out catalina.out during printing nonASCII job >> >> Feb 22, 2018 11:02:02 PM org.apache.coyote.http11.AbstractHttp11Processor >> process >> INFO: Error parsing HTTP request header >> Note: further occurrences of HTTP header parsing errors will be logged >> at DEBUG level. >> java.lang.IllegalArgumentException: Invalid character found in the >> request target. The valid characters are defined in RFC 7230 and RFC 3986 >> at org.apache.coyote.http11.InternalInputBuffer.parseRequestLin >> e(InternalInputBuffer.java:189) >> at org.apache.coyote.http11.AbstractHttp11Processor.process(Abs >> tractHttp11Processor.java:1028) >> at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler >> .process(AbstractProtocol.java:637) >> at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run( >> JIoEndpoint.java:316) >> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool >> Executor.java:1142) >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo >> lExecutor.java:617) >> at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable. >> run(TaskThread.java:61) >> at java.lang.Thread.run(Thread.java:748) >> >> >> 2018-02-22 22:51 GMT+03:00 Евгений Н. Жуков : >> >>> Just inzip an old vm with debian & 0.9.10 , in this version printing >>> with nonASCII job name works fine. >>> >>> 2018-02-22 22:49 GMT+03:00 Евгений Н. Жуков : >>> This issue from 0.9.12. In server.xml uriencoding already set to UTF8 2018-02-22 22:43 GMT+03:00 Mike Jumper : > Assuming you are using Tomcat, please verify that the following is set > on the applicable connector in your server.xml: > > URIEncoding="UTF-8" > > See: > > https://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8 > > - Mike > > > On Feb 22, 2018 11:35, "Евгений Н. Жуков" > wrote: > >> Hi, just installed latest version, and got old problem. If printing >> job has non-ASCII symbols (for example russians characters) the job >> stucks >> in printing queue, or I getting empty pdf file. >> >> >> -- >> Евгений Жуков >> +79534155676 <+7%20953%20415-56-76> skype: xrt_nn >> > -- Евгений Жуков +79534155676 <+7%20953%20415-56-76> skype: xrt_nn >>> >>> >>> >>> -- >>> Евгений Жуков >>> +79534155676 <+7%20953%20415-56-76> skype: xrt_nn >>> >> >> >> >> -- >> Евгений Жуков >> +79534155676 <+7%20953%20415-56-76> skype: xrt_nn >> > > -- Евгений Жуков +79534155676 skype: xrt_nn
Re: printing issues (non-ASCII job name)
All parts of the download URL should be correctly encoded: https://github.com/apache/guacamole-client/blob/0.9.14/guacamole/src/main/webapp/app/rest/services/tunnelService.js#L192-L198 Are you able to grab the HTTP request that's failing (ie: from the Tomcat access logs)? It should be a GET request with "api/session/tunnels/" and "/streams/" within the path. Is there any sort of proxy between your browser and Tomcat which might be handling the request incorrectly? - Mike On Thu, Feb 22, 2018 at 12:04 PM, Евгений Н. Жуков wrote: > I found error out catalina.out during printing nonASCII job > > Feb 22, 2018 11:02:02 PM org.apache.coyote.http11.AbstractHttp11Processor > process > INFO: Error parsing HTTP request header > Note: further occurrences of HTTP header parsing errors will be logged at > DEBUG level. > java.lang.IllegalArgumentException: Invalid character found in the > request target. The valid characters are defined in RFC 7230 and RFC 3986 > at org.apache.coyote.http11.InternalInputBuffer.parseRequestLine( > InternalInputBuffer.java:189) > at org.apache.coyote.http11.AbstractHttp11Processor.process( > AbstractHttp11Processor.java:1028) > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler. > process(AbstractProtocol.java:637) > at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor. > run(JIoEndpoint.java:316) > at java.util.concurrent.ThreadPoolExecutor.runWorker( > ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run( > ThreadPoolExecutor.java:617) > at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run( > TaskThread.java:61) > at java.lang.Thread.run(Thread.java:748) > > > 2018-02-22 22:51 GMT+03:00 Евгений Н. Жуков : > >> Just inzip an old vm with debian & 0.9.10 , in this version printing with >> nonASCII job name works fine. >> >> 2018-02-22 22:49 GMT+03:00 Евгений Н. Жуков : >> >>> This issue from 0.9.12. >>> In server.xml uriencoding already set to UTF8 >>> >>> >>> >>> >>> 2018-02-22 22:43 GMT+03:00 Mike Jumper : >>> Assuming you are using Tomcat, please verify that the following is set on the applicable connector in your server.xml: URIEncoding="UTF-8" See: https://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8 - Mike On Feb 22, 2018 11:35, "Евгений Н. Жуков" wrote: > Hi, just installed latest version, and got old problem. If printing > job has non-ASCII symbols (for example russians characters) the job stucks > in printing queue, or I getting empty pdf file. > > > -- > Евгений Жуков > +79534155676 <+7%20953%20415-56-76> skype: xrt_nn > >>> >>> >>> -- >>> Евгений Жуков >>> +79534155676 <+7%20953%20415-56-76> skype: xrt_nn >>> >> >> >> >> -- >> Евгений Жуков >> +79534155676 <+7%20953%20415-56-76> skype: xrt_nn >> > > > > -- > Евгений Жуков > +79534155676 <+7%20953%20415-56-76> skype: xrt_nn >
Re: printing issues (non-ASCII job name)
I found error out catalina.out during printing nonASCII job Feb 22, 2018 11:02:02 PM org.apache.coyote.http11.AbstractHttp11Processor process INFO: Error parsing HTTP request header Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level. java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986 at org.apache.coyote.http11.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:189) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1028) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) 2018-02-22 22:51 GMT+03:00 Евгений Н. Жуков : > Just inzip an old vm with debian & 0.9.10 , in this version printing with > nonASCII job name works fine. > > 2018-02-22 22:49 GMT+03:00 Евгений Н. Жуков : > >> This issue from 0.9.12. >> In server.xml uriencoding already set to UTF8 >> >> >> >> >> 2018-02-22 22:43 GMT+03:00 Mike Jumper : >> >>> Assuming you are using Tomcat, please verify that the following is set >>> on the applicable connector in your server.xml: >>> >>> URIEncoding="UTF-8" >>> >>> See: >>> >>> https://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8 >>> >>> - Mike >>> >>> >>> On Feb 22, 2018 11:35, "Евгений Н. Жуков" >>> wrote: >>> Hi, just installed latest version, and got old problem. If printing job has non-ASCII symbols (for example russians characters) the job stucks in printing queue, or I getting empty pdf file. -- Евгений Жуков +79534155676 <+7%20953%20415-56-76> skype: xrt_nn >>> >> >> >> -- >> Евгений Жуков >> +79534155676 skype: xrt_nn >> > > > > -- > Евгений Жуков > +79534155676 skype: xrt_nn > -- Евгений Жуков +79534155676 skype: xrt_nn
Re: printing issues (non-ASCII job name)
Just inzip an old vm with debian & 0.9.10 , in this version printing with nonASCII job name works fine. 2018-02-22 22:49 GMT+03:00 Евгений Н. Жуков : > This issue from 0.9.12. > In server.xml uriencoding already set to UTF8 > > > > > 2018-02-22 22:43 GMT+03:00 Mike Jumper : > >> Assuming you are using Tomcat, please verify that the following is set on >> the applicable connector in your server.xml: >> >> URIEncoding="UTF-8" >> >> See: >> >> https://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8 >> >> - Mike >> >> >> On Feb 22, 2018 11:35, "Евгений Н. Жуков" >> wrote: >> >>> Hi, just installed latest version, and got old problem. If printing job >>> has non-ASCII symbols (for example russians characters) the job stucks in >>> printing queue, or I getting empty pdf file. >>> >>> >>> -- >>> Евгений Жуков >>> +79534155676 <+7%20953%20415-56-76> skype: xrt_nn >>> >> > > > -- > Евгений Жуков > +79534155676 skype: xrt_nn > -- Евгений Жуков +79534155676 skype: xrt_nn
Re: printing issues (non-ASCII job name)
This issue from 0.9.12. In server.xml uriencoding already set to UTF8 2018-02-22 22:43 GMT+03:00 Mike Jumper : > Assuming you are using Tomcat, please verify that the following is set on > the applicable connector in your server.xml: > > URIEncoding="UTF-8" > > See: > > https://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8 > > - Mike > > > On Feb 22, 2018 11:35, "Евгений Н. Жуков" wrote: > >> Hi, just installed latest version, and got old problem. If printing job >> has non-ASCII symbols (for example russians characters) the job stucks in >> printing queue, or I getting empty pdf file. >> >> >> -- >> Евгений Жуков >> +79534155676 <+7%20953%20415-56-76> skype: xrt_nn >> > -- Евгений Жуков +79534155676 skype: xrt_nn
Re: printing issues (non-ASCII job name)
Assuming you are using Tomcat, please verify that the following is set on the applicable connector in your server.xml: URIEncoding="UTF-8" See: https://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q8 - Mike On Feb 22, 2018 11:35, "Евгений Н. Жуков" wrote: > Hi, just installed latest version, and got old problem. If printing job > has non-ASCII symbols (for example russians characters) the job stucks in > printing queue, or I getting empty pdf file. > > > -- > Евгений Жуков > +79534155676 <+7%20953%20415-56-76> skype: xrt_nn >
Re: printing issues (non-ASCII job name)
On Thu, Feb 22, 2018 at 2:35 PM, Евгений Н. Жуков wrote: > Hi, just installed latest version, and got old problem. If printing job > has non-ASCII symbols (for example russians characters) the job stucks in > printing queue, or I getting empty pdf file. > Do you have any information on what version this issue occurred in in the past, and what version it was fixed in? Or a JIRA ticket number documenting when it was fixed? -Nick
printing issues (non-ASCII job name)
Hi, just installed latest version, and got old problem. If printing job has non-ASCII symbols (for example russians characters) the job stucks in printing queue, or I getting empty pdf file. -- Евгений Жуков +79534155676 skype: xrt_nn
Re: Prevent VNC display from stretching?
Hi Andrew,
If you are using the stock Gaucamole client, you can modify the default
behavior in the javascript to prevent autoFit at startup and set the zoom
increments to whatever you want.
In guacamole.js you will find the below. Don't foget to re-minify the
javascript into guacamole.min.js after you make changes.
Regards,
Jeff
/**
* Whether the Guacamole display should be scaled to fit the browser
* window.
*
* @type Boolean
*/
autoFit : true,
$scope.zoomIn = function zoomIn() {
$scope.menu.autoFit = false;
$scope.client.clientProperties.autoFit = false;
$scope.client.clientProperties.scale += 0.1;
};
$scope.zoomOut = function zoomOut() {
$scope.client.clientProperties.autoFit = false;
$scope.client.clientProperties.scale -= 0.1;
};
On 2/22/18, 7:24 AM, "amlamarra" wrote:
I'd like to disable scaling in VNC. Right now, I'm able to get the scaling
set to 100% by doing the following:
Open the Guacamole menu (press Ctrl+Alt+Shift)
Uncheck "Automatically fit to browser window" under Display
Un-maxmize browser window
Check "Automatically fit to browser window"
Uncheck "Automatically fit to browser window"
Now I'm at 100%. And those zoom buttons don't work very well either. It only
goes in increments of 10%. And if you're at 109% and zoom out, then you're
set to 99%... It just seems kinda wonky. I wasn't sure if there was anything
I can do to set scaling to 100% no matter what.
--
Sent from:
http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
smime.p7s
Description: S/MIME cryptographic signature
Re: Allowing two people to view over VNC
On Thu, Feb 22, 2018 at 9:28 AM, greavette wrote: > Hello Forum, > > I'm still new to using Guacamole so perhaps this is covered in the > documentation so I apologize in advance if this has been already covered. > > I'm using Guacamole sever to help with a vendor providing remote support to > some of our computers that run their software. I also am remote to our > office so I'd like to have it whereby both the vendor and myself can login > through Guacamole and both use VNC to view the workstation at the same > time. > Is there a setting within Guacamole to help me setup so both the Vendor and > myself can see the workstation at the same time and work on the issue? > > Thank you. > Guacamole supports session sharing, which should make this possible. You can find documentation for it here: http://guacamole.apache.org/doc/gug/using-guacamole.html#client-share-menu This should allow you to accomplish this. -Nick
Allowing two people to view over VNC
Hello Forum, I'm still new to using Guacamole so perhaps this is covered in the documentation so I apologize in advance if this has been already covered. I'm using Guacamole sever to help with a vendor providing remote support to some of our computers that run their software. I also am remote to our office so I'd like to have it whereby both the vendor and myself can login through Guacamole and both use VNC to view the workstation at the same time. Is there a setting within Guacamole to help me setup so both the Vendor and myself can see the workstation at the same time and work on the issue? Thank you. -- Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
Re: Prevent VNC display from stretching?
I'd like to disable scaling in VNC. Right now, I'm able to get the scaling set to 100% by doing the following: Open the Guacamole menu (press Ctrl+Alt+Shift) Uncheck "Automatically fit to browser window" under Display Un-maxmize browser window Check "Automatically fit to browser window" Uncheck "Automatically fit to browser window" Now I'm at 100%. And those zoom buttons don't work very well either. It only goes in increments of 10%. And if you're at 109% and zoom out, then you're set to 99%... It just seems kinda wonky. I wasn't sure if there was anything I can do to set scaling to 100% no matter what. -- Sent from: http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
Re: [jira] [Updated] (GUACAMOLE-512) Shared Drive redirection doesn't work with Ubuntu [ xrdp ]
Hi Mike, You are using *XRDP* as your RDP server on Ubuntu Yes, I am using XRDP as RDP server on Ubuntu Drive redirection works when connecting to this XRDP instance with > *xfreerdp* from another, separate Linux machine Yes, Drive redirection works when connecting to this XRDP instance with xfreerdp from another ( separate ) Linux Machine. On Thu, Feb 22, 2018 at 2:47 PM, Nick Couchman (JIRA) wrote: > > [ https://issues.apache.org/jira/browse/GUACAMOLE-512? > page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > Nick Couchman updated GUACAMOLE-512: > > Priority: Minor (was: Critical) > > > Shared Drive redirection doesn't work with Ubuntu [ xrdp ] > > --- > > > > Key: GUACAMOLE-512 > > URL: https://issues.apache.org/jira/browse/GUACAMOLE-512 > > Project: Guacamole > > Issue Type: Bug > > Components: guacamole > >Affects Versions: 0.9.14 > > Environment: Remote Server : Ubuntu > >Reporter: Amarjeet Singh > >Priority: Minor > > > > Shared drive redirection works with xrdp command line [ O.S. : Ubuntu ] > but it doesn't work with Guacamole. > > > > -- > This message was sent by Atlassian JIRA > (v7.6.3#76005) >
Re: Prevent VNC display from stretching?
> > - Get VNC to behave the way RDP does, where the resolution of the client > is passed to the server at connection time and the remote display > automatically sizes to the correct resolution specified by the client? > > I'm not certain how feasible the first option is in Guacamole; the second > - getting VNC to dynamically pass resolution from client to server - is not > possible, and is a limitation of the VNC protocol, not of Guacamole. You > can work around it using xrandr to add the client resolution and resize the > VNC server display, but I don't know of a way to automate that process > native to VNC. > > Just one quick note of clarification, here - it looks like some VNC client/server systems have implemented dynamic sizing support by extensions the VNC (RFB, actually) protocol, but these extensions are very product-specific and are not standardized across different pieces of software. So, supporting each of these implementations would be difficult, and some of them would not be possible, for commercial products that do not provide source code or documentation for their extensions. -Nick
Re: Prevent VNC display from stretching?
On Wed, Feb 21, 2018 at 9:59 PM, amlamarra wrote: > Is there a way to get VNC connections from stretching (or shrinking) the > display by default? I'd like to keep it at 100%. > > It's not entirely clear what you mean, here: - Disable "scaling" of the VNC display, such that the zoom remains at 100% and you get scrollbars and/or a black border? or - Get VNC to behave the way RDP does, where the resolution of the client is passed to the server at connection time and the remote display automatically sizes to the correct resolution specified by the client? I'm not certain how feasible the first option is in Guacamole; the second - getting VNC to dynamically pass resolution from client to server - is not possible, and is a limitation of the VNC protocol, not of Guacamole. You can work around it using xrandr to add the client resolution and resize the VNC server display, but I don't know of a way to automate that process native to VNC. -Nick
