Linie generală subțire: transferăm biroul către clienți subțiri care rulează Thinstation. Instalarea și configurarea clientului subțire Thinstation

EVGENY BUSHKOV

Ghid detaliat de configurare
thin clients bazați pe distribuția Thinstation și pe protocolul NX

Tehnologia NX, dezvoltată de Nomachine, oferă noi opțiuni de conectivitate și poate revitaliza computerele vechi ca client subțiri.

Înainte de a trece direct la descrierea NX, voi enumera câteva tendințe care devin evidente pentru mulți astăzi companii mari tara noastra:

Echipamentele informatice devin din ce în ce mai ieftine și mai accesibile decât înainte. În același timp, productivitatea sa se dublează la fiecare 1,5-2 ani conform legii lui Moore. Acest lucru duce la acumularea de echipamente care nu și-au epuizat durata de viață, dar sunt deja depășite.
Aplicațiile client-server dezvoltate la întreprinderi de programatori din departamentele de sisteme de control automatizate în anii perestroika încă funcționează pe tehnologie veche, dar nu mai îndeplinesc cerințele vremii.
Modern softwareȘi OS nu poate fi făcut să funcționeze pe computere cu procesoare din generațiile anterioare (i386, i486 etc.).
Nu este un secret pentru nimeni că în multe organizații din țara noastră, de mult timp, multe programe și sisteme de operare pe care angajații le-au instalat din proprie inițiativă au fost folosite ilegal. La început acest lucru a fost văzut ca un lucru firesc, dar apoi a fost justificat de situația financiară. Acum că țara noastră se aderă la OMC, guvernul este nevoit să corecteze rapid această situație, prin urmare, presiunea asupra întreprinderilor din partea autorităților interne pentru a abandona software-ul și sistemele de operare utilizate ilegal.

Există o contradicție evidentă între al doilea și al treilea punct: este necesar fie să se găsească o modalitate de a utiliza eficient tehnologia veche pentru a îndeplini sarcinile moderne, fie să se abandoneze această tehnologie. Dacă există suficiente fonduri, atunci alegerea este clară. Dar ce să faci dacă nu există fonduri sau nu există nicio modalitate de a anula astfel de echipamente și este păcat să-l arunci? Și cum să rezolvi problema nu mai puțin acută a „purității licențiate” a programelor utilizate, care este menționată în al patrulea paragraf?

Tehnologiile terminale vin în ajutor, permițându-vă să utilizați computere vechi și, de asemenea, să eliminați parțial problemele de „puritate a licenței” dacă utilizați soluții bazate pe produse Open Source.

Revista a publicat deja mai multe articole despre lucrul cu distribuția Thinstation [,]. În acest articol, voi vorbi despre specificul experienței de configurare și operare în întreprinderea mea cu clienți subțiri bazați pe distribuția Thinstation și tehnologia NX dezvoltată de Nomachine.

Până de curând, în lumea comunicațiilor cu terminale erau puține cunoscute de succes protocoale de rețea la nivel înalt, capabil să comprima și să cripteze eficient traficul dintre clientul subțire și server. Cele mai cunoscute și populare dintre ele sunt RDP de la Microsoft și ICA de la Citrix. Ambele protocoale sunt utilizate de servere bazate pe sistemul de operare MS Windows. M-a interesat posibilitatea de a folosi thin clients cu servere pornite Bazat pe Linux. Ca bază pentru clientul subțire, un mic kit de distribuție, un fel de designer Linux, Thinstation a fost ales aproape imediat ca fiind cel mai constant și mai popular în țara noastră și în străinătate. Dar, odată cu alegerea protocolului care ar fi responsabil de comunicarea cu serverul, a trebuit să schimb și să experimentez. Voi enumera principalele criterii după care a fost selectat protocolul. În primul rând, am vrut să folosim cât mai mult posibil gamă largă Avem o mulțime de computere vechi cu procesoare care încep de la i486, cu o cantitate minimă de memorie. În al doilea rând, au dat deoparte produse comerciale: Nu am vrut să suportăm costuri suplimentare. În al treilea rând, este necesar un suport bun pentru limba rusă și alfabetul chirilic, precum și prezența unui mod familiar prin care utilizatorii pot comuta între aspecte - combinații de taste . În al patrulea rând, în cadrul unei rețele locale, nu trebuie să acceptăm criptarea, dar compresia și minimizarea traficului de rețea sunt importante.

Găsirea unei soluții

În primul rând, am acordat atenție VNC ca fiind cel mai comun și disponibil în orice distribuție Linux, precum și un produs ușor de configurat. Când trebuie să vă conectați la un desktop de la distanță al unui server Linux cu stație de lucru Windows sau Linux, primul lucru care îmi vine în minte este VNC. Descărcați cea mai recentă versiune a distribuției Thinstation, apoi dezarhivați fișierul arhivă rezultat în directorul dvs. de acasă. Să presupunem că calea către distribuție arată astfel: ~/thinstation. Fișierul responsabil pentru parametrii de construcție se află aici: ~/thinstation/build.conf. Are comentarii detaliate. Despre configurarea acesteia, precum și despre cum să forțați imaginea Thinstation să pornească folosind card de retea cu un cip nedorit, nu voi intra în detalii, despre asta s-a scris deja în articolele menționate. Voi enumera pe scurt pașii pentru configurarea clientului: editați ~/thinstation/build.conf și creați o imagine rulând scriptul ~/thinstation/build. Copiem fișierul imagine finit ~/thinstation/boot-images/etherboot/thinstation.nbi pe serverul TFTFP. Adăugăm o intrare despre adresa MAC a plăcii de rețea a clientului subțire la fișierul de configurare dhcp.conf al serverului DHCP. În directorul serverului TFTP, creați un fișier cu setările pentru această adresă MAC și/sau editați fișierul thinstation.conf.network. Setarile mele sistem de lucru poate fi văzut în lista secțiunii „Configurarea și crearea unei imagini Thinstation” și în Fig. 1.

Pentru a adăuga un pachet client VNC la imagine, decomentați linia „#package vncviewer” din Fișier de configurare~/thinstation/build.conf. Dacă directorul serverului tftp se află în /tftpboot (cum este și pentru mine), atunci editați fișierul /tftpboot/thinstation.conf.network astfel încât liniile să apară în el:

SESSION_0_TYPE=vncviewer
SESSION_0_TITLE="VNC" !}
SESSION_0_VNCVIEWER_SERVER=10.10.10.10:5901

Înlocuiți adresa IP 10.10.10.10 cu adresa serverului dvs. VNC.

Acum să verificăm imaginea asamblată cu noul parametru în funcțiune: porniți clientul subțire, așteptați descărcarea și lansarea imaginii Thinstation, conectați-vă la serverul VNC. Vă rugăm să rețineți că schimbarea aspectului are loc utilizând tasta „Alt dreapta”. De fapt, nu clientul VNC este de vină aici, ci fișierul Thinstation din pachetul de suport keymaps-ru Cyrillic. Pentru a nu petrece mult timp căutând o soluție la problemă, am generat un fișier xkb pe sistemul SUSE-10.0 configurat după cum urmează:

xkbcomp:0 ru.xkb
xkbcomp -xkm ru.xkb ru.xkm

Utilitarul xkbcomp convertește descrierea aspectului XKB într-unul dintre formate. Prima comandă generează un dump a aspectului curent din sursă, care este afișajul X „:0”. A doua comandă compilează fișierul rezultat într-o formă binară care poate fi citită de sistem. Inlocuim dosarul original la a ta:

cp -f ru.xkm ~/thinstation/packages/keymaps-ru/x-common/lib/kmaps/xkb

După asamblarea imaginii, obținem comutarea normală a layout-urilor în funcție de . Dar clientul VNC este inacceptabil de lent. Pe computerele cu un procesor mai mic decât P-200, începe un fel de „prezentare de diapozitive”, când orice acțiune pe desktop-ul de la distanță este însoțită de o desenare pe îndelete a acestor modificări pe ecranul monitorului clientului subțire. Există multe soluții VNC care folosesc metode similare de codificare a datelor în timpul transmisiei, toate folosind protocolul Remote FrameBuffer (RFB). Ele diferă prin numărul de funcții, parametrii de codificare a datelor și numărul de platforme acceptate. De exemplu, RealVNC acceptă server și client pentru Windows, UNIX, Microsoft PocketPC și Mac OS X, TightVNC include server și client pentru Windows și UNIX, VNC pentru DOS - client pentru DOS, UltraVNC - server și client pentru Windows, OSXvnc - server și client pentru Mac OS X. Am testat RealVNC și TightVNC: al doilea produs (atât server, cât și client) este subiectiv puțin mai rapid, dar ambele creează un efect de „slideshow” pe computerele mai slabe. Va trebui să încercăm altceva ca protocol de comunicare între client și server. Să lăsăm VNC în pace deocamdată, va trebui să revenim la el mai târziu. Aici am apelat la NX.

Suportul pentru clientul Nomachine NX a apărut pentru prima dată în Thinstation versiunea 2.1 în 2005, iar cel mai recent este în prezent 2.2, care va fi implicat mai jos. Pentru a construi o imagine cu pachetul NX, înainte era necesar accesul direct la Internet în cele mai recente versiuni ale Thinstation, a devenit posibilă specificarea căii către fișier cu prefixul „file://”. Clientul utilizat și susținut de distribuția Nomachine NX este încă la versiunea 1.5.x, deși a trecut destul de mult timp de la lansarea noii versiuni NX 2.0. În fișierul de configurare build.conf, decomentați linia „pachet nx”, tot la sfârșitul fișierului vom găsi linia „param nxurl”: indicați calea către fișierul predescărcat sau lăsați-o așa cum este ( aveți nevoie de acces la internet). Copiem imaginea rezultată generată în directorul serverului tftp, copiem fișierul thinstation.conf.sample din rădăcina distribuției de acolo, îl redenumim în thinstation.conf.network și îl edităm: căutați #SESSION_0_TYPE=NX și editați rândurile aferente acestei sesiuni ( aici cu numărul 0), introducând parametrii necesari.

Pornim clientul subțire și încărcăm imaginea creată, verificând performanța. Progresul este evident: „prezentarea” se oprește pe computerele cu procesor P-100, P-120 și superior. Acest lucru nu este ceea ce ne-am dori să obținem ca rezultat, așa că PC-urile cu procesoare i486 nu vor putea fi folosite aici. Am numit astfel de PC-uri clienți „superthin” și le-am configurat să funcționeze cu programe DOS folosind o combinație de FreeDOS și sshdos pe partea client și Dosemu pe partea serverului Linux. Nu voi vorbi despre ele în acest articol. Cu toate acestea, acesta este un rezultat bun, să ne uităm la cerințele hardware de la dezvoltatorii Thinstation și clientul NX: primii recomandă un procesor i486 și 16 MB de memorie, cei din urmă recomandă un procesor cu o frecvență de 400 MHz și 128 MB a memoriei. Să determinăm empiric procesorul și volumul P-120 ca configurație minimă necesară pentru ca un client subțire să lucreze cu pachetul NX. memorie cu acces aleator 32 MB. Am testat alți clienți, în special XRDP, VNC pentru DOS, dar dintr-un motiv sau altul alternativa reala Nu am găsit NX. Acum este timpul să aruncăm o privire mai atentă asupra tehnologiei NX.

Recenzie și scurtă descriere a Nomachine NX

Arhitectura NX este un set de tehnologii Open Source și instrumente comerciale concepute pentru a face calculul în rețea ușor și distribuit. Este format din software-ul server care permite oricărui computer UNIX să devină un server terminal și clienți pentru o gamă largă de platforme și sisteme de operare. Nomachine a ales ca bază pentru arhitectura NX binecunoscutul și larg utilizat sistem X-Window, pe care se bazează GUI-urile Linux și ale altor sisteme de operare UNIX.

Cele mai disponibile solutii de retea nu a fost conceput ca mijloc principal pentru utilizatori de a accesa desktopul. Protocoale precum RDP și VNC sunt mult mai simple decât X (și, prin urmare, sunt potrivite pentru clienții subțiri), dar simplitatea lor nu compensează lipsa de eficiență și funcționalitate. De exemplu, aceste protocoale sunt folosite pentru a desena ecran de la distanță transferul unor volume mari de date de imagine. Deși RDP este un protocol mai eficient decât RFB (protocolul folosit de VNC), nu a fost conceput inițial pentru utilizarea zilnică de către dispozitivele din rețea, ci doar ca o extensie a sistemului de operare. X-Window este subsistem grafic(nu este o extensie a sistemului de operare), iar aplicațiile X interacționează cu acesta folosind protocolul X, așa că sistemul de operare nu are nivel special, responsabil pentru difuzarea actualizărilor ecranului la protocolul de rețea.

