Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar
BÁNYÁSZ GÁBOR DÉVAI ISTVÁN KARDOS GERGELY SZÁNTAI ISTVÁN
LINUX ALAPÚ HÁLÓZATOK Jegyzet v1.0
Budapest, 2012. május 10.
Tartalomjegyzék 1. Bevezetés
1
1.1. A Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.1.1. A szabad szoftver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.1.1.1. A Linux licence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2. A Linux rendszermag áttekintése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2.1. A Linux-kernel felépítése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3. Belépés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.4. Virtuális konzolok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.5. Grafikus felület . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.6. A jelszó beállítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.7. A legfontosabb parancs: man . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.8. A parancsformátum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.9. Gyakran használt parancsok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.10. Szövegszerkesztők . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.10.1. A vi szövegszerkesztő . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.10.2. A nano szövegszerkesztő . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.10.3. A joe szövegszerkesztő . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2. Állományok, állományrendszerek
13
2.1. Állomány típusok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2. Hierarchikus állományrendszer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3. A könyvtárfa áttekintése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. Linkek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5. Az eszközállományok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.6. Fájlrendszer típusok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.6.1. Minix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.6.2. Extended filesystems (ext, ext2, ext3, ext4) . . . . . . . . . . . . . . . . . . . . . . 18 2.6.3. Journaling állományrendszerek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.6.4. Más operációs rendszerek támogatása . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.6.5. A CD állományrendszere: iso9660 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.6.6. Hálózati állományrendszerek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.6.7. Az állományrendszer paraméter használata . . . . . . . . . . . . . . . . . . . . . . 21 2.6.8. Fájlrendszer létrehozása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.7. Partíciók létrehozása, kezelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.8. Állományrendszerek összekapcsolása és leválasztása . . . . . . . . . . . . . . . . . . . . . . 22 2.9. Partíció létrehozása, formázása, felcsatolása . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.10. A Linux állományrendszer megjavítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.11. Rendszerpartíciók paramétereinek megadása . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.12. Ext2 állományrendszer konverziója ext3-ra . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
ii
2.13. A swap
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.13.1. Swap partíció hozzáadása a rendszerhez . . . . . . . . . . . . . . . . . . . . . . . . 27 2.13.2. Swap állomány hozzáadása a rendszerhez . . . . . . . . . . . . . . . . . . . . . . . 27 2.13.3. A swap eltávolítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3. Felhasználók adminisztrációja, quota, shell
29
3.1. Felhasználók adminisztrációja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.1.1. A felhasználói azonosítók . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.1.2. Felhasználók létrehozása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.1.3. Felhasználó letiltása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.1.4. Felhasználó törlése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.1.5. Csoportok adminisztrációja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.1.6. Az állományrendszer jogosultságai . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.1.6.1. A jogok megváltoztatása (szimbolikus jelekkel) . . . . . . . . . . . . . . . 34 3.1.6.2. A jogok állítása (oktális számokkal) . . . . . . . . . . . . . . . . . . . . . 35 3.1.6.3. Alapértelmezett állomány jogok . . . . . . . . . . . . . . . . . . . . . . . 36 3.1.7. Az ext2, ext3, etx4 állományrendszerek további jogosultságai . . . . . . . . . . . . 37 3.2. Quota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.2.1. A quota bekapcsolása az állományrendszerre . . . . . . . . . . . . . . . . . . . . . 38 3.2.2. A quota táblázatok létrehozása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.2.3. A quota rendszer bekapcsolása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.2.4. A quota értékek beállítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.2.5. A türelmi idő beállítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.3. A parancsértelmező (shell) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.3.1. Parancssor értelmezés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.3.2. A shell beépített parancsai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.3.3. Állománynév-helyettesítés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.3.4. Standard input/output átirányítás . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.3.5. Csővezeték . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.3.6. Parancshelyettesítés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.3.7. Parancssorozatok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.3.8. Szinkron és aszinkron folyamatok . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.3.9. Csoportosítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.3.10. A Bash shell további funkciói . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.3.10.1. Változók kezelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.3.10.2. Speciális változók . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.3.10.3. A shell indulási folyamata . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.3.10.4. Alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.3.10.5. Parancs history
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.10.6. Parancsállományok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.3.10.7. Beépített parancsok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 iii
3.3.10.8. Feltételek kiértékelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.3.10.9. Vezérlési szerkezetek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.3.10.9.1. If feltétel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.3.10.9.2. For ciklus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.3.10.9.3. While ciklus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.3.10.9.4. Until ciklus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.3.10.9.5. Case szerkezet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.3.10.10.Shell szkript példa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.3.10.11.Erőforrás kontroll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4. Segédprogramok, folyamatok kezelése, chroot, a rendszer indulása, automatizált programindítás, log
55
4.1. Segédprogramok és szűrők . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.1.1. A find parancs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.1.2. A head és tail parancsok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.1.3. A sort parancs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.1.4. A uniq parancs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.1.5. A cmp és diff parancsok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4.1.6. A patch parancs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.1.7. A grep parancs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 4.1.8. Egyszerű reguláris kifejezések . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.2. Folyamatok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.2.1. A folyamatok monitorozása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.2.2. Háttérfolyamatok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.2.3. Kommunikáció a folyamatokkal, megszüntetés . . . . . . . . . . . . . . . . . . . . . 64 4.2.4. Folyamat vezérlése a bash shellben . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.2.5. Prioritásállítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.3. Chroot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.4. A rendszer elindulása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.4.1. GRUB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.4.1.1. GRUB telepítése merevlemezre . . . . . . . . . . . . . . . . . . . . . . . . 67 4.4.1.2. GRUB konfigurációs állomány . . . . . . . . . . . . . . . . . . . . . . . . 68 4.4.1.3. GRUB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.4.2. Az inittab állomány . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.4.3. Upstart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.4.3.1. Az Upstart működése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.4.3.2. Upstart események . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.4.3.3. Upstart jobok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.4.3.4. Kompatibilitás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.4.4. Leállítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.4.5. Újraindítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 iv
4.4.6. „Elfelejtettük a jelszót, nem probléma, törjük fel!”
. . . . . . . . . . . . . . . . . . 79
4.4.7. A futásszintek szolgáltatásai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.4.7.1. Kezelés kézzel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.4.7.2. A chkconfig program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.4.7.3. A sysv-rc-conf program . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.5. Automatizált programindítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.5.1. Cron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.5.1.1. Konfiguráció . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.5.1.2. Felhasználók lehetőségei . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4.5.1.3. A hozzáférés szabályozása . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4.5.1.4. A módosítások hatályba lépése . . . . . . . . . . . . . . . . . . . . . . . . 84 4.5.2. At . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4.5.2.1. A hozzáférés szabályozása . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4.5.3. Batch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4.6. Log mechanizmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4.6.1. Rsyslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.6.2. Log állományok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 4.6.3. Logrotate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5. Csomagkezelés, X Window System, asztali környezetek
89
5.1. RPM csomagkezelés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.1.1. Az rpm használata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.1.1.1. Csomagok telepítése és eltávolítása . . . . . . . . . . . . . . . . . . . . . . 89 5.1.1.1.1.
Telepítés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.1.1.1.2.
Eltávolítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.1.1.2. Frissítés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.1.1.3. Információk lekérdezése . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.1.2. Csomagok fordítása, készítése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.1.2.1. Forrás csomag lefordítása . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.1.2.2. Bináris RPM készítése forrás RPM-ből . . . . . . . . . . . . . . . . . . . 94 5.1.2.3. A spec fájl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.1.2.3.1.
A header szekció . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.1.2.3.2.
Prep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.1.2.3.3.
A build szekció . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.1.2.3.4.
Az install szekció . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.1.2.3.5.
A clean szekció . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.1.2.3.6.
Opcionális telepítés, eltávolítás előtti és utáni szkriptek . . . . . 97
5.1.2.3.7.
A files szekció . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.1.2.3.8.
A changelog szekció . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.1.2.4. Bináris RPM készítése tgz forrásból . . . . . . . . . . . . . . . . . . . . . 98 5.1.3. A yum használata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 v
5.1.3.1. Csomagok telepítése és eltávolítása . . . . . . . . . . . . . . . . . . . . . . 99 5.1.3.1.1.
Telepítés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.1.3.1.2.
Eltávolítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.1.3.2. Frissítés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.1.3.3. A yum egyéb funkciói . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.1.3.4. Csomaginformációk lekérdezése, keresés . . . . . . . . . . . . . . . . . . . 101 5.2. Debian csomagkezelés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.2.1. A dpkg használata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.2.1.1. Csomagok telepítése és eltávolítása . . . . . . . . . . . . . . . . . . . . . . 103 5.2.1.1.1.
Telepítés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.2.1.1.2.
Eltávolítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.2.1.2. Frissítés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.2.1.3. Csomaginformációk lekérése
. . . . . . . . . . . . . . . . . . . . . . . . . 106
5.2.2. Bináris Debian csomag készítése . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 5.2.2.1. Csomagszerkezet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 5.2.2.1.1.
A debian-binary fájl . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.2.2.1.2.
data.tar.gz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.2.2.1.3.
A control.tar.gz fájl . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.2.2.1.4.
A Debian control fájl . . . . . . . . . . . . . . . . . . . . . . . . 110
5.2.2.2. A csomag összeállítása és ellenőrzése . . . . . . . . . . . . . . . . . . . . . 112 5.2.2.2.1.
A helyi debian könyvtár előkészítése . . . . . . . . . . . . . . . . 112
5.2.2.2.2.
A szükséges fájlok . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.2.2.2.3.
A fájlok elhelyezése a helyi debian fa-struktúrában . . . . . . . . 112
5.2.2.2.4.
A Debian csomag elkészítése és ellenőrzése . . . . . . . . . . . . 113
5.2.3. Az apt használata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.2.3.1. Csomagok telepítése és eltávolítása . . . . . . . . . . . . . . . . . . . . . . 114 5.2.3.1.1.
Telepítés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.2.3.1.2.
Eltávolítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.2.3.2. Frissítés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 5.2.3.3. Az apt-get egyéb funkciói . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 5.2.3.4. Csomaginformációk lekérdezése, keresés . . . . . . . . . . . . . . . . . . . 116 5.2.3.4.1.
Az apt-file program . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.3. Átjárás az RPM és a Debian csomagkezelés között . . . . . . . . . . . . . . . . . . . . . . 119 5.4. X Window System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 5.4.1. X Window architektúra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 5.4.2. Ablakkezelők . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 5.4.3. Kliens alkalmazások . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 5.4.4. Asztali környezetek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 5.4.5. Az X elindítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 5.4.5.1. A startx működése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
vi
5.4.5.2. Az X session indulása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 5.4.5.3. Az xorg.conf fájl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 5.4.6. Kliens futtatása távoli gépen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 5.4.6.1. Jogosultság beállítása az X szerveren . . . . . . . . . . . . . . . . . . . . 124 5.4.6.1.1.
Xhost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.4.6.1.2.
Xauth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.4.6.2. Az X kliens kimenetének átirányítása . . . . . . . . . . . . . . . . . . . . 125 5.4.6.3. SSH X forward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 5.4.7. Grafikus konfigurációs eszközök . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 5.4.7.1. A felhasználók adminisztrálása . . . . . . . . . . . . . . . . . . . . . . . . 126 5.4.7.2. A folyamatok monitorozása . . . . . . . . . . . . . . . . . . . . . . . . . . 126 5.4.7.3. Futásszintek beállításai . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 5.4.7.4. Log állományok tanulmányozása . . . . . . . . . . . . . . . . . . . . . . . 128 5.4.7.5. Rendszer csomagok telepítése és eltávolítása . . . . . . . . . . . . . . . . 129 6. Hálózat-konfiguráció, SSH, FTP, NFS, Samba 6.1. Röviden a TCP/IP hálózatokról
131
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.1.1. Kommunikáció a hálózaton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 6.1.1.1. Lokális hálózat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 6.1.1.2. Globális hálózat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 6.1.2. A TCP/IP protokoll ismertetése . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 6.1.2.1. Host to Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 6.1.2.2. Internetwork Layer
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.1.2.2.1.
Internet Potocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.1.2.2.2.
Adress Resolution Protocol . . . . . . . . . . . . . . . . . . . . . 135
6.1.2.2.3.
Internet Control Message Protocol . . . . . . . . . . . . . . . . . 135
6.1.2.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 6.1.2.3.1.
Transmission Control Protocol . . . . . . . . . . . . . . . . . . . 135
6.1.2.3.2.
User Datagram Protocol . . . . . . . . . . . . . . . . . . . . . . 135
6.1.2.4. Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 6.2. Hálózati eszközök . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 6.3. A hálózati interfészek konfigurálása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 6.3.1. Red Hat konfigurációs szkriptek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 6.3.2. Az /etc/network/interfaces állomány . . . . . . . . . . . . . . . . . . . . . . . . . . 138 6.3.3. Az Ethernet interfész . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 6.3.4. Az Alias interfész . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 6.3.5. Egyéb interfészek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 6.3.6. Interfész kontroll szkriptek
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.3.7. Grafikus konfiguráció . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 6.4. Útválasztás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 6.5. Névleképezés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 vii
6.6. A Network Configuration program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 6.7. Hálózati szolgáltatások automatikus indítása . . . . . . . . . . . . . . . . . . . . . . . . . 143 6.8. TCP Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 6.9. Távoli shell alapú elérés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 6.10. Állományok átvitele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 6.11. Állományok megosztása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 6.11.1. FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 6.11.2. NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 6.12. Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 6.12.1. A működő szerver vizsgálata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 6.12.2. A konfiguráció . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 6.12.2.1. Alap szerver beállítások . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 6.12.2.2. Autentikációs beállítások . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 6.12.2.3. Felhasználók importálása az smbpasswd állományba . . . . . . . . . . . . 155 6.12.2.4. Megosztások . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 6.12.2.5. Konfiguráció ellenőrzése . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 6.12.3. Grafikus konfigurálás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 7. Webszerver, PHP, Drupal, AWStats
159
7.1. Webszerver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 7.1.1. Globális beállítások
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
7.1.1.1. Port és interfész használat . . . . . . . . . . . . . . . . . . . . . . . . . . 160 7.1.1.2. Server-Pool beállítások . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 7.1.1.3. Dynamic Shared Object (DSO) . . . . . . . . . . . . . . . . . . . . . . . . 161 7.1.2. A fő szerver szekció
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
7.1.2.1. Jogosultság beállítások . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 7.1.2.2. Adminisztratív cím . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 7.1.2.3. A szerver azonosítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 7.1.2.4. A dokumentum könyvtár . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 7.1.2.5. Könyvtár beállítások . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 7.1.2.6. Felhasználói könyvtárak . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 7.1.2.7. Az alapértelmezett index állomány . . . . . . . . . . . . . . . . . . . . . . 163 7.1.2.8. A .htaccess állomány . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 7.1.2.9. MIME típus beállítások . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 7.1.2.9.1.
Az alapértelmezett MIME típus . . . . . . . . . . . . . . . . . . 164
7.1.2.10. Logolás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 7.1.2.11. A dokumentum-könyvtáron kívüli könyvtárak elérése . . . . . . . . . . . 164 7.1.2.12. Átirányítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 7.1.2.13. A szerver által generált index lista . . . . . . . . . . . . . . . . . . . . . . 164 7.1.2.14. Nyelvi beállítások . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 7.1.2.15. További kiterjesztés leképezések . . . . . . . . . . . . . . . . . . . . . . . 165 viii
7.1.2.16. Hibajelzések . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 7.1.2.17. Egyéni browser beállítások . . . . . . . . . . . . . . . . . . . . . . . . . . 165 7.1.2.18. Apache mint proxy szerver . . . . . . . . . . . . . . . . . . . . . . . . . . 165 7.1.3. Virtuális szerverek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 7.1.4. Védett könyvtár létrehozása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 7.1.5. SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 7.1.6. Grafikus konfigurációs eszköz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 7.2. A PHP beállítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 7.2.1. A mod_rewrite modul használata PHP esetén . . . . . . . . . . . . . . . . . . . . 169 7.2.2. A phpMyAdmin telepítése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 7.3. A Drupal tartalomkezelő rendszer telepítése . . . . . . . . . . . . . . . . . . . . . . . . . . 171 7.4. Az AWStats statisztikai programcsomag telepítése . . . . . . . . . . . . . . . . . . . . . . 171 8. Levelezés (protokollok, levelezőszerverek, spamszűrés)
175
8.1. SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 8.2. POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 8.3. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 8.4. A levelezőszerver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 8.4.1. Sendmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 8.4.2. Postfix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 8.4.3. Dovecot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 8.5. Procmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 8.6. Spamszűrés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 8.7. Squirrelmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 9. Hálózatdiagnosztika, hálózatok feltörése, Certificate Authority, snort
193
9.1. Hálózatdiagnosztika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 9.1.1. Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 9.1.2. Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 9.1.3. LFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 9.1.4. Netstat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 9.1.5. Nmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 9.1.6. Tcpdump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 9.1.7. Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 9.1.7.1. Egyszerű monitorozás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 9.1.7.2. A TCP kommunikáció követése . . . . . . . . . . . . . . . . . . . . . . . . 198 9.1.8. Whois . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 9.2. Hálózatok feltörése, avagy mennyire nyilvános a kommunikációnk . . . . . . . . . . . . . . 199 9.2.1. ARP poisoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 9.2.2. Ettercap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 9.2.3. Aircrack-ng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
ix
9.2.3.1. Az aircrack-ng alapszintű használata . . . . . . . . . . . . . . . . . . . . . 203 9.2.3.2. SSID rejtése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 9.2.3.3. MAC szűrés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 9.2.3.4. WEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 9.2.3.5. WPA/WPA2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 9.2.3.6. Összegzés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 9.3. Certificate Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 9.3.1. A valós élet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 9.3.2. OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 9.3.3. Az openssl.cnf állomány . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 9.3.4. A CA segédprogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 9.3.5. A Certificate Authority létrehozása . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 9.3.6. A tanúsítvány lecsupaszítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 9.3.7. A szöveges információk megtekintése . . . . . . . . . . . . . . . . . . . . . . . . . . 211 9.3.8. Tanúsítványok létrehozása és aláírása . . . . . . . . . . . . . . . . . . . . . . . . . . 211 9.3.9. A jelszó eltávolítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 9.3.10. A tanúsítvány visszavonása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 9.3.11. A tanúsítvány megújítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 10.Tűzfalak
213
11.Naplófeldolgozás
214
12.PAM, DNS, DHCP
215
12.1. PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 12.1.1. Konfigurációs állományok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 12.1.2. A konfigurációs állományok szintaktikája . . . . . . . . . . . . . . . . . . . . . . . 215 12.1.3. Példa konfigurációs állomány . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 12.1.4. Konzol jogosultságok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 12.1.5. További beállítások . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 12.2. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 12.2.1. A DNS feladata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 12.2.2. Helyi feloldás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 12.2.3. A névfeloldás folyamata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 12.2.4. BIND konfiguráció . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 12.2.5. A reverse DNS beállítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 12.2.6. BIND futtatása chroot környezetben . . . . . . . . . . . . . . . . . . . . . . . . . . 224 12.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 12.3.1. A DCHP feladata
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
12.3.2. DCHP konfiguráció . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 12.3.2.1. Dinamikus host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226 12.3.2.2. Statikus hoszt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 x
12.3.3. A dhcpd indítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 13.Verziókezelő rendszerek
228
13.1. CVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 13.2. Subversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 13.2.1. A Subversion beüzemelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 13.2.1.1. Szerver-beállítások . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 13.2.1.1.1. SVN tároló létrehozása, fájlok importálása . . . . . . . . . . . . 230 13.2.1.2. Hozzáférés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 13.2.1.2.1. Közvetlen hozzáférés . . . . . . . . . . . . . . . . . . . . . . . . . 230 13.2.1.2.2. Hozzáférés WebDAV protokollal . . . . . . . . . . . . . . . . . . 231 13.2.1.2.3. Hozzáférés SSL titkosított WebDAV protokollal . . . . . . . . . 232 13.2.1.2.4. Hozzáférés saját protokollal . . . . . . . . . . . . . . . . . . . . . 232 13.2.1.2.5. Hozzáférés SSL titkosított saját protokollal . . . . . . . . . . . . 233 13.3. Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 13.3.1. A Git beüzemelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 13.3.2. Új projekt hozzáadása a tárolóhoz . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 13.3.3. Az első projekt commitolása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 13.3.4. Felhasználók hozzáadása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236 13.3.5. Elérés böngészőből . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 13.3.6. Publikus tároló létrehozása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 13.3.7. A git daemon kezelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 13.4. SVN vagy Git? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
xi
1.
Bevezetés
1.1.
A Linux
A Linux szónak több jelentése is van. Technikailag pontos definíciója a következő: A Linux szabadon terjeszthető, Unix-szerű operációs rendszer-kernel. A legtöbb ember a Linux szó hallatán azonban a Linuxkernelen alapuló teljes operációs rendszerre gondol. Így általában az alábbiakat értjük rajta: A Linux szabadon terjeszthető, Unix-szerű operációs rendszer, amely tartalmazza a kernelt, a rendszereszközöket, programokat, és a teljes fejlesztői környezetet. A továbbiakban mi is a második jelentését vesszük alapul, vagyis a Linuxot mint operációs rendszer mutatjuk be. A Linux kiváló, ingyenes platformot ad a programok fejlesztéséhez. Az alapvető fejlesztőeszközök a rendszer részét képezik. Unix-szerűségéből adódóan, programjainkat könnyen átvihetjük majdnem minden Unix- és Unix-szerű rendszerre. További előnyei: • a teljes operációs rendszer forráskódja szabadon hozzáférhető, használható, vizsgálható és szükség esetén módosítható; • ebbe a körbe bele tartozik a kernel is, így komolyabb, a kernel módosítását igénylő problémák megoldására is lehetőségünk nyílik; • mivel a stabil és a fejlesztői kernel vonala jól elkülönül, ezért célrendszerek készítésénél szabadon választhatunk, hogy stabil, vagy a legújabb fejlesztéseket tartalmazó rendszerre van szükségünk; • a Linux fejlesztése nem profitorientált fejlesztők kezében van, így fejlődésekor csak technikai szempontok döntenek, marketinghatások nem befolyásolják; • a Linux-felhasználók és -fejlesztők tábora széles és lelkes. Ennek következtében az interneten nagy mennyiségű segítség és dokumentáció lelhető fel. A Linux története 1991-re nyúlik vissza. Linus Torvalds a helsinki egyetem diákja ekkor kezdett bele a projektbe. Eredetileg az Andrew S. Tanenbaum által tanulmányi célokra készített Minix operációs rendszerét használta a gépén. A Minix az operációs rendszerek működését, felépítését volt hivatott bemutatni, ezért egyszerűnek, könnyen értelmezhetőnek kellett maradnia. Emiatt nem tudta kielégíteni Linus igényeit, aki ezért belevágott egy saját, Unix-szerű operációs rendszer fejlesztésébe. Eredetileg a Linux-kernelt gyenge licenccel látta el, amely csak annyi korlátozást tartalmazott, hogy a Linux-kernel nem használható fel üzleti célokra. Azonban ezt rövidesen GPL-re cserélte. A GPL feltételei lehetővé tették más fejlesztőknek is, hogy csatlakozzanak a projekthez, és segítsék munkáját. A GNU C-library projektje lehetővé tette alkalmazások fejlesztését is a rendszerre. Gyorsan követték ezeket a gcc, bash, Emacs programok portolt változatai. Így az 1992-es év elején már aránylag könnyen lehetett telepíteni a Linux 0.95-ös verzióját a legtöbb Intel-gépen. A Linux-projekt már a kezdetektől szorosan összefonódott a GNU-projekttel. A GNU-projekt forráskódjai fontosak voltak a Linux-közösség számára, rendszerük felépítéséhez. A rendszer további jelentős részletei a kaliforniai Berkley egyetem nyílt Unix forráskódjaiból, illetve az X konzorciumtól származnak. 1
A különböző Unix-fajták egységesített programozói felületének létrehozására született meg a C nyelven definiált POSIX (Portable Operating System Interface) szabvány. A szó végén az X a Unix világra utal, amit a Linux implementálásakor is messzemenőkig figyelembe vettek. Ahogy a Linux fejlődött, egyre többen foglalkoztak a telepítést és a használatot megkönnyítő disztribúciók készítésével. A Slackware volt az első olyan csomag, amelyet már komolyabb háttértudás nélkül is lehetett telepíteni és használni. Megszületése nagyban elősegítette a Linux terjedését, népszerűségének növekedését. A Red Hat a társaihoz képest viszonylag későn született, de napjaink egyik legnépszerűbb üzleti disztribúciója lett. Fejlesztőinek célja egy stabil, biztonságos, könnyen telepíthető és használható csomag készítése volt. A Red Hat cég termékeihez támogatást, tanfolyamokat, könyveket is nyújt. A fentieken kívül, megemlítjük még a Debiant, valamint a magyar nyelvű és magyarok által gondozott UHU Linuxot is. A Linux-disztribúciók általában a fejlesztői könyvtárakat, fordítókat, értelmezőket, parancsértelmezőket, alkalmazásokat, segédprogramokat, konfigurációs eszközöket és még sok más komponenst is tartalmaznak a Linux-kernel mellett. Napjainkban már sok Linux-disztribúcióval találkozhatunk. Mindegyiknek megvannak az előnyei, hátrányai, hívői. Azonban mindegyik ugyanazt a Linux-kernelt és ugyanazokat a fejlesztői alapkönyvtárakat tartalmazza. [1] 1.1.1.
A szabad szoftver
A számítástechnika hajnalán a cégek kis jelentőséget tulajdonítottak a szoftvereknek. Első sorban a hardvert szándékozták eladni, a szoftvereket csak járulékosan adták hozzá, üzleti jelentőséget nem tulajdonítottak neki. Ez azt eredményezte, hogy a forráskódok, algoritmusok szabadon terjedhettek. Azonban ez az időszak nem tartott sokáig, a gyártók hamar rájöttek a szoftverben rejlő üzleti lehetőségekre, és ezzel beköszöntött a zárt forráskódú programok korszaka. Az intellektuális eredményeket a cégek levédik, és szigorúan őrzik. Ezek a változások nem nyerték el Richard Stallman tetszését. Ennek hatására megalapította az FSF (Free Software Foundation) nevű szervezetet Cambridge-ben. Az FSF célja szabadon terjeszthető szoftverek fejlesztése. A kifejezésben a free szabadságot jelent, nem ingyenességet. Hite szerint a szoftvernek és a hozzátartozó dokumentációnak, forráskódnak szabadon hozzáférhetőnek és terjeszthetőnek kell lennie. Ennek elősegítésére megalkotta (némi segítséggel) a GPL-t (General Public License, magyarul általános felhasználói licenc). 1.1.1.1.
A Linux licence
A Linux kernelt a 2. verziójú GNU General Public License szerint licencelik. Ezt a licencet nem is akarják lecserélni a 2007. júniusában megszületett GNU GPLv3-ra, de nem is nagyon lehetne, mivel a Linux kernel készítésében eddig több száz ember közreműködött, akiknek a beleegyezése szükséges a licencváltáshoz, ami ezért ma már gyakorlatilag kivitelezhetetlen. Az alábbiakban a GPLv2 licenc magyar nyelvű fordításának egy részlete olvasható. [2]
2
1. A program forráskódja módosítás nélkül másolható és bármely adathordozón terjeszthető, feltéve, hogy minden egyes példányon pontosan szerepel a megfelelő szerzői jogi megjegyzés, illetve a garanciavállalás elutasítása; érintetlenül kell hagyni minden erre a szabályozásra és a garancia teljes hiányára utaló szöveget és a licencdokumentumot is el kell juttatni mindazokhoz, akik a programot kapják. Felszámítható díj a másolat fizikai továbbítása fejében, illetve ellenszolgáltatás fejében a programhoz garanciális támogatás is biztosítható. 2. A program vagy annak egy része módosítható, így a programon alapuló munka jön létre. A módosítás ezután az 1. szakaszban adott feltételek szerint tovább terjeszthető, ha az alábbi feltételek is teljesülnek: (a) A módosított fájlokat el kell látni olyan megjegyzéssel, amely feltünteti a módosítást végző nevét és a módosítások dátumát. (b) Minden olyan munkát, amely részben vagy egészben tartalmazza a programot vagy a programon alapul, olyan szabályokkal kell kiadni vagy terjeszteni, hogy annak használati joga harmadik személy részére licencdíjmentesen hozzáférhető legyen, a jelen dokumentumban található feltételeknek megfelelően. (c) Ha a módosított program interaktívan olvassa a parancsokat futás közben, akkor úgy kell elkészíteni, hogy a megszokott módon történő indításkor megjelenítsen egy üzenetet a megfelelő szerzői jogi megjegyzéssel és a garancia hiányára utaló közléssel (vagy éppen azzal az információval, hogy miként juthat valaki garanciához), illetve azzal az információval, hogy bárki terjesztheti a programot a jelen feltételeknek megfelelően, és arra is utalást kell tenni, hogy a felhasználó miként tekintheti meg a licenc egy példányát. (Kivétel: ha a program interaktív ugyan, de nem jelenít meg hasonló üzenetet, akkor a programon alapuló munkának sem kell ezt tennie.) Ezek a feltételek a módosított munkára, mint egészre vonatkoznak. Ha a munka azonosítható részei nem a programon alapulnak és független munkákként elkülönülten azonosíthatók, akkor ez a szabályozás nem vonatkozik ezekre a részekre, ha azok külön munkaként kerülnek terjesztésre. Viszont, ha ugyanez a rész az egész részeként kerül terjesztésre, amely a programon alapuló munka, akkor az egész terjesztése csak a jelen dokumentum alapján lehetséges, amely ebben az esetben a jogokat minden egyes felhasználó számára kiterjeszti az egészre tekintet nélkül arra, hogy melyik részt ki írta. E szövegrésznek tehát nem az a célja, hogy mások jogait elvegye vagy korlátozza a kizárólag saját maga által írt munkákra; a cél az, hogy a jogok gyakorlása szabályozva legyen a programon alapuló illetve a gyűjteményes munkák terjesztése esetében. Ezenkívül más munkáknak, amelyek nem a programon alapulnak, a programmal (vagy a programon alapuló munkával) közös adathordozón vagy adattárolón szerepeltetése nem jelenti a jelen szabályok érvényességét azokra is.
3
3. A program (vagy a programon alapuló munka a 2. szakasznak megfelelően) másolható és terjeszthető tárgykódú vagy végrehajtható kódú formájában az 1. és 2. szakaszban foglaltak szerint, amennyiben az alábbi feltételek is teljesülnek: (a) a teljes, gép által értelmezhető forráskód kíséri az anyagot, amelynek terjesztése az 1. és 2. szakaszban foglaltak szerint történik, jellemzően szoftverterjesztésre használt adathordozón; vagy, (b) legalább három évre szólóan írásban vállalja, hogy bármely külső személynek rendelkezésre áll a teljes gép által értelmezhető forráskód, a fizikai továbbítást fedező összegnél nem nagyobb díjért az 1. és 2. szakaszban foglaltak szerint szoftverterjesztésre használt adathordozón; vagy, (c) a megfelelő forráskód terjesztésére vonatkozóan megkapott tájékoztatás kíséri az anyagot. (Ez az alternatíva csak nem kereskedelmi terjesztés esetén alkalmazható abban az esetben, ha a terjesztő a programhoz a tárgykódú vagy forráskódú formájában jutott hozzá az ajánlattal együtt a fenti b. cikkelynek megfelelően.) Egy munka forráskódja a munkának azt a formáját jelenti, amelyben a módosításokat elsődlegesen végezni szokás. Egy végrehajtható program esetében a teljes forráskód a tartalmazott összes modul forráskódját jelenti, továbbá a kapcsolódó felületdefiníciós fájlokat és a fordítást vezérlő parancsfájlokat. Egy speciális kivételként a forráskódnak nem kell tartalmaznia normál esetben a végrehajtható kód futtatására szolgáló operációs rendszer főbb részeiként (kernel, fordítóprogram stb.) terjesztett részeit (forrás vagy bináris formában), kivéve, ha a komponens maga a végrehajtható állományt kíséri. Ha a végrehajtható program vagy tárgykód terjesztése a forráskód hozzáférését egy megadott helyen biztosító írásban vállalja, akkor ez egyenértékű a forráskód terjesztésével, bár másoknak nem kell a forrást lemásolniuk a tárgykóddal együtt.
1.2.
A Linux rendszermag áttekintése
Ebben a fejezetben a Linux-kernel egyes részeivel ismerkedünk meg. A következőkben leírtak elsajátítása nem elengedhetetlen a jegyzet további fejezeteinek megértéséhez, azonban megvilágítja, hogy mi zajlik le a programok futása közben a rendszer belső magjában, ezáltal hasznos háttérinformációkat szolgáltathat a fejlesztők és a rendszeradminisztrátorok számára. 1.2.1.
A Linux-kernel felépítése
Egy operációs rendszer magjának strukturális felépítésénél két alapvető választásunk van. Választhatunk a mikrokernel és monolitikus kernel struktúra közül. A mikrokernel struktúrában a kernelt több különálló, kernel módban futó processz alkotja, amelyek egymással kommunikálnak. Az igazi kernel csak a legszükségesebb funkciókat implementálja, úgymint a processzek közötti kommunikáció és a memóriakezelés. Ezek segítségével már megvalósítható a többi modul, és felépíthető a kernel. A mikrokernel egyik előnye a flexibilitása, az egyes modulok egymástól elkülönülten dolgoznak, könnyen lecserélhetőek akár menet közben is. Ebből adódik a másik előnye, hogy 4
csak az éppen szükséges kernelmodulokat kell a memóriában tartani. Hátránya, hogy az egyes modulok jól meghatározott interfészekkel kapcsolódnak, ezáltal lehetetlen bármilyen optimalizáció a modulok között. A monolitikus kernel a mikrokernellel szemben egyetlen nagy program, amely minden funkciót tartalmaz. Habár egyes részeit modulokra oszthatjuk, futás közben továbbra is csak egy nagy program. Ebből következően mikrokernelnél látható jól definiált kommunikációs vonalak helyett a kernel egyes részei közvetlenül hívhatják egymást. Így a monolitikus kernel a mikrokernellel szemben gyorsabb, jobban optimalizálható. Mint láthatjuk a mikrokernel képviseli a flexibilitást, a monolitikus kernel pedig a hatékonyságot. Az operációs rendszerek magjának jelenlegi fejlődési irányvonala a mikrokernelek irányába mutat, a fejlesztők általában ezt részesítik előnyben (pl. Microsoft Windows NT rendszerek), ezzel szemben a Linux a monolitikus irányvonalat képviseli. Ennek történelmi okai vannak. A kezdeti lépések a monolitikus kernel esetében jóval egyszerűbbek, nem igénylik a rendszer alapos megtervezését, mint mikrokernel struktúra esetén, így Linus számára a monolitikus kernel célszerűbb választásnak bizonyult. A másik ok, hogy a Linux először az aránylag lassú i386-os architektúrán jelent meg, ezért fontos volt a rendszer optimalizálása a megfelelő teljesítmény érdekében. A Linux-kernel amellett, hogy monolitikus, kellően moduláris felépítésű, hogy a fejlesztése, a változtatások ne okozzanak problémát. Továbbá a betölthető modulok révén lehetőségünk nyílik arra, hogy a kernel egyes részeit futás közben betöltsük, esetleg lecseréljük. Így a Linux kernel nem tisztán monolitikus, hanem többé-kevésbé tartalmazza a mikrokernelek előnyös vonásait is. A fejlesztők ezért nem látták szükségesnek, hogy az idők során valódi mikrokernel-struktúrára alakítsák át a rendszer magját. A struktúrák alapjainak megismerése után nézzük meg, milyen részekre oszthatjuk fel a Linux kernelt. (Az 1. ábrán látható felosztás vázlatos, a könnyebb megérhetőség érdekében nem tér ki a rendszer minden részletére.) A felhasználói programok a rendszerhívásokon keresztül kérhetik a kerneltől a kívánt szolgáltatásokat. Ezeket a rendszerhívásokat a programok általában a rendszerkönyvtárak segítségével érik el. A fájlrendszerek magasabb színtű absztrakciót nyújtanak a perifériák kezelésére. Ennek az alrendszernek a segítségével kezelhetünk állományokat, könyvtárakat az egyes eszközökön, de a fájlkezelés műveleteivel férhetünk hozzá például a soros portokhoz is. A hálózati réteg a különböző hálózati protokollok implementációját tartalmazza. A perifériakezelő alrendszer az eszközök alacsonyszintű kezelését valósítja meg. Hozzá tartozik a háttértárolók, I/O-eszközök, soros, párhuzamos és egyéb portok kezelése. A processzkezelő alrendszer több, a processzek kezelésével kapcsolatos funkciót valósít meg: • A Linux többfeladatos (multitask) rendszer, ami azt jelenti, hogy több processzt futtat párhuzamosan vagy majdnem párhuzamosan. Azt, hogy az egyes processzek mikor jussanak a processzorhoz, az ütemező dönti el. • A processzeknek általában szükségük van arra, hogy egymással kommunikáljanak. Ezt az IPC (Inter-process Communication, processzek közötti kommunikáció) alrendszer teszi lehetővé. • A fizikai memória kiosztását a processzek között a memóriakezelő alrendszer végzi el. [1]
5
Felhasználói processzek
Rendszerkönyvtárak Kernel
Rendszerhívások
Processzkezelés Fájlrendszerek
Ütemező Memóriakezelés
Hálózati réteg IPC
Perifériák kezelése
Hardver 1. ábra. A Linux kernel vázlatos felépítése
1.3.
Belépés
A szokásos bejelentkezés nem tér el a más rendszereknél is használt egyszerű felhasználónév, jelszó alapú azonosítástól. Azonban általában a Linux rendszerek egyszerre két felületet is nyújtanak a felhasználó felé. Egyrészt a szöveges, virtuális konzolokat, másrészt egy grafikus felületet (X Window System) 1 . Mivel a Linux nagymértékben konfigurálható, ezért az egyes rendszereknél a beállítások eltérhetnek. Mi a disztribúciók által általánosan használtakat tekintjük most át.
1.4.
Virtuális konzolok
A terminálok használata a korai időkre vezethető vissza. Eredetileg a Unix nagy számítógépek tipikus kezelői felületei a soros terminálok voltak, amelyek egyszerű karakterbevitelt, és a válaszkarakterek 1 A Linux rendszerek támogatják a hagyományos, soros portos terminálokat is, azonban a beágyazott rendszerek kivételével ezek használata manapság már nem tipikus.
6
megjelenítését tették lehetővé. Ez az idők folyamán fejlődött, és a terminál karakterek segítségével barátságosabb felületet nyújtottak. A személyi számítógépek, illetve a hálózatok fejlődése révén a soros terminálok használata háttérbe szorult, azonban egyszerűségük, uniformitásuk, elterjedtségük révén virtuális terminálokként tovább élnek. A Linux rendszerek a konzolon általában egyszerre hat ilyen virtuális terminált szimulálnak. Ezek között az Alt+F1–F6 gombokkal váltogathatunk. (Grafikus módról történő átváltás esetén: Ctrl+Alt+F1– F6.) Mindegyik egy teljes értékű szöveges terminál. Külön-külön mindegyiken bejelentkezhetünk valamely felhasználóként, és párhuzamosan dolgozhatunk. A később tárgyalt hálózaton keresztüli bejelentkezés esetén ugyanilyen szöveges terminál felületet kapunk. Egyes célrendszereknél grafikus kezelői felületet nem is telepítenek, mivel az csak az erőforrások pazarlása lenne. Ezért a szöveges felület kezelésének elsajátítása egy adminisztrátor számára alapvető.
Feladat 1. Lépjünk be! Red Hat Linux release 9 Kernel 2.4.18-14 on an i686 localhost login:
password: <jelszó> 2. Próbáljuk ki a következő parancsokat! pwd: Aktuális könyvtár. ls: Az aktuális könyvtár tartalma. echo: Kiírja a parancs után írt paramétert. exit: Kilépés.
1.5.
Grafikus felület
A rendszer indulásakor manapság elsőként a grafikus felülettel találjuk magunkat szembe. Azonban a virtuális konzolok használata után is visszakapcsolhatunk ide az Alt+F7 segítségével. Belépés után – más modern operációs rendszerekhez hasonlóan – egy grafikus ablakos felülettel találjuk magunkat szembe. Linuxnál az aktuális ablakozó rendszertől függően ez a felület változatos lehet. Jelenleg a legelterjedtebbek a Gnome és a KDE. Ezeknél a felületeknél, a más rendszereknél megszokott mechanizmusok ugyancsak használhatóak. Kisebb konfigurációk után a működést teljesen az általunk megszokott rendszerhez igazíthatjuk. A grafikus felületeken is elérhetjük a terminál emulációt. Ezt az xterm, kterm stb. programok teszik lehetővé. Így a terminál parancsokat itt is használhatjuk.
7
1.6.
A jelszó beállítása
Unix rendszereknél a jelszót a passwd parancs segítségével módosíthatjuk. A felhasználók csak a saját jelszavukat módosíthatják. Ehhez meg kell adniuk a régi jelszót (hogy egy magára hagyott terminálnál mások ne írhassák át), illetve kétszer az új jelszót.2 Rendszergazdaként bármelyik felhasználó jelszavát módosíthatjuk. Ilyenkor a passwd szintaxis a használatos.
1.7.
A legfontosabb parancs: man
A Linux (és Unix) elektronikus segítségnyújtó rendszerét a manuál oldalak adják. Ezeket az oldalakat a man paranccsal érhetjük el. Minden, a rendszerben található parancsról, segédprogramról, de még a függvényekről is az alábbi módon kérhetünk segítséget: man <parancs> Magáról a man parancsról is kaphatunk információt az alábbi módon: man man A leírások nyolc fejezetre (kötetre) oszlanak: 1. Általánosan használható programok 2. Rendszerhívások 3. Felhasználói szintű könyvtári függvények 4. Speciális állományok 5. Állományformátumok 6. Játékok 7. Különféle leírások 8. A rendszer karbantartásához szükséges információk Több fejezetben is lehetnek azonos nevű leírások. Például lehet azonos nevű program és rendszerfüggvény is. Ilyenkor az egyértelműség érdekében a fejezet számát is meg kell adni: man <parancs> Kulcsszavakra is kereshetünk: man -k
2 A rendszer a beállításától függően tesztelheti a megadott új jelszót és visszautasíthatja, ha túl „gyengének” találja. Linux alatt a legelterjedtebb a cracklib könyvtár alkalmazása, amely különböző szempontokból teszteli a megadott jelszót, illetve összehasonlítja a szóadatbázisával.
8
Feladat 1. Nézzük meg a man echo parancs által adott manuált! Vizsgáljuk meg milyen részekre oszlik! 2. Próbáljuk ki a man printf és a man 3 printf parancsokat! 3. Próbáljuk ki a man -k reset parancsot!
1.8.
A parancsformátum
A Linux parancsok a következő formátumot használják: parancs opció(k) argumentum(ok) A sor elején áll a parancs, vagy programnév. Ezt helyközzel elválasztva követik az opciók. Az opciók „-” jellel kezdődnek. Több opció is állhat egy „-” jel mögött, vagy megadhatjuk őket külön kötőjellel helyközökkel elválasztva. Időnként használatos a dupla kötőjel is. Az opciókat követik az argumentumok, szintén helyközzel elválasztva. Az argumentumok száma és sorrendje a parancstól függ. Például: ls -l /tmp
1.9.
Gyakran használt parancsok
Linux alatt a leggyakrabban a következő, egyszerű parancsokkal találkozhatunk. Fájlrendszer parancsok: cd: Könyvtárváltás. cmp: Bináris állományok összehasonlítása. cp: Állományok másolása. dd: Állományok konvertálása és másolása. diff: Szöveges állományok összehasonlítása. du: Lemezhasználat összegzése. find: Állományok keresése. ls: Könyvtár tartalmának listázása. mkdir: Új könyvtár létrehozása. mv: Állományok átnevezése vagy mozgatása. pwd: A munkakönyvtár elérési útjának kiírása.
9
rm: Állományok törlése. rmdir: Könyvtárak törlése. Szöveges állományok megtekintése: cat: Állományok kiírása, összefűzése, esetleg létrehozása. less: Állományok megjelenítése. (Görgethetjük, lapozhatjuk az állományt, és kereshetünk is benne.) more: Egyszerű program, amely a szöveges állományt oldalakra tördelve jeleníti meg.
1.10.
Szövegszerkesztők
A Linux története során leginkább az ebben a fejezetben tárgyalt eszközök terjedtek el. 1.10.1.
A vi szövegszerkesztő
A vi egy egyszerű szövegszerkesztő. Kezelését leginkább a gépelni tudók igényeihez alakították. A parancskészletét úgy állították össze, hogy a lehető legkevesebb kézmozgással használható legyen. Azonban egy tapasztalatlan felhasználó számára kezelése meglehetősen bonyolult lehet, ezért népszerűsége az utóbbi időben erősen megcsappant. 1.10.2.
A nano szövegszerkesztő
A nano egy egyszerű képernyő-orientált szövegszerkesztő. A legtöbb Linux rendszeren megtalálható. A nano a Pine levelező csomag részeként elterjedt pico leváltására született, ugyanis a pico lincence nem engedélyezte a módosított kód terjesztését. Elterjedten használják a kisebb szövegek gyors módosítására. Komolyabb feladatokra nem ajánlott, habár rendelkezik kódkiemelés funkcióval is. Ezekben az esetekben alkalmasabb a következő részben tárgyalt joe vagy egy a feladatnak megfelelően specializálódott szerkesztő. A program parancsai folyamatosan láthatók a képernyő alján (lásd 2. ábra). A „^” jel azt jelenti, hogy a billentyűt a Ctrl gomb nyomvatartása mellett kell használni. Ha ez esetleg a terminál típusa miatt nem működne, akkor a dupla Esc gombnyomást is alkalmazhatjuk helyette. Főbb funkciói és parancsai: Keresés: A keresés nem case szenzitív, valamint az aktuális kurzor pozíciótól kezdődik. Blokk „cut and paste”: Blokk műveleteket a kijelölés (Ctrl+^), a delete (Ctrl+K), és undelete (Ctrl+U) parancsokkal végezhetünk. Kreatív használat esetén mozgathatunk, másolhatunk, vagy törölhetünk részeket. Helyesírás-ellenőrző: A SPELL környezeti változóban, vagy programindításkor az -s kapcsoló után megadott helyesírás-ellenőrző programot használja.
10
Billentyűkombináció
Parancs
Ctrl+G
Segítség
Ctrl+X
Kilépés (módosítás esetén rákérdez a mentésre)
Ctrl+O
Az állomány kiírása
Ctrl+R
Állomány beolvasása és beillesztése a szerkesztett állományba
Ctrl+W
Szó keresése
Ctrl+Y
Ugrás az előző oldalra
Ctrl+V
Ugrás a övetkező oldalra
Ctrl+K
Szövegrész kivágása
Ctrl+U
Az utoljára kivágott rész beillesztése az adott kurzor pozícióra (többször is vissza lehet illeszteni, vagyis másolni lehet vele)
Ctrl+C
Aktuális kurzorpozíció kiírása
Ctrl+T
Helyesírás-ellenőrzés
1. táblázat. A nano leggyakoribb billentyűkombinációi
2. ábra. A nano felülete 1.10.3.
A joe szövegszerkesztő
A joe egy elterjedten használt szövegszerkesztő. Komolyabb feladatokra is alkalmas, mint a pico, vagy a nano. Egyszerre több állományt is megnyithatunk különböző opciókkal. Komolyságát a parancsok számából is láthatjuk, amelyek leírását a Ctrl+K+H gombokkal hozhatunk elő és tüntethetünk el. A „^” jel itt is azt jelenti, hogy a billentyűket a Ctrl gomb nyomva tartása mellett 11
kell használni. Mindazokra a funkciókra képes, amelyekre a pico és még sok továbbira is.
3. ábra. A joe felülete
Billentyűkombináció
Parancs
Ctrl+KF
Szöveg keresése
Ctrl+L
Ismételt keresés
Ctrl+KB
Blokk elejének kijelölése
Ctrl+KK
Blokk végének kijelölése
Ctrl+KM
Blokk mozgatása
Ctrl+KC
Blokk másolása
Ctrl+KY
Blokk törlése
Ctrl+Y
Sor törlése
Ctrl+_
Változtatás visszaléptetése
Ctrl+KD
Mentés
Ctrl+KX
Kilépés mentéssel
Ctrl+C
Kilépés mentés nélkül
2. táblázat. A joe leggyakoribb billentyűkombinációi
12
2. 2.1.
Állományok, állományrendszerek Állomány típusok
A Linux fájlrendszerében a következő állománytípusokat különböztetjük meg: Egyszerű állomány: Az egyszerű állományok azok, amelyekre először gondolnánk az állomány szó hallatán, vagyis bájtok sorozata, adatok, programok stb. A Linux minden állományt egyszerűen bájtok véletlenszerűen címezhető szekvenciájának tekinti. A rendszer eltakarja az állományt tároló fizikai eszköz tulajdonságait. Az állomány mérete az általa tartalmazott bájtok számával azonos. Könyvtár: A könyvtár speciális állomány, amely olyan információkat tartalmaz, amire a rendszernek szüksége van az állományok elérésére. A régi Unix rendszerekben az implementációk megengedték, hogy közvetlenül, állományként kezeljük a könyvtárakat, és megnézzük a tartalmukat. A Linux programok ezzel szemben hibával térnek vissza, ha ilyesmivel próbálkozunk. (Leszámítva a less parancsot, amely a könyvtárról egy olyan listát ad vissza, mintha az ls -l parancsot használtuk volna.) Eszközök: A legtöbb fizikai eszköz a Unix rendszereken, mint állomány jelenik meg. Ez azt jelenti, hogy ezekre az eszközökre állománynevekkel hivatkozhatunk, és ugyanúgy kezelhetjük őket, mint a közönséges állományokat. Írhatjuk, olvashatjuk, azonban ezeket a műveleteket természetesen az adott eszközre értelmezhető műveletre képezi le a kernel. (Például egy hangkártya eszköz olvasása a hang bedigitalizálását jelenti, az írása pedig a hang állomány lejátszását.) Két eszköztípust különböztetünk meg: blokk és karakter típusú eszközök. A blokkos eszköz állomány egy olyan hardver eszközt reprezentál, amelyet nem olvashatunk bájtonként, csak bájtok blokkjaiként. A blokkos eszközök leggyakrabban háttértárak, és fájlrendszert tartalmaznak. A karakteres eszköz bájtonként olvasható. A modemek, terminálok, printerek, hangkártyák és az egér mind-mind karakteres eszköz. Tradicionálisan az eszköz leíró speciális állományok a /dev könyvtárban találhatóak. Szimbolikus link: A szimbolikus link (röviden symlink ) egy speciális állomány, amely egy másik állomány elérési információit tartalmazza. Amikor megnyitjuk, a rendszer érzékeli, hogy szimbolikus link, kiolvassa az értékét, és megnyitja a hivatkozott állományt. Ezt a műveletet a szimbolikus link követésének hívjuk. A linkekre és használatukra még később visszatérünk. Csővezeték (pipe) és socket állományok: A csővezeték és a socket állományok a Unix két egyszerű IPC (Inter-process Communication, folyamatok közötti kommunikáció) mechanizmusát alkotják. Speciális állományok, amelyek egy kommunikációs csatornát írnak le a memóriában.
2.2.
Hierarchikus állományrendszer
A Linux operációs rendszernél egy kitüntetett alap állományrendszer van (root partíció), amely a merevlemezen helyezkedik el. Ez az állományrendszer tartalmazza a gyökér könyvtárat. A gyökér katalógus több alkatalógust tartalmaz, amelyek további alkatalógusokat tartalmaznak. Így egy hierarchikus fa struktúra 13
alakul ki. Az alkatalógusok nevének elválasztására a „/” jel szolgál. Az állománynevekre az egyetlen megkötés az, hogy a „/” jelet nem tartalmazhatják (illetve a különböző implementációknál eltérő megkötések vannak az állománynév hosszára). További merevlemez-partíciókat, és egyéb tárolóeszközöket (floppy, CD-ROM, pendrive-ok, memóriakártyák) hozzá kell fűznünk ehhez a fához (mount). Így a könyvtárfában az adott csomópont alatt található az eszköz tartalma.3 Ezzel a módszerrel a programok számára teljesen átlátszó módon oldható meg a könyvtárstruktúra széttördelése az egyes háttértárakra. A könyvtárakban a „.” karakterrel kezdődő bejegyzések rejtettek, vagyis az egyszerű könyvtárlistán nem szerepelnek. Teljes, a rejtett állományneveket is tartalmazó listát az ls -a paranccsal jeleníthetünk meg. Minden katalógus tartalmaz két speciális bejegyzést: „.”, „..”. A „.” magát az aktuális katalógust jelenti. A „..” az aktuális katalógus szülő katalógusát jelenti, vagyis azt a katalógust, amelyben az aktuális katalógust létrehozták. (A gyökérkatalógusnál a „.” és a „..” is a gyökérre mutat.)
2.3.
A könyvtárfa áttekintése
Ez a fejezet a Filesystems Hierarchy Standard (FHS) [3] – szabad – szabványon alapul, amely megkísérel létrehozni egy szabványt, amely szerint felépíthető egy könyvtárfa egy Linux-rendszerben. Egy ilyen szabványos felépítésnek az az előnye, hogy könnyebb lesz írni vagy áthozni programokat Linux alá, illetve adminisztrálni egy linuxos gépet, ha minden a szokásos helyén található. A gyökér fájlrendszernek általában kisméretűnek kell lennie, mivel a kritikus fájlokat tartalmazza, és egy kicsi, ritkán módosított fájlrendszernek jobb esélye van a sérülések elkerülésére. Egy sérült gyökér fájlrendszer általában azt jelenti, hogy a rendszer nem képes elindulni (boot), legfeljebb különleges segítséggel (például hajlékonylemezről), és ezt nem érdemes kockáztatni. A gyökérkönyvtár (/) általában nem tartalmaz fájlokat, legfeljebb a szabványos rendszerfájlt, melynek szokásos neve /vmlinuz. Minden más fájl a gyökérkönyvtár alkönyvtáraiban helyezkedik el: /bin: A rendszerindítás során szükséges parancsok, melyeket (a rendszerindítás után) a normál felhasználók is használhatnak. /boot: A rendszerbetöltő (bootstrap loader), például a GRUB által használt fájlok könyvtára. A rendszermag fájl (kernel image) is gyakran itt van, nem a gyökérkönyvtárban. Ha több rendszermag fájl is van, a könyvtár gyorsan megnőhet, ezért célszerű lehet külön fájlrendszerre rakni. /dev: Eszközmeghajtók. /etc: Gépspecifikus konfigurációs állományok. /home: A könyvtár tartalmazza a felhasználók home könyvtárait, azaz minden igazi adatot a rendszerben. A home könyvtárak külön fájlrendszerbe való elkülönítése megkönnyíti a biztonsági mentéseket; a többi részt általában nem, vagy csak ritkábban kell elmenteni, mivel ritkábban változnak. /lib: Megosztott könyvtárak a gyökér fájlrendszer programjaihoz. 3A
koncepció jelentősen eltér pl. a Microsoft Windowsnál megszokott címkék használatától, ahol az egyes eszközöket betűk jelölik.
14
/mnt: Felcsatolási pontok a rendszergazda által létrehozott ideiglenes csatlakozásokhoz. A programoktól nem várható el, hogy automatikusan felcsatolódjanak a /mnt alá. A /mnt felosztható további alkönyvtárakra (például a /mnt/dosa lehet az MS-DOS formátumú hajlékonylemezek csatlakozási pontja, a /mnt/exta pedig az ext2-es hajlékonylemezeké). /proc: A /proc könyvtár egy látszólagos katalógus. Nem is lemezen létezik, hanem a rendszermag hozza létre a memóriában. Arra használják, hogy a rendszerről (eredetileg a processzekről – innen a neve) adjon információkat. A legfontosabb fájlok és könyvtárak közül néhánynak a leírása megtalálható lentebb. Részletes leírást a proc kézikönyv oldal ad. /root: A root felhasználó home könyvtára. A rendszer többi felhasználója számára rendszerint nem elérhető. /sbin: Hasonló a /bin könyvtárhoz, de az ebben lévő parancsokat nem a normál felhasználóknak szánták, noha szükség esetén használhatják (ha van rá engedélyük). Az /sbin rendszerint nincs benne a normál felhasználók alapértelmezett elérési útvonalában, viszont a root felhasználóéban igen. /tmp: Ideiglenes fájlok. A rendszerindítás után futó programoknak inkább a /var/tmp használata ajánlott a /tmp helyett, mivel az előbbi valószínűleg egy nagyobb kapacitású lemezen van. A /tmp gyakran a /var/tmp könyvtárra mutató szimbolikus link (symbolic link). /usr: Az /usr fájlrendszer gyakran nagyon nagy, mert lényegében minden programot ide telepítünk. Az /usr összes fájlja rendszerint egy Linux disztribúcióból származik; a helyileg telepített programok és egyéb anyagok az /usr/local alá kerülnek. Ez a módszer lehetővé teszi, hogy a rendszert a terjesztés egy új változatával frissítsük, vagy akár egy teljesen új terjesztéssel, anélkül, hogy minden programot újra kellene telepítenünk. /var: Olyan adatokat tartalmaz, melyek a rendszer normális üzemelése során megváltoznak. Ez rendszerspecifikus, azaz nem osztható meg a hálózaton más számítógépekkel. Az FHS-től – nagyon alapos indok nélkül – nem jó ötlet eltérni, mivel az FHS megpróbálja a Unix szokásokat és az aktuális tendenciákat követni, így a Linux rendszer ismerős lesz a más Unix rendszereken gyakorlatot szerzettek számára is. [4, 5] Ez természetesen nem jelenti azt, hogy egyes disztribúciókban ne lenne némi eltérés a könyvtárfa felépítésében, de a terjesztők általában ragaszkodnak a korábban megszokott, szabad szabványban felsorolt irányelvekhez.
2.4.
Linkek
Sok operációs rendszerben egy az egyes összerendelés van az állományok és az állománynevek között. (Minden állománynak egy neve van, és minden állománynév egy állományt jelöl.) A Unix a nagyobb rugalmasság érdekében szakított ezzel a koncepcióval. Az állomány egyetlen egyedi azonosítója az inode-ja (information node). Az állomány inode-ja tartalmaz minden információt az állományról, beleértve a jogokat, a méretét, a hivatkozások számát. A 15
katalógusok csak egy fájlnév-inode összerendelést tartalmaznak, ezért lehetséges, hogy egy katalógusból több néven, vagy különböző katalógusokból hivatkozzunk ugyanarra az inode-ra. Ezt a Unixban link nek hívják. Amikor különböző névvel hivatkozunk egy inode-ra, azt hard link nek hívják. Ebben az esetben az állomány addig létezik, amíg van rá mutató bejegyzés. Hard linket csak egy köteten (egy partíción, egy eszközön) belül hozhatunk létre. Azonban lehetséges ún. szimbolikus link ek létrehozása is. Ilyenkor különböző nevekkel hivatkozhatunk egy katalógus bejegyzésre. Ilyen módon különböző kötetek között is létrehozhatunk linkeket. Azonban mivel a link csak egy katalógus bejegyzésre mutat, ezért ha a bejegyzés megszűnik, akkor a link nem működik többé. Amíg a hard linket katalógusokra nem szokás (de lehetséges4 ) használni, addig a szimbolikus linkeket igen gyakran alkalmazzák katalógusok között is. Hard linket két katalógusbejegyzés között az ln segédprogrammal lehet létrehozni: ln Szimbolikus linket két katalógusbejegyzés között az ln segédprogrammal és annak -s kapcsolójának használatával lehet létrehozni: ln -s
Feladat 1. Hozzunk létre szövegszerkesztővel egy állományt! 2. Csináljunk egy hard és egy szimbolikus link et az adott állományra! 3. Az ls -il paranccsal listázzuk ki a könyvtár tartalmát! (A -i opció hatására az első oszlopban láthatjuk minden állomány inode számát.) Vizsgáljuk meg ezeket a számokat! 4. A lista harmadik oszlopában az állományra való hivatkozások számát láthatjuk. 5. Mindkét linken keresztül nézzük meg az állomány tartalmát! 6. Módosítsuk a linkeken keresztül az állomány tartalmát és nézzük meg a hatását! 7. Töröljük le az eredeti állományt, majd próbáljuk meg a linkeken keresztül megnézni a tartalmát! 8. Az ls -ail paranccsal vizsgáljuk meg az aktuális könyvtárban a „.” és „..” könyvtárakat. Magyarázzuk meg a hivatkozások számát! 4 A könyvtárak közötti link létrehozására csak a super-usernek van joga, mivel ezzel a módszerrel hurkot lehet képezni a fában, ami viszont a programok hibás működését eredményezheti.
16
2.5.
Az eszközállományok
Ebben a fejezetben felsoroljuk a leggyakoribb eszközállományokat. Egyes eszközök némelyike csak akkor működik, ha a kernelbe fordítják a megfelelő támogatást. Egyegy adott eszközre vonatkozóan érdemes elolvasni a rendszermag dokumentációját. A következő lista semmiképp sem törekszik a teljességre, sem a maximális részletességre. /dev/dsp: Digitális jelprocesszor. Ez az alapvető felület, amelyen keresztül a hangkártya és a hangokat létrehozó program kommunikál. Karakteres eszköz. /dev/fd0: Ez az első hajlékonylemez meghajtó. Ha több is van, akkor folyamatos számozást kapnak. Blokkos eszköz. /dev/fb0: Az első framebuffer -eszköz. A framebuffer egy absztrakciós réteg a programok és a grafikus hardver között. Tehát az alkalmazásoknak nem kell tudniuk arról, hogy milyen a grafikus hardver; elég annyi, hogyan kommunikáljanak a framebuffer meghajtó jól definiált és szabványosított API-jával (Application Programming Interface). Karakteres eszköz. /dev/hda: A /dev/hda az elsődleges IDE vezérlőn (controller en) lévő master IDE meghajtó. A /dev/hdb a slave meghajtó ugyanitt. A /dev/hdc és a /dev/hdd a másodlagos vezérlőn lévő master és slave meghajtók (ebben a sorrendben). Minden lemez partíciókra tagolódik. Az 1-től 4-ig tartó partíciók az elsődleges partíciók, az ötödiktől kezdődően pedig a logikai partíciók vannak a kiterjesztett partíciókon belül. Ezért az egyes partíciókra hivatkozó eszközfájlok több részből állnak. Például a /dev/hdc9 a 9-es partíciót jelenti (logikai partíció egy kiterjesztetten belül) a másodlagos IDE vezérlő master IDE meghajtóján. Blokkos eszköz. /dev/null: A null eszköz egy speciális fájl, amely minden beleírt adatot elvet, miközben az írási művelet sikeres. Az eszközből való olvasás nem ad vissza semmilyen adatot. Felfogható adatnyelő eszközként. (Érdemes olyan programok kimenetét átirányítani a /dev/null -ba, amelyeknek kimenetére nem vagyunk kíváncsiak.) Karakteres eszköz. /dev/lp0: Az első párhuzamos nyomtató. A sorban következő nyomtatók a lp1, lp2 stb. neveket kapják. Karakteres eszköz. /dev/sda: Az első SCSI, SATA vagy USB meghajtó. A /dev/sdb3 a második SCSI vagy SATA merevlemez harmadik partícióját jelöli. Blokkos eszköz. /dev/random és /dev/urandom: Ezek a kernel véletlenszám-generátorai. A /dev/random nem-determinisztikus generátor, azaz a következő szám értékét nem lehet kitalálni az előzőekből. A rendszer hardverelemeinek entrópiáját használja fel a számok generálására. Ha elfogy a használható entrópia, akkor várnia kell, amíg újra összegyűlik annyi, hogy újabb számokat olvashasson ki belőle.
17
A /dev/urandom hasonló elv szerint működik. Kezdetben ez is a rendszerhardver entrópiáját használja, de ha ez elfogy, akkor is folytatja a számok küldését, egy ál-véletlenszám-generátor képlet segítségével. A /dev/urandom-ot kevésbé biztonságosnak tartják, ha olyan életbe vágóan fontos célokról van szó, mint például titkos kulcspárok generálása. Ha a biztonság az elsődleges szempont, akkor a /dev/random használata javasolt, ha viszont a gyorsaság fontosabb, akkor megteszi a /dev/urandom is. Mindkettő karakteres eszköz. /dev/zero: Ennek segítségével egyszerűen juthatunk sok nullához. Valahányszor ezt az eszközt olvassuk, 0-át ad vissza. Ez olyankor lehet hasznos, ha például fix hosszúságú fájlra van szükség, de nem számít, mi a tartalma. Karakteres eszköz. [4, 5]
2.6.
Fájlrendszer típusok
A Linux számos fájlrendszer típust támogat. Ezek egy része használható a rendszerállományok tárolására is, másik része pedig az egyéb operációs rendszerekkel való együttműködés érdekében került a rendszerbe (FAT, VFAT, NTFS).5 A következőkben – a teljesség igénye nélkül – végigtekintjük a Linux által támogatott állományrendszereket. 2.6.1.
Minix
A Linux születésének hajnalán a fejlesztés a Minix operációs rendszer alatt történt. Egyszerűbb volt megosztani a háttértárolót a két rendszer között, mint egy új állományrendszert kifejleszteni. Ezért legelőszőr ennek a fájlrendszernek a támogatása került bele a Linux-ba. Azonban a minix állományrendszer túl sok korlátozást tartalmazott, ezért a fejlesztők idővel szükségesnek látták a lecserélését, ezért fejlesztették ki az extended filesystems nevű állományrendszert. 2.6.2.
Extended filesystems (ext, ext2, ext3, ext4)
Az ext, ext2, ext3 és ext4 állományrendszerek elsősorban a Linux számára lettek kifejlesztve. Az ext a minix egy továbbfejlesztése. Azonban még így is számos hiányossággal rendelkezett, és teljesítmény problémái is voltak, ezért szükségessé vált egy új rendszer kifejlesztése, amely az ext2 nevet kapta. A minix, ext, ext2, ext3 és ext4 állományrendszerek korlátainak összehasonlításához nézzük meg a következő táblázatot! 5 Bár nincsen valójában megkötés, hogy milyen állományrendszert használhatunk a rendszerállományok tárolására, azonban célszerű olyat választani, amelyik kompatibilis a Unix védelmi rendszerével. Ellenkező esetben számos problémával kell megküzdenünk.
18
Minix
Ext
Ext2
Ext3
Ext4
Max. méret
64 MB–2 TB
2 GB
4 TB–32 TB
2 TB–32 TB
1 EB6
Max. állomány méret
64 MB
2 GB
16 GB–2 TB
16 GB–2 TB
16 GB–16 TB
Max.fájlnév hossz
14/30/60 bájt
255 bájt
255 bájt
255 bájt
256 bájt
Három idő támogatása
nem
nem
igen
igen
igen
Bővíthető
nem
nem
igen
igen
igen
3. táblázat. Állományrendszerek összehasonlítása
Az ext3 állományrendszer az ext2 továbbfejlesztése. Lényegében az ext2 kibővítése a journaling mechanizmussal. A létező ext3 fájlrendszerek néhány parancs lefuttatásával migrálhatók ext4 fájlrendszerre. Ez azt jelenti, hogy formázás vagy az operációs rendszer újratelepítése nélkül javítható a teljesítmény, emelhető a tárolási limit és egyéb funkciók is elérhetőek. Az ext4 fájlrendszer az új adatstruktúráját csak az új adatoknál fogja használni, a régi struktúra érintetlen marad. Ez azt jelenti,hogy a korábban ext4-re átkonvertált fájlrendszert csak úgy lehet ext3má visszaalakítani, hogy a meglévő ext4-es fájlrendszerünket a noextents kapcsoló segítségével csatoljuk fel, és az új struktúrájú fájlokról másolatot készítünk, majd a tune2fs program segítségével töröljük a INCOMPAT_EXTENTS flaget. Ezek után ismét ext3-as fájlrendszert kapunk. Ext3 fájlrendszer esetén az egy könyvtáron belül létrehozható az alkönyvtárak maximális száma 32 000 volt. Az ext4-nél nem áll fenn ez a limit, korlátlan számú alkönyvtára lehet egy könyvtárnak. Ext4 állományrendszer használata esetén az fsck program nem ellenőrzi a használatlan inode-okat, ezért fájlrendszer-ellenőrzés kevesebb ideig tart. Fontos megjegyezni, hogy az fsck hozza létre a használatlan inode-ok listáját, ezért csak az fsck soron következő futása lesz gyorsabb. (Ext3 fájlrendszerről ext4 fájlrendszerre történő átállás előtt az fsck programnak mindenképp sikeresen le kell futnia az ext3-as fájlrendszeren.) 2.6.3.
Journaling állományrendszerek
A komolyabb állományrendszerek adatainak frissítése, összetettségükből adódóan több különálló írás műveletből áll. Ahhoz, hogy az állományrendszer konzisztens maradjon az összes írás műveletnek végre kell hajtódnia. Ha eközben egy áramkimaradás miatt a rendszer összeomlik, akkor a fájlrendszer egy köztes állapotban maradhat. Ilyenkor a következő bootolásnál a rendszer végig ellenőrzi az állományrendszert és megpróbálja ezeket a hibákat kijavítani. Azonban ez egy nagyobb partíción nagyon sokáig eltarthat, és nem is jár mindig sikerrel, ha a helyreállításhoz nincsenek meg a szükséges információk. A journaling állományrendszer eken ennek a problémának a megoldására születtek. Az állomány rendszer tartalmaz egy elkerített területet, melyet journal nak, vagy lognak neveznek. Mielőtt az állományrendszerhez hozzányúlna a rendszer, hogy az egyik állapotból eljusson egy újabb állapotba, előtte a 61
exabájt = 1 048 576 TB = 1018 bájt.
19
műveleteket feljegyzi ebbe az elkerített területbe. Majd ezek után végrehajtja az utasítást. Ha eközben a rendszer összeomlana, akkor a journal tartalmazza a szükséges információkat, amely alapján a művelet visszajátszható. Természetesen, ha a journal terület írása közben omlana össze a rendszer, akkor az állományrendszer konzisztens állapotban van, ezért nem igényel beavatkozást. A journaling fájlrendszer hátránya, hogy a több írásműveletből adódóan valamennyivel lassabb, mint a könyvelés nélküli társai. A Linux alatt a következő journaling állományrendszer ek léteznek: JFS: az IBM által kifejlesztett, elsősorban az IBM Enterprise szerverekben használatos fájlrendszer. XFS: a Silicon Graphics által kifejlesztett és használt fájlrendszer. ext3: az ext2 fájlrendszer kiegészítése. ext4: a 2.6.28-as kernel óta stabil, az ext3 utódja. ReiserFS, Reiser4: a Namesys által fejlesztett általános célú fájlrendszer. 2.6.4.
Más operációs rendszerek támogatása
A Linux számos, más operációs rendszerek által használt állományrendszer típust is támogat: FAT12, FAT16, FAT32, VFAT: a DOS és Microsoft Windows rendszerek által bevezetett fájlrendszerek. NTFS: a Microsoft Windows NT vonal, illetve a Windows XP/Vista/7 által használt fájlrendszer. (Használata csak olvasható módban ajánlatos, mivel a Microsoft nem közli a specifikációját, és bármikor önhatalmúlag megváltoztathatja. A fejlesztők csak az állományrendszer elemzésével készítették a támogatást.) HFS, HFS+: a Macintosh rendszerek által használt fájlrendszer. HPFS: az OS/2 operációs rendszer által használt fájlrendszer. AFFS: az Amiga gépek támogatására. QNX4: a QNX operációs rendszer támogatására. 2.6.5.
A CD állományrendszere: iso9660
A CD-ROM állományrendszerének neve Linux alatt az iso9660, mivel ez a szabvány definiálja a működését. 2.6.6.
Hálózati állományrendszerek
A Linux három hálózati megosztásokra használatos állományrendszer támogat. A Unix rendszereknél használatos NFS-t (Network Filesystem), a Microsoft Windows család által bevezetett SMB (Server Message Block) protokoll, valamint a Novell Netware szerverek által használt ncpfs-t. 20
2.6.7.
Az állományrendszer paraméter használata
Az állományrendszer típusát a mount parancs -t opciója után kis betűkkel kell megadnunk. Az egyes állományrendszerekhez további, típus függő paramétereket is megadhatunk, amelyekről információ a mount manuál oldala tartalmaz. Amennyiben nem specifikáljuk az állományrendszert, vagy az auto típust adjuk meg, akkor a mount a partíció superblockját ellenőrzi és az alapján próbál választani. Ha ez sikertelen, akkor az /etc/filesystems állományt próbálja beolvasni és az abban szereplő lista alapján próbálgatja az egyes állományrendszer típusokat. Ha nem találja ezt az állományt, vagy már sikertelenül végigpróbálta a listát, és a lista végén egy „*” karakter szerepel, akkor a /proc/filesystems állomány alapján folytatja a tesztelgetést. Ez tulajdonképpen a kernel által támogatott állományrendszerek listája. A mount minden olyan sort végig próbál, amelyben nem szerepel a nodev kulcsszó. Az automatikus állományrendszer meghatározás hasznos lehet, amikor például a felhasználó egy pendrive-ot próbál felcsatolni. Azonban a tesztelés tévedhet, ami katasztrofális hatással lehet az állományrendszer tartalmára. Ezért fontos adatok esetén ne hagyjuk, hogy a mount találgasson! 2.6.8.
Fájlrendszer létrehozása
A Linux alatt az mkfs parancs használatos az állományrendszerek létrehozására: mkfs -t <eszköz állomány> Az eszköz állomány helyett esetleg megadhatunk könyvtárat is. Az mkfs parancs valójában egy front-end a különböző állományrendszereket elkészítő programoknak. Ezek a programok az /sbin könyvtárban találhatóak mkfs. néven. Az egyes állományrendszereknek eltérő beállításai lehetnek, ezért használatukkor tanulmányozzuk a hozzájuk tartozó manuál oldalakat!
Feladat Hozzunk létre FAT állományrendszert egy pendrive-on!
2.7.
Partíciók létrehozása, kezelése
A háttértárolót feloszthatjuk egy vagy több logikai részre, amelynek neve partíció. Ezeket az egységeket a partíciós tábla írja le. A Linux rendszert feltelepíthetjük egyetlen partícióra is, azonban teljesítmény szempontjából célszerű swap állomány helyett partíciót használni. Szerverek esetén a biztonság érdekében a rendszert is célszerű részekre bontani és külön partíciókra telepíteni. A partíciós tábla kezelésére a Linux rendszerek alatt az fdisk program használata javasolt. Bár egy régi eszközről van szó, ezért a felülete elsőre barátságtalannak tűnhet a később született társaihoz képest, azonban kis gyakorlással könnyű kezelni. Ugyanakkor az adminisztrátor számára ez a program nyújtja
21
a legtöbb állítási lehetőséget, szabadságot. Azonban ebből következően óvatosan kell bánnunk vele, éles rendszerek esetén pedig még fokozottabban kell ügyelnünk. A parancs leggyakrabban használt alakja a következő: fdisk <eszköz> Az eszköz neve általában a következő: /dev/hd[a–h] IDE lemezek esetén, vagy /dev/sd[a–p] SCSI, SATA, USB meghajtók esetén. Lefuttatás után a program egy prompt-ot ad és a parancsainkra vár. A parancsok listáját az „m” billentyűvel kérdezhetjük le. A leggyakrabban használt parancsok: Billentyű
Parancs
a
A boot partíció beállítása, illetve a jelzés törlése
d
Partíció törlése
l
A támogatott partíció típusok listázása
m
A segítség lista
n
Új partíció létrehozása
p
Az aktuális partíciós tábla megtekintése
q
Kilépés mentés nélkül
t
A partíció típusának módosítása
v
A partíciós tábla ellenőrzése
w
Kilépés mentéssel
x
további funkciók szigorúan csak tapasztalt felhasználó számára 4. táblázat. Az fdisk főbb parancsai
Mint látható a tábla módosítása után a „q” vagy „w” billentyűkkel léphetünk ki. Előbbi esetben mentés nélkül, utóbbi esetben a módosítások elmentésével. Az fdisk parancsot meghívhatjuk még a -l paraméterrel is, amikor csak kilistázza a partíciós tábla tartalmát: fdisk -l <eszköz>
2.8.
Állományrendszerek összekapcsolása és leválasztása
A Linux állományrendszere a root partíción elhelyezkedő gyökér könyvtárból indul ki. Innen kezdve épül fel a könyvtárak fa struktúrája. Ezt további blokk orientált készülékekkel bővíthetjük ki. A mount rendszerparanccsal egy már létező könyvtárat egy másik készüléken elhelyezkedő állományrendszerrel (esetleg ugyanazon eszközön lévő másik állományrendszerrel) kapcsolhatunk össze. Ezután a már meglévő könyvtárra való hivatkozások a másik állományrendszer gyökér könyvtárára fognak vonatkozni. Gyakorlatilag a mount parancs a hierarchia fa egy pontját egy teljesen új részfával cseréli fel. A lecserélt pont a kapcsolat megszüntetéséig (umount) elérhetetlenné válik. A mount parancs végrehajtása után lényegében nem 22
lesz különbség az eltávolítható köteten és a gyökér állományrendszerben található állományok között, egyformán kezelhetjük őket. Fájlrendszer hozzácsatolása a könyvtárfához: mount -t <eszköz állomány> A fájlrendszer lecsatolása két féle képpen is elvégezhető. Vagy az eszköz állományt adjuk meg mint csatolási pontot, vagy azt a könyvtárat, ahova felcsatoltuk a fájlrendszert: umount <eszköz állomány> umount A felcsatolt eszközökről, és a felcsatolás módjáról információkat kaphatunk a mount paraméter nélküli meghívásával. A felcsatolt eszközök kapacitását és a tárolt állományok helyfoglalását a df paranccsal kérdezhetjük le.
Feladat 1. Próbáljuk ki egy pendrive felcsatolását! mount /dev/sdb1 /mnt/tmp1 2. Vizsgáljuk meg mennyiben változott a könyvtárstruktúra! Majd csatoljuk le! umount /mnt/tmp1 3. Próbáljuk ki egy CD-vel is! mount -t iso9660 /dev/cdrom /mnt/cdrom 4. Próbáljuk ki mi történik akkor, ha olyan könyvtárat választunk csatolási pontnak, amelyben már vannak állományok! Vizsgáljuk meg a helyfoglalás változását a df paranccsal! Mi történik a lecsatolás után?
2.9.
Partíció létrehozása, formázása, felcsatolása
Feladat 1. A megismert fdisk program segítségével hozzunk létre egy új linux partíciót! 2. Az mkfs paranccsal hozzunk létre az új partíción egy ext2 állományrendszert! 3. A mount parancs segítségével csatoljuk fel a könyvtárstruktúrába!
23
4. Az umount paranccsal csatoljuk le! 5. Hozzunk létre egy új ext2 állományrendszert úgy, hogy ne legyen rajta a rendszergazda számára fenntartott terület! 6. A tune2fs program segítségével utólag módosítsuk az állományrendszer maximális mountszámát! 7. Próbáljuk ki mi történik ha felcsatolásokkal elérjük az előbb beállított maximális értéket!
2.10.
A Linux állományrendszer megjavítása
Az fsck program fő feladata, hogy rendszeres időközökkel ellenőrizze a Linux állományrendszerét, és szükség esetén automatikusan kijavítsa a hibákat. Amennyiben az automatikus ellenőrzés során túlságosan jelentős hibákat talál, akkor hibával tér vissza és a rendszer az adminisztrátor által futtatott interaktív javítást igényli. Ez az eset leggyakrabban akkor fordul elő, ha az állományrendszerünk nem journal típusú és a rendszer összeomlott (pl. áramszünet esetén). Azonban bármikor parancssorból ellenőrizhetünk állományrendszereket. Ehhez az állományrendszer ne legyen felcsatolva, hiszen egy ilyen folyamat aktív fájlrendszeren nem biztonságos. A parancs formája a következő: fsck -t <eszköz állomány> Az eszköz állomány helyett esetleg megadhatunk csatolási pontot is. Az fsck az mkfs-hez hasonlóan csupán egy front-end. Szintén az /sbin könyvtárból hívja meg az fsck. nevű programokat.
Feladat Ellenőrizzük a korábban létrehozott állományrendszerünket!
2.11.
Rendszerpartíciók paramétereinek megadása
A Linux rendszerben az /etc/fstab állomány tartalmazza az információkat az egyes, a rendszer által használt állományrendszerekről. Ennek az állománynak a karbantartása az adminisztrátor feladata. Kizárólag az adminisztrátor segédprogramjai módosíthatják. Minden állományrendszert egy sor ír le. Az egyes mezőket szóköz vagy tab karakterek választják el egymástól. Az egyes mezők jelentése sorrendben: 1. Az eszköz állomány neve. Hálózati állományrendszer esetén a távoli megosztás leírója (pl. NFS állományrendszer esetén a következő formában: <szerver>:). Ext2, ext3, ext4 állományrendszerek esetén az eszköz helyett a partíció címkéjét is megadhatjuk (pl. LABEL=/ ), de célszerűbb a partíció ún. UUID-ját megadni. (A blkid programot rendszergazdaként lefuttatva kapjuk meg az egyes partíciók UUID-ját.) 2. A csatolási pont. 24
3. Az állományrendszer típusa. Használható az auto kulcsszó is. Működése megegyezik a mount parancsnál tárgyalttal. 4. Az állományrendszer csatolási opciói vesszővel elválasztva. Az állományrendszer specifikus opciókat az állományrendszer manuál oldalán találhatjuk meg. A következő opciók minden állományrendszer esetén használhatóak: noauto: A rendszer indulásakor az állományrendszer ne csatolódjon fel. user: A felhasználók is felcsatolhassák az állományrendszert. (A felhasználó ilyenkor a mount parancsnak csak az eszközt, vagy a csatolási pontot adhatja meg. A felcsatolást a rendszer az fstab állományban meghatározott opciókkal végzi el.) owner: Az eszköz tulajdonosa csatolhatja fel az állományrendszert. _netdev: Az eszköz felcsatolásához hálózat működőképessége szükséges.) 5. A biztonsági mentés során a dump program az adott partíciót figyelembe vegye-e (1) vagy sem (0). 6. A rendszer indulásakor az automatikus állományrendszer-ellenőrzéskor (fsck) a sorrend megadása. A root állományrendszernél az 1-es érték beállítása javasolt. Egyéb állományrendszereknél a 2-es érték használható. Ebben az esetben egy meghajtón belül az ellenőrzések szekvenciálisan hajtódnak végre. Ha több meghajtón találhatóak a partíciók, akkor a rendszer párhuzamosítja az ellenőrzéseket. Ha a hatodik mezőt nem adjuk meg, vagy értéke 0, akkor a rendszer nem ellenőrzi az adott fájlrendszert.
Feladat 1. Tanulmányozzuk a rendszer /etc/fstab állományát! 2. Állítsuk be, hogy a korábban létrehozott állományrendszer induláskor automatikusan felcsatolódjon a /export csatolási pont alá! Az állományrendszer ellenőrzését is kapcsoljuk be, azonban a biztonsági mentés során hagyjuk figyelmen kívűl!
2.12.
Ext2 állományrendszer konverziója ext3-ra
Mivel az ext2 és az ext3 állományrendszerek között csak a journal mechanizmus támogatása jelenti a különbséget, ezért az utólagos konverzió könnyen megvalósítható.
Feladat 1. Csatoljuk le a korábban létrehozott ext2 állományrendszerünket! 2. A tune2fs -j <eszközállomány> paranccsal végezzük el a journal mechanizmus hozzáadását! (A parancsnak megadhatunk további paramétert, amellyel szabályozhatjuk a journal fájl méretét.) 25
3. Módosítsuk az /etc/fstab állományban a fájlrendszert ext2-ről ext3-ra! 4. Csatoljuk fel a partíciót! A tune2fs parancs a -j opcióval egy speciális attribútumokkal rendelkező rejtett állományt hoz létre, amelyet a műveletek könyvelésére használ majd az állományrendszer kezelő alrendszer. A konverzió visszafelé is lehetséges, az ext3 állományrendszerről ext2-re: 1. Az állományrendszer lecsatolása. 2. Az állományrendszert megszabadítása a journaling mechanizmustól: tune2fs -O ^has_journal <eszköz állomány> 3. Az állományrendszer ellenőrzése: e2fsck <eszköz állomány> 4. Módosítjuk az /etc/fstab állományt. 5. Felcsatoljuk az állományrendszert. 6. Töröljük le a .journal állományt az állományrendszerről. A tune2fs parancs letörli a journal fájl inode-ját, az e2fsck vagy fsck -t ext2 pedig befejezi a fájl eltávolítását.
2.13.
A swap
A kezdetek óta gyakran felmerül a probléma, hogy több memóriára lenne szükségünk, mint amennyi a gépünkben fizikailag rendelkezésünkre áll. Ugyanakkor felhasználhatjuk a merevlemezt, ami ugyan lassabban kezelhető, de jelentős kapacitással bír. Amikor kifutunk a szabad memóriaterületből, akkor a memória egyes nem használt részeit átmenetileg a merevlemezre helyezhetjük, így felszabadul a szükséges hely a programok számára. A Linux a virtuális memóriakezelés módszerét használja, amellyel ezt biztosítja számunkra. A memória és a merevlemez felhasználásával a processzek számára nagyobb memória terület elérését teszi lehetővé, mint amennyi szabad fizikai memóriánk valójában van. Mindezt ráadásul úgy oldja meg, hogy a processz számára az egész memóriaterület egységesen kezelhető és átlátszó. A Linux a virtuális memóriakezelés megvalósítására a memórialapozás technikáját alkalmazza. A rendszer memóriáját tartományokra, úgynevezett lapokra (page) osztja. Ezeket a lapokat egymástól függetlenül mozgatja a memória és a merevlemez között. Amikor a folyamatnak további memóriára van szüksége, de nincs már a memóriában szabad terület, akkor a Linux egyes, régebben használt lapokat kiír a lapcsere (swap) állományba vagy partícióra, és ezáltal helyet teremt. A swap terület lehet állomány, partíció, vagy állományok és partíciók kombinációja. Az ajánlott a külön partíció használata, mivel ez a megoldás nyújtja a legjobb teljesítményt.
26
2.13.1.
Swap partíció hozzáadása a rendszerhez
Előfordulhat, hogy kevésnek bizonyul a swap terület a rendszer számára, ezért újabb partíciókat szeretnénk hozzáadni. Ezt néhány lépésben megtehetjük:
Feladat 1. Létre kell hoznunk egy új partíciót a swap számára. 2. Meg kell formáznunk: mkswap <eszköz állomány> 3. Majd máris engedélyezhetjük a használatát a rendszer számára: swapon <eszköz állomány> 4. Már csak hozzá kell adnunk az fstab állományhoz, hogy a következő rendszerinduláskor használhassuk: <eszköz állomány> swap swap defaults 0
2.13.2.
Swap állomány hozzáadása a rendszerhez
Amennyiben nem tudunk egy partíciót felhasználni, a swap területhez, akkor még lehetőségünk van arra, hogy állományt hozzunk létre, és azt használjuk swapként.
Feladat 1. Létre kell hoznunk egy akkora állományt, amekkorát swap területnek szánunk: dd if=/dev/zero of=/swapfile bs=1024 count=<méret> A méretet kB-ban kell megadnunk. 2. Az állományt is a partícióhoz hasonlóan meg kell formáznunk: mkswap /swapfile 3. Majd engedélyeznünk kell: swapon /swapfile
27
4. Utolsó lépés, hogy hozzáadjuk az fstab állományhoz, hogy automatikusan használja a rendszer: /swapfile swap swap defaults 0
2.13.3.
A swap eltávolítása
A swap partíció vagy állomány eltávolításának menete: 1. A swap terület használatának kikapcsolása: swapoff <állomány> 2. El kell távolítani az eszköz vagy állomány sorát az fstab állományból.
28
3.
Felhasználók adminisztrációja, quota, shell
3.1. 3.1.1.
Felhasználók adminisztrációja A felhasználói azonosítók
A Unix rendszerek alatt minden felhasználó rendelkezik egy egyedi azonosító számmal (UID, vagy user identifier), és egy vagy több csoport azonosító számmal (GID, vagy group identifier). A felhasználók azonosítása a rendszerben a uid szám alapján történik. Bejelentkezéskor a rendszer a név alapján kikeresi az /etc/passwd állományból a felhasználó azonosítóját, és a későbbiekben ezt használja a rendszerben folytatott tevékenységünk során. A csoportokba sorolás segítségével a felhasználók egy csoportját összefoghatjuk és a rendszer egyes részeihez több jogot biztosíthatunk, mint a többieknek. Egy felhasználó több csoport tagja is lehet egyszerre. Ebből az egyik csoport szerepe megkülönböztetett. Ez az alapértelmezett, amelyet az állományok létrehozásakor használ a rendszer. A felhasználó azonosítója és az alapértelmezett csoport azonosítója az /etc/passwd állományban van eltárolva. A többi csoport azonosító az /etc/group állomány bejegyzései alapján rendelődik hozzá a felhasználóhoz. Ezekről az állományokról a man 5 passwd és a man group parancsokkal kaphatunk további információt. Létezik egy kitüntetett felhasználó, a rendszergazda (superuser, a felhasználóneve „root”). A rendszergazdára nem vonatkoznak a felhasználókra beállított hozzáférési jogok, a rendszer még az állományok tulajdonosánál is bővebb lehetőségeket engedélyez számára. A rendszer az alapján ismeri fel, hogy az uid je 0. Jogai gyakorlatilag korlátlanok, éppen ezért igen körültekintőnek kell lennünk, amikor rendszergazdaként jelentkezünk be, mert egyetlen rossz mozdulattal az egész rendszert tönkre lehet tenni. Ezért javasolt, hogy egészen addig egyszerű felhasználóként tevékenykedjünk a rendszerben, amíg valamelyik művelethez nem kellenek feltétlenül a rendszergazdai jogosultságok. Az Ubuntu disztribúciókban a root felhasználóhoz tartozó jelszó alapállapotban zárolva van. Ezért rootként nem is lehet bejelentkezni. Ez nem azt jelenti, hogy rendszergazdai jogosultságú műveletek elvégzésére nincs lehetőségünk. Ubuntu alatt sudo-t kell használnunk a rendszergazdai jogosultság eléréséhez. Azon felhasználók, akik használhatják a sudo parancsot az /etc/sudoers fájlban vannak felsorolva. Nagyon fontos, hogy a sudoers állományt tilos szerkeszteni. Erre külön program, a visudo szolgál, amely rendszergazdai jogosultságok mellett használható. (A visudo szövegszerkesztőjének átállításához az EDITOR környezeti változóban kell beállítani a használni kívánt szövegszerkesztőt, majd a változót exportálni kell, végül a visudo-t a sudo -E visudo paranccsal kell elindítani.)
Megjegyzés Mivel a rendszer a rendszergazdát valójában a 0-s uid alapján azonosítja, ezért minden felhasználó, akinek ez az azonosító van beállítva az /etc/passwd állományban az rendszergazda. A szerverek feltörése esetén szokott előfordulni, hogy a betörő létrehoz egy felhasználót, akinek 0-s azonosítót állít be. Így később is visszatérhet, és rendszergazdaként garázdálkodhat. Ezért egy ilyen esemény után célszerű ezt is ellenőrizni.
29
3.1.2.
Felhasználók létrehozása
Unix rendszereken az új felhasználó létrehozásához elegendő, ha egy rávonatkozó bejegyzést írunk az /etc/passwd állományba. Továbbá létre kell hoznunk neki egy home könyvtárat, amelyet a tulajdonába adunk, és bejegyzünk szintén a passwd állományba. Azonban léteznek segédprogramok is, amelyek ezeket a műveleteket elvégzik nekünk. Parancssoros programok közül ilyen a mindenhol megtalálható useradd. Alapvetően két működési módját különböztetjük meg. Az egyik feladata, hogy új felhasználókat hozzon létre. A másik módja a konfigurációs mód, amikor az alapértelmezett értékeket állítjuk be. A legegyszerűbb, és leggyakrabban használt formája a következő: useradd -c Alapértelmezett esetben bejegyzi a felhasználót a passwd állományba, majd létrehoz egy home könyvtárat, amelybe bemásolja az /etc/skel könyvtárban található állományokat. Mivel a létrehozott felhasználónak nem állítottunk be jelszót, ezért blokkolja a hozzáférését a rendszerhez. A jelszót utólag rendszergazdaként a passwd paranccsal adhatunk. Azonban nem csak valódi felhasználókat hozhatunk létre, hanem úgynevezett rendszer-felhasználókat is. Ezek jelszó nélküli, blokkolt felhasználók home könyvtár nélkül. Csak azért szükségesek, hogy egyes szolgáltatások ezeknek a virtuális felhasználóknak a nevében fussanak, és ez által a rendszer a hozzáférési jogosultságaikat szabályozhassa. Ezek a rendszer-felhasználók abban is különböznek a normál felhasználóktól, hogy az azonosítójuk általában kisebb. A useradd programmal a -r opcióval hozhatjuk létre őket. Az alapértelmezett paramétereket módosíthatjuk is a -D opció használatával: useradd -D A rendszer az alapértelmezett értékeket az /etc/default/useradd állományban tárolja.
Megjegyzés A Red Hat disztribúcióban a useradd program egy módosított változata található. Ez, ha nem definiáljuk a felhasználó csoportját, akkor figyelmen kívül hagyja az alapértelmezett értéket, és minden felhasználónak egy új csoportot hoz létre. Az újonnan létrehozott csoport lesz a felhasználó alapértelmezett csoportja. Ez a működési mód általában fölösleges pazarlás, ezért célszerű a useradd program használatakor a -g opcióval definiálni a felhasználó csoportját.
Megjegyzés Az Ubuntu disztribúcióban a root felhasználóhoz tartozó jelszó alapállapotban zárolva van. Ezért rootként nem is lehet bejelentkezni. Ehelyett sudo-t kell használnunk a rendszergazdai jogosultság eléréséhez. Ahhoz, hogy egy felhasználó használhassa a sudo-t, hozzá kell adnunk a /etc/sudoers állományhoz. Ez esetenként körülményes lehet, ugyanakkor létezik egy kényelmesebb, könnyebben
30
adminisztrálható megoldás, miszerint a felhasználót csak hozzá kell adnunk az admin csoporthoz. sudo adduser admin
Feladat Állítsuk át az alapértelmezett csoportot a users (100) csoportra, majd hozzunk létre felhasználókat! (Red Hat esetén a felhasználó létrehozásakor is meg kell adni a csoportot.)
3.1.3.
Felhasználó letiltása
A felhasználó hozzáférését számos okból letilthatjuk. Egyik szokásos eset, amikor csak egy bizonyos időszakra adjuk a hozzáférést. Ilyenkor már a felhasználó létrehozásánál a useradd parancs -e opciójával megadhatjuk a lejárati dátumot, amikortól nem férhet hozzá a rendszerhez. A másik szokásos eset az automatikus letiltásra, amikor kötelező érvényűvé tesszük, hogy a felhasználók bizonyos idő elteltével cseréljék a jelszavukat. Ezt a passwd parancs -x opciójával adhatjuk meg napokban. Az -i opcióval pedig azt állíthatjuk be, hogy ha elmulasztaná a felhasználó a jelszó megváltoztatását, akkor hány nap múlva tiltódjon le a hozzáférése. Adódhat olyan eset is, amikor manuálisan kell letiltanunk egy hozzáférést valamilyen oknál fogva. Ezt szintén a passwd paranccsal tehetjük meg. Az -l kapcsoló blokkolja, az -u opció pedig újra engedélyezi a hozzáférést. 3.1.4.
Felhasználó törlése
A felhasználó törlése történhet kézzel. Ilyenkor törölnünk kell a felhasználó bejegyzését az /etc/passwd állományból, továbbá shadow jelszó használata esetén az /etc/shadow állományból is. Amennyiben az /etc/group állomány tartalmaz rávonatkozó bejegyzéseket, akkor azt is el kell távolítanunk. Ezzel a felhasználó megszűnt létezni, azonban még további állományai lehetnek a rendszerben. Ez alapértelmezett esetben a /home/ könyvtár tartalma, és a levelesládája (általában /var/spool/mail/). De természetesen ezeket a műveleteket elvégezhetjük egyszerűbben is a userdel paranccsal: userdel -r Az -r paraméter használatával érhetjük el, hogy a felhasználó home könyvtára, és a levelesládája is törlődjön. 3.1.5.
Csoportok adminisztrációja
A felhasználókhoz hasonlóan a csoportok adminisztrálására is találhatunk segédprogramokat. Ilyen a groupadd és a groupdel, ami mint a felhasználóknál, itt is az új csoportok létrehozására, illetve törlésére szolgál. A groupadd program is rendelkezik egy -r kapcsolóval, amellyel rendszer-csoportokat hozhatunk létre, amely ebben az esetben csak azt jelenti, hogy a csoportazonosító kisebb lesz a normál azonosítóknál. 31
3.1.6.
Az állományrendszer jogosultságai
Mint minden többfelhasználós rendszer a Linux is védi az egyes felhasználók állományait és folyamatait a többi felhasználótól. A Linux és más Unix operációs rendszerek a felhasználói- és csoportazonosítókat használják a védelmi korlátozások meghatározására. A rendszer minden állománya egy tulajdonos és egy csoportazonosítóval rendelkezik: • A tulajdonosazonosító az állományt létrehozó felhasználó azonosítója. (A rendszergazda ezt a paramétert állíthatja a chown paranccsal.) • A csoportazonosító az állomány létrehozásakor a felhasználó alapértelmezett csoportja. Ez később a chgrp paranccsal állítható. Ezek az azonosítók szabályozzák, hogy az egyes folyamatok hozzáférhetnek-e az adott állományhoz és elvégezhetik-e a kérdéses műveleteket, vagy sem. A folyamat (felhasználó) és az állomány között három fajta reláció állhat fenn: • Azon felhasználó, akinek az azonosítója megegyezik az állomány azonosítójával, az a tulajdonos (owner). • Akinek a felhasználói azonosítója más, de valamelyik csoport azonosítója megegyezik a bejegyzés azonosítójával az a csoporttárs (group). • Akiknek pedig a felhasználói és csoport azonosítója egyaránt eltér a bejegyzés azonosítóitól, azok a többiek (others). Minden egyes relációra három féle jogosultsági engedélyt állíthatunk be: olvasás, írás, és végrehajtás (könyvtárak esetén ez utóbbi keresési jogot jelent). Nézzük, hogyan is néz ez ki! Az ls -l paranccsal részletes listát kérhetünk az adott könyvtár tartalmáról: drwxr-xr-x 2 root root 4096 Sep 23 23:24 dir1 -rw-r--r-- 1 root root
5 Sep 23 23:24 file1
A lista sorainak első mezője tartalmazza az adott állományra/könyvtárra érvényes jogokat a következők szerint: drwxrwxrwx Ahol az első karakter az állomány típusa:
32
Jelzés
Típus
b
a bejegyzés egy blokk-orientált speciális állomány
c
a bejegyzés egy karakter-orientált speciális állomány
d
a bejegyzés egy katalógus
l
a bejegyzés egy szimbolikus link
-
a bejegyzés egy egyszerű állomány 5. táblázat. Állománytípusok
A következő kilenc karakter hármas csoportokra osztható. Az első három az owner, a második a group, a harmadik pedig az other jogait jelenti. A hármas csoporton belül a három karakter sorrendben a következő lehet: „r”, „w” és „x”. ezek bármelyike helyén „-” is állhat. Jelentésük pedig rendre az olvasási (read), írási (write), végrehajtási (execution) jogot vagy „-” jel esetén annak hiányát jelenti. Az olvasási jogkör szabályozza, hogy van-e joga az adott felhasználónak az állomány tartalmának megtekintésére, illetve a katalógus tartalmának kilistázására. Ha egy felhasználó rendelkezik írási joggal egy bejegyzésre, akkor bővítheti, kicserélheti, megváltoztathatja az állomány tartalmát, illetve létrehozhat, törölhet bejegyzést katalógus esetén. A végrehajtási jog (amely csak állományra vonatkozhat, ha katalógusra vonatkozik, akkor keresési jognak nevezzük) azt jelzi, hogy az adott felhasználó futtathatja-e az állományt. Maga a végrehajthatósági jog önmagában még nem jelenti azt, hogy az állomány ténylegesen futtatható kódot tartalmaz. A katalógusokra vonatkozó keresési jog azt jelzi, hogy van-e jogunk a katalógus bejegyzéseinek eléréséhez, használatához. A tulajdonos lehetőségeit ismertető csoportban „x” helyén „s” áll, ha az állomány setuid módban van. Hasonlóképpen a csoporttárs lehetőségeit ismertető csoportban „x” helyén „s” áll, ha a bejegyzés setgid módú. Az ún. setuid mód lehetővé teszi, hogy a rendszer a programot futtató felhasználót saját uid je helyett a programállomány tulajdonosának uid jével azonosítsa (természetesen csak a program futásának időtartamára). Így a felhasználó által futtatott program mindazt végrehajthatja, amit a programállomány tulajdonosa végrehajthat. A setgid mód teljesen azonos a setuid móddal: a rendszer a felhasználó valódi gid je helyett a programállomány tulajdonosának gid jét (gid jeit) használja a hozzáférési jogok megállapításánál a program futásának időtartama alatt. A jogokat a chmod paranccsal módosíthatjuk. A parancsot kétféleképpen használhatjuk: egyrészt a jogok egzakt, oktális számokkal való megadásával, másrészt szimbolikus jelekkel. A chmod parancs használatának általános formája: chmod <mód> Azonban a rendszernek már az állományok létrehozásakor be kell állítania valamilyen engedélyeket. Lehetne szigorú és elvehetne minden jogot, de lehetne engedékeny is, és megadhatná őket. Azonban a 33
legjobb megoldás, ha a felhasználó megadhatja. Ezt meg is tehetjük az umask segítségével. Ez egy egész szám, amely azt tartalmazza, hogy mely biteket töröljön a rendszer az engedélyek közül. A legegyszerűbb, ha oktális számokkal adjuk meg. Ilyenkor lényegében a chmod parancsnál használt szám inverzét kell megadni: umask <mód inverze>
3.1.6.1.
A jogok megváltoztatása (szimbolikus jelekkel)
A mód szimbolikusan a következő módon adható meg: [kinek] op jogok [op jogok] ... Ahol a „kinek” a következő betűk kombinációja kehet: Jelzés
Kinek állítjuk a jogait?
u
a tulajdonosnak
g
a csoportnak
o
a többieknek
a
mindenkinek
6. táblázat. Jogosultsági csoportok
Ha a „kinek” elmarad, akkor az mindenkit jelöl (mint az „a”), de ilyenkor az aktuális umask ot figyelembe veszi, és azokra a bitekre, ahol a umask 1 az állítás nem hat. Az operátor +, -, vagy = lehet: Jelzés
Művelet
+
jogokat adunk hozzá az állomány jogaihoz
-
jogokat veszünk el az állomány jogaiból
=
pontosan ezt az értéket akarjuk beállítani
7. táblázat. A jogosultságokat állító operátorok
A jogok a következő betűk kombinációi lehetnek:
34
Jelzés
Jogok
r
olvasási jog
w
írási jog
x
végrehajtási jog
X
végrehajtási jog, de csak akkor, ha az állomány katalógus, vagy van már másik x bitje
s
setuid vagy setgid bit
t
sticky bit7
u
a tulajdonos mezőt az eredeti módból veszi
g
csoport mezőt az eredeti módból veszi többiek mezőt az eredeti módból veszi
o
8. táblázat. Hozzáférési jogok
Feladat 1. Hozzunk létre állományokat, vagy könyvtárakat, és gyakoroljuk a jogok beállítását! Pl. adjunk írás jogot a csoportnak, vegyük el a többiek olvasás jogát, adjunk a tulajdonosnak futtatási jogot, adjunk mindenkinek futtatási jogot, ha valakinek van, stb. 2. Adjunk írás jogot a teszt könyvtárunkra mindenkinek! Hozzunk létre benne egy állományt, amelyre levesszük az írási jogokat! Egy másik felhasználóval próbáljuk meg szerkeszteni, átnevezni, törölni az állományt! Próbáljuk meg ugyanezt, ha a sticky bitet beállítjuk a könyvtárra!
3.1.6.2.
A jogok állítása (oktális számokkal)
Az abszolút kód egy oktális szám, ami a következő kódok vagy kapcsolatával állítható elő: 7A
sticky bit állományok esetén nem értelmezett. Csak a régi Unix rendszerek használták, a Linux figyelmen kívül
hagyja. Könyvtárak esetén a jelentése, hogy a benne található állományokat csak a tulajdonos vagy a root nevezheti át vagy törölheti. Jellemzően a /tmp könyvtár használja ezt a jog bitet. Nélküle bárki átnevezhetné vagy törölhetné az állományokat.
35
Jelzés
Jogok
4000
setuid mód a végrehajtáskor
2000
setgid mód a végrehajtáskor
1000
sticky bit
0400
olvasás a tulajdonos által
0200
írás a tulajdonos által
0100
végrehajtás (keresés a katalógusban) a tulajdonos által
0040
olvasás a csoportnak
0020
írás a csoportnak
0010
futtatás a csoportnak
0004
olvasás a többieknek
0002
írás a többieknek
0001
futtatás a többieknek
9. táblázat. Jogosultságok oktális számokkal
User
Group
Other
Szimbolikus
rwx
r-x
--x
Bináris
111
101
001
Oktális
7
5
1
10. táblázat. Jogosultságok formátumai
Feladat Hozzunk létre állományokat és gyakoroljuk a jogok beállítását oktálisan!
3.1.6.3.
Alapértelmezett állomány jogok
Azok a programok, amelyek állományokat hoznak létre, a létrehozáskor beállítják a létrehozandó állomány védelmi kódját. Így történik ez akkor is, ha pl. szövegszerkesztővel létrehozunk egy új állományt. Ilyenkor a jogokat az umask beállítások alapján állítja be a rendszer. Mégpedig úgy, hogy azokat a védelmi biteket (csak az alsó 9 bitet), amelyek értéke 1 az umask ban, a létrehozandó állomány védelmi kódjából kitörli. Például a 002 umask érték azt jelenti, hogy állományok estén a jog 664 lesz, könyvtárak esetén 775. (Látható a fentiekből ez az alapértelmezett értéke az umask nak.) Állományok esetén futásjogot nem tudunk az umask kal adni.
36
3.1.7.
Az ext2, ext3, etx4 állományrendszerek további jogosultságai
Az eddig megismert általános Unix jogosultságokon kívül az ext2, ext3 és ext4 állományrendszerek további jogosultságok beállítását is támogatják. Ezek a jogosultság beállítások eltérően a Unix jogosultságokhoz nem a felhasználók közötti hozzáférést szabályozzák, hanem elsősorban a rendszergazda számára nyújtanak segítséget speciális esetekben. Egy adott könyvtárban a jogokat az lsattr programmal listázhatjuk ki. Az ls programhoz hasonlóan -R (rekurzív listázás), -a (rejtett állományok listázása), -d (könyvtár nevek listázása) opciókat is használhatjuk. A jogokat a chattr programmal állíthatjuk szimbolikusan: chattr +|-|=<jog> Jelzés
Jogok
A
Az atime érték nem módosul az állományhoz való hozzáféréskor.
a
Az állomány csak hozzáírásra nyitható meg. Törölni, felülírni nem lehet.
c
Az állomány automatikusan tömörítve tárolódik a lemezen. Olvasáskor a kernel kitömöríti.
D
Könyvtárak esetén az adatok kiírása szinkron módon történik.
d
Az állomány kimarad a biztonsági mentés készítésekor (dump).
i
Az állomány nem módosítható, törölhető, mozgatható, átnevezhető. Továbbá nem hozhatunk létre linket rá.
j
Ha az ext3 fájlrendszert nem journal módban csatoltuk fel, az adott állományra akkor is működik a journal mechanizmus. Normál esetben nincs hatása.
s
Az állomány törlésekor az adatok 0-val íródnak felül a meghajtón.
S
Az állomány esetén módosításkor az adatok szinkron módon íródnak ki a lemezre.
u
Az állomány törlésekor a tartalma elmentődik, így vissza lehet vonni a törlést.
11. táblázat. Az ext2, ext3, ext4 állományrendszerek további jogosultságai
Megjegyzés A 2.2-es és korábbi kernel verziók nem támogatják az összes állományrendszer opciót. Egyes betörők az „i” vagy „a” opciókkal levédhetik hátrahagyott állományaikat a tapasztalat-
37
lan rendszergazdákkal szemben. Ezért ha rendszergazdaként is problémánk adódik az állományok letörlésével, felülírásával, akkor gyanakodjunk ezen opciók használatára.
Feladat Próbáljuk ki egy tesztállományon az egyes opciók hatásait, hogy megismerjük az általuk okozott jelenséget!
3.2.
Quota
A quota rendszer segítségével szabályozhatjuk, hogy egyes felhasználók, vagy csoportok mennyi háttértároló kapacítást használhatnak el. Így megakadályozhatjuk, hogy a felhasználók teleírják a merevlemezt. A korlátozásokat megadhatjuk felhasználókra vagy csoportokra bontva is. A quota rendszer bekapcsolásához az alábbi teendőket kell végrehajtanunk: 1. A kernelben be kell kapcsolnunk a quota támogatást. (Ez modern disztribúciók esetén alapértelmezetten támogatott.) 2. Az /etc/fstab állományban meg kell adnunk a quota opciókat a felcsatolt állományrendszerekre. 3. Létre kell hoznunk quota táblázatokat, és az egyes felhasználóknak és csoportoknak meg kell adnunk az értékeket. 4. Be kell kapcsolnunk a rendszert. 3.2.1.
A quota bekapcsolása az állományrendszerre
A quota rendszer támogatásához az egyes felcsatolt állományrendszerekre be kell kapcsolnunk az usrquota vagy grpquota opciókat, attól függően, hogy a felhasználói, csoport, vagy mindkét beállítást használni szeretnénk. Ezt az /etc/fstab állományban tehetjük meg, ha azt szeretnénk, hogy minden induláskor automatikusan megtörténjen. Pl. /dev/hda2 /home ext2 defaults,usrquota,grpquota 1 1 Ha az állítás előtt is fel volt csatolva az állományrendszer, akkor mount-oljuk újra. 3.2.2.
A quota táblázatok létrehozása
Miután felcsatoltunk minden olyan állományrendszert, amelyre a quota opciókat bekapcsoltuk a quotacheck paranccsal le kell generálnunk az információs táblázatokat (aquota.user és aquota.group). Ezt a -c opció használatával tehetjük meg. Emellett meg kell adnunk, hogy a felhasználói (-u) vagy a csoport (-g) táblázatot szeretnénk legenerálni. Ha a /home partícióra szeretnénk legenerálni, akkor a következő parancsot kell kiadni:
38
quotacheck -acugm /home Az -a opció azt jelenti, hogy minden felcsatolt quota-t használó állományrendszert végignéz. A táblázatok legenerálása után az aktuális lemezhasználat információkat a következő paranccsal frissíthetjük: quotacheck -avugm Ezt akár crontabból is tehetjük: 0 3 * * 0 /sbin/quotacheck -avug
3.2.3.
A quota rendszer bekapcsolása
Miután a táblázatokat is legeneráltuk következő lépésként bekapcsolhatjuk a quota rendszert: /usr/sbin/quotaon -avug Azonban előfordulhat, hogy az adott rendszerben ez már szerepel az inicializációs szkriptekben, ezért nekünk már nem kell megadni. 3.2.4.
A quota értékek beállítása
A quota rendszer beüzemelése után állítsuk be a quota értékeket. Ezt az edquota paranccsal tehetjük meg. Egy felhasználó esetében: edquota A rendszer az EDITOR környezeti változó által meghatározott szövegszerkesztővel megnyit egy táblázatot, amelyben beállíthatjuk az értékeket az egyes kötetekre. Az oszlopok jelentése a következő: filesystem: A kötet neve. blocks: A jelenleg használt blokkok száma. soft: A soft limit a maximálisan használható blokkok számára. Ezt egy meghatározott türelmi időre átlépheti a felhasználó. hard: A hard limit a blokkok számára. Ezt semmiképpen nem lépheti át a felhasználó. inodes: A használt inode-ok száma. soft: A soft limit a maximálisan használható inode-ok számára. hard: A hard limit a maximálisan használható inode-ok számára. A quota használatát a következő paranccsal ellenőrizhetjük le: quota
39
A csoportok értékeinek beállítása hasonló. A következő paranccsal érhető el: edquota -g A megjelenő beállítások megegyeznek a felhasználóknál látottakkal, csak a csoportra értelmezendőek. A beállatásokat a következő paranccsal ellenőrizhetjük: quota -g Átfogó jelentést a következő paranccsal kaphatunk: repquota -avugs
3.2.5.
A türelmi idő beállítása
A soft limitek esetén szó esett egy türelmi időről. Ezt az értéket a következő paranccsal állíthatjuk: edquota -t
3.3.
A parancsértelmező (shell)
A Unix rendszerek és így a Linux egyik érdekessége, hogy a felhasználói felületet megvalósító parancsértelmező (shell) egy közönséges felhasználói program. Ez a parancsértelmező nem integráns része az operációs rendszernek, és nem élvez speciális megkülönböztetéseket. Így bárki lecserélheti a sajátját egy másik programra. A rendszerbe való bejelentkezéskor a rendszer a login-név (uid) és a jelszó alapján ellenőrzi a felhasználót, majd a password állomány hozzá tartozó sorának megfelelő mezőjében megadott programot elindítja. Ez rendszerint valamelyik shell (sh, csh, ksh, tcsh stb.), de lehet valami más program is. Mindegyik felhasználónak joga van ezt a programot lecserélni (chsh parancs). Az egyes shell változatok között a különböző kényelmi szolgáltatásokban, valamint a programozói felületükben van eltérés. Ugyanis a UNIX shellek nem csupán parancsértelmezők, hanem programozási nyelvek is egyben. A következőkben áttekintjük a bash (Bourne-again shell) különböző funkcióit. 3.3.1.
Parancssor értelmezés
A Unix shell lényegében egy parancsértelmező program, amely beolvassa a felhasználó által begépelt sorokat, és azt más programok végrehajtását előíró kérésekként értelmezi. Egy parancssor a legegyszerűbb esetben egy parancsból és a hozzá tartozó, szóközökkel elválasztott paraméterekből áll. parancs argl arg2 ... argn A parancsértelmező különálló karaktersorozatokká bontja fel a parancs nevét és argumentumait. Ezután egy beállítható keresési út (PATH) szerint a különböző katalógusokban megkeresi a „parancs” nevű állományt. Ha sikerült megtalálni, akkor azt végrehajtja. A parancs végrehajtásának befejezését a prompt kiírásával jelzi. 40
A parancssorban szereplő állománynév után következő argumentumok a következő négy kategória valamelyikébe esnek: • Egyszerű karakterlánc. • Állománynév, amit „<”, „>” vagy „>>” előz meg. • Egy karakterlánc, amely állománynév helyettesítő karaktert is tartalmaz. • „`. . . `”, vagy „$(. . . )” jelek közé zárt újabb parancs, ami ún. parancshelyettesítést eredményez. Az egyszerű argumentumokat a program string tömbjeként kapja meg. A shell állítja elő ezt a tömböt, ezáltal könnyebb és egységes a paraméter kezelés implementálása a programokban. 3.3.2.
A shell beépített parancsai
A shellek tartalmaznak néhány beépített parancsot. Ezek többnyire a shell működésével szorosan összefüggő parancsok, amelyeket nem érdemes más módon implementálni. Azonban léteznek olyan shellek, amelyek számos parancs megvalósítását integrálják magukba. Teszik ezt azért, hogy a rendszerhibák esetén is működhessenek, és ezáltal lehetőséget nyújtsanak az adminisztrátornak a nehéz helyzetből való kilábalásra. Ilyen shell program a sash (Stand-alone shell). Ez egy statikusan linkelt program, amely tartalmazza a legszükségesebb programok egyszerűsített változatait. Így akkor is működőképes, amikor az alap programkönyvtárak meghibásodása miatt a rendszer lényegében használhatatlan. Az ilyen shellek telepítése feltétlenül javasolt, hogy a problémás helyzeteket egyszerűbben megoldhassuk. 3.3.3.
Állománynév-helyettesítés
A parancs argumentumában megadott „*”, „?”, és „[. . . ]” jelek ún. állománynév-helyettesítő jelek. Ezek jelentése: Jel
Jelentés
*
Nulla vagy tetszőleges számú tetszőleges karakter.
?
Pontosan egy tetszőleges karakter.
[abc]
Az „a” vagy „b” vagy „c” karakter egyike.
[m-n]
m–n intervallumból egy karakter.
12. táblázat. Állománynév-helyettesítés reguláris kifejezésekkel
Az olyan argumentumok, amelyek állománynév-helyettesítő karaktereket tartalmaznak, állománynevekből álló egyszerű argumentumok sorozatára cserélődnek le. Például „*f”-ből azoknak az aktuális katalógusban található állományneveknek a sorozata lesz, amelyek az „f” karakterekre végződnek. A helyettesítő karakterek közül több is szerepelhet egyidejűleg ugyanabban az argumentumban. Pl. az „[a-z]*” a kisbetűvel kezdődő neveket jelenti. 41
Az, hogy a kifejtő metódust a shell tartalmazza, több előnnyel jár: • A kifejtést megvalósító program csak egyszer szerepel a rendszerben (helytakarékosság). • A programoknak a kifejtéssel nem kell foglalkozniuk. • A kifejtő algoritmus alkalmazása így bizonyosan mindig egységes lesz. 3.3.4.
Standard input/output átirányítás
A shell által végrehajtott programok eleve három megnyitott állománnyal indulnak. Ezek a 0, 1 és 2 állományleírókhoz vannak hozzárendelve. 0: Standard input. 1: Standard output. 2: Error output. Ezek alapértelmezésben a felhasználó termináljához vannak rendelve, de átirányíthatjuk őket. A „>” vagy „>>” jellel a standard kimenetet irányíthatjuk át. A parancs végrehajtása alatt az 1-es állományleíró a „>” jel után megadott nevű állományra mutat. A következő parancs létrehozza a „kimenet” nevű állományt és a listát abba írja: ls > kimenet Ha a „>>” jelet használjuk, akkor az ls parancs kimenetét a „kimenet” állomány végéhez fűzi: ls >> kimenet A hibakimenetet a „2>” jelöléssel irányíthatjuk át. Hasonlóan a standard input is átirányítható. Ezt a „<” jellel tehetjük meg. A „< bemenet” jelölés azt jelenti, hogy a standard input a „bemenet” nevű állományból jöjjön. 3.3.5.
Csővezeték
A Linuxban gyakran előfordul, hogy az egyik program kimenetét szeretnénk használni egy másik program bemeneteként. Például, ha egy program kimenetét szeretnénk megszűrni, rendezni, tördelni. Ezt megtehetjük az előző fejezetben ismertetett módon átmeneti állományok létrehozásával. Azonban a Linux tartalmaz egy sokkal hatékonyabb eszközt is, amelyet csővezetéknek (pipe) nevezünk. A csővezeték egy olyan speciális állomány, ami egy FIFO-t (First In First Out) valósít meg. Az érdekessége abban áll, hogy ez a FIFO állományként kezelhető. Két állományleíróval hivatkozhatunk rá, egyiken írhatunk bele, a másikon pedig a beírási sorrendben kiolvashatjuk a beírt adatokat. A csővezeték-szervezés lehetőségeinek előnyei: • Nincs szükség ideiglenes állományokra, amit később úgy is letörölnénk. • Mivel a folyamatok „párhuzamosan” futnak, a FIFO-nak nem kell nagynak lenni.
42
• A pipe használata gyorsabb, mivel az a memóriában keletkező állományként jelenik meg (egy FIFO csupán 8 kB). • Az eredmény a cső végén már azelőtt megjelenhet, mielőtt az első program az összes bemenetét feldolgozná. A csővezetéket a shell számára a „|” jellel adhatjuk meg. ls | grep "minta" | sort | more Ebben a példában az ls parancs kimenetéből a grep program kiszűri azokat, amelyekben szerepel a „minta” string, majd az eredményt rendezi, és oldalakra tördelve megjeleníti. 3.3.6.
Parancshelyettesítés
Igen hasznos és érdekes szolgáltatása a shelleknek az ún. parancshelyettesítés. Ez lehetővé teszi, hogy az egyik program kimenetét a másik program paraméter listájaként használjuk. Ilyenkor a megfelelő parancsargumentumot „`. . . `” (visszafelé dőlő aposztróf) párba vagy „$(. . . )” jelek közé kell zárni. du `cat parameters.txt` Például az iménti parancs esetén a du parancs megmondja azon fájlok méretét, amelyek a „parameters.txt” állományban fel vannak sorolva. 3.3.7.
Parancssorozatok
Ha a parancsokat egymás után pontosvesszővel elválasztva írjuk, akkor úgynevezett parancssorozathoz jutunk. Így például a következő parancs először kiírja az aktuális dátumot, majd kilistázza a pillanatnyi katalógust. date; ls Parancssorozatot nem csak pontosvessző segítségével alkothatunk, hanem a „||” és a „&&” jelekkel is. Ekkor egy feltételesen végrehajtódó sorozathoz jutunk. A „||” és a „&&” jelek jelentése azonos a C nyelvben megszokottal. parancs1 || parancs2 parancs3 && parancs4 Vagyis az előző parancssorozatból a parancs2 csak akkor fog végrehajtódni, ha a parancs1 hamis megállási státusszal állt meg. A parancs4 pedig csak akkor fog végrehajtódni, ha a parancs3 igaz megállási státusszal állt meg. 3.3.8.
Szinkron és aszinkron folyamatok
Az eddigi példákban az egymás utáni parancsok egymást követve szinkron módon hajtódtak végre. Lehetőség van azonban aszinkron végrehajtásra is. Ha egy parancsot az „&” jel követ, akkor a shell
43
nem várja meg a parancs befejeződését, hanem a prompt jel kiadásával újabb parancsra várva azonnal visszajelentkezik, miközben a kiadott parancs aszinkron módon a shelltől leválasztva fut tovább. Pl. find / -name 'core' > eredmeny & Ebben az esetben a shell azonnal visszatér és új parancsra vár. A fájlkeresés a háttérben fut és az eredményt az „eredmeny” állományba írja. (A háttérben futó folyamatok kimenetét érdemes fájlba irányítani, hogy ne keveredjen össze más parancsok kimenetével.) A parancs futtatásakor a rendszer kiír egy ún. processz ID-t (pid) amellyel hivatkozhatunk később a háttérben futó folyamatra. 3.3.9.
Csoportosítás
A parancsokat zárójelekkel is csoportosíthatjuk. ( parancs1 ; parancs2 ) (date; ls) > lista & Ez utóbbi parancs kiírja a dátumot és az állományok listáját a „lista” állományba, és mindezt a háttérben teszi. 3.3.10.
A Bash shell további funkciói
A következőkben röviden áttekintjük a bash további lehetőségeit, programozását. 3.3.10.1.
Változók kezelése
A shellek az eddig megismert funkciókon túl változók kezelésére is alkalmasak. A változókat egyszerű string típusú tárolóként kezeli. Értékadás shell változónak: változó=érték Az érték beállítása a „=” jellel történik. (Előtte és mögötte nem lehet üres hely.) kutya=ugat Ha már beállítottuk a változót, akkor a „$” jellel a változó neve előtt hivatkozhatunk az értékre. $ kutya=ugat $ echo $kutya ugat A példánkban az echo parancsot használtuk, amely kiírja a paraméterként kapott szöveget. Mint látható, a változó helyére a shell behelyettesíti a változó értékét. Az echo parancs már az értéket kapja meg, és azt írja ki. Előfordul, hogy közvetlenül a változó után kell írnunk valamit. Ebben az esetben meg kell határoznunk a shell számára, hogy meddig tart a változó neve. Ezt a „{” és „}” jelekkel tehetjük meg.
44
$ kati=zsuzsi $ echo ${kati}ka zsuzsika A set parancsot kiadva kiírathatjuk a beállított változók listáját. A változót az unset paranccsal törölhetjük. Ebben az esetben, ha továbbra is használjuk, akkor a shell egy üres stringet helyettesít be. Szükség lehet arra is, hogy a shell által indított programok is megkapják a környezeti változók értékét, mert a rendszerről, vagy a felhasználó preferenciájáról tudhatnak meg információkat. Ilyenkor az export kulcsszóval tesszük számukra elérhetővé. TERM="VT100" export TERM Az előző két sort összevonva: export TERM="VT100" A programok számára kiexportált környezeti változókat az env paranccsal listázhatjuk ki.
Feladat 1. Hozzunk létre változót, majd írassuk ki az értékét! 2. Keressük meg a set parancs által adott listában! Nézzük meg az env parancs listájában! 3. Exportáljuk ki a változót, hogy a programok számára is elérhető környezeti változó legyen! 4. Újra nézzük meg mind a set, mind az env parancs listájában! 5. Töröljük a változót!
Feladat 1. Az mc programmal nyissunk meg egy szövegállományt szerkesztésre! Jegyezzük meg, hogy mit látunk! 2. Állítsuk be az EDITOR változó értékét „ joe”-ra, és exportáljuk ki! 3. Az mc programmal újból nyissuk meg az állományt szerkesztésre! 4. Töröljük az EDITOR változót!
3.3.10.2.
Speciális változók
A shellek rendelkeznek néhány speciális változóval is. Ezen változók speciális szerepe abból adódik, hogy vagy automatikusan kapnak értéket, vagy értékük befolyásolja a shell működését.
45
Változó
Jelentés
$#
Argumentumok száma
$*
Az összes argumentum
$@
Ua. mint $*, ha nincs "" jelek között7
$-
A shell által adott opciók
$?
Az utolsó parancs visszatérési értéke
$$
Processz szám
$!
Utolsó háttérben indított folyamat azonosítója
$0
Parancsállomány neve
$HOME
Home könyvtár neve
$IFS
Input mezőhatároló karakter
$MAIL
Levelesláda állomány
$CDPATH
Keresési út a cd parancshoz
$PATH
Keresési út a programok indításához
$PS1
Elsődleges prompt
$PS2
Másodlagos prompt 13. táblázat. A bash shell speciális változói
Feladat 1. Futtassuk le a true programot, majd nézzük meg a $? változó értékét! 2. Ismételjük meg az előbbi műveletet a false programmal is! 3. Írjuk ki a shell processz azonosítóját ($$)! 4. Állítsuk át a PS1 változó értékét a következőre: [\A \h:\w]\$ és értékeljük a hatását! (Az eredeti érték Fedorán: [\u@\h \W]\$, míg Ubuntun: \[\e]0;\u@\h: \w\a\]$debian_chroot:+($debian_chroot)\u@\h:\w\$.) 5. Vizsgáljuk meg a PATH változó értékét! Fűzzük a lista végére az aktuális könyvtár jelzését, hogy a rendszer a lefuttatandó programot ott is keresse!
3.3.10.3.
A shell indulási folyamata
Az első fájl, amelyet a shell betölt a bejelentkezéskor az /etc/profile. Ez az állomány tartalmazza az alapvető változó beállításokat a folyamatokhoz, és csak a rendszeradminisztrátor módosíthatja. A változók beállításán kívül parancsokat is futtathat a felhasználók bejelentkezésekor. A $HOME/.bash_profile hasonló feladatokat lát el, mint az /etc/profile, azonban ezt a felhasználó is módosíthatja. A felhasználó ebben az állományban beállíthatja a saját környezetét. (Mint az a nevében 7 "$*"
== "$1 $2 . . . ", de "$@" == "$1" "$2" . . .
46
is szerepel ez az állomány csak a bash shell esetén funkcionál. Léteznek azonban más állományok is más shellekhez.) A $HOME/.bashrc olyan beállításokat tartalmaz, amelyeket nem exportálunk ki az alfolyamatok számára. Az /etc/bashrc a rendszer szintű beállításokra szolgál és csak a rendszeradminisztrátor módosíthatja. Az /etc/bashrc a $HOME/.bashrc állományból hívódik, ezért a felhasználó dönthet akár úgy is, hogy nem használja.
Feladat Vizsgáljuk meg az előbb a felsorolt állományokat!
3.3.10.4.
Alias
Az alias parancs segítségével a felhasználó saját parancsokat hozhat létre, vagy leegyszerűsíthet gyakran használt parancsokat. alias p='ps aux' alias l='ls -l' Az alias parancs argumentum nélkül kiírja az aliasok listáját az aktuális környezetben. Az unalias parancs segítségével pedig megszüntethetjük az alias-okat. 3.3.10.5.
Parancs history
A HISTSIZE változó által megadott számú utolsó parancsot eltárolja a rendszer a .bash_history állományban. A history parancs lehetővé teszi, hogy kilistázhassuk a megadott számú bejegyzést. $ history 6 501 pwd 502 touch file 503 l 504 rm -f file 505 l 506 history 6 Az fc -s parancs lehetővé teszi, hogy megint lefuttassunk egy parancsot a listából. Használhatjuk a sorszámát vagy a szöveg kezdetét is, de a fel és le nyíllal is választhatunk a parancsok közül. $ fc -s pw pwd /home/tomcat
47
3.3.10.6.
Parancsállományok
A legtöbb felhasználó azt hiszi, hogy a shell csak egy interaktív parancsértelmező, pedig a parancsértelmezés valójában egy programnyelv része. Mivel a parancsvégrehajtásnak az interaktív és a programozott módját egyaránt a shellnek kell végrehajtania, ezért furcsa nyelvvé vált. A Linux rendszerben gyakran találkozhatunk parancsállományokkal, más néven shell scriptekkel. Egyszerűbb feladatokat gyakran gyorsabban elvégezhetünk velük, mintha programot írnánk. A rendszeradminisztrátorok különösen sokszor használják őket egyes funkciók elvégzésére. A legegyszerűbb változata, amikor parancsokat egymás után egy szövegállományba írjuk. Ekkor a shell egymás után végrehajtja őket. Az állományt kétféle képpen futtathatjuk: • Meghívunk egy shellt és paraméterként átadjuk az állományt és a futtatási paramétereit: bash állomány [argumentum...] • Vagy adunk futás jogot az állományra (x bit) és csak futtatjuk az állományt: állomány [argumentum...]
3.3.10.7.
Beépített parancsok
Korábban már volt szó arról, hogy a shellek beépített parancsokat is tartalmaznak. Azonban ezeknek csak egy részét alkotják a shell működésével kapcsolatos parancsok. A másik csoportot azok a parancsok adják, amelyek a shell programnyelvét adják. A következőben a bash shell parancsait tekintjük át röviden.
48
Parancs
Jelentés
break[n]
Ciklus elhagyása
continue[n]
Továbblépés a következő ciklusra
cd arg
Könyvtár váltás
echo arg
Az argumentum kiírása
eval arg
Az argumentum végrehajtása
exec arg
Az argumentum végrehajtása, de nem indul új shell
exit[n]
Megállás n értékkel
export var
A var változó kiexportálása
pwd
Az aktuális könyvtár elérési útjának kiírása
read var. . .
A var változóba olvas a standard bemenetről
readonly var
Csak olvashatóvá teszi a var változót
return[n]
Visszatérés függvényből
set[kapcs[arg]]
Kapcsolók beállítása
shift[n]
Pozícionális paraméterek léptetése
test
Feltétel kiértékelése
ulimit[-fp][n]
Limit beállítás állományokra
umask[ddd]
Alapértelmezett jogok
unset var
Változó megszüntetése
wait[n]
Várakozás az n. folyamatra 14. táblázat. A bash shell beépített parancsai
A break, continue, exit, return parancsok funkciója megegyezik más programozási nyelveknél használtakkal. 3.3.10.8.
Feltételek kiértékelése
A programok visszatérési értéke alapján elágazásokat, ciklusokat szervezhetünk. A 0 az igaz értéket, a nem 0 a hamis értéket jelenti. Azonban a test parancs segítségével lehetőségünk nyílik arra, hogy feltételeket adhassunk meg, és ez szolgáljon alapként az elágazáshoz. A feltételeket három csoportra oszthatjuk. Az első csoport a stringeket vizsgálja: Parancs
Jelentés
test s
Igaz, ha s nem null szöveg
test -z s
Igaz, ha s nulla hosszúságú szöveg
test -n s
Igaz, ha s nem nulla hosszúságú szöveg
test s1 = s2
Igaz, ha s1 szöveg egyezik s2 szöveggel
test s1 != s2
Igaz, ha s1 szöveg nem egyezik s2 szöveggel 15. táblázat. Stringek kiértékelése
49
A feltételek második csoportja a numerikus értékeket vizsgálja: Parancs
Jelentés
test n1 -eq n2
Igaz, ha n1 szám egyenlő n2 -vel (numerikus =)
test n1 -ne n2
Igaz, ha n1 szám nem egyenlő n2 -vel (numerikus !=)
test n1 -lt n2
Igaz, ha n1 kisebb mint n2 (numerikus <)
test n1 -le n2
Igaz, ha n1 kisebb vagy egyenlő mint n2 (numerikus <=)
test n1 -gt n2
Igaz, ha n1 nagyobb mint n2 (numerikus >)
test n1 -ge n2
Igaz, ha n1 nagyobb vagy egyenlő mint n2 (numerikus >=)
16. táblázat. Numerikus kiértékelés
A feltételek harmadik csoportja az állományok tulajdonságainak ellenőrzésére szolgál: Parancs
Jelentés
test -f f
Igaz, ha f egy létező állomány vagy könyvtár
test -r f
Igaz, ha f olvasható
test -w f
Igaz, ha f írható
test -d f
Igaz, ha f könyvtár
test -s f
Igaz, ha f létezik, és nem nulla hosszúságú
test -t fd
Igaz, ha fd egy megnyitott állomány leírója, és az egyben egy terminál
17. táblázat. Állomány-tulajdonságok szerinti kiértékelés
Ezeket a műveleteket kombinálhatjuk is a ! (tagadás), -o (vagy), -a (és) logikai műveletekkel, továbbá zárójelekkel csoportosíthatjuk is. A test parancsot „[”, „]” jelekkel is helyettesíthetjük az alábbi módon: [ n1 -eq n2 ] A szögletes zárójelek használata esetén figyeljünk arra, hogy a szögletes zárójelek és a feltétel között egy-egy szóköz van.
50
3.3.10.9.
Vezérlési szerkezetek
A shell tartalmaz olyan eszközöket, amellyel elágazásokat és ciklusokat hozhatunk létre a parancsállományon belül (de akár egy parancssorban is a „;” jel használatával). Most ezeket vesszük sorra. 3.3.10.9.1.
If feltétel
Az if feltétel használata esetén, ha a feltétel teljesül, vagyis a parancs visszatérési értéke 0, akkor a then ág hajtódik végre. Ha a feltétel nem teljesül, vagyis a parancs visszatérési értéke nem 0, akkor az else ág hajtódik végre. if <parancs> then <parancsok> else <parancsok> fi if test $1 -eq 1 then echo 'egy' fi if [ $1 -eq 1 ] then echo 'egy' fi Általában a test szögletes zárójeles változatával találkozhatunk az if feltételeként, de használhatunk más programot is, ha követi a fenti visszatérési érték szabályokat. 3.3.10.9.2.
For ciklus
A for ciklus eltér a más programozási nyelvekben általában használt szintaktikától. Itt egy érték listát adunk meg, amelyen egyesével végigmegy a ciklus. A megadott változónak átadja az aktuális értéket és meghívja a do és done közötti parancsokat. for i in w1 w2 ... do <parancsok> done for i in egy ketto harom do echo $i done
3.3.10.9.3.
While ciklus
A while ciklus működése olyan, mint más programozási nyelvek esetén: amíg a feltétel igaz végrehajtja a do és done közti parancsokat.
51
while <parancs> do <parancsok> done while test $i -le 5 do i=`expr $i + 1` done while [ $i -le 5 ] do i=`expr $i + 1` done
3.3.10.9.4.
Until ciklus
Az until ciklus is úgy működik, ahogy már más programozási nyelvek esetén megszokhattuk, vagyis a while-hoz képest negált a feltétel vizsgálat. until <parancs> do <parancsok> done until test $i -le 5 do i=`expr $i + 1` done until [ $i -le 5 ] do i=`expr $i + 1` done
3.3.10.9.5.
Case szerkezet
A case szerkezet a változó értéke szerint kiválasztja az azzal megegyező minta ágát, és végrehajtja a parancsokat. A „*” minta az alapértelmezett. case word in minta1) <parancsok>;; minta2) <parancsok>;; minta3) <parancsok>;; esac case $1 in 1) echo egy;; 2) echo ketto;;
52
*) echo sok esac 3.3.10.10.
Shell szkript példa
Egy szkript amely megszámolja a könyvtárban található állományokat az alábbiak szerint néz ki: #!/bin/bash # # file szamlalo # n=0 for i in * do if [ -f $i ] then n=$(expr $n + 1) fi done A szkriptek első sorában mindig megadjuk a futtató shell nevét általában elérési úttal a következő formában: #!<shell> A kommenteket a „#” jellel kezdődően írhatunk az állományba. A példában az n változó értékét 0-ra állítottuk. Ez után a for ciklus végiglépked az adott könyvtár bejegyzésein (mivel a * helyére a shell behelyettesíti a könyvtár állományait és könyvtárait). Az if feltételében megvizsgáljuk, hogy a bejegyzés egy állomány-e. Ha igen, akkor a számláló értékét eggyel megnöveljük.
Feladat Módosítsa a scriptet úgy, hogy a könyvtárban található „a” vagy „b” betűvel kezdődő, illetve az „a” vagy „b” betűvel végződő, futtatható állományokat számolja össze!
3.3.10.11.
Erőforrás kontroll
Korábban a beépített parancsok listájában már találkozhattunk az ulimit paranccsal. Ez a parancs lehetővé teszi, hogy korlátozzuk a shell és az általa futtatott programok erőforrás felhasználását. A parancs formátuma: ulimit [-SH] [opció limit]
53
Az -S és a -H opció határozza meg, hogy soft limitet, vagy hard limitet állítunk. A hard limitet ha már egyszer beállítottuk, akkor nem lehet növelni. A soft limit ezzel szemben megnövelhető egészen a hard limit szintjéig. Amennyiben nem adjuk meg, hogy soft vagy hard limitet állítunk, akkor mindkettő állítódik. A limit értéke egy egész szám, amelynek mértékegysége az állított paramétertől függ. Ezen kívül használhatjuk a hard, soft, és unlimited kulcsszavakat is, amelyek a hard limit, a soft limit, vagy a nincs limit értékeket jelentik. Az állítható paraméterek: Paraméter
Leírás
-a
Az aktuális limit értékek kiírása
-c
A core állomány8 maximális mérete
-d
A folyamatok adatszegmensének maximális mérete
-f
A shell által létrehozható állományok maximális mérete
-l
A maximum méret ami a memóriába blokkolható
-m
A maximum memória rezidens rész mérete
-n
A nyitott állományleírók maximális száma
-p
A csővezetékek mérete 512 B blokkokban
-s
Maximum stack méret
-t
A maximum processzoridő másodpercben
-u
Az egy felhasználó által indítható maximális processzek száma
-v
A shell által használható maximális virtuális memóriaméret 18. táblázat. Az erőforrás kontroll opciói
A méretek, ahol nem emeltük ki külön, ott 1 kB-os egységekben értendő. Amennyiben nem adjuk meg egyik opciót sem, akkor a -f opció az alapértelmezett.
8A
core állomány a processzek összeomlásakor a rendszer által generált memória pillanatfelvétel, amely alapján a gdb
hibakereső a fejlesztő számára hasznos információkkal szolgálhat. Azonban ezek a pillanatfelvételek a folyamattól függően jelentős méretűek lehetnek, ezért érdemes a méretüket korlátozni a rendszer védelmében. Természetesen, ha a korlátozás által az állomány csonka lesz, akkor a hibakereső számára már használhatatlan.
54
4.
Segédprogramok, folyamatok kezelése, chroot, a rendszer indulása, automatizált programindítás, log
4.1. 4.1.1.
Segédprogramok és szűrők A find parancs
A find parancs rekurzívan végignézi az adott könyvtárból nyíló alkönyvtárakat. Keresi bennük a kifejezésnek megfelelő állományokat, majd kiírja a talált állományok listáját, vagy feladatokat hajt végre az adott állományokon. A parancs formája: find <elérési út> A leggyakrabban használt eset, amikor megadott nevű állományokat keresünk a könyvtárak sűrűjében. $ find . -name fontos ./doksik/fontos ./fontos Nézzünk meg még néhány opciót, amelyekkel összetettebb keresési feltételeket adhatunk meg. Paraméter
Leírás
-name
Az állomány megfelel, ha a neve a fájl paraméterrel egyezik. A shell által használt állománynév helyettesítő szintaxis használható, de idézőjelek közé kell tenni, hogy ne a shell értelmezze.
-type
Az állomány típusát specifikálhatjuk.9
-user
Az állomány megfelel, ha az állomány tulajdonosa megegyezik a felhasználónévvel.
-nouser
Az állomány megfelel, ha nincs tulajdonosa regisztrálva.
-group
Az állomány megfelel, ha az állomány csoportja a megadott.
-nogroup
Az állomány megfelel, ha az állomány csoportja nincs regisztrálva.
-perm <jogosultság>
Az állomány megfelel, ha a joga megegyeznek a megadottal.
-perm -<jogosultság>
Az állomány megfelel, ha a jogosultság minden 1-es bitje az állomány jogaiban is 1.
-perm +<jogosultság>
Az állomány megfelel, ha a jogosultság valamelyik 1-es bitje az állomány jogaiban is 1.
-size n
Az állomány megfelel, ha az állomány n blokk hosszúságú (egy blokk 512 bájt).
55
Paraméter
Leírás
-empty
Az állomány vagy könyvtár megfelel, ha üres.
-amin n
Az állomány megfelel, ha utoljára n perce fértek hozzá.
-atime n
Az állomány megfelel, ha utoljára n napja fértek hozzá.
-cmin n
Az állomány megfelel, ha utoljára n perce módosult a státusza.
-ctime n
Az állomány megfelel, ha utoljára n napja módosult a státusza.
-mmin n
Az állomány megfelel, ha utoljára n perce módosították.
-mtime n
Az állomány megfelel, ha utoljára n napja módosították.
-exec <parancs>
Az állomány megfelel, ha a végrehajtandó program 0 visszatérési értékkel tér vissza. A parancs végét egy pontosvessző „;” jelzi, amit a shell miatt idézőjelek közé kell zárni. Az állománynevet „{}” jelekkel helyettesíthetjük. Használhatjuk úgy is, hogy a talált állományokra a megadott parancsot végrehajtsa.
-ok <parancs>
Megegyezik az -exec kapcsolóval, de a parancs végrehajtása előtt jóváhagyást kér a felhasználótól.
-print
Hatására az aktuális állomány teljes nevét kiírja.
-xdev
Hatására a find nem megy át másik kötetre (csatolt eszközre). 19. táblázat. A find kapcsolói
Az opciókat a következő jelekkel kombinálhatjuk: ! (nem), -a (és), -o (vagy). Továbbá zárójelekkel csoportosíthatjuk, azonban a zárójeleket idézőjelekbe kell tenni, hogy a shell ne értelmezze. Az n értékek helyén a számok mellett használhatjuk a + és - jeleket: n: Pontosan az adott szám. +n: Több (nappal ezelőtt) mint n. -n: Kevesebb (nappal ezelőtt) mint n.
Feladat 1. Keressük meg az állományrendszeren az egyik felhasználó szimbolikus linkjeit! 2. Keressük meg az állományrendszeren a felhasználó azon állományait, amelyre valakinek végrehajtási joga van!
9 b:
blokk speciális állomány; c: karakter speciális állomány; d: könyvtár; f: normál állomány; l: szimbolikus link; p:
named pipe; s: socket.
56
3. Keressük meg az állományrendszeren azokat a rejtett állományokat és könyvtárakat, amelyeket kevesebb, mint egy napja módosítottak! A find parancs -exec paraméterével programokat is lefuttathatunk az egyes állományokra. Ez lehet a keresést szolgáló állomány tesztelő program, de ha egy -a paraméterrel illesztjük a keresés végére, akkor keresés eredményein végrehajtott művelet is. A find a „{}” jelek helyére a talált állományok nevét helyettesíti be, és így hajtja végre a parancsot minden állományra. A parancsot pontosvesszővel kell zárnunk. Hogy a shell ne értelmezze idézőjelbe kell tennünk, vagy „\” jelet kell tennünk elé. Nézzünk egy példát, ahol a program futtatása az állomány tesztelését szolgálja! find -exec grep -q "alma" {} ";" -a -print És egy másik példát, ahol az eredmény állományokon végzünk el műveletet. find -name "*fontos" -a -exec ls -l {} ";"
Feladat Minden „fontos” nevű állományt nevezzünk át „fontos.old”-ra! Ha nem vagyunk benne biztosak, hogy minden állományra szeretnénk végrehajtani a parancsot, akkor hasznos az -ok paraméter használata az -exec helyett. 4.1.2.
A head és tail parancsok
A head parancs a megadott állomány vagy a standard bemenet első néhány sorát írja ki: head <állomány> ... Ha -n <szám> argumentum meg van adva, akkor ennek megfelelő számú sort ír ki, egyébként tíz sort. head -n 5 myfile ls -l | head -n 12 A -c <szám> paraméterrel megadhatjuk, hogy hány bájtot írjon ki az állomány elejéről. A tail parancs a megadott állomány vagy a standard bemenet utolsó néhány sorát írja ki: tail <állomány> Az -n <szám> argumentummal megadhatjuk, hogy az állomány utolsó hány sorát írja ki. Ha szám helyett a -c +<szám> kifejezést használjuk, akkor az állomány elejétől számított megadott sortól írja ki a tartalmat. A -c <szám> hasonlóan az utolsó bájtokat adja meg. tail -n 20 myfile Az -f opcióval is használhatjuk a tail parancsot, amely azt eredményezi, hogy a program nem áll le az állomány végénél, hanem végtelen ideig próbálkozik tovább olvasni. Ezáltal folyamatosan követ57
hetjük a kimenet állományok vagy log állományok változását. Ilyenkor a Ctrl+C billentyűkombinációval állíthatjuk le. 4.1.3.
A sort parancs
A sort az összes megnevezett állomány sorait együtt sorba rendezi, és a rendezés eredményét kiírja a standard kimenetre: sort <állomány> ... Ha nem adunk meg állományt, vagy ez a „-” karakter, akkor a standard bemenetet használja bemenetként a program. Az opciók mezőben használható paraméterek: Paraméter
Leírás
-b
A kezdő szóközöket és tabulátorokat figyelmen kívül hagyja a mezők határának meghatározásánál. Szótárrendezés. Csak a betűk, számjegyek és szóközök számítanak az összehasonlításban.
-d -f
Kis és nagy betű figyelmen kívül hagyása.
-k pos1<,pos2>
A rendezendő mezők.
-n
Numerikus rendezés.
-r
Megfordítja a rendezés sorrendjét.
-t <mezőhatároló>
A mezőhatároló karaktert adhatjuk meg a szokásos szóköz és tab helyett. 20. táblázat. A sort kapcsolói
Nézzünk néhány példát a sort használatára! (A példaállomány az „autok”.) $ cat autok lamborghini:2 ferrari:4 porsche:10 lotus:5 Egyszerű rendezés az első karakter alapján: $ sort autok ferrari:4 lamborghini:2 lotus:5 porsche:10 Rendezés a sorok második karaktere alapján:
58
$ sort -k 1.2 autok lamborghini:2 ferrari:4 porsche:10 lotus:5 A -t paraméterrel megadjuk, hogy a mezőhatároló karakter a „:”. Ezután a második oszlop alapján rendezünk, de karakteresen: $ sort -t: -k 2 autok porsche:10 lamborghini:2 ferrari:4 lotus:5 Most ugyanezt elvégezzük numerikusan: $ sort -t: -n -k 2 autok lamborghini:2 ferrari:4 lotus:5 porsche:10
4.1.4.
A uniq parancs
A uniq egy nagyon egyszerű, de sokszor használt parancs. A sort paranccsal elvégzett rendezés után a duplikált sorokat eltávolíthatjuk. A -d paraméterrel csak a duplikált sorokat írja ki egy példányban, az -u paraméterrel pedig csak a nem duplikált sorokat. 4.1.5.
A cmp és diff parancsok
Mind a cmp, mind a diff parancs az állományok összehasonlítására szolgál. Azonban míg a cmp parancs csak egyszerű byte összehasonlítást végez, addig a diff parancs a szövegállományok sokkal komolyabb összevetésére képes. A cmp parancs két állományt binárisan hasonlít össze. Kiírja ha az állományok eltérnek, és megadja az eltérés pozícióját. Használata a következő: cmp <-ls> állomány1 állomány2 A diff parancs ennél sokkal komolyabb összehasonlítást végez. Értelmezi a szövegállományokat és megpróbálja megadni, hogy mely sorokat kell lecserélni, hogy az egyikből a másikat kapjuk. Törekszik arra, hogy úgy adja meg az eltéréseket, hogy a lista minimális legyen. Az alábbi módon használhatjuk. diff állomány1 állomány2
59
Ha mind a két paraméter katalógus, akkor a diff először névsorba rendezi a katalógusokban található állományneveket, majd azokra a szöveges állományokra, amelyek különböznek, a normál módon lefut a program. diff könyvtár1 könyvtár2 Különböző opciókkal megadhatjuk, hogy az összehasonlításnál milyen karaktereket vagy sorokat hagyjon figyelmen kívül, milyen legyen a kimenet formátuma. Az -u kapcsoló használatával megadható, hogy a nem egyező sorok környezetét (az előtte és utána következő sorokat) is írja ki a kimenetre, ezáltal a különbségek még pontosabb meghatározását téve lehetővé. Szoftverfejlesztés esetén a diff nagy segítséget jelenthet a verziók kezelésénél, vagy a patch-ek előállításánál. A nagyobb szoftverek (pl. a Linux kernel) esetén jól bevált gyakorlat, hogy a diff által generált különbség állományokat (patch fájl) is letölthetővé teszik. Így ha már rendelkezünk a forrás állományok korábbi verziójával, akkor nem szükséges az egész csomagot újból letölteni, elegendő a különbségfájlt. Majd ez alapján a patch programmal elvégeztethetjük a módosításokat, hogy a csomagunk az új verzió állapotába kerüljön. 4.1.6.
A patch parancs
A patch-csel és az előzőekben tárgyalt különbségfájlokkal (patch fájlokkal) lehetőségünk nyílik a eltérő verziójú állományok frissítésére, vagy reverse patch-elésére. patch <patchelendő fájl> -i -o A megfelelő különbségfájl birtokában akár egész könyvtárakat, azaz a könyvtárban levő összes állományt is frissíthetjük. Ez esetben azonban vigyázni kell, hogy különbségfájlban és a munkaállomásunkon a megfelelő könyvtárakat adjuk meg. Egy patch tényleges alkalmazása előtt a parancsot a --dry-run kapcsolóval futtassuk, amellyel a patch a megadott argumentumokkal lefut ugyan, de ténylegesen nem frissíti a fájlokat. Ezt a módszert a hibák elkerülése végett érdemes alkalmazni. A --reverse vagy a -R kapcsolók használatával egy már frissített, vagy a különbségfájllal azonos verziószámú állományt visszaalakíthatunk a különbségfájl által leírt korábbi verzióra. 4.1.7.
A grep parancs
A grep (Global Regular Expression Print) parancs a megadott mintát keresi az állományokban, és az illeszkedő sorokat kiírja a standard kimenetre. A minta lehet egy egyszerű szöveg, azonban a grep képes a reguláris kifejezésnek nevezett, speciális jelentésű karakterekkel kiegészülő szövegminta használatára is. grep minta <állomány >... Ha egynél több állománynevet adtunk meg, akkor a megtalált sorok elé kiírja azt is, hogy melyik állományban vannak. Az alábbi opciókkal befolyásolhatjuk a grep működését, a mintaillesztési szabályt (-i, -w), vagy az eredményként megjelenő információkat (-l, -n, -v).
60
Paraméter
Leírás
-i
A kis- és nagybetűket azonosnak tekinti.
-l
Csak az állományok nevét írja ki.
-n
Minden kiírt sor előtt a sorszám is szerepel.
-v
Inverz működés: a nem illeszkedő sorokat írja ki.
-w
A mintát, mint szót keresi. 21. táblázat. A grep kapcsolói
Létezik két módosult változata az alap grep utasításnak: • Az egrep mintaillesztője a kiterjesztett reguláris kifejezéseket is ki tudja értékelni. (Egyenértékű a grep -E utasítással.) • Az fgrep mintaillesztője csak egyszerű szöveget használ. (Egyenértékű a grep -F utasítással.) 4.1.8.
Egyszerű reguláris kifejezések
A szövegek feldolgozása során gyakori feladat a mintaillesztés. A minta megadására az egyszerűbb használhatóság érdekében közös szintaktikát használnak a programok. Ezt hívjuk reguláris kifejezésnek. Egy szövegmintában általában minden karakter önmagát jelenti, azaz a mintában az adott helyen elő kell fordulnia, de egyes karaktereknek speciális a jelentése, így adhatunk meg bonyolultabb mintát. Karakter
Jelentés
\
Az utána írt speciális karakter is karakterként kerül a mintába, kivéve: újsor-jel, számjegy, „(” vagy „)”.
^
Sor eleje.
$
Sor vége.
.
Egy darab valamilyen karakter.
*
Nulla vagy többször az előtte levő karakter.
.*
Nulla vagy több valamilyen karakter.
[abc]
Valamelyik karakter a listából, hasonlóan, mint a shell-nél. Használható pl. [a-c] módon is.
[^abc]
Bármely karakter, ami nem „a” vagy „b” vagy „c”. 22. táblázat. Egyszerű reguláris kifejezések
Ezen karakterek egy részét a shell is értelmezi. Hogy ez biztosan ne okozzon problémát a minta stringet egyszeres idézőjelek közé célszerű tenni. A reguláris kifejezések metakarakterei hasonlóak a shelléhez, azonban akad néhány eltérés. Továbbá a reguláris kifejezések jóval több speciális karaktert tartalmaznak. Ez a lista a fenti táblázatban megadottnál bővebb, azonban itt csak a legáltalánosabbak, a grep parancs által is értelmezhetőeket soroltuk
61
fel. Az egrep esetében lehetőségünk van a többi kifejezést is használni, azonban ezekre most nem térünk ki. grep "minta$" szoveg Azokat a sorokat írja ki a „szoveg” állományból, amelyeknek a végén a „minta” szó szerepel. cat szoveg | grep '[pt]i.os' Olyan sorokra illeszkedik, amelyekben szerepel egy szövegrészlet, ahol az első betű „p” vagy „t”, majd „i”, egy meghatározatlan karakter és „os”. Például piros vagy tilos. ls -l | grep "^d" A long listából azokat a sorokat írja ki, amelyek „d” betűvel kezdődnek, vagyis a könyvtárakat.
4.2.
Folyamatok
A programok elindításakor létrejön egy folyamat, amely tartalmazza a program kódját, adatait és a környezeti beállításokat is (munkakönyvtár, környezeti változók stb.). Minden folyamathoz az operációs rendszer egy egyedi folyamatazonosítót (process ID) és egy folyamat csoportazonosítót (process group ID) rendel. Egy folyamatot (kivéve a legelső folyamatot, az úgynevezett init-et) mindig egy másik folyamat hoz létre. A létrehozó folyamatot szülő folyamatnak (parent process), a létrehozott folyamatot gyermek folyamatnak (child process) nevezzük. Az init folyamatot kivéve minden folyamatnak van szülője. A gyermek a szülő másolata, csak az azonosítója különbözik. Így többek közt örökli a megnyitott állományok leíróit, az umask, ulimit értékeit, szignálok kezelésére vonatkozó beállításokat. A szülő-gyermek reláció alapján egy fa struktúrát is felrajzolhatunk. Ezt a pstree paranccsal nézhetjük meg. Amennyiben egy szülő folyamat előbb szűnik meg, mint annak gyermek folyamatai, a gyermek folyamatok árvákká (orphan) válnak, és szülőjük automatikusan az init folyamat lesz. A folyamatok továbbá tudnak még a szülő folyamat azonosítójáról (parent process ID) is. 4.2.1.
A folyamatok monitorozása
A folyamatokat a ps paranccsal listázhatjuk ki. ps Alapértelmezésben a ps parancs csak azokat a folyamatokat listázza ki, amelyeket az adott terminálról indítottunk. A listában csak a folyamat azonosítója, a terminál, a státusz, az eltelt idő, és a parancs neve szerepel. Azonban opciókkal nagyban befolyásolhatjuk a kilistázott folyamatokat és a megjelenített információkat.
62
Paraméter
Leírás
-A
Hatására az összes folyamatról információt kaphatunk.
-N
Negálja a folyamatválasztást.
-a
A terminálokhoz kapcsolódó összes folyamat listáját kapjuk, csak a shellek nem szerepelnek benne.
a
Az adott terminál folyamatait listázza ki.
r
Csak a futó folyamatokat írja ki.
-u
A megadott felhasználó folyamatait listázza ki.
x
Azokat a folyamatokat is kiírja, amelyek nem tartoznak terminálhoz. 23. táblázat. Folyamatok kiválasztása ps-sel
Paraméter
Leírás
-f
Ún. teljes listát ad.
-j
Kiírja az ún. job control információkat is.
-l
Hosszú listaformátummal jeleníti meg.
-o
Felhasználó által definiált formátum.
j l
Lásd -j Lásd -l
o
Lásd -o
24. táblázat. A ps kimenetének formázása
A top parancs segítségével folyamatosan is monitorozhatjuk a folyamatokat. Alapértelmezésben a CPU használatának sorrendjében listázza ki az egyes processzeket, azonban ezt könnyen átrendezhetjük. Segítséget a „h” vagy „?” billentyűk leütésével kaphatunk. 4.2.2.
Háttérfolyamatok
A háttérfolyamat indítását már korábban is tárgyaltuk. parancs & Azonban ezt a módszert csak rövid folyamatok esetén használjuk, mert ha kilépünk a shellből, akkor a rendszer szignáljára leáll. A másik jellemzője, hogy a program kimenete ilyenkor a terminál. Hosszú folyamatok esetén a nohup parancsot használhatjuk. nohup parancs &
63
A nohup parancs megmondja a folyamatnak, hogy ne vegye figyelembe a hangup (SIGHUP (1)) és quit (SIGQUIT (3)) szignálokat. Ezáltal a folyamat tovább fut akkor is, ha a felhasználó kilép. (A szignálokat rövidesen bővebben is áttekintjük.) A nohup által indított folyamat kimenete nem kerülhet a terminálra, mert lehet, hogy a felhasználó rövidesen kijelentkezik. Ha a parancssorban nem irányítjuk át a kimenetet, akkor a nohup parancs automatikusan átirányítja a nohup.out állományba. Ha már létezik a nohup.out fájl, akkor hozzáfűzi a végéhez. Mivel minden folyamatnak kell, hogy legyen szülő folyamata, ezért amikor kilépünk a rendszerből, a nohup által indított folyamatnak az init folyamat lesz a szülője. 4.2.3.
Kommunikáció a folyamatokkal, megszüntetés
A kill parancs segítségével szignálokat küldhetünk a folyamatnak, így kommunikálhatunk velük. kill <-szignál> folyamatszám ... Ha nem adunk meg szignált, akkor az alapértelmezés a term (SIGTERM (15)) szignál. Ezzel a szignállal leállíthatjuk a folyamatot, ha nincsen maszkolva. Ha ez nem sikerül, akkor keményebb eszközhöz kell nyúlnunk, ez a kill (SIGKILL (9)) szignál. Ezt már nem maszkolhatják a folyamatok. Azonban óvatosan bánjunk vele, mert nyitott állományokat, vagy lockokat hagyhat maga mögött. A szignálokat a kill -l paranccsal listázhatjuk ki. Íme a legfontosabbak: Szignál
Leírás
SIGHUP (1)
Akkor generálódik, ha kilépünk, miközben a folyamat még fut.
SIGINT (2)
Interrupt karakter (Ctrl+C).
SIGQUIT (3)
Quit karakter (Ctrl+\).
SIGKILL (9)
A legerősebb szignál, a program ezt nem hagyhatja figyelmen kívül.10
SIGTERM (15)
Folyamatok leállítása. (Az alapértelmezett érték.)
25. táblázat. A legfontosabb szignálok
4.2.4.
Folyamat vezérlése a bash shellben
Néhány további műveletre is lehetőségünk nyílik a bash shell használata esetén. Az előtérfolyamatot felfüggeszthetjük a Ctrl+Z billentyűkombinációval. Ez nem szünteti meg a folyamatot, csak megállítja a pillanatnyi állapotában. Amikor megállítjuk a folyamatot, a shell megjelenít egy job számot, amivel később hivatkozhatunk rá. Ha háttérfolyamatként szeretnénk folytatni, akkor az a bg paranccsal tehetjük meg. 10 Használata
csak végső esetben javasolt.
64
bg <job> Ha megint előtérbe akarjuk hozni, akkor azt az fg paranccsal tehetjük meg. fg <job> A jobs paranccsal kilistázhatjuk a felfüggesztett- és háttérfolyamatokat. A job számot használhatjuk a kill parancs paraméterezésére is, így nem kell a processz azonosítót megjegyezni. kill <-szignál> <job>
4.2.5.
Prioritásállítás
Lehetőségünk van arra, hogy az egyes folyamatok prioritását módosíthassuk. Ezáltal megmondhatjuk a kernel processzütemezőjének, hogy mely taszkokat részesítse előnyben, és mely taszkok nem fontosak. A prioritást a renice paranccsal állíthatjuk be. renice <prioritás> <<-p> pid ...> <<-g> pgrp ...> <<-u> user ...> Egy, de akár több folyamatot is megadhatunk egyszerre. Felsorolhatjuk a folyamatok azonosítóját (-p pid), hivatkozhatunk folyamat csoportokra is (-g pgrp), vagy egy felhasználó összes folyamatának állíthatjuk a prioritását (-u user), vagy kombinálhatjuk is ezeket. A leggyakrabban használt alak, amikor csak egy folyamat prioritását módosítjuk: renice 20 1033 Ahol az 1033-as azonosítóval rendelkező folyamat nice szintjét 20-ra állítjuk. A nice parancs segítségével módosított nice szinten is indíthatunk programokat. nice -n <parancs> <arg1> <arg2> ... A 0 prioritás a folyamatok alapértelmezett prioritása. Ehhez képest a pozitív értékek egyre nagyobb előzékenységet jelentenek. A maximum érték a 20. Ha egy folyamat nice érték e 20, az azt jelenti, hogy csak akkor fut, amikor más folyamatnak nincs szüksége a processzorra. A felhasználók csak 0 és 20 között állíthatják az értéket. A rendszergazda ellenben mínusz értékeket is beállíthat egészen -20-ig. Ezzel megnövelheti a folyamat által kapott processzoridő arányát. Ezzel azonban óvatosan kell bánnunk, hogy ne szívjuk el az erőforrásokat más processzek elől.
4.3.
Chroot
Időnként szembekerülhetünk olyan problémával, hogy átmenetileg meg kellene változtatnunk a root könyvtár at egy program lefuttatásának idejére. Ennek egyik tipikus esete, amikor egy rendszer visszaállítás során felcsatolunk egy root partíciót valamely pontra a könyvtárstruktúrában. Majd ezen a köteten szeretnénk lefuttatni egy programot úgy, hogy a root könyvtár nak a kötet eredeti root könyvtár át lássa. Ilyenkor a megoldás a chroot parancs használata, amely indít egy olyan shellt, ami a megadott könyvtárat látja root könyvtár nak.
65
chroot <új gyökér könyvtár> A másik ok, amiért a gyökér könyvtárat átállíthatjuk egy program működési területének lekorlátozása. Így ha a szolgáltatást fel is törnék a támadók, az úgy gyökérnek megadott alkönyvtárnál nem juthatnak feljebb a könyvtárstruktúrában, ezáltal nem szerezhetnek hozzáférést a rendszer kényesebb részeihez.
4.4.
A rendszer elindulása
Egy operációs rendszer betöltődése, elindulása első pillantásra mindig is kicsit mágikus dolognak tűnik. Általában ha egy, a háttértárolón lévő programot szeretnénk betölteni, lefuttatni, akkor beírjuk a nevét a shellbe, vagy rákattintunk az ikonjára, és az operációs rendszer elindítja nekünk. Azonban hogyan történik mindez, amikor a gép indulásakor magát az operációs rendszert szeretnénk betölteni, elindítani? A Linux kernel betöltését és elindítását az ún. kernelbetöltő végzi el. Ilyen program a LILO, a LOADLIN, a GRUB stb. Ahhoz, hogy ez a program betöltődjön szükséges egy kis hardveres segítség. Általában a gép csak-olvasható memóriájában egy kis program foglal helyet (x86 architektúra esetén ennek neve BIOS ), amely megtalálja ezt a kernelbetöltőt, betölti és futtatja. Vagyis összegezve, egy kicsi beégetett program lefut és elindít egy valamivel nagyobb betöltő programot. Ez a betöltő program pedig elindít egy még nagyobb programot, nevezetesen az operációs rendszer kernel programját.11 A kernel manapság általában tömörített formában foglal helyet a lemezeken, és képes önmagát kitömöríteni. Így az első lépés a kernel kitömörítése, majd a folyamat a kitömörített kernel kezdő címére ugrik. Ezt követi a hardver inicializálása (memóriakezelő, megszakítás táblák stb.), majd az első C függvény (a start_kernel()) meghívása. Ez a függvény, amely egyben a 0-ás azonosítójú processz, inicializálja a kernel alrészeit. Az inicializáció végén a 0-ás processz elindít egy kernel szálat (a neve init), majd egy üresjárati ciklusba (idle loop 12 ) kezd, és a továbbiakban a 0-ás processz szerepe már elhanyagolható. Az init kernelszálnak, vagy processznek a processz azonosítója 1. Ez a rendszer első igazi processze. Elvégez még néhány beállítást (elindítja, a fájlrendszer szinkronizáló és swap kezelő folyamatokat, feléleszti a rendszer konzolt, felcsatolja a root fájlrendszer t), majd lefuttatja a rendszerinicializáló programot (nem keverendő a korábban említett processzel). Ez a program valamelyik a következők közül (az adott disztribúciótól függ): /etc/init, /bin/init, /sbin/init.13 Az init program az /etc/inittab konfigurációs állomány segítségével új processzeket hoz létre, és ezek további új processzeket. Például a getty processz létrehozza a login processzt, amikor a felhasználó bejelentkezik. Ezek a processzek mind az init kernel szál leszármazottai. 4.4.1.
GRUB
A GNU GRUB (GRand Unified Bootloader) egy jól használható, sok funkcióval rendelkező bootloader. Képes a szabad operációs rendszerek széles skáláját betölteni, de a bootloaderek láncolásával a zárt forráskódúakat is. 11 Lehetőség van arra, hogy a betöltő programokat még tovább láncoljuk. Ezáltal lehetővé válik a több operációs rendszert tartalmazó gépeken, hogy induláskor kiválaszthassuk a számunkra szükségeset. 12 Amikor a rendszernek nincs semmi feladata, az ütemező ezt az üresjáratban futó folyamatot futtatja. 13 Amennyiben egyik helyen sem találja meg a rendszer az init programot, akkor megpróbálja feldolgozni az /etc/rc állományt, és indít egy shellt hogy a rendszergazda megjavíthassa a rendszert.
66
A GRUB egyik fő tulajdonsága a flexibilitás. Több állományrendszert is tud értelmezni és kezelni, ezért anélkül is képes betölteni a kernelt, hogy a pozícióját előre megadnánk vagy letárolnánk. Induláskor a GRUB beolvassa a konfigurációs állományát. A konfigurációs állomány alapján egy menü interfészt jelenít meg (karakteresen, vagy grafikusan), ahonnan kiválaszthatjuk az indítani kívánt kernelt, vagy operációs rendszert. 4.4.1.1.
GRUB telepítése merevlemezre
A disztribúciók telepítéskor automatikusan telepítik a bootmenedzsert is. Azonban előfordulhat, hogy ezt utólag kézzel kellene megtennünk. Erre mutatunk most egy rövid példát. 1. Első lépésként el kell indítanunk a GRUB shell programját. # grub 2. A következő lépés, hogy megadjuk a GRUB root eszközét. Ez nem feltétlenül a root partíciót jelenti, hanem azt a partíciót, amely a GRUB állományait (stage1, stage2 stb.) tartalmazza. Ez Red Hat disztribúciók esetén a /boot/grub könyvtárat tartalmazó partíció. grub> root (hd0,0) A (hd0,0) az első meghajtó első partícióját jelöli. Ha nem vagyunk biztosak a partícióban, akkor meg is kereshetjük. grub> find /boot/grub/stage1 Figyeljünk arra, hogy ebben az esetben az állomány elérési útjának nem a rendszerünkben elfoglalt helyét kell megadnunk, hanem a partíció root könyvtár ához képest elfoglalt helyét. Vagyis ha a /boot könyvtár külön partíción helyezkedik el, akkor a parancs alakja: grub> find /grub/stage1 3. Ha beállítottuk a root eszköz t, akkor a következő lépés a GRUB telepítése. Egyrészt telepíthetjük a meghajtó boot szektor ába. grub> setup (hd0) Másrészt a partíció boot szektor ában is elhelyezhetjük. grub> setup (hd0,0) Ha a lépések végrehajtása során nem kaptunk hibaüzeneteket, akkor a rendszerünk indulásra kész.
67
4.4.1.2.
GRUB konfigurációs állomány
A GRUB konfigurációs állománya a telepítéstől függően általában /boot/grub/grub.conf
vagy
/etc/grub.conf helyen található meg. Tekintsük át néhány fontosabb parancsát! (A kommenteket itt is a sor eleji „# ” karakter jelzi.) # grub.conf generated by anaconda A menüből az első elem (nullától indexelődik) lesz az alapértelmezett. default 0 Ha 30 másodpercig nem ütünk le billentyűt, akkor a GRUB automatikusan elindítja az alapértelmezett menüpontot. timeout 30 Az egyes menüelemek konfigurációs részei az indított operációs rendszertől függnek. Egy Linux rendszer esetén: title Red Hat Linux (2.4.20-20.9) root (hd0,0) kernel /boot/vmlinuz-2.4.20-20.9 ro root=LABEL=/ initrd /boot/initrd-2.4.20-20.9.img Az első sor a menüben látható szöveg. Ezt követi a root partíció beállítása. Majd a kernel állomány neve és opciói, illetve az initrd állomány neve. Egy Microsoft Windows rendszer esetén: title MS Windows rootnoverify (hd0,1) chainloader +1 Az első sor itt is a menü szövegét tartalmazza. Majd beállítjuk a Microsoft Windows rendszer root partícióját. (A rootnoverify parancs annyiban tér el a root parancstól, hogy nem próbálja meg az állományrendszert felcsatolni.) Majd a partíció első blokkján található másik bootloadert töltjük be. Számos további parancsot is használhatunk a konfigurációs állományban. Ezekről a GRUB dokumentáció nyújt bővebb információt. 4.4.1.3.
GRUB2
Manapság a legtöbb disztribúció a GRUB 2-es verzióját használja, mely több ponton is eltér a korábbi verzióktól: • Ha a Linux rendszerünkön kívül nincs másik operációs rendszer a számítógépen, akkor alapesetben a GRUB menü meg sem jelenik. Ha mégis szükséges, akkor bootoláskor a Shift billentyű lenyomásával előhozható ez a menü, hogy pl. régebbi kernelt válasszunk, vagy recovery promptot kérhessünk.
68
• A GRUB által korábban használt menu.lst fájlt felváltotta a /boot/grub/grub.cfg.14 A grub.cfg fájl viszont több szkript kimeneteként jön létre, ezért nem szokás manuálisan szerkeszteni. Ehelyett az /etc/grub.d könyvtárban levő szkripteket, illetve az /etc/default/grub fájlokat lehet szerkeszteni, aztán az update-grub paranccsal legenerálni a grub.cfg-t, hogy a változtatások érvényre jussanak. • Az update-grub parancs minden egyes futtatáskor megnézi, vannak-e más operációs rendszerek a számítógépen (pl. Microsoft Windows), és ha talál, akkor azokat automatikusan elhelyezi a GRUB menüjében. A következőkben megnézzük, mit találhatunk egy olyan rendszer /etc/default/grub fájljában, amelyen csak egy Ubuntu, illtve csak egy Fedora disztribúció van telepítve. GRUB_DEFAULT=0 GRUB_HIDDEN_TIMEOUT=0 GRUB_HIDDEN_TIMEOUT_QUIET=true GRUB_TIMEOUT=10 GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" GRUB_CMDLINE_LINUX="" GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="Fedora" GRUB_DEFAULT=saved GRUB_CMDLINE_LINUX="rd.md=0 rd.dm=0 KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rd.lvm.lv=vg_szantaiivirtualbox/lv_root rhgb rd.luks=0 rd.lvm.lv=vg_szantaiivirtualbox/lv_swap LANG=en_US.UTF-8" GRUB_DEFAULT: Az alapértelmezetten beállított bejegyzés. Szám is megadható, ilyenkor a listában szereplő n. bejegyzés lesz az alapértelmezett. Szöveget is írhatunk ide, ami akkor hasznos, ha a gépünkön több operációs rendszer is van, amelyeket gyakran cserélgetünk. menuentry 'Example GNU/Linux distribution' --class gnu-linux { ... } Például a fenti ilyen bejegyzés alapértelmezetté tételéhez egyszerűen a következőt kell megadnunk: GRUB_DEFAULT='Example GNU/Linux distribution' A GRUB_DEFAULT opcióhoz használhatjuk a saved kulcsszót is. Ebben az esetben az alapértelmezett bejegyzést a grub-set-default, valamint a grub-reboot parancsokkal adhatjuk meg, vagy a GRUB_SAVEDEFAULT opció értékét true-ra állítva mindig az lesz az alapértelmezett bejegyzés, melyet utoljára választottunk 14 Fedora
rendszeren az /etc/grub2.cfg fájl.
69
A GRUB_DEFAULT alapértelmezett értéke 0. GRUB_TIMEOUT: Az alapértelmezett bejegyzés bootolása annyi másodperc után, amennyit itt megadunk. Az értékét 0 -ra állítva azonnal elindítja az alapértelmezetten beállított rendszert, míg -1 -es érték mellett a végtelenségig vár a felhasználó beavatkozására. GRUB_HIDDEN_TIMEOUT: Annyi másodpercet vár a GRUB a menü megjelenítésére, amennyit itt megadunk. Ha az itt megadott időtartam alatt nem nyomjuk le a szükséges billentyűt, akkor a rendszer bebootol. Alapértelmezetten nincs beállítva. GRUB_HIDDEN_TIMEOUT_QUIET: A GRUB_HIDDEN_TIMEOUT opcióval együtt használva a visszaszámlálást is elrejti a felhasználó elől. GRUB_DISTRIBUTOR: A GRUB disztribútorának megnevezése. GRUB_CMDLINE_LINUX: A menüben szereplő Linux kernelekhez tartozó parancssori argumentumok. GRUB_CMDLINE_LINUX_DEFAULT: A
GRUB_CMDLINE_LINUX_DEFAULT
kulcsszóval megadott argumentumokat a GRUB csak a normál módú indítás esetén alkalmazza, a helyreállítási módnál nem.15
Feladat 1. Nézzük meg az /etc/default/grub fájl tartalmát! 2. A következő paranccsal kérjük le az /etc/default/grub dokumentációját, és nézzük meg a fenti példában nem használt opciók jelentését!16 info -f grub -n 'Simple configuration'
4.4.2.
Az inittab állomány
A kernel a kezdeti feladatainak végrehajtása és a root állományrendszer csatolása után elindítja az init programot, amely gondoskodik a további rendszer inicializálási lépések végrehajtásáról. Ilyen feladatok a hálózati eszközök beállítása, a konzol konfigurálása, az USB eszközök inicializálása, az állományrendszerek ellenőrzése és felcsatolása stb. Majd ezután következik a különböző szolgáltatások elindítása, a virtuális konzolok, és esetleg az X felület létrehozása. Ezeket a feladatokat az /etc/inittab állomány alapján végzi el. 15 Amennyiben a GRUB_DISABLE_RECOVERY nincs bekapcsolva, a Linux kernelhez két menübejegyzés kerül: a normál, illetve a helyreállítási mód bejegyzése. 16 Fedorán ehhez először a man-pages.noarch csomagot kell telepítenünk, majd az info -f grub2 -n 'Simple configuration'
parancsot kiadnunk.
70
Az init program több futásszintet definiál. A futásszint egy konfigurációs összeállítás, amelyben összeállíthatjuk, hogy a rendszer egyes állapotaiban milyen szolgáltatások fussanak és melyek nem. A használható futásszintek a következők. Szint
Leírás
0
Fenntartott. A rendszer leállítása.
1
Fenntartott. Egy felhasználós mód. Minden hálózati és felhasználói szolgáltatás leáll. A felhasználók nem léphetnek be, csak a rendszergazda kap egy shellt a konzolon.
2
Többfelhasználós mód hálózat nélkül.
3
Többfelhasználós mód.
4
Nem használt.
5
Többfelhasználós mód, X felülettel.
6
Fenntartott. A rendszer újraindítása.
7–9
A Linux rendszerek esetén ezek is működő futás szintek, azonban ezt a dokumentumok általában nem említik. Ennek oka, hogy a tradicionális Unix rendszerekben csak a 0-6 futás szintek léteznek. 26. táblázat. Futásszintek
A 0, 1, 6 szintek a rendszer működéséhez vannak fenntartva. A többi futási szint lényegében az adminisztrátor által szabadon konfigurálható. Leírásuk inkább ajánlás, amely alapján célszerű beállítani a rendszerünket, illetve amit a disztribúciók készítői is szem előtt tartottak az alapértelmezett konfiguráció összeállításakor. Az /etc/inittab állomány sorainak szintaxisa a következő: :::<processz> Az azonosító egy egyedi 1–4 karakteres szöveg, amely a bejegyzést azonosítja. (Régi rendszereknél előfordul, hogy a limit két karakter.) Terminálok esetén az azonosítónak a tty előtag utáni résznek kell lennie. Például: tty1 esetén 1. Ellenkező esetben problémáink lehetnek a bejelentkezéssel. A futási szinteknek azon szintek listáját kell megadnunk, ahol az adott akciót végre kell hajtani. Az akció az init program által definiált műveleteket jelenti, melyeket a 27. táblázatban sorolunk fel.
71
Akció
Leírás
respawn
A processz mindig induljon újra, ha valamiért leállna.
wait
A processz egyszer induljon el, amikor az adott futási szintre lépünk, és az init várja meg amíg véget ér.
once
A processz egyszer induljon el, amikor az adott futási szintre lépünk.
boot
A processz a rendszer indulásakor induljon el. (A futási szint mezőt figyelmen kívül hagyja.)
bootwait
Mint a boot, csak az init megvárja, amíg véget ér. (A futási szint mezőt figyelmen kívül hagyja.)
off
Nem csinál semmit.
initdefault
Speciális bejegyzés. A kezdő futási szintet adja meg. Ha hiányzik, akkor az init rákérdez. (A processz mezőt figyelmen kívül hagyja.) A processz a rendszer indulásakor fog elindulni, még a boot és a bootwait előtt. (A futási szint mezőt figyelmen kívül hagyja.)
sysinit powerwait
A processz akkor fog végrehajtódni, amikor elmegy a tápfeszültség (szünetmentes tápegység használata esetén). Az init megvárja, amíg véget ér.
powerfail
Mint a powerwait, csak az init nem várja meg a végét.
powerokwait
Akkor fut le a processz, ha visszajött a tápfeszültség.
powerfailnow
Ez a processz akkor fog lefutni, ha a szünetmentes tápegység értesíti a gépet, hogy rövidesen kimerül.
ctrlaltdel
A processz akkor hajtódik végre, ha megnyomjuk a Ctrl+Alt+Del billentyűkombinációt. 27. táblázat. Az init által definiált műveletek/akciók
A processz mező egy végrehajtandó program elérési útját, és a paramétereit tartalmazza. Ez a program lehet szkript állomány is természetesen. Nézzük meg az /etc/inittab néhány sorát! A következő sor azt mondja meg, hogy induláskor az alapértelmezett futási szint a hármas legyen. id:3:initdefault: A következő sor indítja el közvetlenül az init program indulása után az /etc/rc.d/rc.sysinit szkriptet. Ez a szkript gondoskodik a korábban említett rendszer inicializációról. si::sysinit:/etc/rc.d/rc.sysinit A következő sorok futtatják le az egyes futási szintek szkriptjeit, amelyek a szolgáltatások elindításáról gondoskodnak. Ez a Red Hat rendszereken tulajdonképpen egyetlen szkript eltérő paraméterekkel. l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4
72
l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6 A Ctrl+Alt+Del billentyűkombináció lenyomására a shutdown program indul el, amely ebben a beállításban három másodperc múlva újraindítja a gépet. ca::ctrlaltdel:/sbin/shutdown -t3 -r now A következő sorok hozzák létre a virtuális terminálokat, amelyek között váltogathatunk az Alt+F1–F6 billentyűkombinációkkal. 1:2345:respawn:/sbin/mingetty tty1 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5 6:2345:respawn:/sbin/mingetty tty6 És végül a sor, amely az xdm (X Display Manager) programot az ötös futás szinten elindítja. A Red Hat rendszereken prefdm szkript választja ki az xdm programot, illetve valamelyik változatát majd lefuttatja. x:5:respawn:/etc/X11/prefdm -nodaemon
Feladat 1. Próbáljuk ki a futási szintek változtatását! 2. Vizsgáljuk meg az 1-es, 3-as, és 5-ös futási szinteket! 3. Változtassuk meg az alapértelmezett futási szintet, és nézzük meg hogyan indul el a rendszer! 4. Változtassuk vissza az alapértelmezett futási szintet az eredetileg is használtra!
4.4.3.
Upstart
Az Upstart a hagyományos /sbin/init daemon leváltására született eseményvezérelt megoldás, mely rendszerindításkor, illetve leállításkor gondoskodik az egyes szolgáltatások indításáról és leállításáról, továbbá futás közben is felügyeli azokat. A korábbi daemon alapját a System V Unix sysvinit nyújtotta. Az egyes szolgáltatásokhoz különböző futási szinteket rendeltek, azaz a különboző futási szinteken különböző alkalmazás-összeállítások futottak. Az /etc/init.d/rc script is System V alapú, vagyis az /etc/rc.d könyvtárakban szereplő scripteket sorban futtatja.
73
4.4.3.1.
Az Upstart működése
Az Upstart eseményeket küld, és fogad, melyekre az egyes szolgáltatások feliratkozhatnak. Ha olyan esemény, vagy események sora következik be, ami kielégíti egy szolgáltatás bizonyos követelményeit, az Upstart gondoskodik az adott szolgáltatás indításáról, vagy leállításáról. Amennyiben egy esemény több job indítását is kiváltja, akkor az Upstart ezeket „párhuzamosan” indítja el. Néhány a lehetséges események közül: control-alt-delete, deconfiguring-networking, desktop-shutdown, failsafe-boot,
graphics-device-added,
net-device-added,
net-device-removed,
net-device-up,
started,
starting, startup, stopped, stopping. Valójában a rendszerben helyet foglaló bármely folyamat küldhet eseményt az init daemonnak, vagyis az Upstart, a biztonsági megkötéseket figyelembe véve, kiterjedt felhasználásra ad lehetőséget.
Várakozás
Leállítás
Indítás
Futás
Újraindulás 4. ábra. A jobok életciklusának egyszerűsített modellje A várakozás és futás állapotok pihenő állapotok. Alapesetben a folyamat ebben az állapotban marad mindaddig, amíg egy rá hatással levő esemény be nem következik. A többi mind átmeneti állapot, melyek lehetővé teszik az egyes joboknak, hogy az indításukhoz, futásukhoz, leállításukhoz szükséges shell scripteket futtassanak. Az újraindulás állapotba olyan szolgáltatások kerülnek, amelyek valamilyen okból még azelőtt leálltak, mielőtt a számukra szóló leállítási esemény bekövetkezett volna, így a szolgáltatás újraindítása előtt ismét van lehetőség shell scriptek futtatására. [6] 4.4.3.2.
Upstart események
Az események a következő típusúak lehetnek: Signal: Aszinkron, nem blokkoló esemény. A kibocsátója folytatja futását, nem vár más jobokra, folyamatokra. Az eseményt küldő szemszögéből ez egy szimpla jelzésként fogható föl. Azaz az olyan
74
jobok, melyek egy ilyen esemény hatására elindulnak, a küldő jobra semmilyen hatással nincsenek, nem állítják meg, nem tartják fel, stb. Ilyen eseményt az initctl programmal tudunk küldeni: # initctl emit --no-wait mysignal Method: Blokkoló, vagyis szinkron esemény, melyhez általában valami task párosul. Az eseményt küldő job rendszerint valaminek az elvégzésére vár az esemény kibocsátása után, ezért minden esetben megvárja, míg az intictl visszatér. Az esemény kibocsátóját az initctl visszatérési értékéről (siker/hiba) minden esetben tájékoztatni kell, hogy annak megfelelően reagáljon. Method esemény küldése: # initctl emit mymethod Hook: Blokkoló, szinkron esemény, mely leginkább az előbb tárgyalt két eseménytípus keverékeként fogható föl, mivel a kibocsátó csak jelzésre használja az eseményt, mégis megvárja míg az initctl visszatér. Azaz az adott hook eseményre váróknak a kicsbocsátó hagy egy kis időt a „felkészülésre”. (Pl. az Upstart által kiadott starting, illetve stopping események, melyek egy job indulását, leállítását jelzik.)
Feladat Nézzük meg a starting és stopping események kézikönyv oldalait! man 7 starting man 7 stopping
4.4.3.3.
Upstart jobok
Egy jobot a konfigurációs fájlja írja le (<jobnév>.conf ), ami formátumát tekintve egy szekciókra bontott sima szövegfájl. Ezeket a konfigurációs fájlokat két helyen találhatjuk meg a fájlrendszeren, attól függően, hogy egy job rendszer job (system job) vagy felhasználói job (user job). [7] System Job: A rendszer jobok konfiguárciós állományai az /etc/init/ könyvtárban foglalnak helyet. A init daemon --confdir= opciójával ez a könyvtár felülbírálható, de ezt csak igen nagy körültekintéssel használjuk. User Job: Az Upstart 1.3-as verziója óta sima felhasználók is készíthetnek jobokat, amennyiben a jobok konfigurációs állományait a $HOME/.init/ könyvtárban helyezik el. Nézzük meg a network-interface job konfigurációs állományát!
75
# network-interface - configure network device # # This service causes network devices to be brought up or down as a result # of hardware being added or removed, including that which isn’t ordinarily # removable. description "configure network device" emits net-device-up emits net-device-down emits static-network-up start on net-device-added stop on net-device-removed INTERFACE=$INTERFACE instance $INTERFACE export INTERFACE pre-start script if [ "$INTERFACE" = lo ]; then # bring this up even if /etc/network/interfaces is broken ifconfig lo 127.0.0.1 up || true initctl emit -n net-device-up \ IFACE=lo LOGICAL=lo ADDRFAM=inet METHOD=loopback || true fi mkdir -p /var/run/network exec ifup --allow auto $INTERFACE end script post-stop exec ifdown --allow auto $INTERFACE Az egyes szekciók jelentése sorban: description: Az adott job egysoros, idézőjelek közé zárt, rövid leírása. emits: Megadja, hogy az adott job milyen eseményeket generálhat. Ha többet eseményt is generál, akkor azokat egyesével, több sorban kell megadni. start on: A job elindíási eseménye. stop on: A job leállítási eseménye. (Pl. stop on runlevel [016] vagy egy másik konkrét esemény esetén.)
76
instance: A változót, amely azonosítja egy job egyedi példányát, az instance kulcsszó segítségével adjuk meg. Ez leginkább akkor jó, ha egy jobot különböző argumentumokkal is szeretnénk futtatni. export: Változó kiexportálása minden olyan eseménynek, amelyet az adott job generál. (A kezdő „$” karaktert nem kell kiírni.) pre-start: A job futásához szükséges környezetet készíti elő (pl. ideiglenes könyvtárak kiürítése stb.). script: Lehetővé teszi, hogy a konfigurációs fájlba többsoros shell scripteket írhassunk. A script végét az end script blokkal jelezzük. post-stop: „Takarítás” a job leállítása után, hogy a rendszerben biztosan ne maradjon szemét. A fent említett szekciókon kívül természetesen még sok más is elérhető [7], de ezeket nem tárgyaljuk.
Feladat Nyissuk meg és elemezzük a System V inicializációs scriptek futtatásáért felelős job konfigurációs állományát! less /etc/init/rc-sysinit.conf
4.4.3.4.
Kompatibilitás
Mivel az Upstart egy merőben új megközelítés, és a rendszeradminisztrátorok többsége még a System V féle megközelítéshez szokott, valamint a piacon levő könyvek nagyrészében még éveking kell várni az Upstart részletes tárgyalásának megjelenésére, ezért a kompatibilitás nagyon fontos. Vagyis az Upstart képes futtatni a meglévő scripteket, így az egyes szolgáltatások készítőinek megvan a lehetőségük a fokozatos átállásra, illetve a régi módszernél való maradásra. [6, 7] Jelenleg a következő rendszerek használják az Upstart daemont: Ubuntu 6.10 és későbbi verziók, Fedora 9 és későbbi verziók, Debian (választható), Maemo, HP WebOS, Google Chromium OS, Google Chrome OS. 4.4.4.
Leállítás
Fontos, hogy kövessük a rendszerleállítás helyes módját, ha leállítunk egy Linux rendszert. Ha nem így teszünk, a fájlrendszerek megsérülhetnek, mivel a Linux csak időnként hozza szinkronba a lemez cache és a lemez tényleges tartalmát. Ez ugyan javítja a rendszer teljesítményét működés közben, de azt is jelenti, hogy egy rossz rendszerleállás (pl. hirtelen lekapcsoljuk a főkapcsolót) adatvesztést és rendszersérülést okozhat. Egy másik ok, ami az egyszerű kikapcsolás ellen szól, hogy egy többfeladatos (multitaskig) rendszerben sok processz futhat a háttérben, és ezekre az áram lekapcsolása szörnyű hatással lehet. A megfelelő rendszerleállítási (shutdown) eljárás esetén ezek el tudják menteni adataikat, nem csak meghalnak egy pillanat alatt. 77
A Linux rendszerekben a shutdown parancs szolgál a rendszer leállítására. Általában két módon szokás használni. • Ha olyan rendszert futtatunk, ahol mi vagyunk az egyetlen felhasználó, a shutdown használatának szokásos módja az, hogy kilépünk minden futó programból, kijelentkezünk minden virtuális konzolról, valahol bejelentkezünk rendszergazdaként, majd kiadjuk a shutdown -h now parancsot (a now helyettesíthető a „+” jellel és a percek számával, ha késleltetni akarjuk a leállást). • A másik mód akkor használatos, ha a rendszeren több felhasználó is van. Ekkor a shutdown -h +time <msg> használata célszerű, ahol time az az idő percekben mérve, amennyi múlva a rendszer leáll, az msg pedig egy rövid üzenet, amely a leállás okát magyarázza. # shutdown -h +10 'Új merevlemezt telepítünk. A rendszer rövidesen újraindul.' # Ez mindenkit figyelmeztet, hogy a rendszer tíz perc múlva leáll, és még az üzenetet is megkapják a felhasználók minden terminálon, melyen valaki bejelentkezett, és minden xterm ablakban is: Broadcast message from root (ttyp0) Wed Aug
2 01:03:25 1995...
Új merevlemezt telepítünk. A rendszer rövidesen újraindul. The system is going DOWN for system halt in 10 minutes !! A figyelmeztetés automatikusan megismétlődik a leállás előtt néhányszor, egyre gyakrabban, ahogy annak ideje közeledik. Amikor a rendszerleállás ténylegesen elindul, a gyökér kivételével minden fájlrendszer lecsatolódik, a felhasználók processzeit (ha még létezik olyan) megszakítja a rendszer, a daemonok leállnak, minden fájlrendszer lecsatolódik, és általában minden leáll. Amikor ez kész van, az init kiír egy üzenetet, hogy most már lekapcsolható a számítógép. Ekkor, és csakis ekkor szabad a kapcsoló után nyúlni. Néha még jól karbantartott rendszerekkel is megesik, hogy nem lehet megfelelően leállítani a rendszert. Például ha a kernel pánikol, vagy bármi más módon rendellenesen viselkedik, lehetetlen további parancsokat kiadni, így a rendszerleállási folyamat sem fog lefutni. Ekkor csak reménykedni lehet, hogy semmi sem sérül komolyan, majd lekapcsolni az áramot. Ha a probléma nem ennyire súlyos (pl. valaki egy fejszével szétverte a billentyűzetet), és a kernel, valamint az update rendesen fut, érdemes várni pár percet, hogy a cache puffer és a lemez tartalma biztosan szinkronba kerülhessen, majd azután lekapcsolni az áramot. Voltak, és talán még ma is akadnak olyanok, akik a rendszerleállítást a sync paranccsal szeretik elvégezni.17 Az elgondolás az, hogy háromszor kiadva a sync-et, majd megvárva, hogy minden lemezművelet befejeződjön, biztonsággal lekapcsolható a számítógép.18 Ha nincsenek futó programok, ez majdnem egyenértékű a shutdownnal. Azonban ezzel az eljárással a fájlrendszerek nem lesznek lecsatolva, ami sync kiírja a lemezre a cache puffert. oka, hogy háromszor kell kiadni a sync-et az, hogy a korai Unix rendszerek esetében a parancs háromszori begépelése általában elegendő időt adott a lemeznek a műveletek befejezésére. 17 A
18 Annak
78
problémát okozhat az ext2 fájlrendszer clean filesystem bitjénél. Ezen kívül az esetleges elfelejtett felhasználók és processzek sem tudnak szépen kilépni. Ezért az ún. „tripla sync” módszer nem ajánlott. [4, 5] 4.4.5.
Újraindítás
A rendszer újraindítása egyenértékű egy rendszerleállás, lekapcsolás, majd rendszerindítás egymás utáni kiadásával. Ennél egyszerűbb módszer megkérni a shutdownt, hogy indítsa újra a rendszert a leállás után. Ezt az -r opcióval érhetjük el. [4, 5] shutdown -r now
4.4.6.
„Elfelejtettük a jelszót, nem probléma, törjük fel!”
Időnként felmerülő probléma, hogy egyes ritkán használt gépeknek hajlamosak vagyunk elfelejteni a root jelszavát, és esélyünk sincs, hogy megtaláljuk valamelyik papírhalom alján azt a cetlit, amire ráírtuk. Ilyenkor valahogy jó lenne jelszó nélkül bejutni, és megváltoztatni. Az egyik lehetőségünk a rescue lemez használata, amikor egy kis rendszert állítunk fel a memóriában, ahonnan rendbe tehetjük a rendszerünket. Erről később a rendszer helyreállításánál fogunk beszélni. A másik lehetőség nem igényel semmilyen további segédeszközt. A GRUB és a kernel segítségével megoldható. A kernel indításakor egy paraméterrel megadhatjuk, hogy a rendszer az 1-es futási szinttel induljon. Ilyenkor nem kell bejelentkeznünk, rögtön egy root jogokkal rendelkező shellt kapunk a konzolon. Nézzük, hogyan is néz ez ki a gyakorlatban a GRUB 1-es verziója esetén! 1. A GRUB menüjének megjelenésekor válasszuk ki az indítani kívánt kernelt. 2. Az „e” gombbal eljutunk a menüelem szerkesztéséhez. 3. A kernelre vonatkozó sort keressük meg. 4. Az „e” gomb ismételt lenyomásával eljutunk a sor szerkesztéséig. 5. Egészítsük ki a kernel paramétereket a következővel: single 6. Ezek után a „b” gombbal bootolhatjuk a rendszert Természetesen az eddig tárgyalt eset ritkán fordul elő. Viszont ezek után láthatjuk, hogy a fontos rendszereknél milyen lényeges, hogy fizikailag megvédjük a konzolt. Megtehetjük, hogy a GRUB ezen funkcióit jelszóval védjük. Ebben az esetben azonban még továbbra is indíthatunk pendrive-ról, vagy CD-ről teljes értékű rendszereket, amellyel szintén rendszergazdai szinten férünk hozzá az állományokhoz. A BIOS beállításaival és jelszavaival megakadályozhatjuk természetesen ezt is, de igazi védelmet valójában csak az jelent, ha illetékteleneket nem engedünk a gép közelébe.
79
4.4.7.
A futásszintek szolgáltatásai
Az inittab állomány tanulmányozásánál már láthattuk, hogy létezik egy /etc/rc.d/rc szkript a Red Hat rendszerekben, amely minden futásszinten lefut a futásszint paraméterével. Ennek a parancsállománynak a feladata, hogy az /etc/rc.d/rc.d könyvtárstruktúra alapján az egyes futásszintekhez tartozó szolgáltatásokat elindítsa és leállítsa. Az /etc/rc.d/rc[0–6].d könyvtárak szimbolikus linkeket tartalmaznak az /etc/rc.d/init.d könyvtárban található szkript állományokra. Ezeknek a parancsállományoknak a közös jellemzője, hogy start paraméterrel meghívva őket elindítják a hozzájuk tartozó szolgáltatást: ./httpd start A stop paraméter hatására pedig leállítják azokat: ./httpd stop Az /etc/rc.d/rc szkript a futásszintek könyvtárában található szimbolikus linkek alapján hívja meg a szolgáltatások indító, leállító szkriptjét. A végrehajtott művelet függ a szimbolikus link nevétől, mely nevek három részből tevődnek össze: 1. Az első karakter (S vagy K) határozza meg, hogy indítjuk (start) a szolgáltatást vagy leállítjuk (kill). 2. Ezt követi egy kétjegyű szám. Ez határozza meg az egyes szolgáltatások indításának vagy leállításának sorrendjét. (A végrehajtásban a kisebb szám jelent elsőbbséget.) 3. Ezt követi a szolgáltatás neve. S85httpd K15httpd
4.4.7.1.
Kezelés kézzel
A szintaktika ismeretében akár saját kezűleg létrehozhatunk, illetve törölhetünk linkeket, és ezzel beállíthatjuk, milyen szolgáltatások induljanak el az adott futási szinten. (Ha egy futási szinten az adott szolgáltatást nem szeretnénk elindítani, akkor célszerű a leállítást beállítani, mert a egyébként a futásszintek váltása közben az adott szolgáltatás nem állna le.) 4.4.7.2.
A chkconfig program
A chkconfig program megkönnyíti az /etc/rc.d/rc[0–6].d könyvtárstruktúra kezelését. A program négy funkcióval rendelkezik: • új szolgáltatások bevonása a menedzseltek közé; • szolgáltatások eltávolítása a menedzseltek közül, 80
• az aktuális indítási információk kilistázása; • az indítások és leállítások módosítása. Az --add paraméterrel felvehetünk egy szolgáltatást a menedzseltek közé. Ezt a paramétert akkor szoktuk használni, amikor egy új szolgáltatást telepítünk a rendszerre. Ilyenkor az indító szkriptben található információk alapján a chkconfig beállítja az alapértelmezett indítási jellemzőket is. chkconfig --add httpd A --del paraméter hatására a chkconfig eltávolítja a szolgáltatást a menedzseltek közül, és letörli az összes linket az /etc/rc.d/rc[0–6].d könyvtárstruktúrából. chkconfig --del httpd A --list paraméterrel kilistázhatjuk egy vagy az összes szolgáltatás beállításait. chkconfig --list A --level opció segítségével beállíthatjuk, hogy egy szolgáltatás valamely futási szinten elinduljon-e vagy sem. Ha az opciót elhagyjuk, akkor a beállítás minden futási szintre érvényes. Az elindítást az on, a leállítást az off kulcsszóval állíthatjuk be. chkconfig --level 35 httpd on chkconfig httpd off
4.4.7.3.
A sysv-rc-conf program
A sysv-rc-conf program megkönnyíti az /etc/rc[0–6].d könyvtárstruktúra kezelését. Funkciója a szolgáltatások indításának és leállításának beállítása a különböző futásszintekre. Ahogy a 5. ábrán is látható a sysv-rc-conf igen barátságos felületet nyújt az egyes szolgáltatások menedzseléséhez. Amint átállítunk valamit a listában a sys-rc-conf megejti a változtatásokat, azaz a program nem vár a kilépésig, ezért körültekintéssel válasszuk meg az egyes futásszintek szolgáltatásait! A sysv-rc-conf programot a chkconfig szintaxisával is meghívhatjuk, ekkor felhasználói felület nélkül, a parancssorban menedzselhetjük a szolgáltatásokat.19
4.5.
Automatizált programindítás
A Linux rendszerben nem csak bootolás során indíthatunk programokat, hanem más előre meghatározott időben, vagy időközönként is. Így megtehetjük, hogy egyes erőforrás igényesebb feladatokat éjszakára időzítünk, amikor a szervert kevesen használják. De felhasználhatjuk arra is, hogy bizonyos időközönként automatikus tisztogató, információgyűjtő, archiváló programokat futtassunk. Azonban nem csak időpontokhoz köthetjük a folyamatok indítását, hanem a rendszer terheléséhez is. Beállíthatjuk hogy bizonyos terheltségi szint alatt futtasson a rendszer programokat. sysv-rc-conf parancssori szintaxisa megegyezik a chkconfignál tárgyaltakkal, de apróbb eltérések lehetnek. Ezért mielőtt használnánk, először mindig tanulmányozzuk a sysv-rc-conf manuál oldalát! 19 A
81
5. ábra. A sysv-rc-conf felülete 4.5.1.
Cron
A cron daemon segítségével ismétlődő feladatokat hajthatunk végre. Ennek meghatározására idő és dátum részekből állítunk össze egy feltételt. A cron feltételezi, hogy a rendszerünk folyamatosan működik. Vagyis a beállításoknak megfelelő időpontokban elindítja a programokat. Azonban ha ezt az időpontot lekési, mert a rendszer nem működött, akkor az indítás elmarad. A cron daemont a bootfolyamat során el kell indítanunk hasonlóan a többi folyamatosan futó szolgáltatáshoz. Az indító szkript általában az /etc/rc.d/init.d/crond. 4.5.1.1.
Konfiguráció
A cron szolgáltatás fő konfigurációs állománya az /etc/crontab. SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly
82
Az első sorok a környezeti változók beállításait tartalmazzák. A MAILTO változó értéke azt a felhasználót adja meg, ahova a cron a végrehajtott feladatok kimenetét küldi egy levélben. Ha értéke „""”, akkor nem készül jelentés a feladat végrehajtásáról. (A „#” karakterrel kezdődő sorok megjegyzésnek számítanak.) A további sorok a cron egy-egy feladatát jelentik a következő formában: <parancs> Az idő a 28. táblázatban felsorolt mezőkből áll. Idő
Formátum
Perc
0–59
Óra
0–23
hónap napja Hónap
1–31 1–12
hét napja
0–720
28. táblázat. A cron idő mezőjének formátuma
A mező értékei a következők lehetnek: • Használhatunk *-ot, amely az adott mezőre minden értéket jelent. • Megadhatunk tartományt: 1–3. • Megadhatunk listát: 1,3,5. • Lépték megadására is lehetőségünk van. Ezt a „/” jellel tehetjük. Ha például a hónap mezőbe a következőt írjuk: */2 akkor minden második hónapban hívódik meg a feladat. De tartományokkal is kombinálhatjuk. Például ha az óra mezőben a 7–12/2 értéket adjuk meg, akkor 7 és 12 között minden második órában teljesül a feltétel. A példában az egyes sorok a run-parts szkriptet futtatják, amely meghívja a paraméterként megadott könyvtárban található szkripteket. A sorok értelmezése: 01 * * * * root run-parts /etc/cron.hourly Minden óra 1 perckor végrehajtja az /etc/cron.hourly könyvtárban található szkripteket. 02 4 * * * root run-parts /etc/cron.daily Minden nap 4 óra 2 perckor végrehajtja az /etc/cron.daily könyvtárban található szkripteket. 22 4 * * 0 root run-parts /etc/cron.weekly Minden vasárnap 4 óra 22 perckor végrehajtja az /etc/cron.weekly könyvtárban található szkripteket. 20 A
0 és a 7 is a vasárnapot jelöli.
83
42 4 1 * * root run-parts /etc/cron.monthly Minden hó elsején 4 óra 42 perckor végrehajtja az /etc/cron.monthly könyvtárban található szkripteket. Ha ezektől eltérő időpontban szeretnénk meghívni egy programot, akkor azt külön sorban meg kell adnunk. Egyébként pedig használhatjuk a megadott könyvtárakat. Nem kell feltétlenül az /etc/crontab állományt módosítanunk. Az /etc/cron.d könyvtárban is elhelyezhetünk állományokat, amelyben a crontabhoz hasonlóan specifikálhatunk feladatokat. 4.5.1.2.
Felhasználók lehetőségei
Az /etc/crontab állományt csak a rendszergazda módosíthatja, de a felhasználóknak is lehetősége van rá, hogy használják a cron daemont. Ezt a crontab -e paranccsal tehetik meg. A következő parancs meghívja az EDITOR környezeti változó által megadott szövegszerkesztőt, amellyel létrehozhatunk egy saját crontab állományt. A program ezt Fedorán a /var/spool/cron, míg Ubuntun a /var/spool/cron/crontabs könyvtárban helyezi el a felhasználó nevével. 4.5.1.3.
A hozzáférés szabályozása
Az /etc/cron.allow és /etc/cron.deny állományokban felsorolhatjuk azokat a felhasználókat, akiknek engedélyezzük, vagy tiltjuk a cron szolgáltatás használatát. Szintaktikailag egy névlistát kell megadnunk, soronként egy-egy névvel. Ha egyik állomány sem létezik, akkor minden felhasználó számára engedélyezett. Ha létrehozzuk a cron.deny állományt, akkor csak az abban meg nem adott felhasználók számára lesz engedélyezett a szolgáltatás használata. A cron.allow állomány létezése esetén csak az abban felsorolt személyek használhatják a cront. 4.5.1.4.
A módosítások hatályba lépése
A módosítások során nem kell újraindítanunk a cron daemont, mivel minden percben megvizsgálja a változásokat az eddig tárgyalt konfigurációs állományoknál, és ez alapján frissíti a beállításait. 4.5.2.
At
Az at daemon a cronnal ellentétben az egyszer, bizonyos időpontokban végrehajtandó feladatokra lett kitalálva. Ezt a szolgáltatást az /etc/init.d/atd szkripttel indíthatjuk el a korábbiakhoz hasonló módon. A feladatokat itt az at parancs segítségével adhatjuk meg: at A futtatandó parancsokat a standard bemeneten írhatjuk be, vagy az -f paraméterrel adhatjuk meg a parancsfájl nevét. Az időt a 29. táblázatban felsorol módokon adhatjuk meg.
84
Idő
Formátum
óra, perc
ÓÓ:PP
éjfél
midnight
dél
noon
16:00
teatime
most
now
hónap, nap, év
HH NN ÉÉÉÉ (Az év opcionális.), HHNNÉÉ, HH/NN/ÉÉ, HH.NN.ÉÉ
+ <szám> <mértékegység>
pl. now + 3 hours 21
29. táblázat. Idő megadása az at parancs esetén
Ha nem adtuk meg az -f paramétert, akkor a parancs lefuttatásakor egy promptot kapunk. Itt megadhatjuk azokat a parancsokat, amelyeket végre szeretnénk hajtatni. A végét a Ctrl+D billentyűkombinációval jelezhetjük. A feladatok listáját az atq paranccsal nézhetjük meg, míg az egyes bejegyzéseket pedig az atrm paranccsal törölhetjük. 4.5.2.1.
A hozzáférés szabályozása
A jogosultságokat az /etc/at.allow és az /etc/at.deny állományokkal szabályozhatjuk. Ezek szintaxisa és funkcionalitása megegyezik a cron daemon hasonló állományaival, melyekről a 4.5.1.3.-ban ejtettünk szót. 4.5.3.
Batch
Az at csomag rendelkezik még egy további paranccsal is. A batch paranccsal megadhatunk olyan feladatokat, amelyeket a rendszer akkor fog végrehajtani, amikor az átlagos load érték Red Hat esetén 0,8, míg Ubuntu esetén 1,5 alá esik. A parancs lefuttatásakor a korábbiakhoz hasonlóan egy promptot kapunk, ahol megadhatjuk a parancsainkat. A végén egy üres sorban nyomjuk le a Ctrl+D gombokat. A másik lehetőség hogy -f paraméterekkel parancsállományokat adunk meg.
4.6.
Log mechanizmus
A log állományok információkat tárolnak a rendszer működéséről, a kernel, a szolgáltatások, az alkalmazások eseményeiről. Az ilyen könyvelések nagyon hasznosak lehetnek a rendszer problémáinak kiderítésében, vagy az illetéktelen tevékenységek felderítésében. Ebben a fejezetben a Linux logrendszerét tekintjük át röviden. Linux alatt a programok általában kétféle mechanizmust használnak a működési információik, eseményeik könyvelésére. Az egyszerűbb, de kevésbé flexibilis megoldás, amikor a program egy vagy több, 21 A
mértékegységek a következők lehetnek: minutes, hours, days, weeks.
85
a konfigurációs állományában beállított logfájlba jegyzi az információkat. Ezek az állományok általában a /var/log könyvtárban helyezkednek el, vagy ha nem, akkor célszerű úgy bekonfigurálni, hogy oda kerüljenek. Azonban az egyéni logolások mellett a Linux rendelkezik egy központi mechanizmussal, amely képes fogadni és tárolni a processzek eseményeit. Ennek neve rsyslog. 4.6.1.
Rsyslog
A rendszerben folyamatosan fut egy rsyslogd szolgáltatás (daemon), amely képes mind lokálisan, mind hálózaton keresztül fogadni az eseményeket. Ennek előnyei: • A programoknak nem kell külön implementálniuk a log állományok kezelését. • Mivel egy központi, konfigurálható helyre kerülnek az események, így az adminisztrátor a saját elgondolása szerint oszthatja szét őket. Ezáltal a kritikus eseményeket kigyűjtheti egy külön állományba. • A hálózati logolás révén kialakíthatunk egy központi szervert, amely képes akkor is megőrizni az események listáját, ha a gépünk összeomlott, vagy támadás áldozata lett. Az rsyslogd konfigurációs állománya az /etc/rsyslog.conf. Ez határozza meg a logolás szabályait. Minden szabálysor két mezőből áll. Az első mező az események egy csoportjának kiválasztására szolgál a szolgáltatás és az esemény prioritása alapján. A második mező a végrehajtandó műveletet adja meg az rsyslog számára. Ez általában egy állománynév, ahova az adott eseményt el kell tárolnia. A kiválasztó mező két részre osztható: <szolgáltatás>.<prioritás>. A szolgáltatást a következő kulcsszavak valamelyikével adhatjuk meg: auth, authpriv, cron, daemon, kern, lpr, mail, news, syslog, user, uucp és local0–local7. Az egyes programok a feladatkörüktől függően ezen azonosítók valamelyikével küldik el az eseményeiket. Így például minden email szerver a LOG_MAIL azonosítót csatolja az üzeneteihez. A prioritást is kulcsszavakkal adhatjuk meg. A következő lista a lehetőségeket tartalmazza növekvő sorrendben: debug, info, notice, warning, warn (ugyanaz, mint a warning), err, error (ugyanaz, mint az err ), crit, alert, emerg, panic (ugyanaz, mint az emerg).22 Az egyes szolgáltatások ezekkel a címkékkel jelzik üzenetük jellegét, fontosságát. Az rsyslog alapértelmezett működési metódusa az, hogy a kiválasztásnál azok az események felelnek meg, amelyeknek a prioritása megegyezik, vagy nagyobb a megadottnál. Az egyszerű szolgáltatás-prioritás pár megadásán kívül léteznek további lehetőségeink is: • A szolgáltatás vagy a prioritás helyett használhatunk „*” karaktert. Ez az összes szolgáltatást, illetve az összes prioritást jelenti. A prioritás helyén a none kulcsszó pedig azt jelenti, hogy egyik sem. • Akár több szolgáltatást is felsorolhatunk az adott prioritás szinthez vesszővel elválasztva. 22 Az
error, warn és panic kulcsszavak már érvénytelenek, nem használhatók.
86
• Kiválasztó mezők listáját is megadhatjuk egy művelethez „;” karakterrel elválasztva. Ilyenkor az egyes kiválasztó mezők módisíthatják is a listában korábbiak hatását. • Amennyiben csak egy bizonyos prioritás szintre szeretnénk a műveletet végrehajtani, akkor ezt a prioritás elé írt „=” jellel adhatjuk meg. • Negálhatjuk is a prioritás megadást a „!” jellel. Vagyis ebben az esetben minden olyan prioritást figyelmen kívül hagy, amely egyezik, vagy nagyobb a megadottnál. • Az „=” és „!” jeleket kombinálhatjuk is egy „!=” jellé. Ennek jelentése, hogy csak a megadott prioritás szintet hagyja figyelmen kívül. Az eseményekre végrehajtandó művelet leggyakrabban egy állományba való beleírás. De vannak további lehetőségeink is: • Kiírathatjuk a konzolra (/dev/console). • Kiírhatjuk felhasználók egy csoportjának a képernyőjére (felhasználónevek vesszővel elválasztva). • Elküldhetjük az összes bejelentkezett felhasználó képernyőjére („*”). • Átirányíthatjuk egy csővezetékbe (az állománynév elé egy „|” jelet kell tenni). • Elküldhetjük egy központi gépre („@” jel után hostnév). • A log bejegyzéseket MySQL, MS SQL, SQLite és Oracle adatbázisokba is küldhetjük. Nézzünk néhány példát a rendszer /etc/rsyslog.conf állományából! A kernel összes üzenete jelenjen meg a konzolon. kern.*
/dev/console
Minden info és nagyobb prioritási szintű üzenet kerüljön a /var/log/messages állományba. Kivéve a mail, authpriv, és cron szolgáltatások üzenetei. *.info;mail.none;authpriv.none;cron.none
/var/log/messages
Minden emerg prioritású üzenet minden felhasználónak megjelenik. *.emerg
*
Feladat Tanulmányozzuk az /etc/rsyslog.conf állományt, hogy megtudjuk az egyes log állományok nevét!
87
4.6.2.
Log állományok
Az rsyslog.conf állományból megtudhatjuk, hogy mely log állományok milyen információkat tartalmaznak. Vegyük sorra a legfontosabbakat: • A boot.log
tartalmazza a szolgáltatások elindításának és leállításának eseményét. (Az
/etc/rc.d/init.d könyvtárban található szolgáltatás szkriptek által küldött események.) • A cron.log állomány az időzített feladatokról szolgál információkkal. • A mail.err, mail.info, mail.log, mail.warn fájlok tartalmazzák a levelező szerver üzeneteit, könyvelését. • A messages tartalmaz szinte minden fontosabb rendszereseményt. (A legfontosabb logfájl!) • Az auth.log állomány a felhasználók bejelentkezésének könyvelése. 4.6.3.
Logrotate
Ha körülnézünk a /var/log könyvtárban, akkor láthatjuk hogy a log állományokból általában több példányt láthatunk. Ezeket a név után ponttal elválasztott szám különbözteti meg egymástól. Minél nagyobb a szám annál régebbi az adott log állomány. Ennek oka az, hogy nem őrizhetjük meg a könyveléseket örök időkre. Időnként a régi, elavult bejegyzéseket ki kell selejteznünk, ellenkező esetben egy idő után megtelne a merevlemezünk. A selejtezés legegyszerűbb módja, hogy a log állományokat időközönként átsoroljuk egyre régebbi kategóriákba (ez a számozás), és a legrégebbieket letöröljük. Ezt a műveletet a logrotate program végzi el automatikusan, magát a műveletet pedig log rotációnak nevezzük. A logrotate program beállításait az /etc/logrotate.conf állomány tartalmazza, míg az egyes szolgáltatásokra vonatkozó konfigurációkat az /etc/logrotate.d könyvtár.
88
5.
Csomagkezelés, X Window System, asztali környezetek
5.1.
RPM csomagkezelés
5.1.1.
Az rpm használata
A Red Hat által kifejlesztett csomagkezelő segítségével könnyen, gyorsan és egyszerűen tudjuk kezelni a rendszert felépítő csomagokat. Az RPM által nyújtott szolgáltatások közül néhány a teljesség igénye nélkül: • telepítés, eltávolítás, tesztelés és függőség figyelés; • frissítés; • információk lekérdezése telepített és nem telepített csomagokról; • bináris RPM csomag készítése forrás RPM csomagból; • RPM csomag készítése tgz csomagból. A következőkben ezeket a funkciókat tekintjük át röviden. 5.1.1.1.
Csomagok telepítése és eltávolítása
Az rpm minden egyes csomag telepítése vagy eltávolítása előtt ellenőrzi a csomag függőségi viszonyát és figyelmeztet, ha probléma van, valamint telepítés előtt a konfliktusokat is figyeli (pl. telepítve van-e már a csomag). Fontos és hasznos, hogy egyszerre több csomagot is megadhatunk. Ez a kényelmen túl, akkor hasznos, ha például két kölcsönösen függő csomagot szeretnénk telepíteni. Mindkét csomagot megadva, nem kapunk függőségi figyelmeztetést. Ha egy csomag telepítése vagy eltávolítása valamilyen ellenőrzési hiba miatt megakad, de tudjuk, hogy ez a probléma csak ideiglenes, használhatjuk a --force kapcsolót, hogy az rpm ne vegye figyelembe a hibát. Csak óvatosan bánjunk ezzel a kapcsolóval, mert az esetek döntő többségében igaza van a csomagkezelőnek! 5.1.1.1.1.
Telepítés
Csomag telepítésére az rpm program -i kapcsolójának használatával van lehetőség: # rpm -i eject-1.2-2.i386.rpm # Több információt kapunk, ha a -v kapcsolót is használjuk, ami több csomag egyidejű telepítésekor lehet hasznos. # rpm -iv *.rpm Installing eject-1.2-2.i386.rpm Installing iBCS-1.2-3.i386.rpm Installing logrotate-1.0-1.i386.rpm 89
# A -h kapcsoló használata még személetesebbé teszi a telepítés folyamatát. # rpm -ivh *.rpm eject
##################################################
iBCS
##################################################
logrotate
##################################################
# Ha valamiért még több információt szeretnénk kapni a telepítés közben használjuk a -vv kapcsolót. # rpm -ivv eject-1.2-2.i386.rpm D: installing eject-1.2-2.i386.rpm Installing eject-1.2-2.i386.rpm D: package: eject-1.2-2 files test = 0 D: running preinstall script (if any) D: setting file owners and groups by name (not id) D: ///usr/bin/eject owned by root (0), group root (0) mode 755 D: ///usr/man/man1/eject.1 owned by root (0), group root (0) mode 644 D: running postinstall script (if any) # Előfordul, hogy csak ellenőrizni szeretnénk, hogy egy csomag feltelepíthető-e, ekkor használhatjuk a --test kapcsolót, ami csak az ellenőrzéseket végzi el. # rpm -i --test eject-1.2-2.i386.rpm # A telepítés során természetesen különböző hibákkal is találkozhatunk. A következő példában egy régebbi csomagot próbálunk feltenni, holott már telepítve van egy frissebb. # rpm -i --test rpm-2.0.11-1.i386.rpm /bin/rpm conflicts with file from rpm-2.3-1 /usr/bin/gendiff conflicts with file from rpm-2.3-1 /usr/bin/rpm2cpio conflicts with file from rpm-2.3-1 /usr/bin/rpmconvert conflicts with file from rpm-2.3-1 /usr/man/man8/rpm.8 conflicts with file from rpm-2.3-1 error: rpm-2.0.11-1.i386.rpm cannot be installed # Ebben a példában pedig egy függőségi probléma látható. # rpm -i --test blather-7.9-1.i386.rpm failed dependencies: bother >= 3.1 is needed by blather-7.9-1 #
90
5.1.1.1.2.
Eltávolítás
Csomag eltávolítására az rpm program -e kapcsolóját kell használnunk. # rpm -e eject # Sikeres végrehajtás estén itt sincs semmi értesítés. A telepítéshez hasonlóan itt is használható a -v, -vv és a --test kapcsoló. # rpm -ev eject # # rpm -evv eject D: uninstalling record number 286040 D: running preuninstall script (if any) D: removing files test = 0 D: /usr/man/man1/eject.1 - removing D: /usr/bin/eject - removing D: running postuninstall script (if any) D: removing database entry D: removing name index D: removing group index D: removing file index for /usr/bin/eject D: removing file index for /usr/man/man1/eject.1 # # rpm -e --test bother removing these packages would break dependencies: bother >= 3.1 is needed by blather-7.9-1 #
5.1.1.2.
Frissítés
Két frissítési metódust ismer az RPM, az upgrade-et (-U) és a frissítést (-F). A különbség a két mód között, hogy frissítés esetén csak abban az esetben kerül fel a csomag, ha már volt belőle korábbi verzió telepítve a rendszerre. Mindkét esetben a frissítés felfogható egy telepítés és minden korábbi verzió eltávolításának egymás utáni alkalmazásával, így ugyanazok a kapcsolók használhatóak, mint a telepítésnél (-v, -h, -vv, --test, --force). # rpm -U eject-1.2-2.i386.rpm # # rpm -F eject-1.2-2.i386.rpm #
91
5.1.1.3.
Információk lekérdezése
A lekérdezés kapcsolója a -q, amit kiegészítő kapcsolókkal paraméterezve a csomagkezelő az információk széles palettáját nyújtja a felhasználó felé. Például információkat kérdezhetünk le a már feltelepített és a még fel nem telepített csomagokról. Szimplán a -q kapcsoló használatával a csomag teljes nevét tudhatjuk meg. # rpm -q bash bash-2.05b-20.1 # Az -a kapcsoló kilistázza az összes csomagot. # rpm -qa setup-2.5.25-1 bzip2-libs-1.0.2-8 e2fsprogs-1.32-6 openssh-server-3.5p1-11 sendmail-cf-8.12.8-9.90 mailman-2.1.1-4... # Az -f opció segítségével megkérdezhető, hogy egy adott fájl melyik csomaghoz tartozik. # rpm -qf /etc/ntp.conf ntp-4.1.2-0.rc1.2 # Az -l kapcsoló kilistázza a csomaghoz tartozó fájlokat. # rpm -ql time /usr/bin/time /usr/share/doc/time-1.7 /usr/share/doc/time-1.7/NEWS /usr/share/doc/time-1.7/README /usr/share/info/time.info.gz # Az -i kapcsoló információkat ad a csomagokról. # rpm -qi bash Name
: bash
Version
: 2.05b
Release
: 20.1
Relocations: /usr Vendor: Red Hat, Inc. Build Date: Wed 09 Apr 2003 03:02:36 PM CEST
Install Date: Wed 27 Aug 2003 11:59:11 PM CEST Group
: System Environment/Shells
Size
: 1619204
Build Host: stripples.devel.redhat.com
Source RPM: bash-2.05b-20.1.src.rpm License: GPL 92
Signature
: DSA/SHA1, Tue 10 Jun 2003 12:45:19 AM CEST, Key ID 219180cddb42a60e
Packager
: Red Hat, Inc.
Summary
: The GNU Bourne Again shell (bash).
Description : The GNU project Bourne Again shell (bash) is a shell or command language interpreter that is compatible with the Bourne shell (sh). Bash incorporates useful features from the Korn shell (ksh) and the C shell (csh) and most sh scripts can be run by bash without modification. Bash is the default shell for Red Hat Linux. # A -p kapcsoló lehetővé teszi, hogy egy RPM csomagot adjunk meg információforrásként. # rpm -qlp ulogd-0.97rk-3.i386.rpm /etc/rc.d/init.d/ulogd /usr/lib/ulogd /usr/lib/ulogd/ulogd_BASE.so /usr/lib/ulogd/ulogd_LOGEMU.so /usr/lib/ulogd/ulogd_OPRINT.so /usr/lib/ulogd/ulogd_PWSNIFF.so /usr/sbin/ulogd /usr/share/doc/ulogd-0.97rk /usr/share/doc/ulogd-0.97rk/AUTHORS /usr/share/doc/ulogd-0.97rk/COPYING /usr/share/doc/ulogd-0.97rk/README /usr/share/doc/ulogd-0.97rk/ulogd.a4.ps /usr/share/doc/ulogd-0.97rk/ulogd.conf.sample /usr/share/doc/ulogd-0.97rk/ulogd.html /usr/share/doc/ulogd-0.97rk/ulogd.txt #
5.1.2.
Csomagok fordítása, készítése
5.1.2.1.
Forrás csomag lefordítása
Feladat Töltsük le az eject-*.src.rpm forrás csomagot és telepítsük fel! (Az /usr/src/redhat/SOURCES/ könyvtárban megtaláljuk a forrást.) # ./configure # make # make DESTDIR=/tmp install
93
5.1.2.2.
Bináris RPM készítése forrás RPM-ből
Előfordul, hogy csak a forrás RPM csomag áll rendelkezésünkre, azonban ilyenkor is lehetőségünk van bináris csomag előállítására a forrás csomagokból. # rpmbuild --rebuild eject-2.0.13-5.src.rpm
5.1.2.3.
A spec fájl
Ebben a fejezetben az RPM csomagmenedzsment spec fájlját tárgyaljuk röviden. A spec fájl tartalmazza egy adott forráscsomagban található szoftver elkészítési lefordításához és telepítéséhez szükséges parancsokat és lépéseket, valamint a telepítendő binárisok listáját. A spec fájlok elnevezése a következő konvenció szerint történik: --.spec. Ez biztosítja, hogy ugyanazon forráscsomag különböző verziójú változatainak használata esetén a spec fájlok ne íródjanak felül. Egy egyszerű spec fájl (eject-2.0.2-1.spec): Summary: A program that ejects removable media using software control. Name: eject Version: 2.0.2 Release: 3 Copyright: GPL Group: System Environment/Base Source: http://metalab.unc.edu/pub/Linux/utils/disk-management/ eject-2.0.2.tar.gz Patch: eject-2.0.2-buildroot.patch BuildRoot: /var/tmp/%{name}-buildroot %description The eject program allows the user to eject removable media (typically CD-ROMs, floppy disks or Iomega Jaz or Zip disks) using software control. Eject can also control some multidisk CD changers and even some devices’ auto-eject features. Install eject if you’d like to eject removable media using software control. %prep %setup -q %patch -p1 -b .buildroot %build
94
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS" %install rm -rf $RPM_BUILD_ROOT mkdir -p $RPM_BUILD_ROOT/usr/bin mkdir -p $RPM_BUILD_ROOT/usr/man/man1 install -s -m 755 eject $RPM_BUILD_ROOT/usr/bin/eject install -m 644 eject.1 $RPM_BUILD_ROOT/usr/man/man1/eject.1 %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-,root,root) %doc README TODO COPYING ChangeLog /usr/bin/eject /usr/man/man1/eject.1 %changelog * Sun Mar 21 1999 Cristian Gafton - auto rebuild in the new build environment (release 3) * Wed Feb 24 1999 Preston Brown - Injected new description and group. A következőkben a spec fájl egyes részeit tekintjük át. 5.1.2.3.1.
A header szekció
A spec fájl fejrésze a következő részekre bomlik, melyeket pontosan ebben a sorrendben kell specifikálni: Summary, Name, Version, Release, Copyright, Group, Source, Patch, BuildRoot és %description. Summary: A csomag egysoros leírása. Name: Az RPM csomag neve. Version: Az RPM csomag verziószáma. Release: Az RPM csomag kiadási száma. Copyright: A csomag szerzői joga. Általában különböző licencek megjelölését találhatjuk itt, de tartalmazhatja a következő stringek valamelyikét is, attól függően, hogyan áll a csomag szerzői jogi státusza: public domain, distributable, vagy commercial. 95
Group: A magasabb szintű csomagkezelőknek szánt lista, amely megmondja, hogy az adott csomag milyen csoportba tartozik. A csomagok kategóriái a /usr/share/doc/rpm-/GROUPS fájlban találhatók. Source: Az eredeti forrásfájl helye. (A rendszeren levő fájl nevének meg kell egyeznie az eredetivel.) Patch: Az a hely, ahol patch fájl található, ha esetleg még egyszer le kellene tölteni. (Az itt szereplő fájlnévnek meg kell egyeznie azzal, amellyel a patchet készítjük.) BuildRoot: A csomag lefordítására és telepítésére szolgáló root könyvtár. %description: A leírás mező nem illeszkedik a fejrészben található többi leíráshoz, de itt szokás megadni a tartalmát, ami nem más mint a csomag többsoros, átfogó leírása. 5.1.2.3.2.
Prep
A spec fájl második szekciója, amely a forrás csomag lefordításának és telepítésének előkészítésére szolgál. Itt lehet az egyes forrásfájlokat patchelni, a megfelelő beállításokat elvégezni. A prep szekcióban két makróval találkozunk: %setup: Az első makró, amely általában nem tesz mást, mint kicsomagolja a forrást, és belép annak könyvtárába. %patch: A második makró, amely a patchelés folyamatát hivatott automatizálni. 5.1.2.3.3.
A build szekció
Ebbe a részbe kerülnek azok a parancsok, amelyek a forrás lefordításához szükségesek. Az itt megadott parancsok átadódnak a shellnek, így a shellben használható parancsok bármelyike itt is használható.
Megjegyzés Az aktuális munkakönyvtár minden egyes szekció elején a forrás könyvtár legfelső szintjére ugrik. Természetesen be lehet lépni az alkönyvtárakba, ha szükséges. Az RPM_OPT_FLAGS változó a /usr/lib/rpm/rpmrc értékeivel töltődik fel. Ha ezt a változót használjuk, ellenőrizzük, hogy az előre beállított értékek megfelelőek-e. 5.1.2.3.4.
Az install szekció
Ide kerülnek azok a parancsok, amelyek a telepítéshez szükségesek. (Az aktuális munkakönyvtár a forrást tartalmazó legfelső könyvtár.) Az RPM_BUILD_ROOT változóban érhető el a fejrészben megadott Buildroot könyvtár. Az RPM_BUILD_ROOT használata nem kötelező, de az egységes kezelhetőség, és a hibák elkerülése végett ajánlott.
96
5.1.2.3.5.
A clean szekció
A csomag elkészítése előtt érdemes gondoskodni arról, hogy az RPM_BUILD_ROOT változó által megadott könyvtárban az előző telepítés után maradt fájlokat töröljük, nehogy ez befolyásolja a jelenlegi telepítésünket.
Megjegyzés Mielőtt tisztogatni kezdenénk érdemes megnézni, hogy mi van beállítva a RPM_BUILD_ROOT változóban, nehogy véletlenül a gyökér könyvtárban (/) kezjünk el törölgetni.
5.1.2.3.6.
Opcionális telepítés, eltávolítás előtti és utáni szkriptek
Ebbe a részbe azokat a szkripteket helyezhetjük, melyeket a csomagok telepítése, eltávolítása előtt, illetve után szeretnénk lefuttatni. (Szükség lehet pl. az ldconfig lefuttatására olyan bináris csomagok telepítése esetén, amelyek megosztott könyvtárakat is tartalmaznak.) Ebben a következő négy makró van a segítségünkre: %pre: A telepítés előtt végrehajtandó szkriptek indítását végző makró. %post: A telepítés után végrehajtandó szkriptek indítását végző makró. %preun: Az eltávolítás előtt végrehajtandó szkriptek indítását végző makró. %postun: Az eltávolítás után végrehajtandó szkriptek indítását végző makró. A fenti szkriptek gyakorlatilag sima shell szkriptek, de nem kell bennük feltüntetni a shell eléréi útját (#!/bin/sh). 5.1.2.3.7.
A files szekció
Ebben a részben kell felsorolni mindazokat a fájlokat, amelyeket a bináris csomag tartalmaz. A követező makrók állnak rendelkezésünkre: %doc: A %doc makró a forrás csomag azon dokumentációs fájljainak felsorolására szolgál, amelyeket szeretnénk telepíteni. A dokumentációs fájlok az /usr/doc/$NAME-$VERSION-$RELEASE struktúrában kerülnek elhelyezésre. %config: A csomag konfigurációs fájljai. %dir: Azok a könyvtárak kerülnek ide, amelyek majd a bináris csomagban is benne lesznek. %defattr: A defattr kulcsszó után következő fájlok alapértelmezett attribútumait (mód, tulajdonos, csoport sorrendben) állítja be.
97
Megyjegyzés A files szekcióban megadott könyvtárak minden fájlja bekerül a bináris csomagba. Ha véletlenül megadnánk a /usr/bin könyvtárat, akkor az abban megtalálható összes fájl is bekerülne a bináris csomagunkba.
5.1.2.3.8.
A changelog szekció
Ez a log tartalmazza azokat a változtatásokat, amelyek a csomag előző verziója óta történtek. Ha egy meglévő RPM csomagot módosítunk, akkor itt kell feltüntetnünk a változtatásainkat. A log formátuma igen egyszerű, de fontos betartani a következő megkötéseket, miszerint minden új logbejegyzést „*” karakterrel kell kezdeni, meg kell adni a módosítás dátumát, a módosító nevét és emailcímét. A dátumot a következő formában kell megadni: <év>. A dátumot, pontosan ebben a formátumban, a következő parancs kiadásával kaphatjuk meg. [8] date +"%a %b %d %Y"
5.1.2.4.
Bináris RPM készítése tgz forrásból
Vannak olyan programok, amik csak tgz formátumú forrás csomagokban állnak rendelkezésre. Amennyiben a csomagban található spec fájl, szintén készíthető bináris RPM csomag, amit már könnyen beilleszthetünk rendszerünkbe. Ha valaki ügyes akár saját maga is készíthet egy egyszerűbb SPEC fájlt. # rpmbuild -ta autospec-0.8.tar.gz A kész csomag az /usr/src/redhat/RPMS/noarch könyvtárban található. 5.1.3.
A yum használata
Az rpm segítségével ugyan elvileg mindent el tudunk végezni, ami a telepítésekhez és eltávolításhoz szükséges, de használata olykor igen kényelmetlen, mivel nekünk kell a szükséges RPM csomagokat felkutatnunk. Erre a problémára megoldást jelent a yum (Yellowdog Updater Modified) program. A yum egy adatbázisban tárolja, hogy az RPM csomagokat hol kell keresnie. Amikor egy új programot szeretnénk telepíteni csak annyit kell tennünk, hogy megmondjuk a yumnak a csomag nevét, és a yum tudni fogja, hogy az adott csomaghoz milyen fájlt melyik adatbázisból töltheti le. Ha a telepítéshez más csomagokra is szükség van akkor azokat is megkeresi és feltelepíti. Csomagok telepítésekor és eltávolításakor a yumnak egyszerre akár több csomagot is megadhatunk kényelmesebbé téve a csomagok menedzselését. Hogy mindez működhessen meg kell mondanunk az yumnak, hogy hol talál RPM csomagokat. Ezt az információt az /etc/yum.conf, illetve az /etc/yum.repos.d könyvtárban levő fájlokban tárolja el. A yum figyelmen kívül hagyja a kikommentezett (a „#” karakterrel kezdődő) sorokat.
98
Ha bármely yum parancsnál a -v kapcsolót is használjuk, akkor minden tranzakcióról részletes információt kaphatunk. yum -v <parancs>
5.1.3.1.
Csomagok telepítése és eltávolítása
5.1.3.1.1.
Telepítés
Csomag telepítésére a yum program install kulcsszavának használatával van lehetőség. yum install ... # yum install robotfindskitten Loaded plugins: downloadonly, langpacks, presto, refresh-packagekit Adding en_US to language list Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package robotfindskitten.i686 0:1.7320508.406-3.fc12 set to be installed --> Finished Dependency Resolution Dependencies Resolved ======================================================================= Package
Arch
Version
Repository
Size
======================================================================= Installing: robotfindskitten
i686
1.7320508.406-3.fc12
fedora
34 k
Transaction Summary ======================================================================= Install
1 Package(s)
Total download size: 34 k Installed size: 58 k Is this ok [y/N]: y Downloading Packages: Setting up and reading Presto delta metadata Processing delta metadata Package(s) data still to download: 34 k robotfindskitten-1.7320508.406-3.fc12.i686.rpm Running rpm_check_debug 99
|
34 kB
00:00
Running Transaction Test Transaction Test Succeeded Running Transaction Installing
: robotfindskitten-1.7320508.406-3.fc12.i686
1/1
Installed: robotfindskitten.i686 0:1.7320508.406-3.fc12 Complete! # 5.1.3.1.2.
Eltávolítás
Csomag eltávolítására a yum program remove kulcsszavának használatával van lehetőség. yum remove ...
5.1.3.2.
Frissítés
A check-update parancsot használva megtudhatjuk, hogy létezik-e frissíthető csomag a rendszerünkön. Ha létezik, akkor a yum 100-as visszatérési értékkel áll meg, és egy listát is készít a frissíthető csomagokról, ha nincs frissíthető csomag, akkor a visszatérési érték 0. yum check-update A csomagok frissítését az update kulcsszóval kezdeményezhetjük. Ha nem adunk meg csomagokat az update-nek, akkor a rendszeren levő összes csomagot frissíti, viszont csomag megadásával csak a megadott csomagokat fogja frissíteni. yum update ... yum update Frissítéskor használható az --obsoletes kapcsoló is. Ekkor a yum figyelembe veszi az elavult csomagokat is, így ezt az opciót érdemes használni disztribúció-frissítéskor. yum --obsoletes update Az upgrade funckió megegyezik az update --obsoletes kapcsolóval való meghívásával. yum upgrade
5.1.3.3.
A yum egyéb funkciói
A makecache funkcióval tölthetjük le az engedélyezett tárolók metaadatait.
100
yum makecache A clean funkcióval a yum cache könyvtárát üríthetjük ki. Az elérhető opciók: expire-cache, packages, headers, metadata, dbcache, rpmdb, plugins, all. yum clean <expire-cache|packages|headers|metadata|dbcache|rpmdb|plugins|all>
5.1.3.4.
Csomaginformációk lekérdezése, keresés
A rendszeren levő, illetve a rendszerre telepíthető összes csomagot a yum list funkciójával, annak is az all kulcsszavával kérdhetjük le. yum list all Keresést a search funkcióval kezdhetünk. yum search <string> $ yum search mplayer Loaded plugins: downloadonly, langpacks, presto, refresh-packagekit Adding en_US to language list =========================== Matched: mplayer =========================== kmplayer.i686 : A simple front-end for MPlayer/FFMpeg/Phonon gmusicbrowser.noarch : Jukebox for large collections of music files libbluray.i686 : Library to access Blu-Ray disks for video playback vorbisgain.i686 : Adds tags to Ogg Vorbis files to adjust the volume $ Az info kulcsszóval az egyes csomagokról kérhetünk le részletes információt. yum info ... $ yum info zaz Loaded plugins: downloadonly, langpacks, presto, refresh-packagekit Adding en_US to language list Available Packages Name
: zaz
Arch
: i686
Version
: 1.0.0
Release
: 1.fc14
Size
: 19 M
Repo
: fedora
Summary
: A puzzle game where the player has to arrange balls in triplets
URL
: http://sourceforge.net/projects/zaz/
License
: GPLv3+ and CC-BY-SA 101
Description : Zaz is an arcade action puzzle game where the goal is to get : rid of all incoming balls by rearranging their order and : making triplets. : : A 3D accelerator is needed for decent gameplay. $ A provides kulcsszóval az egyes csomagok által nyújtott szolgáltatásokra, illetve fájlokra is rákereshetünk. yum provides <string> $ yum provides "*/Print.h" Loaded plugins: downloadonly, langpacks, presto, refresh-packagekit Adding en_US to language list lesstif-devel-0.95.2-1.fc12.i686 : Header files for LessTif/Motif development Repo
: fedora
Matched from: Filename
: /usr/include/Dt/Print.h
Filename
: /usr/include/Xm/Print.h
... R-devel-2.12.2-1.fc14.i686 : Files for development of R packages Repo
: updates
Matched from: Filename
: /usr/include/R/R_ext/Print.h
$ Egy RPM csomagban levő fájlok kilistázására az repoquery programot használhatjuk, amelyet a yumutils RPM csomagban találunk meg. repoquery --list Az engedélyezett tárolókról a yum repolist kulcsszavával kérhetünk le adatokat. $ yum repolist Loaded plugins: downloadonly, langpacks, presto, refresh-packagekit Adding en_US to language list repo id
repo name
status
fedora
Fedora 14 - i386
17,883
updates
Fedora 14 - i386 - Updates
repolist: 23,698 $
102
5,815
5.2.
Debian csomagkezelés
A Debian csomagkezelés alapja a külön erre a célra kifejlesztett dpkg program. 5.2.1.
A dpkg használata
A dpkg egy alacsonyszintű csomagkezelő eszköz, szolgáltatásokat nyújt az olyan felsőbb szintű csomagkezelők számára, mint az APT, vagy a Synaptic. Ezek a magasabb szintű csomagkezelők képesek az egyes csomagokat távoli gépekről letölteni, a disztribúciók csomagadatbázisait és bonyolult csomagfüggőségeket, kapcsolatokat kezelni. A dpkg helyett általában ezeket használjuk, mivel a felületük könnyen áttekinthető, használatuk kényelmesebb és egyszerűbb. Azonban dpkg is képes ellátni a fenti feladatok nagy részét, ismerete pedig egy rendszergazda számára elengedhetetlen. Néhány a dpkg által nyújtott szolgáltatások közül: • Csomagok telepítése és eltávolítása. • Csomagok frissítése. • Csomaginformációk lekérdezése. • Debian csomag készítése forrásból. 5.2.1.1.
Csomagok telepítése és eltávolítása
A dpkg minden egyes csomag telepítése vagy eltávolítása előtt ellenőrzi a csomag függőségi viszonyát és figyelmeztet, ha probléma van, valamint telepítés előtt a konfliktusokat is figyeli. Fontos és hasznos, hogy egyszerre több csomagot is megadhatunk. Ez a kényelmen túl, akkor hasznos, ha például két kölcsönösen függő csomagot szeretnénk telepíteni. Mindkét csomagot, a helyes sorrendben megadva, nem kapunk függőségi figyelmeztetést. Egy csomag telepítése vagy eltávolítása valamilyen ellenőrzési hiba miatt nem feltétlen akad el, viszont a dpkg minden ilyen esetben figyelmeztet minket, hogy valami gond van. Természetesen használhatjuk a csomagkezelő --force-all kapcsolóját, de ezzel nagyon körültekintően kell bánni, mert egy rossz paranccsal akár tönkre is tehetjük a rendszert! 5.2.1.1.1.
Telepítés
Csomag telepítésére a dpkg program -i kapcsolójának használatával van lehetőség. # dpkg -i eject_2.1.5+deb1+cvs20081104-7_i386.deb Selecting previously deselected package eject. Unpacking eject (from eject_2.1.5+deb1+cvs20081104-7_i386.deb) ... Setting up eject (2.1.5+deb1+cvs20081104-7) ... #
103
Több információt kapunk, ha egyidejűleg a --debug=<debug szint> kapcsolót is használjuk. Ezt a kapcsolót bármelyik másikkal együtt használva, az adott parancs végrehajtásáról kapunk bővebb információt. # dpkg -i --debug=1 eject_2.1.5+deb1+cvs20081104-7_i386.deb Selecting previously deselected package eject. Unpacking eject (from eject_2.1.5+deb1+cvs20081104-7_i386.deb) ... D000001: process_archive oldversionstatus=not installed D000001: deferred extract mass sync D000001: process_archive updating info directory Setting up eject (2.1.5+deb1+cvs20081104-7) ... D000001: deferred_configure updating conffiles # Szint szám
Név
1 2
general scripts
10
eachfile
100
eachfiledetail
20
conff
200
conffdetail
40
depcon
400
depcondetail
10000
triggers
20000
triggersdetail
40000
triggersstupid
1000
veryverbose
2000
stupidlyverbose
30. táblázat. A dpkg debug szintjei
A dpkg debug szintjeiről a dpkg --debug=help parancs segítségével tudhatunk meg többet. A rendszerre telepített aktuális csomagot akár egy régebbivel is lecserélhetjük, a dpkg ezt nem tiltja meg, de figyelmeztet, ha ez történik. # dpkg -i eject_2.0.13deb-18ubuntu4_i386.deb dpkg: warning: downgrading eject from 2.1.5+deb1+cvs20081104-7 to 2.0.13deb-18ubuntu4.
Preparing to replace eject 2.1.5+deb1+cvs20081104-7 (using eject_2.0.13deb-18ubuntu4_i386.deb) ... Unpacking replacement eject ... dpkg: dependency problems prevent configuration of eject: eject depends on libdevmapper1.02 (>= 2:1.02.02-2); however:
104
Package libdevmapper1.02 is not installed. dpkg: error processing eject (--install): dependency problems - leaving unconfigured Errors were encountered while processing: eject # Ez esetben akár az is elképzelhető, hogy a rendszerünk nem úgy fog viselkedni, ahogy mi szeretnénk, ami akár komoly hibákhoz is vezethet. Ha szeretnénk elkerülni az ún. csomag downgrade-et, akkor telepítéskor, vagy frissítéskor ellenőrizzük a telepített és a telepíteni kívánt csomagok verziószámát, vagy használjuk a --refuse-downgrade kapcsolót. 5.2.1.1.2.
Eltávolítás
Csomag eltávolítására a dpkg program -r kapcsolójának használatával van lehetőség. # dpkg -r eject Removing eject ... # Ha azt szeretnénk elérni, hogy csomag eltávolításakor a csomaghoz tartozó minden konfigurációs állomány is eltávolításra kerüljön, akkor a --purge kapcsolót kell használnunk. # dpkg --purge eject Removing eject ... # A csomag eltávolítása leáll, ha a csomagkezelő függőségi hibát észlel. # dpkg -r eject dpkg: dependency problems prevent removal of eject: ubuntu-minimal depends on eject. dpkg: error processing eject (--remove): dependency problems - not removing Errors were encountered while processing: eject #
5.2.1.2.
Frissítés
A csomagok frissítése dpkg esetén sima telepítést jelent, ahol a telepítendő csomag verziójának lehetőleg újabbnak kell lennie, mint a már telepítettnek. (Telepített csomag verzióinformációjának lekérdezését az 5.2.1.3.-ban mutatjuk be.)
105
5.2.1.3.
Csomaginformációk lekérése
A legtöbb lekérdezést a dpkg-query programmal tehetjük meg, melyet kapcsolókkal paraméterezve a csomagkezelő az információk széles palettáját nyújtja a felhasználó felé. A telepített csomagok listáját két módon is lekérdezhetjük. Az első módszer kiírja listát a standard kimenetre, minden csomagnév mellett a telepítés státuszával (installed). dpkg --get-selections A második módszer kiírja a csomagok nevét, verziószámát és egysoros, rövid leírásukat. dpkg-query -l Telepített csomag verziójának lekérdezésére a --show kapcsoló használatával nyílik lehetőség. $ dpkg-query --show mencoder mencoder
2:1.0~rc4~try1.dsfg1-1ubuntu1
$ A csomaginformációk kiíratása az -l kapcsoló segítségével lehetséges. $ dpkg-query -l mplayer mencoder Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name
Version
Description
+++-==============-==============-=================================== ii
mencoder
2:1.0~rc4~try1 MPlayer’s Movie Encoder
ii
mplayer
2:1.0~rc4~try1 movie player for Unix-like systems
$ Részletes információt a csomagokról a -p kapcsoló használatával kaphatunk. $ dpkg-query -p eject Package: eject Priority: optional Section: utils Installed-Size: 340 Maintainer: Ubuntu Developers Architecture: i386 Version: 2.1.5+deb1+cvs20081104-7 Depends: libc6 (>= 2.8), libdevmapper1.02.1 (>= 2:1.02.20) Suggests: cdtool, setcd Filename: pool/main/e/eject/eject_2.1.5+deb1+cvs20081104-7_i386.deb Size: 32902 MD5sum: 2200943a9f9287a7f1fd5f891b08514c
106
Description: ejects CDs and operates CD-Changers under Linux This little program will eject CD-ROMs (assuming your drive supports the CDROMEJECT ioctl). It also allows setting the autoeject feature. . On supported ATAPI/IDE multi-disc CD-ROM changers, it allows changing the active disc. . You can also use eject to properly disconnect external mass-storage devices like digital cameras or portable music players. Original-Maintainer: Frank Lichtenheld Homepage: http://www.pobox.com/~tranter/eject.html $ A --listfiles kapcsoló kilistázza a csomaghoz tartozó összes fájlt. $ dpkg-query --listfiles vrms /. /usr /usr/bin /usr/bin/vrms /usr/share /usr/share/vrms /usr/share/vrms/reasons /usr/share/vrms/reasons/vrms /usr/share/vrms/reasons/vrms/vrms /usr/share/doc /usr/share/doc/vrms /usr/share/doc/vrms/README.Debian /usr/share/doc/vrms/copyright /usr/share/doc/vrms/changelog.gz /usr/share/man /usr/share/man/man1 /usr/share/man/man1/vrms.1.gz /etc /etc/cron.monthly /etc/cron.monthly/vrms $ A --search kapcsolóval lehetőség nyílik a telepített csomagok fájljai között való keresésre. $ dpkg-query --search mencoder mencoder: /usr/share/doc/mencoder
107
mplayer: /usr/share/man/man1/mencoder.1.gz mplayer: /usr/share/man/es/man1/mencoder.1.gz mplayer: /usr/share/man/it/man1/mencoder.1.gz mplayer: /usr/share/man/de/man1/mencoder.1.gz mencoder: /usr/share/doc/mencoder/README.Debian mencoder: /usr/bin/mencoder mencoder: /usr/share/doc/mencoder/changelog.Debian.gz mplayer: /usr/share/man/hu/man1/mencoder.1.gz mplayer: /usr/share/man/cs/man1/mencoder.1.gz mplayer: /usr/share/man/pl/man1/mencoder.1.gz mplayer: /usr/share/man/fr/man1/mencoder.1.gz mencoder: /usr/share/doc/mencoder/copyright mplayer: /usr/share/man/ru/man1/mencoder.1.gz mplayer: /usr/share/man/zh_CN/man1/mencoder.1.gz $ 5.2.2.
Bináris Debian csomag készítése
Ebben a fejezetben csak azt mutatjuk be, hogyan tegyünk bele egy kis bináris csomagba egy egyszerű shell szkriptet, vagy egy futtatható binárist. A szabályos Debian csomagok egy komplett forráscsomagot tartalmaznak, az ebben lévő debian/rules fájl automatikusan végrehajtja a megfelelő lépéseket, beleértve a bináris elkészítését is. Példaként használható Debian csomagokat a /var/cache/apt/archives könyvtárban találhatunk. A dpkg-deb parancs -I kapcsolójával megkapjuk az argumentumként megadott csomag által nyújtott információkat. A dpkg-deb parancs -c kapcsolója megmutatja, hogy az argumentumként megadott csomagban lévő fájlok hova kerülnek a telepítés után. 5.2.2.1.
Csomagszerkezet
Vizsgáljunk meg egy példacsomagot egy kicsit közelebbről! Például a parted_1.4.24-4_i386.deb csomag ezt a három fájlt tartalmazza: $ ar tv parted_1.4.24-4_i386.deb rw-r--r-- 0/0 rw-r--r-- 0/0 rw-r--r-- 0/0
4 Mar 28 13:46 2002 debian-binary 1386 Mar 28 13:46 2002 control.tar.gz 39772 Mar 28 13:46 2002 data.tar.gz
$ Az ar xv parted_1.4.24-4_i386.deb paranccsal csomagoljuk ki a csomagot és a benne levő tar fájlokat is!
108
5.2.2.1.1.
A debian-binary fájl
Ennek a fájlnak a „2.0” string a tartalma. Ez a Debian csomagformátum verziószáma. A 2.0-ás verziónál az összes többi sort figyelmen kívül hagyja a rendszer. 5.2.2.1.2.
data.tar.gz
A data.tar.gz tartalmazza az összes telepítendő fájl listáját, a telepítés utáni elérési útvonalukkal együtt. ./ ./sbin/ ./sbin/parted ./usr/ ./usr/share/ ./usr/share/man/ ./usr/share/man/man8/ ./usr/share/man/man8/parted.8.gz ./usr/share/doc/ ./usr/share/doc/parted/ ./usr/share/doc/parted/README.Debian ./usr/share/doc/parted/copyright ./usr/share/doc/parted/changelog.Debian.gz ./usr/share/doc/parted/changelog.gz
5.2.2.1.3.
A control.tar.gz fájl
A mi példánkban ez a fájl a következőket tartalmazza: -rw-r--r--
1 root
root
1336 Mar 28
2002 control
-rw-r--r--
1 root
root
388 Mar 28
2002 md5sums
-rwxr-xr-x
1 root
root
253 Mar 28
2002 postinst
-rwxr-xr-x
1 root
root
194 Mar 28
2002 prerm
Az md5sums fájl a data.tar.gz összes fájljának az MD5 (Message-Digest Algorithm 5) hashét. Az md5sums, valamint a postinst és a prerm fájlok minden hivatalos Debian csomagnak részei. A prerm és postinst ügyel arra, hogy a régi dokumentációs fájlok törlődjenek, valamint készüljön egy doc könyvtárban lévő link, amely a share/doc könyvtárban lévő megfelelő dokumentációs könyvtárra mutat. $ cat postinst #!/bin/sh set -e # Automatically added by dh_installdocs if [ "$1" = "configure" ]; then
109
if [ -d /usr/doc -a ! -e /usr/doc/parted -a -d /usr/share/doc/parted ]; then ln -sf ../share/doc/parted /usr/doc/parted fi fi # End automatically added section $ cat prerm #!/bin/sh set -e # Automatically added by dh_installdocs if [ \( "$1" = "upgrade" -o "$1" = "remove" \) -a -L /usr/doc/parted ]; then rm -f /usr/doc/parted fi # End automatically added section
5.2.2.1.4.
A Debian control fájl
És végül a legérdekesebb fájl a Debian csomag control fájlja. $ cat control Package: parted Version: 1.4.24-4 Section: admin Priority: optional Architecture: i386 Depends: e2fsprogs (>= 1.27-2), libc6 (>= 2.2.4-4), libncurses5 (>= \ 5.2.20020112a-1), libparted1.4 (>= 1.4.13+14pre1), libreadline4 (>= \ 4.2a-4), libuuid1 Suggests: parted-doc Conflicts: fsresize Replaces: fsresize Installed-Size: 76 Maintainer: Timshel Knoll Description: The GNU Parted disk partition resizing program GNU Parted is a program that allows you to create, destroy, resize, move and copy hard disk partitions. This is useful for creating space for new operating systems, reorganizing disk usage, and copying data to new hard disks. .
110
This package contains the Parted binary and manual page. . Parted currently supports DOS, Mac, Sun, BSD, GPT and PC98 disklabels/partition tables, as well as a 'loop' (raw disk) type which allows use on RAID/LVM. Filesystems supported are ext2, ext3, FAT (FAT16 and FAT32) and linux-swap. Parted can also detect HFS (Mac OS), JFS, NTFS, ReiserFS, UFS and XFS filesystems, but cannot create/remove/resize/check these filesystems yet. . The nature of this software means that any bugs could cause massive data loss. While there are no known bugs at the moment, they could exist, so please back up all important files before running it, and do so at your own risk. $ A control fájl egyes mezői: Package: E mező értéke adja meg a csomag nevét, melyből a legtöbb telepítő eszköz fájlneveket állít elő. Version: Ez általában az eredeti csomag verziószáma a program készítője által használt formában. Debian revízió számot is tartalmazhat nem natív csomagok esetén. Ha mindkettő meg van adva, elválasztásuk kötőjellel történik („-” karakter). Ezért az eredeti változat nem tartalmazhat kötőjelet verziószámában. Section: Ez egy általános mező, mely a csomagot egy témakörhöz (szakaszhoz) társítja (pl. utils, net, mail, text, x11 stb.). Priority: Megadja a csomag fontosságát a rendszer egészében (pl. required, standard, optional, extra stb.). Architecture: Megadja, hogy a csomag milyen architektúrájú gépre fordították a csomagot. A leggyakoribbak: i386, amd64, powerpc, m68k, sparc, alpha stb. Az all lehetőség az ettől független csomagokat jelenti (pl. Perl parancsfájlok, shell szkriptek, dokumentációk). Depends: Azon csomagok listája, melyek szükségesek egy csomag rendes működéséhez. A csomagkarbantartó szoftver nem engedi a telepítést a Depends mezőben megadott csomagok telepítése nélkül (de kényszerítő erre), és lefuttatja a postinst és prerm parancsfájlokat. Suggests: Azon csomagok listája, melyek a csomagban található szoftver képességeit bővíthetik, de mellőzhetők. Conflicts: Ütköző csomagok, melyek például azonos nevű fájlokat tartalmaznak. A csomagkarbantartó szoftver nem engedi ezek egyidejű telepítését. (Pl. két ütköző csomag egy-egy Conflicts mezőben hivatkozik egymásra.) 111
Maintainer: Formátuma a következő: „John Doe <[email protected]>”, és általában nem a szoftver, hanem a csomag készítőjét tartalmazza. Description: A csomagok leírásának formátuma egy rövid összefoglaló az első sorban (a Description tag után). A következő sorok hosszabb leírásra használhatók. A hosszú leírás minden sora szóközzel kell kezdődjön, és a hosszú leírás üres sorai egy pontot („.” karakter) kell tartalmazzanak a sor eleji szóköz után. 5.2.2.2.
A csomag összeállítása és ellenőrzése
A bináris Debian csomag elkészítésének lépéseit vesszük sorra ebben a fejezetben. 5.2.2.2.1.
A helyi debian könyvtár előkészítése
Ebben a könyvtárban állítjuk össze a csomagunkat. 1. Készítsük el a debian/usr/bin könyvtárat, vagy ahová a futtatható fájlokat szeretnénk telepíteni. 2. Készítsük el a debian/usr/share/man/man1 könyvtárat, vagy amelyik szekcióba a kézikönyv oldalakat szeretnénk elhelyezni. 3. Készítsük el a debian/DEBIAN könyvtárat. 4. Készítsük el a debian/usr/share/doc/ könyvtárat. 5. Győződjünk meg arról, hogy a debian könyvtárban lévő összes alkönyvtár 0755-ös hozzáférési joggal rendelkezik. 5.2.2.2.2.
A szükséges fájlok
1. Egy vagy több bináris futtatható fájl, vagy shell szkript. 2. Egy kézikönyv oldal minden egyes futtatható fájlhoz. 3. A control fájl, amit a készülő csomagunk DEBIAN könyvtárába kell másolnunk. $ mkdir -p debian/DEBIAN $ find ./debian -type d | xargs chmod 755 $ cp control debian/DEBIAN 4. A copyright fájl. 5. A changelog és changelog.Debian fájlok. 5.2.2.2.3.
A fájlok elhelyezése a helyi debian fa-struktúrában
1. Másoljuk a futtatható fájlokat a debian/usr/bin könyvtárba, vagy ahová telepíteni szeretnénk őket.
112
2. Másoljuk a kézikönyv oldalakat a debian/usr/share/man/man1, vagy a megfelelő kézikönyv szekció könyvtárába. 3. Másoljuk a control fájlt a debian/DEBIAN könyvtárba. 4. Másoljuk a copyright, changelog és changelog.Debian fájlokat a debian/usr/share/doc/ könyvtárba. 5. Tömörítsük a gzip programmal a kézikönyv oldalt, a copyright, a changelog és a changelog.Debian fájlokat a --best opcióval a helyi debian könyvtárstruktúrába. 5.2.2.2.4.
A Debian csomag elkészítése és ellenőrzése
1. Használjuk a dpkg-deb --build parancsot a fakeroot segítségével a debian könyvtárra. fakeroot dpkg-deb --build debian 2. Nevezzük át az eredményül kapott debian.deb fájlt a végső csomagnévre, benne a verziószámmal és az architektúrára vonatkozó információval. Fontos, hogy ha a csomagunkat újra elkészítjük, akkor növelnünk kell a verziószámot például 1.1.-1-ről 1.2-1-re (növeljük a saját belső kiadási számot). 3. Ellenőrizzük a kapott fájlt a lintian segédprogrammal, hogy megfelel-e a Debian irányvonalnak. lintian csomag_1.1-1_all.deb Jelen dokumentumban nem tárgyaljuk részletesen a kézikönyv oldalakat, a copyright, a changelog és a changelog.Debian fájlokat, valamint a prerm és a postinst szkripteket. [9] 5.2.3.
Az apt használata
A dpkg segítségével ugyan elvileg mindent el tudunk végezni, ami a telepítésekhez és eltávolításhoz szükséges, de használata olykor igen kényelmetlen. Egyrészt mindig nekünk kell a szükséges Debian csomagokat felkutatnunk. Másrészt nem túl intelligensen kezeli a függőségeket. Mindkét problémára megoldást jelent az apt (Advanced Packaging Tool) program. Az apt egy adatbázisban tárolja, hogy a Debian csomagokat hol kell keresnie. Amikor egy új programot szeretnénk telepíteni csak annyit kell tennünk, hogy megmondjuk az apt-nek a csomag nevét. Az apt tudni fogja, hogy az adott csomaghoz milyen fájlt melyik CD-ről, vagy adatbázisból töltheti le. Ha a telepítéshez más csomagokra is szükség van akkor azokat is megkeresi és feltelepíti. Csomagok telepítésekor és eltávolításakor az apt programnak egyszerre akár több csomagot is megadhatunk. Hogy mindez működhessen meg kell mondanunk az apt-nek, hogy hol talál Debian csomagokat. Ezt az információt a /etc/apt/sources.list fájlban tárolja el. Az apt figyelmen kívül hagyja a kikommentezett (a „#” karakterrel kezdődő) sorokat.
113
5.2.3.1. 5.2.3.1.1.
Csomagok telepítése és eltávolítása Telepítés
Csomag telepítésére az apt-get program install kulcsszavának használatával van lehetőség. apt-get install ... # apt-get install robotfindskitten Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: robotfindskitten 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 29.0kB of archives. After this operation, 123kB of additional disk space will be used. Get:1 http://archive.ubuntu.com/ubuntu/ maverick/universe robotfindskitten amd64 1.7320508.406-2 [29.0kB] Fetched 29.0kB in 0s (47.5kB/s) Selecting previously deselected package robotfindskitten. (Reading database ... 340244 files and directories currently installed.) Unpacking robotfindskitten (from ... /robotfindskitten_1.7320508.406-2_amd64.deb) ... Processing triggers for install-info ... Processing triggers for man-db ... Setting up robotfindskitten (1.7320508.406-2) ... #
5.2.3.1.2.
Eltávolítás
Csomag eltávolítására az apt-get program remove kulcsszavának használatával van lehetőség. apt-get remove ... # apt-get remove robotfindskitten Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: robotfindskitten 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. After this operation, 123kB disk space will be freed. Do you want to continue [Y/n]? y 114
(Reading database ... 340254 files and directories currently installed.) Removing robotfindskitten ... Processing triggers for man-db ... Processing triggers for install-info ... # Ha azt szeretnénk elérni, hogy egy csomag eltávolításakor a csomaghoz tartozó minden konfigurációs állományt és beállítást is töröljünk, akkor az apt-get program purge kulcsszavát kell használnunk. apt-get purge ... Az apt-get program autoremove kulcsszavának használatával azokat a csomagokat távolíthatjuk el, amelyek korábban a csomagfüggőségek kielégítése céljából lettek telepíve, de már nincs rájuk szükség. Az ilyen csomagok általában a rendszerünkön csak foglalják a helyet. apt-get autoremove
5.2.3.2.
Frissítés
A telepített csomagok frissítését az apt az /etc/apt/sources.list fájlban beállított online csomagadatbázisok alapján végzi. Az apt-get programot az update kulcsszóval meghívva szinkronizálja a helyi csomag index fájlokat az előre beállított csomagadatbázisok alapján. # apt-get update Hit http://archive.canonical.com maverick Release.gpg Hit http://extras.ubuntu.com maverick Release.gpg Ign http://archive.canonical.com/ubuntu/ maverick/partner Translation-en ... Hit http://linux.dropbox.com maverick/main amd64 Packages Fetched 2,617B in 0s (3,846B/s) Reading package lists... Done # Az index fájlok szinkronizálása után az apt-get programot az upgrade kulcsszóval és rendszergazdai jogosultsággal meghívva frissíthetjük a telepített csomagokat. apt-get upgrade Az apt-get program dist-upgrade funkciója az upgrade-hez hasonlóan a csomagokat frissíti, de ha netán rendelkezésre állnának újabb függőségi csomagok, akkor eltávolítja a régieket, és újabbra cseréli őket. Esetenként újabb csomagok is telepítésre kerülhetnek. (Használatához szintén rendszergazdai jogosultságokra van szükség.) apt-get dist-upgrade
115
5.2.3.3.
Az apt-get egyéb funkciói
Az apt-get program egyik nagyon hasznos funkciója, hogy képes végignézni a telepített csomagjainkat, megkeresni az ütközéseket vagy a hiányzó függőségeket. Mindezt a check kulcsszó használatával tudjuk megtenni. # apt-get check ... # Hiányzó függőségek, vagy csomagütközés esetén az apt-get install funkcióját a -f kapcsolóval meghívva kijavítja talált hibákat. # apt-get install -f ... # Az apt-get program clean kulcsszavának használatával letörölhetjük a gépünkről telepítéshez letöltött csomagokat. Ezt általában az apt-get elvégzi helyettünk, de bizonyos esetekben használata szükséges lehet. apt-get clean Az autoclean kulcsszó is hasonló funkcióval bír, mint a clean, de csak azokat a korábban letöltött fájlokat törli, amelyeket már nem lehet letölteni, így azokról nagy biztonsággal kijelenthető, hogy már nincs rájuk szükség. apt-get autoclean
5.2.3.4.
Csomaginformációk lekérdezése, keresés
Csomaginformációk lekérdezésére az apt programcsomag apt-cache parancsával van lehetőségünk. A dpkg-hoz hasonlóan ezzel az eszközzel is képesek vagyunk információt lekérdezni, keresni az egyes programcsomagokról. Az apt-cache annyival nyújt többet a dpkg-nál, hogy az adatbázisában szerepelnek a fel nem telepített csomagok is. Vagyis mindazon csomagok között kereshetünk, végezhetünk lekérdezéseket, amelyek szerepelnek a helyi csomagadatbázisunkban. (Természetesen a helyi csomag index fájloktól függ, hogy milyen friss az adatbázisunk.) Az apt-cache leggyakrabban használt funkciója a keresés, amelyet a search kulcsszóval indíthatunk. Az alábbi parancs hatására a megadott stringet tartalmazó csomagnevek, és csomagleírások között fog keresni az apt-cache. apt-cache search <string> Az apt-cache segítségével csomagok teljes leírását is lekérdezhetjük, ehhez a showpkg kulcsszót kell használnunk.
116
apt-cache showpkg ... $ apt-cache showpkg robotfindskitten Package: robotfindskitten Versions: 1.7320508.406-2 (/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_ maverick_universe_binary-amd64_Packages) (/var/lib/dpkg/status) Description Language: File: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_ dists_maverick_universe_binary-amd64_Packages MD5: cea3321f9fceee71952062f05aaf60f7 Reverse Depends: Dependencies: 1.7320508.406-2 - libc6 (2 2.3.4) libncurses5 (2 5.6+20071006-3) Provides: 1.7320508.406-2 Reverse Provides: $ Az apt-cache segítségével lekérdezhetjük a csomagfüggőségeket is. Ehhez a depends kulcsszót kell használnunk. apt-cache depends ... $ apt-cache depends robotfindskitten apache2 robotfindskitten Depends: libc6 Depends: libncurses5 apache2 |Depends: apache2-mpm-worker |Depends: apache2-mpm-prefork |Depends: apache2-mpm-event Depends: apache2-mpm-itk Depends: apache2.2-common $ Az rdepends kulcsszóval a csomagok fordított függőségeit is megtudhatjuk. apt-cache rdepends ... Az apt-cache stats funkciójával a helyi csomagadatbázisról nyújt hasznos információkat, mint például a cache-ben fellelhető csomagok száma, az eltérő verziójú csomagok száma, s függőségi viszonyok száma stb.
117
apt-cache stats Az apt-cache számos további funkcióval rendelkezik, amelyeket itt most nem tárgyalunk. 5.2.3.4.1.
Az apt-file program
Az apt-file program nem az apt csomag része, külön az apt-file csomagban található. Ez a program teszi számunkra lehetővé, hogy a dpkg-query-hez hasonlóan a csomagokban található fájlok között is kereshessünk, azonban az apt-file a nem telepített csomagok fájljai között is képes keresni. Mivel azonban az apt-file nem szerves része az apt csomagnak, adatbázisának frissítését az update kulcsszó használatával külön kell elvégeznünk. (Az apt-file az /etc/apt/sources.list fájlban megadott szerverekről kéri le a frissítéshez szükséges információkat.) apt-file update Keresést a search kulcsszó használatával tudunk kezdeni. (Az apt-file csak fájlokat keres, a csomagokban fellelhető könyvtárak között nem.) apt-file search <string> $ apt-file search robotfindskitten games-thumbnails: /usr/share/games/thumbnails/robotfindskitten.png robotfindskitten: /usr/games/robotfindskitten robotfindskitten: /usr/share/doc/robotfindskitten/AUTHORS robotfindskitten: /usr/share/doc/robotfindskitten/BUGS robotfindskitten: /usr/share/doc/robotfindskitten/NEWS.gz robotfindskitten: /usr/share/doc/robotfindskitten/README robotfindskitten: /usr/share/doc/robotfindskitten/README.Debian robotfindskitten: /usr/share/doc/robotfindskitten/changelog.Debian.gz robotfindskitten: /usr/share/doc/robotfindskitten/copyright robotfindskitten: /usr/share/info/robotfindskitten.info.gz robotfindskitten: /usr/share/man/man6/robotfindskitten.6.gz $ A list funkcióval a dpkg-query --listfiles kapcsolójához hasonlóan egy megadott csomagban található összes fájlt kapjuk vissza, természetesen azzal a különbséggel, hogy míg a dpkg-query csak telepített csomagok között keresett, addig az apt-file a nem telepítettek között is keresni fog. apt-file list $ apt-file list vrms vrms: /etc/cron.monthly/vrms vrms: /usr/bin/vrms vrms: /usr/share/doc/vrms/README.Debian
118
vrms: /usr/share/doc/vrms/changelog.gz vrms: /usr/share/doc/vrms/copyright vrms: /usr/share/man/man1/vrms.1.gz vrms: /usr/share/vrms/reasons/vrms/vrms $
5.3.
Átjárás az RPM és a Debian csomagkezelés között
Ma már gyakorlatilag minden jelentősebb csomagkezelő rendszerhez készülnek programcsomagok. Azonban ha mégsem találnánk meg egy bizonyos csomagot a számunkra szükséges formátumban, akkor az ebben a fejezetben leírtak alapján viszonylag könnyedén elő tudjuk állítani. Ha szeretnénk egy RPM csomagot egy Debian csomagkezelést használó, vagy fordítva, rendszerre feltelepíteni, akkor a korábban megismert módon, a forráscsomag beszerzésével, a megfelelő módosítások és a csomag lefordítása után feltelepíthetjük a szóban forgó csomagot. Sajnos ez már kicsit bonyolultabb programok esetén is igen nehézkes és hosszú munka lehet, de szerencsére létezik egy program, ami könnyedén biztosítja számunkra a különböző csomagkezelő rendszerek közötti átjárást. Ez a program az Alien. Az Alien nem csak az RPM és a Debian csomagkezelő rendszerek közötti átjárást biztosítja, de támogatja a Stampede (.slp), a Solaris (.pkg), és a Slackware (.tgz) csomagformátumokat is, azonban ezeket most nem tárgyaljuk. Fontos megjegyeznünk, hogy az Alien kísérleti szoftver, ezért kritikus, a rendszer működéséhez szükséges csomagokat ne készítsünk vele. Sajnos az Aliennel készített, konvertált csomagok sokszor hibásak, esetleg nem is lehet őket telepíteni, ezért az így készített csomagokkal óvatosan bánjunk! Ahhoz, hogy az Alient használni tudjuk, először fel kell telepítenünk. Fedorán a programot forráskódból fordíthatjuk és telepíthetjük, Ubuntun az alien csomagot kell telepítenünk. Csomag konverziójához, készítéséhez az alient mindig rendszergazdai jogosultsággal kell futtatnunk. Debian csomagot a -d kapcsoló használatával készíthetünk, míg RPM csomag készítéséhez az -r kapcsolót kell alkalmaznunk. A -c kapcsolóval az alien a telepítéskor, illetve eltávolításkor végrehajtott szkripteket is létrehozza az adott csomaghoz. # alien -d -c robotfindskitten-1.7320508.406-3.fc12.i686.rpm robotfindskitten_1.7320508.406-4_i386.deb generated # # alien -r -c robotfindskitten_1.7320508.406-2_i386.deb robotfindskitten-1.7320508.406-3.i386.rpm generated #
5.4.
X Window System
Manapság ha egy operációs rendszer versenyképes szeretne lenni a piacon, akkor kétség kívül szüksége van egy grafikus felhasználói felületre vagy más néven GUI-ra (Graphical User Interface). A grafikus
119
felhasználói felület számos feladatra egyértelműen barátságosabb és könnyebben kezelhető, mint egy szöveges terminál. A Unix rendszerek és a Linux grafikus felülete az X Window vagy egyszerűen X, amely hasonlóan sok más Unix-os fejlesztéshez egy akadémiai projekt eredménye. Az X-et 1984-ben az MIT-n az Athena projekt keretében fejlesztették ki. 1988-tól az X konzorcium felügyeli a fejlesztést és a terjesztést. Specifikációja szabadon hozzáférhető. Ez utat nyitott az ingyenes implementációk létrejöttének, amilyen az XFree86. Linux alatt is ezt a felületet használjuk. Elterjedtsége viszont nem korlátozódik a Linuxra, használják más operációs rendszereken is (BSD, OS/2), de nevével ellentétben más architektúrákon is. A Unix kezdetek óta rendelkezik a többfelhasználós (multiuser), többfeladatos (multitask) képességekkel, illetve a hálózatok elterjedése óta támogatja a távoli bejelentkezést is. Az X architektúráját is úgy alakították ki, hogy illeszkedjen ebbe az elképzelésbe. 5.4.1.
X Window architektúra
Az X-et kliens-szerver architektúrájúra alakították ki. Az alkalmazások a kliensek, amelyek kommunikálnak a szerverrel. Kéréseket küldenek, és információkat kapnak. Az X szerver kezeli a képernyőt és a bemeneti eszközöket (billentyűzet, egér), a programok ezekhez nem férnek hozzá közvetlenül, csak az X szervert kérik meg az egyes műveletek végrehajtására. Ennek a megoldásnak az előnye egyértelmű: a kliensnek nem kell az adott eszköz jellemzőivel foglalkoznia, csak a szerverrel való kommunikációt kell implementálnunk. Ez pedig nem különbözik attól, mintha csak egy grafikus könyvtárat használnánk. Az X architektúra azonban ennél is tovább megy. Nem szükséges, hogy a kliens és a szerver alkalmazás egy gépen fusson. A kliens-szerver protokoll hálózaton keresztül is megvalósítható bármilyen IPC mechanizmussal, amely megbízható stream jellegű kommunikációt biztosít. Az egyes gépeken használt operációs rendszer is eltérhet. 5.4.2.
Ablakkezelők
Amikor ablakos, grafikus felületet használunk, akkor természetes igényünk, hogy a kliens ablakokat kezelhessük: mozgathassuk, átméretezhessük, minimalizálhassuk, maximalizálhassuk stb. Az X nem kezeli ezeket a műveleteket, ez a feladat az ablakkezelőre (window manager) vár. Az ablakkezelő díszíti az ablakokat, illetve a felhasználóknak felületet biztosít az ablakműveletekhez, magukat az ablakműveleteket az X szerver implementálja. Mivel az ablakkezelő is csak egy kliens program, nem része az X szervernek, így kívánság szerint cserélgethetjük, és széles választékból választhatunk az ízlésünknek megfelelőt. Bár az ablakkezelő fő feladata a kliensek ablakainak menedzselése, emellett különböző egyéb funkciókkal is rendelkezhet. Az egyik ilyen általános funkció például a kliens programok indítása. 5.4.3.
Kliens alkalmazások
Az X-es alkalmazások készítésénél a programozók úgynevezett widget könyvtárakat használnak. Ezek a programkönyvtárak tartalmazzák az ablakok felületén megjelenő különböző vezérlő elemeket (pl. gombok, edit mező, lista mező stb.). Mivel ezek működése eltérően lehet implementálva az egyes programkönyvtárakban, ezért a programok viselkedése nagyban függ a fejlesztő által választott widget könyvtártól.
120
Az első widget könyvtár az Athena projekt keretében kifejlesztett Athena könyvtár volt. Csak a legalapvetőbb elemeket tartalmazza, és a kontroll elemek kezelése eltér a manapság használatosaktól. Az ezt követő legismertebb könyvtár az OSF (Open Software Foundation) Motif csomagja volt. 1980tól a korai 1990-es évekig volt igen elterjedt, de a mai napig sok helyen használják. A legkomolyabb hibája, hogy súlyos összegekbe kerül a fejlesztői licence. Manapság már vannak jobb alternatívák árban, sebességben, szolgáltatásokban. Ilyen például a GTK, amely a GIMP projekthez készült. Aránylag kicsi, sok szolgáltatással, bővíthető, és teljesen ingyenes, illetve egy másik népszerű toolkit, a Qt, amely a KDE projekt óta ismert igazán, mivel a KDE alapját szolgáltatja. (A Qt forráskódja jelenleg a GNU LGPL licenc alatt is elérhető, de kereskedelmi változata is létezik.) További alternatíva a LessTif, amely egy ingyenes helyettesítője a Motifnak. Azonban mivel minden X kliens alkalmazás alapvetően az Xliben alapul, ezért egyes opciókat egységesen kezelnek (lásd 31. táblázat). Paraméter
Leírás
-bg <szín>
Az ablak háttér színe
-bd <szín> -bw <szám>
Az ablakkeret színe Az ablakkeret pixel vastagsága
-fg <szín>
Az ablak előtér színe
-fn
Az alapértelmezett méretű fontset
-geometry
Az ablak méretei és elhelyezkedése
-icon
A program ikon méretben indul
-display :<szám>
Megadja szerver nevét és az X szerver display számát az applikáció számára23
-xrm <string>
Resource stringeket állíthatunk be
31. táblázat. Általános X kliens opciók
5.4.4.
Asztali környezetek
A korábbiakból látható, hogy felhasználóként választhatunk ablakkezelőt kedvünk szerint, és a programok írói is választhatnak widget könyvtárakat. Azonban ennek a nagy szabadságnak megvannak a hátrányai: • A kliens program írója határozza meg, hogy milyen widget könyvtárat használ. Azonban mivel e könyvtárak kontroll elemei nagyban különbözhetnek, előfordulhat, hogy ahány programot használunk, annyiféle módon kell kezelni. • Ezek a widget könyvtárak általában dinamikusan linkelődnek a programokhoz, azonban ha a kliens programjaink különbözőket használnak, akkor az plusz memóriát igényel. • Az ablakkezelők is sokfélék, különböző kezelési koncepciókkal. 23 Ha
nem állítjuk be, akkor a kliens az információkat a DISPLAY környezeti változóból veszi.
121
• Az egész felület ezeknek következtében nem áll össze egy egységes egésszé, például nem lehet egyben konfigurálni a kinézetét, kezelését. Ez azért alakult így, mert az X kialakítása során a flexibilitásra, és a felhasználók szabadságára helyezték a hangsúlyt, ellentétben egyéb operációs rendszerek (pl. Microsoft Windows, Mac OS) megkötöttségeivel, zártságával. Mindez azonban a fent említett helyzethez vezetett, ezért előtérbe került a komplex felület létrehozása a szabadsággal szemben. Ez a helyzet vezetett az asztali környezetek (desktop environment) kialakulásához. Az asztali környezet tartalmaz szolgáltatásokat és módszertanokat, amellyel a felület egységesíthető és a problémák leküzdhetőek. Ugyanakkor több fajtája is létezik, és a választás szabadsága ezáltal megmarad. Az ismertebbek: GNOME (GNU Network Object Model Environment), KDE (KDE Software Compilation), XFCE, CDE (Common Desktop Environment). 5.4.5.
Az X elindítása
Az X session elindítására két metódus közül választhatunk. Amennyiben a gépünk nem futtat folyamatosan X szervert, ami egy szerver gép esetén gyakori, akkor a startx paranccsal indíthatjuk el és hozhatunk létre egy sessiont. A másik lehetőség, amikor egy xdm (X Display Manager) nevű szolgáltatás (vagy ennek egy variánsa) folyamatosan fut a gépünkön. Ez a munkaállomások esetén gyakori. Az xdm menedzseli az X felületet, egy autentikációs szolgáltatást nyújt, ahol bejelentkezhetünk és elindítja számunka a sessiont. 5.4.5.1.
A startx működése
A startx valójában egy front-end az xinit program számára. Egy kicsit barátságosabb felületet nyújt számunkra, mint az xinit parancs formátuma. Az xinit futtatja a ~/.xinitrc szkriptet. Ha ez nem létezik, akkor a rendszerszintű xinitrc szkript indul el (/usr/lib/X11/xinit/xinitrc vagy /etc/X11/xinit/xinitrc). Ez az állomány elindíthat X kliens applikációkat és a ablakkezelőt, de a jelenlegi konfigurációkban ezt az Xclients szkript teszi. Az .xinitrc futatja a ~/.Xclients szkriptet, vagy ha ez nem létezik, akkor a rendszer szintű változatát (/etc/X11/xinit/Xclients). Ennek feladata az X kliensek és a választott ablakkezelő indítása.
Feladat Vizsgáljuk meg a felsorolt szkript állományokat!
5.4.5.2.
Az X session indulása
Az xdm használata esetén belépéskor hasonló folyamatok játszódnak le, mint a startx esetén. Az xdm létrehoz egy új sessiont. Lefuttatja rendszerszintű Xsession szkriptet (/usr/lib/X11/xdm/Xsession vagy /etc/X11/xdm/Xsession). Ez a szkript futtatja a felhasználó ~/.xsession szkriptjét. Ha nem létezik az .xsession szkript, akkor a ~/.Xclients vagy a /etc/X11/xinit/Xclients szkript hajtódik végre. Ezekben a szkriptekben indíthatjuk el az X kliens applikációkat és az ablakkezelőt. 122
Feladat Vizsgáljuk meg a felsorolt szkript állományokat!
5.4.5.3.
Az xorg.conf fájl
Az xorg.conf fájl az X szerver egyik fő konfigurációs állománya, és általában az /etc/X11 könyvtárban található meg. Az xorg.conf fájl tartalmazza tipikusan a grafikus meghajtók, a monitor, a beviteli eszközök beállításait és a betűtípusok elérési útját. Az állomány a következő szekciókból áll: Files, ServerFlags, Module, Extensions, InputDevice, InputClass, Device, VideoAdaptor, Monitor, Modes, Screen, ServerLayout, DRI, Vendor. Ha valamelyik szekció hiányzik a fájlból, akkor az X szerver a szekcióhoz tartozó alapértelmezett értékeket használja. Section "SectionName" SectionEntry ... EndSection Az xorg.conf fájl manuális szerkesztése sokáig bevett módszer volt, hogy bizonyos beviteli eszközök és grafikus kártyák működésre bírhatók legyenek. Ez korábban sokszor a használhatóság rovására ment, azonban az újabb X-ek esetén a dinamikus modulbetöltés és az XRandR kiterjesztés használata miatt ma már erre nincs szükség. Sőt, sok esetben a xorg.conf állomány már nem is a fájlrendszeren létezik, hanem az X dinamikusan generálja. Ha mégis szükségünk van xorg.conf állományra, akkor a fellelhető leírások alapján magunk is elkészíthetjük, de könnyebb dolgunk van ha legeneráljuk a xorg.conf skeletonját és utána szerkesztjük. Ezt az alábbi parancsot rendszergazdaként lefuttatva tehetjük meg. (Eredményként az X készít egy xorg.conf.new fájlt a home könyvtárunkba.) Xorg -configure Az xorg.conf egyéb funkcióit, illetve az egyes szekciókat nem tárgyaljuk, további információért forduljunk az állomány manuál oldalához.24 5.4.6.
Kliens futtatása távoli gépen
Mint már volt róla korábban szó, az X architektúrájában lehetőség van rá, hogy az X szerver (a kezelői felület) az egyik gépen fusson, míg a kliens program egy másikon, és a hálózaton keresztül kommunikáljanak. Ez az X protokoll on keresztül zajlik. (Ezt tömöríteni is lehet, ami lassú kapcsolat esetén hasznos.) Ha használni szeretnénk ezt a funkcionalitást, akkor a következőképpen kell eljárnunk: 1. A lokális géppel (X szerver) közölnünk kell, hogy fogadja a távoli gép kapcsolódását. 2. A távoli géppel (kliens program) közölnünk kell, hogy a kimenetét a lokális gépünkre irányítsa. 24 man
xorg.conf
123
Lehetséges, hogy egy gépen több X szervert használjunk, vagy több felhasználó által futtatott programok egy X szerveren jelenjenek meg. Ezeket is a távoli elérésnél használatos módszerekkel szabályozhatjuk. 5.4.6.1.
Jogosultság beállítása az X szerveren
Az X szerver nem fogad kapcsolódást bárhonnan. Ha nem így lenne, az biztonságilag komoly problémákat vetne fel: • bárki bármit odarakhatna a képernyőnkre; • monitorozhatná a billentyű leütéseinket, egér-eseményeket stb. Az X Window az authentikációra kétféle metódust támogat: • a host listát használó mechanizmus (xhost), • és a magic cookie-t használó xauth. 5.4.6.1.1.
Xhost
Ebben az esetben az X szerver egy listát kezel a kapcsolódásra jogosult gépek neveiről. Ehhez a listához hozzáadhatunk, illetve elvehetünk gépneveket. Xserver> xhost +xclient.valahol.hu Xserver> xhost -xclient.valahol.hu De akár teljesen ki is kapcsolhatjuk (ezzel gyakorlatilag mindenkit engedélyezünk), de ez természetesen nem javasolt, mert a fentebb említett biztonsági problémákat veti fel. Xserver> xhost + Visszaállítása: Xserver> xhost Az xhost, mint látható, nem biztonságos megoldás. Egyrészt nem különbözteti meg az adott gépen lévő felhasználókat, másrészt gépnév alapján dolgozik, ami félrevezethető. Így ezt csak olyan hálózaton használjuk, ahol megbízunk a felhasználó-társainkban. 5.4.6.1.2.
Xauth
Az xauth azon klienseknek engedi a kapcsolódást, amelyek ismerik a titkos jelszót (authorization record vagy magic cookie). A cookie-k a ~/.Xauthority állományban tárolódnak. (Vigyázni kell a jogok beállításánál, hogy csak a tulajdonos olvashassa.) Ezt az állományt az xauth program kezeli. Az xauth protokoll használatához az X szervert az -auth paraméterrel kell indítani. Kezelése nehézkesebb, mint az xhostos megoldásé. Ugyanakkor az autentikációs kommunikáció továbbra is kódolatlanul zajlik a hálózaton, ezért a biztonság szempontjából érdemes lehet egy kódolt csatornával kiegészíteni (pl. SSH). 124
5.4.6.2.
Az X kliens kimenetének átirányítása
A DISPLAY környezeti változón keresztül adhatjuk meg az X applikációknak, hogy melyik X szerverhez kapcsolódjanak. DISPLAY=:0 DISPLAY=localhost:1 DISPLAY=x.valahol.hu:0 A DISPLAY változó egy hosztnévvel kezdődik, ami opcionális. Követi egy „:”. Utána az X szerver szekvenciaszáma következik. Ha egy gépnek több display-e van, vagy csak több X szervert futtatunk, akkor ez az indexe az azonosításhoz. (Kiegészíthető meg egy screen numberrel is: :.<screen> módon.) A kliens programok induláskor megvizsgálják a DISPLAY környezeti változót, hogy hova kell kapcsolódniuk. Azonban ezt felülírhatjuk a -display paraméterrel, ami után ugyanúgy kell megadnunk a display leírását, mint korábban a DISPLAY változónál. A következőkben néhány példát nézünk meg. Az Xclient> az applikációt (X kliens) futtató gép promptja: Xclient> export DISPLAY=x.valahol.hu:0 Xclient> xterm & Xclient> DISPLAY=x.valahol.hu:0 xterm & Xclient> xterm -display x.valahol.hu:0 & Használhatjuk az rsh (remote shell) parancsot, vagy a biztonságosabb ssh (secure shell) programot. rsh xclient.valahol.hu xapplikáció -display szerver:0
5.4.6.3.
SSH X forward
A hagyományos megoldásokhoz képest a legegyszerűbb és legbiztonságosabb megoldást az ssh program X forward funkciója nyújtja. Ez lehetővé teszi, hogy amennyiben a gépünkön X-et használunk, és az ssh programmal belépünk egy távoli gépre, akkor a shellből indított programok kimenete automatikusan az X-es felületünkre irányítódik át egy titkosított csatornán keresztül. Ehhez a felhasználónak semmilyen beállítást nem kell elvégeznie. A kapcsolat felépítéséhez az ssh automatikusan létrehoz egy Xauthory állományt egy véletlen jelszóval. Később ezzel azonosítja az átirányított kapcsolatokat.
Megjegyzés Az ssh program ezen funkciójának használatához az SSH szervernek támogatnia kell az X kapcsolatok átirányítását. (A konfigurációs-állományban a ForwardX11 opciónak engedélyezve kell 125
lennie.) 5.4.7.
Grafikus konfigurációs eszközök
Az adminisztrációs feladatok megkönnyítésére léteznek grafikus felülettel rendelkező segédprogramok, amelyekkel a szokásos feladatok könnyebben és gyorsabban elvégezhetőek. Azonban nem célszerű kizárólag ezekre támaszkodni, mert az általuk beállítható paraméterek korlátozottabbak lehetnek, illetve nem elemei minden disztribúciónak. Továbbá a kis sávszélességű távoli elérés esetén használatuk nehézkesebb lehet, mint a parancssoros változataiké. A következőkben áttekintjük, hogy a Red Hat disztribúció milyen programokat tartalmaz az eddig tárgyalt feladatok elvégzésére. A programok kezelésére a dokumentumban nem térünk ki, mert felületük a korábbi ismeretek alapján könnyen értelmezhető. 5.4.7.1.
A felhasználók adminisztrálása
A felhasználók adminisztrálásának megkönnyítésére használhatjuk a Red Hat User Manager programot. Ez a system-config-users RPM csomag része. Segítségével felvehetünk új felhasználókat, törölhetünk, megnézhetjük, és módosíthatjuk adataikat. Használatához rendszergazdai jogosultságokkal kell rendelkeznünk.
6. ábra. A Red Hat User Manager főablaka A főablakon láthatjuk a felhasználók vagy a csoportok listáját, és főbb információikat. A gombokkal létrehozhatunk új felhasználót, csoportot, vagy módosíthatjuk, törölhetjük az éppen kiválasztottat. 5.4.7.2.
A folyamatok monitorozása
A folyamatok kilistázására, kezelésére, a rendszer állapotának a figyelemmel kísérésére mind a KDE, mind a GNOME asztali környezet tartalmaz programokat. A KDE környezetben találjuk a KDE System Guard szoftvert.
126
7. ábra. A rendszer terheltsége a KDE System Guard ban
8. ábra. Folyamatok adatai a KDE System Guard ban A GNOME környezet a folyamatok kezelésére a System Monitor programot nyújtja.
127
9. ábra. Folyamatadatok és rendszer leterheltség a System monitor ban 5.4.7.3.
Futásszintek beállításai
Az egyes futásszinteken induló szolgáltatások beállítására is készített a Red Hat segédeszközt. A systemconfig-services RPM csomag tartalmazza a Service Configuration programot.
10. ábra. Futásszintek beállításai a Service Configuration programban 5.4.7.4.
Log állományok tanulmányozása
A számtalan log állomány könnyebb áttekintésére is létezik segédeszköz. A Red Hat disztribúció a System Logs programot nyújtja erre a feladatra. Ez a system-logviewer RPM csomagban található. Az állományok megjelenítése mellett rendelkezik egy figyelmeztető funkcióval is. Egyes kulcsszavakra kérhetünk riasztásokat.
128
11. ábra. Log állományok kezelése 5.4.7.5.
Rendszer csomagok telepítése és eltávolítása
A Red Hat disztribúció tartalmaz egy csomagkezelő szoftvert, amellyel a rendszer csomagjait utólag is feltelepíthetjük és eltávolíthatjuk. Ennek neve Add/Remove Applications, és a system-config-packages RPM csomagban található.
12. ábra. Csomagok telepítése és eltávolítása Csomagok telepítésére és eltávolítására a Debian csomagkezelést alkalmazó disztribúciók általában a Synaptic csomagkezelőt nyújtják.
129
13. ábra. A Synaptic csomagkezelő
130
6.
Hálózat-konfiguráció, SSH, FTP, NFS, Samba
Ebben a fejezetben a hálózati konfiguráció alapjaitól a leggyakoribb hálózati szolgáltatásokig jutunk el. A Linux szorosan kötődik a hálózatokhoz. Létrejöttét az internetnek köszönheti. A hálózati támogatás a kezdetek óta megtalálható benne, és funkcióját tekintve is, mint hálózati kiszolgáló szerver a legelterjedtebb.
6.1.
Röviden a TCP/IP hálózatokról25 [10]
Az Internet kialakulásához nagymértékben hozzájárult az Amerikai Védelmi Minisztérium egyik kutatási projektje, melynek célja egy nehezen megsemmisíthető, katonai célú számítógépes hálózat létrehozása volt. E kutatás során kifejlesztettek egy csomagkapcsolt hálózati protokollt, mely felépítésével és redundáns útvonalaival biztosítani tudta a megfogalmazott követelmények maradéktalan teljesítését. A protokoll – amely TCP/IP néven vált ismertté – civil alkalmazására először az 1970-es évek közepén került sor egy elsősorban az amerikai egyetemekhez kötődő számítógépes hálózatban, hogy később ebből a hálózatból fejlődjön ki a mai internet. Napjainkra a hálózat az egész világot átszövi, megváltoztatja az emberek üzletről, szórakozásról, információáramlásról alkotott képét, jelentősége napról napra nő és ezért rendkívül fontos az alapját képező technológia megismerése és megértése. 6.1.1.
Kommunikáció a hálózaton
Az internet lokális hálózatokból épül fel. Sok kisebb nagyobb hálózatból, amelyeket routerek kapcsolnak össze. Ez azt is jelenti, hogy a hálózati komunikáció azonos lokális hálózaton levő számítógépek között másképpen zajlik mint az egymástól távoli, különböző lokális hálózatba tartozó számítógépek között. 6.1.1.1.
Lokális hálózat
Lokális hálózatnak tekintendő az a hálózat amelyen belül két számítógép között router közbeiktatása nélkül, közvetlenül lehet kommunikálni. Ez sok esetben egyetlen (koaxiális) kábelt jelent, de jelenthet hubokkal, vagy switch-ekkel összekapcsolt koaxiális vagy UTP kábelre kapcsolódó számítógépeket is. Szokás ezt szegmensnek vagy alhálózatnak is nevezni. Többfajta hálózat típus is létezik (Token bus, Token ring, Ethernet stb.) melyek közül most csak az Ethernetre térünk ki. Itt egy szegmensen, jellemzően egyszerre csak egy számítógép kezdeményezhet kommunikációt (adó). Ha valamelyik gép adni szeretne, akkor megvizsgálja, hogy szabad-e a kábel, ha igen, akkor használni kezdi. Persze még ekkor is előfordulhat, hogy többen egyszerre kezdik használni a kábelt, ilyenkor természetesen nem lehetséges értelmes kommunikáció – ezt hívják ütközésnek. Ezt az interfészek (hálózati kártyák) felismerik, ekkor azonnal beszüntetik a forgalmazást, majd véletlen ideig várnak, és újra próbálkoznak. Tehát egyszerre mindig csak egy gép forgalmazhat, viszont az üzenet szólhat mindenkinek (broadcast) illetőleg egy meghatározott címzettnek. Természetesen a csomagot elvileg minden gép látja (hiszen azonos kábelhez csatlakoznak), de csak az használja fel, akinek szól (illetve broadcast esetén mindenki). Hogy 25 Az alfejezet egyes részei Kovács Ferenc és Nagy Tamás TCP/IP hálózat működése, TCP/IP alapú kommunikáció című jegyzetéből került átvételre.
131
kinek szól, azt a címzett gép hálózati kártyájának fizikai címe (MAC address, Ethernet address stb.) határozza meg. Ez a cím minden hálózati kártyára egyedi, és csak ennek ismeretében lehetséges két számítógép között kommunikációt megvalósítani. Miért van szükség akkor az IP címre, miért nem használja a protokoll a fizikai címeket? Először is mert kényelmetlen, nehezen megjegyezhető. De ami sokkal fontosabb megváltoztathatatlan, ezért rugalmatlan, ami azt is eredményezi, hogy önmagában a címzett fizikai címének ismeretében nem vagy csak nagyon nehezen eldönthető, hogy a címzett az adott szegmensbe tartozik-e vagy sem, márpedig két számítógép egymással csak akkor tud közvetlenül kommunikálni, ha egy alhálózatba tartoznak. Hogyan dönthető akkor el, hogy egy adott IP címmel rendelkező gépnek (címzett) mi a fizikai címe? Erre szolgál az ARP (Address Resolution Protocol). Ha egy gép egy másikhoz akar kapcsolódni – amelyről a subnet mask alapján tudja, hogy vele azonos alhálózaton van –, akkor elküld egy broadcast üzenetet, amelyben megkérdezi, hogy ki is az adott IP címmel rendelkező számítógép és mi is az ő fizikai címe. Az üzenetet mindenki veszi, de csak az válaszol rá, aki az adott IP cím tulajdonosa, és elküldi a kezdeményezőnek a saját fizikai címét (a kezdeményező a sajátját természetesen feltüntette az üzenetben). Ezután a kezdeményező – hogy ne kelljen folyton ARP üzeneteket küldözgetni – elhelyezi a címzettre vonatkozó információkat egy gyorsítótárba (ARP Cache) és legközelebb, ha ugyanazzal a címzettel akar kommunikálni, akkor már abból veszi az adatokat. 6.1.1.2.
Globális hálózat
Mi történik akkor, ha olyan címzettel akar egy számítógép kommunikálni, aki nincs vele egy szegmensen? Ekkor jut szerephez a router. A router (útválasztó) egy kitüntetett számítógép a szegmensen, amely egyszerre több lokális hálózathoz is kapcsolódik, és amelyik épp ezért több szegmensbe is tud adatot küldeni, így lehetővé teszi a szegmensek közötti kommunikációt. Ha egy számítógép egy másik szegmensben (ezt az alhálózati maszk segítségével állapítja meg) lévő géppel akar kommunikálni, akkor nem közvetlenül a címzettel kezdeményez kapcsolatot, hanem az alapértelmezett útválaszóval (ez minden gép esetén be van állítva). Ehhez persze először ARP-vel kideríti a router fizikai címét, majd elküldi az adatcsomagot, azzal az utasítással, hogy végeredményben a megadott IP címre kell eljuttatni. Ezután ha a célcím valamely a routerhez kapcsolódó alhálózathoz tartozik (megintcsak alhálózati maszk), akkor ARP-vel kideríti annak a fizikai címét, és elküldi a csomagot. Ha a címzett egyik a routerhez kapcsolódó szegmenshez sem tartozik, akkor a router is egy másik – vele egy szegmensen levő – routerrel veszi fel a kapcsolatot, és annak küldi tovább a csomagot. Fontos észre venni, hogy két számítógép között ebben az esetben is csak egy szegmensen belül, és a fizikai címek alapján zajlik a közvetlen kommunikáció, szegmenseken kívülre közvetetten (routerek közbeiktatásával) kerülnek a csomagok. 6.1.2.
A TCP/IP protokoll ismertetése
A TCP/IP a protokollt csomagkapcsolt hálózatok adatátviteli protokolljára hozták létre. Ez egy négy réteget tartalmazó hálózati protokoll rendszer (lásd 14. ábra), szemben az ISO OSI hét rétegű modelljével.
132
Application Transport Internetwork Host to network 14. ábra. A TCP/IP protokoll felépítése 6.1.2.1.
Host to Network Layer
Ez a szint az OSI modell fizikai és adatkapcsolati rétegéhez áll közel, feladata a kapott bájtok átvitele. A fölötte levő rétegek csak azt várják el tőle, hogy bájtfolyamokat tudjon fogadni, illetve átadni. 6.1.2.2.
Internetwork Layer
Ez a réteg felelős az adatok átviteléért a hálózaton, a gépek közötti kapcsolat összeköttetés-mentes és nem tudja biztosítani a réteg az adatok korrekt átvitelét sem. Ezen a szinten több protokoll is megtalálható, de ezek közül a legfontosabbak: • IP (Internet Protocol); • ARP (Address Resolution Protocol); • ICMP (Internet Control Message Protocol). 6.1.2.2.1.
Internet Potocol
Ez a protokoll gondoskodik a csomagok átviteléről a hálózaton, a hostok közötti összes kommunikáció IP csomagok formájában történik. Ez egy kapcsolat nélküli protokoll, a kommunikációhoz nem szükséges előzetes kapcsolatfelvétel. Adatátvitel szempontjából nem megbízható, a csomagokkal bármi megtörténhet: elveszhetnek, megsérülhetnek, sorrendjük összekeveredhet. Egy IP csomag két részből áll: IP fejrész: Ez tartalmazza a csomagot azonosító információkat. (Lásd 15. ábra.) Adat: Ebben a részben van az az adat, amit ténylegesen át kell vinni. Az egyes mezők jelentése az IPv4-es fejrészben: Version: Ez egy négybites információ arról, hogy a fejrész milyen IP verziót használ. Header Length: A fejrész hossza bájtos egységekben. TOS (Type Of Service): Ebben a mezőben lehet megadni kéréseket a routerek felé, hogy a csomagot hogyan továbbítsák. A csomaghoz prioritást lehet rendelni, kérni lehet, hogy a kisebb késleltetésű úton menjen a csomag, nagyobb sávszélesség felé menjen a csomag, nagyobb megbízhatóságú úton menjen a csomag, stb. Ez csak egy kérés a routerek felé, melyek nem kötelesek ezeket figyelembe venni. 133
Version
Header length
TOS
Total length Identifier Flags
Fragment offset TTL
Protocol Header Checksum Source Address
Destination Address
Options 15. ábra. Az IPv4-es fejrész felépítése Identifier: A fragmentáció támogatására szolgál. Amennyiben egy IP csomagot fel kell bontaniuk a routereknek kisebb csomagokra akkor, ebben a mezőben lesz benne egy azonosító az eredeti csomagra. Erre akkor lehet szükség, amikor az egyes alhálózatok eltérő keretmérettel dolgoznak, ezért szükségessé válhat a csomagok hosszának a csökkentése. A fragmentáció során keletkezett csomagokat természetesen a routerek nem építik össze egy egységes csomaggá, amikor már a csomagméret megengedhetné, mivel az egyes IP csomagok két host között nem feltétlenül egy útvonalon közlekednek. Az eredeti csomag előállításáról mindig a hostoknak kell gondoskodniuk. Flags: Ez a mező is a fragmentáció támogatására szolgál, amennyiben egy csomag fragmentált akkor ebben a mezőben jelzik ezt. Fragment offset: Fragmentált csomag esetén azt mutatja, hogy ez a csomag az eredetinek hányadik darabja. TTL (Time To Live): Ez a mező minden egyes routoláskor eggyel csökken, amennyiben ez a mező 0-ra csökken akkor a routerek eldobják a csomagot. Ez arra szolgál, hogy hibás címmel bekerült csomag ne keringjen végtelenségig a hálózaton. Protocol: Ebben a mezőben adják meg, hogy milyen fejrészt tartalmaz az IP csomag adat része. Azaz milyen protokoll várja fent ezt a csomagot (pl: TCP, UDP, ICMP stb.). Header checksum: A fejrészre vonatkozó ellenőrzőösszeg. Source Adress: A küldő IP címe. Destination Adress: A címzett IP címe. 134
6.1.2.2.2.
Adress Resolution Protocol
Az ARP részletes ismertetése elolvasható a 6.1.1.1.-ban. 6.1.2.2.3.
Internet Control Message Protocol
A két kommunikáló fél ennek segítségével küld egymásnak beállítandó paramétereket, valamint hibajelzésre is szolgál. Természetesen ez is IP csomag formájában közlekedik a hálózaton, az adat mezőbe van beírva az üzenet. Az adatmezőben van két darab bájt, amely az üzenet azonosítására szolgál. Ezt követi az ellenőrző összeg, majd opcionálisan az egyéb az egyéb paraméterek. Tipikus üzenetek lehetnek: • Hibás IP fejrész ellenőrző összeg; • A címzett nem elérhető; • Az írási sebességet lassítsa a küldő; • Echo req/replay; • TTL mező 0-ra csökkent. 6.1.2.3.
Transport Layer
Ezen a szinten két különböző protokoll található, melyek teljesen eltérő tulajdonságúak: • TCP (Transmission Control Protocol); • UDP (User Datagram Protocol). 6.1.2.3.1.
Transmission Control Protocol
Megbízható adatátvitelt biztosít a felsőbb rétegek számára úgy, hogy alatta egy megbízhatatlan protokoll található. Felülről bájtfolyammal lehet táplálni (stream orientált), full duplex átvitelt biztosít (kapcsolat orientált). Kliens-szerver kapcsolatok kialakítására képes, bárki lehet egyszerre kliens és szerver is. A kapcsolat felvétele mindkét oldalon nyugtázva történik. A kezdeményező küld egy kérés csomagot, a címzett válaszol a kérésre, majd a kezdeményező küld egy nyugtát arról, hogy vette a címzett válaszát. A kapcsolatok azonosítására szolgálnak a portok, a szerver egy adott porton érkező kérésekre figyel, és az ott érkező kéréseket kiszolgálja. A TCP portok közül az első 1024 foglalt a standard alkalmazások számára. A megbízhatóság érdekében a protokoll a teljes TCP csomagra számol ellenőrző összeget. A megbízható kapcsolat kialakítására pozitív nyugtázást használ. A küldő oldal nyugtát vár minden egyes elküldött TCP csomagról. Amennyiben egy később küldött csomagról előbb kap nyugtát, mint egy korábban küldött csomagról, akkor a korábban küldött csomagtól kezdve megismétli az adást. Egy TCP csomag szintén két részből áll: egy fejrészből és az átviendő adatokból. 6.1.2.3.2.
User Datagram Protocol
Ez sokkal gyorsabb, mint a TCP protokoll, viszont adatátvitel szempontjából nem megbízható. Nem kapcsolat orientált, nincs hibajavítás és nincs nyugtázás. Tulajdonképpen az IP szint által biztosított 135
szolgáltatásokat nyújtja felfelé. Akkor szokták használni, ha az adatátvitel sebessége a legfontosabb, minden többi feladatot a felette elhelyezkedő réteg lát el. Tipikusan a DNS-ek (Domain Name Server), valós idejű alkalmazások, játékok szokták használni (egy valós idejű hangátvitel esetén, pl. voip telefonálás, ha egy csomag rossz akkor a hang ott legfeljebb sercen egyet, de ez még mindig kisebb baj, mintha az adott pontnál az adás megállna, és onnantól elkezdené újra adni a csomagokat). A szegényesebb szolgáltatásból adódóan sokkal egyszerűbb az UDP fejrész. 6.1.2.4.
Application Layer
Ezen a szinten helyezkednek el az alkalmazások. Az adatok átvitelét TCP, vagy UDP porton keresztül történő hívásokkal valósítják meg. A portok tulajdonképpen a kommunikációs csatorna egy végpontjának az azonosítására szolgálnak. A szabvány 65535 db TCP és 65535 db UDP portot engedélyez, ezek közül az első 1024 foglalt szabványosított protokollok számára (pl.: Telnet, SMTP, POP3, Rlogin, FTP SNMP, STMP, HTTP stb.). Az összeköttetés kliens-szerver alapon valósul meg. Az egyes szerver alkalmazások az adott host gép operációs rendszerénél bejegyeztetik magukat, hogy egy adott TCP, vagy UDP portra érkező kérések kiszolgálásáért az adott alkalmazás a felelős. Az egyes kliens alkalmazások, amikor megszólítják a szerver gép adott portját akkor az ott futó operációs rendszer értesíti a szerver alkalmazást arról, hogy kérés érkezett az adott portra. Azaz amikor egy szolgáltatás azonosítására van szükség a hálózaton akkor nem elég a szerver gép IP címét megadni, hanem szükséges az adott szolgáltatáshoz kapcsolódóan megadni a szerver adott TCP, vagy UDP portját.
6.2.
Hálózati eszközök
A Unix rendszerek alatt a hálózati eszközök leírói gyakran a /dev könyvtárban vannak. Azonban a Linux nem tartozik ezek közé. Linux alatt a hálózati eszközök dinamikusan a kernelben jönnek létre, és nem tartozik hozzájuk eszköz állomány. Az esetek többségében automatikusan hozzák létre az eszközvezérlők. Az interfészek elnevezése általában pedig az eszköz típusától függ. Elnevezés
Típus
eth[0. . . n]
Ethernet
isdn[0. . . n]
ISDN
ppp[0. . . n]
Modem, xDSL
tr[0. . . n]
Token Ring
lo
Loopback
32. táblázat. Hálózati eszközök
Amennyiben a Linux kernelben a hálózati eszköz aliasok támogatása be van kapcsolva, akkor létrehozhatunk virtuális hálózati interfészeket is. Ezek ugyanazt a fizikai eszközt használják, amelyből származtattuk, azonban más IP cím beállításokkal láthatjuk el őket. Ezen virtuális interfészek neve az eredeti fizikai eszköz neve után írt egy kettősponttal elválasztott számból áll. Például az eth0 eszközből származtatott első virtuális interfész neve eth0:0. 136
6.3.
A hálózati interfészek konfigurálása
A hálózati interfészek kernel rezidens részeinek kezelésére az ifconfig program szolgál. Segítségével aktiválhatjuk, vagy deaktiválhatjuk az interfészeket, illetve beállíthatjuk az interfészek jellemzőit: IP cím, netmask stb. Paraméterek nélkül meghívva kilistázza az aktív interfészeket. Az eth0 interfész deaktiválása: ifconfig eth0 down Az eth0 interfész IP cím beállítása és aktiválása: ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
Feladat Aktiváljuk egy, a hálózati interfészünkből származó virtuális interfészt a 192.168.0.0/255.255.255.0 tartományból választott címmel, majd próbáljuk ki! Az ifconfig mellett az ip programmal is konfigurálhatjuk a hálózati interfészeket, de akár rountingot is beállíthatunk vele. $ ip addr show 1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth1: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 08:00:27:c6:e9:27 brd ff:ff:ff:ff:ff:ff inet 10.0.2.15/24 brd 10.0.2.255 scope global eth1 inet6 fe80::a00:27ff:fec6:e927/64 scope link valid_lft forever preferred_lft forever $ $ ip route show 10.0.2.0/24 dev eth0
proto kernel
169.254.0.0/16 dev eth0
scope link
default via 10.0.2.2 dev eth0
scope link metric 1000
proto static
$
137
src 10.0.2.15
metric 1
6.3.1.
Red Hat konfigurációs szkriptek
A Red Hat disztribúció tartalmaz egy szkriptgyűjteményt a hálózati interfészek automatikus felkonfigurálására, és egyszerűbb kezelésére. A szkriptek az /etc/sysconfig/network-scripts könyvtárban található konfigurációs állományokat használják az interfészek beállítására. A könyvtár minden interfészhez tartalmaz egy állományt melynek elnevezése: ifcfg-<eszköz>. Ezeket egészíti ki az /etc/sysconfig/network konfigurációs állomány, amely a globális routing és host beállításokat tartalmazza. Mindezeket a konfigurációs állományokat könnyen módosíthatjuk a system-config-network program segítségével. 6.3.2.
Az /etc/network/interfaces állomány
A Debian alapú disztribúcióknak általában része az /etc/network/interfaces állomány. Ez tartalmazza az egyes interfészek beállításait, gyakorlatilag itt állítjuk be, hogyan kapcsolódjon a rendszerünk a hálózathoz. Az állomány tartalma különböző hálózatok és kapcsolódási módok esetén igen eltérő lehet. Az alábbi példában először egy statikus kapcsolatot, majd egy DHCP segítségével létrejött, ezért jóval rövidebb leírással rendelkező, kapcsolatot láthatunk. # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet static address 192.168.1.90 gateway 192.168.1.1 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet dhcp
6.3.3.
Az Ethernet interfész
Egy Ethernet interfész esetén az állomány tartalma a következő (ifcfg-eth0): 138
DEVICE=eth0 BOOTPROTO=static IPADDR=192.168.0.136 NETMASK=255.255.255.0 ONBOOT=yes USERCTL=no DEVICE: Tartalmazza az eszköz nevét. BOOTPROTO: Az IP cím beállítás módját adja meg: statikus (static), dinamikus (bootp, dhcp). IPADDR, NETMASK: Az IP-beállítások. ONBOOT: Ez adja meg, hogy az interfész a rendszer indulásakor automatikusan aktiválódjon-e, vagy sem. USERCTL: Megadja, hogy nem root felhasználók kezelhetik-e az eszközt. Azonban a konfigurációs szkript tartalmazhat még további opciókat is: DHCP_HOSTNAME: Csak abban az esetben használjuk, ha a DHCP szerver megköveteli, hogy megadjunk egy host nevet, amire ő az IP címet szolgáltatja. DNS{1,2}: Megadhatunk DNS szerver címeket, amelyet a szkript automatikusan elhelyez az /etc/resolv.conf állományban amikor az interfész aktív. Azonban ehhez engedélyezni kell a PEERDNS opciót is. HWADDR: Amennyiben több hállókártyát is tartalmaz a gépünk, akkor a MAC címmel specifikálhatjuk, hogy melyiket kívánjuk konfigurálni. MACADDR: Beállíthatjuk a hálókártya MAC címét (értelemszerűen az előző opcióval együtt nem szabad használni). NETWORK: Megadhatjuk a hálózati címet, de használata nem kötelező. PEERDNS: Ha engedélyezzük, akkor a hálókártya konfiguráló szkriptek az /etc/resolv.conf állományt is frissítik. Elsősorban a DHCP szerverek esetén használatos, mivel ezen szolgáltatás automatikusan megadja a hálózaton használható névszervereket. 6.3.4.
Az Alias interfész
Nem túl gyakori, de azért időnként felmerülő igény, hogy egy hálózati interfészhez több IP címet rendeljünk. Ezt könnyen megtehetjük alias interfészek használatával. Alias interfészeket az ifcfg konfigurációs állományokkal is létrehozhatunk. Ilyenkor csak a :<szám> résszel kell kiegészíteni az interfész nevét. Pl. ifcfg-eth0:0. Ezt az interfészt ugyanúgy felkonfigurálhatjuk, mint az eredetit, amiből származik. Logikailag egy másik interfészt alkot, de fizikailag természetesen ugyanarról az eszközről van szó. 139
6.3.5.
Egyéb interfészek
Az ifcfg-<eszköz> konfigurációs állományokkal még további interfész típusokat is beállíthatunk: ifcfg-lo: A loopback hálózati interfész beállítása. A loopback interfész feladata a gépen belüli IP kommunikáció lekezelése. ifcfg-irlan0: Az infravörös kapcsolatok interfésze. ifcfg-tr0: A token ring kommunikáció interfésze (ezt lényegében már kiszorította az Ethernet). 6.3.6.
Interfész kontroll szkriptek
Az eddigi fejezetekben definiált interfész konfigurációk segítségével az /etc/sysconfig/network-scripts könyvtárban található interfész-specifikus ifup és ifdown szkriptek konfigurálják fel, illetve állítják le az interfészeket. Azonban a megfelelő szkript kiválasztását elintézik nekünk az /sbin könyvtárban található ifup és ifdown front-end szkriptek. Pl. ifup eth0 Amennyiben az összes hálózati interfészt szeretnénk egyszerre leállítani, elindítani, vagy újraindítani, akkor ezt az /etc/init.d/network szkripttel tehetjük meg. 6.3.7.
Grafikus konfiguráció
Napjaink egyik legelterjedtebb grafikus hálózati konfigurációs eszköze a NetworkManager. A Red Hat azzal a céllal kezdte el 2004-ben a fejlesztését, hogy a mai hálózatorientált világunkban a konfigurációt gyorsabbá, egyszerűbbé tegye. Ha van Ethernet kábelen keresztül elérhető hálózat, akkor alapesetben a NetworkManager azt fogja választani, döntését természetesen felül is bírálhatjuk. Ezek után a NetworkManager mindig a már korábban használt WLAN-ok egyikéhez próbál kapcsolódni, de ha azok közül egyik sem elérhető, akkor valamelyik nyílt WLAN hálózatot fogja választani. Ha egy titkosított hálózathoz kapcsolódunk, akkor ennek megfelelően kérni fogja a WEP, vagy WPA kulcsunkat. A NetworkManager két fő komponensből áll: 1. A háttérben futó szolgáltatásból, ami menedzseli a kapcsolatokat és figyeli a hálózatot. 2. A grafikus felhasználói felületből, amivel az egyes kapcsolatok közül választhatunk, VPN-t állíthatunk be stb.26 A különböző asztali környezetek eltérő kinézetű NetworkManagerrel rendelkeznek, de ezek leginkább csak kinézetükben térnek el, az általuk kínált szolgáltatások álalában megegyeznek. A NetworkManager egyik legfőbb tulajdonsága, hogy a mobil internet és a mobiltelefonok igen széles skáláját ismeri, ezért ma egy NetworkManagert használó Linux disztribúcióval mobil eszközről is nagy eséllyel gond nélkül tudjuk használni a világhálót. 26 Az
nmcli program segítségével a garfikus felülethez hasonlóan a parancssorból is kezelhetjük a NetworkManagert.
140
16. ábra. A NetworkManager applet
6.4.
Útválasztás
Először is érdemes definiálni mi is az az IP routing. Az IP Routing egy olyan folyamat, amelynek segítségével egy több hálózati interfésszel rendelkező host eldönti, hogy a kapott IP csomagokat merre továbbítsa. Nézzünk erre egy gyakorlati példát! Képzeljünk el egy kis céget, amelynek van egy routere. Ez két Ethernet interfésszel rendelkezik a cég két alhálózatához, és egy PPP interfésszel az Internet felé. Amikor a router kap egy csomagot valamelyik interfészén keresztül, akkor a routing az a mechanizmus, amelynek segítségével eldöntheti, hogy melyik interfészén kell tovább küldenie. Az egyszerű hostok is rendelkeznek routing táblával. Minden hálózatra kapcsolt gépnek legalább két interfésze van. Egy virtuális loopback interfész, melyet a lokális visszacsatolásokhoz használ a rendszer, és egy valódi hálózati interfész (Ethernet, PPP stb.). Ezek után nézzük, hogyan is működik ez a mechanizmus. Minden host tartalmaz egy speciális listát a routing szabályokról, ezt hívjuk routing táblának. Ennek a táblának a sorai legalább három információt kell, hogy tartalmazzanak. Egyrészt a cél címét (ez gyakran egy alhálózat címe és netmaskja), az interfészt, amelyen a csomagot továbbítja, és a harmadik opcionális, egy router címe amely a csomag továbbításában a következő lépcső szerepet tölti be. Ezt a táblát a route paranccsal listázhatjuk ki. Maga a routing folyamat egyszerű: Ha a számítógép kap egy csomagot, akkor megvizsgálja célcímet és összehasonlítja a tábla minden bejegyzésével. Kiválasztja a legjobban illeszkedő sort (a legspecifikusabb az illeszkedő sorok közül) és továbbítja a csomagot az adott interfész felé. Ha az átjáró mező is ki van töltve, akkor az adott gépnek küldi tovább, ha nincs kitöltve, akkor úgy veszi, hogy a célgép az adott hálózaton helyezkedik el, és közvetlenül oda továbbítja. Ezt a táblát az előbb megismert route paranccsal kezelhetjük. A parancsot különböző paraméterekkel meghívva hozzáadhatunk, törölhetünk vagy módosíthatunk sorokat a táblában. (Ezt a táblát a kernel
141
kezeli, a route parancs rendszerhívásokkal kéri a kerneltől a tábla módosítását.) Nézzünk egy példát a routing tábla kezelésére! A következő módon hozzáadhatunk egy sort a routing táblához, amellyel megmondjuk a kernelnek, hogy a 192.168.1.* IP című gépeknek szánt csomagokat ezen az interfészen küldje ki: route add -net 192.168.1.0 netmask 255.255.255.0 eth0 Lényeges a -net paraméter megadása. Ez jelzi, hogy a megadott cím egy hálózatot jelöl. (Egyes gépeket a -host paraméterrel adhatunk meg.) Ezzel a bejegyzéssel már létrehozhatunk IP kapcsolatokat a szegmensünk gépeivel. Azonban ahhoz, hogy a világ többi részével is beszélgetni tudjunk, az ő hálózatuk irányába is be kell állítanunk routing szabályokat. De mivel egy gépen keresztül látjuk az internetet, ezért elég csak egy szabályt megadnunk, amely az összes olyan csomagot, amire nem tudtunk szabály sort illeszteni, elküldi ennek a routernek. Ő majd gondoskodik arról, hogy továbbmenjen. Ezt a szabályt nevezzük default szabálynak, a gépet pedig default átjárónak. A default átjárót az alábbi paranccsal állíthatjuk be. route add default gw 192.168.1.1 eth0 A gw paraméter jelenti azt, hogy az IP cím egy átjáró (router) címe vagy neve, amely a csomagot továbbítja a célhoz. Az interfészeknél már említett konfiguráló szkript mechanizmusnak a alapértelmezett átjárót is megadhatjuk, hogy a rendszer indulásakor automatikusan beállítsa rá a routing szabályt. Ezt a paramétert (GATEWAY) az /etc/sysconfig/network állományban találjuk.
6.5.
Névleképezés
Mivel az IP címek az emberi elme számára nehezen megjegyezhetőek, ezért az IP címekhez neveket rendelünk. Az előbb említett /etc/sysconfig/network állományban a gépünk nevét is beállíthatjuk (HOSTNAME). Azonban ez lényegében az önfelismerést szolgálja, vagyis hogy az egyes szolgáltatások tudják, hogy mi a gép neve. Az igazi nevet természetesen a DNS (Domain Name System) szerver határozza meg. A gépünk által használt DNS szervereket az /etc/resolv.conf állományban állíthatjuk be. A nameserver direktíva után adhatjuk meg a DNS szerver IP címét. Természetesen több szervert is megadhatunk egymás után. Ezek sorrendje határozza meg, hogy melyik szerverhez forduljon először. Ha a saját hálózatunk gépeire nem szeretnénk teljes névvel hivatkozni, akkor a search direktíva után megadhatjuk domain nevet, így a rendszer automatikusan megpróbálja a név után illeszteni. Ha szeretnénk statikus név-IP cím összerendeléseket is összehozni (pl. a 127.0.0.1 IP cím a localhost), akkor azt az /etc/hosts állományban tehetjük meg.
6.6.
A Network Configuration program
A hálózati konfigurációs állományok kezelésének egyszerűsítésére a Red Hat disztribúció tartalmaz egy grafikus eszközt is. A program neve Network Configuration, és a system-config-network RPM csomag 142
része.
17. ábra. Network Configuration főablak Ezzel a programmal könnyen létrehozhatunk konfigurációs állományokat az új interfészeknek, vagy módosíthatjuk a beállításait a már meglévőknek. Emellett lehetőség nyílik a DNS szerver és a hosts állomány beállításainak megváltoztatására is.
6.7.
Hálózati szolgáltatások automatikus indítása
Miután a hálózati eszközök konfigurációját befejeztük a következő lépés az egyes hálózati szolgáltatások beüzemelése. A szerverprogramok alapvető működési elve, hogy a hálózaton keresztül várják a kliens programok kapcsolódását, majd kiszolgálják azok kéréseit. Ezért a szerver programok gyakran a hátérben folyamatosan futó processzek, amelyek egyes TCP, UDP portokra kapcsolódva várják a felhasználókat. Ezeket a szolgáltatásokat a már korábban megismert módokon indíthatjuk automatikusan. Ennek hátránya, hogy ilyenkor a processzek idejük jelentős részében csak várnak és foglalják az erőforrásokat. Azonban létezik egy másik metódus is. Az inetd program segítségével elérhetjük, hogy a szolgáltatás csak akkor induljon el, amikor szükség van rá. Ilyenkor csak az inetd daemon indul el és fut folyamatosan. Várja a szolgáltatások portjain a kapcsolódási kérelmeket, majd amikor érkezik egy, akkor automatikusan elindítja a szerver szolgáltatást. Az inetd egy flexibilisebb és biztonságosabb változata az xinetd program, amellyel manapság a Linux szervereken találkozhatunk. Az xinetd által indított szolgáltatásokat két csoportra oszthatjuk. A szolgáltatások egyik csoportját többszálúnak hívják. Ez működési elvükből adódik, mivel az xinetd minden kapcsolódási kérelem hatására egy újabb példányt indít el belőle. Az új példány kezeli a továbbiakban azt a kapcsolatot, az xinetd pedig várja az újabb kapcsolódásokat.
143
A másik csoport azonban olyan szolgáltatásokat tartalmaz, amelyek az összes kapcsolódási kérelmet egymagukban kezelik le. Ezeket nevezzük egyszálúnak. Az xinetd egy ilyen szolgáltatás elindítása után felfüggeszti az újabb kérelmek lekezelését, azt meghagyja a szolgáltatásnak egészen addig, amíg a szerver program le nem áll. Az ilyen szolgáltatások általában UDP alapúak. Azonban az xinetd daemon az eddigieken kívül további előnyökkel is rendelkezik. A mechanizmus révén központosítva adminisztrálhatjuk a szolgáltatásokhoz való hozzáféréseket, továbbá könyvelhetjük az egyes szolgáltatások tevékenységét. Az xinetd program konfigurációs állománya az /etc/xinetd.conf. Ebben sorolhatjuk fel az egyes szolgáltatások paramétereit. Az egyszerűbb kezelhetőség érdekében azonban ezt az állományt általában részekre szokás bontani. A Red Hat és Ubuntu disztribúciókban az egyes szolgáltatásokhoz külön állományok tartoznak az /etc/xinetd.d könyvtárban. Az egyes szolgáltatások paraméterei a következő formában találhatóak: service <szolgáltatás neve> { <paraméter> <érték> <érték> ... ... } Az operátor a következő jelek valamelyike: „=”, „+=”, „-=”, de a paraméterek nagyrészénél csak a „=” jel értelmezett. Ezzel állíthatjuk be egy jellemző értékét. Azonban ha egy paraméter érték listát is tartalmazhat, akkor „+=” jellel vehetünk fel új elemeket a listába, a „-=” jellel pedig eltávolíthatjuk. Paraméter
Leírás
id
A szolgáltatás egyedi azonosítója.
type
A szolgáltatás típusa: RPC kommunikáció (Remote Procedure Call), az xinetd belső szolgáltatása (INTERNAL), TCPMUX szolgáltatás [11], nem szabványos (UNLISTED).
flags
A szolgáltatás működésének speciális beállításai.
disable
A szolgáltatás letiltása („yes” vagy „no”).
socket_type
A kommunikáció típusa: stream, dgram, raw (IP), seqpacket (szekvenciális datagram).
protocol
A protokoll típusa, lásd /etc/protocols (értéke általában tcp, vagy udp).
wait
Ezzel a paraméterrel állíthatjuk be, hogy az szolgáltatás egyszálú (yes), vagy többszálú (no).
user
A szolgáltatás felhasználóazonosítója.
144
Paraméter
Leírás
group
A szolgáltatás csoportazonosítója.
instances
Egyszerre hány példány lehet aktív a szolgáltatásból.
nice
A szolgáltatás processzének prioritása.
server
A szolgáltatáshoz futtatott program.
server_args
A szolgáltatás programjának paraméterei.
only_from
A szolgáltatás csak a felsorolt IP címekről, illetve tartományokból érhető el.
no_access
A szolgáltatás a felsorolt IP címekről, illetve tartományokból nem elérhető.
access_times
Korlátozhatjuk a hozzáférést az idő alapján is.
log_type
A logolás metódusa.
log_on_success
A szolgáltatás elindulásakor logban eltárolandó paraméterek.
log_on_failure
Meghatározza a logolandó információkat, amikor valami oknál fogva nem sikerül a szolgáltatás elindítása.
env
A szerver processz számára beállított további környezeti változók.
passenv
Az xinetd processz környezeti beállításaiból a szerver processz számára továbbítottak listája.
port
A szolgáltatás portja.
redirect
A TCP alapú szolgáltatást az xinetd átirányítja egy másik gépre.
bind
A szolgáltatás hálózati interfészhez rendelése.
interface
Lásd bind.
banner
A kapcsolódáskor elküldött szövegállomány.
banner_success
Engedélyezett, sikeres kapcsolódás esetén elküldendő szövegállomány.
banner_fail
Megtagadott, vagy sikertelen kapcsolódás esetén elküldendő szövegállomány.
per_source
Az egy IP címről eredő kapcsolódások maximális száma.
cps
A maximális kapcsolódási ráta.
max_load
A megadott rendszerterheltségi limit fölött nem engedélyez több kapcsolódást a szolgáltatáshoz.
umask
A szolgáltatás processzének beállított umask értéke.
enabled
A szolgáltatás engedélyezése.
145
Paraméter
Leírás
rlimit_<erőforrás>
A szolgáltatás erőforrás limitációi.
deny_time
A szolgáltatások újraindításának minimális ideje. (Denial-ofservice támadások megakadályozására.) 33. táblázat. Hálózati szolgáltatások paraméterei
A service kulcsszó mellett használhatjuk a defaults kulcsszót is, amellyel az alapértelmezett értékeket állíthatjuk be.
Feladat 1. Vizsgáljuk meg az xinetd szolgáltatások beállításait! 2. Engedélyezzük valamelyik szolgáltatást és próbáljuk ki! A korábban megismert chkconfig programmal az xinetd szolgáltatásokat is engedélyezhetjük, letilthatjuk, listázhatjuk. Ebben az esetben természetesen nem adhatunk meg futásszintet.
Feladat 1. A chkconfig programmal listázzuk ki az xinetd szolgáltatásokat! 2. Tiltsuk le az előbb engedélyezett szolgáltatást!
6.8.
TCP Wrapper
A TCP Wrapper egy plusz védelmi réteget alkot az xinetd és a hálózat között (lásd 18. ábra), de természetesen más programok is használhatják. Feladata hogy központilag konfigurálhassuk a szerver hálózati szolgáltatásaihoz való hozzáférést. Ezt az /etc/hosts.allow és az /etc/hosts.deny állományokkal tehetjük, amelyekben az engedélyezéseket, illetve a tiltásokat állíthatjuk be. Elsőként a rendszer a hosts.allow állományban található szabályokat illeszti az adott kapcsolati kérelemre, így ha itt van találat, akkor a kapcsolat engedélyezve lesz. Ezek után elemzi a hosts.deny állományt. Ha itt találatunk van, akkor tiltva lesz a kapcsolat. A formátum: <szolgáltatás> : : [: ] ... vsftpd : .bme.hu Ha ezt a hosts.allow állományban helyezzük el, akkor a bme.hu gépeinek engedélyezzük az FTP szolgáltatás használatát. Ha pedig a hosts.deny állományba, akkor letiltjuk. Mind a szolgáltatásnál, mind a kliensnél használhatjuk az ALL kulcsszót. De kombinálhatjuk az EXCEPT operátorral is, amely kivételt jelent.
146
Internet
Tűzfal Kérés elfogadva
Kérés elutasítva
TCP Wrapper
xinetd Kérés elfogadva
Kérés elfogadva
TCP Wrappelt hálózati szolgáltatás
xinetd irányított hálózati szolgáltatás
18. ábra. Hálózati szolgáltatások védelme ALL EXCEPT vsftpd : .bme.hu Vagyis minden szolgáltatás kivéve az FTP. Ezen kívül még számos egyéb, de ritkábban használatos lehetőséggel rendelkezik a rendszer. Azonban jelenleg használata visszaszorult, és ezeket a megkötéseket tűzfalakkal kényszerítjük ki.
6.9.
Távoli shell alapú elérés
A telnet szerver lehetővé teszi, hogy távoli gépekről bejelentkezzünk a szerver gépre, és egy felhasználói shellt kapjunk. A telnet kliens egy virtuális terminált hoz létre a felhasználó számára. Ezen a felületen keresztül mindazt megtehetjük, amit a lokális virtuális terminálokon. A telnet szervert az xinetd mechanizmuson keresztül futtathatjuk.
Feladat 1. Állítsuk be az xinetd -t, hogy futtassa a telnet szervert!
147
2. Próbáljunk meg kapcsolódni a szomszéd gépére! (Ha szükséges, hozzunk létre felhasználókat a szomszédaink számára!) Azonban arra is lehetőségünk van, hogy a távoli gépen ne interaktív shellt futtassunk, hanem csak egyes parancsokat hajtsunk végre. Erre az RSH (Remote Shell) program szolgál. Az RSH szerver a telnethez hasonlóan az xinetd mechanizmuson keresztül futtatható. A kliens program parancs szintaxisa: rsh <-l felhasználó> host <parancs>
Feladat 1. Üzemeljük be az RSH szervert! 2. Futassunk parancsokat a szomszéd gépén! Azonban mind a telnet, mind az RSH nyílt, titkosítatlan kommunikációt használ, ezért lehallgatható. Azonban létezik egy biztonságos alternatívájuk, az SSH (Secure Shell). Működését tekintve az RSH-nak felel meg, azonban biztonságos, titkosított kommunikációt használ.27 Az SSH szerver program képes daemonként folyamatosan futni, de használhatjuk a az xinetd mechanizmuson keresztül is. Az utóbbi azonban nem célszerű. Az SSH szerver a működéséhez egy szerver kulcs legenerálását igényeli, azonban ha ezt minden kapcsolódáskor el kell végeznie, akkor az lelassítja a bejelentkezés műveletét. Az SSH kliens szintaxisa: ssh <-l felhasználó> host <parancs> ssh felhasználó@host <parancs> Ha nem adunk meg parancsot, akkor interaktív shellt kapunk, így a telnet programot is kiválthatjuk vele.
Feladat Vizsgáljuk meg, hogy fut-e a gépünkön az SSH szerver! Ha nem, akkor indítsuk el! Lépjünk be a szomszéd gépére! Az SSH szerver konfigurációját az /etc/ssh/sshd_config állományban állíthatjuk be. A kliens alapértelmezett konfigurációja az /etc/ssh/ssh_config állományban található.
6.10.
Állományok átvitele
Mind az RSH, mind az SSH szolgáltatás rendelkezik a lokális cp parancs gépek között alkalmazható változatával. Ezeknek neve rcp (Remote Copy), illetve scp (Secure Copy). A parancs szintaxisa: 27 Az SSH protokoll két változata létezik a v1 és a v2. A v1 protokoll jelenleg már nem tekinthető teljesen biztonságosnak, ezért csak a v2 használata javasolt.
148
scp [[user@]host1:]file1 [...] [[user@]host2:]file2 Használhatjuk még az -r paramétert, amellyel rekurzívan másolhatunk. Az ssh csomag tartalmaz még egy sftp nevű programot is, amellyel az FTP-hez hasonló módon tölthetünk le állományokat.
6.11.
Állományok megosztása
Manapság a számítógépek már nagy háttértárolókkal rendelkeznek, azonban még mindig szükség van a fájlszerverekre. Az okok lehetnek az alábbiak: • Fontos információk központi tárolása, mások számára elérhetővé tétele. • Az egyes számítógépek különböző veszélyeknek vannak kitéve, vírusok, meghibásodások, emberi hibák. Ezért biztonsági másolatokat helyezhetünk el a központi szerveren. • A munkaállomások könnyebb adminisztrációja, a telepítő állományok tárolása, vagy a programok központi szerverről való futtatása révén. 6.11.1.
FTP
Az állományok megosztásának egyik legrégebbi, és manapság is elterjedten használt módja az FTP (File Transfer Protocol) szerverek használata. A Linux rendszereken, akárcsak máshol, az FTP szerverek több változata is elterjedt. Jelenleg a Red Hat disztribúció a vsftpd (Very Secure FTP Daemon) programot használja. Ennek működése daemon jellegű. Azonban léteznek inetd alapú FTP szerver implementációk is. A vsftpd konfigurációs állománya Fedorán az /etc/vsftpd/vsftpd.conf, míg Ubuntun az /etc/vsftpd.conf. Az FTP szerverek működése alapján két változatot különböztetünk meg. A legáltalánosabban használt, amikor a rendszer felhasználói a nevükkel és jelszavukkal bejelentkezve, a felhasználói jogaikkal látják az állományrendszert. Ilyenkor kezelhetik a saját állományaikat. A másik működési mód, amikor publikálunk állományokat. Ebben az esetben a kliens programok azonosítás nélkül, ún. „anonymous”ként jelentkeznek be. Ekkor az FTP felhasználó jogaival tevékenykednek, és mozgási területük az FTP felhasználó home könyvtárára korlátozódik. (A vsftpd programban is bekapcsolhatjuk az „anonymous” működési módot.)
Feladat Tegyük elérhetővé az /export könyvtárat „anonymous” FTP-n keresztül!
6.11.2.
NFS
Az NFS (Network File System) protokoll a Unix rendszerek elterjedt megoldása az állományok megosztására. A Linux rendszerek üzemelhetnek NFS szerverként is, de kliensként fel is csatolhatjuk más szerverek megosztott könyvtárait.
149
Linux alatt az NFS szerver implementációja két részre oszlik. Egyrészt egy kernel modulra, másrészt egy felhasználói módú programra. A felhasználói módban futó folyamat fogadja a kapcsolódási kérelmeket, és indítja a kernel szálakat. Az NFS szerver elindulása és működése részben különbözik az eddig megismert daemon, illetve inetd alapú működéstől. Ennek oka, hogy RPC (Remote Procedure Call) alapú kommunikációra épül. Ezért igényli a működéséhez az RPC kommunikációs rendszert is, amelyhez kapcsolódik a folyamatosan futó daemon jellegű szerver. Az RPC kommunikációs rendszert a portmap szolgáltatással indíthatjuk el. Ezek után már futtathatjuk az nfs és az nfslock szolgáltatásokat. A könyvtár megosztásokat az /etc/exports állományban állíthatjuk be. Minden sor elején a megosztott könyvtár szerepel, majd ezt követi a megosztást elérhető kliensek listája (üres helyekkel elválasztva). Minden kliensnek külön megadhatjuk a hozzáférési jogait zárójelben. Kliensnek megadhatunk egyes gépeket névvel vagy IP címmel. De megadhatjuk gépek egy csoportját úgy, hogy a név megadásánál használjuk a „*” és „?” karaktereket, vagy IP címtartományt adunk meg. A hozzáférés paramétereit a 34. táblázatban láthatjuk. Paraméter
Leírás
ro
Csak olvasható a megosztás. (Ez az alapértelmezett.)
rw
Olvasható-írható a megosztás.
secure
A kliens kérelmének 1024 alatti portról kell érkeznie, vagyis csak root lehet a felhasználó. (Ez az alapértelmezett.)
insecure
A secure opció ellentéte.
async
Aszinkron módon kezeli a szerver a meghajtót, vagyis hamarabb válaszol, mint hogy letárolta a módosításokat.
sync
Szinkron kezeli a meghajtót. (Ez az alapértelmezett.)
no_wdelay
A szerver kicsit várakoztatja a módosítások kiírását a lemezre, ha arra számít, hogy még további kérelmek jöhetnek. Ezáltal, az adatok egyszerre kiküldésével növeli a rendszer teljesítményét.
subtree_check
Ha egy alkönyvtárt osztunk meg, akkor a jogok megfelelő kezeléséhez az NFS szervernek végig kell néznie, hogy az adott felhasználónak a szülő könyvtárakhoz van-e megfelelő hozzáférése, hogy a megosztott könyvtárhoz hozzáférjen. Ezt hívjuk subtree check nek. (Ez az alapértelmezett.)
no_subtree_check
A subtree check kikapcsolása. (Biztonsági problémát jelenthet.)
root_squash
A root azonosítókat (uid/gid 0) leképezi „anonymous” azonosítóra. (Ez az alapértelmezett.)
no_root_squash
Kikapcsolja a root azonosító leképezést.
all_squash
Minden felhasználót „anonymous”-ra képez le.
no_all_squash
Kikapcsolja az azonosítók leképezését. (Ez az alapértelmezett.)
anonuid
Az „anonymous” felhasználói azonosítója.
anongid
Az „anonymous” csoportazonosítója. 34. táblázat. Az NFS hozzáférés paraméterei
150
Nézzünk egy példát! /pub
*.valahol.hu(rw,all_squash)
Itt a /pub könyvtárat tettük elérhetővé a valahol.hu domain minden gépe számára olvasás-írás joggal, és a felhasználók „anonymous”-ra képezésével.
Megjegyzés Figyeljünk arra, hogy a gép név és az opciók között ne legyen üres hely! Nézzük az előző példa módosított változatát! /pub
*.valahol.hu (rw,all_squash)
Ilyenkor a valahol.hu domain gépei csak olvasási jogot kapnak (alapértelmezett), és a világ többi része olvasás-írás jogot.
Feladat Osszuk meg az /export könyvtárat mindenki számára csak olvashatóan, illetve a szomszédunk számára olvashatóan és írhatóan! Egy szerver NFS megosztásait a következő paranccsal listázhatjuk ki. showmount -e A megosztások konfigurálására is tartalmaz a Red Hat disztribúció grafikus konfiguráló programot. Ennek neve NFS Server Configuration, és a system-config-nfs RPM csomagban található.
151
19. ábra. NFS Server Configuration főablak Segítségével megosztásokat hozhatunk létre, törölhetünk, vagy paramétereit módosíthatjuk, és az előbb felsorolt paramétereket mind beállíthatjuk a megosztás számára.
20. ábra. NFS általános beállítások és felhasználói jogosultságok
6.12.
Samba
A Samba az SMB (System Message Block) protokollt implementálja, amely a Microsoft Windows kliensek és szerverek elsődleges protokollja az állományok és nyomtatók megosztására. Így a Linux alapú szerverek szolgálhatnak állományszerverként Microsoft Windows környezetben is. A szolgáltatás három daemonként futó alrészből áll: nmbd: A névregisztrációkat és feloldásokat kezelő daemon.
152
smbd: A fájl- és nyomtatómegosztásokat TCP/IP kapcsolatokon szolgáltató daemon. Továbbá kezeli a lokális autentikációs metódusokat. winbindd: Ezt a daemont akkor használjuk, amikor a Samba szerver egy Windows NT4 vagy ADS domain (Active Directory Services) része. 6.12.1.
A működő szerver vizsgálata
A működő Samba szervert tesztelhetjük egyrészt Windows kliensekkel, másrészt Linux kliens gépen, vagy magán a szerveren az smbclient nevű programmal. Ilyenkor az alapértelmezett megosztásokat láthatjuk. (Köztük megtaláljuk az $IPC megosztást.) Az smbclient parancs a samba csomag része. A Linux gépek egyik SMB klienseként szolgál, amellyel elérhetjük a megosztott könyvtárakat. Az egyik gyakran használt paraméterezése: smbclient -N -L <szervernév> A program ilyenkor bejelentkezik a szerverre az alapértelmezett guest felhasználóként, és kilistázza a felhasználó által elérhető szolgáltatásokat. Lekérdezhetjük más felhasználó által használható megosztásokat is, ebben az esetben el kell hagynunk az -N opciót (nincs jelszó) és az -U paraméter után meg kell adnunk a felhasználói nevet. Az smbclient parancs egy másik gyakran elforduló formája: smbclient //szervernév/felhasználó -U felhasználó Ezzel a paraméterezéssel egy FTP szerű fájltranszfer kapcsolatot hozhatunk létre. Miután a kapcsolat létre jött a get és put parancsokkal letölthetünk, illetve elküldhetünk állományokat, illetve a dir paranccsal kilistázhatjuk a könyvtár tartalmát. Bejelentkezéskor a felhasználó a home könyvtárát láthatja, amely megosztás alapértelmezett a samba csomagban. Az első paranccsal a szerver működéséről bizonyosodhatunk meg. A második típusú paranccsal a megosztásokat ellenőrizhetjük le. 6.12.2.
A konfiguráció
A Samba szerver konfigurációs állományai az /etc/samba könyvtárban találhatók meg. • Az smb.conf fájl tartalmazza a szerver beállításait. Megosztásokat is ebben az állományban hozhatunk létre. • Az lmhosts a hosts fájlhoz hasonlít, azonban a NetBIOS név-IP cím leképezéseket tartalmazza. • Az smbusers az NT felhasználók Linux felhasználó listába való leképezését tartalmazza. Egy-egy sort tartalmaz minden Linux felhasználóhoz, és az NT felhasználónevek listáját, amelyeket az adott felhasználóra képez le a rendszer. • Az smbpasswd állomány a Samba felhasználói jelszókat tartalmazza kódolt formában. (Az eredeti passwd állományt, amelyben a Linux rendszer a jelszavakat tárolja csak abban az esetben használhatjuk, ha a jelszavakat nyíltan továbbítjuk a hálózaton.) 153
A rendszer másik fontos könyvtára a /var/log/samba könyvtár, ahol a log állományok találhatók. A Samba nem használja a korábban megismert syslog szolgáltatást, a log állományok kezeléséről maga gondoskodik.28 6.12.2.1.
Alap szerver beállítások
Ahogy az előbb a konfigurációs állományoknál láttuk, a fő konfigurációs opciók az /etc/samba/smb.conf állományban találhatóak. Első lépésként beállíthatjuk a szerver workgroup paraméterét, a leíró szövegét, és esetleg a NetBIOS nevét is. netbios name = név workgroup = CSOPORT server string = Ez egy samba szerver Következő lépésként lekorlátozhatjuk a hozzáférést a szerverhez egyes IP cím tartományokra a cím részleges megadásával. host allow = 192.168.
6.12.2.2.
Autentikációs beállítások
Az SMB/CIFS világban alapvetően kétféle autentikációs metódust különböztetünk meg. A régi Windows 9x metódust (share), amely a megosztásokra ad meg jelszavakat, illetve a felhasználók azonosításán alapuló metódust. Utóbbi esetben négy különböző megoldás közül is választhatunk az információk ellenőrzésénél. user: A legegyszerűbb változat. A Samba szerver fogadja a felhasználónév-jelszó párost, és az adatbázisa alapján leellenőrzi. domain: Ebben az esetben a szerver egy NT domain tagja, rendelkezik egy machine accounttal a domain controller ben. Minden autentikációs információt a domain controller felé továbbít. ADS: A Samba szerver csatlakozhat egy Active Directory domainhez is. Amennyiben ezt nem NTkompatibilis módban használjuk, akkor választhatjuk ezt az opciót. Ehhez azonban még szükséges a Kerberos autentikáció bekonfigurálása is. server: Ez egy elavult választási lehetőség abból az időből, amikor még a Samba nem volt képes a domain authentikációra. Lényege, hogy a szerver átveszi a felhasználónevet és jelszót a klienstől, majd ezzel megpróbál a domain controller re belépni. Amennyiben sikerül, akkor elfogadja az autentikációt. Mi az egyszerűség kedvéért a példában user autentikációs metódust választunk, titkosított jelszókezeléssel. Az autentikációs metódust a következő sorral állíthatjuk be:
28 Fordításkor
bekonfigurálhatjuk a Sambat úgy is, hogy használja a syslog mechanizmust.
154
security = user Azonban ahhoz, hogy a jelszavak a hálózaton biztonságban legyenek, szükséges hogy titkosítva továbbítsuk. encrypt passwords = yes Ez felvet egy problémát. A Microsoft Windows rendszeren és a Unix, Linux rendszerek jelszó kódolási algoritmusa különbözik egymástól. Ugyanakkor a kódolás egyirányú, ezért a titkos jelszóból az eredeti jelszó nem nyerhető vissza, ebből következően a Linux jelszavakat nem tudjuk felhasználni a Samba autentikációhóz. Vagyis kódolt jelszavak esetén a Samba jelszavakat külön meg kell adnunk és tárolnunk. Az állomány, amely a jelszókat tárolja a következő sorral adható meg: smb passwd file = /etc/samba/smbpasswd A jelszót az smbpasswd programmal tudjuk beállítani. De ehhez először fel kell vennünk a Samba felhasználókat. Így az első alkalommal az -a paraméterrel kell meghívnunk: smbpasswd -a Azonban, hogy a Samba és a Linux jelszavunk egyforma legyen megadhatjuk, hogy az smbpasswd program használata esetén automatikusan a passwd paranccsal a rendszer jelszavunkat is utána állítsa a Samba jelszónak. Ezt az alábbi parancsokkal kapcsolhatjuk be: unix password sync = Yes passwd program = /usr/bin/passwd %u passwd chat = *New*UNIX*password* %n\n *ReType*new*UNIX*password* %n\n *passwd:*all*authentication*tokens*updated*successfully*
Megjegyzés Arra is van lehetőség, hogy a passwd parancs használatakor a Samba jelszót is módosítsuk. Ezt a PAM mechanizmus és a pam_smbpass.so modul segítségével lehet elérni. Ha a Samba felhasználók neve nem egyezik meg a Linux accountokkal, akkor leképezést is megadhatunk a kettő között. Ezt a korábban említett smbusers állomány tartalmazza, és az alábbi sorral adhatjuk meg: username map = /etc/samba/smbusers
6.12.2.3.
Felhasználók importálása az smbpasswd állományba
Bár a jelszavakat nem importálhatjuk be a Samba felhasználói adatbázisába, a felhasználók neveit azonban igen. Az smbpasswd állomány legenerálását a következőképpen végezhetjük el:
155
cat /etc/passwd | mksmbpasswd.sh > /etc/samba/smbpasswd A létrehozott állomány kényes információkat tartalmaz, ezért módosítsuk úgy a jogait, hogy csak a rendszergazda férhessen hozzá. A felhasználók listájának legenerálása után az smbpasswd programmal beállíthatjuk az jelszavakat is egyenként. 6.12.2.4.
Megosztások
A főbb paraméterek beállítása után már létrehozhatunk megosztásokat is. Ha egy publikus, de csak olvasható megosztást szeretnénk létrehozni, akkor annak alakja a következő lehet. [public] comment = Publikus path = /home/samba public = yes writable = no printable = no Itt a „[ ]” jelek közötti szöveg adja meg a megosztás nevét, a comment a megosztás leírását. A path paraméterrel állíthatjuk be a megosztott könyvtárat. A public jellemző beállításával mindenki számára elérhetővé tesszük. Viszont mivel a writable paramétert „no”-ra állítottuk, ezért csak olvasható. Ha azt szeretnénk, hogy a felhasználók egy csoportja írhassa, akkor az alábbiak szerint módosítsuk. [public] comment = Publikus path = /home/samba public = yes writable = yes printable = no write list = felhasználó1 felhasználó2 ... A felhasználók felsorolása helyett megadhatunk csoportot is. Ilyenkor a csoport neve elé be kell írnunk a „@” jelet. Azonban ha csak egyes felhasználók számára szeretnénk valami teljes eléréssel megosztani, akkor a következő konfigurációt használhatjuk. [joe] comment = Joe könyvtára path = /home/joe valid users = joe public = no writable = yes printable = no
156
Ha a szerver minden felhasználójának szeretnénk megosztani a saját home könyvtárát, akkor szerencsére nincs szükségünk arra, hogy mindegyikhez írjunk egy ilyen konfigurációs részt. Ehhez a Samba támogat egy speciális megosztást, amelynek a neve homes. [homes] comment = Home Directories browseable = no writable = yes create mode = 0664 directory mode = 0775 Ha nem hozunk létre megosztást a felhasználó nevével, de egy klienssel mégis csatlakozni szeretnénk egy ilyen megosztáshoz, akkor a Samba a homes szekció beállításai alapján automatikusan hoz létre nekünk egy ilyen megosztást. A browseable paramétert „no”-ra állítva a megosztás nem látszódik a böngészőben. Két további paramétert is láthatunk illusztráció képpen. A create mode azt adja meg, hogy az új állományok milyen jogokkal jöjjenek létre. A directory mode paraméter hatása pedig ugyanez a könyvtárakra nézve.
Feladat Osszuk meg publikusan az /export könyvtárat!
6.12.2.5.
Konfiguráció ellenőrzése
Az elkészített konfigurációs állományt a testparm programmal ellenőriztethetjük. testparm /etc/samba/smb.conf A tesztelés után érdemes csak az új konfigurációval elindítanunk a szervert. 6.12.3.
Grafikus konfigurálás
A Samba szerver konfigurálásához és a megosztások létrehozásához is létezik grafikus segédeszköz a Red Hat disztribúcióban. Ennek a programnak a neve Samba Server Configuration. A system-config-samba RPM csomagban található.
157
21. ábra. Samba Server Configuration főablak
22. ábra. Szerver beállítások és megosztások
158
7.
Webszerver, PHP, Drupal, AWStats
7.1.
Webszerver
Linux alatt a legelterjedtebb webszerver az Apache. Az Apache egy robusztus, széles körű funkcionalitással, és bővíthetőséggel rendelkező webszerver. A Fedora és Ubuntu disztribúciók jelenleg a 2.2-es verziót tartalmazzák, továbbá számos bővítő modult. Apache Microsoft nginx Google lighttpd qq.com Sun egyéb
70%
60%
Piaci részesedés
50%
40%
30%
20%
10%
1.
20
12
.0
6.
20
11
.0
2.
20
10
.1
5. .0
20
10
1. 09
20
20
.1
4. 09
.0
9. .0 08
20
20
08
.0
3.
0%
23. ábra. Webszerver szoftverek piaci részesedése29 Az
Apache
szerver
fő
konfigurációs
állománya
Fedora
disztribúció
esetén
az
/etc/httpd/conf/httpd.conf, míg Ubuntu esetén az /etc/apache2/apache2.conf fájl. Ennek további, modulokhoz tartozó kiegészítő részei az /etc/httpd/conf.d, illetve az /etc/apache2/mods-enabled könyvtárban találhatóak. A webszervert Fedora disztribúció esetén a httpd, míg Ubuntu esetén az apache2 szolgáltatás elindításával indíthatjuk. A publikált weboldalak könyvtára a httpd.conf, illetve az apache2.conf állományban beállított DocumentRoot. Ez a Fedora disztribúció esetén a /var/www/html, míg Ubuntu esetén a /var/www könyvtár.
29 Forrás:
http://news.netcraft.com/archives/category/web-server-survey.
159
Megjegyzés Figyeljünk arra, hogy az állományok a webszerver által olvashatóak legyenek! A webszerver uid és gid beállításai a httpd.conf, illetve az apache2.conf állományban találhatóak (User és Group).
Feladat 1. Indítsuk el a webszervert, helyezzünk el egy html oldalt a dokumentum könyvtárban, majd ellenőrizzük a rendszer működését egy böngészővel! 2. Fussuk át a httpd.conf, illetve az apache2.conf állomány főbb beállításait!
7.1.1.
Globális beállítások
A globális szekció (a httpd.conf, illetve az apache2.conf állomány első része) a szerver általános beállításait tartalmazza. 7.1.1.1.
Port és interfész használat
A Listen opcióval megadhatjuk, hogy a webszerver melyik TCP portot használja a kapcsolatok fogadásához. Listen 80 De interfészt is specifikálhatunk, ha nem mindegyiken akarjuk elérhetővé tenni a szervert. Listen 192.168.0.1:80
7.1.1.2.
Server-Pool beállítások
Amikor az Apache szerver fogadja a kéréseket, akkor ezeket szét kell osztania kiszolgáló szálak, vagy processzek között. Ezzel érjük el, hogy párhuzamosan több klienst is képes legyen kiszolgálni. Ezeket a szálakat server-pool -nak nevezzük. Az Apache 2.2-es verziója több megoldást is tartalmaz a serverpool -ok létrehozására és kezelésére. Linux alatt jelenleg a worker, a kísérleti event és a prefork érhető el. A régi – Apache 1.3-ban megtalálható – többprocesszes megoldást a prefork metódus képviseli. Ha a stabilitást és a kompatibilitást tartjuk szem előtt, akkor ezt célszerű választanunk. Paraméterei: StartServers: Az induláskor létrehozandó szerver processzek száma. MinSpareServers: A várakozó processzek minimális száma. MaxSpareServers: A várakozó processzek maximális száma. MaxClients: Az indítható szerver processzek maximális száma. 160
Szülő folyamat
Szülő folyamat
Gyermek Gyermek Gyermek folyamat [1] folyamat [...] folyamat [n]
Gyermek Gyermek Gyermek folyamat [1] folyamat [...] folyamat [k] Szál [1]
Szál [1]
Szál [1]
Szál [2] Szál [...]
Szál [2] Szál [...]
Szál [2] Szál [...]
Szál [l]
Szál [m]
Szál [n]
24. ábra. Az Apache prefork és worker metódusai MaxRequestPerChild: A szerver processzek által kiszolgálható kérések maximális száma. Ezután a processzt megszünteti a szerver. Így elkerülhető egy esetleges memóriaszivárgásból eredő probléma. Amennyiben a webszerverünknél a teljesítmény és a skálázhatóság a fő szempont, akkor célszerű egy szálakat használó megoldást választanunk. Ez a worker metódus. Paraméterei: StartServers: Az induláskor létrehozandó szerver processzek száma. MaxClients: A párhuzamos kliens kapcsolatok maximális száma. MinSpareThreads: A várakozó kiszolgáló szálak minimális száma. MaxSpareThreads: A várakozó kiszolgáló szálak maximális száma. ThreadsPerChild: A kiszolgáló szálak száma egy szerver processzen belül. MaxRequestsPerChild: A szerver processzek által kiszolgálható kérések maximális száma. 7.1.1.3.
Dynamic Shared Object (DSO)
Lehetőségünk van arra, hogy a szerverbe további modulokat töltsünk be induláskor, ezzel bővítve a képességeit. A modulokat a LoadModule kulcsszóval tölthetjük be. Azonban egyes modulok további konfigurációs beállításokat is igényelnek. Ebben az esetben a betöltést és a konfigurációt egy külön állományban adjuk meg az /etc/httpd/conf.d, illetve az /etc/apache2/mods-enabled könyvtárban. Ezeket az Include conf.d/*.conf, illetve az Include mods-enabled/*.load és Include mods-enabled/*.conf sorokkal töltjük be. 7.1.2.
A fő szerver szekció
A fő szerver konfigurációs szekcióban azokat a paramétereket adjuk meg, amelyekkel a fő szervert üzemeltetni szeretnénk. A „fő szerver” kifejezés azt a webszervert takarja, amelyet nem a később tárgyalt 161
virtuális szerver szekció kezel. Azonban ezek a beállítások a virtuális szerverek alapértelmezett értékeiként is tekinthetőek. 7.1.2.1.
Jogosultság beállítások
Megadhatjuk, hogy a webszerver melyik felhasználó és csoport nevében, illetve jogaival fusson. User apache Group apache
7.1.2.2.
Adminisztratív cím
A ServerAdmin paraméterrel megadhatjuk az adminisztrátor email címét akihez probléma esetén a felhasználók fordulhatnak. 7.1.2.3.
A szerver azonosítása
A szerver a ServerName paraméterben megadott névvel és porttal azonosítja magát a kommunikáció során. 7.1.2.4.
A dokumentum könyvtár
A fő dokumentum könyvtárat a következő sor állítja be. DocumentRoot "/var/www/html" vagy DocumentRoot "/var/www" Az URL-ben szereplő elérési út alapértelmezett esetben ettől a könyvtártól értendő. 7.1.2.5.
Könyvtár beállítások
A és direktívák által közrefogott részben egy könyvtár paramétereit állíthatjuk be. Engedélyezhetünk opciókat az Options kulcsszóval. A következő listából választhatunk: Indexes, Includes, FollowSymLinks, SymLinksIfOwnerMatch, ExecCGI, MultiViews. De használható a None és az All direktíva is. Az AllowOverride kulcsszóval definiálhatjuk, hogy milyen beállításokat definiálhatunk felül az alkönyvtárakba elhelyezett .htaccess állománnyal. A választható kulcsszavak: Options, FileInfo, AuthConfig, Limit, továbbá a None és az All. Az Order kulcsszóval megadhatjuk, hogy a szerver először az Allow vagy a Deny beállításokat értékelje ki. Az Allow kulcsszóval megadhatjuk, mely kliensek férhetnek hozzá a könyvtárhoz. A Deny segítségével pedig letilthatjuk.
162
7.1.2.6.
Felhasználói könyvtárak
Ahhoz, hogy a felhasználók is elhelyezhessenek saját weboldalakat a szerveren, engedélyeznünk kell a következő opciót. UserDir public_html Ezáltal a felhasználó home könyvtárában létrehozott public_html könyvtár tartalmát publikálja a szerver /~felhasználónév/ cím alatt. Természetesen a könyvtárra és az állományokra olyan jogosultságokat kell megadnunk, hogy a szerver szolgáltatás hozzáférhessen. Azonban a könyvtárban elérhető szolgáltatások korlátozására célszerű a lentebb látható, a konfigurációs állományokban rendre megtalálható rész kikommentezése is. AllowOverride FileInfo AuthConfig Limit Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec Order allow,deny Allow from all Order deny,allow Deny from all
7.1.2.7.
Az alapértelmezett index állomány
Amikor a felhasználó az URL-ben nem ad meg oldalt, csak egy könyvtárat (a címet „/” jellel zárja), akkor a szerver az alapértelmezett index állományt adja vissza, ha az létezik. Azt, hogy mi számítson az alapértelmezett index állománynak, a DirectoryIndex kulcsszóval adhatjuk meg. DirectoryIndex index.html index.htm index.php
7.1.2.8.
A .htaccess állomány
Korábban már szó volt a .htaccess állományról, amellyel felüldefiniálhatjuk egy könyvtár beállításait, megadhatjuk a hozzáférési követelményeket. Azonban, hogy ezt az állományt pontosan hogyan is nevezzük, az AccessFileName kulcsszóval adhatjuk meg. AccessFileName .htaccess
163
7.1.2.9.
MIME típus beállítások
A MIME (Multipurpose Internet Mail Extensions) típus listát és összerendelést tartalmazó állományt a TypesConfig kulcsszóval állíthatjuk be. TypesConfig /etc/mime.types
7.1.2.9.1.
Az alapértelmezett MIME típus
A DefaultType kulcsszóval megadhatjuk az alapértelmezett MIME típust, amit a szerver akkor használ, amikor azt nem tudja meghatározni. DefaultType text/plain
7.1.2.10.
Logolás
Az ErrorLog kulcsszóval megadhatjuk a szervernek, hogy melyik állományba logolja a hibákat. A LogLevel a logolás részletességét hangolja, míg a LogFormat a bejegyzések formátumát. A kommunikációs bejegyzések állományát és formátumát a CustomLog kulcsszóval definiálhatjuk. 7.1.2.11.
A dokumentum-könyvtáron kívüli könyvtárak elérése
Az Alias kulcsszó lehetővé teszi, hogy a dokumentum-könyvtárstruktúrán kívül eső más könyvtárakat is elérhetővé tegyünk azáltal, hogy leképezzük erre a területre. A ScriptAlias olyan könyvtárakat tesz elérhetővé, amelyben futtatható CGI (Common Gateway Interface) állományok vannak. Az ilyen könyvtárakat többnyire nem is a dokumentum-könyvtárstruktúrában helyezzük el biztonsági okokból, hogy a kód ne legyen elérhető. 7.1.2.12.
Átirányítás
A Redirect kulcsszót akkor használjuk, amikor egyes oldalak más címre kerültek. Ilyenkor a címben szereplő régi könyvtárakat új URL-re cseréli. 7.1.2.13.
A szerver által generált index lista
Ha a könyvtárban nem szerepel index állomány, és engedélyeztük a könyvtárban található állományok listájának lekérdezését, akkor az IndexOptions kulcsszóval megadhatjuk ennek formátumát. Az AddIcon* direktívákkal megadhatjuk az egyes állománytípusokhoz használt ikonokat, illetve a DefaultIcon direktívával az alapértelmezett ikont. Az AddDescription kulcsszóval leírásokat is megadhatunk egyes állomány-kiterjesztésekhez. A ReadmeName és HeaderName kulcsszóval megadott állományneveket a szerver keresi a könyvtárban, és ha rendelkezésre állnak, akkor hozzáfűzi a tartalmukat a generált listához. Ha egyes állományokat szeretnénk kihagyni a listából, akkor az IndexIgnore kulcsszóval adhatjuk meg őket mintákkal.
164
7.1.2.14.
Nyelvi beállítások
A DefaultLanguage kulcsszóval beállíthatjuk a dokumentumok alapértelmezett nyelvét. Az AddLanguage pedig lehetővé teszi, hogy különböző kiterjesztésekkel több nyelven is elérhetővé tegyük oldalainkat. Amennyiben a kliens böngészők nem rendelkeznek nyelvpreferencia listával, akkor a szerver a LanguagePriority kulcsszóval megadott listát fogja követni. Hasonlóan a nyelvekhez alapértelmezett karakterkészletet is megadhatunk az AddDefaultCharset direktívával, illetve kiterjesztés összerendelést is beállíthatunk az AddCharset kulcsszóval. 7.1.2.15.
További kiterjesztés leképezések
Az AddType kulcsszóval felüldefiniálhatjuk egyes kiterjesztésekre az állomány MIME típusát. Az AddEncoding hasonlóan, egyes tömörített állományok típusát adja meg, hogy a kliens automatikusan kitömöríthesse. Az AddHandler segítségével egyes kiterjesztésekre beállíthatjuk a lekezeléseket. Ezek lehetnek beépítettek, vagy az Action direktívával definiálhatunk sajátokat is. 7.1.2.16.
Hibajelzések
Az ErrorDocument direktívával felüldefiniálhatjuk az alapértelmezett hibajelzéseket. Ez lehet egy egyszerű szöveg, egy lokális oldal, vagy egy akár egy URL is. 7.1.2.17.
Egyéni browser beállítások
A BrowserMatch direktíva segítségével alkalmazkodhatunk az egyes böngészők jellemzőihez, hibáihoz. 7.1.2.18.
Apache mint proxy szerver
Az Apache képes proxy szerverként is funkcionálni. Ehhez a mod_proxy modul bejegyzései előtt lévő komment jeleket ki kell szednünk, és a ProxyRequests kulcsszó után az On értéket megadnunk. A Proxy tag-ek közt találhatók a hozzáférés korlátozásának beállításai. A mod_disk_cache modul segítségével cache funkcióval is felruházhatjuk szerverünket. 7.1.3.
Virtuális szerverek
Ha több hosztnévhez tartozó webszervert is egy gépen szeretnénk megvalósítani, akkor a virtuális szerverek kialakításához kell folyamodnunk. A leggyakoribb a név alapú leképezés használata. Ennek használathoz be kell kapcsolnunk a NameVirtualHost opciót. NameVirtualHost *:80 Majd beállítjuk az egyes virtuális konténereket. ServerName server1.example.org ServerAlias server1b.example.org DocumentRoot /var/www/html/ 165
ServerName server2.example.org DocumentRoot /var/www2/html
7.1.4.
Védett könyvtár létrehozása
Ha a webszerveren valamelyik könyvtárat le akarjuk védeni, akkor erre is van lehetőségünk. Ezt két fajta módon tehetjük. Egyik megoldás, hogy létrehozunk az adott könyvtárban egy .htaccess nevű állományt az alábbi beállításokkal. AuthType Basic AuthName "Restricted Directory" AuthUserFile /etc/httpd/conf/passwd Require user felhasznalo Azonban figyeljünk arra, hogy az adott könyvtárra engedélyeznünk kell az autentikációs beállítások módosítását. Ezt a következő opcióval tehetjük meg: AllowOverride AuthConfig A másik megoldás, hogy létrehozunk egy konfigurációs állományt az /etc/httpd/conf.d könyvtárban, az alábbi tartalommal. AuthType Basic AuthName "Restricted Directory" AuthUserFile /etc/httpd/conf/passwd Require user felhasznalo AllowOverride None Mindkét megoldáshoz szükséges, hogy a htpasswd programmal létrehozzuk a felhasználót, és jelszót állítsunk be neki.
Feladat Hozzunk létre védett könyvtárat! Azonban ennek a megoldásnak hibája, hogy a jelszó nyíltan, kódolás nélkül közlekedik a hálózaton. Viszont az Apache szerverhez rendelkezésre áll egy SSL (Secure Sockets Layer) modul, amellyel titkosíthatjuk a kommunikációt.
166
7.1.5.
SSL
Fedora disztribúció esetén a mod_ssl RPM csomag tartalmazza ezt a modult. A modul konfigurációs állománya az /etc/httpd/conf.d/ssl.conf. Ubuntu disztribúció esetén az SSL modult az apache2.2-common csomag tartalmazza, amely az Apache telepítése során a függőségek miatt automatikusan települ. A modul konfigurációs állománya az /etc/apache2/mods-available/ssl.conf. Ezzel az Apache webszerver támogatja a https kommunikációt is. Természetesen itt is előkerül a tanúsítványok problematikája. A csomag alapértelmezett selfsigned tanúsítványokkal érkezik, amelyek lehetővé teszik a tesztelést. A későbbiekben azonban ezt célszerű szabályos tanúsítványokra cserélni. A bejelentkezéskor megkövetelhetjük a https protokoll használatát. Ehhez az alábbi sorral kell kiegészítenünk a fenti beállításokat. SSLRequireSSL
Feladat Használjuk a védett könyvtárunkat https protokollon keresztül!
7.1.6.
Grafikus konfigurációs eszköz
Az Apache konfigurálásához is rendelkezésünkre áll grafikus segédeszköz. A Fedora eszközének neve Apache Configuration. Ez a program a system-config-httpd RPM csomagban található.
25. ábra. Apache Configuration
Megjegyzés Ha ezt a programot használjuk a szerver konfigurálására, akkor ne módosítsuk kézzel a httpd.conf állományt, mert felülírja a módosításainkat.
167
7.2.
A PHP beállítása
A PHP az egyik legelterjedtebb szkriptnyelv webes alkalmazások fejlesztéséhez. Azonban nem csak új alkalmazás készítésekor hasznos, hanem számos elterjedt nyílt forráskódú szoftver futtatható általa. Fedora disztribúciókban a PHP-t a php RPM csomag, míg Ubuntu esetén a php5 Debian csomag tartalmazza. A telepítés után a következőket figyelhetjük meg: • Fedora esetén az /etc/httpd/conf.d könyvtárban elhelyezésre került a php.conf állomány, míg Ubuntu esetén az /etc/apache2/mods-available könyvtárban került elhelyezésre a php5.conf állomány, amely betölti a PHP használatához szükséges modult. • Fedora esetén az /etc/httpd/modules könyvtárba, míg Ubuntu esetén az /usr/lib/apache2/modules könyvtárba került be a szükséges modul libphp5.so néven. A telepítés sikerességét úgy tudjuk igazolni, hogy létrehozunk a DocumentRoot direktívával megadott könyvtáron belül egy „test.php” állományt a következő tartalommal: Amennyiben ezt a PHP szkriptet lefuttatjuk egy böngészőben, a 26. ábrához hasonló kimenetet látunk majd.
26. ábra. A phpinfo kimenete
168
Az így született oldalon tehát láthatjuk a webszerver illetve a PHP jelenlegi konfigurációs beállításait. Ha a fenti oldal helyett a test.php állomány forrása jelenik meg, úgy tudjuk, hogy a PHP konfigurációja nem sikerült és a webszerver konfigurációs állományaiban kell keresnünk a hibát. 7.2.1.
A mod_rewrite modul használata PHP esetén
A mod_rewrite modul számos módon használható, célja, hogy a kliens felől érkező kérések URL-jét bizonyos szabályok szerint átalakítsa. Ennek egyik gyakori alkalmazása az ún. „szép URL”-ek használata. Erre látunk példát a következőkben. Készítsük el a következő PHP szkriptet! Ha a fenti szkriptet lefuttatjuk a böngészőben http:// localhost/ termek.php? termekid=23 paraméterezéssel, akkor a szkript az „A termék azonosítója 23” szöveget fogja kiírni. Természetesen egy igazi alkalmazásban egy termékről sokkal több információt is közölhetünk, mint az azonosítója és az adatok megjelenítéséhez valószínűleg adatbázisra is szükségünk lesz, azonban a jelenlegi példa kedvéért csupán ennyi funkcionalitást tételezzünk fel. A mod_rewrite modult jelen esetben arra fogjuk használni, hogy a fenti szkripthez „szép URL”-t készítsünk, azaz a felhasználónak elég legyen annyit beírni a böngészőbe, hogy http:// localhost/ termek/ 23 és ne kelljen foglalkozni azzal, hogy ezt PHP szkript állítja elő, illetve milyen paraméternévvel kell átadni a termékazonosítót. A modul által tehát célunk, hogy a fenti URL-t visszaalakítsuk abba a formába, aminek segítségével a PHP szkript futtatása már lehetséges. A következő bejegyzéseket helyezzük el a fő konfigurációs szekcióban, vagy az adott virtuális host konfigurációs fájljában. RewriteEngine On RewriteRule ^/termek/([0-9]+)$ /termek.php?termekid=$1 A webszerver újraindulását követően az újraírási szabály lehetővé teszi a termékek a korábban leírt címeken való elérését. 7.2.2.
A phpMyAdmin telepítése
A PHP-t a legtöbb esetben valamilyen adatbázis-kezelővel kiegészítve használják, mivel a szkript innen olvassa ki és ide írja vissza a működéséhez szükséges adatokat. A labor során a MySQL adatbázis-kezelő szoftvert fogjuk telepíteni. Fedora esetén a mysql, mysql-server és php-mysql csomagokat, míg Ubuntu esetén a mysql-server és php5-mysql csomagokat kell telepíteni. Fedora disztribúció esetén az első két csomag az adatbázisszervert telepíti, a harmadik pedig az adatbázis PHP alóli elérését lehetővé tevő modult, míg Ubuntun az első csomag tartalmazza az adatbázisszerver egészét, és a második csomag tartalmazza a az adatbázis PHP alóli elérését lehetővé tevő modult.
169
Ezután állítsuk be a rendszergazdai jelszót az adatbázisszerveren. mysqladmin -u root password 'jelszo' Ezután következhet a phpMyAdmin telepítése, ami Fedorán a phpmyadmin csomagban, Ubuntun pedig a phpmyadmin csomagban található. A phpMyAdmin lehetővé teszi, hogy kényelmes, webes felületen adminisztráljuk a MySQL adatbázisunkat. Azonban ahhoz, hogy használhassuk ezt a webes felületet, az /usr/share/phpMyAdmin könyvtárba telepített szoftvert be kell hozni valamelyik virtuális hoszt, vagy a fő szerver névterébe. Ezt a szokott, módon, azaz szimbolikus link vagy Alias segítségével lehet megtenni (pl. Alias /phpmyadmin /usr/share/phpMyAdmin).
27. ábra. A phpMyAdmin Érdemes kipróbálni a 27. ábrán is látható alapfunkciókat: • Adatbázis létrehozása; • Tábla létrehozása; • Új sor beszúrása; • Sor módosítása; • Tábla tartalmának megtekintése.
170
7.3.
A Drupal tartalomkezelő rendszer telepítése
Egy tartalomkezelő rendszer segítségével könnyen hozhatunk létre olyan weboldalakat, melyek nagyrészt statikus, információs oldalakból állnak. Az oldalak frissítésére kényelmes felület áll rendelkezésre, valamint lehetőség van kommentelésre, fórumok működtetésére, blogolásra stb. Mindezen kívánalmaknak (és a bővítő modulok, pluginek segítségével ennél jóval többnek) eleget tesz a Drupal tartalomkezelő rendszer. Töltsük le a Drupal legújabb verzióját a http:// drupal.org/ weboldalról és csomagoljuk ki a DocumentRoot-ba. (Az archívum tartalmaz egy drupal- főkönyvtárat, annak tartalmát tegyük a DocumentRoot-ba, tehát az index.php állomány a legfelsőbb szinten helyezkedjen el!) A kicsomagolás után kövessük az INSTALL.txt állományban leírtakat. Jelenleg ez a következő parancsok futtatását jelenti: cp sites/default/default.settings.php sites/default/settings.php chmod o+w sites/default/settings.php chmod o+w sites/default Még mielőtt megkezdődne a tényleges telepítés, létre kell hoznunk egy adatbázist, ahova a rendszer létrehozhatja a szükséges táblákat. (Amennyiben az előző fejezetben szerint telepítettük a phpMyAdmint, célszerű azt használni erre a feladatra.) Mindezek után a böngészővel nyissuk meg az index.php állományt, amely megkezdi az telepítést. Először meg kell adnunk az adatbázis nevét, az adatbázis felhasználói nevét és jelszavát (ezek ugyanazok, amiket megadtunk a mysqladmin parancsnak). Amennyiben minden sikeres, már csak meg kell adnunk az oldal nevét, az adminisztrátor email címét stb. A telepítés végeztével a rendszer beléptet minket és kezdődhet az oldal adminisztrálása, melynek részleteit itt terjedelmi okokból nem tudjuk bemutatni. (Azonban könnyen kipróbálható, például hozzunk lére új tartalmat – a rendszer erre a „Page” kifejezést használja –, majd az Administer → Site building → Menus segítségével próbáljuk meg a tartalmat elérhetővé tenni egy menüpont által.)
7.4.
Az AWStats statisztikai programcsomag telepítése
Az AWStats programcsomag egy statikus logfájl analizáló alkalmazás, amely képes a logokban található kéréseket különböző szempontok szerint aggregálni: • A kérések időbeli eloszlása (napon, hónapon belül); • A használt böngészők típusa; • A kérések hivatkozó oldala (angolul referer); • Java, Flash, JavaScript kompatibilis látogatók aránya; • Ha az oldalt keresőkből találták meg, akkor milyen kulcsszavakra.
171
Mivel legtöbbször egy szerver több oldalt is kiszolgál, ezért az alábbiakban az AWStats egy olyan beállítását mutatjuk be, mely virtuális hosztok esetén használatos. Az első lépés az AWStats telepítése. (Az AWStats Fedorán az awstats RPM csomagban, míg Ubuntun az awstats Debian csomagban található.) Ezután következik a virtuális hosztok konfigurálása: ServerAdmin [email protected] DocumentRoot /var/www/html/domain1.com ServerName domain1.com ErrorLog logs/domain1.com-error_log CustomLog logs/domain1.com-access_log combined Alias /awstats/icon "/var/www/html/domain1.com/awstats/wwwroot/icon" ScriptAlias /awstats "/var/www/html/domain1.com/awstats/wwwroot/cgi-bin" Mint látható, virtuális hosztok esetén célszerű úgy konfigurálni a szervert, hogy minden hoszt külön log állományokkal rendelkezzen, így könnyebb és átláthatóbb az adminisztráció.
Megjegyzés Ez nem minden esetben célravezető, pl. egy hoszting cég esetén, ahol egy szerver több száz, vagy ezer oldalt szolgál ki, problémák lehetnek abból, hogy ennyi logfájlt kell nyitva tartania a szervernek. Szintén fontos megfigyelni, hogy a CustomLog bejegyzés, mely az access logot hivatott biztosítani, combined típusú, ennek azért lesz jelentősége, mert az AWStats alapbeállításai szerint ilyen formátumban várja a logokat. Látható, hogy az AWStats programcsomagot a virtuális hoszt URL névterébe két alias bejegyzéssel tudjuk behozni. Az első bejegyzés elérhetővé teszi az ikonokat, a második pedig azt a Perl szkriptet, mely a statisztikát tartalmazó weboldalt generálja. (A domain1.com DocumentRoot-jába úgy kerül az awstats könyvtár, hogy készítünk egy szimbolikus linket a DocumentRoot-ból az AWStats telepítési könyvtárára, mely az /usr/share/awstats). Ezek után következhet az AWStats konfigurálása. Ennek kezdőlépése, hogy az AWStats telepítési könyvtárán belül megkeressük a tools könyvtárat és azon belül az awstats-configure.pl nevű szkriptet. A szkriptet futtatva először rákérdez, hogy szeretnénk-e, hogy konfigurálja a webszerver httpd.conf állományát. Válasszuk a „no” opciót, mivel a virtuális hosztokat már a fentiekben konfiguráltuk, így erre nincs már szükség. Ezután a szkript rákérdez a virtuális hoszt nevére (ez a fenti virtuális host esetén domain1.com volt) és legenerálja az /etc/awstats/awstats.domain1.com.conf nevű konfigurációs állományt.
172
28. ábra. Az AWStats által készített statisztika Az így elkészített állomány fogja befolyásolni az AWStats működését az adott virtuális hosztra vonatkozóan. Nyissuk meg, mivel néhány dolgot meg kell változtatni benne. Az első ilyen a LogFile nevű direktíva, amelyet állítsunk át arra, amelyet a virtuális hoszt konfigurációjában megadtunk (CustomLog bejegyzés). Ezután keressük meg a SkipHost nevű direktívát és töröljük a „127.0.0.1” értéket. Ezt azért kell megtennünk, mivel a rendszer tesztelése a helyi gépről (tehát a localhostról) fog történni, amelyről érkező kéréseket az AWStats programcsomag alapértelmezésként kihagy a statisztikából. Ennek az az értelme, hogy amennyiben a gép rendszergazdája technikai okokból böngészi a kiszolgált weboldalakat (pl. tesztelés), akkor ezen kérések ne befolyásolják a készített statisztikát. Egy éles rendszeren természetesen érdemes meghagyni ezt az alapértelmezést, azonban a labor során mindenki saját magának teszteli az elkészített virtuális hosztot, így szeretnénk, hogy ezen kérések bekerüljenek a statisztikába. Az így elkészített rendszer már működőképes, ki lehet próbálni. Ezt úgy célszerű megtenni, hogy először behozunk néhány oldalt a böngészőbe (például ha erre a virtuális hosztra telepítettük a Drupalt, vagy phpMyAdmint akkor azt), hogy generálódjon néhány logbejegyzés, amit az AWStats majd fel tud dolgozni. Ha ez megtörtént, a csomag cgi-bin könyvtárában adjuk ki a következő parancsot. perl awstats.pl -config=domain1.com -update Ekkor egy hasonló kimenetet kell lássunk:
Create/Update database for config "/etc/awstats/awstats.domain1.com.conf" by AWStats version 6.9 ( From data in log file "/var/log/httpd/domain1.com-access_log"...
173
Phase 1 : First bypass old records, searching new record... Searching new records from beginning of log file... Phase 2 : Now process new records (Flush history on disk after 20000 hosts)... Jumped lines in file: 0 Parsed lines in file: 23 Found 0 dropped records, Found 0 corrupted records, Found 0 old records, Found 23 new qualified records. Látható, hogy a fenti esetben 23 darab új access log bejegyzést talált az AWStats, amit hozzá is számított a statisztikához. (Amennyiben azt írta volna, hogy „Found 23 dropped records”, akkor valamilyen okból nem számolta a statisztikához a sorokat. Ekkor a -showdropped kapcsolóval tudjuk kideríteni az okát, hogy miért dobta el ezen sorokat.). Ezután ha egy böngészővel behozzuk a http:// domain1.com/ awstats/ awstats.pl oldalt, láthatóvá válik a statisztika (lásd 28. ábra).
174
8.
Levelezés (protokollok, levelezőszerverek, spamszűrés)
Az e-mail az internet egyik leglényegesebb szolgáltatása. Az internet minden felhasználója ismeri és használja, mint az egymás közötti kapcsolattartás eszközét. Az e-mail továbbítása alapvetően a következő részekre osztható: 1. A feladó a levelezőkliensével megírja a levelet, majd elküldi. A levelezőkliens ilyenkor kapcsolatba lép a levelezőszerverrel és átadja neki a levelet. 2. A levelezőszerver továbbítja a levelet a címzett levelezőszerverére. 3. A címzett levelezőszervere veszi a levelet, és elhelyezi a címzett postaládájában. 4. Általában a címzett a levelezőkliensével letölti a levelet a levelezőszerverről. Manapság ritkább az az eset, amikor magán a szerveren nézi meg egy kliens programmal a levelesláda tartalmát. Ahhoz, hogy ez a folyamat végbemehessen, több protokoll használatára van szükség. A feladó kliensétől a levelezőszerverre, majd a két levelezőszerver között a kommunikáció az SMTP (Simple Mail Transfer Protocol) használatával valósul meg. A címzett kliens programja a levelezőszerverről egy másik protokollal tölti le a leveleket. Ez lehet a POP3 (Post Office Protocol 3), vagy az IMAP (Internet Message Access Protocol).
8.1.
SMTP
Az SMTP elsődleges feladata, hogy a levelezőszerverek között továbbítsa a leveleket. Azonban ugyanezzel a protokollal kommunikál a levelezőkliens is a levél elküldésekor a szerverrel. Alapvető jellemzője, hogy a kommunikáció során csak a levél küldője tud kezdeményezni, és ezáltal a levelet csak a címzett levelesládájáig tudja továbbítani. Ezért van szükség másik protokollra a levél letöltéséhez. Fontos még megemlíteni, hogy a protokoll eredetileg nem használ semmilyen autentikációt. Ez nem meglepő, hiszen a levelezőszerverek nem feltétlenül ismerik egymást. (Azonban a kliensek levelének továbbításához beállíthatunk különböző azonosításokat.) Azonban biztonsági problémák miatt idővel autentikációs metódusokat is adtak a protokollhoz, hogy ezáltal a felhasználók azonosítás után több jogosultsággal rendelkezhessenek. (Az MTA relayezzen nekik.) A kényes információk átviteléhez javasolt az SSL titkosítás használata. A SMTP protokollt megvalósító, és ezáltal a levél továbbítását végző szervernek (MTA vagy Mail Transport Agent) gyakran a Sendmail programot használják. Azonban léteznek további implementációk is: Postfix, qmail, Exim. Ezek szolgáltatásaik számában, összetettségükben különböznek egymástól.
8.2.
POP3
A POP3 protokoll segítségével képesek a levelező kliensek letölteni a levelesláda tartalmát. Gyakran törlik is onnan a már letöltött leveleket. Azoknak a felhasználóknak hasznos, akik egy kliens gépet használnak (esetleg több szervert is), és leveleiket helyben szeretnék tárolni. Továbbá ha állandó internet-kapcsolattal nem rendelkeznek. 175
Működése során a kliens program bejelentkezik a levelezőszerverre. A szerver azonosítja a felhasználót, majd lehetővé teszi a kliensnek, hogy kilistázza és letöltse a leveleket. Az azonosítás azonban alapértelmezett esetben nem biztonságosan történik, ezért célszerű SSL titkosítást, vagy APOP, Kerberos stb. autentikáció használata.
8.3.
IMAP
Az IMAP protokoll használata esetén a felhasználó a leveleit a szerveren tárolja és kezeli. A levelező kliens megnyithatja és törölheti a leveleket. Továbbá létrehozhat könyvtárakat, amelyekben rendezve tárolhatja a korábban kapott leveleket. Használata elsősorban azoknak javasolt, akik több kliens gépet használnak, és központilag a szerveren kívánják tartani a levelezésüket. Azonban ebben az esetben állandó kapcsolat szükséges a szerverrel, hogy a leveleinket elérhessük. Az IMAP protokoll szintén azonosítást kíván a felhasználóhoz. Azonban ez a protokoll is alapértelmezett esetben biztonságilag gyenge, plain jelszavakat használ. Ezért célszerű az SSL titkosítás használata, vagy más biztonságos metódus választása.
8.4.
A levelezőszerver
8.4.1.
Sendmail
A Sendmail társaihoz képest jelenleg talán a legtöbb szolgáltatással rendelkező levelező szerver. Nagymértékben konfigurálható és jól skálázható. Azonban ugyanakkor bonyolult, a többi levelező szerverhez képest nehezen kezelhető a konfigurációs állománya. A konfigurációs állományokat az /etc/mail könyvtárban találhatjuk meg. A rendszer fő konfigurációs állománya a sendmail.cf. Azonban ha ezt az állományt szemügyre vesszük, akkor láthatjuk, hogy mérete és bonyolultsága miatt nehezen kezelhető. Erre alternatívát nyújt a sendmail.mc állomány használata. Ebben a fájlban makrók használatával és paraméterezésével összeállíthatjuk a kívánt konfigurációt, és ebből az m4 program segítségével legenerálhatjuk az előbb említett sendmail.cf állományt. A konfiguráció generálásához használható makrókat Fedorán az /usr/share/sendmail-cf, míg Ubuntun az /usr/share/sendmail/cf könyvtárban találhatjuk. (Ennek cf alkönyvtárában megtalálhatunk néhány konfigurációt is a különböző Unix változatokra.) Egy egyszerű mc állomány, amely egy teljes értékű mail szerver konfigurációjához elegendő, a következőket kell, hogy tartalmazza: VERSIONID(`az en verziom') OSTYPE(`debian')dnl DOMAIN(`debian-mta')dnl MAILER(`local')dnl MAILER(`smtp')dnl VERSIONID: Verzióinformációt helyez el az eredmény konfigurációs állományban. OSTYPE: Ez alapján kerülnek be az adott operációs rendszerre jellemző beállítások.
176
DOMAIN: Ezzel a makróval állíthatjuk be a levelező szerverünk nevét. A generic kulcsszó használata esetén a sendmail automatikusan fogja meghatározni. Probléma esetén azonban explicit meg is adhatjuk. MAILER(local): A lokális, a szerver belső levéltovábbításához szükséges. MAILER(smtp): A hálózati levéltovábbítás bekapcsolásához kell. (Ettől lesz SMTP szerver.)
Megjegyzés A MAILER deklarációknak mindig az állomány végén kell lenniük! A hivatalos sendmail csomagban az elkészített mc állományból a következő paranccsal állíthatjuk elő a cf állományt: m4 ${CFDIR}/m4/cf.m4 config.mc > config.cf A parancsban a CFDIR változó értéke tartalmazza a sendmail konfigurációs szkriptjeinek könyvtárát. Fedora esetén ez az /usr/share/sendmail-cf könyvtár, míg Ubuntun az /usr/share/sendmail/cf könyvtár. Azonban az egyszerűsítés végett Fedorán az /usr/share/sendmail-cf/cf könyvtár tartalmaz egy Makefile állományt. Ennek segítségével a könyvtárban található mc állományokat könnyebben is lefordíthatjuk. Ha egy mc állományt szeretnénk lefordítani, akkor használhatjuk a következő parancsot: make .cf Viszont Fedora és Ubuntu esetén tovább egyszerűsödik a feladatunk. Az alapértelmezett /etc/mail/sendmail.mc állományt az /etc/mail könyvtárban kiadott make paranccsal is lefordíthatjuk. Ezek után nézzük meg az alapértelmezett sendmail.mc állományt a FC2 disztribúcióban: divert(-1)dnl dnl # dnl # This is the sendmail macro config file for m4. If you make changes to dnl # /etc/mail/sendmail.mc, you will need to regenerate the dnl # /etc/mail/sendmail.cf file by confirming that the sendmail-cf package dnl # is installed and then performing a dnl # dnl #
make -C /etc/mail
dnl # include(`/usr/share/sendmail-cf/m4/cf.m4')dnl VERSIONID(`setup for Red Hat Linux')dnl OSTYPE(`linux')dnl A VERSIONID és az OSTYPE funkcióját már korábban megismertük.
177
dnl # dnl # default logging level is 9, you might want to set it higher to dnl # debug the configuration dnl # dnl define(`confLOG_LEVEL', `9')dnl Megadhatjuk a log részletességét. Logoláshoz a sendmail a syslog rendszert használja. dnl # dnl # Uncomment and edit the following line if your outgoing mail needs to dnl # be sent out through an external mail server: dnl # dnl define(`SMART_HOST',`smtp.your.provider') Amennyiben egy bizonyos szervernek szeretnénk átadni a kimenő leveleinket, akkor azt ennek a sornak a megadásával tehetjük meg. dnl # define(`confDEF_USER_ID',``8:12'')dnl dnl define(`confAUTO_REBUILD')dnl define(`confTO_CONNECT', `1m')dnl define(`confTRY_NULL_MX_LIST',true)dnl define(`confDONT_PROBE_INTERFACES' ,true)dnl define(`PROCMAIL_MAILER_PATH',`/usr/bin/procmail')dnl A procmail program megadása. A procmail képes a levelek feldolgozására a beállított procmailrc scriptek alapján. define(`ALIAS_FILE', `/etc/aliases')dnl Az /etc/aliases állományban megadhatunk felhasználói név leképezéseket, illetve automatikus forward szabályokat. define(`STATUS_FILE', `/var/log/mail/statistics')dnl} define(`UUCP_MAILER_MAX', `2000000')dnl define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl define(`confAUTH_OPTIONS', `A')dnl dnl # dnl # The following allows relaying if the user authenticates, and disallows dnl # plaintext authentication (PLAIN/LOGIN) on non-TLS links dnl # dnl define(`confAUTH_OPTIONS', `A p')dnl
178
Amennyiben lehetővé szeretnénk tenni a felhasználóink számára, hogy autentikáció után a szerver továbbítsa a leveleiket, akkor azt ennek az opciónak a beállításával tehetjük meg. Ellenkező esetben a szerver egyáltalán nem vesz át leveleket továbbításra csak lokálisan, illetve a bekonfigurált tartományokból.30 dnl # dnl # PLAIN is the preferred plaintext authentication method and used by dnl # Mozilla Mail and Evolution, though Outlook Express and other MUAs do dnl # use LOGIN. Other mechanisms should be used if the connection is not dnl # guaranteed secure. dnl # Please remember that saslauthd needs to be running for AUTH. dnl # dnl TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl dnl define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl Ezekkel a sorokkal kiválaszthatjuk az autentikációs metódust. dnl # dnl # Rudimentary information on creating certificates for sendmail TLS: dnl #
make -C /usr/share/ssl/certs usage
dnl # or use the included makecert.sh script dnl # define(`CERT_DIR',`/etc/mail/certs') define(`confCACERT_PATH',`CERT_DIR') define(`confCACERT',`CERT_DIR/cacert.pem') define(`confSERVER_CERT',`CERT_DIR/cert.pem') define(`confSERVER_KEY',`CERT_DIR/key.pem') define(`confCLIENT_CERT',`CERT_DIR/cert.pem') define(`confCLIENT_KEY',`CERT_DIR/key.pem') Az SSL (TLS) titkosítás használata esetén a szervernek szüksége van tanusítványra, hogy azonosítsa magát. Normál esetben ezt a tanusítványt az úgynevezett Certificate Authority szervezetektől igényelhetjük. Azonban a kommentben látható módon lehetőségünk van rá, hogy mi magunk generáljunk egy nem megbízható tanusítványt, hogy azt használhassuk. (A kliensek jelezni fogják hogy a tanusítvány nem megbízható, de lehetőségünk van ennek ellenére elfogadni.)
Megjegyzés A sendmail elég szigorú a titkos kulcs jogosultságait illetően, ezért figyeljünk rá, hogy csak a rendszergazdának legyen joga olvasni a kulcsfájlt. 30 A sendmail az autentikációhoz a cyrus-sasl (Simple Authentication and Security Layer) szolgáltatást használja. Ezért szükséges, hogy a saslauthd fusson. Amennyiben az autentikációs információt nem közvetlenül az /etc/shadow állományból szeretnénk venni, akkor Fedorán az /etc/sysconfig/saslauthd, míg Ubuntun az /etc/default/saslauthd állományban konfigurálhatjuk be a kívánt mechanizmust.
179
dnl # dnl # This allows sendmail to use a keyfile that is shared with OpenLDAP's dnl # slapd, which requires the file to be readble by group ldap dnl # dnl define(`confDONT_BLAME_SENDMAIL',`groupreadablekeyfile')dnl dnl # dnl define(`confTO_QUEUEWARN', `4h')dnl dnl define(`confTO_QUEUERETURN', `5d')dnl dnl define(`confQUEUE_LA', `12')dnl dnl define(`confREFUSE_LA', `18')dnl define(`confTO_IDENT', `0')dnl dnl FEATURE(delay_checks)dnl FEATURE(`no_default_msa',`dnl')dnl FEATURE(`smrsh',`/usr/sbin/smrsh')dnl Az alapértelmezett /bin/sh shell helyett a rendszer a Sendmail Restricted Shell t használja a programok futtatásához. FEATURE(`mailertable',`hash -o /etc/mail/mailertable.db')dnl Az /etc/mail/mailertable.db állományban bekonfigurálhatunk speciális domain-mailer összerendeléseket. Vagyis a mailertable állomány formátuma: mailer:domain FEATURE(`virtusertable',`hash -o /etc/mail/virtusertable.db')dnl A korábbi aliases lista egy kibővített formája, ahol a felhasználókat teljes címmel adhatjuk meg. Ezáltal lehetővé teszi virtuális domainek használatát. [email protected]
foo-info
[email protected] error:nouser 550 No such user here @jack.org
[email protected]
Azonban a cím megadásnál használhatunk speciális változókat is. Például a „%1” a felhasználónevet jelenti. Ezzel több felhasználó levelét is átirányíthatjuk egy másik domainre. @foo2.org
%[email protected]
FEATURE(redirect)dnl FEATURE(always_add_domain)dnl A lokálisan küldött leveleknél is hozzáteszi a domaint. FEATURE(use_cw_file)dnl
180
Beolvassa az /etc/mail/local-host-names állományt, amelyben felsorolhatjuk a szerverünk további neveit. FEATURE(use_ct_file)dnl Beolvassa az /etc/mail/trusted-users állományt. Ebben felsorolhatjuk azokat a megbízható felhasználókat (root, mailman), amelyek módosíthatják a levél from mezőjét anélkül, hogy erről a tényről a szerver figyelmeztetést írna a levélbe. dnl # dnl # The -t option will retry delivery if e.g. the user runs over his dnl # quota. dnl # FEATURE(local_procmail,`',`procmail -t -Y -a $h -d $u')dnl A procmail paraméterezése. FEATURE(`access_db',`hash -T -o /etc/mail/access.db')dnl Bekapcsolja az access.db támogatást. Ez az állomány megadja, hogy a sendmail mely rendszerektől fogadjon el leveket, és mely gépek levelét továbbítsa. Amennyiben szeretnénk engedélyezni egy tartományra a relayezést, akkor például a következő sorokkal tehetjük meg: 152.66.70
RELAY
aut.bme.hu
RELAY
FEATURE(`blacklist_recipients')dnl Letilthatjuk a levelek fogadását egyes célcímekre. EXPOSED_USER(`root')dnl dnl # dnl # The following causes sendmail to only listen on the IPv4 loopback dnl # address 127.0.0.1 and not on any other network devices. Remove the dnl # loopback address restriction to accept email from the internet or dnl # intranet. dnl # DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl Alapértelmezett beállításban a szerver csak a loopback interfészen (127.0.0.1) fut. Ahhoz, hogy tényleges hálózati szolgáltató legyen a sort módosítsuk az alábbiak szerint: DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl dnl # dnl # The following causes sendmail to additionally listen to port 587 for dnl # mail from MUAs that authenticate. Roaming users who can't reach their
181
dnl # preferred sendmail daemon due to port 25 being blocked or redirected dnl # find this useful. dnl # dnl DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl dnl # dnl # The following causes sendmail to additionally listen to port 465, but dnl # starting immediately in TLS mode upon connecting. Port 25 or 587 dnl # followed by STARTTLS is preferred, but roaming clients using Outlook dnl # Express can't do STARTTLS on ports other than 25. Mozilla Mail can dnl # ONLY use STARTTLS and doesn't support the deprecated smtps; dnl # Evolution <1.1.1 uses smtps when SSL is enabled-- STARTTLS support is dnl # available in version 1.1.1. dnl # dnl # For this to work your OpenSSL certificates must be configured. dnl # dnl DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA, M=s')dnl Ezzel a sorral bekapcsolhatjuk az SSL titkosítás támogatását a szerverünkben. (Ehhez a korábbi konfigurációs beállítások, tanusítvány is szükségesek.) dnl # dnl # The following causes sendmail to additionally listen on the IPv6 dnl # loopback device. Remove the loopback address restriction listen to the dnl # network. dnl # dnl DAEMON_OPTIONS(`port=smtp,Addr=::1, Name=MTA-v6, Family=inet6')dnl dnl # dnl # enable both ipv6 and ipv4 in sendmail: dnl # dnl DAEMON_OPTIONS(`Name=MTA-v4, Family=inet, Name=MTA-v6, Family=inet6') dnl # dnl # We strongly recommend not accepting unresolvable domains if you want dnl # to protect yourself from spam. However, the laptop and users on dnl # computers that do not have 24x7 DNS do need this. dnl # FEATURE(`accept_unresolvable_domains')dnl Elfogadja azoktól a gépektől is a kapcsolatot, amelynek a nevét a DNS nem tudja feloldani. dnl # dnl FEATURE(`relay_based_on_MX')dnl dnl # dnl # Also accept email sent to "localhost.localdomain" as local email.
182
dnl # LOCAL_DOMAIN(`localhost.localdomain')dnl dnl # dnl # The following example makes mail from this host and any additional dnl # specified domains appear to be sent from mydomain.com dnl # dnl MASQUERADE_AS(`mydomain.com')dnl dnl # dnl # masquerade not just the headers, but the envelope as well dnl # dnl FEATURE(masquerade_envelope)dnl dnl # dnl # masquerade not just @mydomainalias.com, but @*.mydomainalias.com dnl # as well dnl # dnl FEATURE(masquerade_entire_domain)dnl dnl # dnl MASQUERADE_DOMAIN(localhost)dnl dnl MASQUERADE_DOMAIN(localhost.localdomain)dnl dnl MASQUERADE_DOMAIN(mydomainalias.com)dnl dnl MASQUERADE_DOMAIN(mydomain.lan)dnl MAILER(smtp)dnl MAILER(procmail)dnl Bár a konfiguráció elemzése során már említettük, foglaljuk össze még egyszer, hogy milyen állományokkal befolyásolhatjuk a levelező szerver működését! access: Megadja, hogy a sendmail mely rendszerektől fogadjon el leveket, és mely gépek levelét továbbítsa. domaintable: Szerver-név leképezéseket adhatunk meg. Például ha a cég nevet és domaint változtatott, akkor ebben az állományban megadhatjuk a leképezést. local-host-names: Megadhatjuk a szerverünk alternatív neveit. mailertable: Ha egyes gépekre a levél továbbításra más út használata szükséges, mint az alapértelmezett, akkor ebben az állományban specifikálhatjuk azt. trusted-users: A megbízható felhasználók listája, akik specifikálhatnak speciális feladókat is a levelekben. virtusertable: Segítségével több virtuális domaint fogadhatunk egy levelező szerveren, majd a beállítások alapján a felhasználók helyi, vagy más szerveren lévő levelesládáiba továbbíthatjuk. Mivel a sendmail valójában az ezekből a szöveges állományokból generált adatbázisokat használja, ezért a módosítások után ezeket újra kell generálnunk. 183
makemap hash /etc/mail/<állomány> De a Fedora és az Ubuntu disztribúciókban elegendő, ha kiadjuk a make parancsot az /etc/mail könyvtárban, amely frissíti az összes adatbázist. Az /etc/aliases állomány módosítása esetén pedig a newaliases parancsot kell lefuttatnunk. Ahhoz, hogy a szerverünk elfogadja a lokális hálózatunkon lévő gépek levelező klienseitől a leveleket, szükséges felvennünk vagy a gépeket, vagy a domainnevet, vagy a címtartományt az access állományba. Példánkban a lokális hálózat neve és címtartománya: valahol.hu, 192.168.0.0/24. A levelező szerver neve és címe: mail.valahol.hu, 192.168.0.10. A kliens neve és címe: kliens.valahol.hu, 192.168.0.101. Amennyiben csak az adott kliens leveleit akarjuk továbbítani, akkor a következő sort kell elhelyeznünk az access állományban: kliens.valahol.hu
RELAY
Vagy IP címmel is hivatkozhatunk rá: 192.168.0.101
RELAY
Amennyiben a helyi hálózat összes gépének levelét továbbítani szeretnénk, akkor: valahol.hu
RELAY
Vagy IP címmel megadva: 192.168.0
RELAY
Ezek után újra kell generálnunk az adatbázist, majd újraindítani a sendmail t.
Feladat Állítsuk be az access állományban, hogy a sendmail a helyi hálózat leveleit továbbítsa! Amikor az MTA szerverek leveleket továbbítanak, akkor gyakran előfordul, hogy a címzett levelezőszervere valamiért éppen nem elérhető. Ebben az esetben a szerver egy várakozási listába helyezi a levelet, és meghatározott időközönként újra megpróbálja elküldeni. A sendmail esetén ezt a várakozási listát a mailq paranccsal tudjuk kilistázni. Helyileg a várakozó levelek a /var/spool/mqueue könyvtárban találhatóak. Ha manuálisan szeretnénk kiváltani a várakozó lista elküldését, akkor azt a sendmail -q paranccsal tehetjük meg. 8.4.2.
Postfix
Ebben a fejezetben a Postfix telepítését, beállítását tárgyaljuk. Az Ubuntu disztribúció jelenlegi alapértelmezett MTA-ja (Mail Transfer Agent) a Postfix. A Postfix beállítása egyszerűbb, mint a Sendmailé, ugyanakkor gyors és biztonságos levelezést tesz lehetővé, valamint a Sendmail MTA-jával is kompatibilis. A Postfix használatához a postfix Debian csomagra van szükségünk.
184
sudo apt-get install postfix Telepítéskor kiválaszthatjuk a nekünk megfelelő funkciókat, de ha ezt elmulasztottuk, akkor a következő parancs kiadásával ismét visszajutunk a konfigurációs képernyőhöz. sudo dpkg-reconfigure postfix A postfix fő konfigurációs fájlja az /etc/postfix/main.cf, melyből a következő opciókat emeljük ki. A certificate állomány megadása: smtpd_tls_cert_file = /etc/ssl/certs/ssl-mail.pem Privát kulcs: smtpd_tls_key_file = /etc/ssl/private/ssl-mail.key TLS támogatása az SMTP kommunikációnál: smtpd_use_tls = yes Az /etc/alias az email leképezés (forward) beállítások állománya: alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases Minden interfészen IPv4 használata: inet_interfaces = all inet_protocols = ipv4 A mailbox formátum (fontos, hogy szinkronban legyen a Dovecottal): home_mailbox = Maildir/ Van SMTP autentikáció, ami SASL-on keresztül megy és SASL-démonnak a Dovecotot használja, vagyis lényegében az autentikál. (Lehetne még Cyrus SASL démon is. Korábban a Sendmail esetén azt használtuk.) smtpd_sasl_auth_enable = yes smtpd_sasl_type = dovecot Csak TLS-en keresztül engedi az autentikációt. smtpd_tls_auth_only = yes
8.4.3.
Dovecot
A Dovecot IMAP és POP3 szervert a biztonsági szempontok figyelembe vételével alakították ki. Teljesen kompatibilis az elterjedt University of Washington IMAP csomaggal, amely széles körben használt. Telepítsük a dovecot-postfix csomagot! 185
sudo apt-get install dovecot-postfix A konfigurációs állománya az /etc/dovecot/dovecot.conf. Az egyes protokollok kiszolgálását a következő sorral kapcsolhatjuk be: protocols = imap imaps pop3 pop3s Protokollonként lehetnek egyéni, a megszokottól eltérő beállításaink. protocol imap { listen = *:10143 ssl_listen = *:10943 ... } Hogy minden interfészen fogadja a kéréseket a következő sort kell beírnunk. (Azért van kikommentezve, mert ez az alapértelmezett beállítás.) # listen = * Az „s” végű protokollok az eredeti SSL-t használó változatai. Mivel a jelszó továbbítás egyébként nyílt, ezért célszerű ezek használata. Az SSL titkosítás használatához szükségünk van SSL tanúsítványokra. Ennek beszerzésére két lehetőségünk van: egy Certificate Authority (CA) cégtől kérünk egyet, vagy egy self-signed certificate-et hozunk létre. Utóbbi megoldás csak teszteléshez javasolt.31 Alapértelmezetten SSL/TLS nélkül nem engedi a plain text autentikációt, amin a következő sor kikommentezésével változtathatunk. # disable_plaintext_auth = yes A konfigurációs állományban az alábbi sorokkal adhatjuk meg a tanúsítvány és a privát kulcs helyét. ssl_cert_file = /etc/ssl/certs/dovecot.pem ssl_key_file = /etc/ssl/private/dovecot.pem A különböző mailbox formátumok megadása, ha nincs megadva a Dovecot megpróbálja automatikusan kitalálni. mail_location = maildir:~/Maildir mail_location = mbox:~/mail:INBOX=/var/mail/%u mail_location = mbox:/var/mail/%d/%1n/%n:INDEX=/var/indexes/%d/%1n/%n A levelek könyvtárakba és állományokba szervezve vannak tárolva a felhasználó home könyvtárában (maildir). 31 Egy
olcsó, alternatív megoldás, ha saját magunk hozunk létre egy Certificate Authority-t a felhasználóink számára. Ebben az esetben elő kell állítanunk egy root certificate-et, amelyet a csoport minden felhasználójának a gépén el kell fogadtatnunk, mint megbízható root certificate. Ezek után ezek a gépek elfogadják az általunk aláírt tanúsítványokat.
186
A
levelek
mail
folderenként
egy
állományban
vannak
(mbox).
Az
inbox
tipikusan
a
/var/mail/ állományban tárolódik, a többi mail folder pedig a home könyvtárban. (Természetesen csak IMAP esetén van az utóbbi, mivel POP3 esetén a kliens nem a szerveren tárolja a leveleket, hanem leszedi azokat.)
Feladat 1. Teszteljük a beállított levelezőszerverünket telnettel! telnet localhost 25 ehlo localhost 2. Állítsuk be a Thunderbird levelező programot a levelezőszerverünkhöz való kapcsolódáshoz, és próbáljuk ki!
8.5.
Procmail
A Procmail egy lokális levéltovábbító rendszer, amely ugyanakkor komoly szűrést tesz lehetőve. Ezáltal a beérkező leveleinket szortírozhatjuk. A procmail programot többféle képpen is meghívhatjuk. A korábban beállított konfigurációban a sendmail automatikusan meghívja minden beérkező levélre. A procmail az /etc/procmailrc és a felhasználó home könyvtárában található .procmailrc konfigurációs állományokban megadottak szerint dolgozza fel a levelet. (A procmailrc állományok szintaktikájának leírása a man procmailrc paranccsal tekinthető meg.) Az /etc/procmailrc állományban célszerű elhelyezni a következő sort, hogy a procmail ne root privilégiumokkal, hanem a címzett felhasználó nevében hajtsa végre az utasításokat. DROPPRIVS=yes A ~/.procmailrc állomány elején is célszerű pár sort mindenképpen elhelyezni. • Az e-mail mappák helye: MAILDIR=$HOME/mail • És a log állomány, hogy visszanézhessük a procmail tevékenységét: LOGFILE=$HOME/.procmail.log
8.6.
Spamszűrés
A spam levelek elkapásának egyik kézenfekvő helye a levelezőszerver. Ebben a fejezetben megtárgyaljuk, hogyan lehet összekötni az Amavisd-new, a Spamassassin és ClamAV programokat a Postfix-szel. A 187
Postfix képes külső szűrőket használni a beérkező emailek vizsgálatára. Ezek a külső szűrők képesek eldönteni, hogy egy beérkező levél spam-e vagy sem. Az összekapcsolt programok: Amavisd-new: Átfogó program, ami képes tartalom-, spamszűrő, vagy antivírus programokat meghívni. Spamassassin: A levél tartalma alapján képes eldönteni, hogy ki kell-e szűrni az adott levelet. ClamAV: Nyílt-forráskódú antivírus program. A következőképpen állnak össze ezek a szoftverek egy hatékony lánccá, amellyel az emailszűrés végrehajtható: 1. A Postfix fogadja a beérkező levelet. 2. Az Amavisd-new feldolgozza. 3. A ClamAV ellenőrzi a levelet, hogy van-e benne vírus. Ha vírust talál, akkor a Postfix eldobja az üzenetet. 4. A megvizsgált leveleket a Spamassassin vizsgálja tovább, hogy kiderüljön, hogy az spam-e vagy sem. Majd a Spamassassin X-Header sorokkal látja el a levelet, hogy az Amavisd-new számára további feldolgozást tegyen lehetővé. Ahhoz, hogy mindez működjön, először fel kell telepítenünk a már említett programokat, illetve a spamszűrőket. sudo apt-get install amavisd-new spamassassin clamav-daemon sudo apt-get install pyzor razor Amennyiben az előzőekkel megvagyunk, akkor néhány további, a levelek csatolmányainak vizsgálatát lehetővé tevő programot is telepítenünk kell. sudo apt-get install arj cabextract cpio lha nomarch pax rar unrar unzip zip A rendszer konfigurációját lépésenként ismertetjük: 1. Az /etc/group állományban az amavis csoporthoz hozzá kell adni a clamav felhasználót. 2. A spamassassint démon módba kell állítani, azaz az /etc/default/spamassassin fájlban engedélyezni kell a spam démont. ENABLED=1 Ezek után újra kell indítani a spamassassint.
188
sudo service spamassassin restart 3. Az
Amavisban
engedélyezni
kell
a
víruskereső
és
spam
kereső
használatát.
Az
/etc/amavis/conf.d/15-content_filter_mode fájlban ki kell venni a komment karaktert a megfelelő sorok elejéről. use strict; # You can modify this file to re-enable SPAM checking through spamassassin # and to re-enable antivirus checking. # # Default antivirus checking mode # Uncomment the two lines below to enable it # @bypass_virus_checks_maps = ( \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re); # # Default SPAM checking mode # Uncomment the two lines below to enable it # @bypass_spam_checks_maps = ( \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re); 1;
# insure a defined return
A spam levelek visszapattintása nem jó megoldás, mert a válaszcím általában nem valódi. Ezért érdemes az /etc/amavis/conf.d/20-debian_defaults fájlban a $final_spam_destiny változó értékét D_DISCARD-ra állítani. $final_spam_destiny = D_DISCARD; Továbbá a következő beállításokkal finomhangolhatók a spam szintek. $sa_tag_level_deflt = -999; # add spam info headers if at, or above that level $sa_tag2_level_deflt = 6.0; # add 'spam detected' headers at that level $sa_kill_level_deflt = 21.0; # triggers spam evasive actions 189
$sa_dsn_cutoff_level = 4; # spam level beyond which a DSN is not sent Ha a szerver hosztneve nem egyezik meg a domain MX rekordjával, akkor manuálisan kell beállítani a $myhostname opciót. Továbbá, ha a szerver több domainről is kaphat levelet, akkor a @local_domains_acl opciót kell átállítani. Ehhez az /etc/amavis/conf.d/50-user fájlban kell megejteni a következő módosításokat. $myhostname = 'mail.example.com'; @local_domains_acl = ( "example.com", "example.org" ); Ha a konfiguráció kész, akkor az amavist újra kell indítani. sudo service amavis restart 4. A Postfix integrációhoz először a következő sort kell beírni a terminálba, hogy a leveleket szűrésre a megadott címre továbbítsa: sudo postconf -e 'content_filter = smtp-amavis:[127.0.0.1]:10024' Majd a következő sorokat kell hozzáadni az /etc/postfix/master.cf fájl végéhez. smtp-amavis
unix
-
-
-
-
2
smtp
-o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes -o disable_dns_lookups=yes -o max_use=20 127.0.0.1:10025 inet
n
-
-
-
-
smtpd
-o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_delay_reject=no -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -o mynetworks=127.0.0.0/8 -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000
190
-o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks Továbbá az alábbi két sorral kell kiegészíteni a pickup átviteli szolgáltatást: -o content_filter= -o receive_override_options=no_header_body_checks Ha a konfiguráció kész, akkor újra kell indítani a postfix et. sudo service postfix restart Ezzel el is készültünk a levelezésszűrés és a víruskeresés beállításával.
Feladat 1. Küldjünk egy levelet telnettel! 2. Küldjünk magunknak egy levelet a Thunderbird programmal, majd vizsgáljuk meg a fejlécben az X-Virus-Scanned sort! 3. Küldjünk magunknak egy levelet a Thunderbird programmal, amelybe belemásoljuk az /usr/share/doc/spamassassin/examples/sample-spam.txt fájl tartalmát! (Ez a levél spamként lesz megjelölve, ezért nem fog megérkezni a postaládánka, hanem az Amavisd-new karanténba helyezi.)
8.7.
Squirrelmail
Gyakori igény, hogy a felhasználók szeretnék webes felületről is elérni leveleiket. Ezáltal lehetővé válik publikus számítógépek, vagy más olyan gépek használata is, ahol nincs módunk vagy szándékunk egy levelező klienst bekonfigurálni. A Squirrelmail egy PHP alapú webmail szolgáltatás. A PHP beépített IMAP és SMTP protokoll támogatását használja a levelező szerver eléréséhez. Konfigurálása egyszerű, a Fedora és Ubuntu disztribúciókban található squirrelmail csomag ezt még tovább egyszerűsíti, így már csak néhány beállítás marad az adminisztrátorra. A szolgáltatás könyvtárát Fedorán az /etc/httpd/conf.d/squirrelmail.conf, míg Ubuntun az /etc/squirrelmail/apache.conf állomány képezi le a webszerver könyvtárstruktúrájába. A konfigurációs állománya az /etc/squirrelmail/config.php. Azonban ezt közvetlenül nem szoktuk kezelni. Erre szolgál az /usr/share/squirrelmail/config/conf.pl Perl szkript. Az /usr/share/squirrelmail egyben a szolgáltatás fő könyvtára. A benne található PHP szkriptek valósítják meg a funkcionalitást. A csomag által használt további könyvtárak: a /var/spool/squirrelmail/attach, amely a csatolt állományok tárolására szolgál, valamint Fedorán a /var/lib/squirrelmail/prefs, illetve Ubuntun a
191
/var/lib/squirrelmail/data, könyvtár amely a felhasználók egyéni beállításait tartalmazza. Mindkét könyvtár tartalmazhat kényes információkat, ezért ügyeljünk rá, hogy csak az Apache szerver férjen hozzá! (Az viszont szükséges, egyébként nem tudnánk használni.) Mielőtt használni kezdjük a szolgáltatást a konfigurációs szkript segítségével először be kell konfigurálnunk. Fedorán az /usr/share/squirrelmail/config könyvtárba kell először belépnünk, majd: perl conf.pl32 A legfontosabb paraméterek, amelyeket be kell állítanunk: Organization Preferences/Organization Name Server Settings/Domain Server Settings/Sendmail or SMTP Server Settings/IMAP Settings Továbbá ha nem az Ubuntu vagy a Fedora disztribúciók csomagját használjuk: General Options/Data Directory General Options/Attachment Directory A helyes működéshez egy szimbolikus linket kell létrehoznunk a squirrelmail konfigurációs fájljáról az apache konfigurációs könyvtárába. sudo ln -s /etc/squirrelmail/apache.conf /etc/apache2/sites-available/squirrelmail Ezek után engedélyeznünk kell a squirrelmail oldalát, majd újra kell indítanunk a webszervert. sudo a2ensite squirrelmail sudo service apache restart A biztonságos bejelentkezéshez a squirrelmail-secure-login csomag telepítése ajánlott. sudo apt-get install squirrelmail-secure-login Ennek segítségével biztosíthatjuk, hogy a felhasználó SSL titkosítás használatával lépjen be, ami azért fontos, hogy a jelszavak titkosítás nélkül ne közlekedjenek a hálózaton. A Plugin menüpont alatt olyan bővítéseket kapcsolhatunk be, amelyek újabb funkcionalitásokat visznek a rendszerbe. További csomagokat a http:// www.squirrelmail.org/ plugins.php címen találhatunk. Az egyes csomagokban leírás is szerepel a plugin telepítéséről.
Feladat Nézzük meg egy böngészővel a helyi squirrelmail fiókunkat!
32 Ubuntun
a squirrelmail-configure parancs szolgál ugyanerre.
192
9.
Hálózatdiagnosztika, hálózatok feltörése, Certificate Authority, snort
9.1.
Hálózatdiagnosztika
Az átlagos felhasználótól a hálózati adminisztrátorig mindenki használ néhány egyszerű programot a hálózati problémák felderítésére, vizsgálatára. A következőkben ezekből tekintünk át néhányat. 9.1.1.
Ping
A legegyszerűbb és leggyakrabban használt hálózati diagnosztikai program. Segítségével megvizsgálhatjuk, hogy a gépünkről elérhető-e egy távoli hoszt. Például a kívánt kapcsolat hiánya a szerver szolgáltatás hibájából, vagy a hálózati forgalmazás hibájából ered-e. Működése egyszerű. A ping ICMP (Internet Control Message Protocol) echo-request csomagokat küld ki, amelyre a másik oldal ICMP echo-reply csomagokkal válaszol. A visszaérkező válasz csomagokból megállapítható a hálózati kapcsolat lehetősége, a csomagok továbbításának ideje és a csomagveszteség. $ ping www.aut.bme.hu PING www.aut.bme.hu (152.66.188.11) 56(84) bytes of data. 64 bytes from www.aut.bme.hu (152.66.188.11): icmp_req=1 ttl=119 time=10.3 ms 64 bytes from www.aut.bme.hu (152.66.188.11): icmp_req=2 ttl=119 time=10.5 ms 64 bytes from www.aut.bme.hu (152.66.188.11): icmp_req=3 ttl=119 time=8.27 ms ^C --- www.aut.bme.hu ping statistics --3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 8.270/9.721/10.549/1.032 ms $
9.1.2.
Traceroute
Az interneten két gép között a kapcsolat sokszor több routeren keresztül valósul meg. Ez a jobbik eset, mert időnként egyáltalán nem valósul meg. Ilyenkor a probléma eredhet két router közötti kapcsolat megszakadásából, vagy router konfigurációs hibából. Hogy behatároljuk a probléma helyét a kommunikációs vonalban, ki kell derítenünk, hogy csomagjaink mely routereken haladnak át a cél felé. A traceroute az IP csomagok TTL (Time To Live) mezője segítségével deríti ki mely átjárókat érintik csomagjaink, illetve hogy hol akadnak el. A program egyesével növekvő TTL mezőértékekkel rendelkező csomagokat küld ki. Amikor a TTL érték egy routeren eléri a nulla értéket, akkor az eszköz ICMP time-exceed hibacsomagot küld vissza a feladónak. Így egymás után begyűjthetjük a routerek címeit. $ traceroute linux.hu traceroute to linux.hu (212.40.96.73), 30 hops max, 38 byte packets 1
ns (152.66.70.4)
2
aut-switch (152.66.70.2)
0.197 ms
0.184 ms
0.996 ms
0.160 ms
1.027 ms
193
1.408 ms
3
vlan14.photon.bme.hu (152.66.0.70)
1.578 ms
4
tge2-2.sup720.bme.hbone.hu (152.66.0.126)
0.707 ms
0.618 ms
0.570 ms
5
tge2-2.sup720.bme.hbone.hu (152.66.0.126)
0.509 ms
0.617 ms
0.503 ms
6
c6513-tengbeth13-2.vh.hbone.hu (195.111.97.101)
7
bix.externet.hu (193.188.137.43)
8
* * *
1.287 ms
2.874 ms
0.883 ms
6.082 ms
1.142 ms
1.098 ms
0.831 ms
1.212 ms
... $ 9.1.3.
LFT
Az LFT (Layer Four Traceroute) program a traceroute egy továbbfejlesztett alternatívája. A traceroute egyes tűzfal konfigurációknál csődöt mond. Ennek kiküszöbölésére fejlesztették ki az lft programot, amely működése sokban hasonlít az elődjéhez. Szintén az IP csomagok TTL mezőjét használja fel a detektálásra, azonban UDP csomagok helyett TCP SYN és FYN csomagokat küld ki. A visszaérkező ICMP time-exceed üzenet mellett más hibaüzeneteket is kezel. Az -E opció használatával további automatizmusokat kapcsolhatunk be, amelynek célja, hogy növelje a keresés sikerét. $ lft linux.hu Tracing ________________. TTL
LFT trace to Linux3.externet.hu (212.40.96.73):80/tcp
1
ns.aut.bme.hu (152.66.70.4) 0.2ms
2
aut-switch.aut.bme.hu (152.66.70.2) 16.5ms
3
vlan14.photon.bme.hu (152.66.0.70) 2.0ms
4
tge2-2.sup720.bme.hbone.hu (152.66.0.126) 3.1ms
5
tge2-2.sup720.bme.hbone.hu (152.66.0.126) 0.5ms
6
c6513-tengbeth13-2.vh.hbone.hu (195.111.97.101) 3.1ms
7
bix.externet.hu (193.188.137.43) 2.9ms
8
[target] Linux3.externet.hu (212.40.96.73):80 3.7ms
$
9.1.4.
Netstat
A netstat a Linux hálózati alrendszerének információit jeleníti meg. Paraméterezés nélkül az élő hálózati kapcsolatok listáját kapjuk. Az -a paraméterrel a lista kiegészül a hálózati szerverszolgáltatások által nyitva tartott portokkal is. Rendszergazdaként kiegészíthetjük ezt még a -p paraméterrel, amely a portokhoz az azt használó processzeket is megjeleníti.
194
Ha valamiért szeretnénk kikapcsolni az IP címek nevekre alakítását, például a leképezés lassúsága miatt, akkor ezt az -n paraméterrel tehetjük meg. A netstat -a által visszaadott listához hasonlót generálhatunk a következő paranccsal is: lsof -i
9.1.5.
Nmap
Az nmap egy hálózat felderítő eszköz. Segítségével egy hálózati tartományban megvizsgálhatjuk a működő gépeket és az általuk kínált szolgáltatásokat. A program számos vizsgálati metódust tartalmaz, amelyeket a paraméterekkel választhatunk ki. A leggyakoribb használati területe a hálózatunk gyenge pontjainak felderítése.
Megjegyzés A program által használt letapogató módszerek jó részét a hálózat felügyeleti programok betörési próbálkozásnak értékelhetik. Ezért távoli hálózatok esetén elővigyázatosan használjuk, mert könnyen tiltólistára kerülhetünk! Egy hoszt nyitott portjainak és a használt operációs rendszer kiderítésére például az alábbi parancssort használhatjuk. nmap -sS -O localhost
9.1.6.
Tcpdump
Mind a tcpdump, mind a következő részben tárgyalt Wireshark a hálózati csomagok monitorozására szolgál. Ezáltal alacsony szinten vizsgálhatjuk, milyen csomagok közlekednek az általunk használt hálózati szegmensen. Analizálhatjuk a hálózati forgalom hibáit. A tcpdump szöveges felületen teszi lehetővé a kommunikáció megfigyelését. Ez általában gyors ellenőrzésre használható. Ugyanakkor a felület korlátokat jelent az alapos vizsgálat esetén. Ha például egy konkrét hoszt felé szeretnénk megfigyelni a forgalmat, akkor azt a következő parancsokkal tehetjük meg: tcpdump host Ha egy portot szeretnénk megfigyelni: tcpdump port <port>
9.1.7.
Wireshark
A Wireshark a tcpdumppal szemben grafikus felületen teszi elérhetővé a csomagok monitorozását, a forgalom analizálását. A grafikus felület lehetővé teszi a csomagok mélyebb elemzését is.
195
A program elindítása után az alkalmazás főablakát láthatjuk magunk előtt. Ezen ablak menüsorából elsősorban a Capture és az Analyze lenyíló menük elemeit használjuk a labor során. A Capture menü tartalmazza a hálózati csomagok monitorozásának beállításait és a monitorozás elindítását. Az Analyze menü a monitorozás során vett csomagok értelmezésének beállításait tartalmazza. 9.1.7.1.
Egyszerű monitorozás
Amennyiben a számítógépünkön nem futtatunk semmilyen hálózaton forgalmazó programot, a gépünk akkor is folyamatosan kap hálózati csomagokat. Ezek broadcast csomagok, többnyire ARP címlekérések, illetve ha Microsoft Windowst használó gépek is vannak a hálózaton, akkor SMB csomagok. A monitorozás kipróbálására ezeket a csomagokat fogjuk megvizsgálni. A monitorozás elindításához válasszuk ki a Capture menü Options elemét.
29. ábra. A Wireshark Capture Options ablaka A dialógusablak Interface mezőjében megadhatjuk a vizsgálandó hálózati interfészt.33 A eth0 interfész a Linux rendszerek első Ethernet interfészét jelenti. A Microsoft Windows rendszerekben az interfészek elnevezése eltér ettől. 33 Az
196
Capture Filter mezőben szűrési feltételeket állíthatunk be, amellyel a hálózati interfészen átvitt számos csomag közül kiválaszthatjuk azt a halmazt, amely számunkra érdekes. Helyes megválasztásával nagyban megkönnyíthetjük a munkánkat. Míg helytelen megválasztása jó pár hálózati csomag átböngészését eredményezheti. Az esetek többségében csak ezt a két paramétert állítjuk, azonban érdekesek lehetnek a Stop Capture beállítások, amellyel a monitorozás végének feltételét adhatjuk meg, vagy a Display Options csoporton belüli Update list of packets in real time opció, amely jelentős terhelést jelenthet, azonban lehetővé teszi a beérkező csomagok folyamatos követését. Ezen kívül a Name Resolution csoportban található opciókkal megadhatjuk, hogy mely címeket és portokat jelenítsen meg szövegesen a program. A paraméterek beállítása után a Start gombbal indíthatjuk a monitorozást. A megjelenő dialógusablakon szám szerint követhetjük az elkapott csomagok számát. Amennyiben szeretnénk a monitorozást leállítani, azt a Stop gombbal tehetjük meg.
30. ábra. A Wireshark főablaka a monitorozás leállítása után A felület három részre tagolódik. A felső részben egy listát találhatunk, amely az elkapott csomagokat tartalmazza. Ha ebből a listából kiválasztunk egy csomagot, akkor az alsó részben láthatjuk a bináris tartalmát, míg a középső rész értelmezett formában mutatja. A vizsgálódásaink során elsősorban a középső részt használjuk. A középső mező a kiválasztott csomag által tartalmazott keretek listáját mutatja. Ahogy a csomag az
197
egyes hálózati rétegeken keresztül haladva felépül, minden réteg egy új keretet alkot belőle. Minden keret rendelkezik néhány fejléc mezővel és egy adat résszel. A lista elemeit lenyitva a fejléc mezők tartalmát tekinthetjük meg. Példaként, a 30. ábrán egy ARP kérés csomag felépítését láthatjuk. A csomagban található egy Ethernet keret, amely tartalmazza a forrás MAC címét, míg a cél MAC cím helyén egy broadcast cím található. Az Ethernet keret tartalmaz egy ARP keretet, amelynek mezői megadják a forrás MAC címet, IP címet, illetve a cél IP címét. A cél MAC címe a kérdés, amelyet a csomag próbál lekérni. Így annak értéke nem definiált, esetünkben (Linux esetén) a broadcast cím. Az előzőekben ismertetett módon bármikor megismételhetjük a monitorozást. Ilyenkor a program a monitorozás elindításakor felteszi a kérdést, hogy a korábban vett csomagokat lementse-e, vagy törölje. Döntsünk belátásunk szerint! 9.1.7.2.
A TCP kommunikáció követése
A TCP protokoll egy stream jellegű kommunikációt tesz lehetővé. Ez a kommunikáció a két program között, mint egy csővezeték funkcionál, amelyen mindkét irányba közlekedhetnek protokoll üzenetek vagy adatok. Ugyanakkor a hálózati modell alsóbb rétegeiben ez a kommunikáció is csomagokra tördelve jelenik meg, az üzenetek csomagok láncolatában kerülnek továbbításra. Ha az előzőekben ismertetett módon egy TCP kommunikáció csomagjait monitorozzuk, akkor azt az ablak felső részében, csomagok listájaként láthatjuk. Ezeket a csomagokat egyenként megvizsgálhatjuk, azonban ha az alkalmazási réteg protokoll üzeneteire vagyunk kíváncsiak, akkor célszerű a csomagokat összefűzni. A TCP kommunikáció összefűzésére az Analyze menü Follow TCP Stream menüpontját használhatjuk. Ehhez ki kell választanunk a TCP kapcsolat egy csomagját, majd aktiválnunk a menüpontot. Ezt a menüpontot úgy is elérhetjük, ha az adott csomagot kiválasztva az egér jobb gombjával kattintunk. A megjelenő ablakban olvashatjuk a két oldal üzeneteit. Az egyes irányokat színek különböztetik meg. Megfigyelhetjük, hogy a menüpont kiválasztása módosítja az ablak tetején a Filter opció értékét. Ha újra az összes vett csomagot szeretnénk látni, akkor a Clear gombbal töröljük a szűrést. 9.1.8.
Whois
A whois adatbázisok az egyes hálózatok adminisztratív információit tárolják. Ha kapcsolatba szeretnénk lépni egy számunkra ismeretlen hálózat rendszergazdáival, akkor ebből az adatbázisból deríthetjük ki az ehhez szükséges információkat. Tegyük fel, hogy egy bizonyos IP címről támadási próbálkozások érkeztek a hálózatunk ellen. Ilyenkor a whois kliens program segítségével le tudjuk kérdezni, hogy mely szolgáltató, vagy hálózat adminisztrációs egység része az adott gép. whois # whois 152.66.115.1 [Querying whois.arin.net] [Redirected to whois.ripe.net] [Querying whois.ripe.net] [whois.ripe.net]
198
% This is the RIPE Whois quaternary server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/db/copyright.html inetnum:
152.66.0.0 - 152.66.255.255
netname:
BMENET
descr:
Budapest University of Technology and Economics
descr:
Budapesti Muszaki es Gazdasagtudomanyi Egyetem
country:
HU
admin-c:
GR1029-RIPE
tech-c:
GB2054-RIPE
tech-c:
IOS2-RIPE
tech-c:
GOYA-RIPE
rev-srv:
nic.bme.hu
rev-srv:
ns.bme.hu
status:
ASSIGNED PI
remarks:
hrcode=05799610e
remarks:
----------------------------------------------------------
remarks:
Please send abuse and spam notifications to [email protected].
remarks:
Reporting guidelines can be found at
remarks:
http://www.bme.hu/en/other/network/abusereport_en.html
remarks:
----------------------------------------------------------
remarks:
A helytelen hasznalatot kerjuk az [email protected] cimen
remarks:
jelezze! A bejelentesekt kerjuk az alabbiak szerint tegye:
remarks:
http://www.bme.hu/hu/egyeb/halozat/abusereport_hu.html
remarks:
----------------------------------------------------------
mnt-by:
AS2547-MNT
changed:
[email protected] 19980924
changed:
[email protected] 20020130
changed:
[email protected] 20030611
changed:
[email protected] 20040202
source:
RIPE
... A visszakapott információk alapján már tudjuk, hogyan jelezhetjük az illegális tevékenységeket.
9.2.
Hálózatok feltörése, avagy mennyire nyilvános a kommunikációnk
A korábbiakban szerepelt, hogy a tűzfallal beállíthatjuk, hogy a határainkon milyen protokollokat engedünk ki, illetve be. Azonban jó eséllyel a határainkon belül mindenféle protokollt használhatnak a
199
felhasználóink. Ennek a fejezetnek a célja, hogy megmutassa, ha valaki hozzáfér a belső hálózatunkhoz, vagy be tud ékelődni a kommunikációs vonalba a határainkon túl, akkor mit lát a forgalmunkból. Miért kell odafigyelnünk arra, hogy biztonságos protokollokat használjunk, vagy SSL-lel titkosítsunk. Mivel ezek a módszerek az interneten széles körben hozzáférhetőek, ezért célszerű tudnunk róla, hogyan védekezhessünk. Gondolhatnánk, hogy azt itt bemutatott veszélyek csak a belső hálózatunkra érvényesek és legfeljebb a gyanús alakokat nem engedjük be. Azonban érdemes számolni azzal, hogy a belső emberekben sem lehet sokszor megbízni, még ha nem is rossz szándékú, de a számítástechnikához nem értő, csak használó ember jó eséllyel akad köztük. Így telepíthet véletlenül egy backdoort a gépére, amit nem biztos, hogy a tűzfalunk akadályoz. A másik nagy veszély, amire külön kitérünk a WLAN AP-k használata. A vezeték nélküli technológia használatával megszűnnek a fizikai határok, így az épületen kívülről is hozzáférhetnek a belső hálózatunkhoz. Különösen nagy veszélyt jelentenek a munkatársak által behozott és rosszul beállított WLAN routerek. Emellett ha VLAN-t (virtuális LAN) használunk az egyes hálózatok elkülönítésére, akkor is számolnunk kell azzal, hogy egy helytelenül konfigurált, vagy hibákkal rendelkező eszköz esetén a támadó átléphet az egyik VLAN-ból a másikba és szintén hozzáférhet a hálózatunkhoz. Bár erre az esetre nem térünk ki, mivel egy felkészült hálózati adminisztrátor ezt az esetet ki tudja küszöbölni. 9.2.1.
ARP poisoning
Manapság helyi hálózatnak switchelt hálózatokat használunk. Ennél a megoldásnál lényegében a switchen keresztül pont-pont kapcsolat tud kialakulni két számítógép között, ha a switch tudja, hogy melyik portján melyik gép található. Így egy harmadik gép alapesetben nem látja a két gép közötti kommunikációt. Azonban ez csak látszólag biztonságos, mivel a switchek többsége támadható olyan módon, hogy elárasztjuk új MAC címekkel, ezzel teljesen feltöltve a tanuló tábláját. Ennek hatására a switch jobb megoldás hiányában innentől minden portjára mindent elküld, vagyis visszabutul és lényegében hubként működik. Az adminisztrálható switcheknél beállítható, hogy egy tanuló időszak után rögzítjük a táblát és innentől érzéketlen az ilyen jellegű támadásokra. De ez sem jelent teljes védelmet. Ahhoz hogy harmadik félként megszerezzük két kommunikáló gép forgalmát valójában nincs szükségünk a hálózati eszközök támadására. A megoldást az ARP protokoll egy hiányossága nyújtja. Ha megnézünk egy normál ARP kommunikációt az így zajlik le: 1. Az „A” gép meg akarja szólítani „B” gépet. Tudja „B” IP címét, de nem tudja a MAC címét. Pedig a tényleges kommunikáció a MAC címmel történik. 2. „A” kiküld egy broadcast ARP kérést, amelyben megkérdezi, hogy mi a „B” IP címéhez tartozó MAC cím. 3. „B” megkapja az ARP kérést és válaszol rá. Az „A” gépnek elküldi az ARP választ benne a saját MAC címével. 200
4. Az „A” gép megkapja a választ és hogy ne kelljen ezt a kommunikációt minden egyes csomag előtt végig folytatni, ezért elhelyezi a cachebe az információt egy időre. Illetve a kapott MAC címre küldi a csomagot. Azonban igazából nem kell, hogy az ARP választ egy ARP kérés megelőzze. Ha az „A” gép kap egy ARP válasz csomagot, akkor a benne lévő információk alapján frissíti az IP cím-MAC cím összerendelést a cache-ben. Ugyanakkor az ARP protokoll nem alkalmaz semmilyen azonosítási mechanizmust, így bárki küldhet bárkinek egy ARP választ és frissítheti a gép ARP táblázatát. Mindebből sejteni lehet, hogy ezek után a harmadik félnek már csak a következőt kell tennie: 1. Az „A” gépnek elküldjük a „B” IP címét és a „C” MAC címét egy ARP válaszban. 2. A „B” gépnek elküldjük az „A” IP címét és a „C” MAC címét egy ARP válaszban. 3. Innentől minden „A” és „B” közötti kommunikáció „C” felé megy. A „C” gépen ezért mindkét irányú kommunikációt tovább kell adni a másik oldalnak, hogy „A” és „B” ne vegye észre a ténykedést. Ezt követően a „C” gép látja a teljes kommunikációt. Ráadásul ha az „A” gép a router, akkor a „B” gép teljes internet felé menő kommunikációját láthatjuk. Csak annyi a feladatunk, hogy a cache lejárta előtt rendszeresen megismételjük az ARP kommunikációt. Az ARP poisoning ellen védekezhetünk statikus ARP táblákkal, de ezeknek minden gépen való kezelése, adminisztrálása nehézkes lehet. A másik megoldás ha monitorozzuk a megszokottól eltérő ARP forgalmat, amikor a csomagban szereplő IP cím-MAC cím összerendelések nem egyeznek meg a korábban rögzítettel. 9.2.2.
Ettercap
Az ettercap csomag az előzőekben említett ARP poisoningot valósítja meg. MITM (Man in the Middle) támadóként beékelődik két gép közötti kommunikációba és monitorozza azt. Ezt a monitorozást lehetne a korábban ismertetett Wireshark programmal is végezni, azonban az Ettercap értelmezi is a kommunikációt és a nyíltan továbbított jelszavakat automatikusan kiszűri. Emellett további modulokkal egyéb értelmezéssel, vagy akár a kommunikációba történő beavatkozással is kiegészíthető. Az Ettercap parancssorból vagy grafikus felülettel használható. Rendszergazdaként kell indítanunk, hogy megfelelő hozzáférése legyen a hálózati interfészekhez. A grafikus felületet úgy érhetjük el, ha a programot a -G paraméterrel indítjuk.34 ettercap -G Első lépésként el kell indítani a sniffert. Válasszuk a Unified sniffing opciót. A megjelenő ablakban kiválaszthatjuk a hálózati interfészt, amelyen hallgatózunk. (Ha a lista üres, akkor a programot jó eséllyel nem rendszergazdaként indítottuk el.) 34 A
grafikus felület kissé instabil és néha apróbb bakikat is láthatunk rajta, de ettől függetlenül használható.
201
A Bridged sniffinget is választhatjuk abban az esetben, ha a gépünk két hálózati kártyával rendelkezik. Így az egyiket az egyik irányba, a másikat a másik irányba használja, vagyis nem feleződik a sávszélesség egy vonal dupla használata miatt és kevésbé feltűnő a jelenlétünk a szenvedő fél számára.
31. ábra. Sniffelés az Ettercap programmal Ezt követően fel kell derítenünk milyen gépek vannak a hálózatban. Használjuk a Hosts → Scan for hosts menüpontot. A folyamatjelző eltűnése után a találatok számát az alsó információs ablakrészben láthatjuk. Az eredményt a Hosts → Hosts list menüponttal érhetjük el. A hoszt listából válasszuk ki az egyik és a másik célpontot, amelyek közé beékelődünk. Indítsuk el a sniffelést: Start → Start sniffing. Innentől figyeljük és elemezzük a forgalmat. Célszerű talán ezzel kezdeni és csak utána bekapcsolni az ARP poisoningot, hogy már az első kommunikációt is lássuk. Ez után a Mitm → Arp poisoning menüponttal beindítjuk az elterelő ARP csomagok küldését. (Válasszuk ki a Sniff remote connections pontot, hogy lássuk ténylegesen a támadott felek kommunikációját.) Ennek hatásosságát az egyik megtámadott gép ARP táblájának megnézésével ellenőrizhetjük. A kommunikációt közben akár a korábban megismert Wireshark programmal is monitorozhatjuk ellenőrzés képpen. A rendszer az egyszerűbb, nyílt jelszavas autentikációkból könnyedén begyűjti a jelszavakat, de akár többre is képes. Ebből láthatjuk, hogy mennyire védtelenek vagyunk, ha nem használunk biztonságos protokollokat.
Megjegyzés Ne felejtsük el kilépés előtt a Mitm → Stop mitm attack(s) menüponttal leállítani az ARP poisoningot! Ennek hatására a program elküldi a helyes IP, MAC párosításokat, hogy a program és ezáltal a proxyzás végével ne szűnjön meg a kommunikáció a felek között.
9.2.3.
Aircrack-ng
A WLAN használatával újabb támadási felületeket nyithatunk meg, ha nem megfelelő technológiát választunk. A WLAN használatakor egyre erősödő sorrendben az alábbi titkosítások közül választhatunk: 202
• Open (nincs titkosítás); • WEP; • WPA/TKIP; • WPA2/AES-CCMP. Az autentikációs megoldások: PSK (Pre-shared key): Egy előre beállított és a felek közt megosztott kulcs. 802.1X rendszerű hitelesítés: Tényleges autentikáció, amikor a felhasználókat külön-külön azonosítja a rendszer. Léteznek még további védekezési próbálkozások, amelyekről rövidesen láthatjuk, hogy semmit sem érnek: • SSID rejtése; • MAC cím szűrés. A WLAN támadhatóság tesztelésére az aircrack-ng csomagot célszerű használnunk, amely tartalmaz minden főbb eszközt, amire szükségünk lehet. Parancs
Leírás
aircrack-ng
Kulcs törő (WEP, WPA-PSK)
airdecap-ng
WEP/WPA capture fájl dekóder
packetforge-ng
Csomagösszeállító
airdecloak-ng
Fake WEP csomagok eltávolítása a cap fájlból
airolib-ng
Létrehozza és menedzseli a WPA/WPA2 törésekhez létrehozott hash táblákat
aireplay-ng
Csomaginjekciós eszköz (Csomagismétléses támadásokhoz)
airodump-ng
WLAN csomag sniffer eszköz
airtun-ng
Virtuális interfész a WLAN forgalom dekódolásához és figyeléséhez
airmon-ng
Szkript a monitor mód be és kikapcsolásához
35. táblázat. Az aircrack-ng csomag elemei
9.2.3.1.
Az aircrack-ng alapszintű használata
Minden további művelethez először a WLAN adapterünket monitor módba kell kapcsolnunk. Egyes drivereknél ilyenkor nem a WLAN adapter kerül monitor módba, hanem létrejön egy virtuális interfész, amely monitor módban használható. 203
airmon-ng start wlan0 Ezt követően meg tudjuk vizsgálni milyen AP-kat és klienseket látunk. airodump-ng wlan0 Azonban ebben az esetben az adapter a csatornák (1–11) között váltogat. Belenéz egy egy csatorna kommunikációjába, így a tényleges kommunikációt csak nagy veszteséggel látja. Ezért ha megtaláltuk a vizsgálandó AP-t, akkor célszerű csak azt a csatornát figyelnünk. airodump-ng -c 1 wlan0 airodump-ng -c Le is menthetjük a teljes forgalmazást egy állományba, de valószínűleg célszerű szűrni egy AP-ra és a klienseire: airodump-ng -c 1 --bssid 00:ab:cd:ef:00:01 -w outfile wlan0 airodump-ng -c --bssid <AP MAC cím> -w Ha a WLAN nem használ titkosítást (Open), akkor az elmentett capture állományból a kommunikáció kinyerése csak egyetlen parancs. airdecap-ng outfile*.cap35 A dekódolt capture állomány például Wiresharkkal megnyitható, de akár az előbb tárgyalt Ettercapot is használhatjuk. Ha nem szeretnénk állományokkal bajlódni, akkor létrehozhatunk egy virtuális interfészt, amelyen már egyből a dekódolt információt láthatjuk egy monitorozó programmal. airtun-ng -a 00:ab:cd:ef:00:01 wlan0 airtun-ng -a <AP MAC cím> A létrejövő virtuális interfészt az ifconfig up paranccsal fel kell húznunk és már használhatjuk is. Felvetődhet a kérdés, hogy miért bajlódnánk ennyit, amikor egy nyílt hálózathoz nehézség nélkül csatlakozhatunk. Azonban ha megfigyeljük, akkor ezzel a módszerrel teljesen észrevétlenül monitorozhatjuk a kommunikációt. Vagyis ha titkosítatlan WLAN-t használunk, nem elég, hogy publikáljuk a teljes forgalmunkat, de még láthatatlan is marad aki lehallgatja. Célszerű mindezt fejben tartanunk, amikor a BME WLAN AP-it használjuk, amelyek szintén nyíltak. Így itt csak titkosított protokollokkal folytassunk kommunikációt! 35 Az
outfile*.cap az airodump-ng-vel készített capture állomány(ok).
204
9.2.3.2.
SSID rejtése
Gondolhatnánk, hogy az SSID elrejtésével az AP-nk rejtve marad és csak az tud csatlakozni hozzá, aki tudja a nevét. Ez tévedés. Bár az SSID rejtve van, a hosszúságát rendszeresen hirdeti az AP. (Ezt az airodump-ng kimenetén is láthatjuk.) Ez még csak kicsi biztonsági rés, azonban ha egy kliens csatlakozik az AP-hez, akkor az SSID nyíltan átmegy. Így ha eközben figyelünk az airodump-ng-vel akkor máris láthatjuk az AP azonosítóját. Vagyis ez a próbálkozás semmit sem ér. 9.2.3.3.
MAC szűrés
A következőkben láthatjuk, hogy a MAC szűrése semmit nem ér, ha a forgalmat akarjuk monitorozni. Mivel látjuk a kapcsolódott kliensek MAC címét így máris van egy listánk az engedélyezett MAC címekről. A saját MAC címünk átírása nem kihívás. Így már csak meg kell várnunk, amíg valamelyik klienst kikapcsolják és máris kapcsolódhatunk az AP-hez. 9.2.3.4.
WEP
A WEP az eddigi megoldásokhoz képest ad egy kis biztonságot, mert titkosítja a kommunikációt, és a titkosító kulcs használatával már korlátozza az AP-hez hozzáférni képes felhasználókat. Azonban a titkosítási algoritmus hibái miatt megfelelően sok csomag összegyűjtésével a titkosítás kulcsa feltörhető. A szükséges csomagszám a WEP kulcs méretétől függ. 64 bites WEP esetén, ami valójában csak 40 bites, értelem szerint jóval kevesebb csomagot kell összegyűjtenünk, mint 128 vagyis 104 bites WEP esetén. Ugyanakkor létezik algoritmus, amely a kommunikációban lévő ARP csomagokból statisztikai alapon jóval hamarabb meghatározza a kulcsot. Így egy 64 bites WEP kulcs feltöréséhez kevesebb mint tízezer csomag is elég lehet. Ha türelmesek vagyunk, akkor kivárhatjuk a szükséges csomagszámot, de egy injection támadással aktívan felgyorsíthatjuk az eseményeket. Bár a kommunikáció titkosított, de egy ARP csomagot a mérete alapján is jó eséllyel megismerünk benne. Egy ARP kérés csomagot visszainjektálva a kommunikációba generálhatunk egy újabb ARP válasz csomagot, sok kérés csomaggal pedig sok válasz csomagot. Így pillanatok alatt rengeteg csomagunk lehet. Ráadásul ezek ARP csomagok, és pont az kell a statisztikai töréshez. Így valójában egy WEP titkosítás feltörése a WLAN adapterünktől és kommunikáció minőségétől függően akár néhány perc alatt is megtörténhet, de rosszabb esetben sem tart sokáig. Ezért a WEP-et manapság ne alkalmazzuk sehol, mivel csak egy árnyalattal jobb, mint a titkosítatlan kommunikáció! A törés menete a következő: 1. Monitor mód bekapcsolása.
205
airmon-ng start wlan0 2. A WLAN AP-k felderítése. airodump-ng wlan0 majd airodump-ng -c 1 wlan0 airodump-ng -c 3. Injection teszt. aireplay-ng -9 -e apnev -a 00:ab:cd:ef:00:01 wlan0 aireplay-ng -9 -e <WLAN név> -a <AP MAC cím> 36 4. Capture. airodump-ng -c 1 --bssid 00:ab:cd:ef:00:01 -w outfile wlan0 airodump-ng -c --bssid <AP MAC cím> -w 5. Fake authentication. aireplay-ng -1 0 -e teddy -a 00:ab:cd:ef:00:01 -h 00:fe:ed:de:ad:01 wlan0 aireplay-ng -1 0 -e <WLAN név> -a <AP MAC cím> \ -h <saját hamis MAC cím> 37 6. Ijection. aireplay-ng -3 -b 00:ab:cd:ef:00:01 -h 00:fe:ed:de:ad:01 wlan0 aireplay-ng -3 -b <AP MAC cím> -h <saját MAC cím> 38 7. Törés.
-9 kapcsoló az injection teszt funkciót kapcsolja be. -1 kapcsoló az fake authentication funkciót kapcsolja be, míg a 0 az ismételt összerendelés idejét adja meg. 38 A -3 kapcsoló az ARP ismétléses támadást kapcsolja be. 36 A 37 A
206
aircrack-ng -b 00:ab:cd:ef:00:01 outfile*.cap A PTW metódus az alapértelmezett. Ez ARP csomagokat igényel, amelyből az előző ARP ismétléses támadás révén van elég. (Figyeljük, hogy ne a saját ismételt csomagjainkat próbáljuk törni!) A -K kapcsolóval a KoreK metódust kapcsolhatjuk be, ami bár lassabb, más, nem ARP csomagokkal is működik. 8. A mentett adatok dekódolása. airdecap-ng -w <WEP kulcs> outfile*.cap 9. Az eredmény megtekinthető Wiresharkkal, vagy más programmal. A virtuális interfészen keresztül valós időben is monitorozhatjuk a kommunikációt. airtun-ng -a 00:ab:cd:ef:00:01 -w 123456 wlan0 airtun-ng -a <AP MAC cím> -w <WEP kulcs>
9.2.3.5.
WPA/WPA2
A WPA-t azért fejlesztették ki, hogy a WPA2 megjelenéséig kiküszöbölje a WEP hibáit. Így egy firmware frissítéssel ismét biztonságossá tehető volt a kommunikáció. A WPA-ban megnövelték a kulcsokat, bevezették az automatikus kulcscserét, a kölcsönös autentikációval kiküszöbölték a hamis autentikációt, és további fejlesztésekkel is kiegészítették. Azonban ettől még nem lesz teljes a biztonság. A WPA-nak két módja van, az egyik a Pre-Shared Key-en alapuló WPA-PSK, a másik a 802.1X alapú. A Pre-Shared Key lényegében egy jelszó, és ezt a jelszót használja az összes felhasználó. Ez már magában rejti azt, hogy aki tudja a közös jelszót, az látja a kommunikációnkat. Másrészt az emberek nagy része hajlamos olyan egyszerű jelszavakat beállítani, amit egy szótár alapú támadással feltörhetünk. A 802.1X alapú rendszer a felhasználókat egyénileg azonosítja. Így a ma elérhető legnagyobb biztonságúnak tekintjük. Jelenleg nincs ellene hatékony törés. A WPA2 a WPA továbbfejlesztése, azonban a törés szempontjából a működése ugyanaz, mint a WPAé. Így a következő módszer mindkettőre igaz. A WPA-PSK törés lényege, hogy elkapjuk az autentikációs handshake-t, majd egy szótár alapján brute-force módszerrel megpróbálunk rájönni mi a kulcs. Ebben az esetben is aktívan gyorsíthatjuk az eseményeket. Deautentikációs csomagokat küldhetünk az APnek a kliens nevében. Ezzel a klienst ismételt autentikációra kényszeríthetjük és máris megvan a kívánt kommunikáció részlet. A törés menete a következő: 1. Bekapcsoljuk a monitor módot a használni kívánt interfészen. 2. Elindítjuk a handshake rögzítését:
207
airodump-ng -c 1 --bssid 00:ab:cd:ef:00:01 -w pskfile wlan0 airodump-ng -c --bssid <AP MAC cím> -w 3. Deautentikációs támadás a kliens ellen: aireplay-ng -0 1 -a 00:ab:cd:ef:00:01 -c 00:fe:ed:de:ad:02 wlan0 aireplay-ng -0 1 -a <AP MAC cím> \ -c 39 4. A kulcs törése: aircrack-ng -w password.lst -b 00:ab:cd:ef:00:01 pskfile*.cap aircrack-ng -w <jelszó fájl> -b <AP MAC cím> A John The Ripper használatával: john --stdout | aircrack-ng -b 00:ab:cd:ef:00:01 -w - pskfile*.cap
9.2.3.6.
Összegzés
Létezik biztonságos WLAN kommunikáció. A WPA2-PSK használatával elégséges biztonsági szintet érhetünk el, ha olyan jelszót választunk, amit szótártámadással nem tudnak feltörni. Egyszerű brute-force módszerrel pedig záros határidőn belül nem tudnak feltörni. Vagyis kellően hosszú (legalább 15 karakter) és a szokásos jelszóadási normáknak megfelelő. Azért számítsunk arra, hogy ha a kommunikációnkra nagyon kíváncsi valaki, akkor jelszótörő szerverfarmokkal sok mindenre képes. A WPA2 a 802.1X technológiával (EAP-PEAP) jelenleg megfelelő biztonságot nyújt, így bátran használhatjuk. (Persze ezzel párhuzamosan meg kell akadályoznunk, hogy a dolgozók saját AP-kat üzemeltessenek, esetleg a laptopjukat ad-hoc hálózatokon keresztül publikálják.)
9.3.
Certificate Authority
Több eddig tárgyalt szolgáltatásnál is felmerült a probléma, hogy protokolljuk nyíltan továbbít kényes információkat. Hogy mégis biztonságossá tegyük ezeket a szolgáltatásokat a kommunikációt kiegészítettük egy SSL titkosító réteggel. Az SSL protokollt a Netscape fejlesztette ki a webszerver és böngészők közötti biztonságos adatátvitelre, illetve a kommunikáció mindkét résztvevőjének azonosítására. A kapcsolat felépítése a következő módon zajlik: 39 A
-0 kapcsoló a deautentikációs támadást kapcsolja be, utána kell megadnunk a deauth csomagok számát.
208
1. A böngésző egy titkos oldalra hivatkozik. 2. A webszerver elküldi a publikus kulcsát a tanúsítványával együtt. 3. A böngésző ellenőrzi, hogy a tanúsítványt aláírta-e egy tanúsítványkiadó szervezet (CA vagy Certificate Authority), érvényes-e és ténylegesen a webszerveré. 4. A böngésző generál egy szimmetrikus kulcsot, amelyet lekódol a szerver publikus kulcsával, majd elküldi. Illetve továbbítja a szimmetrikus kulccsal kódolt URL-t és adatokat. 5. A szerver a privát kulcsával kikódolja a szimmetrikus kulcsot, majd azzal feldolgozza a kódolt URL-t és az adatokat. 6. A szerver visszaküldi az oldalt a szimmetrikus kulccsal titkosítva. 7. A böngésző dekódolja az információkat és megjeleníti. Az algoritmus egyik eleme az aszimmetrikus nyilvános kulcsú titkosítás. Ehhez a tanúsítvány összeállításakor le kell generálnunk egy publikus-privát kulcspárt, amivel a kezdő titkosítást elvégezhetjük. Ahhoz hogy megállapíthassuk, hogy tényleg azzal beszélgetünk, akivel akartunk szükséges, hogy az valamilyen módon azonosítsa magát. Hogy valakiben egyértelműen megbízzunk meg kell szereznünk tőle valamilyen biztonságos módon a tanúsítványát, és el kell helyeznünk a böngésző listájában. Ezt a szoftvergyártók elvégezték helyettünk, így a böngészők már telepítéskor tartalmazzák a gyökér tanúsítvány kiadók (root CA) adatait. Természetesen az összes létező szerver tanúsítványát nem gyűjthetjük be. De erre nincs is szükségünk. Elég ha az általunk megbízhatónak tartott tanúsítványkiadók megvizsgálják a kérelmező adatainak érvényességét és titkos kulcsukkal aláírják azt. Ezáltal igazolják számunkra a személyazonosságát, illetve aláírásukkal biztosítják, hogy utólag senki nem piszkálhatott bele. 9.3.1.
A valós élet
A valós életben, amikor az SSL protokollt használjuk valamely kommunikáció biztonságossá tételére, akkor többnyire a titkosítás az elsődleges célunk és a másik fél azonosítása nem kritikus. Ha tehetnénk a tanúsítványt el is hagynánk, de a protokoll mindenképpen igényli azt. Az egyik lehetőségünk, hogy szabályosan generálunk egy tanúsítvány kérelmet, amelyet elküldünk a tanúsítványkiadó szervezethez, hogy aláírásával hitelesítse azt. Azonban ezt nem ússzuk meg ingyen. Így a mindennapok jelentőségéhez mérten inkább elhagyjuk ezt a lépést. A másik lehetőségünk, hogy generálunk egy tanúsítványt, amit saját magunk írunk alá (self-signed certificate). Természetesen ebben az esetben a tanúsítvány szabálytalannak minősül, így a böngésző, vagy egyéb kliens felhívja erre a figyelmünket, egészen addig, amíg el nem helyezzük a megbízható tanúsítványok listájában. Azonban egy szervezetnél, mint például egy tanszék, több szerver is található, így minden egyes tanúsítvány felvétele nem elhanyagolható feladat. Sokkal egyszerűbb megoldás egy saját CA létrehozása. Ezek után elegendő a CA tanúsítványát felvenni a gépekre, és így minden általa aláírt tanúsítványt hitelesnek fogadnak el. A következőkben a CA létrehozásának és használatának lépéseit vizsgáljuk meg. 209
9.3.2.
OpenSSL
Az SSL titkosítás megvalósítására és a tanúsítványok kezelésére az OpenSSL csomagot használhatjuk. Ez a csomag manapság minden disztribúciónak a része, de a könyvtárak elhelyezkedése eltérő lehet. Fedora alatt az OpenSSL konfigurációs fájlja az /etc/pki/tls/openssl.cnf, míg Ubuntun az /etc/ssl/openssl.cnf. 9.3.3.
Az openssl.cnf állomány
Célszerű használat előtt a csomag konfigurációs állományát átnéznünk. Többnyire az állítgatások a CA könyvtár megadására és az adminisztratív információk alapértelmezett értékeinek megadására korlátozódnak. Ezzel csökkenthetjük a begépelendő adatmennyiséget az egyes tanúsítványok létrehozásánál. 9.3.4.
A CA segédprogram
A misc könyvtárban találhatunk egy CA szkriptet amely az egyes műveleteknél nagy segítségünkre lehet. A program használata révén megúszhatjuk az openssl program fáradtságos paraméterezését. Használata előtt célszerű a szkript elején lévő beállításokat átnézni és szükség szerint módosítani. Például hasznos lehet a tanúsítványok érvényességi idejének átírása 365 napról 3650 napra. Így elkerülhetjük, hogy minden évben új tanúsítványokat kelljen kiadnunk. 9.3.5.
A Certificate Authority létrehozása
Az első lépés a CA rendszerünk létrehozása. Ez egyrészt a tanúsítványok, és egyéb adatok kezeléséhez szükséges könyvtárstruktúra felépítését foglalja magában, másrészt a tanúsítvány kiadónk tanúsítványának létrehozását is. Ezt a következő paranccsal tehetjük meg legegyszerűbben: CA -newca A root CA-nk tanúsítványát a következő parancsok valamelyikével is létrehozhatjuk: CA -newcert openssl req -new -x509 -keyout private/cakey.pem -out cacert.pem -days 3650 A tanúsítvány létrehozásakor a kulcsok legenerálása után meg kell adnunk egy jelszót. Ezt fontos megjegyeznünk (mint általában a jelszavakat), mivel ez teszi lehetővé számunkra, hogy a titkos kulcsot használhassuk, és ez által aláírhassuk a tanúsítványokat. Majd meg kell adnunk a szervezetünket jellemző adminisztratív információkat, amelyek majd a tanúsítványban szerepelnek. Eredményképpen a CA könyvtárban létrejön egy tanúsítvány az adatainkkal, publikus kulcsunkkal, és a privát kulcsunkkal aláírva. Az egyes kliens gépeken ezt a tanúsítványt kell telepítenünk. A private könyvtárban pedig a privát kulcsunkat találhatjuk meg. Erre értelemszerűen vigyáznunk kell, mert ha valakinek a kezébe kerül, akkor bármilyen tanúsítványt aláírhat.
210
9.3.6.
A tanúsítvány lecsupaszítása
Bár az előállított tanúsítvány csak a bináris CERTIFICATE szekciót tartalmazza, de egyéb esetben találkozhatunk olyan tanúsítvánnyal is, amely a szöveges információkat is magában hordozza. Ilyenkor vagy szövegszerkesztővel, vagy a következő paranccsal csupaszíthatjuk le: openssl x509 -in cacert.pem -out cacert.crt Majd ezt a tanúsítványt publikálhatjuk és tölthetjük le az egyes kliensekbe. 9.3.7.
A szöveges információk megtekintése
Amikor a bináris tanúsítványban tárolt információkra vagyunk kíváncsiak, akkor azt a következő paranccsal tekinthetjük azt meg: openssl x509 -in cacert.pem -noout -text
9.3.8.
Tanúsítványok létrehozása és aláírása
Miután létrehoztuk a CA rendszerünket a következő lépés, hogy az egyes szervergépeinknek tanúsítványokat generáljunk. Ha ez a szerver egy Linux, akkor ezt a következő paranccsal tehetjük meg: CA -newreq Ez valójában az alábbi parancsot hívja meg: openssl req -new -keyout newreq.pem -out newreq.pem -days 3650 Az előálló newreq.pem állomány tartalmazza a tanúsítvány kérésünket, amelyet át kell küldenünk a CA-nak. Azonban mivel a privát kulcsunkat is tartalmazza, ezért ha nem mi vagyunk a CA, akkor ezt a részt távolítsuk el, az aláíráshoz nem szükséges. A CA feladata, hogy az adatok áttekintése után ezt aláírja. Ezt a következő paranccsal tehetjük meg legegyszerűbben: CA -sign A parancs azt igényli, hogy a könyvtárban newreq.pem néven szerepeljen a kérelem. Az aláírt tanúsítvány pedig newcert.pem néven áll elő. Ennek legenerálása során először meg kell adnunk a CA titkos kulcsának jelszavát, és nyugtáznunk kell a lépéseket. A lépések eredményeként a newkey.pem állomány tartalmazza a privát kulcsunkat (PRIVATE KEY szekció), a newcert.pem pedig az aláírt tanúsítványt (CERTIFICATE szekció). Ha gondoljuk el is távolíthatjuk az állományokban lévő többi információt. Majd ezeket az állományokat állítjuk be az egyes szolgáltatások certificate és key paramétereiben. 9.3.9.
A jelszó eltávolítása
Ahhoz, hogy a szolgáltatásaink használni tudják a privát kulcsunkat, el kell távolítanunk belőle a jelszót. (Ellenkező esetben minden alkalommal, amikor a szolgáltatás elindul, meg kellene adnunk a jelszót.) 211
A védelmet a következő paranccsal távolíthatjuk el: openssl rsa -in newkey.pem -out unsecure.pem Természetesen ezután még inkább vigyáznunk kell a privát kulcsunkra, ezért nagyon figyeljünk a jogosultságok beállításánál! 9.3.10.
A tanúsítvány visszavonása
Esetünkben a tanúsítvány visszavonása ritkán előforduló feladat. Leginkább a lejárt tanúsítványok megújításakor, vagy az elveszett privát kulcsok lecserélésekor van rá szükség. A tanúsítvány visszavonásához szükségünk van magára a tanúsítványra, majd a következő paranccsal elvégezhetjük a műveletet: openssl ca -revoke newcert.pem Ha a visszavonás után publikálni szeretnénk a CA-nk visszavonási listáját (CRL vagy Certificate Revocation List), akkor azt először le kell generálnunk. openssl ca -gencrl -out crl/my.crl
9.3.11.
A tanúsítvány megújítása
A lejárt tanúsítvány megújításakor első lépésként vissza kell vonnunk az aktuálisat, majd pedig aláírnunk az új kérelmét. Az aláírást végezhetjük kézzel is, ha biztosak akarunk lenni benne, hogy a kezdet és a lejárat dátuma korrekt lesz. openssl ca -policy policy_anything -out newcert.pem -infiles newreq.pem \ -startdate -enddate
212
10.
Tűzfalak
A fejezethez tartozó jegyzet megtalálható a tantárgy honlapján. [12]
213
11.
Naplófeldolgozás
A fejezethez tartozó jegyzet megtalálható a tantárgy honlapján. [12]
214
12.
PAM, DNS, DHCP
12.1.
PAM
A felhasználó azonosítása, vagyis az autentikáció számos szolgáltatás részét képezi. Régen minden programnak megvolt a saját metódusa ennek elvégzésére, azonban beláthatjuk, hogy ez nem célszerű megoldás. Sokkal logikusabb egy központi autentikációs rendszer létrehozása, amelyet az egyes szolgáltatások felhasználhatnak. Ezt a központi rendszert alkotja a PAM (Pluggable Authentication Modules). Ahogy a nevében is szerepel a rendszer moduláris felépítésű. Nézzük, milyen előnyökkel jár a használata: • Nem szükséges minden szolgáltatásban külön leimplementálni az autentikációt. • A központi megvalósítás az összes szolgáltatásra vonatkozóan lehetővé teszi az egységes adminisztrálást. • A moduláris architektúrából adódóan az adminisztrátor és a fejlesztők kezébe egy flexibilis, bővíthető eszközt ad. 12.1.1.
Konfigurációs állományok
Az összes PAM rendszert használó szolgáltatás rendelkezik egy konfigurációs állománnyal az /etc/pam.d könyvtárban, melynek neve megegyezik a szolgáltatás nevével (a szolgáltatás által definiált név). Ezeket a konfigurációs állományokat a szolgáltatások csomagjai telepítik. Ugyanakkor a konfigurációban hivatkozhatunk más állományokra is (a pam_stack.so modul segítségével) így közös konfigurációs részeket is létrehozhatunk. (Pl. a system-auth állomány.) 12.1.2.
A konfigurációs állományok szintaktikája
A konfigurációs állományok a következő sorokból állnak. <modul interfész> <modul név> <modul argumentumok> Az interfész a következő értékeket tartalmazhatja: auth: Ez az interfész valósítja meg az autentikációt. account: Ez az interfész ellenőrzi, hogy az adott felhasználó beléphet-e. Vagyis figyeli az account lejáratát és hozzáférési tiltásait. password: Ez az interfész beállítja és ellenőrzi a jelszót. session: Ez az interfész konfigurálja és menedzseli a felhasználói viszonylatot. Például szükség esetén felcsatolhatja a felhasználó home könyvtárát. A control flag megértéséhez a konfigurációs állományok még egy tulajdonságát meg kell említenünk. Mégpedig, hogy egy interfészre több sort, ezáltal több ellenőrzést is megadhatunk, amelyek így egy szekvenciális listát alkotnak. Azt hogy az egyes sorok mennyire kritikusak az adott művelet szempontjából a control flag értéke adja meg: 215
required: Az adott modulnak sikeresen kell visszatérnie ahhoz, hogy a metódus folytatódjon. Hibás visszatérési érték esetén nem kap a felhasználó azonnali értesítést, csak egyben a többi modullal együtt. requisite: Az adott modulnak sikeresen kell visszatérnie a metódus folytatásához. Azonban hibás visszatérési érték esetén a felhasználó azonnal értesül az eredményről. sufficient: Ha az adott modul sikeresen tér vissza, az a metódus szempontjából elégséges. Vagyis, ha korábban required sor nem tért vissza hibával, akkor a metódus sikeres. Hibás visszatérési érték esetén figyelmen kívül hagyja a sort. optional: A modul visszatérési értékét csak akkor veszi figyelembe a rendszer, ha nincs semmilyen más modul beállítva az adott interfészre. A modul neve az adott modul állománynevét jelenti. Ezek az állományok a /lib/security könyvtárban találhatóak. Az egyes modulok igényelhetnek további argumentumokat a működésükhöz. Ez az adott modul függvénye. A modulok leírását Fedora disztribúciókon az /usr/share/doc/pam-/txts könyvtárban találjuk, míg Ubuntun a man pam_<modul> parancs kiadásával kapjuk meg. 12.1.3.
Példa konfigurációs állomány
Feladat Nézzük meg az /etc/pam.d/login és system-auth állományokat! #%PAM-1.0 auth
required
pam_securetty.so
auth
required
pam_stack.so service=system-auth
auth
required
pam_nologin.so
account
required
pam_stack.so service=system-auth
password
required
pam_stack.so service=system-auth
session
required
pam_selinux.so multiple
session
required
pam_stack.so service=system-auth
session
optional
pam_console.so
Az első sor komment. A következő három sor az autentikációs folyamat leírására szolgál. auth
required
pam_securetty.so
Ez a sor gondoskodik arról, hogy a root csak az /etc/securetty állományban felsorolt biztonságos terminálokról léphessen be. auth
required
pam_stack.so service=system-auth
216
A pam_stack.so modul rekurzív stackelést tesz lehetővé. Megvizsgálja a megadott állománynak az interfészre vonatkozó részeit és csak akkor tér vissza sikeresen, ha azokat végre tudta hajtani. Vagyis esetünkben a system-auth állománynak az auth interfészre vonatkozó részeit vizsgálja meg. auth
required
/lib/security/$ISA/pam_env.so
auth
sufficient
/lib/security/$ISA/pam_unix.so likeauth nullok
auth
required
/lib/security/$ISA/pam_deny.so
Az első sor az /etc/security/pam_env.conf konfigurációs állomány alapján beállítja a környezeti változókat. A második sor a szokásos jelszóállományos autentikációt valósítja meg. Mint látjuk az autentikáció szempontjából elégséges, ha ez a sor sikeres. Ha a Unix autentikáció nem volt sikeres, akkor a pam_deny.so modul megakadályozza a belépést. auth
required
pam_nologin.so
Ez a sor megvizsgálja, hogy az /etc/nologin állomány létezik-e. Ha létezik, akkor csak a root felhasználónak engedi a belépést, a többieknek visszaadja az állomány tartalmát. Ezzel megvalósult az autentikáció. Az account használatának szabályaira vonatkozik a következő sor. account
required
pam_stack.so service=system-auth
Ez csak egyszerűen használja a system-auth állomány idevonatkozó részeit. account
required
/lib/security/$ISA/pam_unix.so
account
sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account
required
/lib/security/$ISA/pam_permit.so
Az első sor az /etc/shadow állományban megadott account beállításoknak szerez érvényt. A következő sor gondoskodik arról, hogy a rendszer account-ok mindig éljenek. Az utolsó sor pedig mindig igaz értéket kap. Ezzel leellenőriztük a felhasználói belépési jogosultságokat. A következő sor a jelszó beállítására vonatkozik, ami szintén a system-auth állományra hivatkozik. password
required
pam_stack.so service=system-auth
password
requisite
/lib/security/$ISA/pam_cracklib.so retry=3
password
sufficient
/lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password
required
/lib/security/$ISA/pam_deny.so
Az első sor ellenőrzi, hogy a jelszó elég erős-e. Ha a felhasználó nem választ megfelelő jelszót, akkor ezzel véget is ér a folyamat. (A felhasználó háromszor próbálkozhat.) A második sor végrehajtja a jelszó módosítását. MD5-ös kódolású shadow jelszót használ, ahogy a paraméterekből látható. A nullok lehetővé teszi, hogy az üres jelszót másra módosítsuk. Ellenkező esetben blokkolná a felhasználót. A use_authok paraméter azért szükséges, mert a jelszót a korábbi
217
pam_cracklib.so modul kérte be a felhasználótól. Ez a modul így már nem ad promptot, csak felhasználja, amit kap. Ha a második sor nem járna sikerrel, akkor az utolsó sor már mindenképpen hibát ad vissza. Ezzel ledefiniáltuk a jelszó állítás lépéseit. Az utolsó interfész a felhasználói viszonylatra vonatkozik. session
required
pam_selinux.so multiple
Ez a sor az SELinux mechanizmus része, amely lehetővé teszi a felhasználó jogainak finomabb hangolását az /etc/security/selinu könyvtárban található konfigurációs állományok segítségével. session
required
pam_stack.so service=system-auth
Ez a sor megint a system-auth állomány idevonatkozó sorait hajtja végre. session
required
/lib/security/$ISA/pam_limits.so
session
required
/lib/security/$ISA/pam_unix.so
Az első sor az /etc/security/limits.conf konfigurációs állomány alapján beállítja a limitértékeket az adott felhasználói viszonylatra. A második sor a Unix jellegű logolásokról gondoskodik. Az utolsó sor a konzol jogosultságok beállítására szolgál. session
12.1.4.
optional
pam_console.so
Konzol jogosultságok
A Linux eredetileg szerver operációs rendszernek számított, azonban egyre inkább használják munkaállomásként is. Azonban hogy ebben a feladatkörben is kényelmes legyen a rendszer használata, a konzolra bejelentkező felhasználónak többletjogokat kell adnunk, hogy hozzáférhessen a perifériákhoz. Ezt a funkciót a pam_console.so modul teszi lehetővé. Amikor a felhasználó bejelentkezik a konzolon, akkor a modul a tulajdonába ad olyan lokális eszközöket, amelyek eredetileg csak a rendszergazda kezelhet. Ilyenek lehetnek a CD meghajtó, a floppy, hangkártya, USB eszközök stb. Ezeket a beállításokat az /etc/security/console.perms állományban adhatjuk meg. Itt megnevezhetjük az egyes eszközcsoportokat, majd megadhatjuk rá a beállítandó, illetve az eredeti jogosultságokat (amire majd kilépéskor visszaállítja). Azonban a konzolt használó számára az eszközök elérhetősége még nem minden. Egyes programokhoz is elérést kell nyújtanunk, hogy teljes értékűen használhassa munkaállomásként a rendszerét. Ezeket a programokat az /etc/security/console.apps könyvtárban adhatjuk meg egy, a program nevével egyező konfigurációs állománnyal. 12.1.5.
További beállítások
Ha megnézzük az /etc/security könyvtár tartalmát, akkor az eddig említetteken kívül más konfigurációs állományokat is találhatunk az telepített modulok függvényében. Ilyenek lehetnek a limits.conf, amellyel felhasználókra, csoportokra megadhatjuk a limit beállításokat, vagy a time.conf, amellyel a belépési időket korlátozhatjuk. 218
12.2.
DNS
12.2.1.
A DNS feladata
A DNS (Domain Name System) feladata, hogy a hálózaton lévő számítógépek számára kijelölt neveket IP címre fordítsa, illetve az IP címeket nevekre fordítsa. Ezen funkciónak a felhasználó számára teljesen „átlátszónak” kell lennie. Azt a műveletet, amikor egy hálózati nevet (pl. www.aut.bme.hu) IP címre fordítunk, feloldásnak hívjuk (angolul: name resolving, mapping). Azt a műveletet, amikor egy IP címet hosztnévre fordítunk magyarul csak körbeírni tudjuk: visszafelé feloldás (angolul: reverse mapping). A domain név-tartomány szerkezete a fastruktúrát követi. A fa leveleit és elágazásait címkéknek nevezzük (labels). Egy teljes objektum domainneve címkék láncolatából áll. A címke karakterláncolat (alfanumerikus, az egyetlen megengedett speciális karakter a „-”), legalább 1 és legfeljebb 63 karakter hosszú, betűvel kell kezdődnie, és nem végződhet „-”-lel. [13] A domainnevet alkotó címkék egy-egy ponttal vannak egymástól elválasztva. A domain nevet ponttal zárjuk le (a leghátsó pontot általában elhagyjuk, de hivatalosan az is része a teljes domain névnek). Egy hibátlan teljes domain név (Fully Qualified Domain Name) például a www.wikipedia.com. (az utolsó pont is a domain-névhez tartozik). A domain név az őt alkotó összes ponttal együtt legfeljebb 255 karakterből állhat, mindig jobbról balra olvassuk, és így és oldjuk fel IP címre. Ez azt is jelenti, hogy minél jobbrább áll egy címke, annál feljebb áll a fastruktúrában. A domain név jobb szélén álló pont választja el a címkét az első hierarchiai szinttől, a gyökértől (angolul root). Ez az első szintet TLD-nek (Top-Level Domain) nevezik. Top-level domain name (TLD): Ezek a hálózati név hierarchiában a legfelső helyen álló, gyökér domainnevek. (Pl.: .hu, .com, .net, .org, .tw, .it stb.) Domainnevek, tehát a TLD-k alatt álló névrészletekkel együtt vett nevek (pl. aut.bme.hu, debian.org stb.). Host name: A domain névhez ragasztott név azonosít egy adott gépet. (pl. www.aut.bme.hu). Egy IP címhez akárhány hoszt- vagy domainnevet rendelhetünk, és egy hosztnévhez akár több IP címet is visszakaphatunk a DNS-ből. Egy adott domain DNS-objektumait (a neveket) úgynevezett erőforrás-rekordként (Resource Record, RR) tároljuk a zónafájlban (zone file), és ez egy vagy több névszerveren (name server) lehet megtalálható. 12.2.2.
Helyi feloldás
Ahhoz, hogy a DNS működjön, először bizonyos helyi szabályokat kell meghatároznunk, hogy mit milyen sorrendben, és honnan kérdezzünk le. A névszolgáltatások lekérdezésének sorrendjét az /etc/nsswitch.conf fájl két sora adja meg. hosts: files dns networks: files dns A files beállítás az /etc/hosts állomány használatát jelenti. Ebben az állományban felsorolhatunk IP cím-név összerendeléseket. Azonban ha csak ezt használnánk névfeloldásra, az nagyon megnehezítené a 219
gépek adminisztrációját. Ezért ez a fájl csak a localhost bejegyzéseket szokta tartalmazni. Ha a helyi fájlokban nem található meg a kért hosztnévhez tartozó IP cím, egy DNS szerverhez kell fordulni. Az /etc/resolv.conf nevű fájl határozza meg a feloldás sorrendjét. search aut.bme.hu bme.hu nameserver 152.66.70.4 nameserver 152.66.116.1 A search sorba írt domainnevekkel egészíti ki a rendszer a domain név nélkül beírt hosztneveket. A nameserver sorokban adhatjuk meg a DNS szerverek IP címeit, az első sorban megadott lesz az elsődleges. 12.2.3.
A névfeloldás folyamata
Vegyünk egy egyszerű esetet. Otthoni internetes kapcsolatunkkal felkeressük a www.aut.bme.hu gépet. Az otthoni bejegyzett DNS szerverünk (pl. a 202.101.192.1). A kérésünket, hogy oldja fel a www.aut.bme.hu nevet és adjon vissza egy IP címet a beállított DNS szerver megkapja (a TCP és UDP protokollok 53-as portján). Mivel ez a szerver nem ismeri ezt a domaint, először lekérdezi a TLD szervertől, hogy ki a felelős a .hu feloldásáért. Majd erre a TLD válaszol hogy a .hu domainért az NIIF szervere felel. Ezután az általunk használt névfeloldó szerver megkérdezi az NIIF szerverétől, hogy ki felel a bme.hu domain feloldásáért. Az NIIF szerver választ ad, hogy a bme.hu-t az ns.bme.hu (152.66.116.1), a nic.bme.hu (152.66.115.1) és az ns2.pantel.net (212.24.160.1) kezeli. Ezután a DNS szerverünk kapcsolatba lép az ns.bme.hu szerverrel (ha nem elérhető, akkor a többivel) és lekérdezni az aut.bme.hu domain kezelő szerverét. Megkapja, hogy az ns.aut.bme.hu, az ns2.aut.bme.hu, és a nic.bme.hu a névfeloldásért felelős szerverek. Ezt követően a DNS szerverünk lekéri az ns.aut.bme.hu-tól a www.aut.bme.hu-hoz tartozó IP címet (152.66.188.11). Így kapjuk meg a keresett IP címet. A névfeloldó szerver ezek után eltárolja a domain, IP párost a cache-be, hogy az esetleges újra lekérdezés gyorsabban történjen, illetve hogy visszaadja nekünk. 12.2.4.
BIND konfiguráció
Ahhoz, hogy a DNS szerverünk tudja, egy adott TLD feloldásához hová kell fordulni, meg kell adnunk neki az ún. root DNS szerverek IP címeit. A root DNS szerverek hatalmas teljesítményű gépeken futó DNS szerverek, melyek az internet fő gerincvonalain ülve a TLD-k feloldását végzik. Tizenhárom gyökérszerver van (A-tól M-ig jelölve). Természetesen ezeket az IP címeket nem kell tudnunk fejből, le lehet tölteni egy megfelelő fájl formájában pl. az ftp.rs.internic.net címről. A fájl neve named.root. Ezt a fájlt Fedorán az /etc/named alkönyvtárba kell named.ca néven elhelyezni, míg Ubuntun az /etc/bind alkönyvtárba db.root néven kell elhelyezni. A BIND alapkonfigurációs fájlja Fedorán az /etc/named.conf, míg Ubuntun az /etc/bind/named.conf. options { directory "/var/named"; version "4.4.4"; };
220
controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; }; }; key "rndckey" { algorithm hmac-md5; secret "secrethash"; }; zone "." { type hint; file "named.ca"; }; zone "0.0.127.in-addr.arpa" { type master; file "named.local"; }; Az options részben a directory kulcsszó megadja, hogy melyik alkönyvtár legyen a named alapértelmezett gyökér könyvtára, innen indul ki minden további elérési út, melyet megadunk. A version paraméterrel egy hamis verziószám megadása csak egy ajánlott egyszerű trükk. Megnehezíti a betörők dolgát, ha egy hamis rég elavult verziószámot hazudunk, mivel nem valószínű, hogy van az adott verzióhoz exploit40 , és ráadásul az nem is fog működni. A controls megadja az rndc szoftverrel való kapcsolat módját, ahol az allow kulcsszó azokat a gépeket jelenti, ahonnan a DNS szerver adminisztrálható (jelen esetben a változtatás csak helyileg lehetséges). A keys megadja, hogy lesz egy titkosítási kulcsunk, melyet a keys részben meg is adunk. Ennek a kulcsnak egyeznie kell azzal a kulccsal, amelyet az adminisztrációs gép /etc/rndc.conf fájljában megadtunk. Ezután következik a root zóna megadása (zóna = domain), melyben a fentiekben említett named.ca, illetve db.root fájl elérési útját kell megadni. A root zóna után meg kell adnunk a saját zónánkat leíró konfigurációs fájlokat, esetünkben ebből egy van, ez Fedorán az /etc/named/named.localhost, míg Ubuntun az /etc/bind/db.local fájl. Egy helyi zónaleíró fájlra mindenképpen szükség van, ennek alakja a következőképpen néz ki (cachingonly DNS esetén). $TTL 3D @ IN SOA localhost. root.localhost. ( 1 ; Serial 8H ; Refresh 4H ; Retry 40 Az exploit informatikai biztonsági fogalom: olyan forráskódban terjesztett vagy bináris program, adathalmaz vagy parancssorozat, amely alkalmas egy szoftver vagy hardver biztonsági résének, illetve hibájának kihasználására, így érve el a rendszer tervezője által nem várt viselkedést.
221
4W ; Expire 1D) ; Minimum TTL NS localhost. 1 PTR localhost. Az első sor a TTL (time to live) értékét adja meg három napban, amely azt jelenti, hogy ez a fájl három nap alatt elévül. A második sorban az ns.linux.bogus a gépünk nevét jelenti, a root.linux.bogus pedig a gép adminisztrátorát. Az NS sor adja meg a domain DNS szerverének nevét, esetünkben ez ugyanaz, mint a második sorban lévő név. (Az utána álló pont fontos, mert így azt lezárja, és nem egészíti ki további DNS utótagokkal.) Az utolsó sor megadja, hogy a (127.0.0).1 gép neve localhost.(linux.bogus). Ahhoz, hogy a gépünkön lévő szoftverek a lokális DNS szervertől kérjék a nevek feloldását, meg kell adnunk a resolv.conf fájlban a következőket. search localnet nameserver 127.0.0.1 Ezután már csak el kell indítanunk a DNS szervert, azaz a named programot. root@ns:/# named -U daemon Az -U daemon paraméter azt jelenti, hogy a named daemon felhasználónév alatt fog futni, nem root jogosultságokkal, erre biztonsági megfontolásokból van szükség. Egy egyszerű domain megvalósításához szükségünk van egy domain névre, amit szeretnénk ezzel kiszolgálni. Legyen ez a mynet.bme.hu domain. Ezután szükségünk van még egy IP tartományra, amit a hálózatcímmel és a netmaskkal adunk meg: 192.168.10.0/24 (másképp 192.168.10.0/255.255.255.0). Így már mindent tudunk, hogy megírjuk a named.conf fájlt. Először is, szükség van arra, hogy a szerver lokális domainjét és saját nevét lekezeljük, ezt az előbb már megismertük a named.conf fájl beállításakor. zone "0.0.127.in-addr.arpa" { type master;} file "named.local"; }; Az in-addr.arpa egy speciális domain név, melynek segítségével egy gép nevét kérdezhetjük meg a DNS rendszertől, az IP cím ismeretében. A zone kulcsszó megadja, hogy mi lesz a zóna fájlunk esetében a gyökér domain, azaz innen ered a hierarchiánkban majd minden név. Ez tehát megmutatja, hogy a 127.0.0 domaint mi fogjuk kezelni, persze csak a saját hatáskörünkben. Lássuk az /etc/named/named.localhost fájl tartalmát! (Ubuntun az /etc/bind/db.local fájlt nézzük!) $TTL 3D @
IN SOA localhost. root.localhost. { 1 ; Serial 8H ; Refresh 4H ; Retry 4W ; Expire 222
1D) ; Minimum TTL NS localhost. 1
PTR localhost.
A localhost zóna mellett nézzük meg a beállításokat egy valós zónára. A named.conf beállítása. zone "mynet.bme.hu" { type master; file "mynet"; } Ezzel létrehoztunk egy új zónát, mely a mynet.bme.hu névre hallgat, és a hozzá tartozó zóna fájl az /etc/named/mynet, illetve /etc/bind/mynet melynek a tartalma a következő. $TTL 1D @
IN SOA ns.mynet.bme.hu. root.mynet.bme.hu. ( 2010040101 8H 2H 1W 1D) NS
ns.mynet.bme.hu.
MX
10 mail.mynet.bme.hu.
$TTL 600 A
192.168.10.1
$TTL 1D MX
10 mail.mynet.bme.hu.
ns
CNAME mynet.bme.hu.
mail
A
192.168.10.2
MX
10 mail
MX
20 mail.bme.hu.
A
192.168.10.3
A
192.168.10.4
www
Egy zóna fájl három darab úgynevezett erőforrás rekordot tartalmaz, ezek: A SOA (Start Of Authority), az NS és az A rekordok. • A „@” az eredet rövidítése (mynet.bme.hu). • Az NS rekord megmutatja, hogy a mynet.bme.hu domainhez tartozó névszerver az ns.mynet.bme.hu gép. • Végül az A rekord megmutatja, hogy a domain név egyben a 192.168.10.1 IP című gép neve is.
223
A SOA rekorddal kell kezdődnie a DNS szerverben minden zóna fájlnak, ebben vannak az alapvető információk a DNS zónáról. Minden zóna fájlban csak egy darab lehet belőle. A SOA kulcsszó után meg kell adni a zóna nevét, majd az adminisztrátor email címét olyan formában, hogy a kukac (@) helyére is pontot írunk. Az ez alatti sorban lévő szám az úgynevezett sorozatszám (serial), amely általában egy dátumból és az az napi változások számából áll. Valójában arra van szükség, hogy ez a szám a változások során növekedjen, mert ebből a számból értesül a többi DNS szerver, hogy változtattunk a zónafájlon, és újból le kell tölteniük. A többi szám helyére (Refresh, Retry, Expire, Minimum TTL) írjuk a fent található számokat, ezek a biztonságos és szokásos értékek. A Refresh, Retry, Expire a másodlagos (kisegítő névfeloldó szervernek szóló információk), míg a minimum TTL egy elutasított kérés (pl. olyan domain név lekérdezése, amely nem szerepel a nyilvántartásban) elévülését jelenti. Az MX rekord az alapértelmezett levelező szervert adja meg a hálózatunkon. Az A rekordok mindegyike egy IP címet rendel egy hosztnévhez. Így érhetőek el a hosztnév alapján a zónafájlban megadott számítógépek. A CNAME rekord lényegében egy alias, ami egy másik gépnévre vagy IP címre mutat. 12.2.5.
A reverse DNS beállítása
A reverse DNS feladata, hogy IP címből visszaadja a gép nevet. Értelemszerűen egy IP címből csak egy gép nevet adhat vissza, annak ellenére is, hogy egy IP címre több név is mutathat. A reverse DNS feloldását az arpa TLD végzi. A feloldás menete az IP címet nézve visszafelé történik. Pl. a 192.168.10.0/24 tartományhoz tartozó zónafájlt megfordítva kell bejegyezni a named.conf -ba: 0/24.10.168.192.in-addr.arpa. A példánkban a named.conf fájlba bejegyeztük a mynet.rev zónafájlt. Ez a zónafájl felel a reverse DNS beállításokért. A mynet.rev fájl a következő elemekből áll. $TTL 1D @ IN SOA ns.mynet.bme.hu. root.mynet.bme.hu. ( 2010040101 28800 7200 604800 86400) NS
ns.mynet.bme.hu.
1
PTR
ns.aut.bme.hu.
2
PTR
mail.aut.bme.hu.
3
PTR
www.aut.bme.hu.
4
PTR
www.aut.bme.hu.
12.2.6.
BIND futtatása chroot környezetben
A BIND program gyakori betörési pont szokott lenni és ezért a biztonság kedvért célszerű chroot környezetben futtatni. Ezzel csökkenthető az olyan kártékony alkalmazások hozzáférése, amelyek a BIND biztonsági hibáit használják ki. 224
Chroot környezet alatt a chroot rendszerhívásra épülő leválasztott alrendszert értjük, amely állományrendszer szinten a külső rendszertől független futtatási környezetet alkot. Első lépésben egy külön felhasználó létrehozására lesz szükség (nem akarjuk a BIND-et root környezetben futtatni). Egy named nevű felhasználót hoztunk létre a BIND számára. A shellt /bin/false-ra állítjuk, mert ez a felhasználó sosem fog belépni. A következőkben ki kell alakítani a könyvtárszerkezetet. Ez bárhol helyet foglalhat a fájlrendszeren, de a következő a tipikus könyvtárlista. /var/named/chroot/ /var/named/chroot/etc /var/named/chroot/var /var/named/chroot/var/run /var/named/chroot/var/run/named /var/named/chroot/var/named /var/named/chroot/dev Az előzőekben beállított BIND meglévő named.conf fájlját és a zónafájlokat a chroot környezetbe kell másolni. A named.conf a /var/named/chroot/etc-be, a zónafájlok a /var/named/chroot/var/named könyvtárba mennek. BIND-nek írnia kell a /var/run/named könyvtár elemeit is, hogy ide tudja tárolni a pid - és statisztikai fájlokat. Ezért a chroot környezetben létrehozzuk a /var/named/chroot/var/run/named könyvtárat. A chrootban futó BIND nem fogja elérni a környezeten kívüli fájlokat, ezért még eszközállományokra is szükség van a /var/named/chroot/dev könyvtárban: null, random.
12.3.
DHCP
12.3.1.
A DCHP feladata
A DHCP szerver segítségével Ethernet cím alapján IP címeket lehet kiosztani dinamikus, vagy statikus módon. A kiosztás csak egy meghatározott időre szól, azután újra kell igényelni. Ez teljesen automatikusan zajlik, a felhasználó ebből nem vesz észre semmit. A szerver nem csak IP címek kiosztására szolgál, a hálózathoz tartozó beállításokat is képes átadni a kliens gépnek (hálózat cím, maszk, átjáró, DNS szerver). 12.3.2. A dhcpd
DCHP konfiguráció program konfigurációs fájlja Fedorán az /etc/dhcp/dhcpd.conf, míg Ubuntun az
/etc/dhcp3/dhcpd.conf. A maximális frissítési (bérleti) idő megadása lehetséges a max-lease-time, az alapbeállítás pedig a default-lease-time opcióval. Itt másodpercben kell megadni az időtartamokat. A leggyakrabban használt bejegyzések az option, subnet, host. Az option általános, illetve alhálózatra/gépre vonatkozóan adhat meg paramétereket. option domain-name "mynet.bme.hu"; option domain-name-servers 192.168.10.1; option routers 192.168.10.254;
225
Server (not selected)
Server (selected)
Client Begins initialization DHCPDISCOV ER
ER
DHCPDISCOV
Determines configuration
Determines configuration DHCPOFFER
DHCPOFFER
Collects replies Selects configuration DHCPREQUES
T DHCPREQUES
T
Commits configuration DHCPACK
Initialization complete
Graceful shutdown DHCPRELEASE
Discards lease 32. ábra. IP cím kiosztása DHCP-vel [14] option subnet-mask 255.255.255.0; default-lease-time 21600; max-lease-time 43200; 12.3.2.1.
Dinamikus host
A subnet egy alhálózaton belüli paramétereket határoz meg. A címek dinamikusan kerülnek kiosztásra, a range által megadott tartományokból. Itt is használható az option kulcsszó, ez az alhálózatra adja meg az opciókat, amennyiben nincs megadva ilyen, akkor az általános részben definiáltak kerülnek értelmezésre.
226
Az egyértelműség érdekében érdemes minden alhálózathoz megadni ezeket a paramétereket, amint az a példában is látható: subnet 192.168.10.0 netmask 255.255.255.0 { range 192.168.10.20 192.168.10.30; option broadcast-address 192.168.10.255; option routers 192.168.10.254; option domain-name servers 192.168.10.1; }
12.3.2.2.
Statikus hoszt
A host kulcsszóval egyetlen gépre vonatkozóan adhatjuk meg az IP címet, az átjárót, a DNS szervert. A hivatkozás Ethernet cím (MAC cím) alapján történik. host pc0 { hardware ethernet 00:40:04:AC:DC:0A; fixed-address 192.168.10.4 }
12.3.3.
A dhcpd indítása
A dhcpd megköveteli, hogy minden felkonfigurált interfészhez legyen a konfigurációs fájlban definíció. Ha nem kívánjuk az összes hálózaton elindítani a szolgáltatást, akkor is létre kell hozni mindegyikhez egy subnet hivatkozást, ám azt hagyjuk üresen, indításkor adjuk meg a kiszolgálandó interfészeket. A szervert a --help paraméterrel elindítva megkapjuk a lehetséges paramétereket: Usage: dhcpd [-p] [-d] [-f] [-cf config-file][-lf lease-file] [-pf pidfile] [if0 [... ifN] ] root@mynet:~# dhcpd -q eth0 Ekkor csak az eth0 -hoz tartozó hálózatokon tartózkodó gépeket fogja kiszolgálni a szerverünk. A kliens oldalon operációs rendszertől függően kell beállítani, hogy DHCP szervertől kapjunk IP címet.
227
13.
Verziókezelő rendszerek
A verziókezelő rendszerek eredeti célja a szoftverfejlesztés támogatása. Lehetővé teszik, hogy a szoftver forráskódján egyszerre több fejlesztő is dolgozhasson anélkül, hogy káosz lenne az eredmény. Másrészt megvalósítják a forráskód rendszeres archiválását és a különböző verziók előállítását. Az elosztott szoftverfejlesztés egyik fő problémája hogyan akadályozható meg, hogy az állományok párhuzamos szerkesztése előre nem látható eredményekhez, egymás módosításainak felülírásához vezessen. A központosított verziókezelő rendszerek két fő stratégiát alkalmaznak: zárolás (locking): A központi rendszer egyszerre csak egy fejlesztőnek engedi egy állomány írását. verzió egyesítés (merging): A módosításokat tárolja a rendszer és mind beleolvasztja az állományokba. Csak szöveges állományokkal működhet és egyes esetekben felhasználói beavatkozást igényel.
13.1.
CVS
Az első elterjedt verziókezelő rendszer a CVS (Concurrent Versions System) volt. A felépítése kliensszerver jellegű. A szerver tárolja a legfrissebb verziót és a módosítások listáját. A kliens a szerverből letöltheti a legfrissebb verziót, majd a módosításokat visszatöltheti a szerverre. A konfliktusok elkerülése végett a szerver csak a legfrissebb verzióhoz fogad el módosításokat. Vagyis a fejlesztőknek rendszeresen frissítenie kell, hogy minden állományból a legutolsó verzión végezzék a módosításokat. A CVS hátrányai: • Folyamatosan frissítenünk kell a szerverről a munka-másolatunkat. • A verziók állomány-módosításonként jönnek létre. • A forráskódok átszervezését nem támogatja. • A commit nem atomi, amiből konfliktusok keletkezhetnek.
13.2.
Subversion
A Subversion (SVN) verzió kezelő a CVS továbbfejlesztése. Hasonlóan a CVS-hez szintén egy központi szerverből és a hozzá kapcsolódó kliensekből épül fel, azonban kiküszöböli a CVS hibáit: • atomi commit-ok; • forráskód átszervezésének lehetősége; • állományok zárolása. Emellett támogatja a bináris állományok hatékony kezelését és sok egyéb optimalizációt is tartalmaz. 41 Állományok
zárolását alkalmazó módszer.
228
Saját munkamásolat készítése svn checkout
Saját munkamásolat frissítése svn update
Állomány létrehozása
fejlesztési ciklus
Állomány zárolása svn lock <állomány>
Állomány hozzáadása svn add <állomány>
Állomány szerkesztése
Változások feltöltése a szerverre svn commit -m "Leírás" 33. ábra. Munkafolyamat SVN-nel41 13.2.1.
A Subversion beüzemelése42 [15]
Egy SVN szerverhez a subversion, illetve a libapache2-svn csomagokat kell először telepítenünk. sudo apt-get install subversion libapache2-svn
13.2.1.1.
Szerver-beállítások
Az alábbiakban áttekintjük, hogy hogyan kell SVN tárolót (repository) létrehozni, és hogyan férhetünk hozzá az egyes projektekhez. 42 A
fejezet az Ubuntu Community Documentation alapján készült.
229
13.2.1.1.1.
SVN tároló létrehozása, fájlok importálása
Egyszerű SVN tárolót az svnadmin parancs segítségével készíthetünk. svnadmin create /elérési/út/a/projekthez Ha sikeresen létrehoztuk a tárolót, akkor elkezdhetjük a fájlok tárolóban való importálását. svn import /elérési/út/a/fájlokhoz file:///elérési/út/a/projekthez43
13.2.1.2.
Hozzáférés
A korábban elkészített tárolóhoz több féle képpen is hozzáférhetünk: helyi lemezen vagy különböző protokollok alkalmazásával távoli gépeken is. Akárhogy is érjük el a tárolót, mindi URL-ként hivatkozunk rá. Protokoll
Hozzáférés
file://
A tárolóhoz való közvetlen hozzéférés (lokális meghajtón).
http://
WebDAV, Apache2 webszerver.
https://
Megegyezik a http:// -nél tárgyalttal, SSL titkosítással kiegészítve.
svn://
Saját protokollal való hozzáférés.
svn+ssh://
Megegyezik az svn:// -nél tárgyalttal, SSH tunnelezéssel kiegészítve.
36. táblázat. Hozzáférés SVN tárolóhoz
Az alábbiakban sorra vesszük ezeket a hozzáférési metódusok alapjait. 13.2.1.2.1.
Közvetlen hozzáférés (file://)
Ez a hozzáférési módszer a legegyszerűbb, mivel nincs szükség külön SVN szerver processzre, mivel a saját gépünkön lveő tárolóhoz „kapcsolódunk”. A fájlok letöltését (checkout) a következő parancsok valamelyikével tehetjük meg: svn co file:///elérési/út/a/projekthez svn co file://localhost/elérési/út/a/projekthez A tárolóhoz való hozzáférési jogokat egyszerűen a fájlokhoz tartozó jogosultságok határozzák meg. Ha egy felhasználónak van írási és olvasási joga is, akkor lehetősége van a fájlok letöltésére és feltöltésére (commit) is. 43 Vegyük
észre a projekt elérési útját, hogy a file:// után a gyökértől indulva (/) adjuk meg, ezért indokolt a három „/”
karakter használata.
230
13.2.1.2.2.
Hozzáférés WebDAV protokollal (http://)
Ahhoz hogy WebDAV protokollal férhessünk hozzá egy tárolóhoz először is kell egy Apache webszerver. A következő sorokat kell hozzáadnunk az Apache által kiszolgált virtuális hoszt beállításaihoz (pl. /etc/apache2/sites-available/default), azaz a beállításokat a és tagek közé kell elhelyeznünk. DAV svn SVNPath /home/svn AuthType Basic AuthName "Your repository name" AuthUserFile /etc/subversion/passwd Require valid-user A fenti konfigurációban az SVN tárolók a /home/svn/ könyvtár alatt találhatók. Elérni őket pedig a http://hostname/svn/repos URL-lel lehet. Ahhoz, hogy az így beállított tárolókba fájlokat importálhassunk, illetve feltölthessünk gondoskodnunk kell róla, hogy a tároló tulajdonosa megegyezzen az Apache szerver felhasználójával, ami Ubuntu disztribúció esetén általában a www-data rendszerfelhasználó. A tárolók fájljait a következő paranccsal adhatjuk át a webszerver felhasználójának. sudo chown -R www-data:www-data /elérési/út/a/tárolókhoz Mivel a tároló tulajdonosa ezentúl a webszervert futtató rendszerfelhasználó, ezért a korábban bemutatott svn import file:///elérési/út/a/projekthez paranccsal már nem tudunk fájlokat importálni. Következő lépésként el kell készítenünk a felhasználók autentikációs adatait tartalmazó fájlt (/etc/subversion/passwd). Ehhez a következő parancsot kell lefuttatnunk, ami elkészíti az említátt fájlt, és hozzá is adja az első felhasználót. sudo htpasswd -c /etc/subversion/passwd Amennyiben már létezik az /etc/subversion/passwd fájl, akkor a további felhasználókat a -c kapcsoló elhagyásával vehetjük fel. (Ugyanis a -c kapcsoló hatására a régi fájlt felülírnánk, így törölnénk belőle az eddig bejegyzett összes többi felhasználót.) sudo htpasswd /etc/subversion/passwd A tárolóhoz ezentúl HTTP-n keresztül férhetünk hozzá: svn co http://szervernév/svn Ez a módszer azonban nem biztonságos, mivel a jelszavak titkosítás nélkül közlekednek a hálózaton, azért inkább a következő részben bemutatott, SSL titkosítást alkalmazó metódust használjuk.
231
13.2.1.2.3.
Hozzáférés SSL titkosított WebDAV protokollal (https://)
Az SSL titkosított WebDAV hozzáférés hasonló az előző részben tárgyalt metódushoz. A kettő között jelentős különség a titkosítás. Először is be kell állítanunk az Apache webszerünket, hogy titkosítottan továbbítsa a jelszavakat. (Lásd 7.1.5.) A legegyszerűbb, ha az /etc/apache2/sites-available/default-ssl fájlhoz adjuk hozzá az előző részben tárgyalt beállításokat. A hozzáférés pedig majdnem megegyezik azzal, amivel előzőleg találkoztunk, kivéve, hogy most már HTTPS protokollt kell használnunk. svn co https://szervernév/svn
13.2.1.2.4.
Hozzáférés saját protokollal (svn://)
A meglévő tárolónkhoz a már eddig felsorolt hozzáférési lehetőségeken túl az SVN saját protokollt is biztost az eléréshez. Az /elérési/út/a/tárolóhoz/projekt/conf/svnserve.conf fájlban kell elvégeznünk a szükséges beállításokat. Az autentikáció beállításához egyszerűen az alábbi sorokat kell kikommentezni. # [general] # password-db = passwd Ha kivettük a komment karaktereket, akkor már csak felhasználókat kell hozzáadni az imént megadott passwd fájlban. Az egyes felhasználókat a következőképp kell megadni: = <jelszó> Végül el kell indítanunk az SVN szervert. $ svnserve -d --foreground -r /path/to/repos # -d -- daemon mode # --foreground -- run in foreground (useful for debugging) # -r -- root of directory to serve For more usage details, please refer to: $ svnserve --help Az SVN szerver alapértelmezetten a 3690-es porton várakozik a kapcsolódásra. A hozzáférés az alábbi paranccsal lehetséges. svn co svn://hostname/project project --username A bemutatott svn:// hozzáférés azonban nem tartalmaz semmilyen titkostást, ezért a felhasználónevek, jelszavak és az adatok is titkosítás nélkül közlekednek a hálózaton. Ebből kifolyólag ezt a protokollt legfeljebb csak a saját számítógépünkön való tárolók eléréséhez használjuk.
232
13.2.1.2.5.
Hozzáférés SSL titkosított saját protokollal (svn+ssh://)
Az SSL titkosított hozzáférés hasonló az előző részben tárgyalt metódushoz. A kettő között jelentős különség a titkosítás. Az svn+ssh:// protokollal SSL titkosítással érjük el az SVN tárolót, azaz mind a jelszavak, mind a letöltött, illetve feltöltött adatok titkosítva közlekednek a hálózaton. A szervert ugyanúgy kell konfigurálni, mint azt az előzőekben bemutattuk. Szükségünk lesz még egy SSH szerverre is, hogy az SVN szerverrel távoli gépről is tudjunk kommunikálni. (Lásd 6.9.) A legfrissebb kód letöltéséhez az alábbi parancsot kell használnunk. svn co svn+ssh://hosztnév/var/svn/repos/project Az SSH szerver beállításától függően bejelentkezéskor jelszót is kérhet. Ha ezt a hozzáférési módot használjuk, akkor mindig a tejles elérési úttal (/elérési/út/a/tárolóhoz/projekt) kell az SVN tárolóra hivatkozni.
13.3.
Git
A git verziókezelő fejlesztését Linus Torvalds kezdte el, és elsődlegesen a Linux Kernel fejlesztéséhez készült. A Linux Kernel nagy méretű projekt, amelyen rengeteg fejlesztő dolgozik párhuzamosan. Ezek a követelmények speciális igényeket támasztanak. Eredményként a git verziókezelő egy elosztott rendszer lett, amely nem igényli folyamatosan egy központi szerver használatát. Minden munka másolat egy teljes értékű példány a verziókezelőből. Így offline dolgozhatunk vele, illetve a központi szerver sérülés esetén bármelyik másolatból visszaállítható. Előnyei: • a git masszívan támogatja a párhuzamos fejlesztést; • támogatja a nemlineáris fejlesztést; • nagy projektek effektív kezelése; • hatékony merge algoritmus. Mivel a git központi szerver nélkül is teljesen működőképes, ezért segítségével bármilyen szöveges állományt kezelhetünk. Érdemes lehet például az /etc könyvtár tartalmát is archiválni vele. 13.3.1.
A Git beüzemelése45 [16]
A Githez szükségünk lesz egy SSH szerverre, hogy az távoli gépről is tudjunk kommunikálni. (Lásd 6.9.) A gites projektmenedzsmenthez a Gitosis programcsomagot, míg a tárolók böngészéséhez a ViewGitet fogunk használni. Telepítsük a git-core és a gitosis csomagokat!
44 Forrás: 45 A
http://nakedstartup.com/2010/04/simple-daily-git-workflow. fejezet az Ubuntu Server Guide alapján készült.
233
Legfrissebb verzió letöltése git pull
Új ág létrehozása, átváltás git checkout -b <ág neve>
Új állományok hozzáadása a következő commithoz git add . A következő commit változásainak listája git diff
fejlesztési ciklus
új szolgáltatás elkészítése
Fejlesztés (érdemes kis lépésekben commitolni, mert könnyebb visszakeresni, ha valami elromlott)
Az új commit létrehozása git -commit -m "leírás" Visszatérés a főágra git checkout master A fejlesztői ág változtatásait átvitele a főágba git merge --no-ff <ág neve>
Változtatások feltöltése a szerverre git push 34. ábra. Munkafolyamat Git használatával44 sudo apt-get install git-core gitosis A gitosis csomag telepítésekor létrejön egy gitosis felhasználó, akinek a home könyvtára az /srv/gitosis, amelyben a tárolók és a konfiguráció találhatók. A Gitosis inicializálása: 234
sudo -H -u gitosis gitosis-init < initialKeyFileName Az initialKeyFileName a saját gépünk publikus kulcsának másolata (a fájl kiterjesztése általában .pub). Ha a kimenet tartalmazza az alábbi üzenetet, akkor elkészült az üres Git tárolónk. ... Initialized empty Git repository in ./ Your gitosis is installed. ... A további beállításokoz először a saját gépünkön levő git-admin ágat kell letöltenünk (checkout).46 git clone [email protected]:gitosis-admin.git Amennyiben a klónozás sikertelen, ellenőrizzük, hogy az SSH szerver beállításai között nem szerepel-e a PermitRootLogin no, beállítás, illetve engedélyezve van-e a gitosis felhasználó az sshd_config fájlban. sudo nano /etc/ssh/sshd_config AllowUsers gitosis A Gitosis beállításait a gitosis.conf fájl tartalmazza. cd gitosis-admin nano gitosis.conf
13.3.2.
Új projekt hozzáadása a tárolóhoz
A Gitosis alapbeállításai mellé felvettünk egy új projektet: [gitosis] [group team] writable = testproject members = keyfilename [group gitosis-admin] writable = gitosis-admin members = keyfilename
Megjegyzés A gitosis-admin csoportot érintő változtatásoknál nagyon figyeljünk, mert akár saját magunkat is kizárhatjuk a tárolóból. A módosítások végeztével commitoljuk vissza szerverre. 46 A
yourserver.com URL-t cseréljük le a saját szerverünk nevére.
235
git commit -a -m "Added a new project" git push A tárolóhoz mindig az itt felsorolt lépésekkel adjuk hozzá az egyes projekteket. 13.3.3.
Az első projekt commitolása
Készítsünk egy könyvtárat a létrehozott projekthez, inicializáljuk, adjuk hozzá az állományainkat, commitoljuk, és végül töltsük fel a tárolóba. mkdir testproject cd testproject git init touch a_text_file.txt git add . git commit -a -m "Initial import" git remote add origin [email protected]:testproject.git git push origin master Ha a commitolás sikertelen, ellenőrizzük a /srv/gitosis/.ssh/authorized_keys fájlt, hogy tartalmazza-e a szükséges publikus kulcsot. 13.3.4.
Felhasználók hozzáadása
A további felhasználók hozzáadásához először szükségünk lesz a publikus kulcsukra (user1.pub, user2.pub). Ezeket a gitosis-admin tároló helyi keydir/ könyvtárába kell bemásolnunk, majd a gitosis.conf fájlban a felhasználókat adjuk hozzá a csoporthoz. cd gitosis-admin cp ~/user1.pub keydir/ cp ~/user2.pub keydir/ git add keydir/user1.pub keydir/user2.pub [group team] writable = testproject - members = hostname.yourserver.com + members = hostname.yourserver.com user1 user2 Commit és feltöltés: git commit -a -m "Commit jog biztositasa a testprojekthez user1 és user2 szamara" git push Ezek után a user1 és a user2 felhasználók is klónozhatják a projektet a saját számítógépükre, illetve commitolhatnak is hozzá.
236
git clone [email protected]:testproject.git
13.3.5.
Elérés böngészőből
A böngészőből való eléréshez először egy PHP modullal ellátott Apache webszervert kell telepítenünk (lásd 7.1.), illetve a kódszínezéshez telepítsük a php-geshi csomagot is. sudo apt-get install apache2 libapache2-mod-php5 php-geshi Ha készen áll az Apache webszerverünk, akkor lépjünk be a munkakönyvtárába (/var/www/), és helyben klónozzuk a ViewGit-et. cd /var/www sudo git clone http://repo.or.cz/r/viewgit.git sudo chown -vR www-data:www-data viewgit A sikeres klónozás után hozzuk létre a ViewGit konfigurációs állományát (localconfig.php), adjuk a webszerver tulajdonába, majd végezzük el a szükséges módosításokat benne. cd /var/www/viewgit/inc sudo cp config.php localconfig.php sudo chown www-data:www-data localconfig.php sudo nano localconfig.php Az alábbiakban bemutatjuk a testproject.git-hez elkészített ViewGit konfigurációt.47 array('repo' => '/srv/gitosis/repositories/testproject.git/'), ); // If set, contains an array of globs/wildcards where to include projects. // Use this if you have a lot of projects under a directory. $conf['projects_glob'] = array('/srv/gitosis/repositories/*.git'); // Where git is. Default is to search from PATH, but you can use an absolute // path as well. $conf['git'] = 'git'; $conf['datetime'] = '%Y-%m-%d %H:%M'; // More complete format for commit page 47 A $conf['projects'] tömbben adhatjuk meg explicit módon, hogy a ViewGit mely tárolókat mutassa, míg a $conf['projects_glob'] tömbben a fájlrendszeren adhatunk meg mintákat, amelyeket a ViewGit szintén elérhetővé tesz. A példában a mindkét tömbben benne lesz a testproject.git (az elsőben explicit módon adtuk meg, míg a második esetben illeszkedik a mintára), azaz a listában kétszer lesz látahtó.
237
$conf['datetime_full'] = '%Y-%m-%d %H:%M:%S'; // Maximum length of commit message's first line to show $conf['commit_message_maxlen'] = 50; // Maximum number of shortlog entries to show on the summary page $conf['summary_shortlog'] = 30; // Maximum number of tags to show on the summary page $conf['summary_tags'] = 10; // Whether to show remote labels on shortlog $conf['shortlog_remote_labels'] = false; // Allow checking out projects via "git clone" $conf['allow_checkout'] = true; // If set, this function is used to obfuscate e-mail addresses of // authors/committers // The 'obfuscate_mail' function simply replaces @ with ' at ' and . with ' dot ' //$conf['mail_filter'] = 'obfuscate_mail'; //$conf['mail_filter'] = create_function('$mail', //
'return str_rot13(strtoupper($mail));');
// Whether to use GeSHi for source highlighting $conf['geshi'] = true; // Path to geshi.php $conf['geshi_path'] = 'inc/geshi/geshi.php'; $conf['geshi_path'] = '/usr/share/php-geshi/geshi.php'; // Path on Debian // Use line numbers in geshi? // Setting this to "false" disables line numbers // Using a value of 0 will enable "NORMAL" geshi line numbers // Using values of 1 or more will enable "FANCY" geshi line numbers $conf['geshi_line_numbers'] = 5; // RSS time to live (how often clients should update the feed), in minutes. $conf['rss_ttl'] = 10; // RSS: Maximum number of items in feed 238
$conf['rss_max_items'] = 30; // RSS item format. Allowed formatting: // {AUTHOR}, {AUTHOR_MAIL}, {SHORTLOG}, {LOG}, {COMMITTER}, {COMMITTER_MAIL}, // {DIFFSTAT} $conf['rss_item_title'] = '{SHORTLOG} ({AUTHOR})'; $conf['rss_item_description'] = '<pre>{LOG}{AUTHOR} <{AUTHOR_MAIL} >
<pre>{DIFFSTAT}'; $conf['debug'] = false; // Includes a small link to the ViewGit homepage on each page $conf['ad'] = false; A http://localhost/viewgit/ címet megynitva a Git tárolót már webböngészőből is el tudjuk érni. Ha mégis probléma merülne fel, adjuk hozzá a webszerverünk rendszerfelhasználóját a Gitosis felhasználójának alapértelmezett csoportjához. adduser www-data gitosis
13.3.6.
Publikus tároló létrehozása
Ahhoz, hogy mások is hozzáférhessenek a tárolóhoz a git-daemon-t kell konfigurálnunk. A git-daemon egy olyan szolgáltatás, ami a 9428-as porton keresztül lehetővé teszi, hogy bárki klónozhassa a tárolónkban levő projekteket. A git-daemon a git-core csomagban található, ezért további telepítésre nincs szükség. A szolgáltatás könnyebb adminisztrációjához használjuk az alábbi scriptet. Készítsük el a git-daemin init scriptet! sudo nano /etc/init.d/git-daemon Másoljuk bele a következő blokkot! # Taken from here: http://pastie.org/227647 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin NAME=git-daemon PIDFILE=/var/run/$NAME.pid DESC="the git daemon" DAEMON=/usr/lib/git-core/git-daemon
DAEMON_OPTS="--base-path=/srv/gitosis/repositories --export-all --verbose --syslog --detach --pidtest -x $DAEMON || exit 0 [ -r /etc/default/git-daemon ] && . /etc/default/git-daemon 239
. /lib/lsb/init-functions start_git() { start-stop-daemon --start --quiet --pidfile $PIDFILE \ --startas $DAEMON -- $DAEMON_OPTS } stop_git() { start-stop-daemon --stop --quiet --pidfile $PIDFILE rm -f $PIDFILE } status_git() { start-stop-daemon --stop --test --quiet --pidfile $PIDFILE >/dev/null 2>&1 } case "$1" in start) log_begin_msg "Starting $DESC" start_git log_end_msg 0 ;; stop) log_begin_msg "Stopping $DESC" stop_git log_end_msg 0 ;; status) log_begin_msg "Testing $DESC: " if status_git then log_success_msg "Running" exit 0 else log_failure_msg "Not running" exit 1 fi ;; restart|force-reload) log_begin_msg "Restarting $DESC"
240
stop_git sleep 1 start_git log_end_msg 0 ;; *) echo "Usage: $0 {start|stop|restart|force-reload|status}" >&2 exit 1 ;; esac exit 0 Hogy az itt közölt script automatikusan elinduljon, először futtathatóvá kell tennünk, majd frissítenünk kell az update-rc.d -t. sudo chmod +x /etc/init.d/git-daemon sudo update-rc.d git-daemon defaults
13.3.7.
A git daemon kezelése
System V initet használó rendszerek estén: sudo /etc/init.d/git-daemon start sudo /etc/init.d/git-daemon stop sudo /etc/init.d/git-daemon restart sudo /etc/init.d/git-daemon force-reload Upstartot használó rendszerek esetén: sudo service git-daemon start sudo service git-daemon stop sudo service git-daemon restart sudo service git-daemon force-reload
13.4.
SVN vagy Git?
Manapság mind az SVN, mind a git használata igen elterjedt. Szoftverfejlesztésekhez a git használata a célszerűbb, mivel hatékonyabb merge algoritmusa révén jobban támogatja a párhuzamos fejlesztést. 241
Emellett támogatja az offline verzió kezelést is. Ha bináris állományokból áll a projektünk, akkor az svn használata a célszerűbb, mivel ebben az esetben a "merge" algoritmusnak nem vesszük hasznát. Ugyanakkor az állományzárolással megakadályozhatjuk az állományok párhuzamos szerkesztését.
242
Hivatkozások [1] Bányász G. és Levendovszky T., Linux programozás.
Bicske: Szak Kiadó, 2003.
[2] Free Software Foundation. (2010.) GNU General Public License (GPL), 2. verzió. FSF.hu Alapítvány. Hivatkozva: 2011. február 8. [Online]. Elérhető: http://gnu.hu/gpl.html [3] R. Russell, D. Quinlan és C. Yeoh. (2004. január) Filesystem Hierarchy Standard. The Linux Foundation. Hivatkozva: 2011. február 8. [Online]. Elérhető: http://www.pathname.com/fhs/ [4] L. Wirzenius, J. Oja, S. Stafford és A. Weeks. (2005. július) The Linux System Administrator’s Guide. The Linux Documentation Project. Hivatkozva: 2011. február 8. [Online]. Elérhető: http://tldp.org/LDP/sag/html/sag.html [5] L. Wirzenius, J. Oja, S. Stafford és A. Weeks. (2003. december) Linux rendszeradminisztrátorok kézikönyve. Magyar Linux Dokumentációs Projekt. Hivatkozva: 2011. február 8. [Online]. Elérhető: http://tldp.fsf.hu/HOWTO/sag-hu/ [6] S. J. Remnant. (2006. augusztus) Upstart in Universe. Hivatkozva: 2012. február 27. [Online]. Elérhető: http://netsplit.com/2006/08/26/upstart-in-universe/ [7] J. Hunt és C. Byrum. (2012. február) Upstart Intro, Cookbook and Best Practises. Canonical Ltd. Hivatkozva: 2012. február 28. [Online]. Elérhető: http://upstart.ubuntu.com/cookbook/ [8] Red Hat, Inc. (1999. november) RPM HOWTO. The Linux Documentation Project. Hivatkozva: 2011. február 20. [Online]. Elérhető: http://tldp.org/HOWTO/RPM-HOWTO/index.html [9] C. C. Lee. (2005. augusztus) Bináris Debian csomag készítése HOGYAN. Magyar Linux Dokumentációs Projekt. Hivatkozva: 2011. február 20. [Online]. Elérhető: http://tldp.fsf.hu/ HOWTO/Debian-Binary-Package-Building-HOWTO-hu/index.html [10] Kovács F. és Nagy T. (2002.) TCP/IP hálózat működése, TCP/IP alapú kommunikáció. Automatizálási és Alkalmazott Informatikai Tanszék, Budapesti Műszaki és Gazdaságtudományi Egyetem. Hivatkozva: 2011. február 20. [Online]. Elérhető: http://avalon.aut.bme.hu/education/ jegyzet/szeszk/tcpip/tcp.htm [11] M. Lottor. (1988. november) TCP Port Service Multiplexer (TCPMUX). Internet Engineering Task Force Network Working Group. Hivatkozva: 2011. február 20. [Online]. Elérhető: http://tools.ietf.org/html/rfc1078 [12] Automatizálási és Alkalmazott Informatikai Tanszék. (2012. január) Linux alapú hálózatok. Automatizálási és Alkalmazott Informatikai Tanszék, Budapesti Műszaki és Gazdaságtudományi Egyetem. [Online]. Elérhető: https://www.aut.bme.hu/Course/VIAUJV60 [13] P. Mockapetris. (1987. november) Domain Names – Concepts and Facilities. Internet Engineering Task Force Network Working Group. Hivatkozva: 2011. március 6. [Online]. Elérhető: http://tools.ietf.org/html/rfc1034 243
[14] R. Droms. (1997. március) Dynamic Host Configuration Protocol. Internet Engineering Task Force Network Working Group. Hivatkozva: 2011. március 6. [Online]. Elérhető: http://tools.ietf.org/html/rfc2131 [15] Ubuntu Documentation Team. (2012. április) Subversion. Ubuntu Documentation Project. Hivatkozva: 2012. április 28. [Online]. Elérhető: https://help.ubuntu.com/12.04/serverguide/ subversion.html [16] Ubuntu Community Documentation. (2011. augusztus) Git. Canonical Ltd. Hivatkozva: 2012. április 28. [Online]. Elérhető: https://help.ubuntu.com/community/Git
244
Ábrák jegyzéke 1.
A Linux kernel vázlatos felépítése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.
A nano felülete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.
A joe felülete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.
A jobok életciklusának egyszerűsített modellje . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.
A sysv-rc-conf felülete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.
A Red Hat User Manager főablaka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
7.
A rendszer terheltsége a KDE System Guard ban . . . . . . . . . . . . . . . . . . . . . . . 127
8.
Folyamatok adatai a KDE System Guard ban . . . . . . . . . . . . . . . . . . . . . . . . . 127
9.
Folyamatadatok és rendszer leterheltség a System monitor ban . . . . . . . . . . . . . . . . 128
10.
Futásszintek beállításai a Service Configuration programban . . . . . . . . . . . . . . . . . 128
11.
Log állományok kezelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
12.
Csomagok telepítése és eltávolítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
13.
A Synaptic csomagkezelő
14.
A TCP/IP protokoll felépítése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
15.
Az IPv4-es fejrész felépítése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
16.
A NetworkManager applet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
17.
Network Configuration főablak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
18.
Hálózati szolgáltatások védelme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
19.
NFS Server Configuration főablak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
20.
NFS általános beállítások és felhasználói jogosultságok . . . . . . . . . . . . . . . . . . . . 152
21.
Samba Server Configuration főablak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
22.
Szerver beállítások és megosztások . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
23.
Webszerver szoftverek piaci részesedése29
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
. . . . . . . . . . . . . . . . . . . . . . . . . . . 159
24.
Az Apache prefork és worker metódusai . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
25.
Apache Configuration
26.
A phpinfo kimenete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
27.
A phpMyAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
28.
Az AWStats által készített statisztika
29.
A Wireshark Capture Options ablaka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
30.
A Wireshark főablaka a monitorozás leállítása után . . . . . . . . . . . . . . . . . . . . . . 197
31.
Sniffelés az Ettercap programmal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
32.
IP cím kiosztása DHCP-vel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
33.
Munkafolyamat SVN-nel41 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
34.
Munkafolyamat Git használatával44 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
245
Táblázatok jegyzéke 1.
A nano leggyakoribb billentyűkombinációi . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.
A joe leggyakoribb billentyűkombinációi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.
Állományrendszerek összehasonlítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.
Az fdisk főbb parancsai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.
Állománytípusok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.
Jogosultsági csoportok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.
A jogosultságokat állító operátorok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.
Hozzáférési jogok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.
Jogosultságok oktális számokkal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.
Jogosultságok formátumai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
11.
Az ext2, ext3, ext4 állományrendszerek további jogosultságai . . . . . . . . . . . . . . . . 37
12.
Állománynév-helyettesítés reguláris kifejezésekkel . . . . . . . . . . . . . . . . . . . . . . . 41
13.
A bash shell speciális változói . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
14.
A bash shell beépített parancsai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
15.
Stringek kiértékelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
16.
Numerikus kiértékelés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
17.
Állomány-tulajdonságok szerinti kiértékelés . . . . . . . . . . . . . . . . . . . . . . . . . . 50
18.
Az erőforrás kontroll opciói . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
19.
A find kapcsolói
20.
A sort kapcsolói . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
21.
A grep kapcsolói . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
22.
Egyszerű reguláris kifejezések . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
23.
Folyamatok kiválasztása ps-sel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
24.
A ps kimenetének formázása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
25.
A legfontosabb szignálok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
26.
Futásszintek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
27.
Az init által definiált műveletek/akciók . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
28.
A cron idő mezőjének formátuma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
29.
Idő megadása az at parancs esetén . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
30.
A dpkg debug szintjei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
31.
Általános X kliens opciók . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
32.
Hálózati eszközök . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
33.
Hálózati szolgáltatások paraméterei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
34.
Az NFS hozzáférés paraméterei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
35.
Az aircrack-ng csomag elemei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
36.
Hozzáférés SVN tárolóhoz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
246
