FreeBSD v malej firme - 6 (terminálové služby)

12. 12. 2005 | Michal Kyseľ | Návody | 8361×

V tomto dieli seriálu sa pozrieme na to, ako možno jednoducho zdieľať prostriedky servera pri práci s aplikáciami bežiacimi na X, a ako na to využiť aj staré menej výkonné počítače.

Terminály sa vracajú späť - alebo vývoj ide v špirále

Myšlienka terminálu je stará takmer ako počítače samy. V princípe sa jedná o to, ako pristupovať k využívaniu služieb centrálneho počítača pomocou klientskeho zariadenia, pričom klientské zariadenie využíva užívateľ iba na vstup a výstup a samotný program beží na hlavnom počítači. Tieto riešenia (ešte na báze znakových - alfanumerických terminálov) boli s príchodom prvých sálových počítačov bežne využívané a samozrejmé, kým ich nevytlačila éra PC s filozofiou samostatného plnohodnotného počítača na každom stole. Na začiatku sa zdalo, že toto riešenie má spústu výhod. Áno, má, ale iba pre niektoré prípady nasadenia. Žiaľ, pre firemný informačný systém toto usporiadanie prináša veľa nevýhod, či už z hľadiska prevádzky, funkcionality alebo nákladov na prevádzku a udržovanie takéhoto systému v konzistentnom a stále aktuálnom stave. Proste pri nárokoch na firemný IT systém je jednoznačne výhodnejšie, úspornejšie a elegantnejšie riešenie na princípe centralizovaného systému.

Dnes sa teda oprášená myšlienka terminálu po rokoch vracia späť, avšak obohatená o možnosti použitia grafického režimu, čo je pre dnešné firemné riešenia už nutnosť. Výhody tohoto usporiadania sú zjavné:

1. spoločný dátový priestor s hromadným zálohovaním
2. jednoduchá administrácia
3. bezproblémová integrácia celého firemného prostredia do jedného kompaktného celku
4. všetky IT prostriedky je možné bez problémov pružne zdieľať v prípade potreby ktorýmkoľvek z užívateľov a sú stále k dispozícii
5. každý užívateľ sa môže prihlásiť z ľubovoľného stroja a okamžite má k dispozícii svoje aplikácie, svoje dáta aj svoje nastavenie prostredia, samozrejme aj rovnaký výpočtový výkon
6. optimalizácia utilizácie systémových prostriedkov
7. jednoduchšie riešenie havarijných situácií, prestojov a výpadkov
8. ekonomická výhoda takéhoto riešenia - možnosť využitia morálne zastaralej výpočtovej techniky na plnohodnotnú prácu
9. bezpečnosť
10. škálovateľnosť

Aj firmy, ktoré predtým odmietali terminálové riešenia, sa k nim teraz potichu vracajú. Napríklad taký Microsoft a jeho Terminal Server...

Prečo teda terminálové riešenie v malej firme?

Ak sú dáta uložené na jednom mieste, je záloha veľmi jednoduchá, stačí zálohovať dáta na serveri. Pracovná stanica nemá nič, čo by stálo za námahu pri zálohovaní a čo by bolo potrebné nejak extra chrániť (body 1, 9). V prípade potreby sa dá nahradiť ktoroukoľvek inou (viď bod 7).

Výhodné je aj to, že súbory sú na jednom mieste a teda sú v rámci celej firmy informačne konzistentné. Iste každý pozná situáciu, keď je jeden dokument v rôznom štádiu rozpracovanosti na desiatich či viacerých strojoch, užívateľ začne písať do jednej kópie a zabudne na to, že včera písal do inej, čo sa síce volala rovnako, ale bola na inom stroji / v inom adresári (pre usera je to iba drobný nepodstatný detail...). Nakoniec takýto prípad skončí chaosom ("včera niečo napíšem, dnes to tam nemám, zase to vyzerá inakšie") a nastupuje informatik, ktorý sa zúfalo snaži dať dáta dohromady a urobiť z n verzií jednu aktuálnu a úplnú... pri jedinom dátovom úložisku a rozumne nastavených prístupových právach sa to pochopiteľne stať nemôže.