Principalele dezavantaje ale rețelelor X-terminale sunt redundanța și întârzierile în transferul datelor grafice X-protocol. De la apariția X-Window, desktop-ul utilizatorului a dobândit tot felul de elemente graficeși efecte care au crescut cererile asupra rețelelor de date.

În fig. Figura 1 sub numărul 1 arată munca tradițională asupra protocolului X: nu există compresie, cerințele pentru lățimea de bandă a rețelei și întârzierile sunt critice. Permiteți-mi să vă reamintesc că în ideologia X-Window, serverul X rulează pe terminal, iar pe serverul terminal există un client X care trimite cereri către serverul terminal X.

În cel mai simplu caz, puteți rula aplicații cu ieșire grafică folosind opțiunea -X a comenzii ssh, de exemplu, „ssh -X me@server firefox”. Puteți adăuga parametrul -C pentru compresie (se folosește biblioteca ZLIB). De asemenea, puteți optimiza viteza de interacțiune cu nodurile prin creșterea debitului rețelei. Dar există o limită peste care creșterea lățimii de bandă nu va mai afecta viteza acestei interacțiuni. Motivul pentru aceasta este schimbul intens de cereri/răspuns al aplicațiilor X moderne.

NX folosește trei metode principale pentru a accelera aplicațiile: compresia, stocarea în cache și suprimarea traficului excesiv de protocol X.

Toate cele trei metode se combină pentru a obține o îmbunătățire de 70 de ori a experienței X GUI la distanță în timp ce se utilizează cel mai înalt nivel de compresie pe legături cu lățime de bandă redusă și latență mare (în setările clientului NX, „modem” corespunde cu compresie maximăși „lan” – fără compresie). În fig. 1 sub numărul 2 arată relația componentelor NX: compresia/decompresia și caching-ul sunt efectuate pe modulele NX Proxy, traficul trece între ele prin protocolul NX, cerințele pentru calitatea liniilor de comunicație sunt minime, se precizează că acestea pot functioneaza pana la viteze de 9600 bps.

Similar cu nxagent care transmite trafic X, există un alt agent („nxviewer”) care traduce traficul RFB/VNC în protocolul NX. Acest lucru îmbunătățește eficiența conexiunii de până la 10 ori în comparație cu rularea unui vncviewer obișnuit care conectează un afișaj X local la server la distanta VNC. Ne vom asigura de asta.

În fig. 1 sub numărul 3 arată posibilitatea funcționării simultane a diferiților agenți NX, RDP, VNC. În același timp, agenții NX traduc în mod eficient protocoalele străine în propriile lor și apoi transmit trafic prin NX Proxy.

Proxy NX– această componentă este tocmai responsabilă de compresie/decompresie: în modul client codifică cererile de la clienții X și decodifică răspunsurile de la serverul X, în modul server – invers.
Agent NX– termenul „agent” este folosit pentru a descrie componenta la care este transmisă imaginea generată înainte de a fi transmisă în rețea printr-un proxy.
NX Viewer– un client VNC obișnuit Nomachine modificat care traduce traficul VNC/RFB în protocolul NX.
Desktop NX– Client RDP care traduce traficul RDP în protocolul NX.

Nomachine a deschis codurile sursă ale majorității dezvoltărilor și bibliotecilor sale, acestea putând fi descărcate de oricine din . Build-urile de la Nomachine în sine sunt disponibile pentru toți clienții gratuit, există și diverse opțiuni ansambluri de servere NX, furnizate contra cost: un abonament anual la NX Enterprise Server cu un număr nelimitat de utilizatori și numărul de procesoare 1-2 costă 1494 USD, cel mai mult solutie completa cu echilibrarea încărcăturii și gestionarea nodurilor bazate pe NX Advanced Server va costa 3.494 USD. În plus, există o variantă NX Ediție gratuită, care poate fi descărcat gratuit, dar are o limită a numărului de conexiuni simultane și de utilizatori egală cu doi, așa că dacă doriți să administrați un server Linux de acasă folosind un modem analog obișnuit, atunci această soluție nu poate fi găsită mai bună, mai sigură si mai usor. Voi remarca, de asemenea, prezența versiunilor client ale NX Client Desktop Edition pentru PlayStation 2 (cu folosind Linux Kit), precum și NX Client Embedded Edition pentru Sharp Zaurus 5xxx și HP/Compaq iPAQ. De asemenea, pot fi descărcate gratuit. Deci, dacă sunteți într-o călătorie de afaceri și aveți doar un PDA cu dvs., nimic nu vă împiedică să vă conectați și să lucrați de la distanță pe serverul dvs. Linux.

Construirea și rularea NX

La rândul său, pe baza open source, comunitatea a dezvoltat o versiune a părții serverului NX numită FreeNX, precum și KNX, un client pentru conectarea la server de sub X. FreeNX este un set de scripturi shell care, împreună cu biblioteci deschise de la NX, formează partea de server (backend).

La începutul lucrului cu NX, am folosit un PC cu SUSE 10.0 ca server. FreeNX era deja asamblat ca parte a distribuției, dar, în primul rând, avea mai mult de un an și, în al doilea rând, după ce am întâmpinat primele dificultăți în timpul lucrului, am decis că este timpul să asamblam partea de server din codul sursă. eu insumi. Voi vorbi despre asamblarea din codul sursă al versiunii 1.5 ca fiind cea mai testată în timp, apoi voi clarifica ce caracteristici există pentru asamblarea versiunii 2.0 (2.1).

În prezent, codul sursă pentru versiunea NX 2.0 este postat pe site-ul web Nomachine, această versiune este recomandată de companie, iar codul sursă pentru versiunea 1.5 este disponibil și acolo link special. Descărcați cele mai recente versiuni ale următoarelor tarball-uri de pe pagină: nx-X11, nxagent, nxcomp, nxcompext, nxdesktop (dacă aveți nevoie de suport RDP), nxproxy, nxscripts, nxviewer (dacă aveți nevoie de suport VNC). nx-X11 este versiunea 4.3 a Xfree86, care a modificat bibliotecile Nomachine X. Unele dintre surse vor fi despachetate direct în arborele nx-X11, așa că îl vom extinde mai întâi, ordinea despachetării tarball-urilor rămase nu este importantă, principalul lucru este că toate sunt despachetate într-un singur director. Acolo descarcăm și despachetăm scripturile FreeNX de la adresa . Veți avea nevoie și de două patch-uri, descărcați-le de aici [,]. Directorul nostru de asamblare va arăta astfel:

freenx-0.4.4
nx-X11
nxcomp
nxcompext
nxdesktop
nxproxy
nxscripts
nxviewer
freenx-lfs_hint.diff
NX-lfs_hint.diff

Pentru a construi, veți avea nevoie de următoarele pachete (pot fi instalate din distribuția dvs. Linux): libjpeg-devel, libpng-devel, openssl-devel, netcat, expect. O descriere a ansamblului poate fi găsită și aici.

# Aplicați patch-ul NX
patch -p0< NX-lfs_hint.diff

# Asamblarea X – cea mai lungă parte, poate dura până la o oră
pushd nx-X11
face lumea
popd

#nxproxy
pushd nxproxy
./configure --prefix=/srv/NX
face
popd

# Construiți agentul RFB
pushd nxviewer
xmkmf -a
cp -a /usr/X11R6/lib/libXp.so* ../nx-X11/exports/lib/
face 2> /dev/null
popd

# Construirea agentului RDP
pushd nxdesktop
./configure --prefix=/srv/NX --sharedir=/srv/NX/share
face
popd

# Întreaga parte a serverului va fi localizată în directorul /srv/NX, creați unele dintre subdirectoare
mkdir -p /srv/NX/bin
mkdir -p /srv/NX/lib
mkdir -p /srv/NX/man/man1
mkdir -p /srv/NX/share/doc

# Instalați bibliotecile și agenții colectați
cp -a nx-X11/lib/X11/libX11.so.* nx-X11/lib/Xext/libXext.so.* nx-X11/lib/Xrender/libXrender.so.* /srv/NX/lib
instalați -m 755 nx-X11/programs/Xserver/nxagent /srv/NX/lib

# Creați un script nxagent care va gestiona toate programele
cat > nxagent<< "EOF"

#!/bin/sh

NXCOMMAND=$(nume de bază $0)

export LD_LIBRARY_PATH=/srv/NX/lib:$LD_LIBRARY_PATH
exec /srv/NX/lib/$NXCOMMAND $(1+"$@")
EOF

# Și instalează-l:
instalați -m 755 nxagent /srv/NX/bin

# Instalați biblioteci de compresie și proxy
cp -a nxcomp/libXcomp.so.* /srv/NX/lib
cp -a nxcompext/libXcompext.so.* /srv/NX/lib
instalați -m 755 nxproxy/nxproxy /srv/NX/lib
ln -snf nxagent /srv/NX/bin/nxproxy

# Instalarea agentului RFB
pushd nxviewer
faceți instalarea DESTDIR=/srv/NX
mv /srv/NX/usr/X11R6/bin/nxviewer /srv/NX/lib
ln -snf nxagent /srv/NX/bin/nxviewer
chmod 755 /srv/NX/bin/nxviewer
mv /srv/NX/usr/X11R6/bin/nxpasswd /srv/NX/bin
popd

# Instalarea unui agent RDP
pushd nxdesktop
face instalarea
mv /srv/NX/bin/nxdesktop /srv/NX/lib
ln -snf nxagent /srv/NX/bin/nxdesktop
chmod 755 /srv/NX/bin/nxdesktop
rm -rf /srv/NX/usr
popd

# Instalarea scripturilor

# Instalați FreeNX
mkdir -p /srv/NX/etc
mkdir -p /srv/NX/var
mkdir -p /srv/NX/var/db
mkdir -p /srv/NX/home
mkdir -p /srv/NX/home/nx
pushd freenx-0.4.4

# Aplicați patch-ul freenx, în principal aici căile sunt corectate pentru a se potrivi cu /srv/NX
patch -p0< ../freenx-lfs_hint.diff
cp -a nxnode /srv/NX/bin
cp -a nxserver /srv/NX/bin
cp -a nxsetup /srv/NX/bin
cp -a nxkeygen /srv/NX/bin
cp -a nxnode-login /srv/NX/bin
cp -a nxloadconfig /srv/NX/bin
cp -a nxclient /srv/NX/bin
cp -a nxprint /srv/NX/bin
instalați -m 755 node.conf.sample /srv/NX/etc
popd

# Adăugați utilizator și grup nx
groupadd -g 77 nx
useradd -c „Utilizator FreeNX” -d /srv/NX/home/nx -g nx -s /bin/bash -u 77 nx
chown -R root.root /srv/NX
chown -R nx.nx /srv/NX/home/nx

# Următorul este un punct important: înainte de a rula, citiți parametrii de lansare a comenzii: /srv/NX/bin/nxsetup –help.
# Dacă doriți să utilizați autentificarea utilizatorului bazată pe cheie, eliminați opțiunea –setup-nomachine-key.
# Pentru a lucra cu clienți subțiri, nu trebuie să schimbați nimic
/srv/NX/bin/nxsetup --install --uid 77 --gid 77 --setup-nomachine-key

# Verificați dacă serverul NX rulează:
/srv/NX/bin/nxserver --status

Răspunsul ar trebui să fie cam așa:

NX>100 NXSERVER - Versiunea 1.4.0-44 OS (GPL)
Serverul NX> 110 NX rulează
NX>999 La revedere

Instalați fișierul de configurare freenx:

mv /srv/NX/etc/node.conf.sample /srv/NX/etc/node.conf

În fișierul de configurare găsim următoarea linie și decommentăm:

ENABLE_1_5_0_BACKEND="1"

Acolo puteți activa și înregistrarea pentru prima dată:

NX_LOG_LEVEL=6

Acum puteți instala clientul Nomachine NX pe orice computer Linux (puteți folosi și KNX) sau Windows și verificați funcționarea serverului NX. Puteți lucra cu serverul atât în modul aplicație, cât și în modul desktop la distanță.

Configurarea și crearea unei imagini Thinstation

