Skip to content
Wszystkie systemy działająv0.16.44AGPL-3.0BEZPŁATNY PLAN · 30 URZĄDZEŃTenvo AI · MCP DLA CLAUDE & CURSOR
Powrót do blogaTutorial

Bezdotykowy pulpit Linux: prawdziwe sesje pulpitu

Tenvo Editorial Team8 min czytania
Bezdotykowy pulpit Linux: prawdziwe sesje pulpitu

Serwer jest osiągalny, ale po połączeniu widzisz czarny ekran, malutki wirtualny bufor ramki lub brak akceleracji GPU — ponieważ maszyna nie ma podłączonego monitora.

Serwer jest osiągalny, ale po połączeniu widzisz czarny ekran, malutki wirtualny bufor ramki lub brak akceleracji GPU — ponieważ maszyna nie ma podłączonego monitora. Ten przewodnik pokazuje, jak uzyskać prawdziwą, użyteczną sesję pulpitu na headless Linuxie: opcje sprzętowe i programowe, polecenia krok po kroku, jednostki systemd, uwagi dotyczące Wayland oraz jak połączyć się bezpiecznie (w tym rekomendowana opcja managed relay Tenvo).

Co oznacza „prawdziwy pulpit” na headless jednostce

Przez „prawdziwy pulpit” rozumiem sesję pulpitu, która zachowuje się tak, jak gdyby monitor był podłączony: pełna rozdzielczość ekranu, prawidłowy wyjściowy strumień GPU (jeśli dotyczy), trwałość sesji po restarcie, przewidywalne mapowanie klawiatury/myszy oraz możliwość uruchomienia środowisk Wayland lub X11 zamiast maleńkiego bufora Xvfb 800×600. Maszyna headless może wystawiać albo wirtualny ekran (emulacja programowa), albo fizyczny (HDMI dummy plug lub wirtualny KMS). Wybór zależy od potrzeby akceleracji GPU, funkcji DRM/KMS lub zwykłego interaktywnego pulpitu do administracji.

Trzy praktyczne podejścia — wybierz według potrzeby

  • Sprzętowy HDMI dummy plug — najprostsze do uzyskania akceleracji GPU. Podłącz HDMI 'headless ghost' za $2, aby zasymulować monitor; GPU i menedżer wyświetlania wygenerują normalną sesję i rozdzielczość.
  • Wirtualny X / Xvfb lub sterownik Xorg dummy + menedżer wyświetlania — tylko programowo i szeroko kompatybilne: tworzy pełną sesję X11, którą można udostępnić przez VNC (TigerVNC) lub x11vnc. Xvfb jest najprostszy, ale nie udostępnia KMS/akceleracji GPU.
  • RDP przez xrdp (zalecane w wielu przypadkach) — xrdp uruchamia prawdziwą sesję X (lub używa XorgXrdp) i zapewnia punkt końcowy RDP. Dobrze działa na serwerach headless, bo nie wymaga fizycznego wyświetlacza i jest szeroko obsługiwany przez klientów Windows/macOS.

Opcja A — HDMI dummy plug (sztuczka sprzętowa)

Jeśli potrzebujesz akceleracji GPU (OpenGL, sprzętowe dekodowanie, wyjście kompozytora Wayland) to najszybsza i najbardziej niezawodna metoda: kup mały HDMI dummy (EDID emulator), który zadeklaruje 1920×1080 lub 2560×1440. Podłącz do wyjścia HDMI GPU, zrestartuj jeśli trzeba, a menedżer wyświetlania (GDM, SDDM, LightDM) utworzy normalną sesję. Brak hacków programowych, brak wirtualnych buforów ramki.

Zalety: prawdziwe GPU, brak zmian konfiguracji. Wady: wymagana fizyczna dostępność, nieosiągalne gdy system nie ma złącza wyświetlacza lub jest w zamkniętej szafie.

Opcja B — Wirtualna sesja X: Xvfb + pulpit + TigerVNC (przykład Ubuntu/Debian)

Użyj tego, gdy nie możesz podłączyć dummy lub gdy akceleracja GPU nie jest wymagana. To daje pełną sesję pulpitu niezależną od fizycznego monitora i zadziała na dowolnej dystrybucji z X11.

sudo apt update
sudo apt install -y xvfb tigervnc-standalone-server xfce4 xfce4-goodies

# Create a dedicated VNC user (optional)
sudo adduser vncuser

# Example: start a persistent Xvfb display and XFCE
sudo -u vncuser Xvfb :99 -screen 0 1920x1080x24 &
export DISPLAY=:99
sudo -u vncuser startxfce4 &

# Start TigerVNC to expose :99 on TCP 5901
sudo -u vncuser x0vncserver -display :99 -passwordfile /home/vncuser/.vnc/passwd -forever -shared

