28. fejezet: A Linux finomságai
Befejezve: 2003.
TFeri.hu logo Forrás: root.hu

28.1.) Az X-felület konfigurálása

2004-es állapot szerinti leírás!!!
Sajnos a legnagyobb jóindulat mellett is előfordul(hat), hogy a Linux viszonylag hosszú telepítési folyamata lezárása után nem hajlandó felismerni és futtatni az X-felületet. Mi a teendő ilyenkor?
Érdemes a videókártya, az esetleges 3Dfx-kártya, valamint a monitor technikai leírását elővenni (esetleg letölteni az internetről), majd alaposan áttanulmányozni. A pontos típusok és beállításaik ismeretében érdemes keresgélni az X-felület beállító-programjait és fájljait.
Az információs fájl (általában): /etc/XF86Config
(másképp:) /etc/X11
A programok a következőek lehetnek: XFree86, XF86Setup, esetleg Xconfigurator.
A helyes programnév keresésekor érdemes a TAB billentyű adta kiegészítési lehetőséget alaposan kihasználni, hiszen az első betű biztosan "X" lesz...

28.1.a.) A startx és helyettesei

2004-es állapot szerinti leírás!!!

28.2.) A Squid beállításai

2004-es állapot szerinti leírás!!!
Forrás: squid-cache.org Eredeti verzió: http://www.root.hu/?c=180
Weblapja: http://www.squid-cache.org/
Magyarosítás: http://www1.hu.squid-cache.org/
FTP-tükör: ftp://ftp.fsz.bme.hu/pub/www/Squid
A Squid angol szó jelentése: tintahal, amely nagyon találó név egy proxy illetve gyorsítótár programra nézve. Egyszerűen egy kis vizuális fantázia kell csak, amint a Squid programot munka közben "elképzeljük".
A proxy program kiválóan használható kis hálózatok esetén, viszont a lekérdezések számát növelve csökken a kiszolgálás minősége, mivel a wwwoffle nincs felkészítve nagyszámú kérés közel egyidejű kiszolgálására. A Squid programot állandó kapcsolatra tervezték, bár megvan benne az offline működés lehetősége, mégis az online összeköttetés jelenti a hazai pályát. A konfigurációs állományát átfutva rögtön látszik, hogy nem lesz könnyű hamar elvégezni a megfelelő beállításokat, szerencsére az alapértelmezett állomány tulajdonképpen működőképes, néhány apróbb beállítást kell elvégezni, hogy számunkra is megfelelő legyen. A proxy egy jól nevelt rendszerprogramhoz illően általában démonként fut, megfelelő parancssori paraméterekkel viszont előtérben való futásra is kényszeríthető. Induláskor feldolgozza a /etc/squid.conf állományt, hogy az általunk szükségesnek gondolt működési körülményeknek eleget tegyen, ugyanakkor különféle paraméterekkel ettől eltérő működésre is bírhatjuk:
-a port : Megadhatjuk egy HTTP port számát, amelyet használni fogunk, alapesetben ez 3128.
-d szint : A hibakövetés szintjét állíthatjuk be, amelyet az stderr kimenetre fog írni a program.
-f file : A /etc/squid.conf fájltól eltérő konfigurációs állomány használata.
-h : Egy összefoglaló oldal a parancssori paraméterekről.
-k reconfigure|rotate|shutdown|interrupt|kill|debug|check|parse : Különféle parancsokat adhatunk a futó démonnak.
-s : A naplózáshoz a syslog démont használja.
-u port: Megadhatunk egy port számot az ICP protokollhoz, amely alapesetben 3130. Ha nullát adunk meg, akkor letilthatjuk az ICP forgalmazást.
-v : A Squid program verzióját írja ki.
-z: Létrehozza a megfelelő könyvtárban a gyorsítótár funkcióhoz használt könyvtárszerkezetet. Ha létezik, akkor törli azt.
-C : Ezt megadva a Squid figyelmen kívül hagyja a legtöbb szignált.
-D : Letiltjuk az induláskor lefutó DNS ellenörzést.
Ezt általában offline környezetben érdemes használni!
-N : Nem démon módban indul a program.
Láthatjuk, hogy a Squid lényegében a konfigurációs állományát használja fel a tevékenységeihez, mivel a parancssori paraméterekkel eléggé szegényesek a lehetőségeink. Ezért keressük meg a /etc/squid.conf fájlt és nyissuk meg valamilyen szerkesztővel.
Legelső paraméter, amit átállíthatunk, az a proxy HTTP portja, amelyet a
http_port 3128
szöveg jelez. A 3128 a Squid alapértelmezett portja, ezt általában szokás a hazánkban inkább elterjedt 8080 számú portra átírni, de ez persze nem feltétlenül kötelező!
Kisebb proxy-k nem szokták használni, de a nagy forgalmú helyeken használják az ICP illetve HTCP protokollokat, amelyek rendre Internet Cacheing Protocol illetve Hyper Text Cacheing Protocol rövidítései. Ezen protokollokat használja a Squid a többi proxy szerverrel való kapcsolattartáshoz, hogy a helyi gyorsítótárban nem található oldalakat például nem a lassabb külföldi vonalakat terhelve kezdi leszedni, hanem megkérdezi a gyorsabb hazai kapcsolatokon található társproxy-szervereket, amelyeken lehet, hogy megtalálható a kérdéses oldal.
icp_port 3130
htcp_port 4827 A fentiekkel összhangban megadható a többi proxy elérhetősége és típusa. Minden sort a cache_peer kulcsszóval kell bevezetni, amelyet a társproxy elérhetősége követ. Továbbá kijelölhetjük a megnevezett proxy szerver elérési módját, majd a HTTP és az ICP portokat. Ezeket követően megadhatunk különféle paramétereket.
cache_peer proxy.akarhol.hu parent 3128 3130 login=usernev:jelszo
Általában a parent kulcsszót használjuk, ez jelenti a hierarchiát a proxy szerverek között. Értelemszerűen a parent a mi gyorsítótárunk felett álló szervert jelenti.
Meg kell adni a Squid által lefoglalt memória maximális méretét. Fontos, hogy mindenképpen sokkal több memória legyen a gépben, mert ha a rendszermag swap használatára kényszerül, akkor nagyságrenddel lassabb lesz a kiszolgálás. Általános szabály, hogy a gépben hosszabb idejű működés után megnézzük, hogy mennyi memória használatos lemezgyorsítótárnak (free parancsnál a cached sor) és ennek felét nyugodtan használhatjuk, ha csak a squid fut, egyébként ennél kevesebbet használjunk.
cache_mem 8 MB
Érdemes meghatározni, hogy mekkora legyen egy objektum maximális mérete amelyet már nem ment le a gyorsítótárba. Ennek alapértéke 4M, de ha például nem szeretnénk, hogy 512 kBájt méretnél nagyobb objektumok a lemezen tárolva legyenek, akkor ezt itt adhatjuk meg.
maximum_object_size 512 kB
Ennek ellentéte az a direktíva, amely meghatározza, hogy mekkora az a legkisebb objektum, amelyet letárolunk a lemezen. Ennek alapértéke 0 Bájt, ezt hagyhatjuk így is, de beállíthatunk más értéket is.
A legfontosabb paraméter a gyorsítótár helyének és méretének meghatározása. Érdemes külön partícióra tenni, illetve a legjobb egy külön lemezegységre tenni, amely lehetőleg SCSI legyen, vagy lehet akár RAID lemeztömb is. A legtöbb alkalmazás helyén erre sajnos nincs anyagi lehetőség, úgyhogy elégedjünk meg egy könyvtárral vagy egy külön partícióval... :) Fontos meghatározni a gyorsítótár maximális méretét, amelyet MBájt mértékegységgel kell megadni. A Squid az itt megadott méretig fogja elfoglalni a szabad területet, viszont előre nem foglalja le. Ebből sajnos menet közben kellemetlen meglepetések várhatnak minket, mégpedig a szabad hely meglepetésszerű eltünése, kivéve, ha külön fájlrendszerre raktuk a gyorsítótárat...
cache_dir ufs /var/squid/cache 1024 256 256
Nagyon fontos megadni a Squid naplófájlok helyét. Ha túl részletes naplózást állítunk be, akkor észrevehetjük, hogy a naplók vég nélkül nőnek nagyon hamar betöltve a rendelkezésre álló helyet. Fontos ezért gondoskodni a naplóállományok rendszeres karbantartásáról, archiválásáról, illetve a naplók helyének megfelelő kijelöléséről, nehogy fontos dolgok vesszenek el a hely elfogyásakor. Ezen okok miatt is részesítsük előnyben a külön partíció használatát.
cache_log /var/squid/log/cache.log
cache_store_log /var/squid/store.log Érdemes megadni az anonymous FTP kapcsolatok esetén használt jelszó helyett megadott email címet. Sok FTP szerver nem kezd ezzel semmit, de néhány szerver létező címet vár. Ez utóbbi esetben létező címet kell megadni, vagy felvenni a mail alias nevek közé a squid felhasználót is.
ftp_user squid@valahol.hu
Érdemes megnézni a timeout paramétereket, mert jelentősen terhelt vonalak esetén lehet, hogy meg kell növelni ezeket.
connect_timeout 120 seconds
peer_connect_timeout 30 seconds Ez utóbbit gyors vonalak esetén érdemes lecsökkenteni, hogy elkerüljük a felesleges várakozást. Ha kellemesen gyors vonalon két-három másodperc alatt nem válaszol a társproxy-szerver, akkor értelmetlen tovább várni. Viszont lassú, illetve csomagvesztéses hálózat esetén lehet, hogy az idők növelése a célszerűbb. Ezen paraméterek optimális értékét a gyakorlatban kell kitapasztalni.
Nagyon fontos része a proxy programnak az elérhetőségének korlátozása. A Squid nagyon kellemesen konfigurálható ebből a szempontból, mivel nem csak a tiltást illetve engedélyezést lehet célként megadni, hanem akár a sávszélességet korlátok közé is lehet szorítani.
Nagyon sok paraméter alapján lehet szűrést végezni. Ezeket az "acl" kulcsszó (Access Control List) vezeti be. Ezeket követi az adott lista általunk megadott neve, majd az acl típusa: 
#src (source) Forrás IP címe, például:
acl sajat01 src 10.1.1.1/30 
acl sajat02 src 10.1.1.6-10.1.1.15/32
#dst (distance) Cél IP címe, például:  
acl sajat03 dst 192.168.1.5/32 
acl sajat04 dst 192.168.1.5-192.168.2.34/32 
#srcdomain (source domain) Forrás neve, például: 
acl sajat05 srcdomain valahol.hu 
#dstdomain (distance domain) Cél neve, például: 
acl sajat06 dstdomain valahol.hu 
#srcdom_regex A forrás nevére illesztett regexp eredménye, például: 
acl sajat07 srcdom_regex user.*valahol\.hu 
#dstdom_regex A cél nevére illesztett regexp eredménye, például: 
acl sajat08 dstdom_regex sex 
#time Idő, például: 
acl sajat09 time M 10:00-12:00 
#url_regex A kért URL szövegére illesztett regexp eredménye, például: 
acl sajat10 url_regex ^ftp.*porn 
#urlpath_regex A kért URL út szövegére illesztett regexp eredménye, például: 
acl sajat11 urlpath_regex \.mpg$ 
#port A megadott portok, például: 
acl sajat12 port 3128 8080 
acl sajat13 port 1024-2048 
#proto (protocolls) A megadott protokollok, például: 
acl sajat14 proto HTTP 
#method A megadott metódusok, például: 
acl sajat15 method POST 
#browser A használt böngésző azonosító szövegére illesztett regexp eredménye, például: 
acl sajat16 browser MSIE 
#maxconn (Maximal Connection Number) Egyidejüleg engedélyezett kérések száma, például: 
acl sajat17 maxconn 5
A fenti acl listák elkészítése után még nincs elvégezve a munka, a "http_access" direktívával kell beállítani, hogy mely acl számára engedélyezzük, vagy tiltjuk a proxy elérhetőségét. Például: 
http_access allow sajat01 
# Az első sor (acl sajat01 src 10.1.1.1/30 ) engedélyezi a 10.1.1.1/30 forráscímről érkező kéréseket. 
http_access deny sajat02 
# A második sor (acl sajat02 src 10.1.1.6-10.1.1.15/32) tilja a 10.1.1.6 IP címtől a 10.1.1.15 IP címig tartó tartományból érkező kéréseket. 
http_access allow sajat03 
# A harmadik sor (acl sajat03 dst 192.168.1.5/32) engedélezi a 192.168.1.5 IP címre irányuló kéréseket. 
http_access deny sajat04 
# A negyedik sor (acl sajat04 dst 192.168.1.5-192.168.2.34/32) tiltja a 192.168.1.5 IP címtől a 192.168.2.34 IP címig tartó 
tartomány felé iráyuló kéréseket. 
http_access allow sajat05 
# Az ötödik sor (acl sajat05 srcdomain valahol.hu) szerint engedélyezzük a "valahol.hu" címről érkező kéréseket. 
http_access deny sajat06 
# A hatodik sor (acl sajat06 dstdomain valahol.hu) szerint tiltjuk azokat a kéréseket, amelyekben a domain egyenlő a "valahol.hu" címmel. 
http_access allow sajat07 
# A hetedik sor (acl sajat07 srcdom_regex user.*valahol\.hu) alapján azokat a kéréseket engedélyezzük, amelyek az forráscímére 
illesztett "user.*valahol\.hu" regexp igaz. Ilyen például az "user123.info.valahol.hu" cím is. 
http_access deny sajat08 
# A nyolcadik sor (acl sajat08 dstdom_regex sex) szerint tiltjuk azokat a célcímeket, amelyek domain nevében szerepel a "sex" karakterlánc. 
http_access allow sajat09 
# A kilencedik sor (acl sajat09 time M 10:00-12:00) szerint engedélyezzük azokat a kapcsolatokat, 
  amelyek hétfőn 10 és 12 óra között kezdődnek. 