Din partea serverului NX, să trecem acum la crearea imaginii Thinstation. Distribuția în sine poate fi descărcată aici. La asamblarea imaginii, vom încerca să reducem cât mai mult posibil numărul de module și pachete, aruncând tot ce nu este necesar. Deoarece multe computere selectate ca client subțiri vor avea hardware și periferice diferite, aș dori să mută pachetele individuale din cadrul unei imagini comune pentru toți. Thinstation are această opțiune: pkg înseamnă a construi ca un pachet descărcabil separat cu extensia pkg, pachet înseamnă a fi inclus într-o imagine comună. Pachetele lprng, sshd, samba-server și altele sunt cu siguranță colectate ca descărcabile. Puteți specifica toate pachetele cu drivere de placă video X ca pachet, dar apoi, la construirea imaginii, vor apărea câteva pachete suplimentare pe care toată lumea va trebui să le încarce și, ca urmare, dimensiunea totală a datelor încărcate va fi mai mare. Să o facem mai simplu: unul dintre driverele video cele mai des folosite, și anume S3, va fi specificat ca pachet, restul - pkg. Modulele pot fi mutate și în afara nucleului, dar până acum această caracteristică nu a funcționat corect și ocupă foarte puțin spațiu în interiorul nucleului. Mai jos este fișierul meu de configurare build.conf:

modul serial
modul intel-agp
modul via-agp
modulul 8139 de asemenea
discheta modulului
modul vfat
modul supermount
pkg xorg6-ati
pachet xorg6-i810
pachet xorg6-nv
pachet xorg6-s3
pachet xorg6-s3virge
pkg xorg6-sis
pkg xorg6-trident
hărți de taste ale pachetului
pachet nx
pachet lprng
pachet sshd
pkg samba-server
param rootpasswd vă rog să mă schimbați
param xorgvncpasswd, vă rog, schimbați-mă
param bootlogo false
rezoluție param boot 800x600
param defaultconfig thinstation.conf.buildtime
param basename thinstation
param basepath .
param knownhosts ./known_hosts
param localpkgs adevărat
param locații complete false
param bootverbosity 3
param nxurl file://home/zhen/sources/nx/bin/nxclient-1.5.0-141.i386.tar.gz

Dacă veți imprima la o imprimantă conectată la un client subțire folosind lprng, va trebui să faceți o mică modificare la fișierul thinstation/packages/lprng/etc/init.d/lprng. Pentru a face acest lucru, înlocuiți linia:

echo „$PRINTER_X_NAME:lp=$PRINTER_X_DEVICE:wd=$PRINTER_X_DRIVER:br=$PRINTER_X_OPTIONS:lf=/var/log/spooler.log:sh:sf” >> /etc/printcap

echo "$PRINTER_X_NAME:lp=$PRINTER_X_DEVICE:wd=$PRINTER_X_DRIVER:br=$PRINTER_X_OPTIONS:if=/bin/lpf:lf=/var/log/spooler.log:sh:sf" >> /etc/printcap

Adăugarea de filtrare locală a eliminat problema scărilor la imprimare. În plus, am creat următorul script pentru a testa dacă imprimarea funcționează în ~/thinstation/packages/base/bin/my:

#!/bin/sh
echo PRINTER TEST la /dev/printers/0 1>&2
pentru i în 1 2 3 4 5 6 7 8 9;
do
echo PRINTER /dev/printers/0 $i > /dev/printers/0;
Terminat
echo -e \\r\\f > /dev/printers/0
ieșire 0;

Când nu este clar ce anume nu funcționează, puteți rula acest script pe consola clientului subțire: /bin/my.

Pentru a preveni o fereastră de avertizare despre o gazdă necunoscută să apară de fiecare dată când conectați un client NX la server, creați un fișier known_hosts în rădăcina Thinstation:

ssh-keyscan -t rsa nxserver_ip>>~/thinstation/known_hosts

Ca „nxserver_ip” trebuie să specificați adresa IP a serverului NX. În acest fel, clientul va ști despre amprenta digitală a cheii RSA a serverului NX în timpul autentificării.

După executarea cu succes a construcției, copiați thinstation/boot-images/etherboot/thinstation.nbi și thinstation.nbi.zpxe, precum și toate fișierele pkg din thinstation/boot-images/pkg-packages în directorul /tftpboot de pe serverul tftp . Fișierul thinstation.nbi.zpxe pe care îl cream nu a funcționat, în acest caz puteți descărca fișierul BootPXE535.zip de la această adresă, această arhivă conține un loader universal loader-native.zpxe, totul ar trebui să funcționeze cu el.

Fișierele de configurare Thinstation sunt destul de bine comentate, dar procesul de configurare în sine și succesiunea acțiunilor nu sunt întotdeauna evidente, așa că voi menționa în continuare unele dintre dificultățile pe care am avut de întâmpinat și subtilitățile.

În fig. Figura 3 prezintă pașii principali pentru punerea în funcțiune a clientului subțire. Mai întâi, adăugați informații despre adresa MAC a plăcii de rețea la dhcpd.conf. Nu uitați să specificați setările legate de tftp în descrierea subrețelei, acestea sunt stabilite de directivele „next-server” și „option root-path”. Serviciile mele tftp și dhcp sunt situate pe același server FreeBSD, acest lucru ușurează configurarea lor. Toate fișierele de setări se află în /tftpboot. Apoi în fișierul thinstation.hosts scriem în ordine: un nume de gazdă arbitrar (este mai bine să includă informații despre locația terminalului), adresa MAC, grupuri din care terminalul este membru, la sfârșitul liniei puteți plasa comentarii după semnul „#”, de exemplu:

otd146_57158 00e04d08d710 smb_flop_hard monitor TUX1C #PC foarte important

Iată în ordine: numele gazdei, în cazul meu, constă din numărul departamentului și numărul de inventar, apoi MAC-ul și apoi o listă a numelor fișierelor de configurare care vor fi folosite de această gazdă.

Apoi, creăm un fișier de setări thinstation.conf-MAC, eu folosesc adresa MAC în nume, deși puteți folosi adresa IP sau numele de la thinstation.hosts. Rețineți că aici se utilizează numai adresa MAC din numele fișierului litere mari. Grupurile sunt descrise în fișierele numite thinstation.conf.group-GROUPNAME. Fișierul thinstation.conf-MAC conține acele setări care se aplică numai acestui terminal și nu sunt incluse în alte grupuri. De exemplu, toate setările generale ale monitorului sunt descrise în fișierul thinstation.conf.group-monitor și un parametru „SCREEN_VERTREFRESH” este mutat în fișierul thinstation.conf-MAC. Acest lucru se datorează faptului că sunt utilizate diferite monitoare, iar setarea ratei de cadre a ecranului poate fi modificată, acesta și alți parametri pot fi configurați pentru fiecare terminal sau pentru toți simultan. Același lucru este valabil și pentru setările mouse-ului. În mod implicit, setarea este făcută pentru un mouse PS/2. Dacă se folosește un mouse conectat la portul COM1, atunci sunt specificați doi parametri „MOUSE_PROTOCOL=Microsoft” și „MOUSE_DEVICE=/dev/ttyS0”, dacă la portul COM2, al doilea parametru este /dev/ttyS1.

Fișierul meu de configurare comun /tftpboot/thinstation.conf.network este aproape gol. Toate informațiile din acesta sunt incluse în fişiere separate setările de grup, la care se face referire în thinstation.hosts. Deoarece sunt utilizate două servere terminale cu versiuni diferite de NX și fiecare client folosește doar propriul server, configurațiile sunt plasate în fișiere text separate (NX și TUX1C), în plus, sunt folosite diferite imagini Thinstation. De asemenea, nu uitați că numele fișierelor thinstation.nbi și thinstation.nbi.zpxe sunt interdependente: dacă linia este specificată în dhcpd.conf:

thinstation.nbi.zpxe";

atunci se va folosi imaginea thinstation.nbi, în cazul meu sunt mai multe imagini și, în consecință, intrările din dhcpd.conf sunt diferite pentru fiecare terminal.

Diferențele de construcție NX2

Sistemul nostru folosește două servere NX. One rulează NX, compilat din versiunile de cod sursă 1.5, iar clienții 1.5.x sunt folosiți pentru a lucra cu acesta. Celălalt rulează NX versiunea 2.0. Vă voi spune care sunt diferențele în funcționarea și asamblarea acestei versiuni. Serverul are instalate Opteroni pe 64 de biți și utilizează sistemul SLES 10.0 x86_64. Deci, nu am putut construi NX pe acest server în același mod ca în cazul NX 1.5 pe un sistem pe 32 de biți, chiar și atunci când am încercat să specific în mod explicit construcția pentru un sistem pe 32 de biți:

faceți lumea BOOTSTRAPCFLAGS="-m32"

Aparent, acestea sunt caracteristici ale sistemului pe 64 de biți și ale bibliotecilor sale. Puțin mai târziu, am găsit o notă pe site-ul Nomachine care spunea că codul sursă NX a fost dezvoltat pentru sisteme pe 32 de biți, dar poate fi folosit și pe sisteme pe 64 de biți. Deoarece încă mai am un computer cu SLED 10.0 x86 instalat și versiunile tuturor bibliotecilor, nucleului și programelor sunt exact aceleași ca SLES, am decis să construiesc NX pe el și apoi să transfer directorul cu rezultatul construirii. copiere regulată pe un sistem pe 64 de biți. Asta am făcut: totul a funcționat ca și cum nimic nu s-ar fi întâmplat. Descărcăm fișiere cu aceleași nume ca atunci când construim versiunea 1.5, doar cu sufixele 2.0 (sau 2.1). Totul se compilează exact la fel ca în cazul lui NX 1.5, cu câteva excepții: în primul rând, nu am aplicat patch-ul NX-lfs_hint.diff, în al doilea rând, a apărut o nouă versiune a scripturilor FreeNX 0.5, care suportă noul NX 2.0, îl puteți ridica de aici, în al treilea rând, fișierul freenx-lfs_hint.diff, care face modificări fișierului nxloadconfig din FreeNX 0.4, nu se potrivește cu noua versiune de FreeNX, trebuie editat. Iată rezultatul comenzii diff, care arată diferența dintre fișierul nxloadconfig original și editat:

Nxloadconf_orig 2006-07-01 22:03:39.000000000 +0500
+++ nxloadconfig 2006-10-16 12:32:19.000000000 +0500
@@ -56,12 +56,12 @@
NX_LICENSE="OS (GPL)"

Prima parte: Câteva versuri

Următorul text al autorului nu pretinde a fi adevărul suprem și nu trebuie folosit pentru a judeca nivelul statistic mediu al infrastructurii IT în companiile mici din vasta noastră țară. Articolul a fost scris pe baza conversațiilor cu numeroși IT cunoscuți (mai ales la nivel de „student” și „abia ieșit din facultate”), care și-au început cariera ca specialiști IT în companii mici.

Să ne imaginăm un birou mediu al unei mici companii comerciale din punct de vedere IT:

câteva zeci de computere slabe pentru secretară, manageri, departamentul de contabilitate și, bineînțeles, șeful principal;
una, două sau trei mașini care îndeplinesc următoarele roluri:
- controler de domeniu Windows (există adesea cazuri când nu există nici măcar un domeniu în rețeaua companiei și toate computerele funcționează într-o rețea peer-to-peer);
- server de fișiere;
- server de e-mail (în schimb, uneori sunt folosite servere de e-mail externe gratuite, de la mail.yandex.ru și gmail.com până la găzduire de zece dolari pentru N cutii poștale);
- Proxy http pentru filtrarea accesului la resurse externe și înregistrarea „unde merge oricine” (deseori lipsește)
- router/firewall la granița cu rețea externă pentru a restricționa accesul la exterior și invers (adesea orice router SOHO entry-level cu un preț de până la 100 USD este folosit ca router de frontieră; acționează și ca server DHCP (pentru distribuirea dinamică a adreselor IP către stațiile de lucru ale angajaților);
- alte lucruri, a căror listă poate fi destul de mare;
mai multe imprimante, adesea conectate local la stațiile de lucru ale angajaților și partajate prin rețea folosind instrumente standard Windows (alternativ, imprimantele pot fi conectate la rețea inițial sau conectate prin servere de imprimare hardware).
în cazuri avansate - un server terminal (sub Windows) pentru contabilitate (1C rulează pe el și există, de asemenea, o bază de date a acestuia, iar contabili, care se conectează la serverul terminal prin standard Instrumente Windows(desktop la distanță), lucrați cu acesta pe un server terminal (local), care, în primul rând, oferă mai multă comoditate și, în al doilea rând, accelerează munca 1C în sine (de obicei, 1C cu baza de date este instalată pe computerul unuia dintre contabili , iar restul sunt conectați accesați-l de pe computerele dvs., lucrând cu o bază de date partajată în rețea).

Toate aceste echipamente sunt conectate într-o singură rețea locală prin unul/mai multe switch-uri ieftine de 100Mbit. Și aceasta funcționează într-un singur domeniu NT/Active directory (deși există opțiuni pentru stațiile de lucru peer-to-peer fără niciun domeniu).

Toate mașinile Windows au de obicei instalat un fel de antivirus (deși există excepții). Nu obișnuit versiuni de rețea dintre aceste programe (același Avast), deși, din nou, în birourile mai avansate (din punct de vedere IT) există versiuni de rețea de antivirusuri cu management centralizat și actualizare a bazelor de date antivirus.

Situațiile de mai sus variază de la caz la caz, deoarece configurația rețelei, a hardware-ului și a software-ului este influențată atât de cunoștințele/deprinderile/dorințele (și, mai important, de lenea) administratorului(lor) de sistem, cât și de înțelegerea autorităților. (reprezentat de Șeful principal) „ce anume face acest administrator de sistem al nostru când totul funcționează deja perfect” (din acesta din urmă rezultă câți bani sunt alocați pentru echipamente IT și salariul viitorului specialist). Dacă se alocă puțini bani (și de obicei acesta este cazul - managerii companiilor comerciale sunt de obicei departe de IT și înțeleg puțin ce se întâmplă acolo), atunci angajatul Enikey care a acumulat suficiente cunoștințe pleacă într-o altă companie. Un alt elev ia locul celui care a plecat si totul se repeta din nou.

Cred că este inutil să spun că în astfel de birouri departamentul administrarea sistemului constă dintr-o persoană care combină un inginer pentru instalarea/întreținerea unei rețele de birou, un administrator de sistem ca atare (adică însăși persoana care este responsabilă de performanța parcului de servere la nivel de software și hardware și de implementarea de noi funcționalități) și un enikeyshika - „băiat de comision” care se ocupă cu rezolvarea problemelor pentru utilizatori, ștergerea șoarecilor, schimbarea cartuşelor de imprimantă și lucruri similare.

Ca rezultat, companiile mici au adesea o flotă destul de diversă de mașini utilizator, de la pentium2/128Mb ram/5Gb hdd la P4 Celeron/1Gb ram/80Gb hdd. Toate mașinile, desigur, au Windows (98, 2000 și XP Home/Pro) și versiuni diferite de software (mașinile au fost instalate în momente diferite). Se ajunge la punctul că software-ul antivirus de pe mașini este, de asemenea, de la diferiți producători.

Și revine greutății administratorului de sistem (și specialistului Enikey cu normă parțială) să sprijine toată această grădină zoologică zi și noapte. Dar fierul se rupe uneori:

ventilatoarele încep să bâzâie neplăcut (trebuie curățate și lubrifiate sau înlocuite cu altele noi);
sursele de alimentare defectează;
hard disk-urile se prăbușesc;
plăcile de rețea (atât încorporate în placa de bază, cât și cele externe nu mai funcționează și necesită înlocuire);
restul fierului de călcat zboară de obicei mult mai rar, dar totuși zboară și el

Când un hard disk (sau o placă de bază a computerului) se defectează, sistemul de operare de pe mașina restaurată trebuie adesea rearanjat de la zero în această secvență sau într-o secvență foarte similară:

instalați Windows;
instalați driverele necesare (întreaga flotă de hardware este diferită - vă amintiți?), după ce ați determinat anterior modelul plăcii de bază din această mașină și ați descărcat cele mai recente versiuni de drivere de pe Internet sau le-ați găsit pe serverul dvs. de fișiere pe cele de care aveți nevoie;
introduceți mașina în domeniu (dacă este configurată);
instalați software-ul necesar (birou, browser, client de email, total commanders, ICQ, jabbers, punto switchers etc.) - în cazul unui domeniu Director activ Unele software pot fi instalate automat, dar nu toată lumea le are configurat și nu toată lumea îi cunoaște capacitățile;
instalați antivirus;
plus dansuri suplimentare cu o tamburină, individuale pentru rețeaua specifică a fiecărei organizații în jurul noii stații de lucru;

După finalizarea cu succes a tuturor punctelor (această procedură durează aproximativ două ore), raportăm șefului că la locul de muncă Angajatul este salvat și poate începe lucrul.

Fericitul proprietar al computerului restaurat se așează la locul de muncă, după care se dovedește că (din moment ce profilurile de domeniu nu erau mobile sau nu exista deloc domeniu, linkul „documentele mele” ducea la unitatea locală C: și despre faptul că tot ceea ce este important este necesar, cu excepția unei unități de rețea - pe server, angajatul a uitat):

Aveam aici un folder cu documente importante - unde este?
Am salvat acolo si fotografii din Turcia, este posibil sa le restabilesc?
erau multe comenzi rapide importante și încă o sută de documente pe desktop - unde s-au dus?
în favorite (este vorba despre marcaje în browser), site-urile mele preferate nu mai sunt acolo - unde le pot căuta acum? și așa mai departe…

Suna familiar? Este bine dacă nu hard diskul este cel care se defectează, ci doar placa de baza. Sau unele dintre informațiile de pe discul prăbușit pot fi restaurate. Dar toate aceste proceduri ocupă timpul de lucru al administratorului de sistem, care ar putea fi petrecut cu un beneficiu mult mai mare jucând un shooter de rețea sau... studiind IPv6 - la urma urmei, toată lumea trece deja la el și va comuta foarte curând, adresele în spațiul IPv4 s-a încheiat deja de aproximativ cinci ani :)

Ca urmare, susținerea infrastructurii IT a unei companii mici pentru un administrator de sistem se transformă, în cea mai mare parte, în susținerea performanței stațiilor de lucru ale utilizatorilor și anume:

reinstalați Windows;
setat la mașină nouă tot software-ul necesar;
restaurați tot ce a fost pierdut;
instalați programe noi pentru cei care au nevoie;
efectuați întreținerea preventivă a carcasei (aspirați praful din unitatea de sistem);

Și în timpul rămas (dacă administratorul de sistem nu este foarte leneș), trebuie să încercați să învățați ceva nou, să actualizați software-ul de pe server (servere) și să puneți în funcțiune un nou serviciu de rețea. Acestea. Nu mai rămâne timp pentru sarcinile de bază (exact ceea ce ar trebui să facă un administrator de sistem de cele mai multe ori).

Cum să ieși din acest cerc vicios?

Una dintre opțiunile pentru rezolvarea problemei descrise mai sus este abandonarea stațiilor de lucru „groase” (unde se poate face acest lucru) și trecerea la .

O stație de lucru „groasă” înseamnă orice computer cu un sistem de operare instalat, care procesează majoritatea informațiilor despre utilizator. Acestea. browserul, biroul și orice altceva sunt executate local pe stația de lucru a utilizatorului, a cărei unitate de sistem zumzea sub biroul lui sau undeva în apropiere.

Trebuie să înțelegeți că cerințele sistemelor de operare moderne (nu neapărat Windows) țin pasul cu hardware-ul modern - cu alte cuvinte, pentru o muncă relativ confortabilă în Windows XP, o mașină veche (dar complet funcțională și relativ puternică) din clasa Celeron 800Mgz/128Mb Ram/10Gb HDD nu poate ajunge. Este, desigur, posibil să lucrați sub un sistem de operare modern pe un astfel de hardware, dar acest sistem de operare și aplicațiile vor încetini destul de des, chiar dacă numai din cauza cantității mici de memorie de la bord și a vechii (a se citi: lent) hard disk.

Un client subțire, pe scurt, poate fi definit ca un computer fără disc, a cărui activitate constă doar în conectarea la un server la distanță și afișarea pe ecran a informațiilor primite de la server. De obicei, un astfel de server este numit server terminal sau server terminal. Toată prelucrarea informațiilor utilizatorului are loc pe acesta (la care mulți, deși nu un număr infinit, de clienți subțiri pot fi conectați simultan).

De obicei, clienții subțiri sunt fabricați pe baza unui hardware slab (și, în consecință, de putere redusă) - adesea aceasta este o singură placă de bază pe care este integrat totul. Procesorul și memoria pot fi, de asemenea, strâns lipite de placa de bază. Unii thin clients au un disc flash (inserat în conectorul IDE al plăcii de bază), pe care este flashat un sistem de operare specializat (WinCE sau altele).

Comparație între clientul subțire Clientron U700 cu un șasiu standard de stație de lucru.

Ca urmare, atunci când porniți clientul subțire (se mai numesc și terminale), sistemul de operare este încărcat de pe discul flash încorporat (de obicei durează mai puțin de 30 de secunde pentru a încărca), după care apare un dialog pentru conectarea la server terminal apare pe ecran. Unii dintre acești clienți se pot conecta doar la Windows Terminal Server sau Citrix Metaframe, alții se pot conecta și la serverele terminale ale altor sisteme de operare. În orice caz, prețul unor astfel de soluții include și prețul unei licențe pentru WindowsCE, flash pe unitatea flash încorporată. Am vorbit mai devreme despre soluții similare:

Terminal Windows
Client slab
Terminal Windows

Desigur, alte companii au soluții similare. Inclusiv fără un sistem de operare încorporat (pentru care, în caz Microsoft Windows CE, trebuie să plătiți suplimentar, iar unitatea flash este un ban, dar merită).

Clienții terminale fără un disc flash încorporat, se încarcă atunci când sunt porniți imaginea dorită OS prin rețea, după care petrec aceleași câteva zeci de secunde încărcându-se. După care suntem gata de lucru, ceea ce înseamnă afișarea unui meniu cu o listă de servere terminale la care să ne conectăm sau conexiune automată la unul dintre serverele terminale hard-coded (în funcție de setări) - utilizatorul va trebui doar să introducă un login și o parolă. După ce a introdus-o corect, intră în sesiunea sa pe serverul terminal și poate începe să lucreze.

Avantajele incontestabile ale soluțiilor terminale pe client subțiri specializati sau computere auto-asamblate adecvate:

lipsa unui hard disk (care se încinge și se rupe);
lipsa ventilatoarelor (pe procesor și sursa de alimentare sunt instalate doar radiatoare, care sunt suficiente pentru a disipa căldura generată în timpul funcționării);
consum redus de putere;
cost teoretic redus (la auto-asamblare, puteți selecta componente foarte ieftine, deoarece performanța hardware nu este necesară; dar producătorii vor cere de două ori mai mult pentru clienți subțiri specializati)
costuri minime de timp pentru întreținere (dacă o astfel de piesă hardware se defectează, este suficient să o deconectați pe cea stricată și să conectați una de rezervă timp de cinci minute; acesta este timpul minim de nefuncționare pentru locul de muncă al unui angajat, precum și timpul minim petrecut privind remedierea defecțiunii administratorului de sistem)
tot software-ul pentru lucrul utilizatorului este configurat central pe unul (două/trei/...) servere terminale, acest lucru este mult mai simplu decât întreținerea unei grădini zoologice de software pe stațiile de lucru „groase” ale angajaților

Nu uitați de datele utilizatorului: terminalul nu stochează nimic local (toate datele utilizatorului se află pe servere la distanță). Drept urmare, este ușor să configurați copii de rezervă automate ale tuturor și, dacă se întâmplă ceva, să restaurați un document „șters accidental”.

În general, există o mulțime de avantaje, dar există și dezavantaje:

dacă rețeaua eșuează, stațiile de lucru ale angajaților „se transformă într-un dovleac” (iar angajații de pe clienți „groși” pot continua să tasteze un document, de exemplu, în OpenOffice);
dacă serverul terminal eșuează, locurile de muncă ale angajaților „se transformă din nou într-un dovleac” (dar acest lucru poate fi rezolvat prin instalarea mai multor - de exemplu, două - servere terminale; dacă unul dintre ele eșuează, al doilea îl va înlocui, sau angajații se vor reconecta la al doilea server manual)
Clienții subțiri nu sunt potriviți pentru toată lumea: de exemplu, persoanele care urmăresc în mod constant videoclipuri sau lucrează activ cu grafică (în Photoshop) sau fac aspectul revistei sunt mai bine să facă acest lucru pe un client „gros” local (dar clienții subțiri sunt grozavi pentru majoritatea celorlalți angajații care au nevoie doar de un browser cu Internet, e-mail, crearea și editarea documentelor în Openoffice și lucrul cu 1C).

Ultimul dezavantaj, pe care nu îl vom lua în considerare aici, este politica de licențiere(ca să nu spun o fraudă) din partea Microsoft. Lucrul pe un server terminal care rulează sistemul de operare al acestei companii binecunoscute necesită cantitate mare diverse licente:

Licență Windows Server
Licențe CAL (Client Access License) pentru conectarea la un server Windows și numărul acestora nu trebuie să fie mai mic decât numărul de clienți care se conectează la server (de obicei, serverul Windows include deja un anumit număr de astfel de licențe de la cinci și mai sus)
licențe pentru lucrul cu un server terminal (numărul acestora trebuie să fie, de asemenea, egal cu numărul de clienți conectați)

Nu uitați de licențe separate pentru toate software-urile utilizate (de exemplu, Microsoft Office) într-o sumă egală cu numărul de clienți conectați la server. Dacă CAL-urile pentru Microsoft Office pot fi încă ocolite prin refuz a acestui produsși având instalat un înlocuitor pentru acesta, de exemplu, OpenOffice, atunci este oarecum mai dificil să scapi de serverul terminal în sine sub forma Windows 2000/2003 TS :) Deși acest lucru este posibil în unele cazuri.

