Wilk w owczej skórze czyli sieć tanich, bezdyskowych terminali graficznych LTSP

Transkrypt

1 Wilk w owczej skórze czyli sieć tanich, bezdyskowych terminali graficznych LTSP Rajmund Radziewicz Niezbyt nowoczesne komputery, które w wielu szkołach masowo oddawane są do wymiany mogą posłużyć jako graficzne, wydajne terminale. Właśnie z racji oszczędności i ze względu na fakt, że sieć taką można skonfigurować w prosty sposób, LTSP został wdrożony w płockim Technikum Uzupełniającym dla Dorosłych SIMP... LTSP (Linux Terminal Server Project) jest oprogramowaniem pozwalającym na uruchomienie sieci terminali w oparciu o kilka usług, m.in DHCP, NFS i TFTP. Postaram się przybliżyć konfigurację LTSP w tym konkretnym przypadku, a także opisać kilka przydatnych czynności, które mogą ułatwić pracę z siecią terminali. Zasada funkcjonowania LTSP polega na tym, że wszystkie aplikacje są faktycznie uruchamiane na serwerze. Użytkownik logujący się na danym terminalu, faktycznie loguje się za pośrednictwem protokołu XDMCP na konto założone na serwerze natomiast sam terminal nie musi być nawet wyposażony w twardy dysk czy jakiekolwiek napędy. W płockim technikum serwer o parametrach Pentium IV 1700 Mhz i 1 GB RAM obsługuje jedenaście X-terminali i komputer pełniący funkcję lokalnego serwera bazy danych. Twórcy LTSP wspominają nawet o instalacji z użyciem serwera o zbliżonych parametrach, obsługującego 40 stacji roboczych. Myślę, że nie trzeba tu wspominać o oszczędnościach, jakie niesie ze sobą wykorzystanie tej technologii. Podobne rozwiązania są zresztą bardzo popularne w wewnętrznych sieciach bankowych czy też uczelnianych. Poza wspomnianymi oszczędnościami, pozwalają one przede wszystkim zwiększyć kontrolę nad pracą każdej jednostki i znacznie ułatwić administrowanie całą siecią. W końcu zarówno aplikacje, jak i użytkownicy korzystają de facto z jednej maszyny. Oczywiście, żeby mechanizm zadziałał, na serwerze musi działać DHCP czyli dynamiczne przydzielanie adresów IP. Terminale uruchamiają się przez sieć za pomocą bootrom-ów znajdujących się na kartach sieciowych lub dyskietkach, otrzymują od serwera adres IP i za pomocą TFTP ściągają specjalnie przygotowane jądro. Kiedy jądro zostanie ściągnięte przejmuje kontrolę nad całym procesem, montuje sobie drzewo katalogów z serwera przy pomocy NFS i uruchamia X-serwer. Następnie komunikuje się z demonem logowania na serwerze (np. KDM) za pomocą protokołu XDMCP i pozwala zalogować się użytkownikowi na konto. Tak w dużym uproszczeniu wygląda zasada uruchamiania terminali. W przypadku opisywanej przeze mnie sieci, wykorzystana została edukacyjna dystrybucja bazująca na Debianie oraz Knoppiksie Linux-EduCD Zawiera ona już zaimplementowany i wstępnie skonfigurowany serwer LTSP. Nic nie stoi jednak na przeszkodzie, żeby zainstalować odpowiednie pakiety w dowolnej innej dystrybucji. W tej chwili na stronie projektu wszelkie wymagane składniki dostępne są zarówno w postaci pakietów RPM, DEB, jak również tgz. Gdybyśmy decydowali się na instalację w systemie, który nie jest wyposażony w LTSP, musimy pamiętać, że do poprawnego działania całości wymagane są skonfigurowane i działające usługi NFS, TFTP i DHCP. Zanim przejdę do opisu uruchamiania LTSP w Linux-EduCD, kilka słów na temat samodzielnej instalacji. INSTALACJA Jeżeli nie mamy jeszcze zainstalowanego serwera dhcp, nfs lub tftp, należy dodać odpowiednie pakiety. To standardowe usługi sieciowe, dostępne praktycznie w każdej większej dystrybucji, więc nie powinno sprawić to nikomu problemu. Serwer tftpd należy ustawić w inetd lub xinetd, w zależności od tego, co jest wykorzystywane przez naszą odmianę Linuksa.