Správa takéhoto centralizovaného systému sa potom redukuje na správu centrálneho počítača. Všetko je pohromade a pod kontrolou správcu, useri, aplikácie, dáta, služby. Kdekoľvek sa user prihlási, všade mu systém ponúkne rovnaké, jeho do detailu nastavené prostredie. Každý má presne definované práva. Všetky zdieľané prostriedky sú na serveri, teda ak sa užívateľ úspešne prihlási a má na ne práva, môže ich využívať bez problémov a riešenia zdieľaní, komunikácie a autentifikácie medzi n stanicami. Takisto správca môže väčšinou odstrániť problém bez zbytočného behania od stanice k stanici a obojstranne nepríjemného odstavovania userov od práce. Nikdy sa nijaké nastavenie nerozhodí "samo od seba", ani nikto z userov nemá možnosť zasiahnuť do niečoho, čo môže ohroziť systém alebo dáta v ňom. Dáta nikdy neopustia server a neskopírujú sa na klientskú stanicu, klientska stanica prijíma iba výstup z ich spracovania a posiela serveru vstupné údaje, čo je veľké plus pre bezpečnosť citlivých údajov.

Kto sa niekedy staral len o niekoľko Win staníc, chápe rozdiel.

Ako klientské stroje možno použiť staré PC s pamäťou minimálne 64 MB (viac RAMky je samozrejme lepšie, terminály potom neswapujú a systémy im bežia priamo z RAM, naše majú 128 a jeden dokonca 256), procesorom min. Pentium 200 MHz a malým diskom, na ktorom je inštalácia minimálneho základného systému a X. Klientské stroje sú prakticky bezúdržbové a nie je okrem občasnej kontroly konzistencie disku ani nutné ich akokoľvek spravovať. V prípade nasadenia bezdiskových staníc odpadá aj tento posledný krok (tam je zasa nevýhodou o hodne pomalší štart, daný tým, že si musí stanica počas bootu celý systém stiahnuť zo siete). Kto chce a má trochu viac peňazí, môže bootovať aj z Compact Flash ROM a vyhnúť sa tak hrkotajúcemu a potenciálne poruchovému disku, predávajú sa CF adaptéry na bežný IDE kábel.

Za pozornosť stoja body 6, 8 a 10. Veľmi spolu súvisia. Ak systém prestane zvládať požadovanú záťaž, stačí vymeniť server za výkonnejší a ide sa ďalej naplno, na rýchlosť systému nemá klientská stanica takmer nijaký vplyv. Výkon skôr ovplyvňuje rýchlosť prenosu dát po sieti, latencia prenosu (teda časové oneskorenie - doba od vyslania dát po ich doručenie) a samozrejme výkon servera samotného. Preto sa po určitej dobe nemusia vyraďovať staršie PC, hoci by už nespĺňali požadované HW parametre na samostatnú prevádzku, na funkciu zobrazovacej vstupno-výstupnej jednotky majú stále výkonu dostatok a možno ich použiť prakticky dovtedy, dokedy slúžia. To je veľmi výhodné aj z hľadiska nízkych nákladov na zostavenie a upgrade takéhoto riešenia. Navyše server plynule rozdeľuje výpočtový výkon tým procesom, ktoré ho potrebujú, a preto aj keď je vyťažený takmer naplno, užívatelia pracujú plynule a rýchlo. K tomu však netreba kupovať n výkonných strojov (ktoré by po 80 percent času iba stáli a počítali šetrič a iba 20 percent ich výkonu by sa skutočne využilo na prácu), ale iba jeden. Teda výhoda investičná aj prevádzková zároveň...

Licencie komerčných riešení sa môžu predražiť

