Olvasgattam, mi kerül be a 2.6.28-as Linux kernelbe, és sajnos úgy néz ki, nem fognak bekerülni Arjan van de Ven boot felgyorsítására készített kódjai. Egy októberi kernel levlistás szál alapján nekem úgy tűnt, Linust meggyőzték hogy ez elég tuti és a gyakorlati tesztben nincsenek nagy bugok vele, de nem győzték meg eléggé. :-(

Aki nincs nagyon képben: Az Intel két mérnöke pár hónapja 5 másodperc alatt bootoló Linuxot készített. Ennek eléréséhez a kernelbe is tettek pár változtatást; főleg az USB hardverek felismerésének területén, ugyanis elég sokáig tart amíg ezek a hardverek magukra találnak. A gyorsítás módja az aszikronizált módszer, azaz nem várnak arra hogy a hardver összeszedje magát hanem közben a kernel már mással tud foglalkozni egy külön szálon. Ezt természetesen felajánlották a hivatalos kernel fejlesztőknek is, többen támogatták is a dolgot de végül - úgy tűnik - Linus Torvalds visszaverte az ötletet. Ez nem jelentette volna persze hogy mindenkinek 5 másodperc alatt bootolt volna a Linugz, de jelentősen fel lehetett volna gyorsítani a dolgokat; mondjuk 15-20 másodpercre a mostani 35-50-ről.

Nagy kár, mert erre a kernelre vártam a "gyorsbútoló picilinux" projekttel kapcsolatban, hogy ne kelljen egyáltalán foltozgatni a kernelt, csak konfigurálni. Ez most nem jött be, úgyhogy próbálok a másik kernel-fordításos ötletemen dolgozni a napokban.

Kernelbe vele! Vagy mégse?

Az az ötlet (a netről loptam én is, nyilván honnan máshonnan), hogy a kernel fordítással kapcsolatos legtöbb félelmet az okozza, hogy mit is kell belefordítani a kernelbe?

Sarkalatos kérdés. Lényegében mindegyik, széles körű általános felhasználásra szánt Linux terjesztés teljesen moduláris kernellel dolgozik, hiszen ahányféle hardverkombináció, annyiféle driver támogatás szükséges; mindet nem lehet a kernelbe fordítani, tehát kitrükközik azzal, hogy mindent modulba fordítanak, amit lehet. Viszont ehhez kell initrd ami sokat lassít a boot folyamaton. Ennek kihajításához a legegyszerűbb módszer az, hogy ki kell listázni az összes kernel modult, ami a boot során betöltődött - ezek fordítsuk bele a kernelbe és akkor ezentúl nem kell a betöltéssel szöszölni. Emellett természetesen nem kell lemondani a modularitás előnyeiről, ha nem akarunk túl sokat tűnödni, minden mást befordítunk modulba oszt csókolom.

A probléma ott kezdődik, hogy meg kell állapítanunk, hogy a kilistázott kernel moduljainkhoz a kernel konfigurálása közepette mit kell bekapcsolni a menüben, mert ez még távolról sem triviális. Szerencsére van nekünk egy nagyon hatékony szövegfeldolgozó nyelvünk, a Perl.

Találtam ugyanis egy írást és egy perl szkriptet a neten, ami pont ezt a kényelmetlen és nehézkes dolgot oldja meg, mint az lsmod-dal a betöltött modulok kilistázása, majd ehhez a megfelelő konfigurációs paraméterek megkeresése és beállítása. Frankó. Vakrepültem is egyet, mert kíváncsi voltam hogy mit tud ez a kis szkriptecske (belenézve természetesen látszik: kikeresgéli a kernelfa Makefile-jaiból a konfigurációs paramétereket és a hozzájuk tartozó modulneveket; majd az lsmod alapján megnézi milyen modulok vannak betöltve és megjegyzi, hogy az ezeknek megfelelő konfigurációs paramétereket mindenképpen kernelbe fordítandónak kell jelölni. Ezután végigmegy egy kernel konfigurációs fájlon, mindent lemásol de ha olyannal találkozik, ami YES (kernelbe fordítandó), akkor azt rakja bele. Egyszerű. Nekem volt egy olyan félelmem hogy mivel ez nem működik hierarchiában, ezért mondjuk be fogja rakni az intel driver támogatást de az eggyel felette lévő SATA meg nem lesz bekapcsolva. Ezt csináltam egy letöltött 2.6.27-es kernellel:

sudo bash
make oldconfig
cp .config .config_orig
perl buildin_used_mods.pl > .config
make Az első utasítás létrehoz egy alap kernel konfigot, amire szükség van a kis perl szkriptnek. Aztán ezt az alap konfigot a biztonság kedvéért elmentjük .config_orig néven, majd futtatjuk a szkriptet, végül fordítjuk a kernelt. Ahogy mondani szokás, ez eltart egy kis ideig. Méghozzá baromi sokáig! Na persze, alapértelmezetten modulba fordítandónak maradt lényegében minden, amit egyébként kikapcsoltam volna. Ráadásul a teljes lefordított kód + forrás 2,8Gbyte-ot evett (!!!). Nem győztem hümmögni.

Ja és persze a kernel nem működött. :-( No persze, mégiscsak hierarchiában kell gondolkodni. Sajnos perpillanat nem tudom leellenőrizni a feltevésem, mert le kell költöznöm arról a laptopról. :-(

Azt hiszem, a mai nap nem a nagy győzelmek napja. De nyomjuk tovább...

Mindig azt szoktam mondogatni kezdőbb rendszergazdáknak, hogy ne adjanak, vagyis csak végső megoldásként adjanak SSH hozzáférést a rendszereikhez, és csakis olyan embernek akikben egyrészt 100%-ban megbíznak, másrészt az SSH hozzáférés egész időtartama alatt a kiskutyájukat kilógatják az Empire States Building legfelső emeletéről, és az első gyanús mozdulatra száttárják a kezüket. Most leírom azt is, hogy miért van ez. Később egyszerűbb lesz minden egyes magyarázat helyett egy linket dobni ide. :-)

Az SSH nem gonosz, de két okból igen veszélyes:

1. Shell szintű hozzáférés, ami mindenképpen magasabb minőség egy alkalmazás-szintű (pl. webes adminisztrációs felület) hozzáféréshez. Lehetnek hibák, amikről még nem tudunk és kihasználhatók privilégium-emelésre vagy (akár nem szándékos) rombolásra.
2. Az SSH egy irgalmatlanul rugalmas protokoll, amely képes más protokollokat a testébe ágyazni (tunneling). Ezt úgy kell érteni, hogy mondjuk a tűzfalra adott egyetlen SSH hozzáféréssel kiadtuk az összes belső gépünket mondjuk egy kiadós szkennelésre. Ha mi építünk ki egy ilyen tunnelt, mert mondjuk el kell érni egy belső Intranet szervert HTTP-n de ez (nyilván) nincs engedélyezve a tűzfalon, azaz nincs port forward befelé, akkor ez a featúra hasznos, ha más csinálja ugyanezt a tudtunk nélkül, az inkább kínos.

Szóval első ötletként jónak tűnik adni egy SSH hozzáférést, hiszen biztonságos. Naja, de ebből adódóan nehezen is karbantartható, figyelhető, hiszen a titkosított forgalmat nekünk is nehéz kontrollálni. Néhány lehetőség:

Fájl transzfer

Talán a legtriviálisabb, hogy az SSH használható fájlok átvitelére is. Ilyen módon az SSH hozzáféréssel rendelkező ember jogosultsága erejéig tud fájlokat fel-le másolgatni a szerverünkre.

X11 forwarding

Ha a szerveren valamilyen rendkívüli körülmény következtében van X, akkor jó tudni, hogy az X11 DISPLAY-t át lehet irányítani SSH-n keresztül. Ha ez működik (SSH szerver és kliens beállítás is kell hozzá), akkor a távoli terminálban elindított program a kliens gépre küldi át a képét, azaz a grafikus ablak hirtelen megjelenik a kliensen, pedig valójában a szerveren dolgozunk. Jó trükk, jó lehetőség hackokra.

Traffic Forwarding

Ugyan nem tudom, hogy az előző folyományaként, továbbfejlesztéseként működik, de az SSH képes arra, hogy egy tetszőleges forgalmat befedjen a titkosított kapcsolatba. Úgy kell ezt elképzelni, hogy tegyük fel az alap 22-es portot használva bejelentkezünk a szerverre (maradjunk előző példánknál, és legyen ez egy tűzfal); egyúttal elindítunk a kliensen egy kis háttérben futó szolgáltatást, amely általunk meghatározott porton figyel a localhost (Lo) interfészen. Ha csatlakozunk rá, akkor a forgalmat elkapja, belevágja a kiépült SSH csatornába, a túloldalon kiesik, és ott továbbküldődik a szintén általunk meghatározott gép meghatározott portjára. Magyarul itt három gép dolgozik, a kliens, a tűzfal (ami csak egy továbbító, forwarder), és a távoli szerver, amire ténylegesen csatlakozunk ("Hé, SSH, titkosítsd a lokális gépem X portjára érkező forgalmat, hogy eljusson Y gép Z portjára, és ehhez használd a Q ssh-szervert!").

Vegyünk egy példát! Mondjuk sima POP3 elérés működik bent egy cégnél, hogy a belső szerverről le tudják tölteni az emberek a leveleiket. Tudjuk, hogy a POP3 nem igazán biztonságos, hiszen lehallgathhatók a mailek, de kis cégen belül még elmegy. Főnökünk kiadja a parancsot, hogy mostantól 0 - 24 órában kell figyelnünk a levelesládánkat. Nyilván nagyon rossz ötlet a POP3-at engedélyezni kívülről, még akkor is, ha legalább minimális biztonsági tudatosságról téve bizonyságot, mondjuk a 9999-es portot forwardoljuk be a tűzfalon a belső levelezőszerver 110-es portjára. Ez ugye csak addig segít, amíg meg nem találják a nyitott portot, aztán jöhet mindenféle brute force próbálkozás, relayként való trükközés, a levelezőszerver gyengeségeinek kihasználása stb.

Legtutibb tehát az lenne, ha csak akkor épülne ki ez a kapcsolat ha ténylegesen használjuk is, és természetesen akkor is legyen titkosított. Ekkor azt csináljuk, hogy (feltéve hogy a 22-es port engedélyezve van a tűzfalon; persze tudom hogy ez is ad teret brute force próbálkozásnak de például ezek visszafoghatók egy iptables-szel ha beállítjuk hogy egy hostról egy percen belül csak 2 kapcsolat jöhet a többit eldobálja. Meg persze ott a jó öreg knocking technológia. Ez két nagyon más téma, nem mennék bele); szóval azt csináljuk, hogy benyomulunk SSH-val, majd a lokális gép 110-es portját beirányítjuk a kihúzott titkosított csatornába, az a másik oldalon kiesve pedig megy a szerverünk 110-es portjára és minden működik szépen.

Az egyetlen fura dolog nyilván az, hogy a kiépített forwarding esetén úgy tűnik, mintha a kliens, azaz a saját gépünk lenne a szerver, mert a levelezőprogramban is localhost:110-et állítunk be a levél letöltéshez, de ez csak technikai kérdés. Az előbb leírtak megvalósítása:

ssh -L110:192.168.1.10:110 tuzfal.cegem.hu


Ez elég egyszerű, nem? A 192.168.1.10-et természetesen a belső szerver (belső) címére kell lecserélni, a két 110-es érték közül az első az, hogy a lokális gépen hányas porton figyeljen, a másik értelemszerűen az elérni kívánt gép portja. Ha több levelezőszervert akarunk elérni, akkor lehet több csatornát is kiépíteni, de egy csatorna lefoglal a lokál gépen egy portot, tehát a második csatornát már pl. a 111-es portra kell tennünk és a levelezőprogramot is így kell beállítani. Természetesen a parancs kiadása után a szokott módon be kell jelentkeznünk. Azt hiszem, túlragoztam. Még annyit, hogy a kapcsolatot állandóvá lehet tenni a konfig fájlunkban (normál esetben ~/.ssh/config), és akkor egyszerűen csak ssh tuzfal.cegem.hu, a csatornák pedig egyből kiépülnek. Ezt így lehet:


LocalForward 110 192.168.1.10:110
LocalForward 111 192.168.1.11:110

A konfigba én még nem írtam ilyet, nem tudom, hogy ez most ténylegesen működik-e...

Figyelem! Fontos dolgok, amiket érdemes tudni: Ha a kliens gépünket többen használják, akkor a megnyitott 110-es portot mindenki fogja látni, tudja használni! Ez persze jó dolog is lehet, de tudjunk róla. A másik, hogy az 1024 alatti portok megnyitásához root jog kell, ezt ne felejtsük! Ha nem akarjuk root joggal csinálni, akkor a -L110 helyett -L9110-et is adhatunk.

És persze a legfontosabb, amiért tépem az ujjaimat: Bármelyik SSH-joggal rendelkező felhasználó ki tudja forwardolni ezzel a módszerrel egy belső gépünk belső portját egy másik gépen keresztül akár az Internetre is!!! (Készít kívülről egy tunnelt, majd a lokális portot a -g kapcsoló segítségével elérhetővé teszi más távoli hozzáférőknek. Tehát tud készíteni egy gonoszceg.com-ot, ahol megcsinálja az előbb említett SSH sort, kiegészítve a -g paraméterrel; ekkor a gonoszceg.com 110-es portjára csatlakozók bekerülnek egy titkosított csatornába, ami átviszi őket a tuzfal.cegem.com-on keresztül szépen a belső hálózati mailszerver 110-es portjára. A vicces az, hogy ezek után a kliensek és a gonoszceg.com közötti forgalom megint nem titkosított! Hiszen csak a gonoszceg.com és a tuzfal.cegem.com közötti kapcsolat van letitkosítva.

Tehát ha nem akarunk ilyen trükköket, akkor a /etc/ssh/sshd_config fájlbe leszünk szíves beírni:

AllowTcpForwarding no

Távoli parancsfuttatás

Csak egy-két rövid példa a távoli parancsfuttatásra. Azt gondolnánk, hogy az SSH-val bejelentkező felhasználó, még ha ilyen sok joga van is, egy interaktív shellben gépelve nem sokra mehet. Ez egyrészt azért is tévedés, mert akár egy kijelölt szövegfájlt is belemásolhat a termináljába, másrészt szkriptet is tud készíteni, amely kis ügyességgel automatikusan igen sokat megtehet. Példák:

bagoj@tarantula:~$ ssh user@host w
bagoj@tarantula:~$ cat myfile | ssh user@host lpr
bagoj@tarantula:~$ tar -cf - source_dir | ssh user@desktop 'cat > dest.tar'
bagoj@tarantula:~$ for i in "server1 server2 server3"; do echo `ssh $i "uptime"`; done


•  Az első bejelentkezik a távoli host nevű gépre, lefuttat egy "who" parancsot és rögtön kilép.
• A második arra mutat példát, hogy a pipe-ok is működnek; itt a cat-tal kiírjuk egy fájlunk tartalmát és beleirányítjuk a távoli hoston a nyomtatósorba, ahol szépen kinyomtatódik.
• Harmadikként ismét egy pipe-os példa; a tar-ral összecsomagolt fájl nem saját gépünkön, hanem egy távoli könyvtárban fog landolni.
• A negyediknél már szkriptezünk; bejelentkezünk sorban a server1, server2, server3 ... gépekre és lefuttatjuk az uptime parancsot, ami infót ad a gépek pillanatnyi terheltségéről és arról hogy mikot bootoltak utoljára. Az eredmény egy komolyabb perl szkripttel értelemszerűen fel is dolgozható.

Gondolhatnánk, hogy nade a bejelentkezéshez jelszó kell, tehát utóbbi példánkban 3-szor kellene beírni a jelszót. "Természetesen" ez is simán kitrükközhető - lássuk az azonosítás részt!

Azonosítás

Elég sokféle azonosítás lehetséges az SSH-ban; számunkra most a jelszavas és a kulcsos bejelentkezés az érdekes. Alapból ugyebár a jelszópromptos azonosítás dukál, ezen sokan nem is lépnek túl. De miért ne legyünk lusták, ha a kulcsos titkosítás még biztonságosabb (kell a bejelentkezéshez jelszó ÉS egy privát kulcs) és megtehetjük, hogy nem kell jelszót gépelni (azaz mégsem kell jelszó CSAK a privát kulcs)?

Azt nem várhatjátok hogy most a nyilvános kulcsú titkosításra kitérjek; szintén nagy téma, persze ha igazán szívhez szólóan könyörögtök, akkor szívesen firkálok róla. :-))) Röviden: A privát kulcs a saját gépünkön van, a publikus párja a szerveren, ahová bejelentkezünk. Egymás nélkül nem érnek fabatkát sem, ennek matematikai alapján már 30 éve próbálnak hibát találni, egyelőre hiába. A módszer lépései:

1. Egy ilyen kulcspárt le tudunk generálni az Openssl segítségével, a privát kulcsunkhoz való hozzáférést pedig jelszóhoz köthetjük. Ha itt megadunk jelszót, akkor ezt kell megadnunk majd a kapcsolódáskor. Ha nem adunk meg semmit, akkor pedig jelszó nélkül, mégis biztonságos azonosítással tudunk belépni (jelszó nem utazik a hálózaton, egyértelműen azonosítva van a kliens gépünk stb). Természetesen ha a privát kulcsot lenyúlják, az ugyanakkora szívás, mintha a jelszót nyúlták volna le... Csináljuk hát meg (jelszó helyett csak entert ütöttem):
   bagoj@tarantula:~ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/bagoj/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/bagoj/.ssh/id_rsa.
Your public key has been saved in /home/bagoj/.ssh/id_rsa.pub.
2. A publikus kulcsot ezek után szét kell másolni mindazon szerverekre, ahová ezzel a módszerrel jelentkeznénk be. A publikus kulcs szolgál az elkódolásra, a privát a dekódolásra, ez utóbbira kell nagyon ügyelnünk. Az algoritmus biztosítja, hogy csak a mi privát kulcsunkkal lehet kikódolni a mi publikus kulcsunkkal titkosított üzenetet. A publikus kulcs helye a távoli szerveren a saját könyvtárunkban a ~/.ssh/authorized_keys fájl, ha több kulcsunk van akkor ezeket egymás után másoljuk. Hogy melyik kulcs a publikus, mindenkinek feladom házi feladatként... :-)
   bagoj@tarantula:~$ scp /home/bagoj/.ssh/id_rsa.pub tuzfal.cegem.com:.ssh/authorized_keys

