Potrzebuję mieć terminale (pewnie będą miały Linux-a) do połączenia z serwerem (też Linux) w trybie graficznym. Pożądane jest, by użytkownik mógł wybierać protokół: X11, albo RDP. Oraz, by podawał nazwę użytkownika i hasło tylko raz, dla konta na serwerze, przy czym to hasło powinno być chronione przed podsłuchaniem w sieci - czyli powinno być szyfrowane.
Dla użytkownika mogłoby to wyglądać tak: włącza terminal, dostaje pytanie o rodzaj sesji - X11, albo RDP - i po wybraniu ma ekran logowania na serwerze, a po zalogowaniu się - sesję na serwerze. Po zakończeniu tej sesji ma znów pytanie o rodzaj sesji. Nie powinien mieć możliwości robienia czegokolwiek na samym terminalu. Byłoby pożytecze, aby w razie przerwania łączności mógł wrócić do przerwanej sesji. Jak coś takiego zrobić?
W sumie potrzebujesz normalny terminal dell np na thin os client lub cos podobnego, ale do czego te terminale, co na nich bedziesz robił?
Swego czasu w jednej z firm masowo zrezygnowali z tego typu narzędzi ponieważ problemem okazał sie teams
Próbowałeś przepuścić zapytanie przez Chatgpt?
Sposób wyboru protokołu to już kwestia konfiguracji
Pewnie to by się nadawało, tylko: (1) który z dostępnych w sprzedaży na ile się do tego nadaje?
Nie napisałeś co użytkownik ma na nich robić
DO tego dużo fimr z tego rezygnuje, koszt nowych urządzeń nie jest zauważalnie tańsze niż kupno zwykłego laptopa i do tego np cal rds do serwera
O to ze fizycznie program nie jest na urządzeniu końcowym a serwerze, problemem jest transmisja audio/video przez pulpit zdalny, kiepskie wsparcie dla linuxa, do tego moc obliczeniowa, takie terminale sa mało wydajne. Sam przykład ma juz kilka lat, nie wiem czy cos w tej materii sie zmieniło w co wątpię. Pozostaje kwestia licencji czy office czy innych programów musisz kupować wersje serwerowe, koszty ogromne w małych firmach, a w większych problemem jak nie te licencje to zwyczajnie ograniczenie takich terminali pod względem mocy (słabe procki, malo ram, wbudowana pamięć (nie każdy model można rozbudować aby na nim wgrać choćby windowsa czy pełnoprawny linux), możliwości softu itd.
Kup jakiś poleasingowy i zobacz czy spełni twoje oczekiwania, ale sam terminal to tylko końcówka, co po drugiej stronie ma być?
To nie ma być do office-a, a już na pewno nie do MS-Office - jeśli już, to darmowy LibreOffice. Ale to ma być do uczenia studentów specjalistycznej wiedzy, a nie klepania tekstów w Wordzie, i przede wszystkim mają być programy do takiej edukacji.
W roli serwera jest komputer z 6-rdzeniowym Xeon-em i 128GB RAM-u.
Jakiś stary Dell Wyse działał całkiem ładnie jako terminal, ale nie ma już go w sprzedaży.
Czy można gdzieś znaleźć zestawienie informacji o takich terminalach, żeby się zorientować, czym się różnią? Jakie porty, jak szybko działa, jaką komunikację obsługuje, ile mocy zasilania potrzebuje...
Ale to ma być do uczenia studentów specjalistycznej wiedzy,
_jta_ napisał:
przede wszystkim mają być programy do takiej edukacji.
Super, tylko, że terminal służy tak naprawdę tylko do łączenia się do serwera, to ten serwer przetwarzać będzie dane. Jeśli jesteś tego świadom że:
- te programy są w stanie pracować na wielu pulpitach naraz
- serwer to uciągnie (6 rdzeni to bardzo mało dla dzisiejszego serwera)
- że tak naprawdę te terminale to nic innego jak przystawka do monitora aby moc zdalnie pracować na komputerze w "chmurze"
To kupuj sprzet, choć w moje ocenie lepiej zrobic to na zwykłym PC
_jta_ napisał:
Jakiś stary Dell Wyse działał całkiem ładnie jako terminal, ale nie ma już go w sprzedaży.
No nie ma ponieważ taki sprzęt nie ma sensu, nowe optiplexy model 3000 thin client to wydatek 2 tys zlotych za 8gb ramu i dysk 64gb z linuxem
To samo zrobisz na każdym laptopie czy komputerze i nie ogranicza Cie sprzęt i system kliencki
_jta_ napisał:
Czy można gdzieś znaleźć zestawienie informacji o takich terminalach, żeby się zorientować, czym się różnią? Jakie porty, jak szybko działa, jaką komunikację obsługuje, ile mocy zasilania potrzebuje...
nowe optiplexy model 3000 thin client to wydatek 2 tys zlotych za 8gb ramu i dysk 64gb z linuxem
Za drogo w stosunku do tego, na co się przyda. Ja potrzebuję tylko rozmnożenia wejść i wyjść (N monitorów, N myszy, N klawiatur), z przyzwoitą szybkością wyświetlania na monitorach.
Ale wybór samego sprzętu, to tylko mała część tego, co potrzebuję - trzeba wiedzieć, jakich programów użyć dla osiągnięcia zamierzonego celu. Ten stary Dell Wyse po prostu miał zainstalowany jakieś dobre programy, i to dzięki nim tak dobrze się spisywał w roli terminala. Ale to chyba nie są darmowe programy - były z licencją do tego modelu terminala. Do innych terminali mogą być podobne programy, ale nie takie same, mogą mieć jakieś wady, z którymi będą nieprzydatne do mojego zastosowania - na przykład nie będą działać z tymi programami dydaktycznymi, których mają używać studenci. I czy w takiej sytuacji ten proponowany model będzie się dał użyć? Pewnie nikt tego nie wie, dopóki nie wypróbuje.
Przeczytałem odpowiedź ChatGPT. Sesja X11 przez SSH - nie ma menu (o ile pamiętam, można z niej na serwerze startować program sesji X, i wtedy będzie menu), nie wszystkie potrzebne aplikacje działają; z X2Go, o ile pamiętam, też nie wszystko działało (ale akurat to, co było potrzebne, a nie działało z X2Go, działało z SSH).
Co do wznawiania sesji, to screen nadaje się to sesji tekstowej (i często go używam), ale z graficzną działa bardzo kulawo: jeśli uruchomię aplikację graficzną, i po chwilowej przerwie wznawiam sesję, to już tę uruchomioną aplikację stracę; poza tym, nowa sesja często ma inny DISPLAY i trzeba to sprawdzać i ręcznie przestawiać.
Nie znam tmux, thinlinc (potrzebuję kilkunastu użytkowników, więc nie będzie darmowy), ani remminy. Ubuntu ma tmux-a i remminę. A, i jest jeszcze LTSP...
@ElektrodaBot - A jak się robiło zdalną sesję X11 bez szyfrowania połączenia? Co i jak należało skonfigurować?
Szybka odpowiedź 1. Serwer X na terminalu musi nasłuchiwać na TCP (usunąć `-nolisten tcp` lub uruchomić `startx -- -listen tcp`). 2. Na terminalu trzeba dopuścić zdalne hosty (`xhost +IP_serwera` lub – bezpieczniej – przekazać plik `xauth`). 3. Na serwerze aplikacji ustaw zmienną `DISPLAY=IP_terminala:0` i – jeśli używasz `xauth` – wstaw ten sam „cookie”. 4. Jeśli chcesz pełny ekran logowania, włącz XDMCP (UDP 177) w menedżerze wyświetlania na serwerze aplikacji i startuj serwer X parametrem `-query IP_serwera`.
Po tych trzech–czterech krokach aplikacje (lub cały pulpit) pojawią się na ekranie terminala, a ruch X11 będzie całkowicie nie-szyfrowany.
Kluczowe porty: TCP 6000 + nr wyświetlacza, a przy XDMCP również UDP 177. Ryzyko: cały ruch – łącznie z naciskanymi klawiszami – idzie w postaci jawnej.
lub w pliku konfiguracyjnym thin-clienta wpisz adres XDMCP. Użytkownik zobaczy zdalny greeter, zaloguje się i dostanie cały pulpit.
5. Firewall i sieć
Kod: Text
Zaloguj się, aby zobaczyć kod
Ogranicz ruch do konkretnej podsieci, bo szyfrowania brak.
6. Typowe pułapki • Wayland – obecnie domyślny w GNOME/KDE. Jeśli system startuje w Wayland, włącz tryb Xorg („GNOME on Xorg”) albo zainstaluj `xwayland` i użyj opcji `-listen tcp` w Xwayland (niewygodne). • Numery wyświetlaczy – przy login-managerach multiseat to nie zawsze `:0`. Sprawdź `echo $DISPLAY` lokalnie. • Akceleracja 3D – przez czysty X11 działa, ale po sieci bywa wolna; brak buforowania jak w RDP/NX. • Audio – X11 go nie przenosi; potrzebny PulseAudio/pipewire-network lub osobny tunel.
7. Dlaczego się już tak nie robi 1. Jawny tekst (przechwyt haseł, przejmowanie sesji). 2. 70+ portów do otwarcia (6000–6063) plus 177/UDP. 3. Słaba kompresja – po Wi-Fi lub WAN interfejs „chodzi jak w syropie”. 4. Współczesne dystrybucje przechodzą na Wayland/SSH/NX/RDP.
Dlatego w 2025 r. sens ma tylko w: • odizolowanych sieciach laboratoriów dydaktycznych, • scenariuszach testowych, • starych terminalach, które nie znają TLS/SSH.
---
Dalsze kierunki 1. Jeśli zależy Ci na jednym logowaniu i możliwości X11/RDP – rozważ LTSP 21 (z systemd-homed i SSSD), ThinLinc albo X2Go; łączą one pulpit NX/RDP i uwierzytelnianie SSH/kerberos. 2. Chcesz wznawiania sesji w X11? `xpra` albo `deskreen-nes`. 3. Do studenckiego labu: użyj trybu `ssh -X` dla podstawowych aplikacji i X2Go z kompresją dla cięższych. Pozostaw nieszyfrowane XDMCP tylko w sieci VLAN-lab.
W razie potrzeby mogę opisać: • autostart terminala w trybie „zapytaj: X11 czy RDP”, • kerberos + GSSAPI, • skrypty deploy-LTSP na ~15 klientów. Daj znać, które z tych tematów chcesz pogłębić.,
Możesz mnie wywołać w każdym temacie pisząc @ElektrodaBot. Zastrzeżenie: Niektóre odpowiedzi udzielone przez ElektrodaBota mogą być niedokładne. Elektroda nie ponosi odpowiedzialności za dokładność, rzetelność ani kompletność prezentowanych informacji. Wszystkie odpowiedzi ElektrodaBota powinny być zweryfikowane przez użytkownika. OpenAI może monitorować i zapisywać informacje wprowadzane po wywołaniu ElektrodaBota.
✨ Dyskusja dotyczy konfiguracji terminali Linux do zdalnego łączenia się z serwerem Linux w trybie graficznym z możliwością wyboru protokołu X11 lub RDP oraz jednokrotnego logowania z szyfrowanym hasłem. Wskazano, że terminale typu thin client, np. Dell OptiPlex 3000, mogą spełniać rolę urządzeń końcowych, jednak ich koszt i ograniczenia wydajnościowe często przewyższają zalety w porównaniu do zwykłych laptopów czy PC. Konieczne jest dobranie odpowiedniego oprogramowania klienckiego kompatybilnego z używanymi aplikacjami edukacyjnymi. W przypadku X11 bez szyfrowania, konfiguracja wymaga uruchomienia serwera X11 na terminalu z nasłuchem TCP, dopuszczenia zdalnych hostów (np. przez xhost lub xauth), ustawienia zmiennej DISPLAY na serwerze aplikacji oraz ewentualnego włączenia XDMCP dla pełnego ekranu logowania. Jednak ruch X11 bez szyfrowania jest podatny na podsłuch. Zaleca się stosowanie tunelowania SSH dla zabezpieczenia transmisji. Dyskusja podkreśla także potrzebę możliwości wznowienia przerwanych sesji oraz ograniczenia działań użytkownika do pracy na serwerze bez ingerencji w terminal. Wygenerowane przez model językowy.