Silným dôvodom pre nasadenie unixového terminálového systému je aj cenová a licenčná politika MS - je rozdiel kúpiť trebárs 5 samostatných plne vybavených PC pracovných staníc, ku každej z nich OS Windows + kancelársky a iný software, a kúpiť 5 lacných starších počítačov iba za cenu HW, bez OS, bez platenia softwarových licencií na každú inštaláciu. Takto možno aj s malým rozpočtom postaviť veľmi solídny firemný systém. Celá vec stojí (a padá) len na fantázii a schopnostiach admina - tvorcu firemného informačného systému.

V prípade Microsoft Terminal server to nie je žiadna výhra - majiteľ systému musí zaplatiť cenu licencie OS Windows v klientskom stroji (z niečoho ten TS klient predsa spustiť musí), licenciu MS Server 2000, licenciu MS Terminal Server a potom ešte licenciu z každého sedenia (per seat). A má holý systém bez aplikácií, ktorého klientske stanice vyžadujú úplne rovnakú starostlivosť ako samostatné stroje (ten Windows treba pravidelne čistiť od temporaries, defragmentovať, udržiavať aktuálny antivírus atď). Jediným zachovaným plus z celej terminálovej koncepcie tu ostáva to, že stanice používajú výpočtový výkon servera.

Ekonomický aj prevádzkový efekt nasadenia terminálov v prostredí MS sa teda viacmenej stráca a pre malú firmu je to dokonca silne nevýhodné riešenie... záujemcom doporučujem ako povinné čítanie cenníky Microsoftu.

Obdobná situácia je, keď sa miesto MS Terminal Servera kúpi Citrix - všetky hore uvedené veci (až na iný typ terminálovej nadstavby MS servera) platia opäť.

Dajme užívateľom to najlepšie!

Ešte jedna poznámka, skôr psychologická ako odborná - aby užívateľ nemal pocit, že sedí len pred nejakým "orezávatkom" a že mu admin hodil na stôl ten posledný šrot z celej firmy, je vhodné dať terminálom pokiaľ možno veľké monitory a optické myši (a samozrejme aj skrinky PC vyčistiť od prachu, nálepiek a inej špiny, aby vyzerali k svetu). Z hľadiska prevádzky je to síce bez významu, ale z hľadiska akceptácie nového systému nedôverčivým Win užívateľom to má význam obrovský. Ťažko niekoho nadchne stará zaprášená kraksňa s blikajúcim 15" monitorom. Zato keď niekomu postavím na stôl monitor devätnástku s perfektným ostrým obrazom, na ktorom je radosť čítať, to je niečo iné... A keď ešte spozná tú rýchlosť práce, nazad ku Windowsu sa mu nebude chcieť. Monitor 19" sa dá v bazári zohnať za pár tisíc. Celá zostava sa v prípade bazárového predaja dá kúpiť tak za 4 až 5 tisícok Sk. Porovnajme si to s cenou novej PC zostavy...

Topológia siete

Pre terminálovú sieť je optimálne a najčastejšie využívané hviezdicové usporiadanie, kde základ siete tvorí switch, na ktorý sa pripájajú stanice aj server. Nedoporučujem používať hub, pre rýchlu prácu s xdmcp reláciami je potrebné mať malú latenciu a pokiaľ možno vysokú priepustnosť siete. Tu má switch oproti hubu výhodu, že posiela pakety iba príjemcovi a ostatní účastníci siete nie sú bombardovaní hromadou cudzích paketov, ktoré by ich spomaľovali a zbytočne zvyšovali traffic. Navyše je to aj výhoda z hľadiska bezpečnosti. V praxi sa osvedčil malý osemportový 100 MBit switch, chodí to rýchlo a odozvy terminálov mám v reálnom čase. Plánujem rozšírenie na 16 portový rackový switch.

Udržanie nízkej latencie komunikácie je pre X dokonca dôležitejšie ako prenosová rýchlosť samotná. Skúšal som pripojiť terminál cez 11 MBit WiFi a napriek tomu, že šírka pásma stačila a nebola využitá "na doraz", oneskorenie prenosu bolo tak strašné, že sa dalo robiť iba s veľkým sebazaprením... niekedy človek videl reakciu na úkon, ktorý urobil, až po pár sekundách. Použiteľné to bolo snáď iba na núdzové účely, rozhodne nie na serióznu prácu.