http_access deny sajat10 
# A tizedik sor (acl sajat10 url_regex ^ftp.*porn) szerint tiltjuk azokat a kapcsolatokat, amelyek URL sorának első felében lévő szövegre 
  (a http://www.valahol.hu/index.html esetén a http://www.valahol.hu szövegre) illesztett regexp igaz. 
  Jelen esetben azokat az ftp kapcsolatokat, amelyek domain nevében szerepel a "porn" szó. 
http_access allow sajat11 
# A tizenegyedik sorban (acl sajat11 urlpath_regex \.mpg$) engedélyezzük az 
  összes mpg kiterjesztésű fájl elérését. 
http_access deny sajat12 
# A tizenkettedik sorban (acl sajat12 port 3128 8080) tiltjuk a más proxy szerverek felé 
  induló kapcsolatokat. 
http_access deny sajat13 
# A tizenharmadik sorban (acl sajat13 port 1024-2048) tiltjuk a 1024 és a 2048 port 
  közötti portok elérését. 
http_access allow sajat14 
# A tizennegyedik sorban (acl sajat14 proto HTTP) engedélyezzük a HTTP protokollt. 
http_access deny sajat15 
# A tizenötödik sorban (acl sajat15 method POST) tiltjuk a POST metódust. 
http_access deny sajat16 
# A tizenhatodik sorban (acl sajat16 browser MSIE) tiltjuk azokat a böngészőket, 
  amelyek MSIE szöveggel azonosítják magukat. 
http_access deny sajat17 
# A tizenhetedik sorban (acl sajat17 maxconn 5) tiltjuk azon kapcsolatokat, 
  amelyeknél 5 egyidejű kérésnél többet szeretnének. 
http_access deny all 
# Azon kérésekre, amelyek nem illeszkednek egyik sorra sem tiltjuk a kapcsolatot.
Ehhez a listához kell még egy acl all src 0.0.0.0/0.0.0.0
sor az acl listánál.
Amikor a Squid kap egy kérést, akkor végigszalad a listán és ha az adott sor acl szabálya igaz, akkor "allow" esetén engedélyezi, ha "deny" akkor tiltja a kapcsolatot. Ha nincs illeszkedés a listában, akkor az utolsó sor a döntő: jelen esetben tiltva van a kapcsolat.
A http_access direktívával analóg módon használhatjuk az icp_access kulcsszavat is.
Érdemes használni a DELAY POOL névvel illetett sávszélesség korlátozó direktívákat. Ezeket használva a http_access sorokon túljutott kérések újabb akadályokkal találkoznak. Ha illeszkednek egy ilyen korlátozásra, akkor a sávszélességből csak adott szeletet használhatnak majd.
Alapvetően meg kell határozni a különféle korlátozások számát.
delay_pools 3
Ezek után meg kell adni a használt korlátozás osztályát. Amelyek szerint az első korlátozás hármas típusú, a második egyes illetve a harmadik kettes. 
delay_class 1 3 
delay_class 2 1 
delay_class 3 2
Ezt követi a korlátozások paraméterezése. Az első paraméter az adott korlátozás száma. A három osztály szerint meg kell különböztetni a három paraméterezést. Az osztályok szerint a következő formátumot kell használni 
delay_parameter 1 osszes 
delay_parameter 2 osszes halozati 
delay_parameter 3 osszes halozati egygep
ahol az "osszes" a teljes forgalom, a "halozati" a 255.255.255.0 hálózati maszkba eső gépek forgalma az "egygep" pedig a 255.255.255.255 hálózati maszkba eső gép forgalma.
A fentiek értelmében a második késleltetés egyes típusú, így egy paramétere van, vagyis 1600 Bájt/másodperc sávszélességet enged, és egyszerre maximum 3200 Bájt adatot szed le a kért objektumból.
delay_parameter 2 1600/3200
A harmadik késleltetés a kettes típusú, két paramétere van, a teljes forgalom nincs korlátozva, viszont az alhálózat 3200 Bájt/másodpercre van korlátozva és egyszerre maximum 6400 Bájtot tölt le.
delay_parameter 3 -1/-1 3200/6400
Az első késleltetés hármas típusú, három paramétere van, az első kettő azonos funkciót lát el, mint az előző, a harmadik egy gép korlátozása, vagyis 512 Bájt jut egy gépre másodpercenként és egyszerre 2048 Bájt terheli a kifelé irányuló vonalat.
delay_paramter 1 1600/3200 800/1600 512/2048
Amint megvannak a paraméterezések, következik az engedélyezés. Amelyik kérés túljutott a http_access sorokon még a késletetést engedélyező sorokon is túl kell esnie. 
delay_access 1 allow sajat04 
delay_access 1 deny all 
delay_access 2 allow sajat11 
delay_access 2 deny all 
delay_access 3 allow sajat09
A fenti sorok például a sajat04 acl sorba eső kéréseket beleirányítja az első korlátozásba. Minden más kikerüli az első korlátot.
A második korlátozásba a sajat11 kerül, vagyis például vállalati szinten maximálisan 1.6 kBájt/mp sebességgel lehet mpg állományokat letölteni. A harmadik korlátozásba akkor jut egy kérés, ha 10 és 12 óra között kapcsolódik.

28.3.) A görgős egér beállítása Linux grafikus felülethez