Mai există, totuși, un „minus” (pe lângă teama de nou) care oprește adesea oamenii să implementeze astfel de soluții - din anumite motive, mulți oameni cred că acești clienți subțiri trebuie cumpărați (și nu sunt foarte ieftini - de la 200 USD și mai mult). Ce ar trebui să facem cu întreaga flotă de computere existente?

Pentru a răspunde la ultima întrebare a fost scrisă această serie de articole. Acesta va acoperi software-ul client subțire.

Acest mic, dar cu multe capacități și, mai important, software OpenSource, vă permite să transformați aproape orice computer antic în client subțiri. Hardware-ul minim descris pe site-ul său principal pentru hardware-ul folosit este un Pentium de 100Mhz și 16Mb de RAM. Da, nu este necesară nici o unitate hard/flash - atunci când computerele sunt pornite, acestea pot descărca imaginea clientului subțire (aproximativ douăzeci de megaocteți) prin rețea (deși este posibil să instalați și clientul Thinstation pe un hard sau USB conduce). În epoca noastră a sistemelor de operare care consumă fericit gigaocteți de spațiu pe disc după instalare, acest lucru este impresionant, nu-i așa?

Thinstation se bazează pe Linux, dar pentru a-l folosi nu aveți nevoie de cunoștințe despre Linux ca atare - trebuie doar să instalați servere dhcp și tftp în rețea și să le configurați în consecință (ambele aceste servere sunt, de asemenea, incluse în produsele Windows Server). Astfel, chiar și într-o rețea în care nu știu altceva decât Windows, utilizarea clientului Thinstation nu va cauza dificultăți.

Thinstation poate funcționa cu următoarele servere terminale:

Servere Microsoft Windows Protocolul RDP sau prin nxclient (Windows NT4TSE, W2k Server, W2k3 Server sau Windows XP în modul utilizator unic);
Servere Citrix prin protocolul ICA (pe serverele MS Windows, SUN Solaris și IBM AIX);
Servere Tarantella
*servere de tip nix care folosesc protocolul X11;
conexiune la servere VNC (tightVNC);
conexiune la servere SSH și Telnet;

Pentru a porni Thinstation prin rețea, computerul are nevoie doar de o placă de rețea încorporată sau externă care acceptă standardul PXE (există și alte opțiuni, dar, de exemplu, toate încorporate placa de sistem plăcile de rețea funcționează exact conform acestui protocol).

PXE înseamnă Pre-boot eXecution Environment. Acest standard a fost implementat pentru prima dată de Intel. Primul semn al prezenței unui BIOS PXE la bordul plăcii de rețea încorporate este elementul „Enable Boot ROM” de lângă elementul de activare a plăcii de rețea din BIOS. Dacă placa de rețea încorporată nu acceptă pornirea prin rețea (sau este absentă cu totul), puteți utiliza orice placă de rețea externă cu opțiunea „Boot ROM” (această problemă va fi discutată în detaliu mai jos).

Acum să aruncăm o privire rapidă asupra procesului de descărcare a clientului Thinstation prin rețea.

Placa de rețea prin protocolul PXE solicită serverului DHCP următoarele informații: adresa IP, masca de subrețea, gateway, precum și adresa IP a serverului TFTP (pe care se află imaginile, în acest caz, ThinStation) și numele imaginii pe care va încerca să o descarce.
Serverul DHCP returnează informațiile solicitate (observând că adresa IP emisă clientului este ocupată de un astfel de client)
Clientul se conectează la serverul TFTP a cărui adresă IP tocmai i-a fost dată și descarcă de pe acesta fișierul de încărcare PXE (al cărui nume i-a fost dat din nou de serverul DHCP)
Încărcătorul PXE descărcat este executat și, la rândul său, descarcă un fișier de configurare de pe serverul TFTP, care conține numele fișierelor kernel-ului Linux vmlinuz și imaginea Sistemul de fișiere initrd. Aceste fișiere sunt descărcate și controlul este transferat către kernel-ul Linux
După despachetarea și încărcarea kernel-ului Linux cu o imagine de sistem de fișiere montată, Thinstation accesează din nou serverul TFTP pentru a descărca fișierele de configurare de care are nevoie (printre altele, adresele serverelor terminale la care trebuie să vă conectați sunt scrise acolo), iar apoi lansează clientul terminal necesar (în acest caz, acesta va fi rdesktop) și se așteaptă ca utilizatorul să introducă numele și parola pentru a se conecta.

La prima vedere, schema descrisă pare complicată. Dar, de fapt, configurarea durează între o jumătate de oră și o oră, iar în viitor funcționează complet autonom. Pornirea clientului subțire din momentul primei solicitări în rețea prin PXE (acest moment coincide cu momentul în care sistemul de operare începe să se încarce de pe hard disk) durează 20...30 de secunde.

După cum sa menționat mai sus, Thinstation poate funcționa cu diferite servere terminale. Dar vom discuta în articolele următoare despre cea mai ușoară modalitate de implementare (dar vă reamintesc încă o dată despre achiziționarea multor licențe client necesare pentru munca oficială), să luăm în considerare doar combinația de Thinstation cu Microsoft Terminal Server.

În primul rând, trebuie să avem un server terminal configurat de la Microsoft. Acest server poate funcționa atât ca parte a unui domeniu (în acest caz este mai convenabil să gestionezi conturile de utilizator - acestea sunt partajate, mai ales dacă există mai multe servere terminale în rețea), cât și în afara domeniului - într-un peer-to- rețea de egali. Al doilea caz diferă de primul prin faptul că utilizatorii necesari vor trebui creați local pe fiecare server și listele curente de utilizatori și drepturile acestora vor trebui sincronizate manual.

Al doilea punct al programului nostru va fi Configurare DHCPși servere TFTP. Primul se ocupă de distribuția dinamică a adreselor IP pentru stațiile de lucru și, de asemenea, raportează de la ce adresă IP (de pe ce server tftp) și ce nume de fișier trebuie să descarce computerul ca imagine de pornire a clientului subțire. Iar cel de-al doilea server tftp oferă de fapt imagini de client subțire și fișiere de configurare pentru ei. Aceste setări pot fi fie globale (pentru toți terminale fără disc rețele), și local pentru anumite grupuri de mașini sau clienți subțiri unici.

Ambele servicii pot fi create atât ca parte a unui server Windows (prin lansarea și configurarea serviciilor corespunzătoare), cât și ca daemoni separati ca parte a unui server *nix, vom analiza acest lucru folosind exemplul unui server cu Gentoo Linux; instalat.

Iar al treilea punct este setarea mașinile client transferându-le la descărcare prin rețea și luând în considerare capcanele standard.

Dar mai multe despre asta în următoarele articole din seria noastră.

Ghid detaliat pentru configurarea clienților subțiri

Bazat pe distribuția Thinstation și protocolul NX

Tehnologia NX, dezvoltată de Nomachine, oferă noi opțiuni de conectivitate și poate revigora computerele vechi ca clienți subțiri.

Înainte de a trece direct la descrierea NX, voi enumera câteva tendințe care devin evidente astăzi pentru multe companii mari din țara noastră:

1. Echipamentele informatice devin din ce în ce mai ieftine și mai accesibile decât înainte. În același timp, productivitatea sa se dublează la fiecare 1,5-2 ani conform legii lui Moore. Acest lucru duce la acumularea de echipamente care nu și-au epuizat durata de viață, dar sunt deja depășite.

2. Aplicațiile client-server dezvoltate la întreprinderi de programatori din departamentele de sisteme de control automatizate în anii perestroika încă funcționează pe tehnologie veche, dar nu mai îndeplinesc cerințele vremii.

3. Software-ul și sistemele de operare moderne nu pot fi făcute să funcționeze pe computere cu procesoare din generațiile anterioare (i386, i486 etc.).

4. Nu este un secret pentru nimeni că în multe organizații din țara noastră, de mult timp, multe programe și sisteme de operare pe care angajații le-au instalat din proprie inițiativă au fost folosite ilegal. La început acest lucru a fost văzut ca un lucru firesc, dar apoi a fost justificat de situația financiară. Acum că țara noastră se aderă la OMC, guvernul este nevoit să corecteze rapid această situație, prin urmare, presiunea asupra întreprinderilor din partea autorităților interne pentru a abandona software-ul și sistemele de operare utilizate ilegal.

Revista a publicat deja mai multe articole despre lucrul cu distribuția Thinstation. În acest articol, voi vorbi despre specificul experienței de configurare și operare în întreprinderea mea cu clienți subțiri bazați pe distribuția Thinstation și tehnologia NX dezvoltată de Nomachine.

Până de curând, în lumea comunicațiilor cu terminale, existau puține protocoale de rețea de succes de nivel înalt cunoscute, capabile să comprima și să cripteze eficient traficul dintre un client subțire și un server. Cele mai cunoscute și populare dintre ele sunt RDP de la Microsoft și ICA de la Citrix. Ambele protocoale sunt utilizate de servere bazate pe sistemul de operare MS Windows. Am fost interesat de posibilitatea de a folosi thin clients cu servere bazate pe Linux. Ca bază pentru clientul subțire, un mic kit de distribuție, un fel de designer Linux, Thinstation a fost ales aproape imediat ca fiind cel mai constant și mai popular în țara noastră și în străinătate. Dar, odată cu alegerea protocolului care ar fi responsabil de comunicarea cu serverul, a trebuit să schimb și să experimentez. Voi enumera principalele criterii după care a fost selectat protocolul. În primul rând, am dorit să folosim cea mai largă gamă posibilă de computere vechi cu procesoare începând de la i486, cu o cantitate minimă de memorie, avem destule astfel de echipamente. În al doilea rând, produsele comerciale au fost respinse: nu am vrut să suportăm costuri suplimentare. În al treilea rând, este necesar un suport bun pentru limba rusă și alfabetul chirilic, precum și prezența unui mod familiar prin care utilizatorii pot comuta între aspecte - combinații de taste . În al patrulea rând, în cadrul unei rețele locale, nu trebuie să acceptăm criptarea, dar compresia și minimizarea traficului de rețea sunt importante.

Găsirea unei soluții

În primul rând, am acordat atenție VNC ca fiind cel mai comun și disponibil în orice distribuție Linux, precum și un produs ușor de configurat. Când trebuie să vă conectați la un desktop de la distanță al unui server Linux de la o stație de lucru Windows sau Linux, primul lucru care vă vine în minte este VNC. Descărcați cea mai recentă versiune a distribuției Thinstation, apoi dezarhivați fișierul arhivă rezultat în directorul dvs. de acasă. Să presupunem că calea către distribuție arată astfel: ~/thinstation. Fișierul responsabil pentru parametrii de construcție se află aici: ~/thinstation/build.conf. Are comentarii detaliate. Nu voi vorbi în detaliu despre configurarea acesteia, precum și despre cum să forțați imaginea Thinstation să pornească folosind o placă de rețea cu un cip de pornire despre acest lucru s-a scris deja în aceste articole. Voi enumera pe scurt pașii pentru configurarea clientului: editați ~/thinstation/build.conf și creați o imagine rulând scriptul ~/thinstation/build. Copiem fișierul imagine finit ~/thinstation/boot-images/etherboot/thinstation.nbi pe serverul TFTFP. Adăugăm o intrare despre adresa MAC a plăcii de rețea a clientului subțire la fișierul de configurare dhcp.conf al serverului DHCP. În directorul serverului TFTP, creați un fișier cu setările pentru această adresă MAC și/sau editați fișierul thinstation.conf.network. Setările sistemului meu de lucru pot fi văzute în lista secțiunii „Configurarea și crearea unei imagini Thinstation” și în Fig. 1.