Konfigurácia na strane servera (X klienta)

Pre rozbehnutie terminálových služieb X je potrebné nastaviť na serveri (tu sa myslí počítač, na ktorom aplikácie fyzicky pobežia, z hľadiska terminológie systému X window je to X klient) konfiguračný súbor správcu prihlásenia, aby umožňoval pripojovanie vzdialených sedení cez protokol xdmcp (X Display Manager Communication Protocol). V našom prípade sa použil správca prihlásení kdm. Jeho konfiguračný súbor sa nazýva kdmrc a nájdeme ho v adresári /usr/local/share/config/kdm. Súbor má veľmi ľahko pochopiteľné názvy premenných a jeho jednotlivé voľby teda nie je problém nájsť a nastaviť. Pre povolenie vzdialených sedení je treba nastaviť sekciu [Xdmcp] takto:

[Xdmcp]
Enable=true
Port=177
Willing=/usr/local/share/config/kdm/Xwilling
Xaccess=/usr/local/share/config/kdm/Xaccess

Prvý riadok zapína xdmcp protokol, v druhom sa určuje, na akom tcp porte má X komunikovať. Pre xdmcp v firemnej LAN sieti sa doporučuje nechať tam výchozí port 177. Meniť to má význam iba v odôvodnených prípadoch, napríklad keď chceme riešiť bezpečné pripojenie vo verejnej sieti tunelovaním protokolu xdmcp cez ssh. Tretí riadok hovorí o ceste na skript Xwilling, ktorý umožňuje samotné vzdialené prihlásenie. Pre bezpečnosť je podstatný štvrtý riadok, ktorý ukazuje cestu na súbor Xaccess. Jedná sa o konfiguračný súbor v tom istom adresári ako kdmrc, ktorý povoľuje prístup na X jednotlivým IP adresám. Po inštalácii je nastavený tak, aby povolil prihlásenie akéhokoľvek stroja, ktorý o vytvorenie vzdialenej X session požiada. Jeho editáciou môžeme zakazovať a povoľovať prístupy jednotlivým klientským staniciam.

Ešte tri poznámky. Z bezpečnostných dôvodov je zakázaný login roota do KDE. Ak ho z nejakých príčin potrebujeme , dá sa to urobiť v kdmrc v sekcii [X-*-Core] cez voľbu AllowRootLogin=true - pôvodne je tam nastavené false.

Druhá dôležitá vec - je dobré na serveri zakázať možnosť vypnúť počítač zo vzdialenej X session. Predídeme tým nepríjemnostiam, keď nejaký "snaživec" namiesto ukončenia sedenia vypne server a s ním aj ostatných užívateľov s rozrobenou prácou. Toto je možné najjednoduchšie urobiť v ovládacom centre KDE, kde v sekcii Správca prihlásenia nastavíme, že shutdown je povolený iba z lokálneho prihlásenia. Samozrejme je možné nastaviť to aj editáciou kdmrc, kde povolíme shutdown z lokálu a zakážeme ho z vzdialeného prihlásenia.

Tretia poznámka, ktorú som už uviedol v časti Inštalácia, pre každý prípad ju však opakujem. Z mne neznámeho dôvodu protokol xdmcp vo FreeBSD nechodí bez povolenia IPv6 v konfigurácii siete na strane klienta aj servera. Sám som strávil dva týždne rozmýšľaním nad tým, prečo mi terminál nepripojí vzdialený server. Potom som narazil na popis chyby na jednej konferencii o FreeBSD a KDE. Riešenie popisované v konferencii bolo jednoduché, povoliť IPv6. Po nastavení ipv6_enable="YES" v /etc/rc.conf na serveri aj termináli sa terminál okamžite pripojil. Zrejme blokovanie IPV6 nechcene zablokuje aj xdmcp... ale môže to byť len môj dohad. Každopádne to po príslušnom nastavení funguje a chodí bez chyby.

Konfigurácia na strane terminálu (X servera)