# Or run tigervncserver directly if you want VNC-managed X sessions
sudo -u vncuser tigervncserver :1 -geometry 1920x1080 -depth 24

Jednostka systemd: spraw, by wyświetlacz przetrwał rebooty. Zapisz jako /etc/systemd/system/xvfb-vnc.service (dostosuj ścieżki i użytkownika):

[Unit]
Description=Xvfb + desktop + VNC
After=network.target

[Service]
Type=simple
User=vncuser
Environment=DISPLAY=:99
ExecStart=/usr/bin/Xvfb :99 -screen 0 1920x1080x24
ExecStartPost=/usr/bin/sleep 1
ExecStartPost=/usr/bin/startxfce4
Restart=on-failure

[Install]
WantedBy=multi-user.target

Uwaga: Xvfb zapewnia tylko programowy bufor ramki; brak akceleracji GPU. Dla wielu zadań administracyjnych i aplikacji GUI jest to wystarczające. Jeśli potrzebujesz sesji z obsługą GPU, użyj HDMI dummy lub sterownika Xorg dummy w połączeniu ze sterownikiem GPU (patrz niżej).

Opcja C — sterownik Xorg dummy / headless X server (dla sesji z DM)

Zamiast Xvfb możesz skonfigurować Xorg do użycia sterownika 'dummy', dzięki czemu systemowy menedżer wyświetlania (GDM/LightDM) utworzy normalną sesję logowania przy starcie. To bliższe prawdziwej sesji monitora i czasem lepiej kompatybilne niż Xvfb.

# Install Xorg dummy driver and a lightweight DE (Debian/Ubuntu)
sudo apt install -y xserver-xorg-video-dummy xfce4

# Example minimal /etc/X11/xorg.conf.d/10-dummy.conf
Section "Device"
  Identifier "DummyDevice"
  Driver "dummy"
EndSection

Section "Monitor"
  Identifier "DummyMonitor"
  HorizSync 28.0-80.0
  VertRefresh 48.0-75.0
EndSection

Section "Screen"
  Identifier "DummyScreen"
  Device "DummyDevice"
  Monitor "DummyMonitor"
  SubSection "Display"
    Depth 24
    Modes "1920x1080"
  EndSubSection
EndSection

Po utworzeniu tej konfiguracji włącz menedżera wyświetlania i zrestartuj. DM powinien pokazać normalnego greeter'a i stworzyć sesje, do których możesz uzyskać dostęp przez x11vnc (do współdzielenia istniejącego pulpitu) lub przez serwer VNC podpięty do wyświetlacza X.

Opcja D — xrdp: sesje RDP, które dobrze działają headless

xrdp to solidna opcja, bo tworzy sesję X na żądanie i mówi RDP, które jest szeroko obsługiwane przez klientów. Nie zależy od podłączonego monitora i często jest najmniej problematyczne dla zdalnego GUI na serwerach.

sudo apt install -y xrdp xfce4 xfce4-terminal
# Configure XFCE for xrdp: create or edit /home/you/.xsession or /etc/xrdp/startwm.sh
echo "startxfce4" > /home/you/.xsession
sudo systemctl enable --now xrdp
# Open firewall for TCP/UDP 3389 only if you control the network; prefer an SSH tunnel or Tenvo relay

Następnie połącz się z dowolnym klientem RDP na porcie 3389 lub przez tunel SSH. xrdp może używać XorgXrdp dla lepszej wydajności; sprawdź pakiety swojej dystrybucji dla dopasowanej wersji xorgxrdp.

Wayland: uwagi i opcje

Kompozycje Wayland obsługują wyjścia inaczej i historycznie miały ograniczone lub brak wsparcia dla wirtualnych ekranów. GNOME na Wayland nie zaakceptuje Xvfb; oczekuje wyjścia DRM/KMS. Twoje opcje:

  • Użyj HDMI dummy, żeby kompozytor uznał, że monitor jest obecny.
  • Uruchom sesję Xorg zamiast (zainstaluj sesję X11 jak XFCE lub GNOME on Xorg) i użyj Xvfb/xrdp/VNC.
  • Dla kompozytorów opartych na wlroots sprawdź wlr-rdp lub wayvnc (dojrzałość projektów zależy od kompozytora).
  • Dla dużych flot wymagających Waylandu rozważ sprzętowy headless GPU lub sterownik enterprise — zwykle wymaga to pakietów vendorowych i haków jądra.

Jeśli polegasz na Wayland, przeczytaj naszą obszerniejszą analizę na Wayland Remote Desktop: PipeWire, portals and gaps zanim wybierzesz rozwiązanie.

Sieć: relay Tenvo i uwagi dotyczące bezpieczeństwa

