Pe serverul meu rulez o instalare recentă de testare Debian (Bookworm, 5.16.0-6-amd64), pe care am actualizat-o astăzi. După ce am actualizat toate pachetele, nu mai pot Win-RDP în cutie. Sesman se conectează bine, dar socket-ul UNIX expiră după câteva minute. Xrdp a funcționat perfect înainte de actualizare și firewall-ul nu poate fi o problemă și am folosit o singură autentificare.
Iată cele două porțiuni relevante din /var/log/xrdp.log:
[20220408-15:13:05] [INFO ] Utilizând certificatul X.509 implicit: /etc/xrdp/cert.pem
[20220408-15:13:05] [INFO ] Folosind fișierul cheie X.509 implicit: /etc/xrdp/key.pem
[20220408-15:13:05] [EROARE] Nu se poate citi fișierul cheii private /etc/xrdp/key.pem: Permisiune refuzată
[20220408-15:13:05] [EROARE] libxrdp_force_read: eroare de citire antet
[20220408-15:13:05] [EROARE] Procesarea [ITU-T T.125] Connect-Initial a eșuat
[20220408-15:13:05] [EROARE] [MCS Connection Sequence] primirea cererii de conectare a eșuat
[20220408-15:13:05] [EROARE] xrdp_sec_incoming: xrdp_mcs_incoming a eșuat
[20220408-15:13:05] [EROARE] xrdp_rdp_incoming: xrdp_sec_incoming a eșuat
[20220408-15:13:05] [EROARE] xrdp_process_main_loop: libxrdp_process_incoming a eșuat
[20220408-15:13:05] [EROARE] xrdp_iso_send: trans_write_copy_s a eșuat
[20220408-15:13:05] [EROARE] Trimiterea [ITU T.125] DisconnectProviderUltimatum a eșuat
[20220408-15:30:39] [INFO ] se conectează la sesman ip 127.0.0.1 portul 3350
[20220408-15:30:39] [INFO ] xrdp_wm_log_msg: sesman connect ok
[20220408-15:30:39] [INFO ] sesman connect ok
[20220408-15:30:39] [INFO] se trimite informații de conectare către managerul de sesiune, așteptați...
[20220408-15:30:39] [INFO ] xrdp_wm_log_msg: autentificare reușită pentru afișajul 10
[20220408-15:30:39] [INFO ] conectare reușită pentru afișajul 10
[20220408-15:30:39] [INFO ] a încărcat modulul „libxup.so” ok, dimensiunea interfeței 10296, versiunea 4
[20220408-15:30:39] [INFO ] a început conectarea
[20220408-15:30:39] [INFO] lib_mod_connect: conectare prin soclu UNIX
[20220408-15:34:09] [INFO ] problemă de conectare, renunțare
[20220408-15:34:09] [INFO] o problemă
Am găsit o problemă legată de Forumul Raspberry Pi dar trecerea la VNC nu abordează problema, iar celelalte sugestii mi se par neprofesionale.
Există o modalitate de a detalia „oarece problemă” socket-ului UNIX? Ai idee despre ce este vorba despre eroarea „Permisiunea refuzată”? Permisiunile pentru fișiere sunt identice pe serverele mai vechi unde xrdp funcționează bine. Deci cred că mai lipsește ceva.
Vreo idee?
Adaug și starea systemctl:
# systemctl status xrdp
â xrdp.service - demonul xrdp
Încărcat: încărcat (/lib/systemd/system/xrdp.service; activat; prestabilit furnizor: activat)
Activ: activ (în rulare) din vineri 2022-04-08 15:42:18 CEST; acum 1h 13min
Documente: man:xrdp(8)
man:xrdp.ini(5)
Proces: 774 ExecStartPre=/bin/sh /usr/share/xrdp/socksetup (code=exit, status=0/SUCCESS)
Proces: 789 ExecStart=/usr/sbin/xrdp $XRDP_OPTIONS (cod=ieșit, stare=0/SUCCESS)
PID principal: 805 (xrdp)
Sarcini: 3 (limită: 76942)
Memorie: 13,0 M
CPU: 59 ms
CGroup: /system.slice/xrdp.service
ââ 805 /usr/sbin/xrdp
ââ67212 /usr/sbin/xrdp
08 aprilie 16:55:30 server2 xrdp[67211]: [EROARE] xrdp_rdp_incoming: xrdp_sec_incoming a eșuat
08 aprilie 16:55:30 server2 xrdp[67211]: [EROARE] xrdp_process_main_loop: libxrdp_process_incoming a eșuat
Apr 08 16:55:30 server2 xrdp[67211]: [EROARE] xrdp_iso_send: trans_write_copy_s a eșuat
Apr 08 16:55:30 server2 xrdp[67211]: [EROARE] Trimiterea [ITU T.125] DisconnectProviderUltimatum a eșuat
Apr 08 16:55:30 server2 xrdp[67212]: [EROARE] Nu se poate citi fișierul cheii private /etc/xrdp/key.pem: Permisiune refuzată
Apr 08 16:55:30 server2 xrdp[67212]: [WARN ] Primit [MS-RDPBCGR] Tipul TS_UD_HEADER 0xc006 este necunoscut (ignorat)
Apr 08 16:55:30 server2 xrdp[67212]: [WARN ] Primit [MS-RDPBCGR] Tipul TS_UD_HEADER 0xc00a este necunoscut (ignorat)
Apr 08 16:55:30 server2 xrdp[67212]: [WARN ] Primit [MS-RDPBCGR] Tipul TS_UD_HEADER 0xc008 este necunoscut (ignorat)
08 aprilie 16:55:31 server2 xrdp[67212]: [AVERTISMENT] xrdp_caps_process_codecs: codul de codec necunoscut 5
Apr 08 16:55:31 server2 xrdp[67212]: [WARN ] fișier local keymap pentru 0x00000807 găsit și nu se potrivește cu keymap încorporat, folosind fișierul keymap local
# systemctl status xrdp-sesman
â xrdp-sesman.service - manager de sesiune xrdp
Încărcat: încărcat (/lib/systemd/system/xrdp-sesman.service; activat; prestabilit furnizor: activat)
Activ: activ (în rulare) din vineri 2022-04-08 15:42:17 CEST; acum 1h 13min
Documente: man:xrdp-sesman(8)
man:sesman.ini(5)
Proces: 766 ExecStart=/usr/sbin/xrdp-sesman $SESMAN_OPTIONS (code=exit, status=0/SUCCESS)
PID principal: 771 (xrdp-sesman)
Sarcini: 1 (limită: 76942)
Memorie: 1,8 M
CPU: 72 ms
CGroup: /system.slice/xrdp-sesman.service
ââ771 /usr/sbin/xrdp-sesman
Apr 08 16:55:41 server2 xrdp-sesman[771]: [EROARE] sesman_data_in: scp_process_msg a eșuat
Apr 08 16:55:41 server2 xrdp-sesman[771]: [EROARE] sesman_main_loop: trans_check_wait_objs a eșuat, eliminarea trans
Actualizați:
Am încercat să șterg și să reinstalez xrdp, dar nu mai pot instala xrdp:
# apt install xrdp
Citirea listelor de pachete... Gata
Construirea arborelui de dependență... Gata
Citirea informațiilor despre stare... Gata
Pachetul xrdp nu este disponibil, dar se referă la un alt pachet.
Acest lucru poate însemna că pachetul lipsește, a fost învechit sau
este disponibil numai din altă sursă
E: Pachetul „xrdp” nu are un candidat pentru instalare
Ceva sugestii, cineva?
Actualizare II:
Nu sunt sigur exact care a fost cauza principală și las răspunsul deschis pentru cineva cu mai multe informații despre Linux.
Iată ce am făcut. Deoarece xrdp a fost (și încă este...) nu mai este disponibil pe Debian:testare Am adăugat Debian: instabil la lista mea de pachete și fixat potrivit pentru Debian:testing. În acest fel aș putea reinstala xrdp. Dar, spre dezamăgirea mea, încă nu am putut Win-RDP în cutie. Asta a fost acum o săptămână.
Azi am alergat apt update && apt upgrade și am repornit caseta și acum RDP funcționează bine din nou! Nu sunt sigur ce anume a rezolvat problema. Credeam că am încercat să repornesc și înainte. Deci totul bine din partea mea.