2 Przykładowo w Debianie i pochodnych wpis w /etc/inetd.conf powinien wyglądać tak jak poniżej: tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot Parametr -s oznacza, że serwer tftpd uruchamiany będzie w bezpiecznym środowisku chroot. Wszelkie jego działania będą się odnosiły wyłącznie do katalogu /tftpboot, który po uruchomieniu będzie stanowił główne drzewo katalogów dla tej usługi. W /tftpd/lts znajdzie się również jądro LTSP, które będzie przesyłane na stacje robocze. No właśnie... jądrem i samym LTSP zajmiemy się już za chwilę. Ze strony projektu musimy pobrać następujące pakiety: lts_core główny pakiet LTSP lts_kernel dedykowane jądro dla LTSP lts_x_core środowisko XFree86 dla LTSP ltsp-x-fonts-i386 pakiet czcionek Opisywana wersja LTSP nosi numer 3.0. Jest już co prawda dostępna edycja 4.0, ale nie posiada jeszcze dedykowanego jądra i wykorzystuje pakiet z wcześniejszej wersji. Z tego względu brak tutaj większych różnic w samej funkcjonalności. Po zainstalowaniu powyższych paczek należy uruchomić skrypt lstp_initialize, znajdujący się w /opt/ltsp/templates. Skrypt automatycznie skonfiguruje odpowiednie usługi i dokona niezbędnych zmian w systemowych plikach konfiguracyjnych. Te zmiany to między innymi: /etc/dhcpd.conf.example Przykładowy plik konfiguracyjny serwera DHCP /etc/exports Plik ze zdefiniowanymi zasobami udostępniamymi poprzez NFS /etc/kde3/kdm/kdmrc Plik konfiguracyjny demona KDM (K Display Manager) /etc/x11/xdm/ltsp.gif Logo graficzne widoczne podczas logowania do LTSP /etc/rc?.d/*nfs-* Dowiązania do skryptów startowych uruchamiających NFS /etc/rc?.d/*portmap Dowiązania do skryptów startowych uruchamiających portmappera /etc/init.d/sysklogd Dowiązania do skryptów startowych uruchamiających demona sysklog Kiedy powyższe pliki zostały już utworzone lub zmodyfikowane, powinniśmy skonfigurować jeszcze serwer DHCP, dokonać wpisów w pliku /etc/hosts oraz głównym pliku konfiguracyjnym LTSP lts.conf. W wyniku działania ltsp_initialize otrzymujemy przykładowy plik dhcpd.conf.example. Jeśli nie potrzebujemy przydzielać numerów IP na podstawie adresów sprzętowych (MAC) kart

3 sieciowych, wystarczy to, co zostało wygenerowane przez skrypt. Możemy także zdefiniować dodatkowo zakres adresów przydzielanych przez serwer DHCP. W Linux-EduCD są to adresy z przedziału Odpowiada za to poniższy fragment pliku /etc/dhcp3/dhcpd.conf. W pliku /etc/hosts/ powinny znajdować się następujące wpisy: ws001.knoppix ws ws002.knoppix ws ws003.knoppix ws003 Są to adresy IP i nazwy poszczególnych stacji roboczych-terminali. Wpisy te nie są obowiązkowe, jeśli mamy skonfigurowany w sieci serwer DNS. W praktyce okazują się jednak niezwykle przydatne, gdyż znacznie przyśpieszają montowanie katalogów systemowych poprzez NFS na terminalach. Wystarczy zresztą wykomentować na próbę wpisy z /etc/hosts i porównać czas uruchamiania stacji roboczych bez nich. Kiedy w /etc/hosts znajduje się już odpowiednio długa lista nazw i adresów, powinniśmy ustawić główny plik konfiguracyjny śro dowiska terminali lts.conf. Znajduje się on w /opt/ltsp/i386/etc/, czyli specjalnym drzewie katalogów, które jak już wspominałem, jądro załadowane na terminal zamontuje sobie poprzez NFS. Plik lts.conf składa się z globalnej sekcji oznaczonej jako: [Default] oraz opcjonalnych sekcji oznaczonych kolejno: [ws001], [ws002], [ws003] czyli sekcji specyficznych dla poszczególnych stacji. Jest to niejako odpowiednik XF86Config w przypadku typowego serwera X. Definiujemy tutaj sterownik karty graficznej, w jaką wyposażone są nasze terminale (jeżeli każdy z terminali posiada inną konfigurację sprzętową wykorzystujemy kolejne sekcje ws), typ myszy, odświeżanie. Jeśli nie zdefiniujemy żadnej sekcji ws, wpisy Default będą dotyczyły wszystkich stacji. W Linux-EduCD /opt/ltsp/i386/etc/lts.conf wygląda następująco: [Default] SERVER = XSERVER = auto X_MOUSE_PROTOCOL = PS/2 X_MOUSE_DEVICE = /dev/psaux X_MOUSE_RESOLUTION = 400 X_MOUSE_BUTTONS = 3 X_VERTREFRESH = 60 # USE_XFS = N LOCAL_APPS = N XkbSymbols = pl(pc101) XkbLayout = pl RUNLEVEL = 5 # [ws001] XSERVER = auto LOCAL_APPS = N USE_NFS_SWAP = N SWAPFILE_SIZE = 48m RUNLEVEL = 5 Parametr XSERVER ustawiony jest na auto. Oznacza to, że system sam dokona autodetekcji karty graficznej, w jaką wyposażone są terminale. W pakiecie lts_x_core znajdują się praktycznie wszystkie sterowniki kart wspieranych przez XFree86 w wersji 4.1. Jeśli zatem posiadamy taką kartę, z powodzeniem możemy to ustawienie zostawić bez zmian. Jeśli nie chcemy korzystać z opcji auto, możemy sami wpisać tutaj odpowiednią wartość, przykładowo: XSERVER = sis

4 Parametr X_MOUSE_DEVICE definiuje urządzenie, do którego podłączona jest mysz. Dla myszy PS/2 będzie to /dev/psaux. Gdybyśmy posiadali mysz szeregową, wpiszemy tutaj /dev/ttys0 lub /dev/ttys1. X_VERTREFRESH to odświeżanie pionowe naszego monitora. Ustawienie 60 jest optymalną wartością, szczególnie dla starszych modeli. USE_XFS informuje, czy korzystamy z serwera czcionek. LOCAL_APPS to możliwość uruchamiania niektórych aplikacji lokalnie przez terminal. Jeśli ustawimy na Y, musimy skonfigurować w sieci serwer NIS i dopisać dwa kolejne parametry do lts.conf: NIS_DOMAIN, w którym wpiszemy nazwę domeny NIS oraz NIS_SERVER, gdzie wpiszemy jego adres. Zalecaną metodą jest oczywiście uruchamianie aplikacji na serwerze. Ponadto lokalne uruchamianie nawet niezbyt pamięciożernego programu wymaga już maszyny o trochę lepszych parametrach sprzętowych. XkbSymbols i XkbLayout to definicje klawiatury, natomiast RUNLEVEL oznacza poziom startowy naszych stacji. W LTSP standardowo mamy do dyspozycji poziomy: 3, 4 i 5. Poziom oznaczony numerem 3 uruchamia stacje w trybie tekstowym, poziom 4 oznacza sesję telnet, natomiast domyślnie ustawiony jest poziom 5. Jest to tryb graficzny, w którym po uruchomieniu każdy terminal (w tym wypadku można go już nazwać X terminalem) pozwoli zalogować się do systemu za pośrednictwem uruchomionego na serwerze demona XDM, GDM lub KDM. Ciekawą opcją LTSP jest możliwość korzystania z pliku wymiany. Informuje o tym parametr SWAPFILE_SIZE w sekcji przykładowego terminala ws001. Możemy utworzyć na serwerze plik wymiany dla naszych stacji, który będzie im udostępniony poprzez NFS. Domyślnie katalog /var/opt/ltsp/swapfiles jest wówczas montowany jako /tmp/swapfiles. Jeżeli nie mamy pliku wymiany, zostanie on utworzony automatycznie, a jego wielkość określi właśnie parametr SWAPFILE_SIZE. Plik wymiany może istnieć również na zupełnie innej maszynie w sieci. Jeśli taka sytuacja ma miejsce, musimy dopisać do naszego pliku lts.conf dodatkowy parametr SWAP_SERVER, w którym podamy adres tego komputera. Jeśli wszystko ustawiliśmy poprawnie, nie powinna nas w zasadzie spotkać żadna niemiła niespodzianka przy uruchamianiu stacji. URUCHAMIANIE TERMINALA Jeśli mamy już zainstalowane odpowiednie pakiety, ustawiony lts.conf i działające usługi DHCP, NFS oraz TFTP, możemy przejść do uruchamiania stacji roboczych. Do tego celu wykorzystamy narzędziem o nazwie Etherboot. Służy ono do tworzenia obrazów ROM, na których umieszczany jest specjalny program umożliwiający uruchomienie komputera przez sieć. Możemy co prawda zaopatrzyć się w karty sieciowe, które są już wyposażone w tzw. bootromy i wówczas nasze terminale przy każdym starcie będą domyślnie próbowały uruchomić się przez sieć i uzyskać dane od rozgłaszającego się serwera DHCP. Jako że jednak nie wszystkie starsze komputery, przeznaczane na terminale LTSP, posiadają takie karty, możemy wygenerować dyskietkę z bootromem, za pomocą której uruchomimy stacje. Ze strony powinniśmy pobrać plik odpowiadający chipsetowi naszej karty sieciowej. Należy nagrać go na dyskietkę, np. poleceniem: cat plik.lzdsk > /dev/fd0 oraz uruchomić za jej pomocą terminal. W BIOS terminala kolejność uruchamiania napędów powinna być oczywiście tak ustawiona, żeby w pierwszej kolejności sprawdzany był napęd dyskietek. Jeśli posiadamy starszy komputer, bez twardego dysku i napędu CD-ROM, zadanie to staje się wręcz jedyną możliwością. Dyskietka nie będzie oczywiście potrzebna przez cały czas pracy terminala. Kiedy ten komputer zainicjuje już program rozruchowy, otrzyma adres od serwera DHCP i zacznie ściągać jądro możemy śmiało wyjąć ją z napędu i uruchamiać już kolejne maszyny (o ile oczywiście posiadają taką samą kartę sieciową). Jeżeli w lts.conf ustawiliśmy RUNLEVEL na

5 5, po chwili powinien uruchomić się tryb graficzny. Stacja robocza przekaże zapytanie do demona logowania na serwerze przy pomocy wspomnianego już XDMCP i wyświetli znajome okienko GDM, KDM lub XDM, w zależności od tego, z jakiego środowiska korzystamy. W przypadku Linux-EduCD jest to KDM. Logujemy się oczywiście na konto, które musi istnieć na serwerze. Jeśli po uruchomieniu terminala serwer X nie chce się uruchomić, a jedynie restartuje co chwila ekran i ostatecznie zostaje w trybie tekstowym, należy sprawdzić ustawienia w lts.conf, w szczególności opcję XSERVER. Często przy słabszych kartach i monitorach, które nie potrafią uruchomić się w rozdzielczości 1024x768, wystarczy dopisać do sekcji terminali: X_MODE_0 = 800x600 Jeśli po uruchomieniu i pomyślnym wystartowaniu serwera X na terminalu mamy jedynie szare tło i kursor na jego tle (nie uruchamia się KDM) najczęściej oznacza to problemy z protokołem XDMCP. Należy sprawdzić wówczas, czy w pliku /etc/kde/kdm3/kdmrc mamy odkomentowany wpis: [XDMCP] Enable = true To wszystko, jeśli chodzi o samodzielną instalację i uruchamianie LTSP. W przypadku dystrybucji Linux-EduCD oprogramowanie jest już zaimplementowane, więc przy konfiguracji sieci w płockim technikum większość z tych kroków można było pominąć. Wszystkie dostępne chipsety kart sieciowych, potrzebne do wygenerowania dyskietek, znajdują się w katalogu: /opt/bootroms. Dystrybucja pozwala na uruchamianie LTSP nawet podczas pracy z płyty CD, jednak zalecane jest oczywiście korzystanie z tego oprogramowania już po instalacji na dysku. Po zainstalowaniu na dysku Linux-EduCD otrzymujemy wstępnie skonfigurowany, oparty na Debianie system, który pracuje oczywiście dużo szybciej i wydajniej niż w przypadku działania z płyty. Po instalacji systemu operacyjnego na serwerze i założeniu odpowiedniej ilości kont ustawione zostały wspomniane opcje w pliku konfiguracyjnym lts.conf. Terminale w sieci to jedenaście jednakowych pecetów o parametrach AMD-K6 200 Mhz i 8 MB RAM. Wyposażone są w karty graficzne S3 Virge i karty sieciowe na chipsecie Realtek Poza napędem dyskietek, nie posiadają twardych dysków ani urządzeń CDROM. Należy pamiętać że w Linux-EduCD LTSP nie uruchamia się automatycznie. Żeby to zmienić, należy uruchomić skrypt start_ltsp, do którego dowiązanie znajduje się w katalogu domowym użytkownika root. Istotne jest to, że pierwsze (i wyłącznie pierwsze) uruchomienie, wprost po instalacji dystrybucji na dysku, należy zainicjować innym skryptem hdd_ltsp. Usługę możemy w dowolnej chwili zatrzymać, wykonując z kolei stop_ltsp lub wybierając z menu KDE opcję LTSP -> Zatrzymaj LTSP. Wszystkie wspomniane skrypty znajdują się w katalogu /opt, a ich dowiązania w /root. W pliku start_ltsp znajdują się w zasadzie polecenia uruchamiające takie usługi jak: DHCP, NFS, portmap i KDM, czyli dokładnie to, co jest potrzebne do zaistnienia komunikacji pomiędzy serwerem a stacjami roboczymi. W pliku /etc/exports zdefiniowane są wymagane zasoby. W Linux- EduCD zawartość tego pliku wygląda następująco: /opt/ltsp/i / (ro,no_root_squash,sync) /var/opt/ltsp/swapfiles / (rw,no_root_squash,async) /home / (rw,no_root_squash,sync) Powyższe opcje w zupełności wystarczają do sprawnego udostępniania głównego drzewa katalogów dla terminali, pliku wymiany (o ile jest stosowany) i katalogów domowych.

6 Możemy analogiczne wpisy ustawić także w przypadku instalacji LTSP w innym systemie. FIREWALL W zasadzie najbardziej optymalna konfiguracja serwera terminali to taka, w której ten stoi już za firewallem i sam nie udostępnia takich usług jak WWW, SMTP czy też DNS. Taki układ ma miejsce w przypadku płockiej sieci. W momencie, kiedy jednak to on jest bramą sieciową dla pozostałych komputerów, warto pamiętać, by poza maskaradą (NAT) odpowiednio ustawić reguły filtrowania pakietów. Wskazane jest, żeby wymagane przez LTSP demony NFS, portmap i inne, mogące stanowić potencjalną lukę w bezpieczeństwie systemu, nie były dostępne z zewnątrz. Konfigurację firewalla możemy przeprowadzić na dwa sposoby. Jako że popularniejszy w nowszych wersjach jądra Linuksa jest iptables posłużymy się właśnie nim. Pierwszy sposób to blokowanie określonych portów przez dodawanie kolejnych reguł odrzucających pakiety: iptables -A INPUT -p tcp -s 0/0 -d 0/0 --dport j DROP iptables -A INPUT -p udp -s 0/0 -d 0/0 --dport j DROP Powyższe reguły blokują np. port 2049 dla tcp i udp, wykorzystywany przez NFS. Posługując się taką metodą, będziemy musieli dla każdego portu, który chcemy zablokować, zdefiniować analogiczny wpis. Można też zastosować inną politykę domyślnie blokować wszystkie pakiety i dodawać reguły dopuszczające tylko poszczególne usługi: iptables -F iptables -A INPUT -i lo -p all -j ACCEPT iptables -A OUTPUT -o lo -p all -j ACCEPT iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT Akceptowanie połączeń nawiązanych iptables -A INPUT -p tcp --tcp-option! 2 -j REJECT --reject-with tcp-reset iptables -A INPUT -p tcp -i eth0 --dport 21 -j ACCEPT Otwieramy port FTP iptables -A INPUT -p udp -i eth0 --dport 21 -j ACCEPT iptables -A INPUT -p tcp -i eth0 --dport 22 -j ACCEPT Otwieramy port SSH iptables -A INPUT -p udp -i eth0 --dport 22 -j ACCEPT iptables -A INPUT -p tcp -i eth0 --dport 80 -j ACCEPT Otwieramy port HTTP iptables -A INPUT -p udp -i eth0 --dport 80 -j ACCEPT iptables -P INPUT DROP Domyślnie reszta jest blokowana Czasami zbyt restrykcyjnie zdefiniowane reguły mogą zablokować potrzebną do działania usługę (np. serwer DHCP). Po włączeniu reguł możemy w każdej chwili wyświetlić zastosowane zasady filtrowania pakietów poleceniem iptables -L -v. Poniżej przedstawiam kilka przydatnych sposobów na ułatwienie pracy administratora w opisywanej sieci terminali, są to: tworzenie kopii zapasowych, wsadowe zakładanie kont użytkowników, kontrola procesów oraz korzystanie z lokalnych napędów dyskietek na stacjach roboczych. Oczywiście możliwości jest o wiele więcej i wszystko zależy od konkretnych wymagań i potrzeb. KOPIE ZAPASOWE Niezbędną czynnością w sieci, w której terminale pracują jako stacje robocze, jest rzecz jasna wykonywanie kopii zapasowych. Pomimo że dane składowane są w zasadzie wyłącznie na dysku serwera LTSP, wskazane jest, aby tym bardziej dbać o ich bezpieczeństwo. W przypadku omawianej sieci - okresowo uruchamiany jest prosty skrypt, który wykonuje kopie katalogów

7 domowych wszystkich użytkowników, archiwizuje je do /opt/kopie_zapasowe i przesyła na oddzielny komputer w sieci o adresie Na komputerze tym, w katalogu /opt, znajduje się podkatalog terminale_kopie, do którego wędrują spakowane paczki. Nie jest to oczywiście wykonywanie kopii przyrostowych, a jedynie prosty sposób na pełne zarchiwizowanie danych. Skrypt kopiuje całą zawartość katalogów domowych, poza katalogiem tymczasowe. Jeśli użytkownicy mają jakieś mało istotne dane, które nie muszą być archiwizowane, mogą umieszczać je właśnie w tym katalogu: #!/bin/bash # najpierw tworzymy katalog /opt/terminale_kopie na zdalnym hoście mkdir /opt/kopie_zapasowe cd /home users=`ls` for x in $users do tar zcvf /opt/kopie_zapasowe/${ x}.tgz /home/${x} --exclude=tymczasowe done scp -r /opt/kopie_zapasowe :/opt/terminale_kopie Jeśli istnieje potrzeba wykonywania kopii przyrostowych, należy synchronizować zawartość zdalnego /opt/terminale_kopie z lokalnym /opt/kopie_zapasowe. Można posłużyć się w tym celu programem rsync. W przeciwieństwie do programu tar, rsync przesyła zmiany, jakie zaszły od czasu wykonania ostatniej kopii. Polecenie: rsync -ave ssh :/opt/terminale_kopie/ /opt/kopie_zapasowe/ spowoduje, że kopia przed wysłaniem będzie odpowiednio zsynchronizowana. WSADOWE TWORZENIE KONT UŻYTKOWNIKÓW Wbrew pozorom, zakładanie kont systemowych w szkolnej lub uczelnianej pracowni wcale nie musi być sprawą łatwą. Przy założeniu, że z pracowni ma korzystać np. pięć średniej wielkości grup/klas, a każdy student/uczeń ma mieć własne konto, wychodzi nam przynajmniej setka użytkowników. Oczywiście wpisywanie dla każdego konta polecenia useradd i dwukrotne powtarzanie hasła nie jest najciekawszym rozwiązaniem w takiej sytuacji. Z pomocą może nam przyjść program newusers. Służy on do wsadowej aktualizacji i tworzenia kont nowych użytkowników. Wystarczy, że dysponujemy listą zawierającą pary: użytkownik:hasło, dopiszemy do każdej linii informacje na temat katalogu domowego i możemy jednym poleceniem załatwić resztę formalności. Hasło powinno być podane jawnym tekstem, ponieważ newusers sam zajmie się jego zaszyfrowaniem. Na serwerze technikum użyliśmy listy users z wpisami: uczen1:password::::/home/uczen1: testowe1:password2::::/home/testowe1 Należy pamiętać o odpowiedniej ilości znaków :. W zasadzie format tego zapisu jest analogiczny do wpisów w /etc/passwd. Jeśli lista jest gotowa, wykonujemy polecenie newusers users. Po chwili konta są już założone, a za pomocą polecenia chpasswd można aktualizować zbiorowo hasła.

8 AUTOMATYCZNE WYLOGOWYWANIE Wszystkie aplikacje i procesy uruchamiane przez terminale rezydują na serwerze. Daje to dużą kontrolę nad wszelkimi działaniami użytkowników. W momencie kiedy są zalogowani, możemy sprawdzać, jak długo pracują i z jakich korzystają aktualnie programów. Wiemy, że w pliku /etc/hosts nasze terminale nazwane są kolejno: ws001, ws002. Wystarczy więc przefiltrować odpowiednio procesy, żeby sprawdzić, ile takich terminali aktualnie pracuje: ps ax grep ws Możemy w analogiczny sposób sprawdzić, jakie aplikacje są wykorzystywane oraz czy pracują wszystkie usługi odpowiedzialne za LTSP. Użytkowników możemy wylogować z serwera w każdej chwili, posługując się prostym skryptem i nazwą użytkownika, podaną jako parametr. Skrypt o nazwie wyloguj znajduje się poniżej: #!/bin/sh # skrypt do wylogowania użytkowników LTSP if [ $1!= 'root' ] then for i in $(pgrep -u $1) do kill -9 $i done else clear echo 'Nie można zabić sesji roota' fi Po utworzeniu takiego skryptu należy oczywiście nadać mu atrybut wykonywalności. Jeśli zalogowany jest np. użytkownik rajmund, wystarczy jako root wykonać polecenie:./wyloguj rajmund LTSP jest z pewnością bardzo użytecznym oprogramowaniem. Sprawdza się znakomicie jako niezwykle wydajny system terminali, drobiazgowo przemyślany zarówno pod kątem funkcjonalności, jak i łatwości obsługi. Po więcej szczegółowych informacji odsyłam do oficjalnej dokumentacji. Strona projektu LTSP: Strona projektu Etherboot: Dystrybucja Linux-EduCD: