Как построить многопользовательский терминальный сервер на ALT Linux?

[yaleks]

В комментариях пишут, не работает сжатие трафика, и решение пока не найдено у них, по этому такие тормоза при подключении через интернет.
Причем, за сжатие отвечает сервер. Так как клиент при проверке (в моей практике) подключения к win и lin один и тотже

вот тут что-то про это есть - https://github.com/neutrinolabs/xrdp/issues/1625

[rits]

вот тут что-то про это есть - https://github.com/neutrinolabs/xrdp/issues/1625

Пацаны тоже пока ни к чему не пришли, rdp виндовая технология, а в мире линукс, где приложений под линукс меньше чем самих дистрибутивов, xrdp долго будут пилить )

[reshta]

Здравствуйте, уважаемые! Поработал с отладкой конфигурации 1сv83 через xrdp в виндовом клиенте. Через несколько часов получил торможение при раскрытии и пролистывании больших списков в конфигураторе. Не понял что это было, - то ли канал, то ли баг. Решив, что с xrdp более-менее ситуация понятна, пробую

x2go

Настраивал по инструкции https://www.altlinux.org/X2Go
Проблемы с раскладкой в виндовом клиенте решены галкой "Не настраивать клавиатуру".
Так же, как и в xrdp, для нормальной работы, требуется отключении изображения фона.
Звук заработал сразу. Проброс папок, буфер обмена из клиента на сервер заработали после настройки. Принтер не пробовал.

Возникла пара вопросов, решение которых необязательно, но буду благодарен за подсказки.

В виндовом клиенте x2go поражает количество возможных методов сжатия, которые субъективно, не сильно отличаются по производительности. Что выбрать?

В системном трее панели МАТЕ - Хаос. Но иногда, нормально. То же не понял, от чего зависит. При попытке настройки системного трея получил неприятное закцикливание. Решил удалением конфигурации сеанса .config/dconf/user. Как победить хаос в системном трее?




 

[reshta]

Я буду отписываться по мере внедрения проекта. Может пригодиться кому-то.

xrdp виндовый клиент подвисает на минуту время от времени, непонятно в какой момент точно. Думал, что на плохом канале, но нет, у коллеги канал хороший а поведение такое же. Это делает невозможным его использование для удалённой работы.

x2go виндовый клиент подвисает иногда но не критично - секунды, но не работает проброс папки на русских путях на клиенте 4.1.2.2. Ошибка такая https://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1156 но починить пока не удалось, сделаю, отпишусь.

[Skull]

Я буду отписываться по мере внедрения проекта. Может пригодиться кому-то.

xrdp виндовый клиент подвисает на минуту время от времени, непонятно в какой момент точно. Думал, что на плохом канале, но нет, у коллеги канал хороший а поведение такое же. Это делает невозможным его использование для удалённой работы.

x2go виндовый клиент подвисает иногда но не критично - секунды, но не работает проброс папки на русских путях на клиенте 4.1.2.2. Ошибка такая https://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1156 но починить пока не удалось, сделаю, отпишусь.

Анализируйте логи сеанса. Я такого на xrdp не ловил.

[yaleks]

А такого бага никто не наблюдал - время от времени после некоторого периода бездействия юзера раскладка сама переключается на английскую...

[yaleks]

А какого фига конфиги xrdp при обновлении сбрасываются на дефолтные? rpmnew уже не в моде?

[Skull]

Какие?

[yaleks]

Какие?

судя по датам все, и /etc/xrdp/xrdp.ini точно сбросился.

[Skull]

Какие?

судя по датам все, и /etc/xrdp/xrdp.ini точно сбросился.

Хм. Действительно, %config без (noreplace). Спасибо за замечание, поправлю.

[KALIBR-10]

На всякий случай тут оставлю свой видеомануал по настройке терминальника xrdp на альте https://www.youtube.com/watch?v=hrnzndqktRE

[reshta]

На всякий случай тут оставлю свой видеомануал

Кнопки нет, но не сказать за это "Спасибо!" не могу.

[reshta]

Всем здравствуйте!

xrdp виндовый клиент подвисает на минуту время от времени, непонятно в какой момент точно. Думал, что на плохом канале, но нет, у коллеги канал хороший а поведение такое же. Это делает невозможным его использование для удалённой работы.

Поймал это на клиенте remmina под Alt9. Сеанс подвис в 14-29 отвис в 14-21 вот логи сервера

Системный журнал:

Спойлер