2004-es állapot szerinti leírás!!!
Eredeti verzió: http://www.root.hu/?c=207
Ha valakinek görgős egere van, miért is mondana le a görgő nyújtotta kényelemről? A 3.x verziójú Xserverek az Imwheel nevű program segítségével szépen le is kezelték ezeket az egereket. A 4.x-es Xserverekhez már nincs szükség az imwheelre, bár hátránya az, hogy nem használható együtt a gpm-el.
Keressük meg a /etc/X11/XF86Config file-ban a Section "InputDevice" kezdetű részt. A görgő a legegyszerűbben ps/2 -es egérnél állítható be, ezért ennek a beállítását mutatom be. Először állítsuk be az egeret. Ps/2-es egér esetében ezt a következő sorok beírásával tehetjük meg: 
Identifier "Mouse1" 
Driver "mouse" 
Option "Protocol" "imps/2" 
Option "Device" "/dev/psaux"
Az imps/2 protokoll biztosítja a továbbiakban az egér működését, így a gpm-re nincs szükség a továbbiakban, azt ki is kell kapcsolni, nehogy összeakadjanak. A görgő használatához definiálni kell, hogy hány gomb van az egerünkön, és mely gomboknak felel meg a görgő. Pl.: 
Option "Buttons" "5" 
Option "ZAxisMapping" "4 5"
Ez a példa egy 5 gombos egérre vonatkozik, de más egerek hasonló analógiával beállíthatók. Ezek után csak el kell indítani az X-et, és használhatjuk a görgőt egerünkön.