bagoj@tuzfal.cegem.com's password:
id_rsa.pub                                    100%  395     0.4KB/s   00:00
3. Ezután ha egy ssh tuzfal.cegem.com-ot kiadunk, jelszó nélkül ott vagyunk. Jó, mi? Ugyanezt bárki megteheti, akinek SSH hozzáférést adtunk. 

Remélem, nem lomboztam le senkit ezzel, hiszen ez csak a biztonságot szolgálja; de természetesen használható arra is, hogy jelszó megadása nélkül automatikusan parancsokat futtassunk. Természetesen mindenkit arra bátorítok, hogy védje privát kulcsát jelszóval, amely egyébként 3DES (szimmetrikus) kódolással véd.

Hab a tortán - Azonosítási Ügynök (Authentication Agent)

Ez a kis fejezet kivételesen nem arról szól, hogy mit tehetnek meg mások a szerverünkkel, hanem hogy mit tehetünk mi saját kényelmünk érdekében. Kapcsolódva az előzőkhöz, ha jelszóval védjük privát kulcsunkat, akkor ismét csak meg kell adni minden bejelentkezéskor a jelszót. De használhatjuk az ssh-agent nevű programocskát is, amely az első alkalommal elteszi a memóriába a begépelt jelszavunkat, így nem kell többször megadnunk. Csak a tisztánlátás kedvéért: nem a távoli géphez szükséges jelszavunkat tárolja el, mert azt nem is használjuk, hiszen kulcs van helyette; hanem a privát kulcsunk kinyitásához (bármekkora képzavar is ez) szükséges jelszót. Ha olyan a disztibúciónk, akkor az X11 elindításakor elindul az ssh-agent is, mint például Ubuntu alatt, így azt külön nem kell futtatnunk. Elég hát kiadni az