Figura 1. Relații dintre componentele NX

Pentru a adăuga un pachet client VNC la imagine, decomentați linia „#package vncviewer” din fișierul de configurare ~/thinstation/build.conf. Dacă directorul serverului tftp se află în /tftpboot (cum este și pentru mine), atunci editați fișierul /tftpboot/thinstation.conf.network astfel încât liniile să apară în el:

SESSION_0_TYPE=vncviewer

SESSION_0_TITLE="VNC" !}

SESSION_0_VNCVIEWER_SERVER=10.10.10.10:5901

Înlocuiți adresa IP 10.10.10.10 cu adresa serverului dvs. VNC.

xkbcomp:0 ru.xkb

xkbcomp -xkm ru.xkb ru.xkm

cp -f ru.xkm ~/thinstation/packages/keymaps-ru/x-common/lib/kmaps/xkb

Pornim clientul subțire și încărcăm imaginea creată, verificând performanța. Progresul este evident: „prezentarea” se oprește pe computerele cu procesor P-100, P-120 și superior. Acest lucru nu este ceea ce ne-am dori să obținem ca rezultat, așa că PC-urile cu procesoare i486 nu vor putea fi folosite aici. Am numit astfel de PC-uri clienți „superthin” și le-am configurat să funcționeze cu programe DOS folosind o combinație de FreeDOS și sshdos pe partea client și Dosemu pe partea serverului Linux. Nu voi vorbi despre ele în acest articol. Cu toate acestea, acesta este un rezultat bun, să ne uităm la cerințele hardware de la dezvoltatorii Thinstation și clientul NX: primii recomandă un procesor i486 și 16 MB de memorie, cei din urmă recomandă un procesor cu o frecvență de 400 MHz și 128 MB a memoriei. Să determinăm empiric configurația minimă necesară pentru ca un client subțire să lucreze cu pachetul NX ca procesor P-120 și 32 MB de RAM. Am testat alți clienți, în special, XRDP, VNC pentru DOS, dar dintr-un motiv sau altul nu am găsit o alternativă reală la NX. Acum este timpul să aruncăm o privire mai atentă asupra tehnologiei NX.

Recenzie și scurtă descriere a Nomachine NX

Cele mai multe soluții de rețea disponibile nu au fost concepute ca mijloc principal pentru utilizatori de a accesa desktop-ul. Protocoale precum RDP și VNC sunt mult mai simple decât X (și, prin urmare, sunt potrivite pentru clienții subțiri), dar simplitatea lor nu compensează lipsa de eficiență și funcționalitate. De exemplu, aceste protocoale folosesc cantități mari de date de imagine pentru a reda un ecran la distanță. Deși RDP este un protocol mai eficient decât RFB (protocolul folosit de VNC), nu a fost conceput inițial pentru utilizarea zilnică de către dispozitivele din rețea, ci doar ca o extensie a sistemului de operare. X-Window este un subsistem grafic (nu o extensie a sistemului de operare), iar aplicațiile X interacționează cu acesta folosind protocolul X, astfel încât sistemul de operare nu are un strat special responsabil pentru traducerea actualizărilor de ecran în protocolul de rețea.

Principalele dezavantaje ale rețelelor X-terminale sunt redundanța și întârzierile în transferul datelor grafice X-protocol. De la apariția X-Window, desktopul utilizatorului a dobândit tot felul de elemente grafice și efecte care au crescut cerințele asupra rețelelor de date.

NX folosește trei metode principale pentru a accelera aplicațiile: compresia, stocarea în cache și suprimarea traficului excesiv de protocol X.

n Ideea compresiei diferențelor se bazează pe proiectul Differential X Protocol Compressor (DXPC), creat în 1995, termenii client și server proxy sunt deja menționați acolo. Nomachine a preluat ideea și și-a dezvoltat propriul produs. NX se pretinde a fi de 10 ori superior bibliotecă standard ZLIB.

n Nomachine a dezvoltat, de asemenea, un mecanism inteligent de stocare în cache pentru traficul X care utilizează termenul proxy familiar „accesări în cache”. Acest mecanism reduce trafic de rețea la transmiterea acelorași blocuri de date, iar când aceste blocuri de date se modifică, firul calculează și transmite doar diferența lor.

n Înainte de NX, nu exista o modalitate fiabilă de a suprima traficul excesiv de protocol X pe legăturile pe distanțe lungi. NX poate face acest lucru prin traducerea traficului X de la distanță (de la aplicație la nxagent) în trafic de protocol NX.

Toate cele trei metode se combină pentru a obține o îmbunătățire de 70 de ori a experienței GUI X la distanță în timp ce se utilizează cel mai înalt nivel de compresie pe legături cu lățime de bandă mică și cu latență mare (în setările clientului NX, „modem” corespunde compresiei maxime și „lan” corespunde lipsei compresiei) . În fig. 1 sub numărul 2 arată relația componentelor NX: compresia/decompresia și caching-ul sunt efectuate pe modulele NX Proxy, traficul trece între ele prin protocolul NX, cerințele pentru calitatea liniilor de comunicație sunt minime, se precizează că acestea pot functioneaza pana la viteze de 9600 bps.

Similar cu traducerea traficului X de către nxagent, există un alt agent („nxviewer”) care traduce traficul RFB/VNC la protocolul NX. Acest lucru îmbunătățește eficiența conexiunii de până la 10 ori în comparație cu un vncviewer obișnuit care conectează un afișaj X local la un server VNC la distanță. Ne vom asigura de asta.

n Proxy NX– această componentă este tocmai responsabilă de compresie/decompresie: în modul client codifică cererile de la clienții X și decodifică răspunsurile de la serverul X, în modul server – invers.

n Agent NX– termenul „agent” este folosit pentru a descrie componenta la care este transmisă imaginea generată înainte de a fi transmisă în rețea printr-un proxy.

n NX Viewer– un client VNC obișnuit Nomachine modificat care traduce traficul VNC/RFB în protocolul NX.

n Desktop NX– Client RDP care traduce traficul RDP în protocolul NX.

Nomachine a deschis codurile sursă ale majorității dezvoltărilor și bibliotecilor sale, acestea putând fi descărcate de oricine din . Build-urile de la Nomachine în sine sunt disponibile gratuit pentru toți clienții, există și diverse opțiuni pentru build-uri de server NX, furnizate contra cost: un abonament anual la NX Enterprise Server cu un număr nelimitat de utilizatori și 1-2 procesoare costă 1.494 USD; cea mai completă soluție cu echilibrarea sarcinii și gestionarea nodurilor bazate pe NX Advanced Server va costa 3.494 USD. În plus, există o opțiune NX Free Edition, care poate fi descărcată gratuit, dar are o limită a numărului de conexiuni simultane și de utilizatori egală cu doi, așa că dacă doriți să administrați un server Linux de acasă folosind un modem analog obișnuit , atunci este mai bine, mai sigur și mai ușor această soluție nu poate fi găsită. Voi nota, de asemenea, disponibilitatea versiunilor client ale NX Client Desktop Edition pentru PlayStation 2 (atunci când se utilizează Linux Kit-ul), precum și NX Client Embedded Edition pentru Sharp Zaurus 5xxx și HP/Compaq iPAQ. De asemenea, pot fi descărcate gratuit. Deci, dacă sunteți într-o călătorie de afaceri și aveți doar un PDA cu dvs., nimic nu vă împiedică să vă conectați și să lucrați de la distanță pe serverul dvs. Linux.

Construirea și rularea NX

Momentan, sursele versiunii NX 2.0 sunt postate pe site-ul Nomachine, această versiune este recomandată de companie și există un link special către sursele versiunii 1.5. Descărcați cele mai recente versiuni ale următoarelor tarball-uri de pe pagină: nx-X11, nxagent, nxcomp, nxcompext, nxdesktop (dacă aveți nevoie de suport RDP), nxproxy, nxscripts, nxviewer (dacă aveți nevoie de suport VNC). nx-X11 este versiunea 4.3 a Xfree86, care a modificat bibliotecile Nomachine X. Unele dintre surse vor fi despachetate direct în arborele nx-X11, așa că îl vom extinde mai întâi, ordinea despachetării tarball-urilor rămase nu este importantă, principalul lucru este că toate sunt despachetate într-un singur director. Acolo descarcăm și despachetăm scripturile FreeNX de la adresa . Veți avea nevoie și de două patch-uri, descărcați-le de aici. Directorul nostru de asamblare va arăta astfel:

n freenx-0.4.4

nnx-X11

nnxcomp

nnxcompext

nxdesktop

nnxproxy

nxscripts

nxviewer

n freenx-lfs_hint.diff

n NX-lfs_hint.diff

# Aplicați patch-ul NX

patch -p0< NX-lfs_hint.diff

# Asamblarea X – cea mai lungă parte, poate dura până la o oră

pushd nx-X11

face lumea

popd

#nxproxy

pushd nxproxy

./configure --prefix=/srv/NX

face

popd

# Construiți agentul RFB

pushd nxviewer

xmkmf -a

cp -a /usr/X11R6/lib/libXp.so* ../nx-X11/exports/lib/

face 2> /dev/null

popd

# Construirea agentului RDP

pushd nxdesktop

./configure --prefix=/srv/NX --sharedir=/srv/NX/share

face

popd

# Întreaga parte a serverului va fi localizată în directorul /srv/NX, creați unele dintre subdirectoare

mkdir -p /srv/NX/bin

mkdir -p /srv/NX/lib

mkdir -p /srv/NX/man/man1

mkdir -p /srv/NX/share/doc

# Instalați bibliotecile și agenții colectați

cp -a nx-X11/lib/X11/libX11.so.* nx-X11/lib/Xext/libXext.so.* nx-X11/lib/Xrender/libXrender.so.* /srv/NX/lib

instalați -m 755 nx-X11/programs/Xserver/nxagent /srv/NX/lib

# Creați un script nxagent care va gestiona toate programele

cat > nxagent<< "EOF"

#!/bin/sh

NXCOMMAND=$(nume de bază $0)

export LD_LIBRARY_PATH=/srv/NX/lib:$LD_LIBRARY_PATH

exec /srv/NX/lib/$NXCOMMAND $(1+"$@")

EOF

# Și instalează-l:

instalați -m 755 nxagent /srv/NX/bin

# Instalați biblioteci de compresie și proxy

cp -a nxcomp/libXcomp.so.* /srv/NX/lib

cp -a nxcompext/libXcompext.so.* /srv/NX/lib

instalați -m 755 nxproxy/nxproxy /srv/NX/lib

ln -snf nxagent /srv/NX/bin/nxproxy

# Instalarea agentului RFB

pushd nxviewer

faceți instalarea DESTDIR=/srv/NX

mv /srv/NX/usr/X11R6/bin/nxviewer /srv/NX/lib

ln -snf nxagent /srv/NX/bin/nxviewer

chmod 755 /srv/NX/bin/nxviewer

mv /srv/NX/usr/X11R6/bin/nxpasswd /srv/NX/bin

popd

# Instalarea unui agent RDP

pushd nxdesktop

face instalarea

mv /srv/NX/bin/nxdesktop /srv/NX/lib

ln -snf nxagent /srv/NX/bin/nxdesktop

chmod 755 /srv/NX/bin/nxdesktop

rm -rf /srv/NX/usr

popd

# Instalarea scripturilor

cp -r nxscripts /srv/NX/share/doc

# instalați FreeNX

mkdir -p /srv/NX/etc

mkdir -p /srv/NX/var

mkdir -p /srv/NX/var/db

mkdir -p /srv/NX/home

mkdir -p /srv/NX/home/nx

pushd freenx-0.4.4

# Aplicați patch-ul freenx, în principal aici căile sunt corectate pentru a se potrivi cu /srv/NX

patch -p0< ../freenx-lfs_hint.diff

cp -a nxnode /srv/NX/bin

cp -a nxserver /srv/NX/bin

cp -a nxsetup /srv/NX/bin

cp -a nxkeygen /srv/NX/bin

cp -a nxnode-login /srv/NX/bin

cp -a nxloadconfig /srv/NX/bin

cp -a nxclient /srv/NX/bin

cp -a nxprint /srv/NX/bin

instalați -m 755 node.conf.sample /srv/NX/etc

popd

# Adăugați utilizator și grup nx

groupadd -g 77 nx