Gdy masz już sesję pulpitu, potrzebujesz niezawodnego połączenia. Tenvo oferuje natywne klienty na macOS/Windows/Linux, klienta w przeglądarce w publicznej becie oraz multi‑region managed relay, który jest zalecanym domyślnym wyborem dla większości użytkowników. Plany: Free $0, Lite $2.99/mo, Pro $7.99/mo. Managed relay eliminuje potrzebę reguł zapory, rozwiązań NAT traversal i utrzymywania floty TURN/STUN.

Bądź precyzyjny co do szyfrowania: Tenvo używa TLS z certyfikatami per‑device. Bezpośrednie połączenie peer‑to‑peer jest end‑to‑end pomiędzy dwoma urządzeniami. Gdy ruch trafia przez relay, TLS jest terminowany na relayu, co oznacza, że operator relayu może uzyskać dostęp do ruchu sesji. Jeśli wymogi zgodności zabraniają infrastruktury stron trzecich, self‑hosting jest właściwym wyborem — inaczej koszt operacyjny self‑hostingu (patchowanie, przechowywanie kluczy, failover) często przewyższa korzystanie z managed relay. Zobacz Self-Hosted Remote Desktop: Why, How, and What Breaks, aby zdecydować kiedy wybrać self‑hosted.

Jeśli chcesz całkowicie uniknąć przekierowań portów, ale nadal używać własnego relaya lub tunelu, przeczytaj Remote Desktop Without Port Forwarding Explained.

Lista kontrolna rozwiązywania problemów (czarne ekrany, zła rozdzielczość, problemy z klawiaturą)

  • Czarny ekran po zalogowaniu: sprawdź logi menedżera wyświetlania (journalctl -u gdm -b lub journalctl -u lightdm) oraz /var/log/Xorg.0.log pod kątem błędów.
  • Zbyt mały bufor ramki (np. 640×480): ustaw niestandardowy tryb w konfiguracji dummy X lub użyj xrandr, aby dodać tryb (działa tylko jeśli X ujawnia wyjście).
  • Błędne mapowanie klawiatury/myszy: zweryfikuj locale i ustawienia xkb oraz sprawdź, czy klient VNC/RDP nie wymusza layoutu; przetestuj na lokalnej wirtualnej konsoli (chvt) jeśli możliwe.
  • Brak GPU/OpenGL: Xvfb nie zapewni akceleracji GPU. Użyj HDMI dummy lub vendor headless driver jeśli potrzebujesz sprzętowej akceleracji.
  • Greeter na Waylandzie, ale brak sesji: przełącz na sesję X lub podłącz dummy display; sprawdź logi kompozytora (journalctl dla gnome-shell lub serwisu kompozytora).

Dla typowych napraw czarnego ekranu zobacz nasz przewodnik: Remote desktop black screen troubleshooting flow. Sprawdź też Xauthority, uprawnienia /tmp/.X11-unix oraz czy użytkownik ma poprawną powłokę i katalog domowy.

Kiedy self‑hostować a kiedy użyć managed relay Tenvo

Wybierz self‑hosting tylko jeśli masz pisemną politykę zabraniającą relayów stron trzecich (lokalizacja danych, niektóre reżimy zgodności) lub maszyny są w sieci izolowanej. W przeciwnym razie managed relay Tenvo to praktyczny domyślny wybór: zmniejsza obciążenie on‑call, obsługuje certyfikaty TLS i oferuje multi‑region failover. Jeśli planujesz self‑host, przeczytaj o kompromisach w Self-Hosted Remote Desktop: Why, How, and What Breaks i przygotuj się na uruchomienie klastra relay, rotację certyfikatów, logowanie i monitoring.

Szybkie odniesienie: polecenia i kontrole

# Check active display
echo "$DISPLAY"
# Test X connectivity
xdpyinfo -display :0 || xdpyinfo -display :99
# View DM logs
sudo journalctl -u gdm -b --no-pager
# Xorg log
sudo tail -n 200 /var/log/Xorg.0.log
# See screen/outputs
DISPLAY=:0 xrandr --listmonitors || DISPLAY=:99 xrandr --listmonitors
# Enable xrdp
sudo systemctl enable --now xrdp

Jeśli migrujesz z narzędzia zdalnego pulpitu, które zawsze 'po prostu działało' z podłączonym monitorem, pamiętaj: maszyny headless zmieniają założenia, które OS i sterowniki mają dotyczące wyświetlaczy. Zacznij od najprostszej poprawki (HDMI dummy) i przejdź do rozwiązań programowych, jeśli dostęp do sprzętu jest niemożliwy.

Gotowy do testów? Pobierz Tenvo, przetestuj połączenie unattended przez managed relay i wybierz podejście pulpitu z powyższych, które odpowiada Twoim potrzebom GPU i wymogom zgodności: Download Tenvo.

Pobierz Tenvo

Gotowy sprawdzić samodzielnie?

Bezpłatne dla 30 urządzeń, bez karty kredytowej. Uruchomienie i połączenie w dwie minuty.