ssh-add

parancsot, és a saját kulcsunk rákerül erre a "kulcskarikára". Ezt bármikor lekérdezhetjük az ssh-add -L parancs segítségével.

A legnagyobb vicc persze nem ez, hanem hogy ha bejelentkezünk egy szerverre, és onnan szintén ugyanazzal a kulccsal mennénk tovább, akkor a józan paraszti észnek adódik, hogy ott is futnia kellene ennek az ssh-agentnek. Nos, a helyzet ennél egyszerűbb: Az ssh tudja ezt a tárolt jelszót is továbbítani a titkosított csatornán. Ilyen módon a távoli gépről egy újabb gépre belépés esetén sem fog még egyszer jelszót kérni, tényleg egyszer kell csak megadnunk a kulcs jelszót, az ssh-add parancs futtatásakor. Ha nem mi vagyunk a távoli gép adminisztrátorai, akkor én egyáltalán nem javaslom ennek a használatát! Hála az égnek, ez nem automatikus! Ahhoz, hogy ez működjön, a -A paramétert kell használni az ssh parancs közben, vagy a ~/.ssh/config fájlunkba a kliensen be kell írni a

ForwardAgent     yes

paramétert.

Biztonságos SSH-szerver beállítások

Azt már tudjuk, hogy mit lehet megtenni egy egyszerű SSH hozzáféréssel. Tegyük fel, hogy mi szeretnénk ez ellen védekezni! Mit kell a szerverünkön beállítani, hogy senki ne csúnyálkodhasson? Szerkesszük a /etc/ssh/sshd_config fájlt:

# Tudom nem sokat ved, de megis, ne a standard porton futtassuk
Port 2222
# Csak 2-es protokollt használjunk, ha megtehetjuk (nincs nagyon osdi UNIXunk)
Protocol 2
# Nem kene engedni, hogy a root tavolrol bejelentkezzen. Jelentkezzunk be
# sajat nevunk alatt, aztan su vagy sudo
PermitRootLogin no
# X11 forwarding nem kell, foleg ha nincs is X11. Desktop
# gepen szukseg lehet ra!!!!
X11Forwarding no
# Ha no-ra allitjuk, nem fog menni a kulcsos bejelentkezes. Szerintem megis
# hasznosabb, mint veszelyes, ezert megengedem
PubkeyAuthentication yes
# Itt a traffic forwardingban is leírt rész. A manual szerint
# ez sem er tul sokat, hiszen shell hozzaferessel barki
# telepitheti sajat forwarderet, de azert az mar nem olyan
# trivialis
AllowTcpForwarding noMit tegyünk, ha mi magunk akarunk mondjuk X11 forwardot, másoknak viszont nem akarjuk megengedni? Háttt ittt a nagyon nagyszerű Match lehetőség, amely képes felhasználó, csoport, host vagy cím alapján eltéríteni a globális beállításokat. Arra figyeljünk, hogy a Match után következő sorok az adott szűrt csapatra lesznek érvényesek mindaddig, amíg egy újabb Match vagy a fájl vége nem jön. Tehát globális szekció előre, Match-ek a végére!