useradd -c „Utilizator FreeNX” -d /srv/NX/home/nx -g nx -s /bin/bash -u 77 nx

chown -R root.root /srv/NX

chown -R nx.nx /srv/NX/home/nx

# Dacă doriți să utilizați autentificarea utilizatorului bazată pe cheie, eliminați opțiunea –setup-nomachine-key.

# Pentru a lucra cu clienți subțiri, nu trebuie să schimbați nimic

/srv/NX/bin/nxsetup --install --uid 77 --gid 77 --setup-nomachine-key

# Verificați dacă serverul NX rulează:

/srv/NX/bin/nxserver --status

Răspunsul ar trebui să fie cam așa:

NX>100 NXSERVER - Versiunea 1.4.0-44 OS (GPL)

Serverul NX> 110 NX rulează

NX>999 La revedere

Instalați fișierul de configurare freenx:

mv /srv/NX/etc/node.conf.sample /srv/NX/etc/node.conf

În fișierul de configurare găsim următoarea linie și decommentăm:

ENABLE_1_5_0_BACKEND="1"

Acolo puteți activa și înregistrarea pentru prima dată:

NX_LOG_LEVEL=6

Figura 2. Sesiunea KDE NX în modul desktop din Windows XP

Configurarea și crearea unei imagini Thinstation

modul serial

modul intel-agp

modul via-agp

modulul 8139 de asemenea

discheta modulului

modul vfat

modul supermount

pkg xorg6-ati

pachet xorg6-i810

pachet xorg6-nv

pachet xorg6-s3

pachet xorg6-s3virge

pkg xorg6-sis

pkg xorg6-trident

hărți de taste ale pachetului

pachet nx

pachet lprng

pachet sshd

pkg samba-server

param rootpasswd vă rog să mă schimbați

param xorgvncpasswd, vă rog, schimbați-mă

param bootlogo false

rezoluție param boot 800x600

param defaultconfig thinstation.conf.buildtime

param basename thinstation

param basepath .

param knownhosts ./known_hosts

param localpkgs adevărat

param locații complete false

param bootverbosity 3

param nxurl file://home/zhen/sources/nx/bin/nxclient-1.5.0-141.i386.tar.gz

echo „$PRINTER_X_NAME:lp=$PRINTER_X_DEVICE:wd=$PRINTER_X_DRIVER:br=$PRINTER_X_OPTIONS:lf=/var/log/spooler.log:sh:sf” >> /etc/printcap

echo "$PRINTER_X_NAME:lp=$PRINTER_X_DEVICE:wd=$PRINTER_X_DRIVER:br=$PRINTER_X_OPTIONS:if=/bin/lpf:lf=/var/log/spooler.log:sh:sf" >> /etc/printcap

Adăugarea de filtrare locală a eliminat problema scărilor la imprimare. În plus, am creat următorul script pentru a testa dacă imprimarea funcționează în ~/thinstation/packages/base/bin/my:

#!/bin/sh

echo PRINTER TEST la /dev/printers/0 1>&2

pentru i în 1 2 3 4 5 6 7 8 9;

echo PRINTER /dev/printers/0 $i > /dev/printers/0;

Terminat

echo -e \\r\\f > /dev/printers/0

ieșire 0;

Când nu este clar ce anume nu funcționează, puteți rula acest script pe consola clientului subțire: /bin/my.

ssh-keyscan -t rsa nxserver_ip>>~/thinstation/known_hosts

Ca „nxserver_ip” trebuie să specificați adresa IP a serverului NX. În acest fel, clientul va ști despre amprenta digitală a cheii RSA a serverului NX în timpul autentificării.

Figura 3. Fișierele de configurare pentru Thinstation thin client

otd146_57158 00e04d08d710 smb_flop_hard monitor TUX1C #PC foarte important

Apoi, creăm un fișier de setări thinstation.conf-MAC, eu folosesc adresa MAC în nume, deși puteți folosi adresa IP sau numele de la thinstation.hosts. Rețineți că adresa MAC de aici folosește numai majuscule în numele fișierului. Grupurile sunt descrise în fișierele numite thinstation.conf.group-GROUPNAME. Fișierul thinstation.conf-MAC conține acele setări care se aplică numai acestui terminal și nu sunt incluse în alte grupuri. De exemplu, toate setările generale ale monitorului sunt descrise în fișierul thinstation.conf.group-monitor și un parametru „SCREEN_VERTREFRESH” este mutat în fișierul thinstation.conf-MAC. Acest lucru se datorează faptului că sunt utilizate diferite monitoare, iar setarea ratei de cadre a ecranului poate fi modificată, acesta și alți parametri pot fi configurați pentru fiecare terminal sau pentru toți simultan. Același lucru este valabil și pentru setările mouse-ului. În mod implicit, setarea este făcută pentru un mouse PS/2. Dacă se folosește un mouse conectat la portul COM1, atunci sunt specificați doi parametri „MOUSE_PROTOCOL=Microsoft” și „MOUSE_DEVICE=/dev/ttyS0”, dacă la portul COM2, al doilea parametru este /dev/ttyS1.

Fișierul meu de configurare comun /tftpboot/thinstation.conf.network este aproape gol. Toate informațiile din acesta sunt plasate în fișiere separate de setări de grup, la care se face referire în thinstation.hosts. Deoarece sunt utilizate două servere terminale cu versiuni diferite de NX și fiecare client folosește doar propriul server, configurațiile sunt plasate în fișiere text separate (NX și TUX1C), în plus, sunt folosite diferite imagini Thinstation. De asemenea, nu uitați că numele fișierelor thinstation.nbi și thinstation.nbi.zpxe sunt interdependente: dacă linia este specificată în dhcpd.conf:

thinstation.nbi.zpxe";

atunci se va folosi imaginea thinstation.nbi, în cazul meu sunt mai multe imagini și, în consecință, intrările din dhcpd.conf sunt diferite pentru fiecare terminal.

Diferențele de construcție NX2

faceți lumea BOOTSTRAPCFLAGS="-m32"

Aparent, acestea sunt caracteristici ale sistemului pe 64 de biți și ale bibliotecilor sale. Puțin mai târziu, am găsit o notă pe site-ul Nomachine care spunea că codul sursă NX a fost dezvoltat pentru sisteme pe 32 de biți, dar poate fi folosit și pe sisteme pe 64 de biți. Deoarece încă mai am un computer cu SLED 10.0 x86 instalat și versiunile tuturor bibliotecilor, nucleului și programelor sunt exact aceleași ca SLES, am decis să construiesc NX pe el și apoi să transfer directorul cu rezultatul build-ului prin copiere normală. la un sistem pe 64 de biți. Asta am făcut: totul a funcționat ca și cum nimic nu s-ar fi întâmplat. Descărcăm fișiere cu aceleași nume ca atunci când construim versiunea 1.5, doar cu sufixele 2.0 (sau 2.1). Totul se compilează exact la fel ca în cazul lui NX 1.5, cu câteva excepții: în primul rând, nu am aplicat patch-ul NX-lfs_hint.diff, în al doilea rând, a apărut o nouă versiune a scripturilor FreeNX 0.5, care suportă noul NX 2.0, îl puteți ridica de aici, în al treilea rând, fișierul freenx-lfs_hint.diff, care face modificări fișierului nxloadconfig din FreeNX 0.4, nu se potrivește cu noua versiune de FreeNX, trebuie editat. Iată rezultatul comenzii diff, care arată diferența dintre fișierul nxloadconfig original și editat:

--- nxloadconf_orig 2006-07-01 22:03:39.000000000 +0500

+++ nxloadconfig 2006-10-16 12:32:19.000000000 +0500

@@ -56,12 +56,12 @@

NX_LICENSE="OS (GPL)"

# Unde pot fi găsite diferite componente nx

-NX_DIR=/usr

+NX_DIR=/srv/NX

PATH_BIN=$NX_DIR/bin # dacă o modificați, asigurați-vă că o faceți și

schimba cheile publice

PATH_LIB=$NX_DIR/lib

-NX_ETC_DIR=/etc/nxserver

-NX_SESS_DIR=/var/lib/nxserver/db

-NX_HOME_DIR=/var/lib/nxserver/home

+NX_ETC_DIR=$NX_DIR/etc

+NX_SESS_DIR=$NX_DIR/var/db

+NX_HOME_DIR=$NX_DIR/home/nx

# NUMAI utilizatori avansați

AGENT_LIBRARY_PATH="" #Calculat

@@ -265,7 +265,7 @@

[ -z „$AGENT_LIBRARY_PATH” ] && AGENT_LIBRARY_PATH=$PATH_LIB

[ -z „$PROXY_LIBRARY_PATH” ] && PROXY_LIBRARY_PATH=$PATH_LIB

[ -z „$APPLICATION_LIBRARY_PATH” ] && APPLICATION_LIBRARY_PATH=$PATH_LIB

-[ -z "$APPLICATION_LIBRARY_PRELOAD" ] && APPLICATION_LIBRARY_PRELOAD="$APPLICATION_LIBRARY_PATH/libX11.so.6.2:$APPLICATION_LIBRARY_PATH/libXext.so.6.4:$APPLICATION_LIBRARY_PATH/libX11.so.6.2:$APPLICATION_LIBRARY_PATH/libXext.so.6.4:$APPLICATION_LIBRARY_PATH .1: $ APPLICATION_LIBRARY_THE/libXrender.so.1.2"

+[ -z "$APPLICATION_LIBRARY_PRELOAD" ] && APPLICATION_LIBRARY_PRELOAD="$APPLICATION_LIBRARY_PATH/libX11.so.6.2:$APPLICATION_LIBRARY_PATH/libXext.so.6.4:$APPLICATION_LIBRARY_PATH/libX11.so.6.2:$APPLICATION_LIBRARY_PATH/libXext.so.6.4:$APPLICATION_LIBRARY_PATH ext.deci. 2.1 .0:$APPLICATION_LIBRARY_PATH/libXrender.so.1.2"

[ -z „$KDE_PRINTRC” -a -n „$KDEHOME” ] && KDE_PRINTRC="$KDEHOME/share/config/kdeprintrc"

[ -z „$KDE_PRINTRC” -a -z „$KDEHOME” ] && KDE_PRINTRC="$HOME/.kde/share/config/kdeprintrc"

@@ -511,8 +511,8 @@

[ -z $(echo „$ENABLE_ROOTLESS_MODE” | egrep „^$”) ] && \

ERROR="yes" && echo "Eroare: valoare invalida\"ENABLE_ROOTLESS_MODE=$ENABLE_ROOTLESS_MODE\""

- [ -z „$(șiruri $PATH_BIN/nxagent | grep „NXAGENT - Versiunea 1.5.0”)” ] && \

- ERROR="yes" && echo "Eroare: Nu s-a putut găsi șirul versiunii 1.5.0 în nxagent. Backend-ul NX 1.5.0 este necesar pentru această versiune de FreeNX."

+# [ -z "$(șiruri $PATH_BIN/nxagent | grep "NXAGENT - Versiunea 1.5.0")" ] && \

+# ERROR="yes" && echo "Eroare: Nu s-a putut găsi șirul versiunii 1.5.0 în nxagent. Backend-ul NX 1.5.0 este necesar pentru această versiune de FreeNX."

[ -z $(echo „$ENABLE_USESSION” | egrep „^$”) ] && \

ERROR="yes" && echo "Eroare: valoare nevalidă \"ENABLE_USESSION=$ENABLE_USESSION\""

Nxloadconfig trebuie editat înainte de a rula comanda /srv/NX/bin/nxsetup. În fișierul de configurare /srv/NX/etc/node.conf, decomentați linia:

ENABLE_2_0_0_BACKEND="1"

Acum să vedem ce trebuie schimbat în distribuția Thinstation ( ultima versiune acum 2.2) pentru a suporta NX 2.0 pe partea clientului. La momentul scrierii, doar versiunea client 1.5 era acceptată. Luăm de la adresa client NX, care nu necesită suport pentru biblioteci XFT, sub forma unei arhive tar.gz (momentan este nxclient-2.1.0-9.i386.tar.gz), o despachetăm în directorul principal, copiați fișierele și creați link-urile celor lipsă.

#!/bin/sh

tar -xzf nxclient-2.1.0-9.i386.tar.gz