28.4.) Mountolási tippek Linuxhoz

Eredeti verzió: http://www.root.hu/?c=553
A Linuxszal most ismerkedőknek gyakran gondot okoz, hogyan lássanak más partíciókat a merevlemezükön. Leginkább a jól megszokott régi Windowsos vagy NT-s partícióikat hiányolják. Nekik szól ez a tipp.
A legelső lépés, hogy megbizonyosodjunk arról, hogy kernelünk támogatja e az adott filerendszert. Ha valaki még mindig az indítókernelt használja, annak jó hír, hogy ezzel nem nagyon kell foglalkoznia, ugyanis ezeknél a kerneleknél a legtöbb támogatás vagy a kernelbe, vagy modulokba van fordítva. Ha már fordítottunk magunknak új kernelt, akkor győződjünk meg róla, hogy az adott filerendszer támogatását is belefordítottuk. Ha nem, ezt pótoljuk.
Ha a fájlrendszer támogatását megoldottuk, akkor mountolhatunk. A szintaktika a következő:
mount [opciók] / /
Néhány opciót a teljesség igénye nélkül ismertetek, továbbiakért lásd a mount manpageket.
Egy ntfs filerendszer mountolása a következőképpen lehetséges:
mount -t ntfs /dev/hda1 /mnt
Ezzel az első IDE vezérlő master diskjének első partícióját a /mnt könyvtárba csatoltuk. Más filerendszer esetében hasonlóan járhatunk el. Ha azt szeretnénk, hogy az fstab file-ban levő összes partíciót bemountoljuk az fstab-ban meghatározott helyére, akkor a következő parancs szükséges:
mount -a
Ha nem akarjuk, hogy egy becsatlakoztatott filerendszeren a felhasználó binárist futtasson, akkor azt a noexec opcióval tehetjük meg:
mount -o noexec / /
Ha quotát is szeretnénk adni az egyes felhasználóknak, csoportoknak, akkor az mountoláskor engedélyezhetjük:
felhasználók esetén:
mount -o usrquota / /
csoport esetén:
mount -o grpquota / /
vagy, mindkettőt meg lehet adni:
mount -o usrquota,grpquota / /
Egy esetleges áramszünet utáni bootoláskor néha nem fut le az fsck hiba nélkül, és kéri, hogy kézzel futtassa. Ilyenkor a filerendszert először irható-olvasható módon kell visszamountolni, hogy az esetleges javítások elvégezhetőek legyenek. Ezt a következőképpen tehetjük meg:
mount -n -o remount,rw /
Néha jól jöhet, hogy CD image file-okba is bele tudjunk nézni, esetleg futtatni bennük lévő binárisokat. Ilyenkor loopbackbe kell mountolni. Ehez szükség van a loopback interface támogatásra, amit a kernelbe kell fordítani. Ezek után a csatlakoztatás a következő módon történik: mount -o loop -t iso9660 / /
Természetesen a felsoroltak csak töredékét képezik a lehetőségeknek, de egy kezdő számára jó kiindulási alapul szolgálhatnak. Továbbiakért a mount parancs man pagek tanulmányozását javaslom.

28.5.) SuSE Linux fontosabb konfigurációs állományai

2004-es állapot szerinti leírás!!!
Forrás: www.suselinux.hu Eredeti verzió: http://www.root.hu/?c=873
Konfigurációs állományok az /etc könyvtárban Rejtett konfigurációs állományok a /home könyvtárban Eszközök a /dev könyvtárban CD-ROM meghajtók Egerek Portok és modemek

28.6.) Apache installálás és konfigurációs fájlok

2004-es állapot szerinti leírás!!!
Forrás: root.hu Eredeti verzió: http://www.root.hu/?c=201
Hozzájutni a http://www.apache.org/, vagy más egyéb mirror vagy ftp site-okról lehet. Ezek közül figyelmet érdemelnek a következők:
http://xenia.sote.hu/ftp/linux/mirrors/www.apache.org/dist/
ftp://ebizlab.hit.bme.hu/pub/apache/dist/

Installálás
Letöltés után: kibontása Linux alatt: tar -xzvf apache_1.3.14.tar.gz - ha ezt a verziót töltötte le.
Utána: cd apache_1.3.14 - Könyvtárváltás.
./configure - Egy konfigurálási parancs. Fontos az elején a PONT.
Igy beállítható, hogy az Apache a /usr/local/apache könyvátrba telepedjen.
A configure bőségesen kommentezhető. Érdemes elolvasni telepítés előtt!
Telepítés után:
make, majd make install parancsok következnek.
Először editáljuk az httpd.conf file-t. Ez állítja be a szerver általános tulajdonságait; mint a port szám, a user aki alatt futni fog a szerver, stb. (Javaslat: www - ez az alapértelmezés is) Általában is érvényes, hogy kezdőként az ALAPÉRTELMEZETT BEÁLLÍTÁSOKAT NE MACERÁLJUK! A következő amit editálunk az a srm.conf ; ez állítja be a dokumentum fa root-ját, valamint speciális funkciókat mint belső imagemap elemző, stb. Végül az access.conf kerül sorra , hogy beállítsuk a hozzáférések vezérlését.
Végül meghívjuk a httpd -f opcióval a teljes elérési útjával a httpd.conf file-nak.
/usr/local/etc/apache/src/httpd -f
/usr/local/etc/apache/httpd.conf A szervernek most futnia kell.
Alapértelmezés szerint az srm.conf és az access.conf helyét név alapján határozza meg. Ha más név alapján akarjuk hívni akkor használjuk az AccessConfig és ResourceConfig directivákat a httpd.conf-ban.