Tegyük fel, hogy szegény jó Bagojtól megvonjuk a jogot az SCP-re, és csak egyetlen belső szerver traffic forwardját hagyjuk meg neki. Ekkor a konfig fájl végére ezt illesszük be:

Match User bagoj
PermitOpen bagojgepe:22
ForceCommand /bin/bashEbben az esetben Bagoj Uraság pofára esik, ha SCP-zni akar, mert azt nem lehet bash-sel, tehát ott fog várakozni a sor és a másolás nem fog végbemenni. A forward pedig csak Bagoj saját gépére lehetséges (a fenébe, egy újabb SSH jogot kapott, és ez a fickó dörzsölt, jó lesz vele vigyázni... :-))

Ahogy mondani szokás, én kérek elnézést, hogy a PCE17OS new-h developer verziójának tesztjét csak most sikerül leírnom, pedig a teszt szeptemberre datálható. Azt is el tudom képzelni, hogy azóta rengeteg javítás, illetve újdonság bekerült a rendszerbe, de el vagyok most maradva kicsit, majd bepótolom. Ez tehát az októberi teszt lett volna, és még a novemberivel és a decemberivel adósotok vagyok. :-)

Tehát bevezetőként annyi, hogy én a szeptemberi állapotot írom le. Az elsőre kicsit furcsa nevű projektet egy honfitársunk hozta létre, egy izgalmas és új terjesztés elkészítését célozva. Hogyan szól a recept ezúttal?

