[jira] [Comment Edited] (GUACAMOLE-925) Add Russian keyboard support for RDP
[ https://issues.apache.org/jira/browse/GUACAMOLE-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835601#comment-17835601 ] Nick Stepin edited comment on GUACAMOLE-925 at 4/10/24 5:50 AM: Может кому интересно, но я решил эту проблему. Анализ проблемы показал, что когда мы указываем раскладку где есть таблица замен, то сервер при получении от клиента unicode нажатой клавиши, находит в этой таблице и подставляет скан-код. Если не находит, то отдает unicode. Соответственно, когда мы выбираем раскладку en_us_qwerty, то при нажатии на "." в любой раскладке будет подмена на скан-код клавиши "ю". Что приводит к эффекту, когда в en у нас ".", а в ru - вместо "." всегда "ю". Если же мы используем раскладку unicode (а у нее просто нет таблицы замен), то всегда передается unicode, но Windows не понимает сочетаний Ctrl+unicode. Второй момент связан с выбором раскладки для freerdp - в нашем случае там должен быть KBD_US, т.к. у нас идет переключение не раскладки, а языка. Основная идея решения состоит в следующем - надо сделать так, чтобы латинские буквы передавались скан-кодами (тогда работает сочетание с Ctrl), а русские и прочие знаки в Unicode. Соответственно таблица замен ru_ru_qwerty,keymap должна выглядеть по-другому ([^ru_ru_qwerty-1.keymap]) Мероприятия по интеграции раскладки в сервер и клиент не описываю, т.к. это описано другими. Нюанс. Чтобы всё работало как надо важно, чтобы выбор языка на хостовой и удаленной машине совпадали, иначе будете получать эффекты типа "вместо хъ - [], бю - ,." was (Author: JIRAUSER304876): Может кому интересно, но я решил эту проблему. Анализ проблемы показал, что когда мы указываем раскладку где есть таблица замен, то сервер при получении от клиента unicode нажатой клавиши, находит в этой таблице и подставляет скан-код. Если не находит, то отдает unicode. Соответственно, когда мы выбираем раскладку en_us_qwerty, то при нажатии на "." в любой раскладке будет подмена на скан-код клавиши "ю". Что приводит к эффекту, когда в en у нас ".", а в ru - вместо "." всегда "ю". Если же мы используем раскладку unicode (а у нее просто нет таблицы замен), то всегда передается unicode, но Windows не понимает сочетаний Ctrl+unicode. Второй момент связан с выбором раскладки для freerdp - в нашем случае там должен быть KBD_US, т.к. у нас идет переключение не раскладки, а языка. Основная идея решения состоит в следующем - надо сделать так, чтобы латинские буквы передавались скан-кодами (тогда работает сочетание с Ctrl), а русские и прочие знаки в Unicode. Соответственно таблица замен ru_ru_qwerty,keymap должна выглядеть по-другому ([^ru_ru_qwerty.keymap]) Мероприятия по интеграции раскладки в сервер и клиент не описываю, т.к. это описано другими. Нюанс. Чтобы всё работало как надо важно, чтобы выбор языка на хостовой и удаленной машине совпадали, иначе будете получать эффекты типа "вместо хъ - [], бю - ,." > Add Russian keyboard support for RDP > > > Key: GUACAMOLE-925 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-925 > Project: Guacamole > Issue Type: Improvement > Components: RDP >Affects Versions: 1.0.0 >Reporter: Roman Adyev >Priority: Minor > Attachments: SCREEN.jpg, apache_guacamole_Russian_layouts.txt, > image-2021-01-04-14-42-50-393.png, ru_ru_qwerty-1.keymap, ru_ru_qwerty.keymap > > > Hello, dear support team! > I'm using Unicode layout because Russian layout isn't presented there, but > with Unicode layout I can't send keyboard shortcuts to remote RDP machine > (CTRL + C for example). > If I switch Unicode to English layout in connection settings, I can do > keyboard shortcuts but unfortunately some signs doesn't match when I use RU > layout, for example instead of period sign I got Russian letter "ю". > The keyboard layouts on remote and local machine are identical, that's 100%, > tested many times on different clean windows 10 installs, on work, on VMs, on > friend's PCs, etc. The issue always the same. > As I can see Russian layout isn't presented in Guacamole connection settings > by itself so it would be highly appreciated if you can suggest any workaround > for Russian users. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GUACAMOLE-925) Add Russian keyboard support for RDP
[ https://issues.apache.org/jira/browse/GUACAMOLE-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835601#comment-17835601 ] Nick Stepin commented on GUACAMOLE-925: --- Может кому интересно, но я решил эту проблему. Анализ проблемы показал, что когда мы указываем раскладку где есть таблица замен, то сервер при получении от клиента unicode нажатой клавиши, находит в этой таблице и подставляет скан-код. Если не находит, то отдает unicode. Соответственно, когда мы выбираем раскладку en_us_qwerty, то при нажатии на "." в любой раскладке будет подмена на скан-код клавиши "ю". Что приводит к эффекту, когда в en у нас ".", а в ru - вместо "." всегда "ю". Если же мы используем раскладку unicode (а у нее просто нет таблицы замен), то всегда передается unicode, но Windows не понимает сочетаний Ctrl+unicode. Второй момент связан с выбором раскладки для freerdp - в нашем случае там должен быть KBD_US, т.к. у нас идет переключение не раскладки, а языка. Основная идея решения состоит в следующем - надо сделать так, чтобы латинские буквы передавались скан-кодами (тогда работает сочетание с Ctrl), а русские и прочие знаки в Unicode. Соответственно таблица замен ru_ru_qwerty,keymap должна выглядеть по-другому ([^ru_ru_qwerty.keymap]) Мероприятия по интеграции раскладки в сервер и клиент не описываю, т.к. это описано другими. Нюанс. Чтобы всё работало как надо важно, чтобы выбор языка на хостовой и удаленной машине совпадали, иначе будете получать эффекты типа "вместо хъ - [], бю - ,." > Add Russian keyboard support for RDP > > > Key: GUACAMOLE-925 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-925 > Project: Guacamole > Issue Type: Improvement > Components: RDP >Affects Versions: 1.0.0 >Reporter: Roman Adyev >Priority: Minor > Attachments: SCREEN.jpg, apache_guacamole_Russian_layouts.txt, > image-2021-01-04-14-42-50-393.png, ru_ru_qwerty-1.keymap, ru_ru_qwerty.keymap > > > Hello, dear support team! > I'm using Unicode layout because Russian layout isn't presented there, but > with Unicode layout I can't send keyboard shortcuts to remote RDP machine > (CTRL + C for example). > If I switch Unicode to English layout in connection settings, I can do > keyboard shortcuts but unfortunately some signs doesn't match when I use RU > layout, for example instead of period sign I got Russian letter "ю". > The keyboard layouts on remote and local machine are identical, that's 100%, > tested many times on different clean windows 10 installs, on work, on VMs, on > friend's PCs, etc. The issue always the same. > As I can see Russian layout isn't presented in Guacamole connection settings > by itself so it would be highly appreciated if you can suggest any workaround > for Russian users. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-925) Add Russian keyboard support for RDP
[ https://issues.apache.org/jira/browse/GUACAMOLE-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Stepin updated GUACAMOLE-925: -- Attachment: ru_ru_qwerty-1.keymap > Add Russian keyboard support for RDP > > > Key: GUACAMOLE-925 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-925 > Project: Guacamole > Issue Type: Improvement > Components: RDP >Affects Versions: 1.0.0 >Reporter: Roman Adyev >Priority: Minor > Attachments: SCREEN.jpg, apache_guacamole_Russian_layouts.txt, > image-2021-01-04-14-42-50-393.png, ru_ru_qwerty-1.keymap, ru_ru_qwerty.keymap > > > Hello, dear support team! > I'm using Unicode layout because Russian layout isn't presented there, but > with Unicode layout I can't send keyboard shortcuts to remote RDP machine > (CTRL + C for example). > If I switch Unicode to English layout in connection settings, I can do > keyboard shortcuts but unfortunately some signs doesn't match when I use RU > layout, for example instead of period sign I got Russian letter "ю". > The keyboard layouts on remote and local machine are identical, that's 100%, > tested many times on different clean windows 10 installs, on work, on VMs, on > friend's PCs, etc. The issue always the same. > As I can see Russian layout isn't presented in Guacamole connection settings > by itself so it would be highly appreciated if you can suggest any workaround > for Russian users. -- 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=17835580#comment-17835580 ] Nick Couchman commented on GUACAMOLE-1658: -- [~mjumper]: I've circled back to this and am trying to re-implement things using the libssh2 built-in functions instead of the custom ones that used to be present back in the 0.9.7 days. However, I'm having an unreasonably hard time wrapping my head around what the intent of this functionality actually is. My *guess* is that, if you use Guacamole to log in to a remote SSH server with a private key, the idea is that that private key will then be available to open further SSH sessions to other hosts. So, you go Guacamole -> host1.example.com with your private key, and then from host1.example.com you can seamlessly SSH to host2.example.com, using that same key-based credential? I guess I'm having trouble conceptualizing it because, normally, I'd physically log in to my laptop, start ssh-agent, use "ssh-add" to add my key identity to my agent, and then I'd be able to SSH from my laptop to host1.example.com, and, if agent forwarding is enabled, I can go from there to host2.example.com, etc. So, instead of my physical computer holding the ssh-agent and key, Guacamole does that, correct? Assuming this is the case, does ssh-agent need to already be running under the same account that guacd runs under? I think this is the part that I'm most confused about - what ssh-agent is actually being connected to - the one on the system running guacd, or the one on the initial SSH server? > 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.6.0 > > > 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-1289) Update guacamole-auth-duo to "Duo Web v4 SDK"
[
https://issues.apache.org/jira/browse/GUACAMOLE-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835574#comment-17835574
]
Nick Couchman commented on GUACAMOLE-1289:
--
Alexander has finished up the code changes for this, and it has been merged.
There's some documentation left to do, now, but should be ready to ship with
1.6.0 release.
> Update guacamole-auth-duo to "Duo Web v4 SDK"
> -
>
> Key: GUACAMOLE-1289
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1289
> Project: Guacamole
> Issue Type: Task
> Components: Documentation, guacamole-auth-duo
>Reporter: Mike Jumper
>Assignee: Alexander Leitner
>Priority: Major
> Fix For: 1.6.0
>
> Attachments: bGVZLZv.png
>
>
> It looks like there have been some changes to the Duo API/SDK which require
> updates to the guacamole-auth-duo extension. As reported by Ralph on the
> user@ mailing list:
> {quote}
> So we're setting up Duo for use on our Guacamole system, and whilst setting
> up the web SDK I noticed this message (see screenshot link): [^bGVZLZv.png]
> This states that there are some changes needed on the web application (The
> Duo Extension in this case). I'm by no means a developer, so I hope this is
> being posted in the correct place, and someone can work on getting the
> extension updated with the requested changes moving forward. Below is a link
> to Duo's Documentation for these changes.
> Thanks!
> https://duo.com/docs/duoweb-v4
> {quote}
> See:
> https://lists.apache.org/thread.html/r707e962d6f856234964e9a51c94d0719b1a5b116bfe9b78e787013b2%40%3Cuser.guacamole.apache.org%3E
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[ https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-1325: - Fix Version/s: 2.0.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 >Reporter: Mathias >Assignee: Nick Couchman >Priority: Major > Fix For: 2.0.0 > > > 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-1085) Consider migrating web application from AngularJS
[ https://issues.apache.org/jira/browse/GUACAMOLE-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-1085: - Fix Version/s: 2.0.0 > Consider migrating web application from AngularJS > - > > Key: GUACAMOLE-1085 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-1085 > Project: Guacamole > Issue Type: Improvement > Components: guacamole >Reporter: Alfred Egger >Priority: Major > Fix For: 2.0.0 > > > [AngularJS is in an LTS period until June 30, > 2021|https://blog.angular.io/stable-angularjs-and-long-term-support-7e077635ee9c]. > Unless resurrected as a community-driven project, it will be cease being > maintained after that date. Assuming no such project surfaces, we should look > into migrate the web application to another framework. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[ https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman updated GUACAMOLE-1325: - Affects Version/s: (was: 1.3.0) (was: 1.4.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 >Reporter: Mathias >Assignee: Nick Couchman >Priority: Major > > 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] [Assigned] (GUACAMOLE-1325) Apache Tomcat 10.0 Servlet API incompatibility
[ https://issues.apache.org/jira/browse/GUACAMOLE-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Couchman reassigned GUACAMOLE-1325: Assignee: Nick Couchman > 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 >Assignee: Nick Couchman >Priority: Major > > 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)