Na strane X terminálu (v terminológii X window sa nazýva X server) je iba potrebné spustiť X s parametrom query na daný server. Keďže od obyčajných userov nemôžem chcieť, aby sa prihlásili lokálne do konzoly a odtiaľ si ručne spustili vzdialenú reláciu X, musíme tento proces automatizovať. Mne sa osvedčilo jednoduché riešenie. Do adresára /etc/rc.d treba vytvoriť súbor s názvom X.sh. Je to jednoduchý shellový skript, ktorý obsahuje iba dva príkazy:

/usr/X11R6/bin/ X -query 10.10.10.10
shutdown -p now

kde 10.10.10.10 je adresa nášho terminálového servera. Po štarte systému na terminálovej stanici automaticky nabehne vzdialené prihlásenie na server a objaví sa nám rovnaké prihlasovacie okno ako na serveri samotnom. Ak chce užívateľ skončiť prácu s terminálom, ukončí beh X na termináli cez Ctrl+Alt+Backspace a ihneď sa spustí ukončovacia sekvencia, ktorá zastaví systém a (v prípade, že to matičná doska umožňuje a táto vlastnosť je u nej podporovaná) automaticky vypne napájanie terminálu. Ak nie, iba ukončí systém a treba terminál ručne vypnúť.

To by bolo snáď všetko. Ak ste nastavili všetko tak, ako treba, mal by vám bez problémov bežať terminálový systém. Zatiaľ sa lúčim s pozdravom: nech vám vaše systémy idú!

       

Komentáře

[Peter S.]

Je to super, vďaka
Ale chcel by som sa spýtať aká kapacita linky je potrebná. Akurát som skúšal xforwarding, teda prenos iba jednotlivej aplikácie, a celkovo to fungovalo, ale asi by to žiadalo silnejšiu linku. Robil som to cez ssh, v rámci siete môjho providera. Rýchlosť bola cca 100 KB/s (nie Kbit), teda celkom slušná, ale stačilo ako tak len na aplikáciu s malou plochou (psi - napriklad). Aj kwrite sa ako tak dalo, ale napríklad Krusader to už trvalo dlho kým ho prekreslilo. Teda celkovo to nebolo na reálne použivanie, ale napríklad som takto konfiguroval kamošovi aplikáciu na dialku - na toto je to super.
Ešte jedna vec - je možnosť pri ssh použiť parameter -C =komprimovať prenos, skúšil som to ale rozdiel bol minimálny. Nie je mi ale jasné, že keď nakonci vyhodí, kompresný pomer 19 %, to znamená, že objem dát stlačilo na 19 % pôvodného objemu alebo o 19%? Sorry za off-topic otázku :)

[Zdeněk Štěpánek]

Zdravim

S tou kompresi nevim, ale 1Mbit je na tenkyho klienta opravdu malo. Casto nejde ani tak o prutok, ale o latence. Obecne lze rict, ze s 10Mbit sitovkou u klienta lze pracovat (rozdil oproti 100 je znat, ale ne moc), ale switch a server musi byt 100Mbit. Samozrejme 100Mbit switch s 1Gbit uplinkem je vyhra. Nas takova sit v praci ceka pres zimu, joj to se tesim, to bude klientu

Cili se to opravdu hodi jen pro moderni 100Mbit site se switchi.

Zdenek

[zz]

ten uplink nieje potreba pokial mate inteligenty switch. tie vedia robit "IEEE 802.3ad Dynamic link aggregation" takze namiesto 1G uplinku ktory vyde draho sa do isteho mnozstva klientou pouzit i n*100Mbis sietovky z (bondingom - linux, etherchanel - cisco, trunking - solaris) dosiahnete tak zvysenia prenosovky. cisco switch co tu mam ma limit 16 portou v kanaly, linux je zevraj obmedzeni poctom sietoviek v systeme.

co sa tyka jeden znamy mi uz davnejsie hovoril ze 100Mbit siet je postacujuca maximajen na 10 terminalov. ale mam dojem ze boly na hube nie switchi