1. Vegyünk egy stabil, jól támogatott, RPM-alapú rendszert
2. Szerezzünk egy olyan toolt, amivel a rendszert testre lehet szabni
3. Végezzük el a piszkos munkát, összeválogatva a legjavát. :-)

Az alaprendszer a PCLinuxOS, az elkészült rendszer, amely a PCLinuxOS tárolóiból frissül, az E17OS. Ha valaki még mindig nem érzi a párhuzamot, akkor: Ubuntu -> *buntu. Szóval valami ahhoz hasonló.

Az Enlightenment olyan 1999-2000 környékén (szerintem) magasan a legjobb, legszofisztikáltabb, legdesignosabb, legfeltűnőbb és legparasztvakítóbb ablakkezelő volt. Igen, ablakkezelő, mert akkoriban a mostanra kissé elhízott népszerű Desktop Environmentek akkor még csak gyerekcipőben léteztek, és ma is sokat köszönhetnek az E16 (Enlightenment 0.16-os verzió) fejlesztőinek. Miben volt más az E16? A desktop kezelése nem Windowsos alapokról származott: a menü az asztalra kattintva bújt elő, sehol egy tálca vagy start gomb (pláne értesítési terület (system tray)); illetve egészen jól el lehetett lenni billentyűzettel is. Akkoriban senkinek nem okozott nehézséget a konfigurációs fájlokban való turkászás... Miután Rasterman és társai ültek kicsit a trónon, elkezdtek fejleszteni egy következő verziót, amelyet már ők is - érezve az idők szelét - Desktop Environmentnek terveztek. Valószínűleg időhiány miatt olyan lassan haladtak vele hogy még mindig messze nincsenek kész, de van már belőle DR, azaz fejlesztői verzió. Nem stabil, nem végleges, de működő.

A recept így folytatódik: végy valami egzotikus felületet, válogass össze kicsi de jól működő, illetve desktopon elengedhetetlenül fontos alkalmzaást és kész. Így esett (gondolom) az Enlightenmentre a választás. Az én véleményem az, hogy ami jó volt 6-8 éve, az nem biztos, hogy még mindig jó; hiszen az Enlightenment alatt sokan keresik a tálcát és főleg a system trayt (hiszen jópár alkalmazás már arra "minimalizálódik", például a Skype, ha becsukjuk akkor oda csücsül - E17 alatt ez úgy jelentkezik, hogy hirtelen "eltűnik"). De meg tudom érteni azokat, akik most is lelkesednek érte, hiszen elég csak az E16-ra gondolnom, hogy milyen penge volt az Alienes témával... :-)

Oké, tehát UNIX-gyökerű felület, lényegében a szokásos "könnyed" alkalmazások, szoros integrációnak nyoma sincs. Vágjunk bele!

Kinézet, sebesség

Bejelentkezés után (livecd-n: root/root) szinte azonnal megjelent a háttérkép, meg is lepődtem. Aztán kiderült, hogy az valójában egy egész ablakos splash screen... hehe, egy pont a készítőknek! Ezt kis töprengés után visszavontam, mert a splash screent meglepően sokáig kell bámulni,jó nehezen jön be a tényleges desktop. Alul-felül a Bar (a MacOSX iBar-jához hasonló alkalmazás, az E része) kelleti magát, amiről gyorsan tudunk bármit elindítani. Ezen felül a már említett desktopra jobbgombbal kattintós módszerrel lehet elérni a menüt, amely beállítások megtételét és természetesen további programindítást tesz lehetővé (bal gomb a futó alkalmazások ablakát dobja fel). Jó ez a koncepció egy olyan irgalmatlanul nagy képernyőn, ahol mindig elérhető a desktop egy csücske, amire kattintani lehet, de én a csontra kinyitott ablakaimmal csak senyvedtem...

Az asztalra egymástól véletlenszerű távolságra kisalkalmazások vannak kiszórva; nem igazán láttam át a koncepciót, kicsit az ovis homokozóra emlékeztet, van rajta minden még kép slideshow is - sajnos csinos lányokról nincsenek képek, de legalább eszi az erőforrást. :-) Az óra és az elem töltöttség elég hasznos, a többi meg jó ha van, úgyis letakarják az ablakok, a slideshow-t azonnal eltávolítottam ("remove gadget").