июл 23 14:18:18 comp-kvm-processor-e08b48 pcscd[430168]: 27639213 auth.c:139:IsClientAuthorized() Process 4003349 (user: 501) is NOT authorized for action: access_pcsc
июл 23 14:18:18 comp-kvm-processor-e08b48 pcscd[430168]: 00000232 winscard_svc.c:335:ContextThread() Rejected unauthorized PC/SC client
июл 23 14:18:19 comp-kvm-processor-e08b48 nmbd[3118]: [2021/07/23 14:18:19.444741,  0] ../../source3/nmbd/nmbd_become_lmb.c:533(become_local_master_browser)
июл 23 14:18:19 comp-kvm-processor-e08b48 nmbd[3118]:   become_local_master_browser: Error - cannot find server COMP-KVM-PROCESSOR-E08B48 in workgroup WORKGROUP on subnet 10.>
июл 23 14:18:53 comp-kvm-processor-e08b48 pcscd[430168]: 35564504 auth.c:139:IsClientAuthorized() Process 4003349 (user: 501) is NOT authorized for action: access_pcsc
июл 23 14:18:53 comp-kvm-processor-e08b48 pcscd[430168]: 00000431 winscard_svc.c:335:ContextThread() Rejected unauthorized PC/SC client
июл 23 14:19:38 comp-kvm-processor-e08b48 dbus-daemon[2738]: [system] Connection has not authenticated soon enough, closing it (auth_timeout=30000ms, elapsed: 30052ms)
июл 23 14:19:56 comp-kvm-processor-e08b48 systemd[1]: pcscd.service: Succeeded.
июл 23 14:19:57 comp-kvm-processor-e08b48 kernel: audit: type=1131 audit(1627024796.825:21115): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=pcscd comm="systemd" exe=>
июл 23 14:19:56 comp-kvm-processor-e08b48 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=pcscd comm="systemd" exe="/lib/systemd/systemd" hostname>
июл 23 14:20:03 comp-kvm-processor-e08b48 kernel: 1cv8 invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
июл 23 14:20:03 comp-kvm-processor-e08b48 kernel: CPU: 3 PID: 368704 Comm: 1cv8 Tainted: G           OE     5.4.51-std-def-alt1 #1
июл 23 14:20:03 comp-kvm-processor-e08b48 kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.2-0-gf9626ccb91-prebuilt.qemu-project.org 04/01/2014
июл 23 14:20:03 comp-kvm-processor-e08b48 kernel: Call Trace:
июл 23 14:20:03 comp-kvm-processor-e08b48 kernel:  dump_stack+0x7c/0x9c
июл 23 14:20:03 comp-kvm-processor-e08b48 kernel:  dump_header+0x4a/0x1d8
июл 23 14:20:03 comp-kvm-processor-e08b48 kernel:  oom_kill_process.cold.33+0xb/0x10
июл 23 14:20:03 comp-kvm-processor-e08b48 kernel:  out_of_memory+0x196/0x460
июл 23 14:20:03 comp-kvm-processor-e08b48 kernel:  __alloc_pages_slowpath+0xc48/0xd20
июл 23 14:20:03 comp-kvm-processor-e08b48 kernel:  __alloc_pages_nodemask+0x2da/0x330
июл 23 14:20:03 comp-kvm-processor-e08b48 kernel:  pagecache_get_page+0xc0/0x220
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel:  filemap_fault+0x505/0x930
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel:  ? page_add_file_rmap+0x11f/0x180
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel:  ? alloc_set_pte+0x330/0x5b0
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel:  ? filemap_map_pages+0x245/0x3b0
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel:  ext4_filemap_fault+0x2c/0x40 [ext4]
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel:  __do_fault+0x38/0xd0
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel:  __handle_mm_fault+0xe91/0x12a0
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel:  handle_mm_fault+0xec/0x210
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel:  __do_page_fault+0x23e/0x4b0
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel:  async_page_fault+0x34/0x40
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel: RIP: 0033:0x7f9f8b1ddb00
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel: Code: Bad RIP value.
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel: RSP: 002b:00007fffae8dd2a8 EFLAGS: 00010216
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel: RAX: 00007f9f8b1ddb00 RBX: 00007f9f8bf78f28 RCX: 00007f9f8c021340
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel: RDX: 00007fffae8dd358 RSI: 00007f9fa7f233f0 RDI: 000000000ae68800
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel: RBP: 0000000000000000 R08: 00000000614e1f45 R09: 0000000002dbb500
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel: R10: 0000000002dbb380 R11: 00007f9fa7f22b80 R12: 00007f9fa7f233f0
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel: R13: 00007fffae8dd358 R14: 000000000ae68800 R15: 000000000d809588
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel: Mem-Info:
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel: active_anon:569836 inactive_anon:366820 isolated_anon:0
                                                      active_file:455 inactive_file:451 isolated_file:32
                                                      unevictable:0 dirty:1 writeback:0 unstable:0
                                                      slab_reclaimable:7306 slab_unreclaimable:17519
                                                      mapped:36824 shmem:37051 pagetables:10026 bounce:0
                                                      free:21514 free_pcp:2024 free_cma:0
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel: Node 0 active_anon:2279344kB inactive_anon:1467280kB active_file:1820kB inactive_file:1804kB unevictable:0kB isolated(anon):>
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel: Node 0 DMA free:15860kB min:268kB low:332kB high:396kB active_anon:32kB inactive_anon:16kB active_file:0kB inactive_file:0kB>
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel: lowmem_reserve[]: 0 2946 3898 3898
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel: Node 0 DMA32 free:54096kB min:50864kB low:63580kB high:76296kB active_anon:1745800kB inactive_anon:1148528kB active_file:137>
июл 23 14:20:04 comp-kvm-processor-e08b48 kernel: lowmem_reserve[]: 0 0 952 952