Konfigurációs file-ok
A file-ok nevét a ServerRoot utasítással lehet beállítani, vagy a -d parancssori flaggel. Konvenció szerint a file-ok:
conf/httpd.conf
Utasításokat tartalmaz amelyek irányítják a server daemon működését. A file neve felülírható a -f parancssori opcióval. Ebben sorrendben a következő dolgokat kell beállítani:
- ServerType
inetd : kevésbé használt, nagyon leterheli a rendszert, viszont biztonsági megfontolásokból vannak akik ezt preferálják
standalone : sokkal hatékonyabb mód,
- Port
Ezt a portot fogja figyelni a daemon. Ha a száma < 1023 akkor a servert a root userid-je alatt kell elindítani.
- HostNameLookUps
Ha be van kapcsolva akkor bejegyzi a kliensek nevét vagy IP számát.
- User
Ennek a usernek a nevében fog a server a kérésekre válaszolni. Lehet egy username, vagy egy user-id. Szoktak egy új usert létrehozni erre a célra , sok esetben nobody vagy wwwuser néven.
- Group
Ebben a csoportban vagy a létrehozott user.
- ServerAdmin
A serveradmin e-mail címe. Nem árt jól kitölteni.
- ServerRoot
A directory ahol a server config és log file-jai találhatóak. Gyakorlatilag az a directory ahol a server "él". Itt található a conf/ és a /log dir-k
- BindAddress
A virtuális host-ok használata esetén az itt felsorolt IP címek alatt figyeli a serverhez irányuló kéréseket. Lehet egy számmal, vagy egy névvel megadni.
- ErrorLog logs/error_log
Ide jegyzi be az esetleges hibákat.
- TransferLog log/access_log
A transfer-rel kapcsolatos bejegyzések.
- LogFormat string
Lehetőséget ad , hogy átformázzuk a log file szerkezetét. A mod_log_config.c modul tartalmazza, és nem fordítódik automatikusan.
- PidFile logs/httpd.pid
A server ide jegyzi be a daemon pid-jét.
- ScoreBoardFile logs/apache_status
Ide jegyzi be a server a belső process információkat.
- ServerName
Itt lehet beállítani a server hostname-jét. Ez elsősorban URL átirányításoknál és virtuális hostoknál szükséges ill. használható.
- Timeout 400
Ennyi secundumot vár a server egy kérésre vagy a nyugtázásra.
- KeepAlive 5
Lehetővé teszi a Keep-Alive support megvalósítását. Ez adja meg a maximálisan kezelhető kérések számát.
- KeepAliveTimeout 15
Ennyi sec-t vár egy subsequent request beérkezésére. Ha egyszer beérkezett a kérés akkor a Timeout lép életbe.
- MaxSpareServers 15
Maximum ennyi tétlen (idle) child server process lehet. Az idle process az, amely nem kezel kéréseket. Ha több van akkor a parent process megöli a felesleges processeket.
- MinSpareServers 5
Ugyanaz mint a fenti csak ez minimumban. Ha nincs meg a minimum, akkor a parent elkezd kreálni processeket. Soha nem jó ha túl nagy ez a paraméter.
- StartServers 5
Induláskor ennyi child server process kreálódik. - MaxClients 150
Egyszerre ennyi request-et tud kezelni, és maximum ennyi child servrer process kreálható. - MaxRequestPerChild 30
Egy child server process ennyi darab kérést szolgál ki, utánna kilép és új child indul. - ProxyRequest On
Akkor kell kivenni belőle, ha proxy serverként akarjuk működtetni a serverünket. Biztosítani a Cache az előző esetre az alábbiakat is ki kell venni a megjegyzésből: 
CacheRoot 
CacheSize 5 
CacheGcInterval 4 
CacheMaxExpire 24 
CacheLastModifiedFactor 0.1 
CacheDefaultExpire 1 
Nocache
Listen [IP address:] port number
Lehetővé hogy egynél több porton vagy IP címen figyeljen a server, a default hogy válaszol a kérésekre minden IP címen, de csak a megadott porton. Végül a virtuális hosttal kapcsolatos dolgokat kell beállítani, persze csak ha használjuk ezt a lehetőséget: 
<VirtualHost host.foo.com>
ServerAdmin webmaster@host.foo.com 
DocumentRoot 
ServerName host.foo.com 
ErrorLog 
TransferLog 
</VirtualHost>
conf/srm.conf
Tartalmazza a leírásokat azokról a dokumentumokról, amelyeket a server a clienseknek szolgáltat. Valamint azokat a server beállításokat, amelyek a requestek kiszolgálását, a végeredmények formáját meghatározzák.
A file neve a ResourceConfig paranccsal definiálható át.
DocumentRoot
Az a directory ahonnan a httpd szolgáltatja a file-okat. UserDir public_html
A user-ek home directory-ja. Ezt fogják hozzáfűzni, ha egy user request érkezik.
Directory_index index.html
File vagy file-ok nevei, amelyek előre megírt HTML dokumentumokat tartalmaznak. Ha több ilyen van akkor space-szel kell őket elválasztva felsorolni.
FancyIndexing on 
AddIconByEncoding icon mime-encoding mime-encoding.. 
AddiconByType icon mime-type mime-type.. 
AddIcon icon name name name ...
Ezek a direktívák állítják be, hogy milyen ikon jelenjen meg egy file mellett. Az mindhárom esetben az ikon vagy egy relativ URL az ikonhoz, vagy (alttext,url). Az alttext egy betűszó a nem grafikus browserekhez.
Például :
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip
AddIconByType (TXT,/icons/text.gif) text/*
AddIcon /icons/binary.gif .bin .exe
- DefaultIcon /icons/unknown.gif
Azokhoz a file-okhoz amelyekhez nincs explicit icon definiálva.
- AddDescription description file file
Egy rövidke lis megjegyzést fűzhetünk minden server által generált file-hoz, amelynek a neve egyezik a file-névvel, ami lehet egy kiterjesztés is.
- ReadmeName filename
- HeaderName filename
Az adott directory-ban az index lista végére ill. elejére teszi be a filename.html-t, vagy ha ilyet nem talál akkor a filename-t keresi mint text file-t.
- IndexIgnore file file
Az itt felsorolt file-ok nem lesznek megjelenítve ha kilistázunk egy directory-t. A file lehet egy név, egy részleges név , egy wildcard karakteres név. A lista defaultként tartalmazza a '.' Például : IndexIgnore README .htaccess - AccessFileName .htaccess
Annak a file-nak a neve amelyet minden directory-ban az access control konfigurációt tartalmazza. Abban az esetben nem olvassa csak el ha : Alloverride None
- DefaultType
Azt adja meg, hogy ha egy file-nak nincs meghatározható típusa a MIME mapping alapján akkor ezt veszi defaultnak. Például: van egy aldir. images/ és abban .gi file-ok , akkor DefaultType images/gif azt eredményezi, hogy ha egy file-nak ebben az aldir-ban nincs meg a .gif kiterjesztése akkor automatikusan annak veszi a server. - AddEncodig mime-enc extension extension
Azt eredményezi, hogy a felsorolt extensionnal rendelkező file-ok a mime-encodingnak megfelelően lesznek azonosítva. Mire jó ez? Arra, hogy egyes browserek menetközben tudnak kitömöríteni ez alapján. Pl: AddEncoding x-compress Z, akkor uncompress fog használni minden .Z végű file-hoz. - AddLanguage mime-lang extension extension
Például: AddEncoding x-compress Z
AddLanguage en .en
AddLanguage fr .fr
Ekkor az xxx.en.Z dokument úgy lesz kezelve mint egy comressált English dokumentum.
- LanguagePriority
Ez egy precedenciát ad meg hogy milyen sorrendben oldja fel a kötéseket.
- ReDirect url-path url
Megmondja a client-nek , hogy próbálkozzon a dokumentum elérésével az új URL címen. Például: Redirect /service http://foo2.bar.com/service .
Akkor egy kérés ami a http://myserver/service/foo.txt akarja elérni a http://foo2.bar.com/service/foo.txt URL irányul át.
-Alias url-path directory-filename
Lehetővé teszi , hogy a local filesystemben is tartsunk dokumentumokat, ne csak a DocumentRoot alatt. Például: Alias /image /ftp/pub/image
Akkor egy kérés http://myserver/image/foo.gif a következő filet fogja szolgáltatni /ftp/pub/image/foo.gif.
- ScriptAliases url-path directory-filename
Ugyanaz a viselkedése mint az Alias-nak csak ez scriptekre érvényes.
például: ScriptAlias /cgi-bin/ /web/cgi-bin
Akkor http://myserver/cgi-bin/foo kérés /web/cgi-bin/foo scriptet fogja indítani.
- AddType mime-type extension ...
Egy új mime típus hozható így létre.
páldául: AddType image/gif GIF
Így nem kell átdefiniálni a TypesConfig file-t. - AddHandler handler-name extension
Azt eredményezi, hogy az adott extension-nal rendelkező file-okat. a hendler-name handler fogja kezelni.
például: AddHandler cgi-script cgi Akkor minden .cgi kiterjesztésű file CGI-scriptként lesz kezelve.
- Action mime-type cgi-script
Ha egy kérés érkezik a mime-type típusú file-ra, akkor a cgi-scriptet aktivizáljuk.
például: AddHandler foot-action foot
Action foot-action /cgi-bin/footer
- MetaDir
- Metasuffix
A CERN HTTPD meta file szemantikát emulálja. A MetaDir azt a directory-t adja meg, amelyben a meta információk file-jai vannak. Ez általában egy 'rejtett' subdirectory. A neve '.' -al kezdődik.
A MetaSuffix azt a file név kiterjesztést adja meg amelyben a meta információk tárolódnak.
- ErrorDocument Error-code document
Lehetőség van arra , hogy egy adott hiba esetén a mi általunk definiált hibaüzenet jelenjen meg.
Háromféle hibakezelés lehetséges ezzel a módszerrel: plain text: Ekkor egy előre meghatározott hibaüzenet jelenik meg.
Például : ErrorDocument 500 "The server made a boo boo.
Ebben a (") jel azt jelenti, hogy ez egy text.
local átirányítás: Például : ErrorDocument 404 /missing.html
Ekkor a helyi /missing.html fog betöltődni
külső átirányítás : pl : ErrorDocument 402 http://other.server.com/subscription_info.html

conf/access.conf
A dokumentumok elérését szabályozó utasításokat tartalmaz. Ez a file azokat a server beállításokat tartalmazza amelyek szabályozzák, hogy mely szolgáltatásokat milyen körülmények között érhetünk el. A file neve az AccessConfig utasítással értelmezhető át. Itt lehet megadni, hogy mely directory-kat akarunk password-el védeni, melyeket teszünk nem hozzáférhetővé.
- <Directory dir-name> ... </Directory>
Arra szolgál , hogy egységbe zárja azokat a direktívákat amelyek az adott directory-ra ill. az összes aldirectorykra érvényesek. Elsősorban az access.conf file-ban jelenhet meg, de persze a többi config file-ban is felhasználható. Nem lóghat át ill. nem jelenhet meg a <Limit> szekcióban.
- <Limit method method> ... </Limit>
A felsorolt access method-okra a közbezárt elérési direktívák lesznek érvényesek.
Például : 
<Limit GET POST> 
require valid-user 
</Limit>
- <Location URL path> ... </Location>
Access control-t tesz lehetővé az adott URL-nek. A URL path formátuma /directory/ legyen. A <DIrectory> section után kell következnie.
Például : 
<Location /status>
SetHandler server-status 
order deny,allow 
deny from all 
allow from .foo.com 
</Location>
- Options options options
Szabályozza, hogy mely extra szolgáltatások érhetőek el az adott Directory-ban.
Például : 
<Directory [documentroot] >
Options Indexes FollowSymlinks 
</Directory>
Azt eredményezi, hogy ha nincs index.html az [documentroot]-ban akkor ad egy directory listát és követi a szimbolikus linkeket az adott directory-ban.
- AllowOverride override override
Ha a server talál egy .htaccess file-t az adott dir-ban akkor tudnia kell, hogy az ott felsorolt utasítások felülbírálhatják-e a már előzőleg tett beállításokat. Ha az override None akkor a server nem olvassa el a .htaccess-t
Például : <Directory [Documentroot]> Options Indexes FollowSymlinks AllowOverride None </Directory> . - allow from host host
Csak azok a host-ok érhetik el az adott direktory-t amelyek a fel vannak sorolva a host-ok között. Tipikusan a <Limit> szekcióban használandó.
A host lehet :
- all : Ekkor minden host kap access-t
- A (partial) domain-name : Az a host, vagy hostok kapnak access melyeknek a neve vagy a nevének a domain része egyezik.
- A full IP address : Az adott IP address-szel rendelkező host kap accesst.
- A partial IP address : Az IP cím 1-től 3 byte-ig terjedő része, subnetting esetén.
- allow from .ncsa.uiuc.com : Ekkor a hostok a fenti domain névvel mind kapnak access-t a directory-ra.
- deny from host host ... : Azt sorolja fel , hogy mely hostok nem kaphatnak access jogot az adott directory-ra. Hasonlóan az előzőhöz ez is a <Limit> szekcióban használandó. A host az előzőben leírt szerint értendő.
Pl: deny from 16 Akkor a specifikált network nem kaphat access jogokat. - order ordering
Ez határozza meg, hogy az allow és deny direktívák hogyan, milyen sorrendben értékelődjenek ki. Például: 
<Directory [Documentroot]>
Options Indexes FollowSymlinks 
AllowOverride None 
order allow, deny 
</Directory>
Vagyis az allow direktíva a deny előtt értékelődik ki.
Lehet még az ordering : - deny, allow
Elsőnek a deny , majd utána az allow értékelődik ki.
- mutual-failure
Csak azok a hostok kapnak elérési jogot az adott direktory-ra, amelyek szerepelnek az allow listában és nem szerepelnek a deny listában.
- require entity-name entity
Ez állítja be , hogy mely userek érhetnek el egy dir-t.
- user userid userid...
Csak a nevezett userek kaphatnak access jogokat.
- group group-name group-name..
Csak az adott csoportoknak lehet access joga.
- valid-user
Minden valid-user elérheti a dir-t.
Ha a <Limit> szekcióban jelenik meg akkor csak az adott method-ra érvényes, egyébként minden access methodra. Egy példa ennek prezentálására: 
AuthType Basic 
AuthName somedomain 
AuthUserFile /web/users 
AuthGroupFile /web/groups 
Limit 
require group admin
- AuthType type
Ez adja meg , hogy a user azonosítás mely típusát használjuk egy adott dir-ra.
- mod_auth
Ez a modul szöveges file-okon alapuló user azonosítást tesz lehetővé. Defaultként fordítódik.

Direktívák:
- AuthGroupFile filename
Ez a file fogja tartalmazni a user gropuokat amelyek kaphatnak access-t.
Egy sora : mygroup: bob joe anne.
Nagy méretű file esetén nem szerencsés alkalmazni. Ekkor az AuthDBMGroupFile jobb hatásfokkal alkalmazható.
A filename abszolút path-al kell megadni.
- AuthUserFile filename
Ez a file tartalmazza a userek neveit és a hozzájuk tartozó password-t. Nagy file esetén az AuthDBMUserFile gyorsabb lesz.
Egy sor tartalmazza a user nevét majd kettőspont után a crypt()-tel titkosított password következik. - mod_auth_msql
Ez is default-ként fordítódik. Lehetővé teszi, hogy public domain mSQL adatbázis file-okat használjunk user azonosításra.
Például: 
<directory /web/docs/private>
Auth_MSQLhost localhost vagy ehelyett 
Auth_MSQLhost datab.machine.your.org 
Auth_MSQLdatabase www 
Auth_MSQLpwd_table user_records 
Auth_MSQLuid_field User_id 
Auth_MSQLpwd_field Cpasswd 
Auth_MSQL_nopasswd off 
Auth_MSQL_Authorative on 
Auth_MSQL_EncryptedPasswords on 
AuthName example mSQL realm 
AuthType basic 
</directory>
<Limit get post head>
order deny, allow 
allow from all 
require valid-user 
require group has_paid 
</limit>
mod_auth_dbm
A user azonosításra DBM file-okat használ. Nem fordítódik defaultként.
Néhány száz azonosítandó user, vagy csoport fölött a sima text file azonosítás nagyon hosszú időt vesz igénybe. Ekkor ezt érdemes használni.
A DBM file-ok nem text állományok és nem vihetők át egyik platformról a másikra csak úgy.

A direktívák:
- AuthDBMGroupFile filename
A filename file adja a user csoportok azonosítását. Egy sora egy user és utána felsorolva a csoportok ahova tartozik.
- AuthDBMUserFile filename
A userek azonosítására szolgáló file. A kettő összekombinálható:
AuthDBMGroupFile /www/userbase
AuthDBMUserFile /www/userbase
Ekkor egyetlen DBM file fog azonosítani. A kulcs a username lesz és a következő formátumban tartalmaz bejegyzéseket:
Unix Crypted Password : List of Groups [ : (ignored) ]
- mod_auth_db
A user azonosításra Berkley DB file-okat használ. Ez is egy opcionális modul.
- AuthDBGroupFile filename
- AuthDBUserFilename filename
- Anonymous access controll A mod_auth_anon modulban található, és default-ként fordítódik.
Az anonymous ftp site-okhoz hasonló viselkedést tesz lehetővé. Vagyis lesz egy 'magic' userid 'anonymous' és a hozzá tartozó password az e-mail cím.
Egy példán keresztül a működése: 
Anonymous anonymous guest www test welcome 
Anonymous_MustGiveEmail on 
Anonymous_VerifyEmail on 
Anonymous_NoUserId off 
Anonymous_LogEmail on 
AuthName Use 'anonymous' & Email address for guest entry 
AuthType basic 
conf/mime.types
Tartalmazza a default mime típusokat. Ezt a file-t szerkeszteni nem igazán ajánlott, helyette inkább az AddType direktíva használandó új mime típusok hozzáadására.

Log file-ok:
pid file A daemon indulásakor elmenti a szülő httpd process id -t a logs/httpd.pid file-ba. Ez a file név át definiálható a PidFile utasítással. A process id -t az adminisztrátor használja újraindítani és lelőni a daemon-t.
Error log
A server ide írja be az hibaüzeneteit, a neve logs/error_log. A file neve átállítható az ErrorLog utasítással. A különböző virtual host-oknak különböző error log-ok állíthatók be.
Transfer log
A server bejegyez minden request-et egy transfer file-ba. A neve: logs/access_log. A file neve a TransferLog utasítással értelmezhető át. A virtuális host-okra itt is érvényes, hogy különböző transzfer bejegyzések állíthatók be.
Cookie log
mod_cookies.c-ben található. Nem fordítódik defaultként. CookieLog filename adja meg a log file helyét. Agent log
mod_log_agent.c-ben található. AgentLog logs/agent_log

28.7.) NCFTP, wget és expect

2004-es állapot szerinti leírás!!!
Sokan nem véletlenül szeretik az FTP-t, azaz a File Transfer Protocol-t. Egyszerűbb, gyorsabb, mint a népszerűbb http, ráadásul reklámmentes.
Minden Linux, mivel sokan vannak a szerzők, folyamatosan fejlődik. Ezért igen sokan kell frissíteni és aktualizálni. Ezt a két tulajdonságot ötvözi a különösebb beavatkozást nem igénylő program, az NCFTP.
Weblapja: http://www.ncftp.com/
Tény, hogy a program elég fapados, de gyakorlatilag mindent lehet vele automatizálni!
Javasolt a kézikönyv igen gyakori használata! (man ncftp)
ncftpget/ncftpput - Beavatkozás nélküli fel-/letöltés.
Többé-keveésbé rokon a két következő szolgáltatás is:

28.8.) Kernel-modulok: frissítés és optimalizálás

2004-es állapot szerinti leírás!!!

28.8.a.) Tényleg kell ez nekem?

A válasz egyszerű: NEM!
Kérem, hogy ha egy otthoni és/vagy irodai feladatokra szánt Linuxos gép megbízhatóan működik, akkor NE fordítson kernelt. Tényleg nem kell hozzányúlni!
Akkor mégis: miért?
A válasz egyszerű: hogy frissebb, jobb és még stabilabb legyen. Lehetnek olyan apróbb problémák, melyket az újabb kernel jobban old meg. Lehetnek olyan frissítések, melyek a felmerülő biztonsági réseket jobban betömködik. Ez komoly szervereknél igen fontos tényező, de szeretném megismételni, hogy egy sima asztali gépnél nem feltétlenül szükséges.

28.8.b.) Állományok beszerzése

A legcélszerűbb a hivatalos, teljesen ingyenes forrásból beszerezni mindent. Mivel a Linux-os környezetben nincs szükségfizetős programokra, ezért minden forrás a szerződés betartása mellett teljesen szabadon letölthető és ízlés szerint alakítható is!
Szeretném figyelmeztetésként felvetni, hogy mivel az egyes disztribúciók ára igen olcsó, ezért a Linux-osok között ismeretlen a Windows-os környezetben "hagyományos" általános másolás.
Szóval a lehetséges letöltési címek:
Red Hat redhat.com
Suse Linux suse.com
Mandrake mandrake.com
Linux Online linux.org
Apache apache.org

28.8.c.) Tömörített állományok kibontása

A legegyszerűbb módszer erre az mc (Midnight Commander) használata, mivel az röptében kibont minden fontosabb tömörítést.
"Gyalog" is lehet boldogulni. A tar tömörítő a szinte egyeduralkodó.
Minta: tar -xvf csomagneve.tar
Ha a csomag végén .Z is szerepel, akkor a kitömörítés előtt: uncompress csomagneve.tar.Z
A tar legfontosabb kapcsolói:
-x : kicsomagolja a fájlokat
-v : a feldolgozott fájlokat beszédesen listázza ki. (Lássuk, hogy mi is történik)
-f : a megadott fájl, illetve eszköznevet használja.

28.8.d.) Program konfigurálása

A kicsomagolás után általában kapunk egy nagy csomó programot.
Érdemes "readme", vagy "install" fájlokat keresni és alaposan elolvasni! (NEM VICC!)
Sajnos a Linux egyik hátránya, hogy sokan fejlesztik, ezért sokféle lehet a setup-módszer.
A konfigurálás egyetlen parancsa: ./configure
Fontos előtte a pont és a törtjel is!

28.8.e.) Utolsó lépések

Ez az esetek túlnyomó többségében elkészíti a "Makefile"-t, amelyet szintén futtatási paramétereket tarttalmazza. Indítása: make
Ez elvégzi a program lefordítását és az egyes részek összefűzését!
Általában ezt a lépést a make install követi, ami tényleg a legutolsó lépés!
A programokat általában el lehet távolítani egy sima uninstall begépelésével, ha a megfelelő könyvtárban állunk!

28.8.f.) A csomagkezelők

Mivel rengeteg Linux létezik, ezért a fenti bonyolult lépéssort az egyes disztribúciók előszeretettel lerövidítik. Eme telepítőcsomagok használatával végletesen leegyszerűsödik a telepítés és általában egyetlen lépéssé szűkül le.
Ilyen kiterjesztés a Debian Linux alatt a .deb, a RedHat, a Caldera, a Mandrake és még sok verzió alatti .rpm. Az esetek többségében a Red Hat Pockage Manager-t fogjuk használni, röviden az rpm-et.
Az egyes csomagok elnevezése igen sokféle lehet. Általában kezdődik a csomag nevével, majd következik a verziószám, esetleg a processzortípus (i386 = általános Intel processzor; i586 = min. Pentium II; i686 = min. Pentium III; ialpha = DEC Alpha szuperprocesszor; ...), míg a legvégén jön a .rpm rövidítés.
Az rpm használt fontosabb kapcsolói:
-i : Install = intallálás
-l : List = Listázza ki az rpm tartalmát.
-e : Erase = Rpm csomag törlése.
-U : Uninstall = uninstallálás
-F : Fresh = frissítés
-h : a folyamat előrehaladtát jelzi # jelekkel. Érdemes bekapcsolni.
-v : érdemes a h-val együtt bekapcsolni az olvashatóbb képernyőért.
-vv : (h nélkül) Az összes információt írja ki telepítés alatt.

Pingvin Összefoglalva egy mintában: 
Telepítés: rpm -ivh csomagneve_verzio.i386.rpm
Törlés: rpm -evv csomagneve_verzio.i386.rpm
Uninstallálás: rpm -Uvh csomagneve_verzio.i386.rpm
Tapasztalatom szerint ez a módszer legtöbbször kiválóan működik, de előfordulhatnak kisebb-nagyobb hibák is. Ilyenkor jól jön egy uninstallálás.

28.9.) Rendszermag

2004-es állapot szerinti leírás!!!
Pingvin Alapvetően a rendszermagot NEM KELL LEFORDÍTANI. Azonban érdemes vele próbálkozni, mivel a rendszer drasztikusan gyorsulhat tőle. (20-150%) Nyilván minél pontosabbak a beállításaink, annál nagyobb lehet az elért sebességnövekedés.
Általános forrása: www.kernel.org/mirrors
Esetleg: www.hu.kernel.org, vagy ftp.hu.kernel.org
NAGYON FONTOS FIGYELMEZTETÉS!
Csak stabil (=stable) kernelt szabad letölteni, mivel a kísérleti fázisban lévők komoly problémát okozhatnak! A kísérleti fázisban lévőket csak a kísérletező kedvűeknek ajánlhatom.

28.10.) Távoli gépek felügyelete - VNC

2004-es állapot szerinti leírás!!!

28.10.a.) Telnet

telnet gépnév - bejelentkezés távoli gépre.
Szolgáltatások port-számai: /etc/services
Rengeteg kapcsolóval és paraméterrel van felszerelve, de igen hasznos lehet! Hibája, hogy a kapcsolat teljesen nyíltan történik, így a bejelentkezés könnyedén lehallgatható!

28.10.b.) Biztonság mindenek előtt: SSH

A telnet használatát lehet vele biztonságossá tenni. Rövid leírása:

28.11.) PostgreSQL adatbáziskezelő

2004-es állapot szerinti leírás!!!
Forrás: PostgreSQL.org

28.12.) Fetchmail levelezőrendszer

28.12.a.) Levélkiszolgáló telepítése

28.13.) Hálózati fájlmegosztás