[ivan]

Ono ani nejde o kapacitu linky jako o rychlost odezvy. X Window protocol porad neco potrzuje. Tyhle problemy by mel resit protocol NX, ale jeste jsem nemel cas to vyzkouset.

Ivan

[Pavel Hradecky]

Za pomocí NX se dá opravdu provozovat terminál i přes modem. Sice trochu déle trvá úvodní inicializace a načtení, ale pak je to celkem svižné. Navíc v NX klientovi lze velmi jednoduše nastavit která aplikace se má po přihlášení na server spustit v okně terminálu. Využívám například pro spouštění IE na linuxových terminálech.

[amnesiac]

Pripojuju se k dotazum ohledne optimalizace prenosu pro slabsi linky.

Je obecne znamo, ze X protokol je celkem nenazrany, ale kdyz jsem zkousel na stejne lince, pri stejnem rozliseni a na prakticky stejnem serverovem zeleze MS Terminal Services 2000 s rdesktopem (RD protokol 5), rozdil v odezve byl propastny

Vedel by nekdo jak se to da zlepsit ?

[mrzout]

http://freenx.berlios.de/

[Zdeněk Štěpánek]

Zdravim

Ze vseho nejvic jsem se tesil jak bude vyreseno vypinani klientu. Bohuzel tohle reseni jsem necekal. Kdyz uz, tak by se uzivatel mel odhlasit a az pak vypnout terminal.

Nevim jak v BSD, ale v Linuxu se X pri ctrl-alt-bksp sami restartuji aniz by se ukoncily. Tudiz by uvedene reseni nefungovalo. Existuje prepinac (myslimze -once), kterej uvedene chovani zpusobi.

Osobne jsem to resil tak, ze v rc.local jsem misto uvedeneho spoustel skript s textove-grafickym menu prihlasit nebo vypnout. Kdyz uzivatel dal prihlasit, spustilo se prihlaseni do X. Jakmile se daj odhlasit, X se ukoncily a znovu se spustil onen skript. Tam bud dal vypnout a nebo to nechal byt, prisel jiny uzivatel a dal prihlasit.

Ten skript bych jeste enkde doma mozna vyhrabal, ale je jednoduchy, a ted bych ho stejne napsal znova.

Zdenek

[Robert Krátký]

v Linuxu se X pri ctrl-alt-bksp sami restartuji aniz by se ukoncily

To ale není standardní chování X - většinou jsou tak pouze nastaveny display managery (a i u těch to jde vypnout - v KDM také, takže nevidím důvod, proč by to nefungovalo).

[Zdeněk Štěpánek]

Zdravim

Aha, uz vim, spletl jsem se. V display manageru lze nastavit, ze se X po padu sami spusti, ale to neni to o cem mluvim, to jsem ani nezapinal.

Mel jsme na mysli to, ze kdyz mam pusteny treba KDE pres XDMCP a tam dam odhlasit, tak pri normalnim chovani se X restartuji a znovu nabehne KDM. Pokud pouziju onen parametr (ted ho v manu nemuzu najit), tak X znovu nenabehnou, cimz se spusti dalsi prikaz ve skriptu, tedy menu ktere jsem popisoval nebo primo shutdown.

Zdenek

[yaplik]

no, ja preferuju na tenky klienty:
http://thinstation.sourceforge.net/
"Thinstation is a thin client Linux distribution that makes a PC a full-featured thin client supporting all major connectivity protocols: Citrix ICA, NoMachine NX, MS Windows terminal services (RDP), Tarantella, X, telnet, tn5250, VMS term and SSH."
"Thinstation can be booted from network (e.g. diskless) using Etherboot/PXE or from a local floppy/CD/HD/flash-disk."

[Vskutečnosti Saýc]