/var/log/xrdp.log

Спойлер

[20210723-14:17:28] [INFO ] xrdp_wm_log_msg: sesman connect ok
[20210723-14:17:29] [INFO ] drdynvc_process_capability_response: DVC version 2 selected
[20210723-14:17:30] [INFO ] xrdp_wm_log_msg: login failed for display 0
[20210723-14:17:36] [ERROR] libxrdp_query_channel - Channel 0 name rdpdr
[20210723-14:17:36] [ERROR] libxrdp_query_channel - Channel 1 name rdpsnd
[20210723-14:17:36] [ERROR] libxrdp_query_channel - Channel 2 name cliprdr
[20210723-14:17:36] [ERROR] libxrdp_query_channel - Channel 3 name drdynvc
[20210723-14:17:36] [ERROR] libxrdp_query_channel - Channel out of range 4
[20210723-14:17:45] [INFO ] xrdp_wm_log_msg: sesman connect ok
[20210723-14:17:45] [INFO ] xrdp_wm_log_msg: login successful for display 10
[20210723-14:17:45] [INFO ] lib_mod_log_peer: xrdp_pid=429990 connected to X11rdp_pid=2370455 X11rdp_uid=500 X11rdp_gid=500 client_ip=194.126.170.30 client_port=39058
[20210723-14:17:45] [ERROR] libxrdp_query_channel - Channel 0 name rdpdr
[20210723-14:17:45] [ERROR] libxrdp_query_channel - Channel 1 name rdpsnd
[20210723-14:17:45] [ERROR] libxrdp_query_channel - Channel 2 name cliprdr
[20210723-14:17:45] [ERROR] libxrdp_query_channel - Channel 3 name drdynvc
[20210723-14:17:45] [ERROR] libxrdp_query_channel - Channel out of range 4
[20210723-14:21:34] [ERROR] received Disconnect Provider Ultimatum
[20210723-14:21:34] [ERROR]   out xrdp_mcs_recv appid != MCS_DPUM
[20210723-14:21:34] [ERROR]  out xrdp_sec_recv : error
[20210723-14:21:34] [ERROR] out xrdp_rdp_recv error
[20210723-14:21:34] [ERROR] libxrdp_process_data: xrdp_rdp_recv failed
[20210723-14:21:34] [ERROR]   out xrdp_mcs_disconnect error - 2
/var/log/xrdp.log lines 6493-6527/6527 (END)

Дисконнекта на который намекают последние строки, реально не было, в это время, сервер был доступен.

При этом
xrdp-sesman.log
пустой. А предыдущий xrdp-sesman.log.1 содержит 25 строк в которые не входит указанное событие.

На сервере xorgxrdp.10.log , вероятно писавшийся в это время, забит сообщениями, поэтому он во вложении

Судя по системным логам, что-то произошло в системе в это время с ресурсами, но почему не понимаю. Сервер Alt9 на виртуалке.

Прошу помощи!

[reshta]

Здравствуйте, коллеги. Чуда не произошло.

xrdp виндовый клиент подвисает на минуту время от времени, непонятно в какой момент точно. Думал, что на плохом канале, но нет, у коллеги канал хороший а поведение такое же. Это делает невозможным его использование для удалённой работы.

Но выяснил, что подвисает не xrdp, а именно только конфигуратор 1с (база лежит на удалённом сервере) и только при использовании xrdp!
Картина выглядит так. Во время зависания конфигуратор 1с занимает от 95 до 100 % одного ядра, при этом xorg начинает занимать 16-25% другого ядра.
При нормальной работе, эти процессы занимают несколько процентов.
При этом в логах xrdp на обеих сторонах нет ничего необычного.
Через x2go такого не происходит никогда.
Канал хороший.

Прошу помощи, может есть у кого мысли относительно этой ситуации? Как бы понять, что именно происходит в связке конфигуратор 1с + xrdp сервер?




 

[reshta]

К штатному клиенту Windows очень много претензий. Впрочем, если есть возможность проверить, пожалуйста, повешайте баг на https://github.com/neutrinolabs/xrdp

На баг сервера xrdp моя ситуация тянет, но проблема очень специфичная, чтобы воспроизвести её, нужно поставить Altlinux +  где-то 1c сервер + конфигуратор, развернуть базу и попробовать поработать  в конфигураторе пару дней через xrdp.