Az általános sebesség teljesen rendben van, sajnos elég gyenge gépen dolgoztam, mindössze 256Mb RAM volt benne és egy 2,4-es Celeron processzor szóval sokat nem vártam de egy normális gépen ez biztosan nagyon hasít.

Alkalmazások, design

Az alkalmazások kiválogatásával semmi problémám nincs, ugyan a TkDVD-t egy kicsit túlzottan ódivatúnak érzem. Inkább magával az egész rendszernek a designjával vannak részenként igen apró problémáim, amik bosszantó egyveleggé válnak rövid használat után:

• Az egérkurzor igen furcsa alakú, elsőre azt se tudni hol a hegye. Persze a különlegesség is jó, de alapértelmezésben lehetne egy hasznosabb
• Az ablakok kerete (ami szintén Mac OSX-imitáció) világos, az ablakok tartalma sötét, az ablakokban a szövegek háttere meg fehér. Ez csak annak nem süti ki a szemét, aki már legalább öt éve stroboszkóppal edzi a pupilláit
• A Bar ikonjai az ablakok alá kerülnek, tehát nem lehet őket használni. Van egy beállítás, hogy kerüljenek az ablakok fölé, ezt örömmel be is kapcsoltam. Ezek után furcsán "elkenődtek" az ikonok, és onnantól nem lehetett rendesen látni őket, készítettem róla képernyőmentést de egy video még jobb lenne
• A nem aktív ablakok úgy jelzik ezt a státuszukat, hogy félig átlátszatlanná válnak; ami szintén cool effekt elsőre, de sok megnyitott ablaknál hülye szellemképet ad és alig lehet látni, melyik is az aktív. Sokat segítene csak a keret válna átlátszóvá, vagy csak színt váltana mint egyéb ablakkezelőkön. Nyilván ez is beállítás kérdése, én az alapbeállításról beszélek (a piros keret az ablak tetején nem az én firkálmányom, hanem ez a notification, azaz ezzel jelzi az ablak hogy történik benne valami - szerintem hányás, ahogy kinéz).

Mégiscsak eszembe jutott az alkalmazások összeválogatásáról: Tudom, hogy lehetetlen feladat csak egyetlen widget setet használó programgyűjtemény összeállítása (csak QT, csak GTK...) de itt kicsit sok a kavar. A mögöttes szándék világos: mindenből a legjobbat. Ezért került be az smplayer (QT), gimp (GTK), TkDVD (Tk), Openoffice (GTK), Skype (QT), ...

Amit ki kell emeljek, az mindenképpen a beállítási lehetőségek széles tárháza; ezt okosan sikerült átemelni a PCLinuxOS-ből, a felhasználói élményen sokat dob, ha grafikusan lehet prüntyögtetni (még ha az sokszor nem is a gyorsabb megoldás). Szintén óriási a magyar nyelvű súgó, amiért egy óriási piros pont jár!

Összefoglalás

Ahogyan írtam is, ez egy igen ígéretes kezdet. A szoftver még béta, de láthatóan van benne potenciál és rugalmasság. Amit helyre kell tenni mindenképpen, az egy szép, szemkímélő és egységes design, illetve reménykedni hogy a jelenlegi E17-ből hamarosan stabil változat is készül majd. Ajánlom olyanoknak, akik már egy ideje linuxoznak, nem kényelmesedtek bele a Gnome/KDE világába és van igényük egy viszonylag gyors de kőegyszerű desktopra.

A blog.hu-n most a legújabb hogy lehet hirdetési modellt váltani. Egyelőre maradtam a hirdetésmentes, csizmáSKAndúr változatnál; csak gondoltam szólok, és persze fenntartom a változtatás jogát, hiszen közismert hogy minden blogger eladná az édesanyját is pár új kommentért... :-) Ennyit a bevezetőről.

Hogy kapcsolódjunk valahogy a csizmához, ma megint a bootról írok. Ennek oka az, hogy kitört a boot-láz. Kezdődött azzal, hogy 5 másodperc alatt bootoltak be egy linuxot. Erre válaszként először egy sima Debian terjesztést optimalizáltak le 14 másodpercre, majd keringett egy videó, hogy a valamelyik alaplapgyártó mérnökei 4 másodperc alatt bootoltak be egy Windows Vistát. Utóbbiról kiderült, hogy az egész "csalás", hiszen azt csinálják, hogy a leállítás után be is bootolják a Windowst, majd suspend-be teszik. Így természetesen igen gyorsan elindul, viszont két perc kell a leállításhoz. :-) Szóval ezt inkább nevezném finoman átszervezésnek, mint valódi megoldásnak.