cp ~/NX/bin/* ~/thinstation/packages/nx/usr/NX/bin

cp -fl ~/NX/lib/libXcomp.so.* ~/thinstation/packages/nx/usr/NX/lib/

ln -sf libXcomp.so.2.1.0 ~/thinstation/packages/nx/usr/NX/lib/libXcomp.so.1.5.0

cp ~/NX/share/keys/server.id_dsa.key ~/thinstation/packages/nx/usr/NX/share/keys

cp ~/NX/share/keyboards ~/thinstation/packages/nx/usr/NX/share/

cp -R ~/NX/share/images ~/thinstation/packages/nx/usr/NX/share/

atingeți ~/thinstation/packages/nx/build/installed

După acești pași, pachetul NX este considerat instalat în arborele pachetelor Thinstation, acum asamblam imaginea rulând build și o copiem pe serverul tftp. Ei bine, imaginea este gata și plasată în directorul serverului tftp, dar asta nu este tot. Se pare că noua versiune a clientului NX pe clientul subțire interpretează diferit setările din fișierele thinstation.conf.group-TUX1C(NX). După câteva cercetări, s-a dovedit că fișierul de setări de sesiune NX ar trebui creat în rădăcina sistemului de fișiere client subțire. A trebuit să fac un mic patch pentru Thinstation, am văzut ideea pe un forum:

# Patch-ul copiează pur și simplu fișierele de setări ale clientului NX din locația standard la rădăcină

ls $HOME/.nx/config/.>nxsessions

if [ -s nxsessions ] ; apoi

(cat nxsessions) |

în timp ce se citește numele fișierului; do

probe=$(nume fișier%*.nxs)

if [ "$filename" != "$probe" ]

apoi

cp $HOME/.nx/config/$filename /$probe

Terminat

rm nxsessions

Această bucată de cod ar trebui să fie inserată la sfârșitul fișierului ~/thinstation/packages/nx/etc/init.d/nx.init înainte de ultima comandă „exit 0”. După aceasta, trebuie să reconstruiți imaginea Thinstation. Acum, sesiunea NX pe clientul subțire începe așa cum a fost prevăzut. În general, noua versiune funcționează mai stabil, sesiunile sunt gestionate mai corect, plus algoritmii de compresie au fost actualizați în cele mai recente surse, iar unele erori au fost remediate. Anterior, pentru a curăța și a închide sesiunile și procesele neterminate, trebuia să apelezi la cron:

1 0 * * * root /srv/NX/bin/nxserver –cleanup

De asemenea, este convenabil ca clientul NX 2.1 să lucreze cu serverele ambelor versiuni.

Figura 4. Sesiune NX în modul aplicație (1C)

În numărul următor, citiți continuarea articolului, în care voi vorbi despre caracteristicile de operare, setările suplimentare ale NX și Thinstation și, de asemenea, voi oferi soluții la unele posibile probleme.

1. Borisov A. Client subțire - un pas către mainframe? //Administrator de sistem, nr. 11, noiembrie 2005 – p. 32-38.

2. Markelov A. Utilizarea stațiilor Linux fără disc cu încărcare în rețea. //Administrator de sistem, nr. 11, noiembrie 2004 – p. 12-14.

Deci, nu aveți nevoie de mult efort pentru a crea un client subțire de pe un computer obișnuit. Pentru o înțelegere minimă a acestui articol, trebuie să aveți cel puțin o idee vagă despre:

Timpul trece, hardware-ul devine învechit din punct de vedere fizic și moral, managementul, ca de obicei, nu are bani pentru a cumpăra noi computere în organizație, în acest caz există posibilitatea de a „respira viața” în gunoiul muzeului. Pentru client subțire Orice va face o raritate cu o frecventa de procesor single-core de 1 GHz si RAM 128 MB, iar cel mai important detaliu este placa de baza cu placa de retea ce suporta PXE boot. Nu vom avea nevoie deloc de un hard disk sau de o unitate de dischetă, vom face un adevărat client subțire, și nu o parodie jalnică! ;)

Cum să faci un client subțire de pe un computer vechi (metoda 2)

Pregătirea clientului subțire și echipamente suplimentare.

Desigur, mai întâi asamblați o unitate mai mult sau mai puțin vie din gunoi, așa cum am spus mai sus, nu avem deloc nevoie de un hard disk, în ceea ce privește unitatea de disc și alte periferice, totul depinde de sarcina pe care o avem la îndemână. clientul trebuie să facă față, am avut destule periferice la serviciu doar monitor, tastatură, mouse, dispozitive USB Conducerea a considerat-o inutil (cu excepția tastaturii și a mouse-ului, desigur), deoarece dorința de a face sistemul mai închis a depășit dorințele utilizatorilor (în mod ciudat, am fost de acord cu ei în acest sens, toate funcțiile suporturi amovibileînlocuiește e-mailul și stocarea internă a fișierelor și pentru cei cu care trebuie să lucreze fișiere mari iar performanța de la PC-uri nu s-a tradus deloc în clienții subțiri). După ce sunteți convins că hardware-ul funcționează, trebuie să configurați boot-ul de pe placa de rețea în BIOS și să dezactivați toate celelalte metode de pornire. Acest lucru se face diferit pe diferite covoare. plăci, dar esența se rezumă la un singur lucru.

Pentru a opera un client subțire, aveți nevoie de un server care va acționa ca o stație de lucru la distanță la care se va conecta clientul nostru subțire. Nu mă voi opri în detaliu asupra tuturor tipurilor de locuri de muncă la distanță, ne vom concentra pe cel mai popular Terminal Server de la Microsoft. Vom presupune că aveți deja un server pe care să îl implementați Terminal Server, de exemplu, pe Windows Server 2008 R2. Dacă nu este nevoie să conectăm utilizatorii din afara organizației, atunci vom lua în considerare configurarea conexiunii doar „intern”. Lăsați serverul nostru terminal să aibă un intern IP 192.168.0.5.

DHCP

Acum să configuram DCHP pentru a distribui adrese IP clienților noștri subțiri și parametri suplimentari. Puteți citi cum să configurați DHCP pe Windows Server 2008 aici, pentru Linux Server aici. În acest articol voi indica doar ceea ce trebuie ajustat la circuitul finit.

Pentru a configura în Windows Server 2008 R2: să trecem la parametrii zonei

Selectați Configurare parametri și adăugați un parametru:

066 Numele de gazdă al serverului de descărcare și indicați adresa IP a serverului nostru TFTP (în cazul nostru 192.168.0.4)

067 Descărcați numele fișierului, introduceți pxelinux.0

și nu uitați să reporniți serviciul DHCP.

Instalarea în Ubuntu Server :

Va fi mai târziu

Server TFTP

Setări, în Ubuntu Server 14.04 LTS . De asemenea, puteți utiliza programul tftpd32 pentru sistemele Windows

Distribuția substației

Puteți face cunoștință cu capacitățile acestei distribuții pe site-ul dezvoltatorului http://thinstation.github.io/thinstation/. Pentru a obține o distribuție funcțională cu posibilitatea de a descărca de pe un server TFTP, trebuie să o asamblați, nu voi lua în considerare modul în care se face acest lucru, ci voi folosi o distribuție gata făcută cu posibilitatea de a descărca printr-o versiune de rețea PXE a ansamblului (oglindă) compilat cu opțiunea allmodules (pentru aceasta există o mulțumire separată pentru nik0el ). Descărcați arhiva și despachetați-o, acum trebuie să împrăștiați fișierele. Mă voi uita la exemplul unui server TFTP configurat în Windows Server 2008 R2.

Să punem toate fișierele și folderele așa cum sunt în C:\TFTPRoot

Acum să începem configurarea fișierelor principale pe care le veți edita pentru a se potrivi nevoilor dvs.:

thinstation.conf.network - responsabil pentru setările implicite de conexiune pentru toți clienții subțiri

thinstation.conf.sample -

thinstation.hosts - specifică setările individuale

thinstation.conf.group-... - în loc de puncte, este indicat numele grupului (1280@75 - rezoluție și frecvență, utilizator - numele clientului subțire atribuit în fișierul thinstation.hosts etc.)

Mai jos sunt parametrii ușor editați în funcție de adresele noastre IP:

thinstation.conf.network

ECRAN=0
WORKSPACE=1SESSION_0_TITLE="Server terminal"!}
SESSION_0_TYPE=rdesktop
SESSION_0_SCREEN=1
SESSION_0_RDESKTOP_SERVER=192.168.0.5
SESSION_0_RDESKTOP_OPTIONS="-u „utilizator””
SESSION_0_AUTOSTART=On#SESSION_#_TITLE="Big Bad Server Donald"!}
#SESSION_#_TYPE=freerdp
#SESSION_#_ECRAN=1
#SESSION_#_SCREEN_POSITION=2
#SESSION_#_FREERDP_SERVER=192.168.1.1
#SESSION_#_FREERDP_OPTIONS="-u nume utilizator -p parola"
#SESSION_#_AUTOSTART=OffRDESKTOP_SOUND=Dezactivat
RDESKTOP_FDD=Dezactivat
RDESKTOP_CDROM=Dezactivat
RDESKTOP_HDD=Dezactivat
RDESKTOP_USB=Dezactivat
RDESKTOP_1394=Dezactivat
RDESKTOP_COM3=Dezactivat
RDESKTOP_COM4=Dezactivat
RDESKTOP_SLOWLINK=Activat
RDESKTOP_COMPRESSION=Activat
RDESKTOP_COLOR_DEPTH="16"
#RDESKTOP_DOMEN=domenul meu
RDESKTOP_USB_NO_MOUNT_DIR=OnFREERDP_USB_NO_MOUNT_DIR=Activat # Montați unitatea USB pornit/dezactivat
FREERDP_USB=Oprit # Mount USB Drive On/Off
FREERDP_SOUND=Activat # Audio, Activat/Oprit
FREERDP_KEYMAP=419 # Număr keymap
FREERDP_CONSOLE=Oprit # Conectare la consolă, Pornit/Oprit
FREERDP_SLOWLINK=Dezactivat # Legătură de rețea lentă, Activat/Dezactivat
FREERDP_COMPRESSION=Dezactivat # Compresie RDP, Activat/Dezactivat
FREERDP_CDROM=Oprit # Unitate CDROM prezentă, Pornit/Oprit
FREERDP_CDROM_SATA=Dezactivat # SATA CDROM prezent, Pornit/Oprit
FREERDP_FDD=Oprit # Floppy Drive prezent, Pornit/Oprit
FREERDP_USBFDD=Dezactivat # Dischetă USB prezentă, Pornit/Oprit
FREERDP_HDD=Oprit # Unitate HDD prezentă, Pornit/Oprit
FREERDP_1394=Oprit # HDD FireWare prezent, Pornit/Oprit
FREERDP_COM3=Oprit # Redirecționare COM1, Pornit/Oprit
FREERDP_COM4=Oprit # Redirecționare COM2, On/OffKEYBOARD_MAP=en_us
TIME_ZONE="Europa/Moscova"
AUDIO_LEVEL=67
AUTOPLAYCD=Activat
DAILY_REBOOT=Activat
CUSTOM_CONFIG=dezactivat
RECONNECT_PROMPT=meniu
NET_TELNETD_ENABLED=Activat
SCREEN_RESOLUTION="1024x768"
SCREEN_HORIZSYNC="30-65"
SCREEN_VERTREFRESH="75"
SCREEN_COLOR_DEPTH="16"
MOUSE_PROTOCOL=IMPS/2
MOUSE_RESOLUTION=100
MOUSE_ACCELERATION="1"
X_DRIVER_OPTION1="swcursor activat"
PRINTER_0_NAME=paralel
PRINTER_0_DEVICE=/dev/printers/0
PRINTER_0_TYPE=P
PRINTER_1_NAME=usb
PRINTER_1_DEVICE=/dev/usb/lp0
PRINTER_1_TYPE=U

thinstation.hosts

# NUME MAC GROUP #COMMENT #thinstation01 0013D409A812 1024@75 cdrom fdd usb #192.168.0.21 utilizator 000A5E1ADCAA 1280@60 cdrom usb #192.168.0.10

Aici atribuim un nume pentru adresa Mac a clientului subțire și indicăm grupurile de setări. În exemplu, acesta este un grup cu setări pentru monitor, unitate și porturile USB.

Accident

Acum asigurați-vă că serverele sunt în funcțiune. Porniți clientul subțire, după descărcarea distribuției și lansarea completă a acesteia, se va deschide o fereastră pentru introducerea numelui de utilizator și a parolei pentru a vă conecta la serverul nostru terminal. În exemplu, am folosit clientul rdesktop pentru a vă conecta și există aproximativ 10 soiuri pe care le puteți alege și personaliza pentru dvs.

Există o a doua metodă descrisă în articol