hezka hracka. jen se se mnou naprosto odmita bavit - korektne se pichne k DM (v tomhle pripade GDM) a pak prestane reagovat klavesnice. a nejakym logovanim se samozrejme nikdo neunavuje :(

Netusis cim by to mohlo byt?

[Marconi]

Thinstation pouivam k pripojeni k Windows 2003 Serveru via RDP a az na par problemku s ceskou klavesnici neni zadny problem. Vrele doporucuji.

Startovani v nasem pripade pres CD-ROM (Nejak jsem jeste nedonutil se k tomu abych donutil spolupracovat Windows DHCP a Tuxovy zavadec pres tftp-ethernet) na kterem je pripaleny i konfiguracni soubor.

[Petr Slansky]

Jak je na tom FreeBSD s podporou FreeNX? To je technologie vyrazne urychlujici komunikaci mezi X serverem a klientem. Pokud ji chcete snadno vyzkouset, pak si stahnete posledni Knoppix, tam spuste FreeNX server a pak si stahnete NX clienta pro Vas desktop, to muze byt Linux, Windows, Solaris anebo MacOS (zase nevidim zadneho klienta pro FreeBSD....). A overite si, ze s NX neni velky rozdil jestli pracujete lokalne anebo vzdalene; lze pouzit i pokud se pripojujete pres pomalejsi linky. NX pouziva SSH, takze komunikace je take zabezpecena. NX technologie vklada do X stacku dalsi vrstvu, ktera provadi vyrazne optimalizace a drasticky snizuje mnozstvi prenasencyh dat pres sit.

http://www.nomachine.com/download.php
http://freenx.berlios.de/

[Predator]

Neskúšal som, ale v portoch nxserver je ... to znamená, že to už určite funguje aj v BSD.

[Sinner]

v portech je i linux-nx-client, bezici pod linuxovou emulaci, takze se da rict ze existuje i klient ;)

[R]

Stroj s 256MB RAM mi vobec nepripada ako tenky klient. To je tak server na 20 webov...

[Predator]

Čo ja viem ... iba ako http server by možno šlo. Tá 256 MB RAM tam je iba preto, aby mašina neswapovala a OS bežal z RAMky, to je potom na výkone fest poznať. Nezabúdaj, že na tom beží kompletné X-ko, a zrovnávať systém s grafikou a systém bez X, ktorý iba obsluhuje HTTP žiadosti, je trochu podivné. Pre X je minimum tých 64 MB, tých 128 je výborné optimum a 256 je už absolútne super.

Ináč procák môže byť vcelku slabý, aj šumítko 200 MHz, a na výkon prevádzkovanej aplikácie to valný vplyv nemá. A je iné kúpiť starú šunku so slušným monitorom a pomerne veľkou RAMkou, ako plnú nadupanú zostavu za 5-násobnú cenu. Zvlášť na také veci, ako kancelárska práca, kde by sa ten procák aj tak iba 80 percent času iba tak váľal a animoval šetrič.

Aj server je dobré nasypať pokiaľ možno čo najväčšou kapacitou RAM. U mňa to má 2 GB, a ešte sa mi ho ani pri maximálnej záťaži nepodarilo dostať do swapu.

[Yeti]

FreeBSD mam narozdil od Linuxu rad. Cela serie clanku se mi opravdu libi, ale tento posledni je tak trosku ideove mimo. V zadnem pripade nemuzete srovnavat staricky system XWindow s modernimi komercnimi resenimi typu TS nebo CITRIX. Kdyz pominu vsechno ostatni (napr. mapovani tiskaren), tak nejvetsi problem je sirka prenosoveho pasma. CITRIXU staci bezny modem 28.8. TS je na tom v pripade RDP 5.2 take celkem slusne, obcne lze rici, ze k plnohodnotne praci staci 64kbit. Nemluvim o takovych vlastnostech jako publikovani aplikaci nebo obsahu, pristup k serveru z mobilnch zarizeni atd. Co se tyce te informace o licencni politice, je tam jedna zavadejici nepresnost - stanice NEMUSI byt Win. Pokud chce clovek usetrit, muze mit na stanicich nejaky unix a pouzivat rdesktop (v pripade TS), nebo CITRIXoveho klienta v pripade MF ne PS. Ale jako zajimavost je to hezke :)