Szóvval úgy tűnik, hogy a Linux és az opensource, amelynek a desktop törekvéseit oly sokan lenézik és azt mondják, csak másolja a zárt kódú oprendszereket, a forgó kocka után (amit szintén lenéznek hogy parasztvakítás; nyilván ha a Microsoft jött volna elő vele akkor mára desktop standard lenne. De az is tény hogy a MS képes a forgó kocka mögé valódi értelmes funkciókat is rakni, mert rengeteg okos ember ötletel náluk) most jött a boot-idő lefaragás őrület. Sokan ezt is hülyeségnek tartják, merthogy létezik a suspend-to-ram és suspend-to-disk, de el kell ismerni, a számítógép is olyan mint az élet: néha kell egy reset. ;-) És akkor kell egy boot is.

A lényeg, hogy úgy érzem, egyszerűen nem hagyhatom szó nélkül a dolgot, ezért elhatároztam, hogy a múltkoriban emlegetett remastersys segítségével nekilátok egy saját változat gyártásának, amit le lehet tölteni majd. A kernellel foglalkoztam korábban; most jönnek - korábbi ígéretemhez híven - a boot szkriptek. Nem létezik hogy ne sikerülne ha másoknak bejött. :-)

Terveim szerint az Ubuntu szabványos tárolóit fogom használni, úgyhogy nincs szükség külön infrastruktúra fenntartására vagy túlzott erőfeszítésekre a részemről. Valószínűleg nem a gépek 100%-át, hanem csak 90%-át fogja támogatni, na és?

Szóval a nagy elhatározás megvan, talán most egy kicsit nyugi is lesz és tudok szüttyögni. Ha van valami, jelentkezem és megírom. Addig ha van valakinek ötlete, hogy az Ubuntu Minimalban lévő alkalmazásokhoz képest még mit rakjak hozzá, dobjon egy kommentet. Köszi.

Olvasom a Full Circle magazin legújabb (18-as) számában, hogy az Ubuntu marketing menedzsere megerősítette a korábban az MSI által közölt tényeket, miszerint az emberek igen nagy százalékban viszik vissza az Ubuntuval előtelepített netbookokat (gondolom, mivel a gyártó az MSI, itt a Wind-ről lehet szó). Ez a hír már korábban is vezércikk volt sok IT oldalon, ahol beállítottságtól függően "na ugye a Linux szar", vagy "hülyék ezek, nem tudják mi a jó" típusú hozzászólások születtek. Ezeken a véleményeken túl nézzük meg, mi lehetett a rengeteg visszavett Netbook oka?

I. felvonás

"Te figyi már, Jane! Itt van egy pont olyan pici laptop mint amit akartál oszt millen jónéz ki, oszt nem is drága?"

"Mégis mennyi, John? Nehogy nekem valami kacatot megvegyél drágán!"

"Nézzed, 1G memória meg 80Gb winchester és csak $399"

"Asztaphassza, nyomassuk a megvételt ízibe!"

II. felvonás

"Te John, Te mégiscsak valami kacatot vettél. Téged átvertek."

"Mémá, asszony?"

"Nézzede'. Milyen furcsa ronda barna valami ez itt. Meg má egy fél órája próbálom felrakni a lolcat-es képernyővédőt meg a Word-öt de ez nem csinál semmit, ha rákattintok az ikonra"

"Hú de furcsa ez. Te ez nem Windóz asszem."

"Most akkor nem értem, mi az, hogy nem Windóz?"

"Hát, írtak valami Linuxot a számlán, ecce' azt hallottam az valami kiegészítő Windózho'. Gondoltam jó lesz azzal is."

"Hát ezt a szart most visszaviszed a boltba és megjavíttatod, hogy menjen a képernyővédőm".

Két szóban, összefoglalva: marketing átbaszás.

Gerry Carr (a Canonical marketing menedzsere) szerint az emberek a neten megrendelték a netbookoat, és otthon szembesültek vele hogy ez nem Windows. Innentől nem érdekelte őket hogy mennyire használható vagy mennyire nem, ők Windowst akartak, azt hitték azért fizettek és hajlandóak pluszban fizetni a Windowsért. Nem hajlandóak újat megtanulni, nem azért vettek számítógépet hogy kísérletezzenek, hanem hogy használják. Azt se tudják, hogy mi az, hogy Windows, Linux, nekik alkalmazásaik vannak és kész.

És itt felmerül a kérdés, hogy a Linux egyáltalán valaha lesz-e legalább alternatívaként megtűrt operációs rendszer a Windows mellett? Hatalmas reményekkel indult a netbook-hullám, mindenki a Linux áttöréséről beszélt, de ez totális kudarcba fulladt. Szerintem két megoldás lehet, attól függően, hogy kiknek kell eladni:

1. El kell hitetni, hogy a Linux egy nagyon cool dolog, ami csak keveseknek adatik meg. Ehhez szerintem azt az utat kell járni, amit a MacOSX: Divatcikké tenni. Drágán.

2. Ha egy Linux terjesztés hajszálpontosan lemásolja a Windowst, és futnak a Windowsos alkalmazások, akkor van esély egy olyan cserére, amit a felhasználó észre se vesz. De akkor meg mi a fenét ér az egész???