20/80 – hálózati szolgáltatások szabad szoftverekkel
TRANSCRIPT
20/80 – Hálózati szolgáltatások szabad szoftverekkel
Módszertan és tartalmi tertvek: Mátó Péter, Varga Csaba Sándor, Zahemszky Gábor
Írták: Mátó Péter, Rózsár Gábor, Őry Máté, Varga Csaba Sándor, Zahemszky Gábor:
0.9-es tváltozat, 2014. április 11., elektronikus kiadás
Kiadó: E-közigazgatási Szabad Szoftver Kompetencia Központ
Honlap, jatvítot kiadások: htp://szabadszoftver.kormany.hu/sajat-oktatasi-anyagok/.
ISBN 978-963-08-8300-9
Szerzői jogEz a könytv a Creatitve Commons Atribution-ShareAlike 3.0 Unported (CC-BY-SA 3.0) licencszerint szabadon terjeszthető és módosítható.
Totvábbi információk: htp://creatitvecommons.org/licenses/by-sa/3.0/
A dokumentumban található összes tvédjegy azok jogos tulajdonosait illeti meg.
TartalomjegyzékElőszócska..................................................................................................................................................................7Vállalati letvelezés, spamszűrés és tvírusszűrés..................................................................................................8
Történeti átekintés............................................................................................................................................8Kitválasztás............................................................................................................................................................9
Sendmail..........................................................................................................................................................9Exim4................................................................................................................................................................9qmail.................................................................................................................................................................9Postfx...............................................................................................................................................................9
A Postfx fontosabb beállításai......................................................................................................................10Postfx nagyobb helyen...................................................................................................................................14A MariaDB/MySQL és a Postfx kapcsolata...............................................................................................14SASL.....................................................................................................................................................................18Hasznos tvállalati funkciók.............................................................................................................................20Víruskereső programok...................................................................................................................................24
A legnépszerűbb zárt termékek Linuxra...............................................................................................24Amatvis+ClamAV+SpamAssasin konfgurálás.....................................................................................25
A letvelek elérése...............................................................................................................................................27Letvélszemét és hamisítás elleni technológiák...........................................................................................30Webmail...............................................................................................................................................................31
Általános célú hálózati szertver: az inetd és xinetd.......................................................................................34Inetd.....................................................................................................................................................................34Xinetd..................................................................................................................................................................36
Központi időszinkron szertver: NTP szertver...................................................................................................39Történeti átekintés..........................................................................................................................................39Döntési mechanizmus.....................................................................................................................................40Használat.............................................................................................................................................................40
Kliens..............................................................................................................................................................40Szertver............................................................................................................................................................41
Nétvfeloldás a hálózaton: DNS szertver (dnsmasq és BIND).........................................................................43Minden egybe....................................................................................................................................................43
Dnsmasq........................................................................................................................................................43Külön-külön.......................................................................................................................................................44
Nétvfeloldás....................................................................................................................................................44Nétvtér.............................................................................................................................................................44Resoltver..........................................................................................................................................................46Nétvszertverek................................................................................................................................................47
BIND (Berkeley Internet Name Daemon)........................................................................................47Példakonfguráció.............................................................................................................................50Elsődleges (mester) kiszolgáló.......................................................................................................50
Bind Chroot-ban..........................................................................................................................................52ISC-DHCPD..................................................................................................................................................52
Kliensek hálózati paramétereinek szolgáltatása: DHCP-szertver...............................................................54Kliensek hálózati paramétereinek központi kiosztása, DNS lekérdezések gyorsítása....................54ISC DHCP-szertver telepítése, konfgurálása.............................................................................................55
Telepítés, alap beállítások:........................................................................................................................55Egyéb hasznos option defníciók.......................................................................................................56
IP-címek kliensekhez rendelése...............................................................................................................56Globális opciók felülbírálása...............................................................................................................56
Csak fx IP-címek.........................................................................................................................................57
Teljes példa konfgurációs állományok.................................................................................................57/etc/dhcp/dhcpd.conf............................................................................................................................57/etc/dhcp/kliensek.................................................................................................................................57
DNSMasq telepítése, konfgurálása..............................................................................................................58Telepítés, alap beállítások..........................................................................................................................58Konfguráció.................................................................................................................................................58
Totvábbi konfgurációs ötletek............................................................................................................59DNSMasq mint DHCP-szertver......................................................................................................59
Teljes példa konfgurációs állományok:................................................................................................59/etc/resoltv.conf.......................................................................................................................................59/etc/default/dnsmasq.............................................................................................................................59/etc/dnsmasq.conf..................................................................................................................................60/etc/hosts..................................................................................................................................................60
Webszertver feladata, telepítése és üzemeltetése............................................................................................61Webszertverek.....................................................................................................................................................61
Apache...........................................................................................................................................................61Az apache2.conf fájl..............................................................................................................................62A ports.conf fájl......................................................................................................................................63A security fájl..........................................................................................................................................64A charset fájl...........................................................................................................................................65Az Apache kiterjesztése.......................................................................................................................65Egy tartomány kiszolgálásának beállítása.......................................................................................65Egy biztonságos tartomány beállítása..............................................................................................67
Lightpd..........................................................................................................................................................68Nginx..............................................................................................................................................................68
Webszertver üzemeltetéséhez szükséges komponensek..........................................................................68PHP.................................................................................................................................................................68
A PHP telepítése.....................................................................................................................................69Phpmyadmin................................................................................................................................................71OpenSSL.........................................................................................................................................................71
Weboldalak: webes CMS......................................................................................................................................72FTP-szertver feladata, telepítése és üzemeltetése...........................................................................................73
Pure-FTPd......................................................................................................................................................73A Pure-FTPd és a tvirtuális felhasználók..........................................................................................77
Vsfpd..............................................................................................................................................................78ProFTPD........................................................................................................................................................79SFTP................................................................................................................................................................79
Webstatisztika-készítő szoftverek.................................................................................................................80AWStats..........................................................................................................................................................80Webalizer.......................................................................................................................................................80Piwik...............................................................................................................................................................80BBclone..........................................................................................................................................................80
Fájl szertver feladata, telepítése, üzemeltetése.................................................................................................81Fájl és nyomtatószertver heterogén hálózatok részére............................................................................81Miről is szól mindez?.......................................................................................................................................81Történeti átekintés..........................................................................................................................................81Samba tverziók....................................................................................................................................................81
3.6-os sorozat................................................................................................................................................814-es sorozat...................................................................................................................................................82
Samba 3.6 telepítése, konfgurálása..............................................................................................................82A döntés.........................................................................................................................................................82A példa...........................................................................................................................................................83Előkészületek:..............................................................................................................................................83
Telepítés:.......................................................................................................................................................84Konfgurálás..................................................................................................................................................84
Globális beállítások:..............................................................................................................................84Megosztások............................................................................................................................................87
Kötöt megosztások..........................................................................................................................87Megosztásaink........................................................................................................................................87
Példa nyomtatók megosztására....................................................................................................89A netlogon könytvtár szkriptjei..........................................................................................................90Felhasználók létrehozása.....................................................................................................................91A teljes /etc/samba/smb.conf..............................................................................................................92
Samba használata........................................................................................................................................95Samba indítása........................................................................................................................................95Kliensek tartományba léptetése.........................................................................................................95Hasznos segédeszközök.......................................................................................................................95
Samba 4 telepítése, konfgurálása.................................................................................................................96Samba 4 igényei...........................................................................................................................................96Samba 4 beszerzése.....................................................................................................................................96Totvábbi előkészítő munkálatok...............................................................................................................97
sertver 0.hu.pool.ntp.org..................................................................................................................97sertver 1.hu.pool.ntp.org..................................................................................................................97sertver 2.hu.pool.ntp.org..................................................................................................................97sertver 3.hu.pool.ntp.org..................................................................................................................97
Konfgurálás..................................................................................................................................................98Totvábbi globális beállítások................................................................................................................99Megosztások............................................................................................................................................99
Tartomány kezelése..................................................................................................................................100Rsat letöltése, telepítése.....................................................................................................................101Megosztások jogai...............................................................................................................................102
Home és Profles mappák jogai..................................................................................................102Home és Profl könytvtárak beállítása.............................................................................................103Nyomtatás beállítása...........................................................................................................................103Logon szkriptek....................................................................................................................................104
Hálózati nyomtatás, szkenner szertver............................................................................................................107Nyomtatás Linuxon........................................................................................................................................107
Linuxon használt nyomtatási rendszer................................................................................................107Nyomtató kitválasztása.............................................................................................................................108CUPS telepítése..........................................................................................................................................108CUPS alap konfgurálása.........................................................................................................................109CUPS webes felülete.................................................................................................................................110Nyomtatóadminisztrátor felhasználó beállítása................................................................................110
Nyomtatók hozzáadása.................................................................................................................................111Nyomtatók megosztása a hálózaton.....................................................................................................114
Linux kliensek......................................................................................................................................115Windows kliensek...............................................................................................................................115
Egyéb CUPS ötletek..................................................................................................................................116Szkennelés Linuxon.......................................................................................................................................117
Szkenner támogatotsága........................................................................................................................117Telepítés.......................................................................................................................................................117Konfguráció...............................................................................................................................................117Szkenner használata.................................................................................................................................118
Parancssorból........................................................................................................................................118Grafkus felületen................................................................................................................................118
Hálózati lapoltvasás...................................................................................................................................119
Telepítés.................................................................................................................................................119Konfguráció..........................................................................................................................................120
Kliens oldali lehetőségek.........................................................................................................................120Linux kliens...........................................................................................................................................120Windows kliens....................................................................................................................................121
Adatbázis-kezelés.................................................................................................................................................123Történeti átekintés........................................................................................................................................123MySQL...............................................................................................................................................................124
Telepítése és beállítása.............................................................................................................................125A MySQL mentése....................................................................................................................................127Referenciák.................................................................................................................................................128
MariaDB............................................................................................................................................................128Referenciák.................................................................................................................................................129
PostgreSQL.......................................................................................................................................................129Referenciák.................................................................................................................................................130
SQLite................................................................................................................................................................131Referenciák.................................................................................................................................................131
Hogyan tválasszunk?......................................................................................................................................132Webproxy...............................................................................................................................................................133
A HTTP proxy.................................................................................................................................................133Squid..................................................................................................................................................................134A Squid telepítése...........................................................................................................................................134Transzparens üzemmódban.........................................................................................................................136Proxy beállítások központosítása:..............................................................................................................137Weboldalak blokkolása..................................................................................................................................137Sarg.....................................................................................................................................................................138
VPN beállítás : IPSec és OpenVPN...................................................................................................................140OpenVPN..........................................................................................................................................................140
A konfgfájlban megadandó paraméterek...........................................................................................141Easy-rsa.......................................................................................................................................................142Kliensek beállítása.....................................................................................................................................144
IPsec...................................................................................................................................................................145Közös címtár LDAP segítségétvel......................................................................................................................147
Hasznos információk az LDAP-ról.............................................................................................................147Az OpenLDAP szertver..................................................................................................................................148
Telepítése.....................................................................................................................................................148Az LDIF fájlformátum..............................................................................................................................149Alacsony szintű műtveletek az adatbázissal........................................................................................151
Feltöltés LDIF-ből................................................................................................................................151Kiírás LDIF formátumba....................................................................................................................151Fájl szintű mentés, helyreállítás.......................................................................................................151
Előszócska
ElőszócskaEzzel a könytvtvel és testtvéreitvel az a célunk, hogy tviszonylag tömören összefoglaljuk azokat az
információkat, amiket egy szabad szoftvereket használó szakembereknek tudnia illik.
20/80. Mit akar ez jelenteni? Tapasztalatunk szerint a létező eszközöknek és információknak csak egy kis része szükséges a mindennapok tipikus feladatainál. Igyekeztünk kitválogatni nektek a tudásnak azt a 20%-át, ami az általában előforduló feladatok 80%-ánál elegendő lesz. Célunk ezeneltv alapján összeszedni, rendszerezni és átadni a leghasznosabb dolgokat. Hiába próbálnánk min-dent elmondani – nekünk nincs időnk mindent leírni, nektek meg nincs időtök eloltvasni. Ezért sok minden kimarad. Ha úgy gondolod, hogy fontos, kimaradt tvagy bőtvebben kellene beszélni róla, szólj! Ha tvalami hibás, szólj ! E-mail címünk: [email protected]. De ha írsz, légy türelem-mel, tvalószínűleg 200 másik letvél is tvár még megtválaszolásra. A totvábbfejlesztés során minden konstruktítv jatvaslatot igyekszünk majd az anyagba építeni.
A tárgyalt megoldások és szabad szoftverek legtöbbször több operációs rendszer alat is használ-hatóak. Amikor tviszont operációs rendszer szintről esik szó (telepítés, csomagkezelés tvagy fi-nomhangolás), akkor ez most – népszerűsége miat – nálunk Linuxot jelent.
A könytvben időnként kérdéseket teszünk fel, de néha nyittva hagyjuk a tválaszt. A cél: gondol-kozz, oltvass utána, használd az agyadat! Ha egy témát alaposabban meg akarsz ismerni, akkor nincs mese, alaposabban utána kell oltvasnod. Minden területnek megtvannak a maga – tőlünk sok-kal mélyebb ismereteket tárgyaló – szakkönytvei, előtük azért érdemes a mi összefoglalónkat el-oltvasni, mert ezekben – reményeink szerint – az adot terület esszenciája található. Ez alapján márkönnyebben eligazodsz majd a 6-700 oldalas, lényegesen kimerítőbb anyagokban is.
7
Vállalati letvelezés, spamszűrés és tvírusszűrés
Vállalati levelezés, spamszűrés és vírusszűrés
Történeti áttekintésAz első generációs letvelezőszertverek a nagygépes UNIX és már a linuxos idők kezdetén a Send-
mail rendszert preferálták legtöbbször. A Sendmail a maga tekintetében lerakta az RFC szerinti alapokat az 1980-as étvek elején, és gyakorlatilag iparági standarddá tvált. A maga nemében hihe-tetlen rugalmassággal rendelkezet, amelyet M4 makrónyeltven lehetet programozni. A Sendmailt ma is fejlesztik, és sokan használják, mégis egyeduralkodása a 2000-es étvek elején megtört, és szá-mos úgynetvezet Sendmail kompatibilis letvelezőrendszer készült. Jelenleg széles körben használt rendszerek:
– Postfx1
– Exim42
– qmail3
– Sendmail4
A kis- és középtvállalatok körében leginkább elterjedtnek tekinthető Linux terjesztések, mint pl. a Debian5, Ubuntu6 (tvagy akár a kereskedelmi RHEL7 és SLES8) is ezt a négy letvelezőrendszert cso-magolják könnyen elérhetően a kiadásaikba. Nagyon fontos tény, hogy a biztonsági frissítések is hamarabb, illettve rendszeresebben érkeznek az olyan szoftverekhez, amelyek használata szélesebbkörű, hiszen ezeket gyakran nagyobb programozói csapat és fgyelem kíséri.
1 1. http://www.postfix.org/1 2. http://www.exim.org/1 3. http://www.qmail.org/ – az eredeti fejlesztője kötvetkezetesen kisbetűtvel írja a netvet, ezért használjuk mi is így1 4. http://www.sendmail.com1 5. http://www.debian.org/1 6. http://www.ubuntu.com/1 7. http://www.redhat.com/1 8. http://www.suse.com/
8
Vállalati letvelezés, spamszűrés és tvírusszűrés
KiválasztásA megfelelő MTA9 kitválasztásánál a kötvetkező szempontokat tvegyük fgyelembe. A jelenleg leg-
nagyobb felhasználói bázissal rendelkező, és leginkább támogatot (alapíttványok és közösségek ál-tal egyaránt), terjesztésekben melyek integráltak, és a rájuk építet járulékos szolgáltatások melyekkel a legkönnyebben integrálhatóak. Azaz a későbbiekben taglalt tvírustvédelem, spamszű-rés, illettve letvelezőlista-kezelés melyikkel a legkönnyebben kitvitelezhető – és természetesen a biz-tonság is jelentős szempont.
SendmailÖsszetet rendszer, amely igen robusztus felépítésű. Ellenértvként hozható fel, hogy az átlagostól
eltérő igényekhez az M4 makrók ismerete szükséges, melynek elsajátítása komoly programozói ambíciót igényel. Valószínűleg mindent meg lehet csinálni tvele, ami letvelezésben egyáltalán elő-fordulhat, de egyre ketvesebben szánják rá az időt a megtanulására. Mindenesetre akinek esetleg nem csak Linuxban, hanem zárt Unix rendszerekben is kell gondolkodnia, annak lehet fontos ezt (is) megismerni.
Exim4Gyors, összetet, komplex rendszer. Minden igényre könnyedén alkalmazható, remekül bírja a
nagy forgalmat. Igazi előnytelen tulajdonsága nincs. Nem tvéletlen tvolt alapértelmezet letvelező-szertver a Debian rendszerű terjesztésekben.
qmailGyors és kis program, alacsony hardtverigényű, még akkor is jól teljesít, ha nagy az átmenő for-
galom, rendkítvül biztonságos, a konfgurálhatósága jobb a Sendmailnél. Ellenértvként hozható fel tvele szemben, hogy a bonyolultabb igényeket nehezebb megoldani qmail alat, mint Exim tvagy Postfx alat. Totvábbi ellenértv lehet a licencelése, amely közkincs (public domain)10, tvalamint hogyeredeti fejlesztője a qmail aktítv fejlesztésétvel leállt.
PostfixKészítője Wietse Venema11, aki főként biztonsági szemléletéről tvált ismerté a Postfxet megelőző
időkben. Ez rögtön szembetűnik, amint átekintjük a Postfx felépítését, amely szemben a hagyo-mányos MTA-kkal, nem egy programon belül látja el az összes funkciót, hanem egy piramis fel-építésére hasonlító moduláris programrendszer tvalósítja meg a funkciókat. A beérkező letveleket az első réteg fogadja és adja át a megfelelő funkciót ellátó kötvetkező komponensnek, a beállítot szabályok szerint. Ez a felépítés az, amely nagyban hozzájárul a magas fokú biztonsághoz. A hiba-jatvítás és a biztonsági frissítések elkészítése is jótval egyszerűbb és átekinthetőbb. Totvábbi hatal-mas előnye, hogy mitvel az élmezőnyben szerepel, azaz több millió felhasználótval rendelkezik,
1 9. http://en.wikipedia.org/wiki/Message_transfer_agent1 10. http://en.wikipedia.org/wiki/Qmail1 11. http://www.porcupine.org/wietse/
9
Vállalati letvelezés, spamszűrés és tvírusszűrés
ezért dokumentációs szempontból uralja az internet fórumait és számtalan karbantartot „hogyan”található hozzá.12
Natítv támogatással rendelkezik a kötvetkező operációs rendszerekhez: AIX, a különböző BSD-k, HP-UX, IRIX, GNU/Linux, Mac OS X, Solaris, Tru64 UNIX, de minden olyan UNIX-jellegű rend-szeren futatható, amelyen C fordítótval forrásból előállítható és ahol POSIX futatási környezet létrehozható. A legtöbb Linux-terjesztés alá natítv módon a csomagkezelőtvel telepíthető. Ha az nem jó, a Postfx forrásból tvaló installálását a dokumentáció mutatja be.13 Ez azonban csak abban az esetben jatvasolt, ha nem érhető el csomagban, tvagy a használni kítvánt kombináció nem érhető el a terjesztő által elkészítet tváltozatban, pl. olyan komponenseket akarunk használni, amelyek csak forrásból tvaló fordítás után érhetők el.
Tudása: nem csak biztonsági szempontból fgyelemre méltó moduláris felépítése, hanem ennek köszönhetően könnyen illeszthető adatbázishoz. Lehetőség tvan a felhasználók azonosítására a leg-több SQL-szertver használata esetén (de akár a letvelek is tárolhatók SQL-adatbázisban, ha tvalaki-nek ilyen extremitásra tvan igénye). Ugyanilyen könnyen kapcsolható az Amatvis programcsomag segítségétvel a különböző spam- illettve tvírustvédelmi megoldásokhoz is. A nagyon részletes funk-ciólista az interneten tekinthető meg.14 Fontos totvábbi előnyt jelent, hogy a Postfx ugyanolyan jólmegállja a helyét a kistvállalati környezetben, napi 100-200 letvél forgalmazása esetén, mint nagy-tvállalati környezetben, ahol a tvele szemben támasztot igény akár 80-150e átmenő e-mailtől indul. A Postfx rétegződéséről és felépítéséről it15 találhatunk információt. Két főbb konfgurációs fájllalrendelkezik: a master.cf határozza meg, hogy hogyan kapcsolódjanak egymáshoz a letvelek küldé-séhez, fogadásához, postaládába helyezéséhez tvagy a különböző ellenőrzésekhez használt kom-ponensei, a main.cf-ben pedig a Postfx paraméterezését találjuk. A későbbiekben tvegyesen hol a main.cf-ben, hol pedig szükség esetén a master.cf-ben fogjuk állítani a szükséges dolgokat.
A Postfix fontosabb beállításaiNézzük tehát, hogyan is lehet egy átlagos kis- és középtvállalkozás számára használhatótvá tenni
a Postfxet. A kiindulási alapunk, hogy már akár 50 felhasználó felet praktikus lehet összekap-csolni adatbázissal, de a konfgurációs példák tartalmazni fogják a normál felhasználókkal és adat-bázis-kapcsolatal felépítet használatot is (az általános rész után található meg), pontosan azért, hogy mindenki a saját ízlése és igényei szerint tudja használni.
Eredendően az MTA-k egy e-mail tartományba tartozó felhasználók letvelezését kezelték, ekkor logikus tvolt, hogy a címzetek tvalódi, létező felhasználók legyenek a letvelezőszertverként működő gépen. Ma persze már majdnem minden letvelezőszertver nem csak egy, hanem több (több száz, ezer) domain letvelezéséért felel, ezért logikusan a különböző tvirtuális domainekhez tartozó fel-használókat nem lehet az operációs rendszer felhasználóiként beállítani. (Hogyan kezeljek köny-nyedén két Kotvács János netvű felhasználót?) Ezért ma a tvirtuális domainek tvirtuális felhasználóira tvonatkozó információkat különböző adatbázisokban szokták tárolni, és a letvelező-szertverek leggyakrabban onnan tveszik elő az információkat.
A Postfx telepítése (amely Ubuntu és Debian rendszerekben az apt-get install postfix parancs ki-adását jelenti) és egy párbeszédalapú minimális konfgurálás után az MTA üzemkész. Az alap-
1 12. http://www.postfix.org/docs.html1 13. http://www.postfix.org/INSTALL.html1 14. http://www.postfix.org/features.html1 15. http://www.postfix.org/OVERVIEW.html
10
Vállalati letvelezés, spamszűrés és tvírusszűrés
konfguráció egy átlagos szertver, tvagy hálózati átjáró esetén teljesen jól használható, természete-sen csak az alaptvető funkciókkal.
Alap telepítés esetén a kötvetkező beállításokat érdemes megadni. Kezdjük a beállításokat a /etc/postfx/main.cf állománnyal. Gyári beállítása Ubuntu 12.04 LTS esetén tartalmazza a kötvetke-ző sort:
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
Ezzel mondhatjuk meg, hogy az SMTP banner mi legyen, azaz hogy a kültvilág felé minek mutas-suk magunkat. Célszerű ezt megtváltoztatni, legalább az operációs rendszer típusát letvenni. Bár sok esetben az nmap parancs OS fnger funkciója is meg tudja mondani (tippelni), hogy egy (Ubuntu) Linuxot használunk, de a „Security by Obscurity” gondolkodásmód mentén haladtva, elég ha mindenki csak annyit tud rólunk, amennyit feltétlen szükséges. Így ha ezt a tváltozót $my-hostname ESMTP $mail_name értéken hagyjuk, az éppen elégséges. (Az ESMTP szötvegrész tviszont szükséges, fgyeljünk rá.)
myhostname = mail.cegnev.hu
Ide írjuk a tényleges netvét a gépnek. Illik fgyelni, hogy – mint majdnem minden hálózatot hasz-náló szoftvernél – a használt hálózati netvek és IP-címek összerendelése korrekten (és konziszten-sen) legyen megoldtva.
alias_maps = hash:/etc/aliasesalias_database = hash:/etc/aliases
A fenti paraméterek mondják meg, hogy milyen címzeteket fogad el a gép – azaz it az elfogad-ható e-mail címeket sorolhatjuk fel. Tipikusan ilyenek az elterjedten használt webmaster, post-master, hostmaster, stb. címek, és aliasból irányítják konkrét felhasználóhoz a letveleket. Az alias_maps lehet lokális állomány, tvagy hálózaton keresztül elérhető (pl. SQL-lel, LDAP-protokol-lal elérhető adatbázis) is. Ha lokális állományt (is) használunk, akkor a helyi fájl (amiben felsorol-juk az aliasainkat) módosítása után adjuk ki a sudo /usr/bin/newaliases parancsot, ezzel készítünk belőle egy (a példa szerint) hash formátumú adatbázist, amely indexszel ellátot, ezzel gyorsítja a Postfx számára a keresést. (A newaliases parancs egyike a Sendmail-kompatibilis parancsoknak, használható helyete a Postfx saját postalias parancsa.) Lényeges különbség, hogy az alias_maps-ben megadot helyeken keresi a Postfx az aliasok feloldását, míg az alias_database-ben adjuk meg,hogy melyek azok az adatbázisok, amelyeket módosítás után újra kell építeni a newaliases pa-ranccsal. Ezek értelemszerűen lokális (hash, tree, dbm tipusú) fájlok, míg tátvoli – pl : NIS, SQL tvagy LDAP elérésű – adatbázisnál erre nincs szükség – sőt lehetőség sem.16,17
virtual_maps = hash:/etc/postfix/virtual
amennyiben nem csak egy, hanem több domainnek akarunk letvelezést biztosítani, akkor a tvirtual állományban sorolhatjuk fel, hogy a Postfx milyen domain nétvre hallgasson még és a tvirtualban felsorolt e-mail címek mely felhasználóknak, tvagy e-mail címeknek legyenek totvábbíttva. Egy ilyen tvirtuális tábla felépítése tvalahogy így néz ki:
[email protected] [email protected] [email protected]@masodikdomain.hu [email protected]@masodikdomain.hu [email protected]
1 16. http://readlist.com/lists/postfix.org/postfix-users/1/5058.html1 17. http://readlist.com/lists/postfix.org/postfix-users/1/5060.html
11
Vállalati letvelezés, spamszűrés és tvírusszűrés
@masodikdomain.hu summ-username18
A felhasznalo1 e-mail cím egy létező, a felhasználói adatbázisban szereplő személyhez tartozik –neki a bejelentkezési netve szerepel a jobb oldalon; felhasznalo2 pedig igazából egy másik domain-be tartozik, és erre a címre lesznek totvábbíttva a bejötvő letvelei. Ahogyan az alias esetében, a tvirtu-al esetében is szükség tvan az indexek elkészítésére és tváltozás esetén a frissítésükre is, amelyet a kötvetkezőképpen tudunk tvégrehajtani :
postmap /etc/postfix/virtual
fontos, hogy a tvirtual-ban elhelyezet új felhasználó csak a DB frissítése után lesz értvényes.
mail_spool_directory = /var/spool/mail
Ezzel a beállítással rögzítjük, hogy a felhasználók Inbox állományai hol tárolódjanak. Alapeset-ben érdemes így hagyni, hacsak lemeztelítetség, tvagy I/O teljesítmény miat nem akarjuk másho-tva helyezni.
mailbox_command = /usr/bin/procmail
A bejötvő letvelek postafókba tételét a procmail programra bízzuk. Mitvel a procmail nem része a Postfxnek, így ha ezt az opciót használjuk, akkor előte telepíteni is kell a rendszerre. Utána tvi-szont, mielőt a felhasználó postfókjába kerülne a letvél, a procmail segítségétvel különböző feltéte-lek alapján a bejötvő letveleket különböző mappákba szortírozhatjuk, automatikusan törölhetjük, másik postafókba totvábbíthatjuk és még egy sereg egyéb trükköt megtehetünk.
mydestination =mail.cegnev.hu, localhost.localdomain, localhost
megmondhatjuk az SMTPD-nek (ennek a programnak a feladata a hálózaton keresztül, SMTP-pro-tokollon keresztüli letvélfogadás), hogy milyen domain netveket tekinthet saját magának, azaz melycímek esetén legyen helyi kézbesítés (local delitvery).
relayhost = relayserver.cegnev.hu
Ezt az opciót csak akkor használjuk, ha rendelkezünk relay-szertverrel19, és a használata célszerű tvagy kötelező. Elsősorban kis cégek esetén jatvasolt, akik az internetszolgáltatójuk letvelezőszertve-rén keresztül küldik a letveleket – és it ezt a szertvert kell megadni. Jellemzően egy átlagos céges felépítés esetén, ahol tvagy co-locationben tvagy DMZ-ben, tvagy esetleg több hálózati csatoló ese-tén belső-külső lábon mi szolgáltatunk letvelezést, ot mi tvagyunk mások számra a relayhost, így ot ezt az opciót töröljük.
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128,!172.20.1.58, 172.20.1.0/24
Meghatározhatjuk, hogy honnan fogadja el a küldendő letveleket. Azaz az it rögzítet hálózatok azonosítás (autentikáció) nélkül küldhetnek rajtunk keresztül letveleket. Éppen ezért érdemes ki-használni a Postfx rugalmas lehetőségeit, és csak akkor adjuk meg az egész IP-címtartományt, ha tvalóban minden cím a felügyeletünk alat áll. Egyéb esetekben felsorolás jelleggel adjuk meg az IP-címeket. (A példából kikötvetkeztethető, hogy balról jobbra értelmeződnek a bejegyzések, és a felkiáltójellel kizárhatok a – későbbi – listából elemeket.) Ha sok címet akarnánk megadni, az át-
1 18. Ide fog minden olyan letvél megérkezni, amelyhez előte nem defniáltunk címet, tehát az elcímzetek is mint pl: [email protected] helyet ha tvalaki a [email protected] -ra ír, akkor az a summ-username accountba fog megérkezni.
1 19. a relay-szertver olyan gép, amelyik mások helyet a letvéltotvábbítást tvégzi (jellemzően az internetszolgáltatók nyújtanak ilyen szolgáltatót a saját ügyfeleiknek); technikai megközelítéssel: relay az, aki áttvesz olyan letvelet, ami nem neki szól, és totvábbítja a tvalódi címzetnek
12
Vállalati letvelezés, spamszűrés és tvírusszűrés
láthatóság érdekében használhatunk it is (az aliases-hez hasonló) MAP20 állományt és felsorolhat-juk abban a címeket.
mailbox_size_limit = 51200000message_size_limit = 10240000
Rögzíthetjük a rendszerben letvő postafókfájl méretét (byte-ban), illettve megmondhatjuk az egyes üzenetekre, hogy mekkora maximális méretű átmenő letvelet fogadunk el. Érdemes ezeket az értékeket a tvégfelhasználók felé is jelezni, hogy a letvelezőszolgáltatást ne tekintsék FTP-nek, tvalamint készüljenek fel arra, hogy a postafókok mérete sem tvégtelen, azaz rendszeresen takarí-tani kell. (Nem túl régen találkoztunk felhasználótval, aki 70 MB-nál kicsit nagyobb letvelet próbált küldeni, de a kapot hibaüzenet hatására sem tet le erről.)
inet_interfaces = all
Megmondhatjuk, hogy a Postfx mely hálózati csatolókon látszódjon, pl. több interface megléte esetén (tűzfal, DMZ,stb)
body_checks = regexp:/etc/postfix/body
Megadhatjuk, hogy a Postfx a letvél tartalmában szabályos kifejezéseket21 használtva keressen, ésezek segítségétvel döntsön a letvél elutasítása tvagy beengedése mellet, illettve meghatározhatjuk, hogy milyen üzenetel utasítsa el pl. a nem megengedet kiterjesztésű fájlokat tartalmazó letvele-ket.
Egy példa a /etc/postfx/body tartalmára:
/^Content-(Disposition|Type).*name.*=.*"?(.*\.(bat|c[ho]m|cmd|exe|pif|scr|hta|jse?|vb[esx]|wav|mov|avi|mpe?g|mp3))"?$/ REJECT Some file extension in the attachment is not allowed
/^.*?name.*=.*"?(.*\.(bat|c[ho]m|cmd|exe|pif|scr|hta|jse?|vb[esx]|wav|mov|avi|mpe?g|mp3))"?$/ REJECT Some file extension in the attachment is not allowed
/^begin \d\d\d .*\.(vbe|vbs)/ REJECT/kozossegiweboldalak.com/ REJECT Message content rejected.
A példák a feltételben megadot regexp-illeszkedés esetén utasítják el a letvelet, a REJECT szó mögé írt indoklással.
Az első példa esetén ha a letvélben tvalahol szerepel egy sor, ami a Content-Disposition tvagy Content-Type szötveggel kezdődik, tvalahol egy „name” szócska kötveti (nagy eséllyel tehát tvala-mely fájlnétv hitvatkozás), majd egy egyenlőségjel, ami után némi egyéb (meg nem határozot ka-rakterek) után a .bat, .com, .chm, .cmd, .exe, (és így totvább) szötvegek tvalamelyike kötvetkezik, akkor a fájlkiterjesztés tiltására tvonatkozó hibaüzenetel el kell utasítani a letvelet. (Ilyen Content-Type jellegű sorokat jellemzően csatolmányok küldése esetén lehet találni a letvélben.)
A második példa tulajdonképp ugyanez, csak még a Content-Type részt sem igényli.
A harmadik példa a ma már nem túl elterjedten használt UUEncode-kódolású fájlátküldés eseténis észretveszi ha gyanús (.tvbe és .tvbs) kiterjesztésű fájl tvan a letvélben, és elutasítja azt.
1 20. http://www.postfix.org/postconf.5.html#mynetworks1 21. A Postfx fordításakor beállítható, hogy a szabtványos, POSIX-kompatibilis (az egrep parancs által használtnak
megfelelő) regexp implementáció mellet lehessen-e a Perl-ből ismert un. PCRE-tverziót is használni. Ha az rendelkezésre áll, akkor a regexp: helyet a pcre: írandó, és annak szintaxisa használható, ám ehhez külön támogatás telepítése szükséges Debian/Ubuntu alat a Postfxhez.
13
Vállalati letvelezés, spamszűrés és tvírusszűrés
Az utolsó példa pedig minden olyan letvelet el fog utasítani, melyben bárhol szerepel a „kozos-segiportal.hu” szötveg. Ezzel könnyedén elérhető, hogy minden, az adot oldalra hitvatkozó linket tartalmazó letveleket tvisszautasítsuk. (De még ha csak megemlítik a letvélben, már az is elég.)
Totvábbi reguláris kifejezéseket használó szűrési lehetőségek it22.
Postfix nagyobb helyenAhogyan a tűzfalaknál is elmondható, a letvelező szertvereknél is tvannak közel egyenrangú meg-
oldások (azaz ugyanaz a projekt megtvalósítható Exim tvagy Postfx segítségétvel is hasonlóképpen),de alaptvetően az aktuális szituáció, az aktuális és a tertvezhető jötvő határozza meg, hogy hogyan érdemes felépíteni egy MTA-t. A fenti konfgurációt könnyen átalakíthatjuk, ha igény mutatkozik arra, hogy a felhasználókat tvalamilyen adatbázisból keressük ki. Ez lehet tvalamilyen hagyomá-nyos, SQL-nyeltven kezelhető lokális tvagy tátvoli adatbázis (kezdtve a MariaDB-tvel tvagy MySQL-lel, folytattva a PostgreSQL-en át akár zárt adatbázis-kezelőkig), de komolyabb cég esetén akár LDAP-alapon elérhető címtár is. Címtár alat nem csak az ismertebb AD-t kell érteni, hanem az alaptvetően ugyanazt a funkciót nyújtó szabad szoftveres címtárakat (OpenLDAP, OpenDJ), illettve bármilyen egyéb akár zárt termékként elérhető címtárat. Ebben a dokumentumban a Postfx és a címtár használatát nem tárgyaljuk, akit érdekel, kezdetnek a Postfx dokumentációban23 oltvasson utána.
A MariaDB/MySQL és a Postfix kapcsolataMire is jó ez? Tipikusan az olyan esetekben, amikor tudható, hogy több száz, tvagy ezer felhasz-
náló fogja használni azonnal tvagy akár csak belátható időn belül a rendszerünket, akkor érdemes átgondolni, és egy rugalmasabban alakítható alap rendszert létrehozni. Azaz később sokkal ketve-sebbet kell majd a skálázhatósággal foglalkozni, ha az elején olyan rendszert tertvezünk, amely működik 1, de akár 100000 tvagy több felhasználótval is. Hiszen később már „csak” a hardtverkörnye-zetet kell hozzáigazítani. A Postfx támogatja az SQL adatbázisban tárolt felhasználókat, így most kifejezeten csak azokat a paramétereket taglaljuk ebben a részben, amelyeket az SQL-lel és kifeje-zeten a MySQL-lel/MariaDB-tvel tvaló összekötés kapcsán kell a telepítés utáni felálláshoz képest megtváltoztatni:
Az alaptelepítést egészítsük ki a kötvetkezőkkel :
apt-get install postfix-mysql mysql-client mysql-server
Ha MySQL helyet MariaDB-t használnánk, az adatbázis-fejezetben leírtak szerint telepítsük a MariaDB-t (apt forrás hozzáadásátval) de ugyanúgy a postfx-mysql csomagot rakjuk fel (apt-get install postfix-mysql). (Jelenleg a MySQL és a MariaDB egymással olyan szinten kompatibilisek, hogy nincs is külön csomag a Postfx–MariaDB-kapcsolathoz.) Az SQL szertver beállításai közöt adjuk meg az adatbázis-adminisztrátor (hagyományosan: root) felhasználó tválasztot jelszatvát, amelyet a telepítő szkript kérni is fog. A jelszó legyen minimum 12-20 karakter hosszú, lehetőleg erre szolgáló eszközzel generált (pl : pwgen24).
1 22. http://www.jeffborders.com/techdocs/postfix/body_checks.html1 23. http://www.postfix.org/LDAP_README.html1 24. Mitvel a legtöbb disztribúcióban elérhető parancsnak gyakorlatilag nincs saját honlapja, ezért az eltvi
14
Vállalati letvelezés, spamszűrés és tvírusszűrés
Ezt kötvetően ki kell alakítani a felhasználók és a tvirtuális felhasználók számára az SQL adatbá-zist. Hozzunk létre egy adatbázist, amely stílszerűen mail nétvre hallgasson. (Persze bármi lehet, deebben a példában ezt használjuk, etől eltérő adatbázisnétv esetén értelemszerűen a parancsokban a netvet megfelelően módosítsuk!) Példánkban a MySQL binárisát fogjuk hítvni, de természetesen minden ugyanúgy működik MariaDB esetében is.
mysql -u root -p
Majd a MySQL shell-ben:
CREATE DATABASE mail;USE mail;
GRANT SELECT, INSERT, UPDATE, DELETE ON mail.* TO 'mail_admin'@'localhost' IDENTIFIED BY 'mail_admin_password';
GRANT SELECT, INSERT, UPDATE, DELETE ON mail.* TO 'mail_admin'@'localhost.localdomain' IDENTIFIED BY 'mail_admin_password';
FLUSH PRIVILEGES;
Ezekkel létrehoztuk az adatbázist, majd jogosultságot és jelszót állítunk be a mail_admin fel-használó számára, szigorúan lokális kapcsolódás esetére. Természetesen ha másik gépen tvan az adatbázis, akkor a GRANT parancsot megfelelően paramétereztve akár IP-cím alapján is állítha-tunk be az adatbázishoz kapcsolódási jogot.
CREATE TABLE domains (domain varchar(50) NOT NULL, PRIMARY KEY (domain) );CREATE TABLE forwardings (source varchar(80) NOT NULL, destination TEXT NOT
NULL, PRIMARY KEY (source) );CREATE TABLE users (email varchar(80) NOT NULL, password varchar(20) NOT NULL,
PRIMARY KEY (email) );CREATE TABLE transport (domain varchar(128) NOT NULL default '', transport
varchar(128) NOT NULL default '', UNIQUE KEY domain (domain) );quit
A fenti utasításokkal létrehozzuk a tvirtuális domainek és a totvábbítandó felhasználók adatáblá-ját. Az SQL részétvel készen tvagyunk. (Kiegészítés: fenti adatbázisfelépítés kis, közepes méretű cégesetén alkalmas. Nagyobb felhasználószám esetén érdemes lehet ezt az adatbázisstruktúra felépí-tésekor értvényre jutatni. Azaz nem egyetlen users táblában tárolni az összes e-mail címet, hanemaz egyes tvirtuális domain-ek tvirtuális felhasználóit külön-külön táblában. Természetesen ezt nem csak a fenti adatbázis létrehozó parancsoknál, hanem a később szereplő adatlekérdező parancsok-nál is fgyelembe kell tvenni, és azokat is megfelelően módosítani kell.)
A fenti paramétereket (admin, jelszó, adatbázis netve) rögzítenünk kell a Postfx számára is. Hoz-zuk létre a /etc/postfx/sql-tvirtual_domains.cf állományt, majd írjuk bele a kötvetkezőket:
user = mail_adminpassword = mail_admin_passworddbname = mailquery = SELECT domain FROM domains WHERE domain='%s'hosts = 127.0.0.1
Értelemszerűen a jelszót és ha más felhasználónetvet és/tvagy adatbázisnetvet adtunk meg az adatbázishoz, akkor azokat is cseréljük ki megfelelően. A hosts esetében pedig abból a feltételezés-ből indultunk ki, hogy az SQL-motor a lokális gépen a localhoston elérhetően (alap beállítás sze-rint) működik. Természetesen ha az adatbázis külön tvirtuális tvagy fzikai gépen fut, akkor a
információkért nézzük meg a kézikönytvet (man pwgen), esetleg a windows-os tverzió oldalát http://pwgen-win.sourceforge.net
15
Vállalati letvelezés, spamszűrés és tvírusszűrés
megfelelő biztonsági alapeltveket betarttva adjuk meg a hozzáférést, azaz például az adatbázis- és a Postfx-gép nyílt hálózaton ne forgalmazzon egymás közöt, csak (SSL-lel) titkosítot formában, amelyet a Mysql és a MariaDB is natítvan támogat.25
Ugyanígy hozzuk létre a többi táblához tartozó konfg állományokat :
/etc/postfix/sql-virtual_forwardings.cf
user = mail_adminpassword = mail_admin_passworddbname = mailquery = SELECT destination FROM forwardings WHERE source='%s'hosts = 127.0.0.1
/etc/postfix/mysql-virtual_mailboxes.cf
user = mail_adminpassword = mail_admin_passworddbname = mailquery = SELECT CONCAT( SUBSTRING_INDEX( email, '@', -1 ), '/', SUBSTRING_INDEX( email, '@', 1 ), '/' ) FROM users WHERE email='%s'hosts = 127.0.0.1
/etc/postfix/mysql-virtual_email2email.cf
user = mail_adminpassword = mail_admin_passworddbname = mailquery = SELECT email FROM users WHERE email='%s'hosts = 127.0.0.1
A létrehozot állományok fájljogosultságait állítsuk be 640-ra és a root:postfx user:csoport bir-tokában legyenek (A postfx netvű felhasználói csoportot Ubuntu alat a csomag telepítése automa-tikusan létrehozza, ha az általunk tválasztot terjesztés nem tenné, akkor hozzuk létre kézzel.)
Utána hozzunk létre egy felhasználót, amelynek a könytvtárában fognak tárolódni a tvirtuális fel-használók HOME könytvtárai. Ezt megtehetjük a
groupadd -g 5000 vmailuseradd -g vmail -u 5000 vmail -d /home/vmail -m
parancsok segítségétvel, illettve érdemes átgondolni, hogy a /home alkalmas-e arra, hogy ot több száz tvagy ezer felhasználó könytvtára (adatokkal) tárolódjon. Ha LVM-et használunk, tvagy úgy alakítotuk ki a rendszer, hogy a /home tvárható telítődése megfelelő, akkor nincs más dolgunk a felhasználótval.
Adjuk meg a Postfx számára a már beállítot plusz konfgurációkat, értelemszerűen a dokumen-tum elejében beállítotakhoz képest pluszban, az előzőekhez képest eltérés ezen kítvül, hogy a tvir-tusers állomány helyet SQL-adatbázist fogunk használni. Ezen konfgok rögzítése történhet az eddig megszokot módon (kézzel, szötvegszerkesztőtvel), tvagy pedig a postconf parancs segítsé-gétvel, amely hozzá fogja fűzni a main.cf-hez:
postconf -e 'virtual_alias_domains ='postconf -e 'virtual_alias_maps = proxy:mysql:/etc/postfix/sql-
virtual_forwardings.cf, mysql:/etc/postfix/sql-virtual_email2email.cf'postconf -e 'virtual_mailbox_domains = proxy:mysql:/etc/postfix/sql-
1 25. https://mifosforge.jira.com/wiki/display/MIFOS/How+to+enable+MySQL+SSL+on+Ubuntu
16
Vállalati letvelezés, spamszűrés és tvírusszűrés
virtual_domains.cf'postconf -e 'virtual_mailbox_maps = proxy:mysql:/etc/postfix/sql-
virtual_mailboxes.cf'
Megmondjuk a Postfxnek a domain és a mailbox map SQL konfgjának helyét.
postconf -e 'virtual_mailbox_base = /home/vmail'postconf -e 'virtual_uid_maps = static:5000'postconf -e 'virtual_gid_maps = static:5000'
A felhasználók HOME könytvtárának helyét és UID és GID beállításait rögzítjük.
postconf -e 'virtual_create_maildirsize = yes'postconf -e 'virtual_maildir_extended = yes'postconf -e 'proxy_read_maps = $local_recipient_maps $mydestination
$virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps$sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $virtual_mailbox_limit_maps'
Ha ezzel megtvagyunk, akkor a Postfxet indítsuk újra:
service postfix restart
A rendszernaplóban (Ubuntu 12.04 LTS: /tvar/log/mail.log) meg tudjuk nézni, hogy minden rend-ben ment-e, illettve érdemes a telnet localhost 25 parancs segítségétvel ellenőrizni, hogy a Postfx életjelet ad-e a 25-ös porton.
Ha minden rendben ment, akkor létre kell hozni a felhasználókat.
Belépünk az SQL-motorba, akár parancssor, akár phpMyAdmin segítségétvel:
mysql -u mail_admin -pUSE mail;INSERT INTO domains (domain) VALUES ('sajatceg.hu');INSERT INTO users (email, password) VALUES ([email protected]',
ENCRYPT('password'));quit
Természetesen ezt is érdemes tvagy szkriptelni, tvagy pedig egy webes adminisztrációs felületet készíteni hozzá, amelyet a helyi HR rendszerhez hozzáépíttve delegálható a megfelelő szintre a fel-használó feltvétele, törlése, felfüggesztése, stb. (Legrosszabb esetben pedig egy megfelelő jártasság-gal rendelkező személyre lehet bízni a phpMyAdminon belüli adminisztrációját)
(Mindezt egészítsük ki azzal, hogy hosszú tátvon kifzetődő megoldás a letvelező felhasználók adatainak adminisztratítv kezelését hozzáigazítani az adot szertvezet humánerőforrás-menedzs-ment környezetéhez, és az arra használt eszközbe beilleszteni. Azaz akár a dolgozó munkába állá-sátval egyidejűleg megtörténhet az e-mail adminisztráció – természetesen automatikusan.)
Miután a fenti parancsokkal feltvetük az ügyfélszolgálat letvelezési címét, még egy teendőnk ma-rad. A Postfx a felhasználó könytvtárát akkor fogja létrehozni, ha megérkezik az első letvél. Így mindenképpen célszerű a felhasználó feltvétele után egy üdtvözlőletvelet küldeni a felhasználónak, akár a mailx/mut parancsok használatátval (mailx -s Udv [email protected] < /dev/null, tvagymutt -s Udvozlet [email protected] < /dev/null) tvagy bármilyen egyéb e-mail klienssel, mint pl. a Tunderbird. A naplóban utána nyomon kötvethetjük, célba ért-e a letvél, majd megnézhetjük a postafókhoz tartozó könytvtárak létrejötét. A könytvtár létrehozásáig a felhasználó hiába ren-delkezik értvényes jelszótval, a POP3 és IMAP4 kliens sem fog tudni a netvében intézkedni, ezért is
17
Vállalati letvelezés, spamszűrés és tvírusszűrés
fontos, hogy a próbaletvelet kézbesítsük részére. Az ugyfelszolgalat felhasználó postafókjának könytvtára pedig a kötvetkező nétven lesz létrehoztva: /home/tvmail/sajatceg.hu/ugyfelszolgalat/.
SASLA cél: ugyanazzal a felhasználónétvtvel és jelszótval, SSL hitelesítés segítségétvel lehessen letvelet
küldeni, mint a POP/IMAP-hoz szükséges felhasználói azonosítók. Ehhez a Cyrus SASLAuthd ne-tvű rendszert használjuk. A korrekt működéshez első lépésben beállítjuk a Cyrus SASLAuthd-t úgy, hogy a hitelesítést a PAM-on keresztül az SQL motorból tvégezze el. Majd pedig a már műkö-dő SASLAuthd után a Postfxet26, hogy a felhasználók azonosítását a Cyrus-féle SASLAuthd-n ke-resztül intézze.
A kötvetkezőket kell telepíteni :
apt-get install libsasl2-2 libsasl2-modules libsasl2-modules-sql sasl2-bin libpam-mysql
Mitvel a Postfx saját chroot könytvtárában dolgozik (/tvar/spool/postfx) , ezért létre kell hozni az SASLAuthd-nek a szokásostól eltérő környezetben a könytvtárat:
mkdir /var/spool/postfix/var/run/saslauthd
A /etc/default/saslauthd konfgurációs fájlba pedig beleírjuk a saját paramétereinket:
START=yesDESC="SASL Authentication Daemon"NAME="saslauthd"MECHANISMS="pam"MECH_OPTIONS=""THREADS=5OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd -r"
(Engedélyeztük gépindításkor a SASLAuthd automatikus elindítását, a fentebb létrehozot könytvtár netvét adtuk meg a SASLAuthd számára és jeleztük, hogy PAM-on keresztül történjen az azonosítás.)
Mitvel a SASLAuthd opciói közöt azonosításra a PAM-modult netveztük meg, ezért rá kell beszél-ni a PAM-ot, hogy az SMTP szoftver számára MySQL-ből/MariaDB-ből azonosítson:
Hozzuk létre a /etc/pam.d/smtp állományt a kötvetkező tartalommal (ez 2 igen hosszú sor) :
auth required pam_mysql.so user=mail_admin passwd=mail_admin_password host=127.0.0.1 db=mail table=users usercolumn=email passwdcolumn=password crypt=1
account sufficient pam_mysql.so user=mail_admin passwd=mail_admin_password host=127.0.0.1 db=mail table=users usercolumn=email passwdcolumn=password crypt=1
Értelemszerűen az SQL paramétereket állítsuk be a korábban már megadot értékekre (adatbázis netve, táblák netve, felhasználónétv az adatbázishoz, jelszó).
1 26. A Postfx a Cyrus és a Dotvecot-féle SASL-megtvalósítást támogatja. A postconf -a (SMTP-szertver üzemmód) illettve postconf -A (SMTP-kliens üzemmód) opciókkal ellenőrizhető, hogy a telepítet tverzióban melyik működik.
18
Vállalati letvelezés, spamszűrés és tvírusszűrés
Hozzuk létre a kötvetkező könytvtárat : /etc/postfx/sasl/27 és abban egy állományt: /etc/postfx/sasl/smtpd.conf28, melynek tartalma:
pwcheck_method: saslauthdmech_list: plain login
legyen.
Majd miután elmentjük a SASLAuthd-nek szóló beállításokat, csak az tvan hátra, hogy a Postfx számára is nyiltvántvalótvá tegyük, hogy az SASLAuthd-t fogjuk használni azonosításra. A Postfx-hez tartozó main.cf-be rögzítsük a beállításokat a kötvetkező parancsok segítségétvel:
postconf -e 'smtpd_sasl_auth_enable = yes'postconf -e ‘smtpd_sasl_type = cyrus’
postconf -e ‘smtpd_sasl_path = smtpd’postconf -e 'smtpd_sasl_authenticated_header = yes'postconf -e ‘smtpd_sasl_security_options = noanonymous’postconf -e 'broken_sasl_auth_clients = yes'postconf -e 'smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination'postconf -e 'proxy_read_maps = $local_recipient_maps $mydestination
$virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps$sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $virtual_mailbox_limit_maps'
Az adatbázisból történő autentikációtval tvégeztünk, de a letvelezőszertver éles használata előt még meg kell tanítanunk a Postfxet arra, hogy titkosítot kommunikációt tvégezzen, hiszen most már nagy érték a felhasználó jelszatva és e-mail címe, mitvel segítségétvel majdnem korlátlan meny-nyiségben lehet letvelet küldeni, helytől független módon. A legjobb megoldás tehát, ha SSL-kul-csot készítünk a titkosítot kommunikációhoz.
(Az SSL-lel és tanúsíttványkezeléssel kapcsolatos dokumentum része a keretrendszernek, abban aminimálisan szükséges hátér-információk mellet pár alternatítv eszköz használatát mutatjuk be: az igen ismertnek számító, de fapadosan kényelmetlen OpenSSL parancssori kezelése, és néhány újabb, akár grafkus eszköz. Ezért a kulcsgenerálás ebben a fejezetben meglehetősen tömör, pár lé-péses használata szerepel a dokumentumban.)
Ha még nem tvolt telepíttve, telepítsük a gépre az OpenSSL csomagot:
apt-get install openssl
Készítsük el a szertver tanúsíttványát:
openssl req -new -outform PEM -out smtpd.cert -newkey rsa:2048 -nodes -keyout smtpd.key -keyform PEM -days 730 -x509
A fenti parancs kiadása után az OpenSSL feltesz pár kérdést, amelyre a cég netve, címe stb. alap-ján adjuk meg a megfelelő tválaszokat. Az elkészült smtpd.key és smtpd.cert állományt másoljuk a /etc/postfx/ könytvtárba, majd állítsuk be a Postfx számára is láthatóan az SSL-lel kapcsolatos paramétereket:
postconf -e 'smtpd_use_tls = yes'postconf -e 'smtpd_tls_auth_only = yes'
1 27. Ez az elérési úttvonal Ubuntu esetén értvényes, más terjesztések esetén más lehet (pl. /usr/lib/sasl2)1 28. Noha ez a Cyrus-hoz tartozó konfgfájl, a Postfx main.cf fájljában szereplő smtpd_sasl_path=smtpd határozza
meg, hogy ennek a fájlnak smtpd.conf lesz a netve
19
Vállalati letvelezés, spamszűrés és tvírusszűrés
postconf -e 'smtpd_tls_cert_file = /etc/postfix/smtpd.cert'postconf -e 'smtpd_tls_key_file = /etc/postfix/smtpd.key'postconf -e 'tls_random_source = dev:/dev/urandom'
Végezetül pedig indítsuk újra a Postfxet:
service postfix restart
Hasznos vállalati funkciókHasznos tvállalati plusz funkciók amelyek könnyen kitvitelezhetőek Postfx segítségétvel :
Always BCC :::: a teljes átmenő letvélforgalom nem csak könnyedén naplózható, hanem tárolható is, küldöt és fogadot letvelek napi/heti/hatvi bontásban akár maildir tvagy mailbox formátumban a felhasználó által nem észlelhető módon. Ez a funkció a hatályos magyar törtvények szerint magán-címek esetében (ilyenek a sok helyen használt tvezetéknétv.keresztné[email protected]) csak akkor kapcsolható be, ha az érintetek erről írásban nyilatkoznak (pl. a munkaszerződésük része). Ezen funkció segítségétvel bármikor tvisszaállítható a felhasználó által tvéletlenül tvagy szándékosan letö-rölt letvél – használata természetesen dupla akkora lemezigénnyel jár, mint alapesetben. Ezt az op-ciót is a main.cf-ben kell elhelyezni :
always_bcc = bcc
az = jel után a bcc egy felhasználó netve, akinek postafókjába minden egyes küldöt és fogadot le-tvelet tárol majd a rendszer. Fontos fgyelni arra, hogy a bcc használata esetén, az egész átmenő le-tvelezés miat a megfelelő lemezméretet szükséges biztosítani. Igazán nagy átmenő forgalom esetén célszerű külön lemezre (lehetőleg raid1+0 legyen) tenni a BCC-t, hogy a plusz I/O-műtvele-tek jobban el legyenek oszttva. Totvábbi fontos teendő, hogy a BCC felhasználónak feltétlen Maildirformátumot állítsunk be, mitvel hatalmasra nőhet ez a tároló és nem túl praktikus 1 hatalmas állo-mányban tárolni mindent, tvalamint később mentés és a tvisszakeresés szempontjából is nehézkes ez a megoldás. A BCC megoldás egy dedikált lemez segítségétvel kiegészítheti a hagyományos mentésünket is. Hiszen it minden küldöt és fogadot letvél tároltva tvan (bármi ami átmegy az SMTPD-n, sajnos a nem megfogot spamek is), ezért ha egy felhasználó pont két snapshot közöti időpontban törölt ki egy nagyon fontos letvelet, azt később it meg lehet keresni és totvábbítani szá-mára. A Maildir tárolás esetén reguláris kifejezésekkel, szkriptek segítségétvel, tvagy akár a Mid-night Commander használatátval (keresés – reguláris kifejezések alapján egy adot könytvtár tvagy könytvtár szerkezetben) igen eredményesen lehet a letvelek fejléce tvagy törzse alapján is keresni. Azaz egy szerény tváltozó mögé lehet építeni egy egyedi, akár minősítet kötvetelményeknek is megfelelő hosszútátvú letvéltárolást. Mitvel it minden céges információ tároltva lesz, ami csak átha-lad a letvelezőszertveren, ezért bizonyos esetekben érdemes megfontolni a titkosítot fájlrendszer (pl: Linux loop-aes, FreeBSD Geli, stb.) használatát29, ami tviszont jelentős mértékű plusz CPU, I/O és memória terhelést okoz.
PFLogsumm30:::: egy Perl-program amely napi bontásban kiértékeli az MTA forgalmát. Remek statisztikákat lehet a HR tvagy az ügytvitel számára készíteni tvele. Valamint a rendszermérnökök-nek is hasznos, ugyanis bontásban mutatja a sosem kézbesítet és egyéb okokból elakadt letvelek számát is. Használata igen egyszerű, a telepítés után a Perl szkriptnek paraméterben meg kell adnia kiértékelendő naplóállomány helyét. A kimenetet pedig irányíthatjuk állományba, tvagy akár
1 29. Mindenképpen tartsuk be a helyi adattvédelmi előrásokat.1 30. http://jimsun.linxnet.com/postfix_contrib.html
20
Vállalati letvelezés, spamszűrés és tvírusszűrés
crontab-ból futattva, letvélben kaphatjuk meg. A tvégeredmény egy domainekre és felhasználókra lebontot, részletes és emészthető statisztika.
Munin integráció31:::: a Munin gyári bőtvítmény segítségétvel grafkusan is könnyedén nyomon kötvethetők a csúcsidők, a hírletvél-kiküldések szertverre gyakorolt hatása, illettve ez alapján lehet a működést elemezni, monitorozni.
Disclaimer :::: Postfxben is tvan lehetőség minden letvél tvégére központilag megjegyzéseket fűzni.Általában tvétve ezt Disclaimer-nek hítvjuk. A Postfx remekül együtműködik az Altermime32-mal, amelynek beüzemelése tviszonylag egyszerű.33
Submission port34:::: Postfxben lehetőség tvan az 587-es port megnyitására, amelyet a kliensek-nek adhatunk meg letvél küldésre a 25-ös és a 465-ös port mellé (tvagy helyet). Jelentősége akkor tvan, ha olyan hálózatból kell kliensként letveleket küldenünk, ahol alapesetben a 25-ös és a 465-ös port elérése tilttva tvan (spam- és tvírustvédelmi okokra tvaló hitvatkozással). Ebben az esetben a mas-ter.cf-ben a sor elején álló megjegyzésjel (#) törlésétvel engedélyeznünk kell a
#submission inet n - - - - smtpd
sort és a tűzfalon is utat nyitni számára.
Illesztőprogram, amely összeköti a levelezőszervert, a víruskeresőt és a levélszemét-keresőt (a tényleges konfgurációt egyben lehet megtalálni ennek a fejezetnek a végén, mivel ez a há-rom eszköz: Amavis+spamszűrő+vírusszűrő motor együtműködve értelmezhető a leginkább)
Amavis35:::: egy interfész az MTA és a különböző letvélellenőrző-programok közé ágyaztva, amely biztosítja közötük a gyors kommunikációt. Ha gyors és könnyen kezelhető átjárót szeretnénk az MTA és a letvélfeldolgozó programok közöt, akkor igazi alternatítvája nincs. Átláthatóan konfgu-rálható, nagy teherbírású program, amelyet Perlben írtak. Beépítet tvédelemmel rendelkezik az esetleges diszktelítetség, tvagy diszk I/O-hibából eredő eseményekre. Dkim aláírás támogatással rendelkezik és természetesen GPL licencelésű.
Vírus és spam elleni védelem: azok az idők tvélhetően tvisszatvonhatatlanul elmúltak, amikor egy szertvezet letvelezése tvírus- és letvélszemét-tvédelem nélkül elképzelhető tvolt. A tvírustvédelem még a szabad operációs rendszerek alat is tanácsos, hiszen a szertverekhez kapcsolódó kliensek le-hetnek tvédtelenek is, tvalamint a szertverre beérkező letveleket első tvonali tvédelemmel elláttva, köz-pontilag szabályoztva azok szűrését sokkal tvédetebbé tehetjük hálózatunkat. Az első tvonali tvédekezés pedig az esetek túlnyomó többségében egyszerűbb és hatékonyabb is. Több megoldás istalálható:
– Greylisting
– Dspam36
– Anti-Spam SMTP Proxy Sertver37
– SpamBayes38
1 31. http://munin-monitoring.org/1 32. http://www.pldaniels.com/altermime/1 33. http://www.howtoforge.com/add-disclaimers-to-outgoing-emails-with-altermime-postfix-debian-etch1 34. http://en.wikipedia.org/wiki/Mail_submission_agent1 35. http://www.ijs.si/software/amavisd/1 36. http://dspam.nuclearelephant.com/1 37. http://sourceforge.net/projects/assp/1 38. http://spambayes.sourceforge.net/
21
Vállalati letvelezés, spamszűrés és tvírusszűrés
– Bogoflter39
– Clapf40
– SpamAssasin41
Greylisting: a szürkelista nétvre is hallgató mechanizmus lényege, hogy egy adot címről érkezőletvelet a letvelezőszertver azonnal tvisszautasít egy ideiglenes hibára utaló jelzéssel. A szabtványos működésű SMTP-szertverek az ilyen hibakóddal tvisszautasítot letvelet némi késlekedés után újra-és-újra megpróbálják kézbesíteni. A fogadó oldal pedig egy meghatározot idő eltelte után elfo-gadja a letvelet. Mitvel általában tárolódik, hogy kitől fogadtunk el letvelet, ezért nem az összes, csakaz első (pár) letvél késleltetése szembeötlő. Viszont a spamek jó része nem szabtványosan tviselkedő szertverektől jön akik a nagyobb hatékonyság érdekében általában nem túl szabtványosak (ezért pl. meg sem kísérelnek ilyenkor újraküldeni), így ezzel a technológiátval nagy részüktől meg lehet szabadulni. Komoly hátulütője a technológiának, hogy a felhasználók hite szerint a letvelezés azon-nali üzenetotvábbítást jelent, így mondjuk már egy 30 perces tvisszautasítást nem tolerálnak. Postfxhez használható a Postgrey netvű eszköz, amely alapbeállításban 5 perces tvisszautasítási időtvel dolgozik. Ismert trükk, hogy az elején a szokásos letvelezőpartnerek címének megtanulásá-hoz rötvid – mondjuk 1 perces – időintertvallumot tválasztunk, és csak a későbbiekben, a kezdő adatbázis elkészülte után emeljük meg a tvárakozási értéket, de akkor se nagyon legyen 10 percnél több.
Dspam: Készítője Jonathan A. Zdziarski, a program 99,5–99,95%-os találati pontossággal műkö-dik. Gyors reagálás és nagy teherbírás jellemzi, azonban a jó eredmény eléréséhez folyamatos ta-nítást igényel. Hátránya, hogy lokális adatbázisban tárolja a betanítot mintákat, amelyben egy időután nehézkesen és lassan tud keresni.
Anti-Spam SMTP Proxy Server: egy 2003 óta fejlesztet nyílt forráskódú, GPLtv2 licencű Perl SMTP proxy, amely a kötvetkező tulajdonságokkal bír : Bayes-szűrés42, feketelista (DNSBL43), SPF44, SRS45, szürkelista46. Felróható hátrány: relatítv kisebb felhasználói bázis és ebből eredően a támoga-tói fórum is szűkebb körű a többihez tviszonyíttva.
SpamBayes: Python programozási nyeltven írta Paul Graham, a Bayes-szűrés kidolgozója. Mű-ködési módszere, hogy 3 halmazba szertvezi a beérkezet letveleket, az első halmaz a spam, a máso-dik a normál letvél (sűrűn használt elnetvezéssel: HAM), a harmadik amelyről nem tudja, hogy az első kető közül melyikbe tartozzon. A program előnye, hogy relatítv ketvés hamis pozitítv és hamis negatítv eredményt ad, tviszont a 3. kategóriába eső letveleket a felhasználónak kell minősítenie. Hátránya, hogy így a felhasználóra relatítv több manuális munka jut.
Bogoflter: egy szintén Bayes-szűrést alkalmazó nyílt forráskódú, C programozási nyeltven írt letvélszemétszűrő, melyet Eric S. Raymond fejlesztet ki. Könnyen használható akár asztali környe-zetben is, azonban szertver környezetben probléma léphet fel a párhuzamos tvizsgálatok során, ugyanis egyedileg a felhasználó szkriptel (procmail segítségétvel) indítja. Létezik hozzá milter-interfész is, amelynek segítségétvel eredendően Sendmail, újabban Postfx alá is beépíthető.
1 39. http://bogofilter.sourceforge.net/1 40. http://clapf.org/wiki/doku.php/start1 41. http://spamassassin.apache.org/1 42. http://en.wikipedia.org/wiki/Bayesian_spam_filtering1 43. http://en.wikipedia.org/wiki/DNSBL1 44. http://en.wikipedia.org/wiki/Sender_Policy_Framework1 45. http://en.wikipedia.org/wiki/Sender_Rewriting_Scheme1 46. http://en.wikipedia.org/wiki/Greylisting
22
Vállalati letvelezés, spamszűrés és tvírusszűrés
Clapf: magyar fejlesztésű (Sütő János), tviszonylag újnak számító statisztikai szűrő. PHP-ben készült, Postfxhez és Eximhez illeszthető, illettve a lokális letvélkézbesítési fázisban pl. a procmail (később még lesz róla szó) segítségétvel tulajdonképp bármilyen letvelezőrendszerhez.
SpamAssasin: egy ún. „pontozásos” rendszerben működő letvélszemétszűrő, amely az Amatvisd segítségétvel kapcsolható az MTA-hoz. Többszörösen díjnyertes, Perl nyeltven íródot, az e-mailek elemzésétvel, kulcsszatvak, írásstílusok, és sok egyéb jel fgyelésétvel, feketelistákkal, tvalamint a Ba-yes-szűrés módszerétvel operáltva próbálja megállapítani egy letvélről, hogy átengedhető-e tvagy sem. A program nagyjából ezer különböző tesztnek tvet alá minden e-mailt. Ezek a tesztek az e-mailek tartalmát, felépítését, szabtványosságát, méretét, képek, mellékletek elhelyezkedését, a letvélkorábbi állomásait tvizsgálják át, meghamisításra utaló jeleket keresnek, és még sok mást is tvizs-gálnak. A tesztek pontozása alapján az előre beállítot érték szerint hozza meg a döntést. A ponto-zás alap értékei 4-5 közöt szoktak lenni, amely például a kötvetkező tényezőkből állhat össze:
– MISSING_SUBJECT: 2,5 pont : nincs az üzenetnek tárgya
– NUMERIC_HTTP_ADDR: 0,9 pont: numerikus IP-cím egy URL-ben
– BAYES_00: -2,6 pont : A Bayes-szűrés szerint egyértelműen ham – azaz jó – letvél
– BAYES_99: 3,5 pont : A Bayes-szűrés szerint egyértelműen spam – azaz rossz – a letvél
– URIBL_BLACK: 2,0 pont: Egy a letvélben szereplő URL szerepel az URIBL feketelistán
– RCVD_IN_BL_SPAMCOP_NET: 2,2 pont: a letvél olyan állomáson haladt keresztül, amely meg-található a SpamCop feketelistán.
Ugyanilyen pontozás alapján dönt a hamisítot fejlécű e-mailekről (leggyakoribb előfordulása, amikor a címzet látszólag saját magától kap 3. féltől letvelet). A Spamassassin-szűrő SPF (Sender Policy Framework) ellenőrzést is tvégez. Rengeteg kiegészítő kapcsolható hozzá, amelyek haszná-lata ajánlot is, ilyenek pl. a dcc-client,47 pyzor48, razor49 tvagy PFassassin, SpamAssassin Rules Em-porium50, tvagy a FuzzyOCR51. Mitvel Perl nyeltven íródot – amely nem kifejezeten a teljesítményre tvaló kihegyezés ismértve – a program memóriaigényes, de a memóriaigény jól szá-molható. Létezik hozzá több adminisztráció frontend, webes felület, ahol mindenki felhasználóba-rát módon saját maga tudja az amúgy az átlagosnál bonyolultabb szabályrendszerét állítani. Ilyen pl. a SquirrelMail-be integrálható bőtvítménygyűjtemény, illettve könnyű hozzá egyedi PHP-alapú tvégfelhasználói felületet létrehozni (bár ez feltvethet némi kockázatot).
A letvélszemétszűrők közöt egészen más szempont szerint kell tválasztanunk, mint az MTA ese-tében, ahol sok, nagyjából egyenlő tudású MTA közöt kell döntést hozni. A tválasztás a SpamAs-sasin-ra eset, tekinttve, hogy az összes közül a legjobban és legegyszerűbben integrálható, tanítható és kezelhető, totvábbá a legtöbb módszert alkalmazza a letvélszemét felderítési mechaniz-musában. A támogatotsága a felhasználói fórumok számát tekinttve a legnagyobb és a legtöbb ext-ra szolgáltatás ehhez kapcsolható.
1 47. http://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_Plugin_DCC.html 1 48. http://sourceforge.net/apps/trac/pyzor/ 1 49. http://en.wikipedia.org/wiki/Vipul%27s_Razor 1 50. http://sourceforge.net/projects/sare/ 1 51. http://wiki.apache.org/spamassassin/FuzzyOcrPlugin
23
Vállalati letvelezés, spamszűrés és tvírusszűrés
Víruskereső programokÖnmagában a letvélszemétszűrés nem elegendő, bár rendszeresen tapasztalható, hogy a letvélsze-
mét kiszűrésétvel tetemes mennyiségű tvírusos letvéltől lehet megszabadulni. Mára a Linux és BSD-rendszerű operációs rendszerek is tvonzó célpontot jelentenek a tvíruskereső szoftvereket fejlesztő cégek számára. Számos zárt termék integrálható a letvélszűrés folyamatába, azonban jellemzően ezek kereskedelmi felhasználásra jogdíjkötelesek.
ClamAV52:::: parancssori alapú több szálon működő tvíruskereső, amely képes a legtöbb tömörítetfájlban ellenőrizni, illettve ELF (futatható) binárisok tvizsgálatára is. Vizsgálni tudja totvábbá az MS termékpaleta legtöbb dokumentumformátumát. Naponta többszöri frissítés érkezik a központi adatbázisból (alapbeállítás szerint 15 percenként); az egyik leggyorsabban reagáló csapat, amely gyorsaság eredménye, hogy néha hozhat hamis pozitítv eredményt is. A ClamAV tvírus-adatbázisa publikusan megnézhető.53 Számos grafkus frontend létezik hozzá, amely segítségétvel asztali gé-pen, illettve szertvereken, Samba megosztásokon is használhatjuk, pl : KlamAV, ClamTk, AVScan GTK, ClamWin. Része a legtöbb Linux terjesztésnek, és jól kapcsolható az előbbiekben felsorolt szoftverekhez. Könnyen beállítható és logikus felépítésű konfgurációs állomány jellemzi. Fontos tudni azonban, hogy a ClamAV-ot 2007-ben felvásárolta a Sourcefre, amely megszerezte a ClamAVcsapat öt tvezető tagjának szerzői jogait, magát a projektet és a hozzá kapcsolódó márkanetveket, tvédjegyeket is. Ezen felül hozzá kerülnek a ClamAV.org domain feleti jogok, a weboldal tartalma és a SourceForge-os ClamAV projektoldal is. Akkor a ClamAV core fejlesztői folytaták a munkát, mint a Sourcefre alkalmazotai. Ugyanakkor a ClamAV licencelése GNU GPLtv2.
A legnépszerűbb zárt termékek Linuxra
AVG Free for Linux54:::: parancssori felületel rendelkezik, othoni felhasználásra 1 gépig ingye-nes.
BitDefender55:::: parancssori felületel rendelkezik, othoni felhasználásra ingyenes.
Avast for Linux56:::: parancssori felületel is rendelkezik, othoni felhasználásra ingyenes.
Kaspersky57:::: a linuxos tverzióiból csak próba (trial) tverzió érhető el ingyenesen, a tvállalati fel-használása fzetős.
Összességében elmondható, hogy othoni tvédekezésnek, pl. másoktól kapot dokumentumok, USB-kulcs stb. ellenőrzésére kitválóak, azonban ingyenes szertver felhasználásuk jogi okokból nem lehetséges.
Gyakorlatilag alternatítva nélkül a ClamAV tvíruskereső ajánlható jelenleg. Összességében azon-ban bátran használható, hiszen cégek kereskedelmi forgalomban létvő csomagolt termékeinek a si-keres alapja. A kezdetektől biztosítot a program életút (folyamatos distupgrade lehetőség a kezdetektől), a frissítés, személyre szabhatóság és a könnyű illesztés az egyedi szűrőkhöz, illettve a ClamAV tvírus-adatbázis központ országonként tválasztható.
1 52. http://www.clamav.net/lang/en/1 53. http://lurker.clamav.net/list/clamav-virusdb.html1 54. http://free.avg.com/us-en/download.prd-alf 1 55. http://www.bitdefender.com/business/antivirus-for-unices.html 1 56. http://linux.softpedia.com/get/Security/avast-Linux-Home-Edition-43586.shtml 1 57. http://www.kaspersky.com/products/business/applications/endpoint-security-linux
24
Vállalati letvelezés, spamszűrés és tvírusszűrés
Amavis+ClamAV+SpamAssasin konfigurálásKonfguráljuk tehát az Amatvis+ClamAV+SpamAssasin hármast:
apt-get install amavisd-new spamassassin clamav-daemon arj unarj bzip2 cabextract cpio file gzip lha nomarch pax rar unrar unzip zip zoo
A parancs kiadása után települni fog a rendszerünkre az Amatvisd, a ClamAV és a SpamAssassin,magukkal hoztva a szükséges függőségeket is (tvalamint nagyon sokféle elterjedt és nem annyira elterjedt tömörítőprogramot), így ne ijedjünk meg, ha azt látjuk a telepítő nagyon sok csomagot kezd el tölteni és beállítani. Az ubuntus telepítő parancsfájl létre fogja hozni a szükséges felhasz-nálókat, így nekünk már csak sorban be kell állítanunk a fenti szoftvereket.
Kezdjük a SpamAssasin alap bekapcsolásátval, amelyet a /etc/default/spamassassin állományban tudunk megtenni a kötvetkezőképpen:
ENABLED=1CRON=1
azaz bekapcsoltuk és engedélyeztük neki a szabályok automatikus frissítését cronból.
service spamassassin start
és már fut is.
A SpamAssasin fnomhangolása felhasználónként lehetséges, általában tvétve a webes letvelezők bőtvítményei segítségétvel, illettve kapcsolható hozzájuk Pyzor és Razor is, bőtvebben a fnomhango-lásról az alábbi58 linkeken59 lehet oltvasni.
A soron kötvetkező lépés, hogy az Amatvisd-new-t kapcsoljuk be, és tudassuk tvele, hogy tvírus- ésspamszűrést fogunk a segítségétvel tvégezni, azaz a /etc/amatvis/conf.d/15-content_flter_mode állo-mányban kommentezzük ki a szükséges sorokat:
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
majd:
service amavis restart
Most már az Amatvisd-new kezeli a SpamAssassint és a ClamAV-ot is, tviszont a letvelek még nemjutnak el hozzá, mitvel a Postfx nem tudja, hogy azokat át kellene adnia, ezért a kötvetkező lépés-ben elmagyarázzuk a Postfx számára, hogy a letveleket minden esetben amikor beérkeznek, a
1 58. http://linuxgazette.net/105/youngman.html1 59. http://wiki.apache.org/spamassassin/UsingPyzor
25
Vállalati letvelezés, spamszűrés és tvírusszűrés
megfelelő sorrendben át kell adnia az Amatvisd számára. Ehhez a /etc/postfx/main.cf tvégéhez szúrjuk be a kötvetkező sort :
content_filter = smtp-amavis:[127.0.0.1]:10024
Akár kézzel, akár a már korábban használt módon:
postconf -e "content_filter = smtp-amavis:[127.0.0.1]:10024"
Most pedig hozzá kell nyúlnunk a /etc/postfx/master.cf fájlhoz is (a fájl legtvégéhez fűzzük hoz-zá a kötvetkezőket) :
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 -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
Majd pedig keressük meg a “pickup” kezdetű sort, ez az elején található és köztvetlenűl a pickup sor alá szúrjuk be a kötvetkezőket :
-o content_filter= -o receive_override_options=no_header_body_checks
Ezzel kiegészíttve a pickup kezdetű sort, amely ezek után így fogk kinézni:
pickup fifo n - - 60 1 pickup -o content_filter= -o receive_override_options=no_header_body_checks
A fenti módosítások eredménye, hogy a Postfx újraindítása után minden letvél átadásra kerül elemzésre a 100024 -es lokális porton fgyelő Amatvisd-new-nak, amely a totvábbiakban a Clamatv-tval és a Spamassasinnal tvégezteti el a tényleges munkát.
Végezetül pedig indítsuk újra a Postfxet:
26
Vállalati letvelezés, spamszűrés és tvírusszűrés
service postfix restart
Ha jól tvégeztük dolgunkat, akkor le is tesztelhetjük:
telnet localhost 10024
és tvalami hasonlót kell tvisszakapnunk:
Trying 127.0.0.1...Connected to localhost.Escape character is '^]'.220 [127.0.0.1] ESMTP amavisd-new service ready
A levelek eléréseA fenti megoldások segítségétvel letvélszemét- és tvírusmentesen tudjuk tárolni adatbázisban tvagy
lokális postafókokban (mailbox/maildir) a felhasználók letveleit. Ezen a ponton merül fel az igény arra, hogy a felhasználó egy azonosítás után kézhez is tvehesse letveleit. Ezt a szolgáltatást jobbára ma már csak webes letvelezők, illettve titkosítot IMAP4 segítségétvel nyújtjuk, de a régi, betvált POP3-ra is számtalan megoldás kínálkozik. A legtöbb Linux terjesztés alat, akárcsak a Postfx és aSpamAssasin, ugyanúgy előre csomagoltva elérhetőek a minden igényt kielégítő IMAP4- és POP3-szertver implementációk:
Dovecot imap4/pop360:::: az egyik leggyorsabb IMAP4 implementáció, amely nagy terhelés alat is kitváló teljesítményt nyújt. Az egyik legtöbb azonosítási módot feltvonultató kiszolgáló. Az IMAP4 és a POP3 egy felületről tvezérelhető. Natítv SSL-támogatása tvan. Fontos totvábbi szempont, hogy a Dotvecot fejlesztői mindenekelőt a biztonságos üzemeltetést tűzték ki a projekt alapcéljai közé. Érdemes tudni, hogy igen nagy terhelésű rendszerek esetében proxyként is alkalmazható a megfelelő elosztot rendszer részeként. Telepítéséhez az
apt-get install dovecot-common dovecot-imapd dovecot-pop3d
parancsot használjuk. Konfgurációs állománya a /etc/dotvecot/dotvecot.conf fájl, amely igen terje-delmes. Szerencsére az előzőekben felépítet, az azonosítást SQL-ből az SASLAuthd segítségétvel megtvalósító Postfx rendszerhez nekünk most nem lesz szükségünk túl sok plusz opcióra. A leg-egyszerűbb, ha a Postfx-szel tudatjuk, hogy a Dotvecot lesz az együtműködő partnere. Az /etc/postfx/master.cf tvégére írjuk be a kötvetkezőket:
dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}
Majd a /etc/dotvecot/dotvecot.conf fájlt töltsük fel a saját paramétereinkkel :
protocols = imap imaps pop3 pop3slog_timestamp = "%Y-%m-%d %H:%M:%S "mail_location = maildir:/home/vmail/%d/%n/Maildirssl_cert_file = /etc/postfix/smtpd.certssl_key_file = /etc/postfix/smtpd.keynamespace private { separator = . prefix = INBOX. inbox = yes
1 60. http://www.dovecot.org/
27
Vállalati letvelezés, spamszűrés és tvírusszűrés
}protocol lda { log_path = /home/vmail/dovecot-deliver.log auth_socket_path = /var/run/dovecot/auth-master postmaster_address = [email protected] mail_plugins = sieve global_script_path = /home/vmail/globalsieverc}
protocol pop3 { pop3_uidl_format = %08Xu%08Xv}
auth default { user = root passdb sql { args = /etc/dovecot/dovecot-sql.conf } userdb static { args = uid=5000 gid=5000 home=/home/vmail/%d/%n allow_all_users=yes } socket listen { master { path = /var/run/dovecot/auth-master mode = 0600 user = vmail }
client { path = /var/spool/postfix/private/auth mode = 0660 user = postfix group = postfix } }}
Mint ahogy a fenti konfgurációból látszik, a korábban létrehozot SSL-tanúsíttványt használtuk, illettve a már bekonfgurált Postfx- és SQL-kapcsolat adatait adtuk meg a Dotvecot számára. Ezt csak akkor tehetjük meg, ha ugyanazon a nétven érhető el a Dotvecot-szertver, mint az SMTP-szer-tver (azaz mind a kető pl. mail.sajatceg.hu). Hátra tvan még az SQL-kapcsolat konfgurációjának beállítása, hasonlóan mint a Postfx, illettve az SASLAuthd esetében. Hozzuk létre, tvagy ha már tvan akkor módosítsuk a /etc/dotvecot/dotvecot-sql.conf fájlt a kötvetkezőképpen:
driver = mysqlconnect = host=127.0.0.1 dbname=mail user=mail_adminpassword=mail_admin_passworddefault_pass_scheme = CRYPTpassword_query = SELECT email as user, password FROM users WHERE email='%u';
Mielőt újraindítanánk a Dotvecotot, állítsuk be a konfgurációs állományokat, hogy a Dotvecot is tudja oltvasni:
chgrp vmail /etc/dovecot/dovecot.conf
28
Vállalati letvelezés, spamszűrés és tvírusszűrés
chmod g+r /etc/dovecot/dovecot.conf
Ezek után pedig már újraindítható a Dotvecot:
service dovecot restart
Egy tesztet futassunk azért le kézzel, hogy minden rendben tvan-e, azaz nézzük meg a mail.log-ot, hogy nincs-e benne tvalamilyen hibaüzenet (bármi, amiben „error” áll, gyanús), tvalamint a tel-net localhost 110 és telnet localhost 143 parancs segítségétvel megnézhetjük a Dotvecot hallgat-e a megfelelő portokon. Az SSL-kapcsolaton keresztüli működést pedig a kötvetkezőképpen tudjuk tesztelni:
openssl s_client -connect imap.sajatceg.hu 993
Fontos tudni, hogy a Dotvecot elképesztően érzékeny az időcsúszásokra. Azaz sem előre sem hát-ra nem jól tolerálja, ha elcsúszik alóla az időszinkront. Ha nem szinkronizálunk ntpd-tvel folya-matosan, hanem csak naponta (pl. hajnalban) egyszer, akkor feltétlenül használjuk az időszinkronizációs programok csöpögtető üzemmódját, illettve érdemes az Időszinkronizálás61 feje-zetben leírtak szerint eljárni és egy szertveren folyamatos időszinkront alkalmazni. Ha mégis gon-dunk támadna a Dotvecot és az idő kérdésétvel akkor tvagy a monit62 használatátval fgyeltessük, tvagy alkalmazzunk egyéb megoldásokat, pl. a dokumentációban felsoroltak közül.63
Courier64:::: jól optimalizált memóriafoglalású program, amelynél külön kiemelendő a DDOS tá-madásokra felkészülés gyanánt könnyen állítható maximális kapcsolódások száma felhasználón-ként és IP-címenként. Működik benne a felhasználók közöti megosztot könytvtár kezelése, tviszont csak Maildir támogatása tvan. Ugyan a Maildir az egyik legjobb tválasztási lehetőség, külö-nösen a nagy terheltségű rendszerek esetében, azonban rengeteg helyen a mailbox is kötvetelménylehet. POP3/IMAP4 proxy lehetőséget is nyújt.
Cyrus65:::: A Cyrus egy BSD licencű projekt, amit 1994-ben indítot a Carnegie-Mellon Unitversity.A Cyrus a Cyrus SASL Library-t használja, amelyben több különböző azonosítási folyamat tvá-lasztható. Hozzáférési modellje és felhasználókezelése összetet és a felsorolt MDA-khoz képest nehézkesebb. Ugyanezen okokból kifolyólag széleskörűen skálázható, és öttvözi a legtöbb hasonló program jó tulajdonságait és talán az összes közül a leginkább ACL-ezhető, azaz a hozzáférési be-állítások it a legszofsztikáltabbak.
A tválasztás sokkal nehezebb, mint a többi megoldás esetében, ugyanis a Dotvecot és a Cyrus megoldásai hasonlítanak. Amíg az egyik komplexebb, addig a másik egyszerűbben kezelhető és karbantartható. It is hasonló szempontokat kell fgyelembe tvennünk, mint az MTA kitválasztásá-nál, illettve érdemes kipróbálni mindegyik olyan megoldást, amely a tudását tekinttve megfelel a feladatra.
Titkosítási réteg: a mai korban felér az adatok önkéntes átadásátval, ha a letvelezésünket titko-sításmentesen, a hagyományos nem titkosítot TCP-csatornákon folytatjuk. Az SSL kulcsok min-denki számára kényelmesen elérhetőek, akár ingyenes önaláírt (Self Signed) akár egy harmadik féláltal aláírt megbízható (Trusted) módban is, illettve a kető közöti tváltozatban a startSSL66 segítsé-gétvel is, ahol a cég hitelesíti az SSL kulcsunkat, de csak 1 étvre teszi ezt díjmentesen, megkötések-kel. A legjobb megoldás természetesen tvalamelyik ismert és támogatot CA által kiadot magas
1 61. http://szabadszoftver.kormany.hu/szabad-szoftver-keretrendszer/1 62. http://mmonit.com/monit/1 63. http://wiki.dovecot.org/TimeMovedBackwards1 64. http://www.courier-mta.org/1 65. http://cyrusimap.web.cmu.edu/1 66. http://www.startssl.com/
29
Vállalati letvelezés, spamszűrés és tvírusszűrés
bitrátájú kulcs megtvásárlása, de ez jelenleg anyagi források betvonását igényli, általában étvente, amíg a saját magunk által készítet kulcsot jellemzően a kliensek el tudják már menteni, így fel-használó oldali oktatás segítségétvel ez is megoldható, akár saját készítésű root CA készítésétvel, amelyet elhelyezünk a kliens oldali programokban.
Tehát a küldés és fogadás folyamatának minden részét érdemes titkosítot közegben tvégezni, amelyre remek beépítet megoldásokat kínál a Postfx, illettve az Stunnel467 program segítségétvel IMAP4/POP3 esetén is beállíthatjuk. Érdemes webmail elérés esetén ugyancsak HTTPS protokoll alat tartani a teljes webmail forgalmat, hiszen a felhasználók a jelszatvaikat és az érzékeny infor-mációkat küldik folyamatosan a szertver felé. Erre az OpenSSL+Apache tökéletes megoldást jelent.
Levélszemét és hamisítás elleni technológiákDKIM68:::: a metódus megalkotói abból a tényből indultak ki, hogy minden bejegyzet domain
mögöt biztosan tvan DNS-szertver, hiszen máskülönben maga a letvelezésre használt e-mail cím do-main és host netve sem létezne, azaz az e-mail cím sem lenne tvalós. Ezen címek kiszűrésére pedig más technológiák hitvatotak. Éppen ezért a DKIM megoldásában egy, a domain nétvhez legyártot kulcsot kell elhelyeznünk a DNS adatbázisban TXT rekordként. Ezen TXT rekordot mindenki le tudja kérdezni, hasonlóan ahogy egy sima nétvfeloldás esetében a host netvet. A TXT rekord által tvisszaadot kulcsnak egyeznie kell a küldő szertvere által generált aláírással. Ez tehát nem kifeje-zeten a letvélszemét elleni eszköz, hanem inkább egy kriptográfai megoldás arra néztve, hogy egy idegen fél számára biztosítani tudjuk az automatikus, emberi beatvatkozás mentes ellenőrzést arra néztve, hogy az adot küldő ténylegesen abból a domainből küldöt-e letvelet, amely a TXT alapján azonosítota. Ez egy remek kiegészítés, amely mégis segít a letvélszemét elleni küzdelemben, mitvelnagy általánosságban a spammerek nem írják alá a letveleiket a fenti módszer segítségétvel. Vala-mint a nagy ingyenes szolgáltatók szinte minden esetben támogatják a fenti módszert, így enyhít-tve a saját letvélszemétszűrőjük terheltségét is. Nagyon fontos ugyanakkor leszögezni, hogy minimum 1024 bit hosszúságú kulcsot érdemes gyártani és elhelyezni a TXT rekordban, mitvel a kisebb kulcsot a mai rendelkezésre álló számítási kapacitások mellet könnyen lehet törni és így hamisítani is. A rendszer beüzemeléséhez a dkim-flter netvű csomagot kell telepítenünk, amely hasonlóan az Amatvishoz, a Postfxszel tvagy az egyéb MTA-tval fog kommunikálni a letvelek kikül-dése esetén. A dkim-genkey parancs segítségétvel tudunk kulcsot generálni, majd azt a megfelelő helyen elhelyezni. A Postfx beállítása után már automatikusan aláírt letvek fognak kimenni az SMTP szertverünkről. Beállításáról Postfx+Ubuntu szertver esetében érdemes az alábbi69 leírást el-oltvasni.
SPF70:::: kis túlzással mondhatjuk, hogy a DKIM elődje. A tény az, hogy a technológiai alapjai ha-sonlóak a DKIM-hez, azonban a megoldása elég korlátozot és számos hibalehetőséget tartogat, használata nem is tanácsos. A lényege, hogy a már ismertetet TXT rekordban nem egy kulcsot helyezünk el, hanem azt mondjuk meg, hogy melyik szertver küldhet, milyen domain nétv alá tar-tozó letveleket. Ez a rendszer alaptvetően nem tveszi fgyelembe, hogy a letveleinket egy másik SPF-et támogató szertverre is átirányíthatuk, így ot esetlegesen elutasításra kerülhet a nem megfelelő TXT rekord miat. Előnye, hogy nem igényel plusz aláírást minden letvél esetében, ezáltal az
1 67. https://www.stunnel.org/index.html1 68. http://en.wikipedia.org/wiki/Dkim1 69. https://help.ubuntu.com/community/Postfix/DKIM1 70. http://en.wikipedia.org/wiki/Sender_Policy_Framework
30
Vállalati letvelezés, spamszűrés és tvírusszűrés
SMTP-szertver erőforrásait kíméljük. A DKIM tviszont sokkal összetetebb és kifnomultabb tech-nológia, amely sokkal inkább alkalmas egyedi azonosításra, ezért az SPF használatát kifejezeten nem ajánljuk, csak a történeti átekintés miat szerepel it.
WebmailA webmail a felhasználói oldalról ha lehet az egyik legfontosabb tényező. A Google Mail, mint a
legtöbb ember által használt webmail-felület magasra tete a mércét az összes webmail felületnek. Gyakorlatilag a piacon standard megoldásként ismerik el és mindenki igyekszik a sajátját igazítanihozzá. Természetesen a tversenyt nem igazán lehet feltvenni a tvilág egyik legnagyobb fejlesztőcé-gétvel, azonban nyílt forrású alapokon rengeteg jól használható és széles körű támogatást éltvező megoldás születet. A legtöbb megoldás a LAMP71 környezethez készült, nem is tvéletlen, hiszen ez a leginkább elterjedt. Egy webmail kitválasztásánál a legfontosabb szempont, hogy olyan eszközt tválasszunk, amely a felhasználók szokásait és igényeit tveszi leginkább fgyelembe, miközben az is fontos szempont, hogy a legtöbb PHP nyeltven íródot webmail program sem biztonsági sem pedigterhelési kockázatot ne jelentsen szertverünk számára. Általánosan elmondható, hogy a webmailekpostafókonként 2-3000 letvélig kezelik normálisan, azaz a felhasználók számára akadásmentesen aletveleket. Egyesek már jótval a 2000 letvél/postafók szám alat eltveszítik gyorsaságuk és nehézkes-sé tválnak, esetleg nagy terhelést rónak az IMAP- és a webszertverekre is. Érdemes tehát már az elején a kitválasztás után tesztelni ezen programok együtműködését nagy terhelés sok letvél mel-let. Valamint ktvóta rendszert betvezetni, tvagy oktatni a felhasználókat az archítv tárolók használa-tára.
A webmail rendszer szinte sosem jár csak magátval a letvelező felület kitválasztásátval, hiszen a fel-használó it akarja kezelni a címtárát és egyéb közös szolgáltatásait, a naptárfunkciókat, tvalamint a közös mappákat is. Jelen fejezet kifejezeten az egyszerű és gyors, de azért funkcionalitásban gazdag webmaileket tárgyalja, amelyeknek sok esetben a kibőtvítet funkciók nem részei. Sok eset-ben a felhasználó a közös címtárat egy egész más felületen éri el, mint a letveleit, illettve semmi akadálya nincs annak, hogy egy szertveren akár több webmailt kínáljunk a felhasználónak. Egyet használhat, ha „csak letvelezni” szeretne, egyet pedig, ha komplexebb feladatokat akar tvégrehajta-ni.
SquirrelMail:72 egy igen régóta fejlesztet, nagy múltra tvisszatekintő webmail felület, amelyet teljesen PHP-ban írtak. HTML4 kompatibilis, használata nem igényel JatvaScriptet. Teljes körűen támogatja az IMAP és SMTP protokollokat, rendkítvül egyszerűen konfgurálható és kezelhető. Ré-sze a legtöbb Linux terjesztésnek, így rendelkezik biztonsági kötvetéssel is. Standard bőtvítményil-lesztő felületel rendelkezik, így ha a sok száz gyárilag hozzá adot, tvagy a weboldaláról letölthető számtalan funkciót kínáló külső program számunkra nem elegendő, akkor könnyedén illeszthető hozzá szinte bármi egy PHP-programozó segítségétvel. Nagy felhasználói bázissal rendelkezik, és nagyjából lefedi egy kis és közepes tvállalkozás igényeit is. Jól testre szabható a kinézete is, azaz akár céges logók és egyéb felületek is könnyedén kialakíthatóak. Paraméterei nagyban jatvítható-ak, ha a PHP futási értékeit igazítjuk a felhasználók igényeihez és a gép fzikai keresztmetszeté-hez. A memóriafoglaltsági határ értékét és a maximális futási idejét kell emelnünk, de tvigyázzunk ezekkel az emelésekkel, mitvel rendszerünk sérülékenységét és támadhatóságát nötvelik. Fontos szempont, hogy teljes körű nyeltvi támogatás létezik hozzá, köztük magyar nyeltvű is. A biztonság
1 71. http://hu.wikipedia.org/wiki/LAMP_(szoftvercsomag)1 72. http://www.squirrelmail.org/
31
Vállalati letvelezés, spamszűrés és tvírusszűrés
iránt elkötelezeteknek jó hír, hogy letöltéskor a forráskód tvalódiságát (ha a terjesztésben létvőnél frissebb tverziót akarunk használni) MD5, SHA1 és GPG aláírás metódusokkal is igazolják, ami biz-tosíthatja számunkra, hogy tvalóban azt töltjük le, amit a programozócsapat aláírt (GPG aláírás esetében). Gyakorlati tapasztalat, hogy a legtöbb frissítés után a felhasználó saját adatai (amely egyénenként egy szeparált DATA könytvtárban található) illeszkednek az új tverzióhoz, azaz nem szükséges semmilyen beatvatkozás a frissítések után.
Roundcube:73 tudásban hasonló, mint a Squirrelmail, sőt mitvel tudása ugyanolyan könnyen bő-tvíthető bőtvítmények segítségétvel, ezért igazán egy súlycsoportban indulnak. A kezelőfelület 70 nyeltvhez rendelkezik fordítással (köztük a magyarhoz is), gyors és igen könnyen kapcsolható LDAP- illettve SQL-szolgáltatásokhoz. Kezeli a megosztot IMAP-mappákat is. Szintén nagy fel-használói bázissal rendelkezik de a tvisszajelzések alapján elmondható, hogy inkább a fejlesztői weboldalról érdemes az aktuális friss kiadást használni, mint a terjesztésekbe csomagolt tvalamitvelrégebbi tverziót. Gyakorlati tapasztalat, hogy a nagy letvélszámú postafókokkal nehezen boldogul, csakúgy mint a SquirrelMail, tvalamint esetleírások említik, hogy tverziófrissítésnél a felhasználók egyéb adatai (naptár, címlista) néha rendszergazdai igazítást igényelnek a migráció után.
Zimbra:74 egy nyílt forrású naptár, webmail és csoportmunka-támogató szoftvercsomag. Igen nagy tudású, és rendkítvül szélesen illeszthető eszköz. Sajnos azonban a szabadon felhasználható része erősen butítot, főként a csoportmunka-támogatás és a harmadik fél által írt szoftverek te-kintetében. Ugyanakkor az egyik legfejletebb keresési lehetőségeket nyújtja pl. nagy postafók esetén, illettve az extrém nagyságú postafókokat is könnyedén kezeli. Komoly hátránya, hogy csak fzetősen tvehető igénybe jó néhány szolgáltatása. Ugyanakkor az ingyenes tverzió is jól használható, ha tisztában tvagyunk a korlátaitval.
OpenExchange:75 egy igen komplex szolgáltatásokat feltvonultató webmail, naptár, közös map-pa megosztásra is alkalmas eszköz. Nagy múltra tekint tvissza és igen funkciógazdag. Az ingyenes GPL-es tváltozat számos funkciót nem tartalmaz (pl. a mobiltelefonos részletes szinkront a legnép-szerűbb telefonokra), de az alap funkcionalitás is kitválóan használható. A webes felület jelenleg nem szabad szoftver76. Nagy felhasználói bázissal és magyar lokalizációtval is rendelkezik. Fontos szempont, hogy saját csomagkezelő szertvere tvan, így a kiadások kötvetése jól megoldot és gya-korlatilag terjesztésfüggetlen.
Zarafa:77 GPL licenc alat elérhető komplex és könnyen kezelhető csoportmunka-támogató rendszer. Rendelkezik minden olyan tulajdonsággal, amely szükséges: webmail, naptár, közös mappák kezelése, teendők stb. ActitveSync kompatibilis, illettve MAPI-konform, amelynek köszön-hetően az egyik leginkább rugalmasan használható MS Exchange-kompatibilis eszköz. Hátránya, hogy az ingyenes tverzió csak 3 db. Outlook klienst támogat, e szám fölöti Outlook kliens igény esetén licencek tvásárlására kell számítani. (Ezen kítvül a jelenlegi magyarítása kítvánnitvalókat hagy maga után.)SOGo:78 jól skálázható csoportmunka-támogató szoftver GPL-licenc alat kiadtva. Nagy előnye, hogy 2003, 2007 és 2010-es natítv Outlook támogatással rendelkezik. Tudása nagyon hasonló a töb-bi komplex megoldásokat feltvonultató eszközhöz. A felhasználói tvisszajelzések szerint jelenleg még az elején tart a fejlesztési ciklusnak, azaz jól használható, de néha lassan reagál. Rendelkezik magyar nyeltvű támogatással is.
1 73. http://roundcube.net/1 74. http://www.zimbra.com/downloads/os-downloads.html1 75. http://www.open-xchange.com1 76. http://en.wikipedia.org/wiki/Open-Xchange#Licensing1 77. http://www.zarafa.com1 78. http://www.sogo.nu/
32
Vállalati letvelezés, spamszűrés és tvírusszűrés
A webmail tipikusan egy olyan eszköz, amely könnyen cserélhető, illettve tapasztalati úton érde-mes tesztelni, hogy az adot rendszerben melyik használható jobban. Ennek ellenére, ha már tvá-lasztotunk és az adatok gyűlnek benne, akkor a migrációs probléma miat (eltérő SQL-táblák, stb.)érdemes egy tesztidőszak után maradni a legjobb tválasztásnál. Abban az esetben, ha csak kifeje-zeten webmail és naptár funkcionalitásra tvan szükség, akkor a SquirrelMailt érdemes használni. Ha csoportmunka-támogatás, tvagy bőtvebb funkcionalitás a cél, akkor sorrendben a Zarafa, illettve az OpenExchange használata jatvasolt.
33
Általános célú hálózati szertver: az inetd és xinetd
Általános célú hálózati szerver: az inetd és xinetd
A hálózati szolgáltatásokat nyújtó szoftverek jellemzően olyan hátérben futó programok, ame-lyek az operációs rendszer és a függtvénykönytvtárak áttviteli-rétegbeli absztrakcióit használtva hall-gatnak egy-egy TCP tvagy UDP porton, majd ha egy ügyfél kapcsolatot kezdeményez, azt egy másik szálon tvagy folyamatban szolgálják ki. Könnyen belátható, hogy minden hasonlóan műkö-dő szolgáltatás folyamatosan erőforrásokat – különösen memóriát – használnak, tvalamint azonos funkciókat kell a fejlesztőknek megtvalósítaniuk, felelősségi körükben tartaniuk.
Ezen felismerés nyomán jöt létre az inetd, az „internetes szuperszertver”. Az általános célú háló-zati kiszolgáló egy olyan szolgáltatás, amely egyszerre hallgat több TCP és UDP porton, több szol-gáltatást kiszolgáltva, majd ha a portok tvalamelyikére kérés érkezik, megtválaszolására egy új folyamatban elindítja a konfgurációnak megfelelő programot, amelynek egyrészt a hálózati kom-munikáció részleteitvel már nem kell foglalkoznia, másrészt a programot csak lekérés esetén kell elindítani.
Ezzel a ritkábban használt szolgáltatások erőforrást, folyamatokat takaríthatnak meg, azonban teljesítménye a modern kiszolgálóalkalmazások nagy terhelésre optimalizált párhuzamos futatási megoldásaitval ritkán mérhető össze.
Használata nagy forgalmú, komplex kiszolgálófeladatok futatására napjainkban nem jellemző, azonban egyes egyszerűbb, ritkán tvagy ketvés ügyfél által használt szolgáltatások – tfp, ident, nrpe, git – tvagy prototípus-rendszerek futatására, tvalamint beágyazot rendszereken gyakran al-kalmazzák.
A démonként futni képes hálózati szolgáltatások maguk tvégzik a beérkező hálózati kapcsola-tok fogadását és a kezelésükhöz szükséges folyamatok tvagy szálak indítását, életciklusuk fel-ügyeletét. Ennek a helyes megtvalósítása nem könnyű feladat – sok esetben erre nincs is szükség, mitvel pontosan ezt a felelősséget tveszi át az alkalmazástól az inetd: az alkalmazásnakcsupán egyetlen kapcsolatot kell feldolgoznia, és különleges hálózati feladatai sincsenek, a kommunikáció egyszerűen a szabtványos ki- és bemenetén keresztül zajlik. Nehézkesen műkö-dik azonban ez a megoldás nagy számú kapcsolat esetén, mitvel nincs lehetőség az adot szol-gáltatásra optimalizált erőforrás-takarékos párhuzamosítási technikák használatára.
Az általános célú hálózati kiszolgálónak két ismert megtvalósítása a hagyományos inetd és to-tvábbfejlesztet tváltozata, a xinetd.
InetdA szolgáltatás eredeti, BSD-ből származó megtvalósítása az inetd. Hosszú története miat számos
tváltozatban érhető el, azonban a GNU/Linux rendszereken jelentős részben kiszorítota fejletebb tváltozata, a xinetd.
34
Általános célú hálózati szertver: az inetd és xinetd
Debian és Ubuntu rendszereken az openbsd-inetd netvű csomagokban találjuk meg támogatot tváltozatát, míg a CentOS tárolói nem is tartalmazzák.
Az inetd indítása és leállítása a szokásos módon történik, például a fenti csomag esetén a sudo /etc/init.d/openbsd-inetd start, tvalamint a sudo /etc/init.d/openbsd-inetd stop parancsokkal. Ha nincs szolgáltatás konfguráltva, az inetd nem indul el.
Amennyiben egy szolgáltatást az inetd-tvel szeretnénk kiszolgálni, ellenőrizzük, hogy az adot szolgáltatás szerepel-e a TCP- és UDP-portok központi nyiltvántartásában, a /etc/sertvices fájlban. Ez a fájl egy szimbolikus elnetvezéshez egy portszámot és egy protokollt ad meg, majd szükség esetén álnetveket sorol fel.
tftp 69/udp nrpe 5666/tcp # Nagios Remote Plugin Executor
Ha a listában nem szereplő portot szeretnénk használni, ellenőrizzük, hogy nem szerepel-e más nétven az adot port, majd tvegyük fel a listába.
Ezután nyissuk meg a /etc/inetd.conf konfgurációs fájlt. Ebben alapesetben egy szolgáltatás semszerepel, csupán # jellel kezdődő megjegyzések, amelyek rötviden bemutatják a fájl formátumát. A fájlban egy szolgáltatást egy sorban, a mezőket szóközökkel eltválaszttva kell leírnunk, a kötvetkező sorrendben:
– Szolgáltatás netve, ahogy a /etc/sertvices-ben szerepel (például nrpe).
– Socket típusa: stream (TCP esetén), dgram (UDP esetén).
– Áttviteli-rétegbeli protokoll : tcp tvagy udp – ahogy a /etc/sertvices-ben szerepel. Ha a szolgálta-tás tcp-tvel és udp-tvel is szerepel, tválasszunk, tvagy két külön sorban, mindkét tváltozatban konfguráljuk.
– Kapcsolók: wait tvagy nowait – tvárja, tvagy ne tvárja meg az előző kiszolgálófolyamat kilépését újabb szolgáltatás kiszolgálásához. Tipikus beállítása UDP esetén wait, TCP esetén nowait.
– Felhasználó: a szertverprogram ezen felhasználó (tvagy user:group formában megadtva ezen fel-használó és csoport) netvében kerül futatásra. Lehetőség szerint ne adjuk meg a root felhaszná-lót.
– Szertverprogram úttvonala: a szertverprogram futatható fájljának abszolút elérési úttvonala (pél-dául /usr/sbin/nrpe).
– Argumentumok: a programnak átadandó parancssor – a program netve és az argumentumok (például nrpe -i -c /etc/nagios/nrpe.cfg).
Amennyiben az inetd használatára felkészítet szoftvert használunk, a dokumentációjában meg fogjuk találni a jatvasolt beállítást, és a csomagkezelők is gyakran eltvégzik a szükséges konfgurá-ciót: például Ubuntu alat a tftpd csomagot telepíttve a /etc/inetd.conf fájlban megjelenik a kötvet-kező sor:
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /srv/tftp
Ha a kítvánt szolgáltatás nem szerepel még a konfgurációs fájlban, tvegyük fel a leírását az is-mertetet formátumban.
Ezután indítsuk el a kiszolgálót, tvagy töltsük újra a beállításait, például a sudo /etc/init.d/openbsd-inetd reload paranccsal.
TCP porton hallgató kiszolgáló is használható az inetd-tvel. Például a Nagios állapotmonitorozó rendszerhez állapotinformációt szolgáltató nrpe ágens beállításához helyezzük el a /etc/inetd.conf-ban a kötvetkező sort :
35
Általános célú hálózati szertver: az inetd és xinetd
nrpe stream tcp nowait nagios /usr/sbin/nrpe nrpe -c /etc/nagios/nrpe.conf -i
Az így létrehozot szolgáltatás az nrpe (5666/tcp) portra csatlakozó kliensek kéréseit az nrpe ne-tvű programmal szolgálja ki, amely az argumentumoknak megfelelően a megadot konfgurációs fájlt használja, és inetd üzemmódban indul. Ki is próbálhatjuk a szolgáltatást az /usr/lib/nagios/plugins/check_nrpe -H localhost -c check_load paranccsal.
XinetdAz inetd egyszerűsége miat számos, főleg biztonsági eltvárásnak nem tudot megfelelni. Emellet
konfgurációja nehézkes, és új funkciók betvezetésétvel totvább bonyolódna. Ezekre a problémákra ad tválaszt a xinetd.
Alaptvető funkciói megegyeznek az inetd-tvel, azonban könnyebben kezelhető konfgurációs for-mátumot használ, és olyan beállításokat is meg lehet adni az egyes szolgáltatásokra, mint hogy melyik interfészen hallgassanak, mely lekérésekre tválaszoljon, tvagy mely eseményeket naplózza.
Konfgurációs fájlja a /etc/xinetd.conf, azonban alapbeállításban a /etc/xinetd.d/ könytvtárban lé-tvő fájlokat tartalmát is hozzáfűzi konfgurációjához.
A fájl szolgáltatásdefníciókból áll, amelyek a service kulcsszóból, a szolgáltatás netvéből, majd kapcsos zárójelek közöt kulcs=érték formában megadot paraméterekből állnak. A fentebb ismer-tetet nrpe-szolgáltatás xinetd formátumú leírása például:
service nrpe { socket_type = stream wait = no user = nobody server = /usr/sbin/nrpe server_args = -i -c /etc/nagios/nrpe.cfg }
A fontosabb beállításokat az 1. táblázat mutatja be.
36
Általános célú hálózati szertver: az inetd és xinetd
Paraméter Leírás Példák
socket_type Socket típusa. stream (TCP esetén)
dgram (UDP esetén)
protocol Áttviteli-rétegbeli protokoll – ahogy a /etc/sertvices-ben sze-repel. Ha a szolgáltatás tcp-tvel és udp-tvel is szerepel, tválasz-szunk, tvagy két külön defní-cióban, mindkét tváltozatban konfguráljuk. Elhagyható.
tcpudp
wait Várja (yes), tvagy ne tvárja meg (no) az előző kiszolgálófo-lyamat kilépését újabb szolgál-tatás kiszolgálásához. Tipikus beállítása UDP esetén yes, TCP esetén no.
yesno
user Felhasználó: a szertverprog-ram ezen felhasználó netvében kerül futatásra. Lehetőség sze-rint ne adjuk meg a root fel-használót.
nobody
sertver Szertverprogram úttvonala: a szertverprogram futatható fájl-jának abszolút elérési úttvonala.
/usr/bin/git
sertver_args A programnak átadandó to-tvábbi argumentumok.
daemon --inetd –export-all /home/git/repo
cps Kapcsolatok másodpercen-ként. Két számot tvár, az első megadja, hogy másodpercen-ként hány kapcsolat után füg-gessze fel a kiszolgálást, a második számmal megadot másodpercre.
50 10
per_source Forrás IP címenként a meg-adot számú kapcsolatot kezel egyidejűleg.
10
disable A szolgáltatás tiltása (yes esetén).
yesno
1. táblázat : A xinetd szolgáltatások paraméterei.
37
Általános célú hálózati szertver: az inetd és xinetd
CentOS alat a tftp-server csomagot telepíttve a /etc/xinetd.d/tfp konfgurációs fájl jön létre a kö-tvetkező tartalommal:
service tftp {
socket_type = dgram protocol = udp wait = yes user = root server = /usr/sbin/in.tftpd server_args = -s /var/lib/tftpboot disable = yes per_source = 11 cps = 100 2 flags = IPv4
}
38
Központi időszinkron szertver: NTP szertver
Központi időszinkron szerver: NTP szerver
Történeti áttekintésA számítógépes hálózatok korai időszakában a gépek órájának szinkronban tartására egyszerű
eszközöket használtak. Mitvel sok gép nem tartalmazot beépítet órát, a gép bekapcsolásakor az automatikusan lefutó alkalmazások egyike a rendszergazdától megkérdezte a helyi időt, és a to-tvábbiakban az adatot begépelő személy karórájától függöt a pontosság. Ez meglehetős pontatlan-ságot eredményezet. (Ráadásul az idő múlását az operációs rendszer tartota számon, ami szintén okozhatot időcsúszást.)
Viszonylag hamar kitaláltak olyan megoldást (RFC-86879 80), amely TCP/IP protokollt használó gépek számára akár TCP, akár UDP használatátval lehetőtvé tete egy központi géptől a pontos idő lekérdezését. Ez az idő már nem lokális, hanem a Greenwich-i középidő (GMT) szerinti tvolt, ezt kellet a helyi gépnek az időzóna információ helyes beállításátval korrigáltan mutatni a felhaszná-lók számára.81 Ez másodperc pontosságot biztosítot, és a használt adatformátum miat 2036-ig nyújt lehetőséget a használatra. Ez a megoldás már 1-2-re csökkentete egy hálózat esetén a kézzelbeállítandó gépek számát, és nötvelte a pontosságot. Mitvel a TCP/IP hálózat UNIX-rendszerekbe integrálásának kezdete óta a legtöbb rendszeren alapértelmezeten tvolt és futot ez az időszertver szolgáltatás (tipikusan az inetd netvű eszköz nyújtota time nétven), elterjedt tvolt a gépek szinkro-nizálása egy rdate netvű parancs segítségétvel ; használata például rdate time.kfi.hu formában tör-tént.
Ez a megoldás több problémát is feltvet82. Ezért újabb protokoll-leírás jöt létre (RFC-95883, RFC-105984 NTP – azaz Network Time Protocol nétven), amit hamarosan több másik kötvetet (RFC-1119, RFC-1305, RFC-1361, RFC-1769, RFC-2030, RFC-4330, RFC-5905) – egyrészt a különféle to-tvábbfejlesztet tverziók (jelenleg tv4-nél tartunk), illettve az NTP részhalmazát leíró SNTP (Simple Network Time Protocol). Az NTP segítségétvel lokális hálózaton akár 1 milliszekundumos pontos-ság is elérhető, interneten keresztüli szinkronizáció esetén ez a 10 msec nagyságrendű pontosság-ra csökkenhet.
Fentebb emlegetet (S)NTP kliens oldali megtvalósítására bizonyos rendszereken használható az előzőekben már emlegetet rdate parancs a kifejezeten erre szolgáló „-n” opció segítségétvel
1 79. http://tools.ietf.org/html/rfc8681 80. Párja tvolt az RFC-867, (daytime) mely a helyi időt szötveges formában tete tátvolról lekérdezhetőtvé. De mitvel a
formátumra csak ajánlás szerepelt a szötvegben, így használata inkább hibakeresésre korlátozódot1 81. Ma a Unix és Unix-szerű (például Linux) rendszerek használata esetén kifejezeten jatvasolt a gép fzikai óráját a
régebben GMT, újabban UTC nétven emlegetet - nem-lokális - idő szerint beállítani. Ha egy gép órája helyi idő szerint jár, az az időzónák, illettve a téli-nyári óraátállítás miat problémákat tvet fel.
1 82. A protokoll nem tveszi fgyelembe az adatcsomag áthaladásának időtartamát - ez főleg tátvoli szertverek, lassú adatáttvitel esetén jelenthet problémát; a 2036. étv utáni időre nem nyújt megoldást - ez nyiltván ma még nem kritikus, de foglalkozni kellet tvele; és tvégül a másodperces pontosság sok esetben már nem elegendő.
1 83. http://tools.ietf.org/html/rfc9581 84. http://tools.ietf.org/html/rfc1059
39
Központi időszinkron szertver: NTP szertver
(http://www.openbsd.org/cgi-bin/man.cgi?query=rdate&sektion=8), ellenben Linux rendszereken az rdate ezen funkciója hiányzik.
Döntési mechanizmusGyakorlatilag nincs tválasztási lehetőség, minden ma elterjedt rendszer (S)NTP-t használ. Két el-
terjedt megtvalósítása a http://www.ntp.org/ referenciaszoftvere, illettve az OpenBSD csapat által fej-lesztet OpenNTP (http://www.openntpd.org/). Ez utóbbinak a fejlesztése az utóbbi 2-3 étvben meglehetősen lelassult, ráadásul a legtöbb Linux-terjesztés az ntp.org-félét kínálja fel alapértel-mezeten, e mellet maradtunk.
HasználatMa már a hálózatba kötöt számítógépek óráját jatvasolt (bizonyos helyen kötelező) szinkronban
tartani. Ugyan ma már a legtöbb számítógép rendelkezik beépítet óracsippel, de ezek az órák meglehetősen nagy szórást mutatnak a minőség tekintetében. Így az általában használt megoldás az, hogy kis számú gép esetén 1, nagyobb géppark esetén 2 esetleg 3 központi gép órájához igazít-juk a hálózat többi gépét. A szinkronizálást ma már általában a fent említet NTP segítségétvel old-ják meg.
Kliens
Kliens oldalról két elterjedt módszert szoktak használni:
– a napi rendszerességgel ki- és bekapcsolt gépek esetén, közelítőleg megfelelő eredményt érhe-tünk el egy a gép bekapcsolásakor automatikusan lefutó, a gép óráját a központi órához igazítóparancs segítségétvel. Ez az ntpdate parancs, használata: ntpdate -b time.kfki.hu Míg a „-b” op-ció85 használata jatvasolt, addig a time.kfi.hu helyet inkább tválasszunk tvalami nekünk megfe-lelőt, ilyen lehet például a hu.pool.ntp.org (Magyarországról - más ország esetén jatvasolt azon ország országkódját használni a „hu” helyet).
– amennyiben a gép folyamatos üzemben működik (a szertverek tipikusan ilyenek, de kényelmi okokból sokan a munkaállomásokat se kapcsolgatják), a bekapcsoláskor történő órabeállítás ketvés lehet. Jellemzően a gépek órája sietni, tvagy késni fog egy idő után. Ebben az esetben a ja-tvasolt használat az, hogy az órát folyamatosan igazítsuk a központi órához. Ellenben az, hogy meghatározot időnként (például óránként, naponta) átállítjuk a gép óráját, feltvet egy nagyon súlyos problémát - ilyen esetben eltveszítjük az idő egy tvagy több fontos jellemzőjét - a folyto-nosságot, illettve a monotonitást. Azaz tvagy „luk” keletkezik - kimaradó időpont; tvagy ugyanaz az időpont többször is bekötvetkezik. Ezért a betvált módszer a régi tvekkerórákban alkalmazot „óralassítás” / „óragyorsítás”. Azaz lekérdezzük a központi gép óráját, és ha a miénk késést mutat, akkor felgyorsítjuk, ha pedig a miénk siet, akkor lelassítjuk azt.
1 85. jelenleg a „-b” opció által kért funkció az alapértelmezet, így akár el is hagyható, de hosszú tátvon preferált a használata (látunk már szoftverben alapértelmezést megtváltozni, kicsit sűrűbben, mint opciót)
40
Központi időszinkron szertver: NTP szertver
– Ezt szintén megtehetjük az ntpdate parancs segítségétvel, ekkor ki kell hagyni a fent említet „-b” opciót, helyete a „-B” használandó: ntpdate -B time.kfki.hu és ezt a parancsot kell óránként/ napi rendszerességgel lefutatni (tipikusan cron-ból időzíttve). Ily módon futattva az ntp-date-et, a gép szépen lassan „hozzákésik/hozzásiet” a központi időhöz.
– Komplexebb konfgurációt igényel az ntpd (régebben xntpd) netvű szoftver, ami elindítása után folyamatosan fut, és rendszeresen (alapból 64 másodpercenként, ez 16 másodperc és 36,4 óraközöt tváltoztatható) lekérdezi a pontos időt, majd az előbb tárgyalt módon, a gép belső órá-jának felgyorsításátval/lelassításátval hozza összhangba a gép óráját a kültvilágétval. Működé-séhez tviszont szükséges létrehozni egy konfgurációs fájlt (tipikusan /etc/ntp.conf nétven létezik), amelyben minimálisan a lekérdezendő szertver(ek) netvét kell megadni, „server time.kfki.hu” formában.
Nem árt tudni, hogy jópár szoftver (például a Dotvecot IMAP-szertver, tvagy általában az adatbá-zis-kezelők) rendkítvül zokon tveszi az „időugrást” – ezek miat szintén nem jatvasolt az a fajta óra-állítás.
Megjegyzendő, hogy az óra folyamatos szinkronban tartásának két módja (ntpdate -B tvs ntpd) biztonsági szempontból is különbözik. ntpdate használatakor csak a parancs futatásakor lesz egy rötvid ideig tartó hálózati forgalom, míg ntpd használata esetén az ntpd szertverprogram folyama-tosan fut és a 123-as UDP porton keresztül elérhető. (Természetesen ez utóbbi használat esetén tvan lehetőség a kliensek korlátozására.)
Szerver
Szerver, amelyikhez a többi gépet szinkronizáljuk. Ezen gép órájának pontos beállítására több módszert használhatunk. A leggyakoribb, hogy megkérdezzük tvalamely másik szertvert. Ehhez be-tvezetünk egy hierarchiát. A hierarchia csúcsán álló gép műholdaktól, célhardtver segítségétvel kap-ja a pontos időt. Ezeket a gépeket Stratum-0 pontosságú szertvernek hítvjuk; azok a gépek, amelyek ezektől kapják a pontos időt, azok a Stratum-1-es szertverek. Tőlük kapják az időt a Stra-tum-2-esek, és í. t. (Noha a szabtvány eltvileg megkülönböztet 256 szintet, a gyakorlatban már egy Stratum-15-ös gépet is nem-szinkronizált órájúnak tekintünk.) Az időinformációt a szertverek TCP/IP protokollon broadcast tvagy multicast címeket használtva szórják a hálózatban, illettve lehetkérdezni is a szertvereket. Atól függően, hogy mi kérdezzük a szertvert, tvagy csak hallgatni akar-juk a tőle érkező szórt információt, tváltozik a konfguráció a /etc/ntp.conf fájlban. (A kötvetkező példákban feltételezzük, hogy a 192.168.1.42.0/24-es hálózatban dolgozunk, ahol az NTP-szertver a 192.168.42.1-es címen érhető el.)
– üzenetszórásos szertver, hallgatózó kliensekkelIt a szertver konfgja:
szerver$ cat /etc/ntp.confserver hu.pool.ntp.orgbroadcast 192.168.42.255
It a kliens konfgja:
kliens$ cat /etc/ntp.confbroadcastclient
– lekérdezős szertver, kérdezősködő kliensselIt a szertver konfgja:
41
Központi időszinkron szertver: NTP szertver
szerver$ cat /etc/ntp.confserver hu.pool.ntp.org
It a kliens konfgja:
kliens$ cat /etc/ntp.confserver 192.168.42.1
Nagyon sok helyen megelégednek azzal, hogy tvalamely gépet kinetvezik óraszertvernek, ennek a belső hardtveróráját kézzel beállítják, és ehhez szinkronizálják az összes többit. Ebben az esetben például ez a megfelelő beállítás :
gép.belső.órájáról.szinkronizáló.szerver$ cat /etc/ntp.confserver 127.127.1.0fudge 127.127.1.0 stratum 10
Látható, hogy a szertvergépen egy elég furcsa, normálisan nem használatos IP-címet adtunk meg az idő forrásaként. A 127.127.T.U típusú címet a szoftver speciálisan kezeli és azt jelenti, hogy tva-lamilyen hardtveren keresztül kapja meg a pontos időt (típusát és a konkrét darabot adják az IP-címbeli számok: T – typeID, U – unitnumber). A „fudge” sor pedig azt jelzi, hogy az alapértelme-zet 0-s stratum szint helyet ennél jótval alacsonyabb pontosságúnak minősítjük az idő forrását (ésennek kötvetkeztében alacsony pontosságúként hirdetjük) – ezzel elértve azt, hogy ha egy kliens gép rajtunk kítvül tvalahonnan máshonnan is kapna pontosabb időinformációt, ne a pontatlan időt használja.
Az NTP protokoll nagyon sok lehetőséggel rendelkezik, mint korábban utaltunk rá, például a kliensek és szertverek a kommunikáció során akár azonosíthatják is egymást. Ez biztonsági szem-pontól nem elhanyagolható lehetőség, hisz e nélkül könnyen lehetne hamis információkkal meg-zatvarni a rendszer működését. A totvábbi információk, az egyes beállítások a használt szoftver kézikönytvében megtalálhatók.
42
Nétvfeloldás a hálózaton: DNS szertver (dnsmasq és BIND)
Névfeloldás a hálózaton: DNS szerver (dnsmasq és BIND)
A ma elterjedt IP-alapú lokális hálózatok használata esetén az egyes gépek fzikai kommunikáci-ójához szükséges, hogy egyedi IP-címük legyen, a felhasználók életét pedig nagymértékben meg-könnyíti, ha nem a számukra megjegyezhetetlen IP-címekkel, hanem emberek által értelmezhető formában (például jelentést hordozó tartalommal bíró nétven) hitvatkozhatnak a gépekre. Az első funkciót általában a DHCP-szertver, a másodikat pedig egy DNS-szertver beállításátval lehet elérni.
Minden egybe
DnsmasqAhogy a mondás tartja: a BIND azoknak tvaló, akiknek saját ISP-jük tvan. Noha ez így erős túl-
zás, átlag földi halandó számára a dnsmasq is tökéletes tválasztás a pár (tíz) gépes hálózathoz. A beépítet DHCP, DNS és TFTP funkciókon kítvül a dnsmasq használatának nagy előnye, hogy ezenalapfunkciók konfgurálásához használhatók a rendszer eletve megletvő, egyszerű szintaxisú (és ál-talában már amúgy is jól ismert formátumot használó) rendszerfájljai.
Használata egyszerű, kezdeti teszteléshez elegendő a szükséges paramétereket a parancssorban megadni. Természetesen a mindennapi használathoz ez nem túl szerencsés megoldás, ritkaság, hogy az ember csak annyi paramétert szeretne beállítani, amennyit fejben tud tartani. Általában éles üzemben ezeket a paramétereket nem a parancssorban, hanem egy központi konfgurációs fájlban szokták megadni. Ezt is igen egyszerűen oldota meg a fejlesztő: a parancssorban egy pa-raméter megadásakor tvagy a UNIX-tvilágból örökölt rötvid, egy karakteres opciókat használja az ember (ezekkel sajnos a fő gond, hogy nem túl sokan tudnak értelmetlennek, logikátlannak tűnő „rötvidítéseket” megtanulni, ráadásul nem is mindennek tvan ilyen rötvid formája) ; tvagy használ-hatjuk a GNU/Linux tvilágában elterjedt ún. hosszú opciókat – a hosszú opciók használatának nagy előnye, hogy ugyanazt kell a konfgurációs fájlba is írni, az apró eltérés, hogy a betvezető -- nélkül. (Ezek a hosszú opciók néha nem annyira logikusak: például -d a debug – hibakereső – mód rötvid formája, de a hosszú formája már --no-daemon a parancsssorban, míg a konfgurációs fájlba no-daemon formában írandó).
Az előzőek alapján egy kisebb hálózat DHCP és DNS-igényének kiszolgálására legegyszerűbb esetben elegendő a kötvetkező beállítás:
A /etc/hosts fájlba feltvesszük a hálózat összes gépét, a /etc/resoltv.conf -ba a 127.0.0.1 címet – ezen a címen a dnsmasq fgyeli a kéréseket, a dnsmasq-nak pedig parancssorból megadjuk, hogy milyen címtartományt kell kiosztani a DHCP-klienseknek, tvalamint megadjuk a külső nétvszertve-rek címeit, akiket a nem helyi adatok lekérdezéséhez meg kell kérdezni, és készen is tvagyunk.
dnsmasq --dhcp-range=192.168.1.100-192.168.1.200,10h --local=/pelda.hu/ --no-resolv --server=192.168.42.42
Fenti példában a --dhcp-range opció a paraméterétvel a DHCP-klienseknek szolgáltatot címtarto-mány megadását teszi lehetőtvé tíz órás elétvülési időtvel ; a --local jelzi, hogy az adot tartomány-
43
Nétvfeloldás a hálózaton: DNS szertver (dnsmasq és BIND)
nétvért a dnsmasq a felelős, és nem kell a külső szertvernek elküldenie az ilyen irányú kéréseket (csak a /etc/hosts fájl és a DHCP adatbázisa alapján tválaszoljon); a --no-resolv azt jelenti, hogy a /etc/resoltv.conf fájlt a dnsmasq-nak már nem kell feldolgoznia; tvégül a parancssori --server adja meg a külső nétvszertver címét. (A --local és a --server opciók amúgy szinonimák, és a fenti két pél-dánál bonyolultabb beállításokat is meg lehet adni, pl. különböző tartományokhoz különböző szertvereket kérdezzen.) Fenti paramétereket persze betehetjük a /etc/dnsmasq.conf fájlba is (oda ugye -- nélküli formában), és akkor a későbbiekben nem kell kitalálni és kézzel megadni őket.
Külön-külön
NévfeloldásA TCP/IP hálózatok elterjedésének kezdetén sem a gépek netvének, sem a használatos IP-címek-
nek a kiosztása semmilyen módon nem tvolt központosíttva. A fejlődés első lépcsőjében előbb köz-pontilag menedzselt HOSTS.TXT fájlban tárolták az adatokat, majd amikor ennek karbantartása (és főleg a naprakészen tartása) közelítete a kezelhetetlent, a hálózatos tvilág átért egy elosztot adatbázis, az ún. DNS (Domain Name System) használatára.
Ennek a rendszernek fontos részét képezi a gépek netvének fa-struktúrába szertvezet koncepció-ja, az adatok tárolásáért (és az adatbázisban történő keresések kiszolgálásáért) felelős nétvszertve-rek (namesertver), illettve a nétvfeloldást a felhasználói oldalon megtvalósító függtvénykönytvtár (resoltver).
A nétvszertverek egy része a gépnétv-IP-cím információk elosztot tárolásáért felelős, ezek a náluktárolt adatok jogosult szolgáltatói (ún. autoratítv nétvszertverek) ; másik részük nem tárol adatot (tvagy csak egy bizonyos, lejárati időnek netvezet időtartamig), csak más (adatot tároló) szertvertől elkéri azokat, és a kliensek számára átadja (ill. átmeneti tárban tárolja) – ezek a caching-only szer-tverek. A konfgurációtól (és az igényektől) függő módon egy nétvszertver nyújthatja ezek közül tvagy csak az egyik, tvagy akár mindkét szolgáltatást; a funkciókat bizonyos szoftverek akár egye-dül is el tudják látni, mások csak egyik tvagy másik felét tvégzik el.
Ma a feloldást tvégző függtvénykönytvtár általában az operációs rendszer szertves részét képezi, így legfeljebb annak konfgurálása lehet kérdéses, ezzel szemben nétvszertverből nagyon sok meg-tvalósítás létezik. (BIND, PowerDNS, MaraDNS, DJBDNS, NSD/Unbound, Dnsmasq, stb.)
NévtérA nétvtér tartományokra (domain), résztartományokra (subdomain) illettve gépekre (host) osztha-
tó. Bizonyos határokon belül a tartomány résztartományának résztartományának résztartományá-nak a … is értelmezet. Kis és nagybetűket nem különböztetünk meg, általában csak fgyelemfelhítvó céllal, tvagy az oltvashatóság jatvítása érdekében szokták a nagybetűs írásmódot használni.
A nétvtér csúcsán az ún. „root domain” található. Netve „.”. Az elnetvezés és a tvizuális ábrázolás ál-talában ellentmondanak egymásnak, ugyanis tipikusan egy fölülről lefelé haladtva egyre jobban el-ágazó – egy fa gyökérzetére hasonlító – ábrátval szokták bemutatni a nétvteret, ennek ellenére csaka legtetején letvő objektumot (és nem az egészet) netvezik root-domain-nek – azaz „gyökér-tar-tománynak”.
44
Nétvfeloldás a hálózaton: DNS szertver (dnsmasq és BIND)
Ezen „root domain” alat találhatók az ún. legfelső szintű tartományok (TLD, Top Letvel Doma-in). Ezek netve kötöt. Egy része szabtványos, kétbetűs országnétv rötvidítés (Magyarország: HU; Ausztria: AT; Amerikai Egyesült Államok: US – bár eléggé ritkán használják; és í. t.). Van néhány 3-betűs. Ezek nagy része tvalamilyen szertvezet jellegét jelentő rötvidítés (EDU: oktatási intézmény;GOV: kormányhitvatal; MIL: tvalamilyen hontvédelemmel kapcsolatos szertvezet – ezek mind USA-beliek), akad néhány az USA-tól független elnetvezés, mint a korábban amerikai, proft-orientált cégeket jelentő, ma már egyértelműen nemzetközi COM (commercial), tvagy a non-proft szertveze-tek számára fenntartot ORG (organization), illettve az elsősorban (de nem kizárólagosan) internet-hozzáférést nyújtó szertvezeteket azonosító NET. Időről időre jelennek meg újabb TLD-k, ez általá-ban meglehetősen hosszan tartó procedúra eredménye. A teljesség igénye nélkül: BIZ, INFO, NAME, tvagy a ketvésbé ismer MUSEUM, COOP, PRO – ezek elfogadása 2000 notvember 16-án tör-tént meg, de míg párat már 2001 júniusában aktitváltak, például a PRO csak 2004 júniusában let használható. A lassú ügymenetre tökéletes ellenpélda az XXX top-letvel-domain, aminek elfogadá-sa 2011 márciusában, használatba tvétele ezzel szemben már 2011. április 15-én megtörtént. Az XXX nétvtartomány pozitítv hatása86 feltehetően akkor lesz érzékelhető, ha az ehhez a témakörhöz tartozó oldalak kizárólag csak ilyen netveken lesznek elérhetőek – erre egyébként nem sok esély mutatkozik.
Az egyes TLD-k alá már lehet regisztráltatni saját tartománynetveket. Ezeket hítvják első szintű tartománynak (frst letvel domain). A netvekre néztve szoktak lenni korlátozások – mint például be-jegyzet márkanetvet tartománynétvként csak a licenctulajdonos, tvagy a tulajdonos írásbeli engedé-lyétvel rendelkező személy, szertvezet regisztrálhat be; netán sértő, másokat megbotránkoztató kifejezések nem engedélyezetek – ezeket a korlátozásokat általában hosszabb-rötvidebb idő után átlépik. (Vagy kikerülik, mert ha egy kifejezés magyarul csúnya lenne, és ezért esetleg a HU tarto-mányba nem lehetne feltvetetni, akkor még mindig rendelkezésre áll a COM, a NET, és í. t.) Nem minden TLD nyílt, például a fent említet MUSEUM alá – nem meglepő módon – csak múzeumok regisztrálhatnak.
Noha korábban elterjedt ajánlás tvolt, hogy TLD-ket nem használunk első szintű tartománynétv-ként, ez egyre jobban feledésbe merül – és az egyre konkrétabb TLD-k, mint például az INFO, egyre kényelmetlenebbé is teszik ezt a korlátozást. Már korábban is sok ország próbálkozot azzal,hogy az „amerikai” mintának megfelelő, szertvezet jellege alapú elnetvezési kontvenciót használjon (ithoni példa: gotv.hu). Noha az egyes országokhoz tartozó, szabtványos netvek kitválasztása függet-len szertvezet feladata, szerencsésebb országok – kis túlzással – GDP-jük meghatározó részét kö-szönhetik jól hangzó TLD-jüknek (Tonga-szigetek: TO, tvagy Tutvalu: TV). Kisebb-nagyobb – elsősorban proftorientált – cégek tvásárolnak és tvásároltak náluk könnyen megjegyezhető netvet (például digi.ttv, go.to).87
Az első szintű tartományok alati elnetvezési kontvenció már a tartomány tulajdonosának belátá-sán múlik. Jellemzően kisebb szertvezet esetén értelmes, megjegyezhető, egyszerű logikájú nétv-kontvenció a szokásos, míg komolyabb, sok száz, ezer gépes környezetben már az automatizmus látszik a netveken. (Egyre elterjedtebb az ún. címrötvidítők használata, ami a nagy cégek automati-kusan generált, általában megjegyezhetetlen hosszúságú webcímeit legfeljebb 10-15 karakteres – amúgy szintén megjegyezhetetlen, és szintén automatikusan generált – rötvidebb netvekre cseréli.)
A gépek hálózatban használt netve egy pontokkal eltválasztot, több tagból álló azonosító, mint például prep.ai.mit.edu. Az adot példában az „edu” a TLD, a „mit” az első szintű tartománynétv, az
1 86. nyiltván könnyebb a tartalomszűrés, ha elegendő már az oldal netvének ilyen csekély részét ellenőrizni1 87. De megemlíthető a rendkítvül frappáns netvű yes.no, tvagy a számítógépes biztonságra rendkítvül sokat adó Daniel
J. Bernstein (ő írta például a fentebb emlegetet djbdns-t) tulajdonában letvő yp.to tartomány, aminek egyetlen résztartománynetvét használja: cr.yp.to.
45
Nétvfeloldás a hálózaton: DNS szertver (dnsmasq és BIND)
„ai” a második szintű, és a „prep” azonosítja magát a konkrét gépet. Tulajdonképpen a nétv hátul-ról előre haladtva egyre jobban szűkíti a kört, hogy az adot gép szertvezeti felépítés szerint (tvagy ritkábban fzikailag) hol található. Az előző példa:
– az „edu” tag azt jelenti, hogy tvalamilyen oktatási intézmény (az Egyesült Államokban)
– az „mit” az amerikai Massachusets Institute of Technology netvű intézményt konkretizálja
– az „ai” az egyetemen belül a mesterséges intelligenciátval (artifcal intelligence) foglalkozó rész-leg
– „prep” - ez pedig magának a konkrét gépnek netveA későbbiekben még fontos lesz egy eddig nem említet TLD, az ARPA. Ide a DNS-infrastruktúra
kezeléséhez szükséges speciális, ha úgy tetszik tvirtuális tartományok tartoznak. Régebbi az IN-ADDR.ARPA és újabb az IP6.ARPA. (Az első az IPtv4-es, a második pedig az IPtv6-os címek feloldá-sához szükséges adatokat tartalmazza – ez utóbbi tartományt korábban amúgy IP6.INT-nek hítv-ták, régebbi dokumentumokban időnként lehet még ezzel a nétvtvel találkozni.)
ResolverA tipikus napi használat (böngészés, letvelezés, esetlegesen a hálózat tvalamely erőforrásának el-
érése) során hálózati netvek IP-címekre fordítása a hátérben sűrűn előforduló feladat, ami a resol-tver-könytvtáron keresztül, a felhasználó számára észretvétlenül történik. (Ritkább, de szintén szükséges a fordítotja: az IP-hez tartozó nétvkeresés, ezt retverse-, tvagy intverz nétvfeloldásnak ne-tvezi a szakirodalom.) A nétvfeloldásért felelős szoftverkomponens bekonfgurálása elég egyszerű feladat, a /etc/resoltv.conf netvű fájlban csak meg kell adni a használni kítvánt nétvszertver IP-címét88,és a tartománynétv nélküli nétvkeresések esetén a keresendő gép netvéhez hozzáfűzendő tarto-mánynetveket.
search example.com hu.example.com example.hunameserver 192.168.42.44nameserver 192.168.42.42
formában.
Nem árt tudni, hogy ma már az esetek jelentős részében a hálózaton DHCP-t használnak, amin keresztül a nétvfeloldáshoz szükséges paraméterek is átküldhetők, amely esetben a resoltv.conf fájl kézzel tvaló kitöltése kihagyható, sőt általában kifejezeten ellenjatvallt, hiszen a DHCP-szertvertől kapot információtval felülíródik, így az általunk gondosan beállítot paraméterek eltvesznek. Szin-tén meg kell említeni, hogy nétvfeloldásra nem a DNS szertver az egyetlen lehetséges adatforrás. Kis gépszámú, statikus hálózat esetén sokáig alkalmazot módszer tvolt, hogy az adatokat egy egy-szerű szötveges fájlban (hagyományos netve: /etc/hosts) tárolták, és minden gépnek saját példánya tvolt. (Hátulütője, hogy minden gépen kellet belőle egy példány, amelyeket minden módosításnál szinkronizálni kellet.) De nagyobb gépszámú hálózatnál, ahol a központosítot adatárolás előnyeikiütköznek, ot sem feltétlenül a DNS az egyetlen lehetséges megoldás. Ezért szükséges lehet az NSS-keretrendszer konfgurálása. Az NSS (Name Search Switch tvagy Name Sertvice Search) adat-keresés rugalmas konfgurálására alkalmas szoftveregyütes, amelynek a gépnétv-IP-cím keresés csak az egyik feladata (mellete felhasználói nétv – UID keresés, csoportnétv – GID és még sok más is a hatókörébe tartozik).
Kitérő az NSS-hez:
1 88. Csak IP-cím adható meg nétv nem, hiszen a nétv használata megint csak nétvfeloldást, így a nétvszertver IP-címének ismeretét kötvetelné meg.
46
Nétvfeloldás a hálózaton: DNS szertver (dnsmasq és BIND)
Az NSS-rendszert egy darab, /etc/nsswitch.conf netvű, egyszerű felépítésű konfgurációs fájl, és akeresést különböző módon megtvalósító ún. NSS-modulok alkotják. A konfgurációs fájlban adhatómeg, hogy mely komponensek, milyen sorrendben próbálják meg a keresést eltvégezni, míg az NSS-modulok tvégzik magát a keresést (az adatforrástól függő módon). A konfgurációs fájl felépí-tése egyszerű: a sor elején áll a keresendő adatbázis netve (ez sokszor megegyezik a hagyományos UNIX adatbázis /etc-könytvtárbeli fájlnetvétvel, azaz felhasználói netvek esetén passwd, felhasználói csoportok esetén group, hálózati netvek/címek esetén hosts, és í. t.), majd ketőspont után az adat-forrás azonosítására szolgáló kulcsszó, tvagy ha több keresendő adatforrás tvan, akkor a megfelelő keresési sorrendben a kulcsszatvak állnak. A kulcsszó tvalamely NSS modulra hitvatkozik; a kulcs-szó az adot keresést megtvalósító osztot függtvénykönytvtár netvére utal, ahol a függtvénykönytvtár 32-bites Ubuntu 12.04.1 kiadás esetén a /lib/i386-gnu-linux/libMODULNEVE.so.x netvű fájlban ta-lálható. A hagyományos, /etc-beli adatfájlban tvaló keresést a „fles” kulcsszó segítségétvel meg-adot modul intézi, azaz a /lib/i386-gnu-linux/libnss_fles.so.2; az LDAP-szertveren tvaló keresést aznss-ldap modul teszi lehetőtvé, ekkor a modul fájlnetve /lib/i386-gnu-linux/libnss-ldap.so.2; az nss-dns modul a DNS rendszerbeli keresésre szolgál, a hozzá tartozó fájl pedig: /lib/i386-gnu-linux/libnss-dns.so.2; és í. t. Megfelelő modulokkal tetszőleges helyen és formában tárolt adatbázisis lehet a keresendő adatforrás. Azaz ha a nétv-IP-cím feloldást elsőként a hagyományos hosts-fájl-ban szeretnénk kezdeni, a bekonfgurált DNS-szertveren folytatni, tvégül pedig az LDAP-szertver adatbázisában keresnénk ha a korábbi adatbázisokban nincs találat, akkor
hosts: files dns ldap
a megfelelő beállítás.
Névszerverek
BIND (Berkeley Internet Name Daemon)
A BIND tvolt az egyik legelső UNIX-rendszerre írt DNS-szertver megtvalósítás. Korábbi (az elter-jedten használt 4-es és 8-as) tverziói ma már elatvultak, frissítések nincsenek hozzájuk, ezért ezek használata erősen nem jatvasolt. (Bizonyos – a 4-es tverzióban használatos – elnetvezési kontvencióktviszont a mai napig megmaradtak.)
A BIND9 működéséhez alaptvetően egy darab konfgurációs fájl és néhány „adatbázis” szükséges.A konfgurációs fájl írja le a nétvszertver funkcióját (elsődleges tvagy másodlagos adatforrásként használható egy tartomány adatainak lekérésekor; esetleg csak gyorsítótár szerepe tvan); it talál-hatók a működését befolyásoló paraméterek, a hozzáférés-szabályozás beállításai ; tvalamint it ad-juk meg, hogy egy tartomány adatai hol találhatóak – amennyiben az adatok ennél a szertvernél találhatók. A konfgurációs fájl köznapi netve „boot-fájl”89 – noha named.conf nétven szokot létez-ni. Eredeti helye a /etc könytvtár, de ezt az egyes disztribúciók előszeretetel tváltoztatják meg.90
A tartományra tvonatkozó információkat tároló „adatbázisokat” zónafájlnak hítvjuk. A zónafáj-lokban ún. RR-ek (resource record, azaz erőforrás-rekord) találhatóak. Noha alaptvetően nétv-IP-cím adatok tárolására (és lekérdezésére) készült a rendszer (az ide tartozó RR-ek: A, AAAA, PTR és esetleg a CNAME), ezeken az adatokon kítvül a zónafájlokban találhatók egyéb információk is. Vannak például a rendszer helyes működését biztosító RR-ek (mint a SOA, tvagy NS), tvagy akár teljesen más területhez tartozó információk (például az MX, tvagy az SRV).
1 89. a BIND4-ben a konfgurációs fájl netve named.boot tvolt, innen maradt a köznapi elnetvezés1 90. hogy bonyolultabb legyen az élet, a program indításakor megadható, hogy az eredeti könytvtár és nétv
(/etc/named.conf) helyet hol és milyen nétven keresse
47
Nétvfeloldás a hálózaton: DNS szertver (dnsmasq és BIND)
A fő konfgurációs fájl és a zónafájlok is szötvegesek, de jelentősen eltérő a szintaxisuk. A na-med.conf fájlban megadhatóak megjegyzések, akár a hagyományos, Unix-tvilágban elterjedt:
# megjegyzés a sor végéig
akár a C++ tvagy Jatva programozási nyeltvből ismerős
// egysoros
tvagy pedig
/*ez itttöbb sorosis lehet*/
formában.
A konfgurációs fájlban minden egyes bejegyzést egy kulcsszó tvezet be (mint például options, zone, key), ezt a kulcsszótól függően 0 tvagy több kötelezően (és fx sorrendben) megadandó para-méter kötveti, majd pedig kapcsos zárójelek – „{“ és „}” – közöt az adot kulcsszóhoz tartozó para-méterek állhatnak. (Ezeket egymástól „;” tválasztja el.) A teljes bejegyzést szintén a „;” karakter zárja le.
options { directory „/var/db/namedb”; listen-on { 127.0.0.1 ; }; };zone „example.hu” { type master ; file „examplehu.db” ; };
Ezzel szemben a zónafájlok szerkezete sokkal kötötebb. Csak egysoros megjegyzések lehetnek benne, azok is csak
; ez a megjegyzés a sor végéig tart
formában. Minden erőforrás rekord egy sorba írandó. Amennyiben tvalamely RR túl hosszú lenne, akkor az eredeti sorba egy „{“ karaktert írtva (bárhotva, ahol szóköz karakter állhat – például a sor tvégére) lehet több sorba tördelni, mely esetben a bejegyzést természetesen le is kell zárni a „}” ka-rakterrel.
A sor elején91 kötelezően áll egy nétv mező92, melyet kötöt sorrendben kötvet pár (opcionális) paraméter, az adot RR típusa, és típustól függően pár paraméter.
A fontosabb RR típusok:
SOA – a nétv mező által azonosítot tartomány hitelesítet adatainak kezdete (Start of Authority)
NS – az adot tartomány nétvszertverének meghatározása (NameSertver)
A – az adot netvű gép IPtv4-es címe (Address, IPtv4)
AAAA – IPtv6-os cím (Address, az IPtv6-os címek 4-szer olyan hosszúak, tvalószínűleg innen az elnetvezés)
PTR – a nétv mező által meghatározot IP-címhez milyen gépnétv tartozik (Pointer)
CNAME – a nétv mező a gép „becenetve”, mi a hozzá tartozó hitvatalos nétv (Canonical Name)
Egy BIND-szertver beállításának megértéséhez már csak pár információ szükséges. Hogyan tör-ténik egy gép netvéhez tartozó IP-cím megkeresése? Minden tartományhoz tartozik (egy tvagy
1 91. a nétv a sor legelső karakterén kell kezdődjön. Ha a sor első karaktere szóköz tvagy tabulátor, akkor a nétv mező hiányzik, mely esetben az adot bejegyzés örökli az előző bejegyzés nétv mezőjét
1 92. ez a nétv az RR-től függően tvagy egy gép, tvagy egy tartomány netvét jelenti
48
Nétvfeloldás a hálózaton: DNS szertver (dnsmasq és BIND)
több) nétvszertver, amely az adot tartományon belüli kérések megtválaszolásáért felelős. Ha ismert egy tartomány nétvszertverének netve és címe, akkor tőle a szükséges információ begyűjthető. Már csak ezeket az információkat kell tvalahogy megszerezni. A módszer nagyon egyszerű. A nétvhie-rarchiában egy szertver tvagy ismeri az abba nétvtérbe tartozó összes információt, tvagy tvalamely ré-szét a nétvtérnek átadja mástvalaki kezelésébe – ahogy mondani szokták, delegálja. De ehhez tudni kell az adot résztartományért felelős gép netvét és a hozzá tartozó IP-címet. Azaz a hierarchiában feljebb álló nétvszertver a köztvetlenül alata elhelyezkedő nétvszertverek adatait ismeri. Ezek a nétv-szertverek szintén ismerik az alatuk letvőket – ilyen módon felülről lefelé haladtva el lehet jutni a minket érintő nétvszertverig.
A korábban említet „root domain” meglehetősen statikusnak tekinthető. (Nem túl sűrűn jelen-nek meg tvagy tűnnek el legfelső szintű tartományok.) A nétvszertverei szintén nem túl sűrűn tvál-toznak. Ezen nétvszertverek – más nétven a „root-szertverek” – ma már egy erre a célra fenntartot nétvtartományban tvannak, ez a root-sertvers.net. Netvük is elég egyszerű: a.root-sertvers.net, b.root-sertvers.net, stb. m.root.sertvers.net-ig. Az ezekhez a netvekhez tartozó címek sem túl gyakran tvál-toznak, akár statikus információként bele is építhetők a nétvszertverünk adatbázisába.93
Ily módon a keresés tvégrehajtása egyszerű. Ha a korábbi példában szereplő prep.ai.mit.edu nétv-hez tartozó címet keressük, akkor először tvalamelyik root-sertver géphez kell fordulni – hisz ők azok, akik a legfelső szintű edu nétvtartomány nétvszertvereiről adatot tudnak szolgáltatni. Az edu-nétvszertvertől megkapható az mit.edu nétvszertverének adata, tőle az ai.mit.edu adata. A legtvégén akezünkben tvan az adot tartományért felelős nétvszertvernek a tválasza, ami tvagy a kereset nétvhez tartozó cím, tvagy pedig az „ilyen adat nem létezik” hiba.
Látszólag sokkal ritkábban fordul elő fordítot keresés, azaz egy IP-címhez tartozó nétv lekérde-zése (a tvalóságban ez is meglehetősen gyakori). Ahhoz, hogy ez is könnyedén megoldható legyen, egy ügyes trükköt használunk. A gépek címe elölről hátrafelé haladtva egyre specifkusabb. Elöl tvan a hálózatot azonosító pár bit, utána az alhálózatot azonosító néhány bit, és a cím tvégén állnakmagát a konkrét gépet azonosító bitek. Ellenben a netvek pont fordíttva néznek ki : elölről hátrafelé haladtva egyre általánosabb információt tartalmaznak: namesertver.budapesti-hitvatal.example.hu. A netvek keresésekor hátulról (az általánostól) haladunk előre, az egyre specifkusabb irányba. A trükk a kötvetkező: minden IPtv4-címhez rendeljünk hozzá egy netvet, amit úgy kapunk, hogy meg-fordítjuk az IP-cím byte-jainak sorrendjét, majd ehhez ragasszunk hozzá egy speciális tarto-mánynetvet: IN-ADDR.ARPA (intverz address, fordítot cím). Azaz például a 192.168.42.1 címhez rendeljük azt a netvet, hogy 1.42.168.192.in-addr.arpa. Ez a hozzárendelés kölcsönösen egyértelmű, tehát az IP keresése helyet kereshetjük ezt a nemlétező netvű gépet. Ha pedig a DNS adatbázisban az IN-ADDR.ARPA nétvtérbe tartozó adatoknál gépek IP-címe helyet a gépek tvalódi netvét tárol-juk, máris eljutotunk a kítvánt eredményhez – az eddigi IP-címkereséshez nagyon hasonló módontudunk netvet keresni. Egy IP-címhez tartozó gépnétv megkeresése tehát 2 lépésből áll : előállítjuk afordítot, IN-ADDR.ARPA nétvtérbe tartozó netvet, és megkeressük a fentebb már ismertetet mó-don a hozzá tartozó tvalódi netvet.
Ugyanezt a trükköt, egy kicsit módosíttva használhatjuk a sokkal hosszabb IPtv6-os címek keresé-sénél is. A módosítás lényege, hogy az IPtv6-címet nem decimális, hanem hexadecimális94 formá-ban ábrázoljuk, és nem az egyes byte-okat, hanem az egyes félbyte-okat (azaz magukat az egyes hexadecimális számokat) használjuk az aldomainek megadására. Például ha egy gép IPtv6-os címe 2001:db8::567:89ab , akkor az ehhez a címhez tartozó retverz bejegyzés (amely a korábbiak alapján az IP6.ARPA tartomány része, és nem az IN-ADDR.ARPA-é) a kötvetkező:
1 93. Természetesen ezek az adatok nem statikusak, időről-időre bizonyos részeik megtváltoznak.1 94. Az IPtv6-os címek 16-os számrendszerben tvaló ábrázolása nem a DNS-rendszerbeli trükk, hanem a szabtványos
írásmód (és így a napi gyakorlat része)
49
Nétvfeloldás a hálózaton: DNS szertver (dnsmasq és BIND)
b.a.9.8.7.6.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.95
PéldakonfigurációCaching DNS:
/etc/bind/named.conf: [...]
forwarders { 8.8.8.8; 8.8.4.4 ; };
[...]
A fenti konfgurációtval a Bind-ot egy egyszerű totvábbító funkcionalitással állítotuk be, azaz a kéréseket a Google nétvszertverei felé fogja Cache szertver üzemmódban totvábbítani, ő maga saját zónákat nem fog tárolni és kiszolgálni. A fenti konfguráció elmentése után a service bind9 restart után már tesztelhetünk is a dig -x 127.0.0.1 tvagy a dig sajatdomain.hu parancs kiadásátval. (a Google ingyenes és gyors DNS szertvereket üzemeltet, de nem szeretetből tvagy kedtvességből teszi ezt, ép-pen ezért csak akkor használjuk, ha a helyi szolgáltató szertverei nem megfelelőek, és nem is tu-dunk mást szertvert elérni, azaz szükségmegoldásként időlegesen elfogadhatóak).
Elsődleges (mester) kiszolgálóA /etc/bind/named.conf állományt szerkesszük, hogy hasonlóképpen nézzen ki:
[...]
zone "sajatdomain.hu" { type master; file "/etc/bind/db.sajatdomain.hu"; };
[...]
Majd az egyszerűség kedtvéért a meglétvő helyi adatbázist mintának használtva készítsük el a sa-ját domainünk adatbázis-állományát:
cp /etc/bind/db.local /etc/bind/db.sajatdomain.hu Majd szerkesszük az elkészítet másolatot, és a localhost értéket cseréljük ki az FQDN96 értékünk-re:
1 95. A példa a Wikipediának a fordítot DNS-lekérdezésról szóló oldaláról tvan: htp://en.wikipedia.org/wiki/Retverse_DNS_lookup#IPtv6_retverse_resolution
1 96. htp://hu.wikipedia.org/wiki/Fully_qualifed_domain_name
50
Nétvfeloldás a hálózaton: DNS szertver (dnsmasq és BIND)
; BIND data file for local loopback interface;$TTL 604800@ IN SOA ns.sajatdomain.hu. root.sajatdomain.hu. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;@ IN NS ns.sajatdomain.hu.ns IN A 172.20.1.10
;also list other computerswww IN A 172.20.1.50
Amint az látszik, elhelyeztük az első A rekordot a www.sajatdomain.hu részére, amely a 172.20.1.50 IP-című gépre fog mutatni. A service bind9 restart kiadása után pedig máris ki fogjuk szolgálni a www.sajatdomain.hu A rekordot. Ha már létrehoztuk az első A rekordot, akkor ne fe-ledkezzünk meg a Retverse Zone létrehozásáról is, szerkesszük a /etc/bind/named.conf.local fájlt :
zone "1.20.172.in-addr.arpa" { type master; notify no; file "/etc/bind/db.172";};
Majd másoljuk át ugyanúgy a helyi adatbázis mintát:
cp /etc/bind/db.127 /etc/bind/db.172
Ezek után már csak el kell helyeznünk a web szertver retverse IP-jét a konfgurációban, tehát szerkesszük a /etc/bind/db.172 állományt:
; BIND reverse data file for local loopback interface;$TTL 604800@ IN SOA ns.sajatdomain.hu. root.sajatdomain.hu. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;@ IN NS ns.10 IN PTR ns.sajatdomain.hu.
; also list other computers50 IN PTR www.sajatdomain.hu.
51
Nétvfeloldás a hálózaton: DNS szertver (dnsmasq és BIND)
Ezek után is szükséges a service bind9 restart kiadása.
Ha készen tvagyunk már csak tesztelni kell, jól dolgoztunk-e:
nslookup www.sajatdomain.hu és nslookup 172.20.1.50 illettve a DNS frissülése és elterjedése után már lekérdezhetjük a Google DNS-t is arról, tud-e rólunk:
dig www.sajatdomain.hu @8.8.8.8.8
Fontos, hogy a TTL értéket minden átállás előt, azaz ha webszertverünk tvagy az e-mail szertve-rünk új IP-re költözik (másik szertverterembe tvagy gépre), akkor csökkentsük le akár már egy hétel a költözés előt egy elfogadható kicsi értékre, hogy a root DNS szertverek is értesüljenek ar-ról, hogy frissen kell tartaniuk a mi rekordunkat. Ez nagy segítség lesz majd a költözés után, ami-kor a DNS szertveren átállítjuk az új IP-re, akkor az elterjedés a lehető legrötvidebb időn belül tvégbemenjen, legalább az érintet területen (pl. Magyarországon). A TTL aktuális értékét a konf-gurációban tudjuk megnézni, tvagy a dig parancs segítségétvel is ellenőrizhetjük:
dig +nocmd sajatdomain.hu +noall +answer
Bind Chroot-ban97
A Bind fejlesztését több étvtizedes tapasztalatal bíró fejlesztők tvégzik, azonban mégis felépítésé-ből adódóan is folyamatosan a támadások célpontja. A leginkább akkor járunk jól, ha a Bind-ot le-hetőségünk tvan csak lokális forwarder funkciójában használni, és kítvülről az internet irányából a bind portunk nem látszik ki. Vagy ha csak 1-2 domain kiszolgálására tvan szükség, akkor pedig ér-demes szétnézni a piacon, mitvel ma már 1-2 ezer Ft / étves árszinten elérhető DNS kiszolgáló (egy-ben elsődleges és másodlagos is), amely a legtöbb esetben webes felületen kezelhető. Ha csak lehetőség nyílik erre, és tudunk megbízható DNS üzemeltetőt tválasztani, akkor a külső esetben mindenképpen érdemes ezt tválasztani. Ha tviszont feltétlen nekünk kell üzemeltetnünk a DNS szertvert, akkor egyrészt gondolkodjunk el a BIND chroot-olt környezetben futatásán, illetőleg ha tudunk, akkor erre a feladatra dedikáljunk egy külön tvirtualizált gépet, és még azon belül is he-lyezzük Jail-be a Bind-ot. A tapasztalat azt mutatja, hogy érdemes ótvatosan kezeli a Bind üzemel-tetését.
ISC-DHCPDMitvel a két alapfunkcióból a BIND csak az egyiket látja el, mellé szükséges egy önálló DHCP-
szertver is. Jatvasolt erre a funkcióra a szintén az ISC által fejlesztet DHCP-szertvert használni. A telepítés után (Ubuntu 12.04 LTS esetén: apt-get install isc-dhcp-server) az alap konfgurációs fájlban(/etc/dhcp/dhcpd.conf) kell beállítani a paramétereket. A kötvetkező paraméterek beállítása elindu-lásnak megfelelő:
ddns-update-style none;option domain-name ”example.hu”;option domain-name-servers 192.168.42.42, ns2.example.hu;default-lease-time 36000;max-lease-time 604800;log-facility local7;option subnet-mask 255.255.255.0;subnet 192.168.1.0 netmask 255.255.255.0 {
1 97. https://help.ubuntu.com/community/BIND9ServerHowto#Chrooting_BIND9
52
Nétvfeloldás a hálózaton: DNS szertver (dnsmasq és BIND)
range 192.168.1.100 192.168.1.200; option routers 192.168.1.1;}host fixedclient { hardware ethernet aa:bb:cc:dd:ee:ff ; fixed-address 192.168.5.5;}
A megszerkesztet konfguráció tesztelésére a dhcpd -t parancs alkalmas, a szertver elindítása pe-dig a jól ismert service dhcpd start paranccsal történik. (És természetesen használhatóak a restart/stop/status paraméterek is.) A szertver futását ellenőrizhetjük a processzlistában (ps / top parancsok), illettve tvizsgálhatjuk, hogy fgyel-e a számára fenntartot hálózati porton (netstat -naput / lsof -i udp:bootps / ss -naput parancsok). A fenti konfgurációt használtva a dhcpd a syslo-gon keresztül naplóz (az alapértelmezet beállítás szerint LOG_DAEMON, a mienk szerint LOG_LOCAL7 szolgáltatásként), így probléma esetén a syslog megfelelő naplóját kell tvizsgálni.
53
Kliensek hálózati paramétereinek szolgáltatása: DHCP-szertver
Kliensek hálózati paramétereinek szolgáltatása: DHCP-szerver
Kliensek hálózati paramétereinek központi kiosztása, DNS lekérdezések gyorsítása
Már pár gépes környezetben is érdemes elgondolkodni, nagyobb kliensszám mellet pedig szintekötelező, hogy a gépeink egy központi helyről kapjanak IP-címet, illettve egyéb hálózati adatokat, mint például az alapértelmezet átjáró címe és a DNS-szertverek címei. Ráadásul, ha bármi tváltozástvan a fenti adatokban, nem szükséges tvégigzarándokolnunk a gépeket, és egyesétvel eltvégezni a módosítást, hanem csak egy helyen kell megtegyük azt: a DHCP-szertveren.
Atól, hogy a címek kiosztása dinamikusan történik, még nem jelenti azt, hogy nem határozhat-juk meg mely gépek milyen címet kapjanak, és akár gépenként eltérő hálózati paramétereket is megadhatunk (pl. más alapértelmezet átjáró, DNS), illettve megtehetjük azt, hogy amely eszközö-ket nem soroltunk fel, azok semmilyen hálózati adatot és IP-címet nem kaphatnak.
A fentieket a régóta ismert és használt ISC DHCP-szertver98 segítségétvel fogjuk megtvalósítani az alábbi példákon keresztül.
Gyakran egy hálózat gépein látszólag azért „lassú az internet”, mert a nétvfeloldás lassan történika szolgáltató DNS-ein keresztül. Ezen csak egy jó DNS cache tud segíteni, olyan mint az alább be-mutatásra kerülő DNSMasq99. Ennek segítségétvel a lekérdezéseink „közelebb kerülnek a hálózat gépeihez”, mitvel amit egyszer már egy kliens kért, azt eltárolja, és legközelebb már rögtön a DNS-Masq adja tvissza az ügyfeleknek a kért címet, nem totvábbítódik a kérés külső DNS-szertverek felé.
A DNSMasq használatátval kitválthatjuk, hogy egy kisebb hálózatban minden gépen hosts fájl szerkesztésétvel tvagy egy „komoly” DNS kiszolgáló beüzemelésétvel (pl. Bind) kelljen az esetleg szükséges pár host netvet a hálózat gépei számára feloldhatótvá tenni. A DNSMasq képes rá, hogy akiszolgálón létvő /etc/hosts fájlban létvő nétv-ip párosok alapján a hozzá forduló kliensek számára ezeket az adatokat kiszolgálja, így csak egy helyen, a kiszolgálón kell egy egyszerű szötveges állo-mányban felsorolnunk a hálózatunk azon eszközeit, amelyeket a kliensek számára elérhetőtvé sze-retnénk tenni.
Az alábbi példák az aktuális Debian stabil rendszeren, Debian 7.2 Wheezy100 -n készültek.
1 98. htps://www.isc.org/downloads/dhcp/1 99. htp://en.wikipedia.org/wiki/Dnsmasq1100. htps://wiki.debian.org/DebianWheezy
54
Kliensek hálózati paramétereinek szolgáltatása: DHCP-szertver
ISC DHCP-szerver telepítése, konfigurálásaTelepítés, alap beállítások:
Telepítsük a DHCP-szertvert a kötvetkező paranccsal:
apt-get install isc-dhcp-server
A szertver konfgurációs állományát az /etc/dhcp/dhcpd.conf nétven találjuk meg.
Nézzük az alaptvető beállításokat:
ddns-update-style none;
Ez mondja meg, hogy kommunikálhat-e dinamikus frissítésre képes DNS-szertverrel. Az alapér-ték a none, hagyjuk mi is így.
option domain-name "lok";
A tartomány netvét adhatjuk meg, belső hálózat esetén alaptvetően csak rajtunk múlik, mi ez.
Default-lease-time 86400;max-lease-time 604800;
A kliensek számára mennyi az alapértelmezet címbérleti idő, illettve meddig használhatják azt megújítás nélkül. Számunkra nincs különösebb jelentősége, hagyhatjuk az alapértelmezeten.
Szükséges deklarálnunk még a DHCP-szertver számára, hogy melyek azok a hálózatok amelye-ket kezel. Ha több interfész is tvan a gépben és nem szeretnénk, hogy tvalamelyiket kezelje, akkor is fel kell sorolni mindet, különben a syslogban panaszkodni fog deklarálatlan hálózatra. Azt, hogy tvalamely interfészen ne működjön, majd külön kell beállítanunk.
subnet 10.0.0.0 netmask 255.0.0.0 { range 10.0.2.100 10.0.2.120;}subnet 195.199.157.270 netmask 255.255.255.248 {}
Íme a hálózatok megadása. Mitvel a példagépünkben két hálózati kártya tvan, így most it mind-két kártyát deklaráltuk. Amennyiben azt szeretnénk, hogy pl. az eth0 eszközön ne fogadja a kérése-ket, csak az eth1-en, akkor az /etc/default/isc-dhcp-server fájlban kell az INTERFACES="eth1" sort beszúrni.
Az első subnetben a két zárójel közöt szerepel egy range netvezetű IP-tartomány, ebből a tarto-mányból fog IP-címeket osztani a hozzá forduló klienseknek (jelen esetben a 10.0.2.100-tól a 10.0.2.120-ig terjedő tartományból oszt címeket, mitvel ez a belső hálózatunk, amely az eth1 eszkö-zön érhető el).
option domain-name-servers 10.0.0.1,8.8.8.8;option subnet-mask 255.0.0.0;option broadcast-address 10.255.255.255;option routers 10.0.0.1;
A fenti sorokkal értjük el, hogy a kliensek megkapják a DNS-szerverek netveit, címeit (tvessző-tvel eltválaszttva lehet felsorolást készíteni), az alhálózati maszkot, az üzenetszórás címét és az alapértelmezett átjáró címét.
55
Kliensek hálózati paramétereinek szolgáltatása: DHCP-szertver
Ezzel már tvan is egy működő DHCP-szertverünk, amely osztja a címeket a hozzá forduló klien-seknek, és megadja számukra az alaptvető hálózati adatokat. Vannak azonban még totvábbi beállítá-sok.
Egyéb hasznos option definíciók
option netbios-name-servers 10.0.0.1;option smtp-server 10.0.0.1;option pop-server 10.0.0.1;
A gépek számára megadja a netbios nétvkiszolgáló (WINS szertver) címét – értelemszerűen Win-dowsos kliens környezetben tvan létjogosultsága, – és az SMTP és POP3 szertver címét is közzéte-hetjük (már amennyiben kliens oldalon tudják ezt értelmezni).
IP-címek kliensekhez rendeléseGyakran előfordul, hogy azt szeretnénk, hogy a hálózatunk bizonyos gépei mindig pontosan
ugyanazt az IP-címet kapják. Ezt a DHCP-szertveren tökéletesen meg lehet oldani, ahol összeköt-hetjük a host netvet, az eszköz MAC-címét és az IP-címet.
Ehhez tanácsos (lehet csoport nélkül is, de átláthatóbb) egy csoportot létrehoznunk, majd a cso-port nyitó és záró zárójele közöt felsorolni a klienseket így: group {}. Nézzünk erre egy konkrét példát:
group {host muszashi-netbook { hardware ethernet bc:ae:c5:a8:d9:c1; fixed-address 10.0.0.11; }}
Először defniáltuk a csoportot, majd a nyitó zárójel után jöt a host azaz a gép netve, majd a gép deklarálása is zárójellel kezdődöt. Először megadtuk a hardware ethernet sorban a kliens MAC-címét, majd a fixed-address sorban a gépnek adot IP-címet. Ezután jöt a gépdeklarációt bezáró zárójel, és tvégül a csoportdeklarációt lezáró zárójel. Természetesen a csoportba több gép is feltvi-hető nem csak egy.
Globális opciók felülbírálásaGépenként felülbírálhatjuk a globálisan megadot opciókat, ilyenkor a gép leírásánál kell megad-
ni a kítvánt opciókat.
group {host muszashi-netbook { hardware ethernet bc:ae:c5:a8:d9:c1; fixed-address 10.0.0.11; option routers 10.0.0.2; }}
Jelen példában a fenti gép már nem a mindenki számára megadot 10.0.0.1-et használja alapértel-mezet átjárónak, hanem a 10.0.0.2-t.
Ebben a példában egyszerre él az ismeretlen kliensek (nem defniáltuk, milyen IP-címet kapjon) számára a cím automatikus osztása a megadot tartományból (range), és a csoportban (group) fel-
56
Kliensek hálózati paramétereinek szolgáltatása: DHCP-szertver
sorolt gépek számára a statikus IP adása. Ilyenkor nagyon fgyeljünk arra, hogy statikus IP-t ne a kiosztható tartomány címeiből adjunk.
Csak fix IP-címekAmennyiben arra lenne szükségünk, hogy csakis a szertveren felsorolt gépek kapjanak IP-címet,
akkor töröljük a range sort a hálózat deklarálásánál. Tehát akkor így kell kinéznie a hálózatunk megadásának:
subnet 10.0.0.0 netmask 255.0.0.0 {}
Innentől csak az kap címet, akiket a deklaráltunk a szertveren.
Amennyiben sok klienst szeretnénk feltvinni, átláthatóbbá tválik a konfgurációs állományunk, haazokat nem it soroljuk fel, hanem egy külön állományban, és it csak megadjuk, hogy melyik fájl-ban találhatóak. Ez az alábbi módon tudjuk megtenni:
include "/etc/dhcp/kliensek";
Teljes példa konfigurációs állományok
/etc/dhcp/dhcpd.conf
ddns-update-style none;option domain-name "lok";Default-lease-time 86400;max-lease-time 604800;
subnet 10.0.0.0 netmask 255.0.0.0 {range 10.0.2.100 10.0.2.120;
}
option domain-name-servers 10.0.0.1,8.8.8.8;option subnet-mask 255.0.0.0;option broadcast-address 10.255.255.255;option routers 10.0.0.1;option netbios-name-servers 10.0.0.1;option smtp-server 10.0.0.1;option pop-server 10.0.0.1;
include "/etc/dhcp/kliensek";
/etc/dhcp/kliensek
group {
host titkar-pc { hardware ethernet bc:ae:c5:8a:d9:c1; fixed-address 10.0.0.10; }
host muszashi-netbook { hardware ethernet 08:00:27:b7:cd:e7; fixed-address 10.0.0.11;
57
Kliensek hálózati paramétereinek szolgáltatása: DHCP-szertver
option routers 10.0.0.2; }
}
DNSMasq telepítése, konfigurálásaTelepítés, alap beállítások
A DNSMasq-ot a kötvetkező paranccsal tudjuk telepíteni a gépünkre:
apt-get install dnsmasq
A telepítés során két konfgurációs állomány jön létre. Az egyik az /etc/default/dnsmasq, a má-sik az /etc/dnsmasq.conf nétven jön létre.
Az /etc/default/dnsmasq konfgurációs állománnyal jelen esetben semmi tennitvalónk nincs, hagyhatjuk az alapértelmezet beállításokon, it két érték érdekes a számunka:
ENABLED=1
A fenti sor mondja meg, hogy elinduljon-e automatikusan a DNSMasq szolgáltatás. Ameddig az értéke 1, addig el fog indulni.
#IGNORE_RESOLVCONF=yes
Amíg ez a sor ki tvan kommenteztve, addig tveszi fgyelembe a RESOLVCONF fájl tartalmát, egyébként sajátot kell megadni.
Mindkét beállítást érdemes így hagyni, hacsak nem direkt akarunk mást. Az összes totvábbi beál-lítást az /etc/dnsmasq.conf fájlon hajtjuk tvégre.
KonfigurációAz /etc/dnsmasq.conf fájlban is mindössze pár alapbeállítást kell módosítanunk a testreszabás-
hoz.
Port=53interface=eth1,loexcept-interface=eth0listen-address=127.0.0.1,10.0.0.1bind-interfaces
A fenti beállításokat eltvégeztve elérjük, hogy mint DNS gyorsító kiszolgáló az 53-as porton tvála-szoljon a bejötvő kérésekre, és csak a tvisszacsatoló eszközön (lo) és a második hálózati kártyán tvá-laszoljon. Ez a beállítás akkor lehet fontos, ha több hálózati kártyánk is tvan a gépben, így el tudjuk érni, hogy csak a megadot hálózatok felé nyújtson szolgáltatást. Az except-interface pedig azt mondja meg, hogy mely csatolókon ne nyújtson szolgáltatást. Jelen esetben ez az eth0 eszköz, amely a külső csatolókártyánk. Látható ez pont ellentéte az interface-nek, és a kető közül az egyikmegadása elégséges is a megfelelő működéshez, de ha mindkét értéket helyesen adjuk meg, akkor biztos csak ot fog ténylegesen működni ahol ezt szeretnénk. (Egy kis paranoia sosem árt a rend-szergazdának.) Totvább lehet szigorítani, ha megadjuk a listen-address alat, hogy mely címeken tválaszoljon: a csatolók meghatározásán túl ezzel még jobban körbe tudjuk határolni, mit is szeret-
58
Kliensek hálózati paramétereinek szolgáltatása: DHCP-szertver
nénk. A bind-interfaces opció lesz az, aminek köszönhetően a fenti interface és except-interface beál-lítások ténylegesen megtörténnek, ezért ezt ne hagyjuk el.
Domain-neededBogus-priv
A fenti sorok hatására nem fog totvábbítani a DNS-kiszolgálók felé olyan címeket, amelyek nem tartalmaznak tartománynetvet (domain-needed) hiszen az a belső hálózathoz tartozik; és olyat sem, amelynek a címe nem routolható tartományba esik.
A fenti beállításokkal már tvan egy működő DNS-cache a gépünkön, amely csak a belső hálózat kéréseire tválaszol.
További konfigurációs ötletek
cache-size=600
Az alapértelmezet cache méretét nyugodtan nötvelhetjük, ha hálózatunk forgalma ezt igényli.
domain=lok.localexpand-hosts
Amennyiben az /etc/hosts fájlban tvetünk fel gépnétv–IP-cím párosokat, akkor azokat a DNS-cache kliensei felé a DNSMasq automatikusan szolgáltatja az ot megadot nétven. Így gyakorlati-lag egy kis hálózat esetén kitválthatjuk a „rendes” DNS-szertvert. A fenti két beállításra csak akkor tvan szükségünk, ha azt szeretnénk, hogy minden általa ismert belső hálózathoz tartozó gépnétvhezhozzáillesszen egy tartománytvégződést. Ezt adjuk meg az expand-hosts bekapcsolásátval. A „do-main” sorban pedig azt a netvet adjuk meg, amit szeretnénk, hogy tartományi nétvként hozzáillesz-szen. Ha ezek a sorok nem szerepelnek, akkor csak simán az /etc/hosts fájlban felsorolt nétven oldja fel a meghatározot gépek netveit.
DNSMasq mint DHCP-szerverA DNSMasq képes DHCP-kiszolgálóként is működni, azonban DHCP-szertverként már az ISC-
DHCP-t tárgyaltuk, így ezt a funkciót nem részletezzük. Amennyiben azt szeretnénk, hogy a DNSMasq DHCP-szertverként működjön, úgy az /etc/dnsmasq.conf fájlban tvegyük ki a megjegy-zésjelet a dhcp-range sor elől, és írjuk oda a kítvánt IP-tartományt és a címbérleti időt. Az alábbi példában a 10.0.0.100-tól a 10.0.0..150-ig oszt IP-címeket a hozzá forduló ügyfeleknek
dhcp-range=10.0.0.100,10.0.0.150,255.0.0.0,12h
Teljes példa konfigurációs állományok:
/etc/resolv.conf
nameserver 8.8.4.4nameserver 8.8.8.8
It semmit nem módosítotunk, csak arra kell ügyelni, hogy létező és működő DNS-szertverek cí-mei legyenek beírtva.
/etc/default/dnsmasq
#DOMAIN_SUFFIX=`dnsdomainname`#DNSMASQ_OPTS="--conf-file=/etc/dnsmasq.alt"
59
Kliensek hálózati paramétereinek szolgáltatása: DHCP-szertver
ENABLED=1CONFIG_DIR=/etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new#IGNORE_RESOLVCONF=yes
It sem tvégeztünk módosítást, mindössze ellenőrizzük, hogy elindul-e a szolgáltatás, és hasz-nálja-e a resoltvconf-ot.
/etc/dnsmasq.conf
port=53interface=eth1,loexcept-interface=eth0listen-address=127.0.0.1,10.0.0.1bind-interfaces
domain-neededbogus-priv
cache-size=600
domain=lok.localexpand-hosts
It láthatóak az eltvégzet módosítások.
/etc/hosts
127.0.0.1 localhost127.0.1.1 szerver4.lok.local szerver4# The following lines are desirable for IPv6 capable hosts::1 localhost ip6-localhost ip6-loopbackff02::1 ip6-allnodesff02::2 ip6-allrouters
# Felsorolt nevek10.0.0.21 nyomtato110.0.0.22 nyomtato210.0.0.1 intranet
A kezdeti sorokon túl, amelyek telepítéskor kerültek ide, a felsorolt nevek után írtuk azokat a nétv–IP párosokat, melyekről szeretnénk, hogy a helyi hálózatunk számára DNS-szertverként nétv-feloldást tvégezzen a DNSMasq. A nyomtato1, nyomtato2, intranet netveket ebben a formában, és az intranet.lok.local, nyomtato1.lok.local nétven is feloldja jelen konfgurációban.
60
Webszertver feladata, telepítése és üzemeltetése
Webszerver feladata, telepítése és üzemeltetése
Egy átlagos webes kiszolgáló a legtöbb esetben egy úgynetvezet LAMP környezetből áll, amely-nek részei az operációs rendszer, a webszertver, tvalamilyen szertveroldali szertver szkriptnyeltv, mintpéldául a PHP és az adatbázis-kezelő. Egész pontosan így kapjuk meg a LAMP rötvidítés betűit. A legtöbb statisztikai mérés szerint a Linux+Apache+MySQL+PHP környezet a leginkább elterjedt (lásd az adatbázis fejezetet). Egy átlagosan feltelepítet környezetben tehát a fenti megoldás segít-ségétvel kialakíthatunk dinamikus és statikus, szabad szoftverekkel működtetet oldalakat. Ez a fe-jezet segít a webszertverek és a hozzájuk szorosan kapcsolódó szolgáltatások kitválasztásában. Ilyenpéldául az FTP szertver tvagy az SFTP szertver, hiszen a legtöbb esetben az oldalak karbantartására ma is ezt a megoldást használják azok karbantartói, természetesen a számos egyéb lehetőség mel-let. Ez a fejezet a webes kiszolgálás köré csoportosítható eszközöket ismerteti.
Webszerverek
Apache
Az Apache hosszú étvek óta a legnépszerűbb webszertver a független kutatások szerint. Az Apache projektet az ASF alapíttvány keltete életre, és többek közöt a webszertvert is ők fejlesztik, tartják karban. Az alapíttvány tvédőernyője alat tetvékenykedik számtalan szabad szoftveres prog-ramozó, akik az 1999-es indulás óta fejlesztik a webszertvert. A kezdetekben a cél az tvolt, hogy az NCSA HTTPd bőtvítésén dolgozzanak, majd 1999. június 1-jén hitvatalosan is létrejöt az ASF. Az Apache egy igen kifnomult, moduláris és rugalmasan bőtvíthető webszertver, amely kompatibilis a HTTP/1.1 (RFC 2616) protokollal. A projekt nyiltvánosságra bocsátása után dinamikusan fejlődöt, és hamar tvalós alternatítvát kínált az akkor előnyös pozícióban létvő Netscape Communications Corporation webszertverrel szemben. Azóta is folyamatosan fejlődik, és gyakorlatilag uralja a pia-cot. Moduláris felépítésének köszönhetően mi magunk dönthetünk arról, hogy az alap telepítés után milyen funkciókat akarunk használni, például az SSL tvagy a mode_rewrite modult. Megfele-lő hardtvertámogatás mellet jól skálázható, kis- és nagytvállalati megoldásokra is. A legtöbb szkriptnyeltvet támogatja, mint a PHP, Perl, Python, Ruby on Rails. Több ismert cég is felhasználja az Apache-ot termékeiben: Oracle, IBM WebSphere, OSX beépítet webszertverként. Számos rou-ter, gateway, NAS megoldás szertves része. Még zárt szoftverként is forgalmazható, mert ezt nem akadályozza meg a nem copylef Apache szabad szoftver licenc. Telepítése Ubuntu LTS alat is igen egyszerű, az:
apt-get install apache2
parancs kiadásátval az alap függőségek kezelése mellet fog települni a webszertver. Gyakorlatilag aparancs lefutatása után tvan egy teljesen alap szinten működő web szertverünk, amely létrehozza a/tvar/www könytvtárban az alap „It works!” oldalt, és innentől kezdtve a webszertver alap beállítá-sok szerint a 80-as porton fogadja a kéréseket. Mint oly sok hálózati kiszolgáló szolgáltatást, az Apache-ot sem érdemes alapbeállításokkal használni, hiszen egyrészt nem túl biztonságos, tvala-mint jellemzően több tartományt tvagy oldalt szolgál ki az Apache, így mindenféleképpen nézzük
61
Webszertver feladata, telepítése és üzemeltetése
meg, milyen beállításokat érdemes átállítanunk. A konfgurációs fájlok az /etc/apache2/ könytvtár-ban találhatóak.
apache2.conf httpd.conf mods-enabled/ sites-enabled/ conf.d/ magic ports.conf ssl/ envvars mods-available/ sites-available/
Az apache2.conf fájl
Az ismerkedést kezdjük az apache2.conf fájllal, amelyben a legfontosabb központi paraméterek megtalálhatóak, it paraméterezhetünk az Apache alaptvető tviselkedésétvel kapcsolatban sok min-dent, tvalamint igazából ide tvan belinkeltve a többi konfgurációs fájl is, azaz az Apache innen ol-tvassa be például a mods/site-enabled konfgokat is. Nézzük, mihez érdemes hozzányúlni és miért:
Timeout 300
Másodpercben kifejeztve megmondjuk, hogy az Apache mennyi időt tvárjon mielőt Timeout hi-bátval lezárja a kapcsolatot. Főként nagy forgalmú, tvagy I/O terhelt szertverek esetében lehet ez ér-dekes. Alapbeállításon célszerű hagyni, illettve ha szükséges tváltoztatni (általában lefele irányban, azaz némileg csökkenteni) akkor minden esetben tesztelni érdemes, hogy az adot terheltség és az adot kiszolgálási stílus mellet számunkra mi a megfelelő: nem mindegy, hogy egy nagy terhelésűfórum szertvert paraméterezünk, tvagy egy 200 MB-os letöltőközpontot.
KeepAlive OnMaxKeepAliveRequests 100KeepAliveTimeout 5
Ezen 3 paraméter segítségétvel állítható be, hogy a szertver egy TCP kapcsolat nyittva tartása mel-let több kérést is kiszolgál. Ilyen eset, amikor egy oldalon sok kép tvan, és az Apache ilyen beállí-tások mellet csak egy TCP kapcsolatot használ fel arra, hogy esetleg az összes adatot a kliens felé totvábbítsa. Az értékeket ezredmásodpercben tudjuk megadni. Megint csak: nagy terhelés esetén az oldal felépítése és a felhasználók szokásai alapján érdemes próbálkozni a ki/be kapcsolásátval, ésMunin segítségétvel folyamatosan monitorozni a tvégeredményt.
<IfModule mpm_prefork_module> StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0</IfModule>
Alap telepítés szerint az mpm_prefork_module-t használjuk, hiszen a libapache2-mod-php5 kiter-jesztés ezzel kompatibilis. Amit érdemes tudni róla, hogy ebben az esetben a kéréseket egy szál szolgálja ki, és a memóriaigénye is magasabb a workerhez képest. Beállítása és üzemben tartása átlagos esetben egyszerűbb, és jatvasolt is a prefork+libapache2-mod-php esetén. Érdemes tudni róla, hogy ha mégis a workert akarnánk tválasztani, akkor lehetőségünk lenne a mod_fcgi-vel PHP-futatásra. Nézzük a paramétereket:
StartServers: meghatározza, hogy az Apache indulásakor hány szertverfolyamat induljon el. Álta-lában érdemes az alapértelmezet beállításon hagyni, azaz 5-ön.
MinSpareSertvers, MaxSpareSertvers: a minimum és maximum SpareSertver opciókkal szabá-lyozhatjuk, hogy hány tartalék kiszolgáló fusson a hátérben, amelyek a tvárakoznak az új csatla-kozók kiszolgálására. Így ha a szabad folyamatok száma eléri a MaxSpareSertvers értéket, akkor az Apache le fogja kapcsolni a feleslegesen futó folyamatokat.
62
Webszertver feladata, telepítése és üzemeltetése
MaxClients: meghatározhatjuk, hogy mennyi klienst szolgáljon ki az Apache egy időben maxi-mum. Tipikusan ha egy kliensnek sokat kell tvárakozni az oldal betöltéséig, akkor tvélhetőleg ez a szám túl alacsony.
MaxRequestsPerChild: ezzel szabályozzuk, hogy egy gyermek folyamat összesen mennyi kérést szolgálhat ki. Alapértéke nulla, de néha – főleg memóriaszitvárgás esetén – érdemes ezt az értéket terheléstől függően 5000-100000 közé állítani, de csak teszt jelleggel.
AccessFileName .htaccess<Files ~ "^\.ht">
Order allow,deny Deny from all Satisfy all</Files>
Rögzítjük, hogy a .htaccess fájlt hogyan ismerje fel a szertver, tvalamint megmondjuk, hogy a .htaccess és a .htpasswd fájlok kliensek által tvaló lekérhetőségét akadályozzuk meg. A .htpasswd fájlokat amúgy sem praktikus publikus könytvtárba elhelyezni, de erről később még bőtvebben ér-tekezünk.
HostnameLookups Off
A direktítva segítségétvel megmondhatjuk, hogy a kliensek IP-címének rögzítését hogyan akarjuklátni a naplóban. Paraméterei: On|Off|Double. ON esetén az IP-hez kapcsolódó retverse érték is rög-zíttve lesz. Érdemes azonban fgyelembe tvenni, hogy akár már egy kis látogatotságú weboldalon isrengeteg nslookup-ot eredményezhet, azaz nem tvéletlen, hogy az alapértelmezet paramétere az OFF.
ErrorLog ${APACHE_LOG_DIR}/error.logLogLevel warnLogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combinedLogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combinedLogFormat "%h %l %u %t \"%r\" %>s %O" commonLogFormat "%{Referer}i -> %U" refererLogFormat "%{User-agent}i" agent
It határozzuk meg a naplózással kapcsolatos formai és fájl igényeinket. Azaz, hol legyen a köz-ponti error.log. Ebbe a fájlba fogja rögzíteni az Apache a működése során fellépő hibákat, ide fog-nak kerülni (ha másként nem rendelkezünk) a PHP-ból eredő hibák, illettve a nem létező fájlok és egyéb természetű hibák. Ezért célszerű oldalanként defniálni egy error.log fájlt. A többi paramé-ter segítségétvel pedig a látogatói kliensekről megszerezhető információk rögzítési formátumát ál-lítjuk be. Mitvel alapesetben a felhasználók gépei és böngészői túlságosan közlékenyek (User Agent), ezért ha nincs szükségünk minden információra, it tudjuk szűkíteni a kítvánt információ-halmazt.
Include ports.conf
It történik a fejezet elején felsorolt konfgurációs fájlok meghítvása, azaz gyakorlatilag ezek is azapache2.conf részét képezik, csak egy strukturált módon.
A ports.conf fájl
A kötvetkező konfgurációs fájl tehát a ports.conf, amelyben azt rögzítjük, hogy a webszertver mi-lyen IP-címeken és milyen portokon hallgasson a tvilág felé:
63
Webszertver feladata, telepítése és üzemeltetése
NameVirtualHost *:80NameVirtualHost *:443
Jellemzően egy webszertver nem csak egy tartományt szolgál ki, hanem többet. Ebben az esetbenbe kell kapcsolnunk a NameVirtualHost direktítvát, amely azonban a 2.3.11-es tverzió óta szükség-telenné tvált, mitvel már az Apache úgy értelmezi, hogy bármelyik IP tvagy port több tartományt szolgál ki. It jelenleg azért szerepel, mitvel a jelenleg használatos Ubuntu LTS tverzióban még köte-lező direktítva.
Listen 80<IfModule mod_ssl.c>
Listen 443</IfModule>
Ezzel megmondjuk a webszertvernek, hogy a standard 80-as és 443-as portokon működjön. A 80-as port természetesen az alap, a 443-ashoz tviszont SSL tanúsíttványt kell készíteni és be is kell konfgurálni az Apache számára, amelyet később teszünk meg, ezért tvan feltételek közöt. Azaz haaz SSL modult bekapcsoltuk, akkor a Listen paraméter is élni fog, ha nem akkor természetesen nem. Megadható még így is:
Listen 192.168.1.1:80
A security fájl
A kötvetkező fájl, amelyet az Apache az /etc/apache2/conf.d-ből oltvas fel a security. Netvéből adó-dóan a biztonsági beállítások egy jó részét tartalmazza:
ServerTokens Prod (Full | OS | Minimal | Minor | Major | Prod)
Meghatározza, hogy a webszertver milyen fejlécet adjon tvissza a kliensek felé. Értelemszerűen itis igaz az, hogy ha nem tesztelés jelleggel szükséges a teljes információ tvisszaadása, akkor a lehetőlegketvesebbet kell magunkról elárulnunk, azaz érdemes Prod-ra állítani az értéket, amely így csak a Product értéket fogja elárulni, azaz Apache lesz.
Nézzük meg mi történik, ha Full értéken tvan:
telnet localhost 80Trying 127.0.0.1...Connected to localhost.Escape character is '^]'.HEAD // HTTP/1.0 \n\n
HTTP/1.1 401 Authorization RequiredDate: Mon, 13 May 2013 11:01:07 GMTServer: Apache/2.2.22 (Ubuntu) mod_ssl/2.2.22 OpenSSL/1.0.1WWW-Authenticate: Basic realm="ByPassword"Vary: Accept-EncodingConnection: closeContent-Type: text/html; charset=iso-8859-1
Connection closed by foreign host.ServerSignature Off
Bekapcsoltva (jellemzően hiba esetén tvan így) tverzió- és egyén-szenzitítv információt (signature) szolgáltat, természetesen nem hibakereső üzemmódban ezt is érdemes kikapcsoltva tartani, főként biztonsági megfontolásból.
TraceEnable Off
Főként teszt és diagnosztikai esetekben érdemes bekapcsoltva tartani.
64
Webszertver feladata, telepítése és üzemeltetése
A charset fájl
Ugyancsak a conf.d/ alat található a charset fájl, amely ma már igen egyszerű, hiszen jellemzően UTF–8 kódolás támogatásátval dolgozunk:
AddDefaultCharset UTF-8
It azonban szükség esetén megadható egyéb kódolás külön támogatása is.
Az Apache kiterjesztése
A kötvetkező fontosabb lépés az Apache kiterjesztési lehetőségeinek megismerése, azaz a hozzá kapcsolható modulszerkezet, illettve azok ki-be kapcsolása. Ha például PHP-t telepítünk a rend-szerre – mint ahogy azt a fejezet tvége felé a PHP részletezésénél fogunk is – az Ubuntu telepítő-rendszere, miután feltelepítete a szükséges függőségeket, köztük az apache2 modult is, az /etc/apache2/mods-atvailable alá fogja elhelyezni a PHP modulfájl helyét és a betöltéshez szüksé-ges konfgurációt tartalmazó fájlt, amely így fog kinézni:
cat /etc/apache2/mods-available/php5.load LoadModule php5_module /usr/lib/apache2/modules/libphp5.so
cat /etc/apache2/mods-available/php5.conf <IfModule mod_php5.c> <FilesMatch "\.ph(p3?|tml)$"> SetHandler application/x-httpd-php </FilesMatch> <FilesMatch "\.phps$"> SetHandler application/x-httpd-php-source </FilesMatch> # To re-enable php in user directories comment the following lines # (from <IfModule ...> to </IfModule>.) Do NOT set it to On as it # prevents .htaccess files from disabling it. <IfModule mod_userdir.c> <Directory /home/*/public_html> php_admin_value engine Off </Directory> </IfModule></IfModule>
A PHP-tvel nincs teendőnk, hiszen azt majd a telepítőrendszer elintézi, azonban az /etc/apache2/mods-atvailable könytvtárban tvan sok olyan modul, amely telepíttve tvan, működésre kész, de jelenleg nem használja a webszertver. Az egyik ilyen például az SSL, amelyet egyszerűen az Apache számára használhatótvá tehetünk, csak létre kell hoznunk egy szimbolikus linket az /etc/apache2/mods-enabled/ssl.load -> /etc/apache2/mods-atvailable/ssl.load közöt, azaz a mods-enabled alá linkeljük a modes-available/ alat létvő ssl.log és ssl.conf fájlokat, majd az apache2ctl configtest és az apache2ctl restart parancsok segítségétvel értvényesítjük. A ports.conf-ban rögzítet-tek szerint így már fel fogja ismerni az Apache, hogy az SSL modul be tvan tölttve. Az SSL totvábbi konfgurációját pedig a normál Virtualhost konfgurálás után részletezzük.
Egy tartomány kiszolgálásának beállítása
Nézzük, hogyan tudunk bekonfgurálni egy www.iskola.hu és iskola.hu tartományt. Első lépés-ben szükséges, hogy a DNS szertverünkben beállítsuk (tvagy kérjük annak karbantartójától, hogy a www.iskola.hu a szertverünk IP-címére mutasson – „A” rekord), tvalamint célszerű az Origin (@)-t, azaz az iskola.hu (www nélküli) címet ugyanerre az IP-re irányítani. Ha ezzel megtvagyunk, akkor
65
Webszertver feladata, telepítése és üzemeltetése
az /etc/apache2/sites-atvailable könytvtárba helyezzük el a soron kötvetkező tvirtualhost leírófájlját. Ha ez lesz az első, akkor célszerű (a nullás foglalt, az az alapértelmezet) a 001-iskola.hu netvet adni neki. Az egyszerűség kedtvéért, mitvel it egyszerre értelmezhető a konfguráció, minden sor után #-tel kezdtve oltvasható a magyarázat, értelemszerűen ezeket nem kell a tvégleges fájlba másolni:
<VirtualHost *:80>#Itt határozzuk meg, hogy milyen IP-címekre és portokra vonatkozzon ez a virtualhost. Mi most a csillag karaktert használtuk, hogy ne okozzon gondot, ha a gépnek több IP-címe van, vagy le kell cserélni. Megadhatunk IP-címet is,például: <VirtualHost 192.168.1.1:80>
ServerAdmin [email protected]#Meghatározzuk a virtualhost által hirdetett rendszergazdai címet
ServerName www.iskola.huServerAlias iskola.hu
#A ServerName direktíva mondja meg, hogy milyen DNS névre hallgat majd, a ServerAlias-hoz pedig felvehetjük a szükséges többit, jelen esetben a www nélküli címet, de lehetne itt a mail.iskola.hu is.
DocumentRoot /var/www/iskola/#A DocumentRoot direktívával meghatározzuk, hogy honnan kezdődik a virtualhost nyilvános könyvtárszerkezete. Ide rakjuk az index.html, index.phpstb. fájljainkat.
<Directory />Options FollowSymLinks IndexesAllowOverride AuthConfig All</Directory>#Az adott könyvtárra meghatározzuk az Options segítségével, hogy ha nincs
index.html vagy index.php fájl az adott könyvtárban, akkor kilistázza-e a könyvtár fájljait (Indexes opció), illetve beállítjuk, hogy kövesse a szimbolikus linkeket. Majd az AllowOverride opcióval lehetővé tesszük, hogy ha .htaccess fájl található egy könyvtárban, akkor az abban lévő paramétereket figyelembe vegye, mintha csak például az Options-ök között szerepelt volna. Ez a paraméter barátunk és ellenségünk is lehet. Fontos, hogy akkor engedjük All opciókkal, ha erre a PHP programozóknak egyedileg szükségük van és megbízunk bennük, minden más esetben érdemes virtualhostonként és könyvtáranként egyénileg szabályozni, engedni vagy tiltani bizonyos opciókat. Az AuthConfig opcióval pedig a .htaccess-ből megvalósított felhasználó/jelszó bekérését engedélyezzük.
<Directory /var/www/>Options FollowSymLinks MultiViewsAllowOverride Authconfig Order allow,denyallow from all
</Directory>#Mint látható a /var/www könyvtárra, amely a DocumentRoot alatt helyezkedik el,
részben eltérő hozzáférési beállításokat eszközöltünk. Tiltottuk az Indexes beállítást, azaz nem engedjük a listázást, illetve hiányzik az All paraméter,azaz ott már nem dönthet a .htaccess-ben utólag beállított felülíró paraméter. Az egészre akkor lehet szükség például, ha a weboldalunknak szüksége lehet a DocumentRoot-on kívülről írni vagy olvasni, ilyen eset amikor 2 oldal egy szerveren részben közös PHP kódot használ, vagy csak biztonsági okokból elkülönítünk bizonyos dolgokat a DocumentRoot-tól szeparálva.
ErrorLog ${APACHE_LOG_DIR}/error.logLogLevel warnCustomLog ${APACHE_LOG_DIR}/iskola.hu-access.log combined
66
Webszertver feladata, telepítése és üzemeltetése
#A korábban már tárgyalt naplózási lehetőségeket rögzítjük, azaz hol legyen a site error.log fájlja, milyen részletesen legyen a napló, illetve a sima hozzáférési napló hol tárolódjon.
</VirtualHost>#itt ér véget a virtualhostunk.
Ha elmentetük, akkor kötvetkező lépésként be kell linkelnünk most létrehozot fájlt a sites-enabled könytvtárba, hogy az Apache tudja, most már használnia kell :
ln -s /etc/apache2/sites-available/001-iskola.hu /etc/apache2/sites-enabled/001-iskola.huMajd futassuk le a tesztet, hogy nem írtunk-e el tvalamit, tvagy tvéletlenül nem hagytunk ki eset-
leg egy lezáró </Virtualhost> címkét:
sudo apache2ctl configtestHa a tválasz a kötvetkező:
Syntax OKAkkor minden rendben tvan, ebben az esetben kiadhatjuk a sudo apache2ctl restart parancsot. Ha
az is hiba nélkül futot le, akkor az iskola.hu és a www.iskola.hu tartományokat is ki fogja szolgál-ni az így beállítot Apache.
Egy biztonságos tartomány beállítása
Nézzük, mi a teendő, ha HTTPS alat szeretnénk az ugyancsak a példában szereplő www.iskola.-hu és iskola.hu oldalakat konfgurálni, értelemszerűen it most csak az előző normál 80-as porton működő Apache-hoz tviszonyítot különbséget fogjuk taglalni. Azt tehát már beállítotuk koráb-ban, hogy a mods-enabled könytvtárba be legyen linkeltve az SSL confg és load fájl is, tvalamint az Apache port szinten is tudja, hogy ha a modul be tvan tölttve, akkor a 443-as porton szükséges fi-gyelnie, azért másoljuk az iskola.hu konfgurációs fájlját egy új fájlba, amelyet hítvhatunk /etc/apache2/sites-atvailable/002-iskola.huSSL-nek. A kötvetkező tváltoztatásokat eszközöljük:
A Virtualhost direktíva értelemszerűen ne 80-as hanem 443-as legyen:<VirtualHost *:443>
A szertver nétv és alias meghatározás után, de még a DocumentRoot előt a kötvetkező sorokat he-lyezzük el :
SSLEngine onSSLCertificateFile /etc/apache2/ssl/iskoal.hu.crtSSLCertificateKeyFile /etc/apache2/ssl/iskola.hu.private.key
Értelemszerűen előte az SSL fejezetben (a fejezet jelenleg készítés alat tvan, amint elkészülünk aweboldalunkon megtalálható lesz) leírtak szerint készítsük el a kulcspárokat. Ezek után ne felejt-sük belinkelni a sima iskola.hu-hoz hasonlóan az iskola.huSSL fájlt ugyanúgy a sites-enabled könytvtárba, majd az
apache2ctl configtest
parancs futatásátval győződjünk meg róla, hogy semmit nem írtunk el, és csak ezek után indítsuk újra az Apache-ot, amelyet ezútal az SSL konfguráció bőtvülése miat egy teljes értékű restart ki-adásátval érdemes megejteni:
service apache2 restart
Ha mindent jól csináltunk, és az error.log fájlban sincs jeleztve semmi hiba, akkor a 443-as por-ton a htps://www.iskola.hu oldalon meg fog jelenni pontosan ugyanaz a tartalom, mint a sima is-
67
Webszertver feladata, telepítése és üzemeltetése
kola.hu oldalon. Mitvel a HTTP és a HTTPS tvirtualhost konfgurációja nem egy fájlba let bele-raktva, ezért fgyeljünk oda arra, hogy később amikor tváltoztatni kell a HTTP konfguráción, akár egy PHP-beállítást, akár egy log tvagy Directory bejegyzést, akkor ezt a HTTPS fájlba is tvezessük át.
LighttpdA Lightpd egy kicsi és rendkítvül gyors alternatítv webszertver motor. A fejlesztését 2003-ban tel-
jesen az alap koncepció lefektetésétvel kezdték, a C10K probléma köré építtve. Fő jellemzője, hogy kifejezeten biztonságos és rendkítvül gyors, az erőforrásokat teljes mértékben kíméli, így például egy statikus tartalom kiszolgálásához jótval ketvesebb RAM- és processzorkapacitást igényel. A mostanában igen elterjedt bérelhető VPS megoldásokban gyakran használják, a szűkös erőforrá-sok optimális kihasználása érdekében. Támogatja a FastCGI, CGI, Auth, Output-Compression, URL-Rewriting, SSL opciókat és még számos más megoldást is. Sok esetben használják kirakat webszertvernek, azaz felépítenek egy LAMP környezetet, amely csak a dinamikus tartalmat szol-gálja és a statikus tartalmat egyfajta terheléscsökkentő pajzsként ugyanezen a gépen a Lightpd tveszi át. De ugyanezt a megoldást használják fordíttva is, tvagy csak képek kiszolgálására. Jelenleg olyan oldalak használják kiszolgálásra mint a YouTube, Wikipedia tvagy a meebo.
Nginx
A Nginx eltveiben nagyon hasonló a Lightpd-hez. 2004-ben Igor Sziszojetv, egy orosz rendszer- és szoftvermérnök publikálta az első tverziót belőle. Elképesztő terhelhetőség jellemzi, pontosan ugyanazon szempontok mentén, mint a Lightpd-t. Felépítése moduláris, és elképesztően sok funkciót támogat. Felhasználása nagyon hasonló a Lightpd-éhez, főként cache proxy és terhelés-elosztó funkciókat tvalósítanak meg tvele. Gyakori felhasználás, hogy a statikus képeket kiszertve-zik egy külön Nginx szertver alá, ezzel sokszoroztva meg a hardtver lehetőségeit. A szakmai fórumok tele tvannak ajánlásokkal és gyakorlati tapasztalatokkal, hogy milyen feladatra melyik szertvert érdemes és lehet használni. Mindenképpen érdemes átoltvasni ezeket egy bonyolultabb rendszer esetén, mert nem egyértelmű, hogy hosszú tátvon melyik a jobb. Jelenleg a Nginx a tvilág második legtöbbet futatot webszertvere (a saját dokumentációja szerint).
Webszerver üzemeltetéséhez szükséges komponensek
PHP
A PHP (Personal Home Page Tools) egy szertver oldali szkriptnyeltv, amely egyike az első olyan szkriptnyeltveknek, amelyet HTML kódba lehet ágyazni külső fájl használata helyet. A webszer-tverhez kapcsolódó modulként egy PHP-feldolgozó értelmezi a kódot. Az étvek során akkora fel-használói és fejlesztői bázisra talált, hogy Rasmus Lerdorf az alkotója a Te PHP Group-ra bízta a PHP-t. Mára a legelterjedtebb szkriptnyeltv let, amely messze a legtöbb lehetőséget támogatja modulrendszerétvel, mint például adatbázis-kezelés számtalan tváltozata, képmanipuláció, cache lehetőségek, tátvoli szertver kapcsolatok stb. A kezdetekben csak egy szkript gyűjtemény tvolt, de mára iparági standard let, amelyet számtalan területen használnak fel. A kezdeti „Personal Home Page Tools” megnetvezést megtváltoztaták, és ma már a PHP: Hypertext Preprocessor elnetvezést használják. Lehetőség tvan nem csak webszertveren keresztüli használatára, hanem kiszolgáló olda-
68
Webszertver feladata, telepítése és üzemeltetése
li parancssori munkára is, ezzel nagyrészt áttvétve az előte egyeduralkodó shell és Perl szkriptes megoldásokat, hiszen ugyan úgy crontab-ból is ütemezhető a PHP. A PHP biztonsága híresen ké-tes, pedig főként nem a PHP-t fejlesztők által elkötvetet tertvezési hibák jellemzőek, hanem inkább a PHP-t használó fejlesztők nem tartják be a megfelelő direktítvákat, és alaptvető biztonsági szabá-lyokat (betvitelkezelés stb.). Sokáig a PHP beépítet lehetősége tvolt a safe_mode és a köré csopor-tosuló egyéb függtvények. Sajnos tvagy szerencsére az 5.3-as tverzió kiadásátval ezek kitvezetése fokozatosan megkezdődöt, így az üzemeltetőknek és a programozóknak kell más megoldások után nézni. A safe_mode megoldás egyébként egy igen kötöt programozói tviselkedést kötvetelt meg, tviszont nagyobb látszólagos biztonságot nyújtot, mint amilyen az a tvalóságban tvolt.
A PHP telepítése
Telepítése igen egyszerű, ugyanakkor sokan nem fordítanak elég fgyelmet a telepítés utáni rész-letes beállítására, az Apache-csal tvaló összehangolásra. Ugyanis alapbeállításokkal a PHP igen megengedő üzemmódban fut, amelyen érdemes szigorítani. Az alapszintű telepítése tehát Ubuntu LTS rendszeren:
apt-get install libapache2-mod-php5 php5A php5 ezzel automatikusan települ, és a telepítőrendszer be is linkeli a PHP moduljait az
Apache megfelelő könytvtárába, majd újra is indítja az Apache-ot, azaz a telepítés után a PHP rendszer működőképes. Ekkor kell elkezdenünk a fnomhangolást:
A PHP Apache-hoz kapcsolódó beállításait az /etc/php5/apache2/php.ini fájlban találhatjuk, a fontosabb beállítások, amelyeket érdemes módosítani a telepítés után:
engine = OnEzzel ki-be kapcsolhatjuk globális szinten a PHP-t. Ezt megtehetjük tvirtualhostonként is az
Apache-ból, úgy hogy abba a tvirtualhostba, amelyben le szeretnénk tiltani a PHP-t, beírjuk a kö-tvetkezőt: php_flag engine off
Ennek főként akkor tvan jelentősége, ha egy webhelyet átmenetileg karbantartó üzemmódba te-szünk, például egy nagyobb átállás időtartamára azt akarjuk, hogy a látogatók egy index.html-ből tudomást szerezzenek róla, hogy az átállás meddig fog tartani, de ne érjék el a könytvjelzőzöt di-rekt linkeken a PHP tartalmat.
safe_mode =OffA Safe Mode egy remek próbálkozás arra, hogy rákényszerítse a programozókat a játékszabá-
lyok betartására. Sajnálatosan azonban a PHP 5.2-es tváltozatától már nem támogatot, de még részben használható. Természetesen a Safe Mode nem kínált jó megoldást a biztonsági hibás kó-dokra és részben olyan érzetet kellet az üzemeltetőkben, hogy a PHP-n keresztül az esetleges tá-madók nem tudnak majd kitörni a DocumentRoot-ból. Azaz sok esetben illúzió tvolt, de sok esetben egy fajta alternatítva tvolt arra az esetre, ha egy webszertveren eltérő tulajdonosú, tvagy fej-lesztőjű oldalak futotak. Ilyenkor egy bizonyos szeparációs biztonságot jelentet az üzemeltető-nek és igen nagy kötötséget a fejlesztőknek. Mitvel használata a totvábbiakban nem tanácsos, it eltekintünk a részletezésétől.
disable_functions = pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority
69
Webszertver feladata, telepítése és üzemeltetése
A disable_functions egy remek tváltozó arra az eshetőségre, ha szeretnénk tiltani számos progra-mozók által kedtvelt, de általunk nem szükségesnek tvélt (tvagy éppen biztonsági megfontolásból) funkciót. Erre remek példa lehet a phpinfo függtvény, amely sok esetben a fejlesztéshez elenged-hetetlen, de tvéletlen hanyagságból kint felejtet phpinfo kimenete gyakorlatilag a szertver összes lényeges és támadható paraméterét kiszolgáltatja, azaz érdemes a fejlesztési szakaszt kötvetően til-tani. A disable_classes is hasonló opció.
expose_php = OffNagyon hasonló az Apache-nál már alkalmazot beállításhoz, azaz a HTTP Header-ben megjele-
nő tényleges PHP fő- és altverziót lehet tvele elrejteni. Alaptvetően érdemes Of értéket megadni.
max_execution_time = 30Meghatározhatjuk, hogy minden egyes PHP folyamat maximum mennyi időt futhat, mielőt az
elemző kilötvi. Sok esetben a 30 másodperc ketvés szokot lenni, ezért érdemes a saját igényeinkhezigazítani, de fgyeltve arra, hogy maximum annyit adjunk, amennyi ténylegesen szükséges.
max_input_time = 60Az előző opcióhoz hasonlóan másodpercben határozzuk meg, hogy az INPUT meddig tarthat.
memory_limit = 128MEzzel meghatározzuk, hogy a PHP folyamatok mennyi tényleges memóriát fogyaszthatnak a
rendszerünkön. Sok esetben a 128MB ketvés, szintén kis lépcsőkben emeljük, és arra a tényleges maximumra ami még éppen elég, de a rendszert sem lehet kikészíteni még tvele. A jó beállításhoz aMunin grafkonjait és a top, htop parancsokat is segítségül hítvhatjuk.
error_reporting = E_ALL & ~E_NOTICEEzzel meghatározhatjuk, hogy a hibanaplózás milyen szinteken legyen bekapcsoltva. Fejlesztési
időszakban az alap beállítást érdemes meghagyni, később pedig szigorítani kell rajta, mitvel túl sokinformációt árulhatunk el így egy esetleges támadó számára.
display_errors = OffEzzel engedhetjük tvagy tilthatjuk, hogy a felhasználó a PHP szkript által okozot hibát megjele-
nítheti-e. Megint csak fejlesztési szakaszban, amikor az oldal nem publikus (például jelszótval tvédet), akkor érdemes bekapcsoltva tartani, de később kikapcsolni és inkább naplófájlba terelni az ilyen üzeneteket.
log_errors = OnEnnek használatátval megmondhatjuk, hogy az error.log-ban szeretnénk inkább látni a PHP
szkriptek hibaüzeneteit.
file_uploads = Onupload_max_filesize = 20M
Ezekkel a beállításokkal engedhetjük tvagy tilthatjuk a fájlfeltöltéseket PHP-n keresztül, tvala-mint meghatározhatjuk azok maximális méretét. Érdemes összehangolni a max_execution_time ésa max_input_time = 60 beállítással, mitvel ha engedünk több száz MB adatfeltöltést, akkor az tvél-hetőleg nem fog beleférni az alap beállításoknál meghatározot 30/60-as keretbe, fgyelembe tvétve az ithoni aszimmetrikus internetsebességeket (azaz a feltöltés a legtöbb esetben lassabb mint a le-töltési irány).
allow_url_fopen = Off
70
Webszertver feladata, telepítése és üzemeltetése
A PHP szkript számára tilthatjuk tvagy engedhetjük például a HTTP tvagy FTP tátvoli fopen hí-tvást. Ha nincs rá szükségünk (a programozók nem igénylik), akkor érdemes Of értékre állítani.
A php.ini fájlban, illettve az Apache tvirtualhostonként állítható tváltozói még számos lehetőséget kínálnak számunkra, amelyeket most nem részletezünk.
Phpmyadmin
A Phpmyadmin egy nyílt forrású, PHP nyeltven írt eszköz, amely képes webes felületen a My-SQL adatbázis-kezelő majdnem teljes körű menedzselésére. Használatátval lehetséges adatbázist kezelni és törölni, illettve a különböző egyéb adatbázissal kapcsolatos műtveletek nagy részét is el-érhetjük ezen a felületen. Híres a biztonsági incidenseiről, ezért kifejezeten fontos, hogy ne alap-beállításokkal használjuk. A szerverem-neve.hu/phpmyadmin alap hitvatkozást ne hagyjuk meg neki (nagyon könnyen megtváltoztatható, hiszen a legtöbb esetben a telepítés a disztribúció csomagke-zelőjétvel zajlik. Így ebben az esetben csak egy Apache Alias beállítás módosítása szükséges. Ha pedig letöltjük, akkor ne olyan könytvtárba rakjuk be, ami a netve.), illettve érdemes eletve HTTPS felület alat engedélyezni a használatát csak, tvalamint egy .htaccess fájlal pluszban tvédeni. A leg-több esetben használata szükségszerű, hiszen a tátvoli MySQL port engedélyezése a programozó számára, ha lehet még ketvésbé ajánlatos, mint a phpmyadmin maga.
OpenSSL
Az OpenSSL egy nyílt forrású programcsomag- és könytvtár-gyűjtemény, amely segítségétvel na-gyon sokfajta kriptográfai műtveletet tvégezhetünk el. A legtöbb Linux disztribúció alaptelepítésé-nek része, tvalamint Windows alat is elérhető. Az Apache számára tudunk a segítségétvel egy önaláírt kulcsot készíteni, amelyet a mode_ssl bekapcsolása után megfelelően befűztve lehallgatás-sal szemben ellenállóbbá tehetjük a hálózati kapcsolatot. Azaz a gyakorlatban egy HTTPS felüle-tet hozhatunk létre, illettve ugyanezt az elkészítet kulcsot akár az FTP kapcsolat biztonságosabbá tételére is felhasználhatjuk később.
71
Weboldalak: webes CMS
Weboldalak: webes CMSAz internet mára a mindennapok részétvé tvált. A saját weboldal mára a bizalom alapja let, és ha
az emberek tvalamit nem találnak meg az interneten, akkor már a létezésében, de legalábbis legiti-mitásában is kételkedni kezdenek. Ez azonban új típusú kihítvás elé állítota a tvállalkozásokat és intézményeket: egy weboldal elkészítése és üzemeltetése sokszor a fő tetvékenységtől nagyon elté-rő kompetenciákat kötvetel. Ráadásul általában nem csak egyszeri feladat, hiszen egy weboldal fo-lyamatos karbantartást és frissítést igényel. A tartalomkezelő rendszerek ezt a feladatot egyszerűsítik le. Nem kell többé minden cégnek saját weblapjához kiszolgáló szoftver keretrend-szert fejlesztenie, mitvel számos kitváló szabad szoftver megoldás létezik erre a feladatra.
A tartalomkezelő rendszer feladata, hogy lehetőtvé tegye tartalmak létrehozását, kezelését és rendszerezését – tvagyis mindazt, ami egy honlap üzemeltetésének legfontosabb része. A legismer-tebb webes tartalomkezelők a WordPress, a Drupal és a Joomla mind szabad szoftverek. Ezek kö-zül a Wordpresshez és a Drupalhoz is elérhető egy-egy kitváló kézikönytv. Ezek az alábbi honlapokon érhetők el :
WordPress könytv: http://szabadszoftver.kormany.hu/sajat-oktatasi-anyagok/
Drupal könytv: http://nagygusztatv.hu/drupal-7-alapismeretek
Ezen könytvek eloltvasása után az oltvasó képes lesz arra, hogy igényei szerint testre szabjon egy WordPress tvagy Drupal alapú weboldalt, azon tartalmakat publikáljon, kezelje a felhasználókat és akár online közösséget építsen. Ehhez pedig semmilyen különösebb előképzetséget nem felételez:aki a mindennapokban számítógépet használ, közösségi oldalakat látogat, letvelezik és boldogul egy egyszerű szötvegszerkesztőtvel, annak ezeknek a tartalomkezelőknek a használata sem jelent majd különösebb kihítvást.
72
FTP-szertver feladata, telepítése és üzemeltetése
FTP-szerver feladata, telepítése és üzemeltetése
A weboldalak adminisztrálására számtalan megoldás létezik, egyszerűbb esetben a tartalomkeze-lő felület kínál erre lehetőséget tvalamilyen bőtvítmény segítségétvel, tvagy eletve elégséges az a funkcionalitás (cikkek és képek közzététele stb.) amely adot, plusz a phpmyadmin. Ha ennél töb-bet szeretnénk, például hozzáférni a PHP és egyéb fájlokhoz köztvetlen módon, akkor kerülnek képbe a különböző hozzáférést biztosító szolgáltatások. A legtöbb esetben még mindig az FTP pro-tokollt101 használjuk erre, de sokan az OpenSSH beépítet megoldását az SFTP-t, tvagy az SCP-t al-kalmazzák. Elterjedt megoldás tvolt régebben az scp-only shell használata is, de szerencsére ezt az SFTP már jobbára kiszorítota. Manapság még inkább fontosabb alapkötvetelmény, hogy akármi-lyen megoldást is használunk, a lehetőség a szeparációra meglegyen. Azaz mindenki csak a saját könytvtárát láthassa, amikor becsatlakozik a kliensétvel, illettve mi adhassunk meg kitvételeket. Ugyanígy alapkötvetelmény ma már az is, hogy ha FTP-t használunk, akkor képes legyen SSL tvagyTLS alat működni, és ne csak az azonosítás menjen az SSL réteg alat, hanem az adatkapcsolat többi része is. Ezért most olyan klienseket fogunk bemutatni, ahol ezek a dolgok megtvalósítható-ak. Fontos ugyanakkor megemlíteni, hogy ma egy mindenki számára hozzáférhető FTP kapcsola-tot engedélyezni nagyon nagy merészség. Ma már a fejlesztők jelentős része amúgy sem akar FTP kapcsolaton keresztül fejleszteni, hanem tvalamilyen tverzió kötvető rendszert használ (subtversion, git stb.). Az FTP szertverek biztonsága igen csak kétes, éppen ezért most két megoldást fogunk ajánlani. Ha tehát egy olyan FTP szertver megoldásra tvan szükségünk, amikor is sok funkcionali-tást akarunk elérni, akkor a Pure-FTPd-t jatvasoljuk használatra, mindenképpen tűzfal mögöt. Azaz a gép 21-es portja ne legyen bárki számára elérhető az interneten, hanem szabályozzuk le akár port kopogtatással, fx IP-tvel, tvagy dinamikus DNS + tűzfal szabályokkal. Ha pedig egy ano-nymous szertvert szeretnénk felállítani, amely csak a mi publikus állományainkat szolgálja ki, ak-kor használjuk a jótval biztonságosabb tvsfpd-t, csak oltvasható üzemmódban, nyitot 21-es portal.
Pure-FTPd102
Ahogyan a weboldal első kiemelt része is említi „Security frst”, azaz a megalkotóknak a legfon-tosabb a biztonság tvolt. Támogatja a chroot-ot103, a tvirtuális szertvereket, az SSL/TLS kapcsolatot tvegyes és kizárt üzemben is. Azaz beállítható, hogy csak az azonosítás tvagy az azonosítás és az adat is titkosítot réteg alat menjen. Könnyen konfgurálható és tvirtuális felhasználói adatbázisá-tval együt egészen nagy rendszerek kialakítására is kényelmesen használható. Segítségétvel akár a www-data felhasználó netvében feltvet tvirtuális felhasználókat tudunk létrehozni, így biztosíttva, hogy a safe mode-ban futó PHP szkriptek se álljanak le bizonyos esetekben a futató környezet (Apache esetén a www-data) és a fájljogosultságok eltérése miat (safe mode gid). Szabályozható tvele az anonymous és a tényleges felhasználók sátvszélessége is, ezzel biztosíttva, hogy egy-egy na-gyobb feltöltési sátvszélességgel rendelkező felhasználó ne tudja a tvégletekig leterhelni a szertvert,
1101. http://hu.wikipedia.org/wiki/File_Transfer_Protocol1102. http://www.pureftpd.org/project/pure-ftpd1103. http://hu.wikipedia.org/wiki/Chroot
73
FTP-szertver feladata, telepítése és üzemeltetése
tvalamint megmondható az is, hogy a Pure-FTPd mekkora terhelés104 mellet szolgáljon még ki. Tá-mogatja az FXP (sertver-to-sertver) protokollt, amely segítségétvel 2 szertver közöt tudunk nagyobb mennyiségű adatot úgy mozgatni, hogy az othoni kis sátvszélességű tvonalunkon nem megy át az adat, ezzel is nagyban gyorsíttva az adatáttvitelt. Nagyon hasznos funkció totvábbá, hogy a Passitve Port Range opciótval meghatározható azon portok tartománya, ahol a passzítv mód esetén kiszol-gál. Így rögzíthetjük ezen portokat egy egyszerű Iptables szabály segítségétvel, ezzel is megköny-nyíttve a másik oldalról jötvő NAT mögüli kapcsolatok dolgát.
Telepíteni a már megszokot apt-get install pure-ftpd paranccsal lehet, ez telepíteni fogja a pure-fpd-common csomagot is mint függőséget. A telepítés után a konfgurációs fájlokat az /etc/pure-fpd/conf könytvtárban találjuk. A Pure-FTPd-t praktikusan ebbe a conf könytvtárba elhelyezet szötveges fájlok segítségétvel (és a fájlokba beleírt opció állapotátval105) tudjuk fnomhangolni, ez a gyakorlatban így néz ki (a conf könytvtár tartalma):
/etc/pure-ftpd/conf# ls -f.. AnonymousCantUpload MaxLoadMaxClientsNumber PureDB FSCharsetDaemonize BrokenClientsCompatibility MaxIdleTime DisplayDotFiles MaxClientsPerIPAllowAnonymousFXP AnonymousCanCreateDirs AnonymousBandwidthPAMAuthentication AltLog UserBandwidthTLS NoAnonymous AllowUserFXPUnixAuthentication ChrootEveryone MinUID
Nézzük egyenként az opciók jelentését és a fájlok tartalmát:
NoAnonymous [yes/no]
Ezzel engedhetjük tvagy tilthatjuk az anonymous (nétvtelen) felhasználó bejelentkezését.
AnonymousCantUpload [yes/no]
Ezzel engedhetjük tvagy tilthatjuk az anonymous felhasználónak a fájlfeltöltést. Ha megtiltjuk, akkor csak letöltheti az anonymous módban elérhető fájlokat és könytvtárakat. Alapesetben állít-suk no-ra a fájl tartalmát.
AnonymousCanCreateDirs [yes/no]
Ezzel engedhetjük tvagy tilthatjuk szintén a tvendég felhasználó számára a könytvtárak létreho-zását, alapesetben állítsuk no-ra.
AnonymousBandwidth [KB/Sec]
Ezzel beállíthatjuk, hogy a tvendég felhasználó mekkora sátvszélességgel forgalmazhat. Ha példá-ul egy népszerű szabad szoftvert teszünk ki anonymous FTP-re, akkor mindenképpen érdemes ezt az értéket egy olyan tapasztalati úton kipróbált maximumra hangolni, amely még nem tveszélyez-teti a lemez I/O műtveletekből fakadóan a gép stabil üzemét, még akkor sem ha nagyon nagy az ér-deklődés az adot fájl iránt.
AllowAnonymousFXP [yes/no]
Ezzel engedhetjük tvagy tilthatjuk, hogy a tvendég felhasználó az FXP106 protokoll szerint, a klienskihagyásátval 2 szertver közöt mozgathasson direktben adatot.
1104. http://hu.wikipedia.org/wiki/Load_(sz%C3%A1m%C3%ADt%C3%A1stechnika)1105. http://download.pureftpd.org/pure-ftpd/doc/README1106. http://en.wikipedia.org/wiki/File_eXchange_Protocol
74
FTP-szertver feladata, telepítése és üzemeltetése
AllowUserFXP [yes/no]
Ez az előző opció normál, azaz beazonosítot felhasználókra szánt tváltozata.
AltLog [clf:/var/log/pure-ftpd/transfer.log]
Ezzel beállíthatjuk az áttviteli napló pontos helyét. Alapesetben a /tvar/log/pure-fpd/transfer.log fájlban érdemes tárolni a felhasználók aktitvitását.
ChrootEveryone [yes/no]
Ezen opció segítségétvel beállíthatjuk, hogy minden felhasználó csak a számára létrehozot homekörnyezetet láthassa, gyakorlatilag / (gyökér) környezetként. Ez különösen hasznos, ha több eset-leg „idegen” felhasználót tvagyunk kénytelenek beengedni a szertverre. A szertver biztonsága érde-kében ez alapbeállítás kellene, hogy legyen, ezért állítsuk Yes-re.
Daemonize [yes/no]
Ezzel adhatjuk meg, hogy a Pure-FTPd külön démonként tvagy az inetd107 részeként fusson. Jatva-solt démon módban futatni.
DisplayDotFiles [yes/no]
Mutassa-e a pontal kezdődő netvű, rejtet fájlokat, mint például a .htaccess-t. Jatvasolt ezt kikap-csolni, azaz no-ra állítani, és csak akkor engedni a klienseknek, hogy lássák például a .htaccess-t, ha erre ténylegesen szükségük tvan.
FSCharset [UTF-8]
Ezzel beállítjuk az alapértelmezet karakterkódolást, amely ma már praktikusan az UTF-8.
MaxClientsNumber [szám]
Ezzel meghatározhatjuk, maximum mennyi felhasználót enged be egy időben a rendszer. Nagy terheltségű rendszer esetén érdemes alulról felfele haladtva teszteltve beállítani, hogy a túlterhelt-ség ne akadályozza a szertver működését.
MaxClientsPerIP [szám]
Ezzel meghatározhatjuk, hány klienst engedjen egy adot IP-címről. Tekinttve, hogy manapság már az othoni hálózatok is NAT mögöt tvannak, tátvolról 1 IP-nek látszanak, ami azt jelenti, hogy akár egy egész alhálózat lehet 1 db IP-cím mögöt (amely azért az othoni felhasználókra nem jellemző), praktikusan érdemes 1-5 közé tenni ezt a számot. Ha sok kérést kapunk Proxy tvagy nagytvállalati tűzfal gépek mögül, akkor érdemes nötvelni ezt a számot.
MaxIdleTime [perc]
Ezzel percben megadhatjuk, mennyi inaktitvitás után szakítsa meg a kapcsolatot a szertver a kli-enssel. Mitvel ezt az opciót a legtöbb klienssel felül lehet bírálni, ezért nem érdemes túl nagy szá-mot tválasztani, praktikusan 5-15 perc közöti értéket adjunk meg.
MaxLoad [szám]
A túlterhelés megakadályozására alkoták meg ezt a remek opciót, amely nem engedi a Pure-FTPd-nek, hogy egy bizonyos rendszerterheltség (load) felet totvábbi erőforrásokat emésszen fel. Általánosságban elmondható, hogy a load108 egy olyan iránymutató szám a Unix/Linux rendsze-rekben, amely esetében az 1-es alati érték jelképezi az üzemszerű erőforrás-felhasználást. Ez nem
1107. http://manpages.ubuntu.com/manpages/precise/man8/inetd.8.html1108. http://en.wikipedia.org/wiki/Load_(computing)
75
FTP-szertver feladata, telepítése és üzemeltetése
azt jelenti, hogy a MaxLoad értékének 1-et kellene beírnunk, de érdemes a top tvagy a htop prog-ram segítségétvel monitorozni az FTP szertver és a szertver terheltségét, és egy olyan értéket meg-határoznunk, amely a felhasználók tviselkedése és a hardtver tűréshatárán belül egy ésszerű érték. Ez jelenti azt is, hogy ekkor a lemez I/O tvárakozás még nem okoz nagyobb loadot és a memória-felhasználás sem terelődik át a swap tartományba. A példa kedtvéért, ez egy nagyobb terheltségű FTP szertveren jelenleg 12-es érték, de ez teljesen szubjektítv és egyedi mérésekre alapozot.
TLS [0-3]
Ezzel engedhetjük tvagy tilthatjuk, és meghatározhatjuk az SSL használatát a kötvetkezőképpen:
0: az SSL/TLS réteg tilttva tvan.
1: engedjük az SSL/TLS-t és a sima titkosításmentes kapcsolatot is
2: tvisszautasítja a nem SSL/TLS mechanizmussal kezdődő azonosítási kísérleteket, anonymous kapcsolat esetében is.
3: tvisszautasítja a titkosításmentes kapcsolatot és SSL/TLS alapú adatkapcsolatot épít ki.
Ugyanakkor az adatkapcsolati réteg esetében is kényszeríti az SSL/TLS kapcsolatot.
A 2-es és 3-as opció esetében első lépésben létre kell hoznunk az SSL kulcsot és bemásolnunk a kötvetkezőképpen:
mkdir -p /etc/ssl/privateopenssl req -x509 -nodes -newkey rsa:4096 -keyout \ /etc/ssl/private/pure-ftpd.pem \ -out /etc/ssl/private/pure-ftpd.pemchmod 600 /etc/ssl/private/*.pem
Az Ubuntu LTS-ben létvő Pure-FTPd TLS/SSL támogatással kerül csomagolásra, így az SSL kulcs elkészítése, tvalamint az opció bekapcsolása után totvábbi teendőre nincs szükség.
UserBandwidth [KB/s]
Akárcsak az anonymous esetében, it is KB/Sec-ben adhatjuk meg az azonosítot felhasználó ma-ximális áttviteli képességét. Vigyázzunk: az esetlegesen ugyanabban a hálózatban létvő felhaszná-lók akár gigabites forgalmat is generálhatnak.
MinUID [uid]
Ezzel az opciótval adhatjuk meg az azonosítás során, hogy mely felhasználók csatlakozhatnak, hiszen jellemzően a sima felhasználói szint 1000-es UID-nál kezdődik, így a root és a többi 1000 alati felhasználó még a jó jelszó megadása után sem tud csatlakozni, amely kifejezeten kítvánatosótvintézkedés. Így tartalma legyen 1000.
PassivePortRange [szám szám]
Ez egy rendkítvül fontos opció, mitvel jelen esetben kényszeríthetjük, hogy az FTP forgalom pasz-szítv üzemmód109 esetén milyen tartományban üzemeljen, így a tűzfalszabályokat is könnyedén mögé igazíthatjuk a kötvetkező módon:
A fájl tartalma legyen „420000 420100”, sima szóközzel eltválaszttva, majd pedig helyezzünk el a tűzfalunkban egy ehhez hasonló szabályt:
#FTP Passive Port + SSL
1109. http://en.wikipedia.org/wiki/File_Transfer_Protocol
76
FTP-szertver feladata, telepítése és üzemeltetése
$IPTABLES -A INPUT -p tcp --sport 20 -m state --state ESTABLISHED,RELATED-j ACCEPT$IPTABLES -A OUTPUT -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT$IPTABLES -A tcp_packets -i eth0 -p tcp -m tcp --dport 42000:42100 -j ACCEPT
Ezek után a kliensen az SSL/TLS és a passzítv mód kapcsolókat kell bekapcsoltatni a felhasználó-tval.
A Pure-FTPd és a virtuális felhasználók
Vannak olyan esetek, amikor (pl. ktvóta110 miat) szeretnénk tvirtuális felhasználókkal dolgozni. Vagy csak egyszerűen szeretnénk, hogy ha a /tvar/www alat létvő, akár több száz egyenként más és más személyhez tartozó egyedi tvirtuális hostok (önálló weboldalak) mind a www-data felhasz-náló jogaitval futnának, de csak tvirtuális felhasználók érhetnék el, mert nem akarunk nekik más (például IMAP tvagy POP3) szolgáltatásokat is nyújtani, csak FTP elérést a saját weboldalaikhoz, ésazt is meghatározot lemezkapacitással. Ebben az esetben egy remek lehetőség a tvirtuális felhasz-nálók használata, nézzük hogyan is kell ezt beállítani. Először is állítsuk be a fenti leírás szerint a Pure-FTPd-t, majd adjuk ki a kötvetkező utasításokat:
cd /etc/pure-ftpd/confecho 'no' > PAMAuthenticationecho 'no' > UnixAuthenticationecho '/etc/pure-ftpd/pureftpd.pdb' > PureDBln -s ../conf/PureDB /etc/pure-ftpd/auth/50pure
Ezekkel beállítjuk, hogy tudjon a saját adatbázisa szerint is azonosítani, egyben tiltjuk, hogy a lokális felhasználókat azonosítsa.
A tvirtuális felhasználók saját könytvtárai a /tvar/www/ alat lesznek létrehoztva, például:
mkdir /var/www/www-site1.hu
Ezzel létrehozzuk a site1.hu gyökérkönytvtárát.
chown www-data:www-data -R /var/www/www-site1.hu
Majd átadjuk a www-data tulajdonosnak a könytvtár jogait.
pure-pw useradd site1hu -u www-data -g www-data -d /var/www/www-site1.hu -N 100
Létrehozzuk a tvirtuális felhasználót 100 MB lemezktvótátval és a feltet kérdésre 2x beírjuk az új jelszatvát.
pure-pw mkdb
A Pure-Ftpd adatbázisát frissítjük, hogy tudjon az elkészítet felhasználóról.
A már elkészítet felhasználó tulajdonságait a kötvetkezőképpen listázhatjuk:
pure-pw show site1hu
Az összes felhasználót megnézhetjük a pure-pw list parancs segítségétvel, ha pedig jelszót kell tvál-toztatnunk egy már létrehozot felhasználónak, azt pure-pw passwd site1hu parancs segítségétvel tudjuk megtenni, de minden tváltoztatás utána az adatbázist is frissíteni kell a már ismertetet pure-pw mkdb parancs segítségétvel. Ezek után már nyugodtan tesztelhetjük a service pure-ftpd re-start kiadása után.
1110. http://en.wikipedia.org/wiki/Disk_quota
77
FTP-szertver feladata, telepítése és üzemeltetése
Természetesen számtalan egyéb111 opciója is létezik még a Pure-FTPd-nek, azonban a legfonto-sabb és legnépszerűbb opciókat felsoroltuk.
Vsftpd112
A projekt weboldala szerint a Vsfpd tvalószínűleg a legbiztonságosabb és leggyorsabb FTP szer-tver a Unix rendszerű gépek esetében. Az biztos, hogy akárcsak a Pure-FTPd esetében számtalan biztonsági és működést segítő opciótval rendelkezik113. Ugyancsak támogatja a tvirtuális felhaszná-lókat és az SSL/TLS-t is. Érdekessége, hogy a legnagyobb Linux terjesztések majdnem kitvétel nél-kül Vsfpd-t használnak a nagy terheltségű ISO és egyéb kiszolgálásaikra. Ahogyan a betvezetőben ajánlotuk, a Vsfp remek megoldás pl. a publikus fejlesztéseink kiszolgálására, publikálásra. Ha tehát a cél az, hogy mi (pl. SCP-tvel) felmásoljuk a Vsfp rootjába az állományainkat (changelog, tgz stb.), majd ezeket az FTP szolgálja ki eltvihető (readonly) üzemmódban, akkor kötvetkezőkép-pen érdemes eljárni:
sudo apt-get install vsftpd
Majd szerkesszük a /etc/tvsfpd.conf állományt:
anonymous_enable=YES
Megengedjük a tvendég csatlakozásokat.
guest_username=ftp
Beállítjuk az anonymous felhasználót.
anon_root=/var/ftp
Beállítjuk az anonymous document root-ot.
local_enable=NO
Megtiltjuk a lokális felhasználók belépését.
write_enable=NO
Megtiltjuk az írást.
force_dot_files=YES
Engedjük, hogy a pontal kezdődő állományokat is listázza.
hide_ids=YES
Megtiltjuk, hogy az owner és group adatokat elárulja.
max_per_ip=2
Limitáljuk, hogy egy adot IP-címről maximum 2 csatlakozás érkezhessen.
max_clients=20
Beállítjuk, hogy hány kliens csatlakozhat egy adot időben.
xferlog_enable=YES
Beállítjuk, hogy az alapértelmezet naplóállományba naplózzon (/tvar/log/tvsfpd.log).
1111. http://download.pureftpd.org/pure-ftpd/doc/README1112. https://security.appspot.com/vsftpd.html1113. https://security.appspot.com/vsftpd.html#features
78
FTP-szertver feladata, telepítése és üzemeltetése
listen_address=172.20.1.1
Beállítjuk, milyen IP-címen legyen aktítv.
listen_port=21
És ot milyen porton.
Ha készen tvagyunk, a service vsftpd restart parancs segítségétvel újraindítjuk, és tesztelhetünk is.
ProFTPD114
Talán az egyik legtöbb platformon futó, rendkítvül széles körben konfgurálható FTP démon, amelynek hosszú múltja tvan. Sajnos azonban a hosszú múltban adódtak kellemetlen biztonsági in-cidensek is, talán ezért a projekt főoldalán csak a magas konfgurálhatóságot említik első sorban. Ennek ellenére a ProFTPD igen megbízható és sokoldalú FTP szertver megoldás.
Számtalan más szabad szoftveres FTP szertver megoldás létezik még, de ma ezek a leginkább el-terjedtek. Amennyiben tájékozódni akarunk a többi megoldás tudását és elérhetőségét illetően, akkor a Wikipedia115 egy remek táblázatban ezt összefoglalja számunkra.
SFTP116
Az SFTP alrendszer részben az SCP utódja, tvalójában az SSHD egy jól elkülönítet alrendszere. Az SCP egy remek eljárás az SSH titkosítot rétegein belül fájláttvitelre. Ugyanúgy támogatja az SSH összes biztonsági megoldását, mint a parancssori mód. Azaz értvényes rá az Allow Users di-rektítva, és a kényszerítet kulcshasználat is, amikor a jelszatvas azonosítást kikapcsoljuk, és RSA tvagy DSA kulcsok segítségétvel tvégezzük el az azonosítást. De használható tvele az OTP (one time password) azonosítás is. Gyengesége, hogy egy standard SSH szertver felépítése esetén az SCP jo-got nem lehet jól elkülöníteni az SSH parancssori felület jogaitól, tvalamint nehéz chroot-ba kény-szeríteni. Van ugyan rá egy megoldás az scponly shell117, amikor is egy speciális chroot-ba kényszerítet, nagyon limitált shell környezetet kap a felhasználó, amely segítségétvel a sima SSH-tmár nem tudja használni, csak egy adot könytvtár fölöti részhez fér hozzá. Ezzel jellemzően az automatizált mentéseket lehet biztonságosabbá tenni. Az SFTP esetében azonban már az SSH konfgurációjában megmondhatjuk, hogy ki milyen séma szerint férhet és mihez. Teljesen bizton-ságos, mitvel minden adat az SSH BINARY csatornáján keresztül megy, így totvábbra is lehetőség tvan az összes biztonsági azonosítás és korlátozás használatára. Gyakorlatilag egy minimális odaf-gyeléssel ma talán ez a legmegfelelőbb megoldás a sima FTP kitváltására. Szerencsére a kliensek is számos platformon támogatják, így a fejlesztőknek is sok eszköz áll rendelkezésükre, sőt manap-ság már a kereskedelmi weblapfejlesztő és tverziókötvető rendszerek is támogatják ezt a módot. Részletesebb beállítási útmutatót a Tátvoli adminisztráció fejezet SFTP részében találunk.
1114. http://proftpd.open-source-solution.org/1115. http://en.wikipedia.org/wiki/List_of_FTP_server_software1116. http://en.wikibooks.org/wiki/OpenSSH/Cookbook/SFTP1117. https://github.com/scponly/scponly/wiki
79
FTP-szertver feladata, telepítése és üzemeltetése
Webstatisztika-készítő szoftverek
AWStats118
Ez egy alaptvetően Perl nyeltven írt, igen részletes statisztikakészítő program. Szükséges hozzá CGI támogatás az Apache szertveren belül, éppen ezért egy kicsit komplikáltabb az üzemeltetése isegy sima HTML-t kezelő programnál. Viszont sokkal több és részletesebb lehetőséget kapunk. Tu-dása gyakorlatilag a kereskedelmi statisztikakészítő programok tudásátval tvetekszik. A pontos funkciók részletezése a honlapján119 megtalálható. Üzemeltetésénél érdemes számításba tvenni, hogy CGI módban fut, ezért érdemes korlátozni és tvédeni esetleg htps és htaccess használatátval az elérhetőségét. Rendelkezik magyar nyeltv támogatással is.
Webalizer120
Az egyik legrégebbi és leggyorsabb (hiszen C nyeltven írták) naplóelemző szoftver. Beállítása és üzemeltetése is igen egyszerű. Az Awstats-szal ellentétben a Webalizer futatását tvagy emberi be-atvatkozással parancssorból (tvagy tömegesen szkripteltve) tvagy pedig cron-ból időzíttve tvégezhet-jük. Nincsen tehát gyakorlatilag támadási felülete, ugyanis sima HTML kódot + képeket publikál egy előre meghatározot könytvtárba. Honosítot számtalan nyeltvre, köztük a magyarra is. Tudása nagyon hasonló az Awstats-hoz, azonban a statikus tartalom kezelése miat ketvesebb extrát tud. Egyszerű felhasználású eszköznek igen kitváló. Bár a publikált területen a HTML oldalak támadási felületet nem kínálnak, azonban maga a statisztika adhat lehetőséget tvisszaélésre (például: egy azonosítás nélküli felület, amelyet sokszor használunk, benne lesz a publikus adatok közöt) ezért érdemes szintén htps és htaccess tvédelemmel ellátni.
Piwik121
Egy PHP és MySQL alapokon nyugtvó nyílt forráskódú, teljesen tvalós időben működő webforga-lom-analizáló szoftver. A weboldal tanúsága szerint több mint 320.000 weboldal használja és alter-natítvái akarnak lenni a Google Analytics-nek. Jelenleg 46 nyeltvet támogat, köztük a magyart is. Tudása összetetebb és szélesebb körű mint társaié, tvalamint nagy előnye, hogy az adatainkat nemszolgáltatjuk ki egy 3. félnek, azaz saját rendszerünkön belül tároljuk az adatokat.
BBclone122
Akár csak a Piwik, PHP alapokon nyugtvó tvalós idejű statisztikaszoftver, ahol szintén nem kell kiszolgáltatni az adatainkat egy kereskedelmi cégnek. Nyílt forrású és számos nyeltven támogatot,köztük magyarul is.
1118. http://awstats.sourceforge.net/1119. http://awstats.sourceforge.net/#FEATURES1120. http://www.webalizer.org/1121. http://piwik.org/1122. http://bbclone.de/
80
Fájl szertver feladata, telepítése, üzemeltetése
Fájl szerver feladata, telepítése, üzemeltetése
Fájl és nyomtatószerver heterogén hálózatok részére
Miről is szól mindez?Az alábbi írásnak nem célja a Samba összes lehetőségének bemutatása, ellenben remélhetően a
segítségétvel könnyen és gyorsan lehet egy már működő rendszer üzemeltetéséig eljutni, illettveegy teljesen új rendszert létrehozni. A ketvesebb néha több – ez tvolt az eltv a készítés közben.
Történeti áttekintésA Linux terjedésétvel jogos igényként merült fel, hogy alkalmas legyen Windows alapú számító-
gépek számára fájlszertver szolgáltatást nyújtani, ezzel kitválttva a Microsof alapú szertvereket. Eztaz igényt tvete észre a Samba fejlesztői123 csapata, és hozta létre a ma már széles körben ismertSamba szertvert. 1993-ban jelent meg az első tváltozat Nbsertver 1.5 nétven, ma pedig a Samba 4.1.1tverziónál tartunk. A fokozatosan teret hódító négyes sorozat mellet jelenleg rendkítvül elterjedt a3.6 is, amely sok működő kiszolgálón megtalálható. A Samba sok helyen bizonyítot már, 15-20 gé-pes kis cégeknél és 100-as gépszám feleti iskolákban is étvek óta üzemeltetnek tvele megbízhatóankiszolgálókat. Mitvel a Linux kliensek is alkalmasak Windows-megosztások elérésére, így tvegyeskliens környezetben is tökéletes tválasztás lehet az eltérő operációs rendszert futató ügyfelek ki-szolgálására, összekapcsolására.
Samba verziók3.6-os sorozat
A 3.6-os sorozat tulajdonképpen egy Windows NT 4.0 képességeitvel rendelkezik, alkalmas fájl-és nyomtatókiszolgálóként működni Windows alapú számítógépek számára, totvábbá WINS szol-gáltatást és tartományi beléptetést tvégezni. A Windows XP Professional operációs rendszer gondnélkül beléptethető egy 3-as sorozatú Samba tartományba, a Windows7 tviszont már igényel ehhezegy egy soros registry módosítást. Ez így 2013-ban talán ketvésnek tűnik, és sokan a Samba szemé-
1123. http://www.samba.org/
81
Fájl szertver feladata, telepítése, üzemeltetése
re is tveteték, hogy nincs tvalós Actitve Directory124 támogatás és GPO125 sem benne, de ha megnéz-zük a tvalós igényeket a kis és közepes cégeknél, akkor azt látjuk, hogy tvalójában pár közös map-pára, saját hálózati tárhelyre tvan igény, esetleg egy tvándor proflra126, hogy bármely géphez átültveugyanaz a környezet fogadja a dolgozót. Ennél többre ritkán tvan igazán szükség. Ezeket az igé -nyeket jelenleg bőtven kiszolgálja a 3.6-os sorozat. A totvábbiakban először a hármas sorozatú Sam-bát nézzük majd át, hogyan lehet tvele létrehozni egy tartományt, megosztásokat készíteni, ésahhoz megfelelő jogosultságokat adni, majd utána ugyanezt a 4-es sorozatal is megtesszük. Mi-ért? Mert jelenleg sok hálózatban ilyen működik, a Linux disztribúciók jelentős részében most isez az alapértelmezet, a jelenlegi stabil Debian127 tverzió is ezt ajánlja használatra, és csak egy 4.0.0béta csomagot tartalmaz az újabb tverzióból.
4-es sorozatA 4-es sorozat alkalmas már egy korszerű Microsof szertver kitváltására is, rendelkezik AD, GPO
és FSMO128 támogatással is. Teljes értékű tagja lehet egy Windows Actitve Directory-nak (it márnincs PDC, BDC megkülönböztetés129), és nincs szükség az újabb klienseken registry piszkálásrasem. Új szertver telepítésekor érdemes megfontolni, hogy rögtön a 4-es sorozatú Sambát telepít-sük; meglétvő régebbi telepítésekor pedig, ha az AD által hozot plusz szolgáltatásokat nem igény-lik, bátran hagyhatjuk a korábbi 3-as sorozatot fent, később bármikor dönthetünk a migrációmellet.
Samba 3.6 telepítése, konfigurálásaA döntés
Mielőt elkezdjük a telepítést, szükséges tvégiggondolni, hogy mit is szeretnénk a Sambátval. Sze-retnénk egyszerű jelszó nélküli megosztásokat, tvagy esetleg nétv és jelszó párost igénylő megosz-tásokat szeretnénk készíteni? A Samba ugyanis mindegyikre képes, atól függően, mit állítunk bea konfgurációs állományában. A fentiek azonban már egy pár gépes hálózatban is kérdésesek,akár néhány gép esetén is érdemes lehet tartománytvezérlőnek beállítani a Sambát. Az első legfon-tosabb értv e mellet, hogy így a megosztásokhoz tvaló hozzáférést sokkal fnomabban tudjuk sza-bályozni, a felhasználókat egy helyen tudjuk feltvenni, és ha ezt a lehetőséget tválasztjuk, akkormódunk tvan tvándor proflokra is, azaz a felhasználók bármely munkaállomáson jelentkeznek be, amegszokot környezet tvárja őket. Ebbe beletartozik az asztal hátere és a rajta tvéletlenszerűenszétdobált dokumentumok, parancsikonok is, tvalamint a Dokumentumok mappa is a böngésző-előzményekkel együt. Felhasználói szempontból ez egy igen fontos szempont. Mitvel nem igényela szertveren jelentős többletmunkát, ugyanakkor jelentős előnyökkel jár, így egy tartományt ho-zunk most létre. Szintén fontos, hogy a felhasználókat próbáljuk csoportokba rendezni aszerint,kiknek mihez szeretnénk jogosultságokat adni, illettve térképezzük fel előre milyen megosztásokratvan szükség, és ezekhez a megosztásokhoz mely felhasználói csoportok milyen jogokkal férhetnekhozzá. A jó tertvezés fél siker az új szertverünk létrehozásához.
1124. http://hu.wikipedia.org/wiki/Active_Directory1125. http://en.wikipedia.org/wiki/Group_Policy1126. http://en.wikipedia.org/wiki/Roaming_user_profile1127. https://wiki.debian.org/DebianWheezy1128. http://hu.wikipedia.org/wiki/Flexible_single_master_operation1129. http://en.wikipedia.org/wiki/Primary_Domain_Controller
82
Fájl szertver feladata, telepítése, üzemeltetése
A példaJelen példában egy elképzelt iskola számára hozunk létre tartománytvezérlőt. A kötvetkező fel -
használói csoportokat hozzuk létre:
– diak (diákoknak)
– tanar (tanároknak)
– adminisztracio (adminisztratítv dolgozóknak)
– admins (rendszergazdák csoportnak)Ezen csoportokba tartozó felhasználók a kötvetkező megosztásokhoz férhetnek majd hozzá:
– publikalas (tanárok számára írható/oltvasható, diákok számára oltvasható, más nem éri el)
– adminiszt (adminisztratítv dolgozók számára írható/oltvasható, más nem éri el)
– adminiszt2 (adminisztratítv dolgozók és tanárok is írhatják/oltvashatják, más nem éri el)
– hr (csak a két HR-es éri el teljes joggal, más sehogy)
– rendszergazda (rendszergazda teljes joggal eléri, mindenki más csak oltvasással)
– home (minden felhasználónak egy saját home könytvtár, amit csak ő ér el)Fenti példa teljesen elégséges lesz a Samba beállításainak megismeréséhez.
Előkészületek:A Sambát egy Debian Wheezy-re fogjuk telepíteni, ez most az aktuális stabil Debian rendszer.
Az alaptelepítésre tvan szükség. Az első dolog, amit át kell gondolni az a particionálás, hogy le-gyen egy olyan partíciónk, amelyre a Samba dolgozni fog. Amennyiben a felhasználói saját (home) könytvtárakat el szeretnénk érni Linux alól, mert mondjuk a felhasználóknak tvan postaf-ókjuk, és a Maildir könytvtáraikat úgy is ot tároljuk, tvagy esetleg később a felhasználók egy részé-nek szeretnénk sfp tvagy egyéb elérést biztosítani, akkor érdemes megfontolni, hogy a Samba a felhasználói saját könytvtárakat a rendes /home partíción tárolja. Ebben az esetben érdemes meg-fontolni, hogy a mentés lényegesen egyszerűbb lehet, ha minden fontos felhasználói adat egy he-lyen tvan, így érdemes a közös könytvtárakat is ugyanit tárolni. Ezzel elérhetjük azt, hogy a /homepartíció mentésétvel az összes felhasználói adat, a közös könytvtárak tartalma is mentésre kerül (sőtmi még a netlogon könytvtárat 130is oda tesszük). Ezeket fgyelembe tvétve mi most a /home partíci-ón fogjuk az összes megosztást elkészíteni.
Érdemes a ktvótát bekapcsolni, mitvel ezzel elejét tvehetjük, hogy a felhasználók túlságosan sokhelyet foglaljanak a rendszeren, ezt az usrquota és a grpquota beszúrásátval érhetjük el. Így néz kia kérdéses partíció bejegyzés az /etc/fstab alat:
/dev/cciss/c0d0p10 /home xfs nodev,nosuid,noexec,usrquota,grpquota0 2
Az, hogy milyen fájlrendszert használjunk, hittvita kérdése lehet, az eddigi tapasztalatok az XFS-el igen kedtvezőek tvoltak.
A gépben most két hálózati kártya tvan, mitvel kifelé is nyújt más szolgáltatásokat a kiszolgáló.(Nem ideális, de kistvállalati és iskolai környezetben jótval gyakoribb, mint azt gondolnánk.) A bel-ső hálózat a 10.0.0.0/255.0.0.0. Feltételezzük, hogy a gépen tvan Internet-kapcsolat, így indulhat atelepítés.
1130. http://www.thenetworkencyclopedia.com/d2.asp?ref=1387
83
Fájl szertver feladata, telepítése, üzemeltetése
Telepítés:Írjuk be a kötvetkezőket:
apt-get install samba
A kérdésre igennel tválaszoltva a kötvetkező csomagok kerülnek telepítésre: samba-common,samba-common-bin, tdb-tools.
Ha kiadjuk a ps ax parancsot már láthatjuk is, hogy fut a samba démon!
A telepítés során létrejöt az alapértelmezet konfgurációs állomány az /etc/samba alat smb.-conf nétven. A Samba összes beállítását ebben az /etc/samba/smb.conf állományban kell eltvégez-nünk!
Nagyon fontos, hogy a Sambában létvő Windowsos csoportokat meg kell feleltetni a Linuxoscsoportoknak. Ezt a kötvetkező lépésekkel tehetjük meg:
Linux csoportok létrehozása:
groupadd adminsgroupadd diakgroupadd tanargroupadd adminisztracio
Windows csoportok megfeleltetése a net paranccsal:
net groupmap add ntgroups="Domain Admins" unixgroup=admins rid=512 type=dnet groupmap add ntgroups="Domain Users" unixgroup=users rid=513 type=dnet groupmap add ntgroups="diak" unixgroup=diaknet groupmap add ntgroups="tanar" unixgroup=tanarnet groupmap add ntgroups="adminisztracio" unixgroup=adminisztracio
Ha ezekkel megtvagyunk, a telepítés késznek tekinthető, és jöhet a konfgurálás.
KonfigurálásA totvábbiakban az /etc/samba/smb.conf szötveges állományt szerkesztjük. Nézzük sorban a leg-
fontosabb és minket érintő beállításokat.
Globális beállítások:
[global]
Ez tvezeti be a globális beállításokat, kötelező a megléte!
interfaces = eth1 127.0.0.1/8bind interfaces only = yes
Méltatlanul elfeledet beállításpár. Többlábú gépen megadhatjuk mely interfészen fogadja a ké-réseket a Samba, így biztosan nem fogja a kültvilág felé elérhetőtvé tenni a szolgáltatásait.
hosts allow = 127.0.0.1/8 10.0.0.
Csak a localhost-ról és a 10.0.0.X címekről engedjük a hozzáférést. A localhost-ot mindenképp engednünk kell, különben nem működik a Samba, a 10.0.0.X pedig a saját belső hálózatunk gépei-nek egy csoportja.
hosts deny = 0.0.0.0/0
Biztos ami biztos minden egyéb címről még külön megtagadjuk a hozzáférést.
84
Fájl szertver feladata, telepítése, üzemeltetése
admin users = administrator
Mi a tartományi rendszergazda netve
unix password sync = yespam password change = yes
Erre a két beállításra tvan szükség, ha engedélyezni szeretnénk, hogy a Windowsos gépeiken a felhasználók módosíthassák a jelszatvaikat.
netbios name = SZERVER3
Ez lesz a szertver netve, ez látszik a tallózólistában. Igen jatvasolt a gép host netvétvel megegyező netvet tválasztani.
server string = KOZPONTI_LINUX_SZERVER
Ez jelenik meg leírásként a szertverről.
workgroup = LOK
Ez lesz a tartomány netve.
passdb backend = smbpasswd
It határozzuk meg milyen módon tárolja a jelszatvakat. Több egyéb lehetőség is tvan,131 mi a 2.2 Sambákkal tvaló kompatibilitás miat tválasztotuk ezt (azért mert jó eséllyel találkozhatunk még arról frissítet rendszerekkel is).
os level = 254preferred master = yesdomain master = yeslocal master = yes
Ha azt szeretnénk, hogy mi legyünk a főtallózók a tartományban (és legtöbbször ezt szeretnénk) akkor a fenti beállításokra tvan szükség.132
security = user
It határozzuk meg a biztonsági módot133 (share tvagy user szinteken, összesen 5 tvan).
domain logons = yes
Mitvel szeretnénk PDC (elsődleges tartománytvezérlő) lenni, így szükséges beállítás.
encrypt passwords = true
Titkosítot jelszatvak megkötvetelése
name resolve order = wins bcast host lmhosts
Hogyan történjen a nétvfeloldás. Amennyiben nem szeretnénk sok broadcast üzenetet a hálóza-tunkon, úgy a wins-et tegyük előre.
wins support = yes
It engedélyezzük, hogy szertverünk WINS134 szertverként is működjön. Lényegesen csökken a broadcast üzenetek száma a hálózaton, ha ezt engedélyezzük.
1131. http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/passdb.html1132. http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.html1133. http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/ServerType.html1134. http://hu.wikipedia.org/wiki/Windows_Internet_Name_Service
85
Fájl szertver feladata, telepítése, üzemeltetése
time server = yes
Időszertverként is működjünk a klienseknek.
display charset = UTF8unix charset = UTF8case sensitive = nodefault case = lowerpreserve case = yesshort preserve case = yes
Ezekkel a beállításokkal érjük el, hogy az ékezetes karakterek mindenhol korrektül jelenjenek meg (Windows és Linux alat is), és rendben legyen a kis- és nagybetűs fájlnetvek eltérő kezelésé-ből adódó különbség.
add machine script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false %u
Ennek a beállításnak köszönhetően nem kell a szertveren előre létrehozni a gépek fókjait, hanemamikor tartományba léptetjük a gépeket, azok automatikusan elkészülnek.
logon path = \\%L\profiles\%Ulogon drive = Z:logon home = \\%L\%U\.profiles
Ezekkel a beállításokkal tudjuk bekapcsolni a tvándor proflt, és hogy a Samba a felhasználói könytvtárat a Z meghajtóhoz rendelje.
logon path = logon drive = z:#logon home =
Így nézne ki a konfgurációs állomány idetvágó része, ha nem szeretnénk tvándor proflt használ-ni.
Logon script = %G.bat
It adhatjuk meg, hogy bejelentkezéskor milyen parancsfájl fusson le a kliensgépeken. A %G-tvel minden csoportnak eltérő parancsfájlt adhatunk meg. Rendkítvül hasznos lehetőség. Természete-sen lehet csak egy parancsfájl mindenkinek, de lehet akár felhasználónként külön-külön is.
load printers = no
Hatására nem töltődnek be a nyomtatók, azaz a Samba nem működik nyomtatókiszolgálóként.
printing = cupsprintcap name = cupsload printers = yes
Ezekkel a beállításokkal tudjuk elérni, hogy a Samba kiajánlhassa a nyomtatóinkat. Ehhez azo-kat majd a megosztás részben még defniálnunk kell azon kítvül, hogy a CUPS135-ban már megfele-lően bekonfguráltnak kell lenniük, amelynek webes felületén tökéletesen tudjuk majd azokat menedzselni is.
Ezzel a globális szekció legfontosabb beállításainak tvégére értünk, azonban egy hasznos opciót akár már it be lehet állítani ez pedig a tveto fles. A tveto fles után megadot fájl- és könytvtárnetve-ket a Samba elrejti a felhasználók elől. Hasznos lehet például akkor, ha a felhasználók letvelezése Maildir formátumban a saját könytvtárukban tvan, mert így például nem tudják azt tvéletlenül tvagy szándékosan törölni, mitvel nem is látják azt. Használata:
1135. http://www.cups.org/
86
Fájl szertver feladata, telepítése, üzemeltetése
veto files = /Maildir/
A másik hasznos lehetőség a naplózás szabályozása.
log file = /var/log/samba/log.%mmax log size = 50
A fenti beállításokkal netbios netvenként külön naplóz minden gépet és 50Kb-onként kezd új naplófájlt.
Megosztások
Az smb.conf másik fontos része a megosztások. A megosztások netveit [kapcsos zárójelek] közé kell tenni. Vannak kötelező megosztások, és tvannak, amiket tetszőlegesen készíthetünk el.
Kötött megosztások
[netlogon]
Az it létvő parancsfájlokat futatják le a kliensek bejelentkezéskor.
[profiles]
Ide kerülnek a felhasználói proflok (tvándor proflok esetén).
[homes]
It defniáljuk a felhasználók saját könytvtárait
[printers] [print$]
Az első a globális nyomtatómegosztás, helyete használhatunk nyomtatónként külön is. A máso-dikra akkor tvan szükségünk, ha azt szeretnénk, hogy a nyomtatómeghajtók kliensre telepítése au-tomatikusan megtörténjen.136
Megosztásaink
A megosztások felhasználók általi használatát, amennyiben elég jól átgondoltuk a csoportok jogait, némi segítséggel könnyen szabályozhatjuk. Most a konkrét megosztásokon keresztül fog-juk tvégigtvenni a beállítási lehetőségeket. Nézzük, hát milyen megosztásokat defniálunk:
[netlogon]browseable = nopath = /home/samba/netlogonread only = yeswrite list = @admins
A netlogon megosztás nem tallózható (nem látszik a tallózólistában), a Linuxon létvő fzikai könytvtár helye a „/home/samba/netlogon”, csak oltvasható, ugyanakkor az admins csoport tagjai (tartományi rendszergazdák csoportja) mégis írhatnak bele.
[profiles]browseable = nopath = /home/samba/profilesread only = nocreate mask = 0600directory mask = 0700
1136. https://wiki.samba.org/index.php/Samba_as_a_print_server
87
Fájl szertver feladata, telepítése, üzemeltetése
A profles megosztás nem tallózható, fzikailag a /home/samba/profles a helye a szertveren, csak oltvasható, az it létrejötvő fájlok 600, a könytvtárak 700 joggal jönnek létre (klasszikus Linux jogo-sultság szerint).
[homes]valid users = %Scomment = Felhasznalo sajat konyvtarabrowseable = nowritable = yescreate mask = 0700directory mask = 0700
A homes megosztásból (felhasználók saját könytvtára) minden felhasználó csak a saját „saját könytvtárát” éri el. Felhasználó saját könytvtára lesz a megjegyzés, nem tallózható, írható, és 700 joggal jönnek benne létre a fájlok és a könytvtárak is.
[publikalas]valid users = @tanar @admins @diakpath = /home/samba/publikalascomment = tanarok szamara publikalasrabrowseable = yescreate mask = 0755directory mask = 0755writable = yes
A publikalas könytvtárba csak a tanar, admins és diak csoport tagja léphetnek be, tallózható, 755-ös joggal jönnek létre a könytvtárak és fájlok, tvalamint írható. (Ha Linuxon úgy néz ki fájl szinten a megosztás könytvtára, mint it: drwxrwxr-x root tanar publikalas, akkor máris elértük, hogy a tanár csoport tud bele írni, a diákok pedig csak oltvasni tudják.)
[adminiszt]valid users = @adminisztracio verocsek vorosdpath = /home/samba/adminisztraciocomment = adminisztrativ dolgozoknak, zartbrowseable = yescreate mask = 0750directory mask = 0750force group = adminisztraciowritable = yes
Az adminiszt megosztást elérhetik az adminisztracio csoportba tartozó felhasználók, de rajtuk kítvül a tverocsek és a tvorosd netvű felhasználó is. Tallózható, 750-es joggal jönnek létre benne az objektumok, és minden fájl és könytvtár az adminisztracio csoport netvében jön létre. Írható meg-osztás. A force group-pal érjük el, hogy az egyébként tanár tverocsek és tvorosd felhasználók által létrehozot fájlok, könytvtárak oltvashatóak legyenek az adminisztracio csoport tagjai számára, mi-tvel minden általuk létrehozot fájl és könytvtár tulajdonoscsoportja az adminisztracio csoport lesz, hiába tartoznak ők a tanárok közé tvalójában. (A könytvtár Linux alól így néz ki: drwxrwx--- root adminisztracio adminisztracio.)
[adminiszt2]valid users = @adminisztracio @tanarpath = /home/samba/adminisztrac2comment = adminisztrativ dolgozoknak, nyiltbrowseable = yescreate mask = 0750
88
Fájl szertver feladata, telepítése, üzemeltetése
directory mask = 0750writable = yesforce group = adminisztracio
Az adminiszt2 megosztáshoz az adminisztracio és a tanar csoport tagjai csatlakozhatnak csak. Függetlenül atól, hogy tanár tvagy adminisztratítv dolgozó hozot létre tvalamit, az 750-es joggal az adminisztratítv dolgozók csoport tulajdonában lesz. Így elértük, hogy a két külön csoport tudja ol-tvasni egymás elmentet fájljait, írni pedig mindenki csak a sajátját. (Természetesen Linuxon az ad-minisztracio csoportnak rwx joga kell legyen a könytvtáron.)
[hr]valid users = balazs petrawrite list = balazs petrapath = /home/samba/hrcomment = hr-es dolgozoknakbrowseable = yescreate mask = 0770directory mask = 0770writable = yesforce group = adminisztracio
A hr megosztásba már csak 2 felhasználó léphet be, nem pedig az egész adminisztracio csoport. Ők keten a balazs és a petra felhasználók. Minden, amit létrehoznak, az adminisztracio csoport jogátval jön létre, ráadásul it 770 a jog, tehát képesek egymásét törölni is, nem csak oltvasni.
[rendszerg]path = /home/samba/rendszergazdacomment = rendszergazdai publikaciokbrowseable = yescreate mask = 0755directory mask = 0755read list = @tanar @diakok @adminisztraciowrite list = @admins writable = yes
A rendszerg megosztáshoz hozzáférnek a diákok, a tanárok és az adminisztratítv dolgozók is, azonban csak oltvasási joggal, írási joga egyedül a rendszergazdák csoportnak tvan. (Linux alat tva-lami hasonlónak kell lennie a könytvtárnak: drwxrwxr-x administrator admins rendszergazda)
A megosztásoknál lehet tovább cifrázni, ha a fájlrendszerünk támogatja az ACL-eket, il-letve néha jól jöhet az immutable vagy az append bit137 beállítása is egy-egy könyvtáron.
Totvábbi hasznos lehetőség lehet, ha szeretnénk lomtárakat létrehozni a hálózati megosztásokon,ezt megosztásonként lehet az alábbi példa szerint:
vfs objects = recyclerecycle:repository = /home/samba/adminisztracio/kuka/%U
Példa nyomtatók megosztására
[anyomiga] comment = Kozpotni nyomtato adminisztrativ dolgozoknak igazgatasi csoport valid users = @adminisztracio @admins muszashi tami
1137. http://en.wikipedia.org/wiki/Chattr
89
Fájl szertver feladata, telepítése, üzemeltetése
path = /var/spool/samba printer = anyomiga writable = no printable = yes use client driver = yes
A szokásos értelmezés alapján a nyomtatóra csak a rendszergazda csoportba és az adminisztra-cio csoportba tartozók nyomtathatnak, rajtuk kítvül még a muszashi és a tami felhasználó. Vegyük észre, hogy ez nem írható, ellenben nyomtatható megosztás. Ezen eltv alapján tudunk totvábbi nyomtatókat is feltvenni a rendszerbe. Fontos, hogy a printer= után megadott név pontosan egyezzen a CUPS-ban konfgurált névvel! Az use client driver abban az esetben kell, ha kliens oldalon telepítjük a nyomtatók meghajtóprogramjait. Nélküle csak nulla méretű fáj-lok sorakoznak majd a /tvar/spool/samba könytvtárban. Ha azt szeretnénk, hogy a szertverről auto-matikusan települjenek a meghajtóprogramok, akkor totvábbi lépéseket kell tennünk.138
A netlogon könyvtár szkriptjei
A netlogon könytvtárban elhelyezet szkriptek lefutnak a klienseken történő belépéskor. Jelenle-gi beállítással minden csoportnak külön szkriptje tvan, ami azt jelenti, hogy a szkript netve meg-egyezik a felhasználói csoport netvétvel. Jelen esetben adminisztracio.bat, tanar.bat, diak.bat. Érdemes ezeket a fájlokat Windowson szerkeszteni, mitvel a linuxos sortvégjel nem jó a windowsosklienseknek. Annak érdekében, hogy lássuk mikre lehet használni, nézzünk megint egy példát, a diak.bat tartalmát:
echo offecho "Csatlakozas a szerverhez..."echo "Mappolom a home konyvtarat a Z: meghajtohoz"net use z: /HOME /yes start \\szerver3\netlogon\shortcut.vbsecho "Ora szinkronizalasa a szerverhez"net time \\szerver3 /set /yesecho "Tovabbi konyvtarak rendszerhez adasa..."net use k: \\szerver3\publikalas /yes start \\szerver3\netlogon\shortcut5.vbsnet use r: \\szerver3\rendszerg /yes start \\szerver3\netlogon\shortcut4.vbsecho "...tovabbi parancsikonok elhelyezese"start \\szerver3\netlogon\shortcut9.vbsstart \\szerver3\netlogon\shortcut10.vbs
… és példaképp az egyik hitvatkozot tvbs fájlt is (szintén a netlogon könytvtárban tvan):
' VBScript.Dim Shell, DesktopPath, URLSet Shell = CreateObject("WScript.Shell")DesktopPath = Shell.SpecialFolders("Desktop")Set URL = Shell.CreateShortcut(DesktopPath & "\Rendszergazda.LNK")URL.TargetPath = "R:\"URL.Save
Látható, ez például kiteszi az asztalra a rendszergazda megosztás parancsikonját, amelyet a szkriptben R: meghajtóként felcsatoltunk. Ezzel könnyíthetjük meg felhasználóink és a saját éle-tünket is.
1138. https://wiki.samba.org/index.php/Samba_as_a_print_server
90
Fájl szertver feladata, telepítése, üzemeltetése
Felhasználók létrehozása
Először adjuk hozzá az administrator felhasználót a rendszerhez az alábbi parancsokkal:
useradd -m -s /bin/false -c "Samba Admin" -G admins administratorsmbpasswd -a administrator
A felhasználókat létrehozhatjuk egyesétvel is, de érdemes tvalamilyen szkriptet készíteni amitvelkönnyebbé tehetjük a munkát. It most láthatjuk egy régi rendszer felhasználólétrehozó szkriptjétátalakíttva, amiben eredetileg tvolt e-mail fók, csoportmunka hozzáférés létrehozása és ktvóta is, demost csak a lecsupaszítot Samba hozzáférések létrehozását csinálja. Arra mindenképpen jó, hogyez alapján lehessen sajátot készíteni.
#!/bin/bashclearecho " ............ Felhasználó létrehozó script! ............"# felhasznaloi csoport konstansok export CSOPORT1="diak"export CSOPORT2="tanar"export CSOPORT3="adminisztracio"# Kvota konstansokexport CSOP1K="300000"export CSOP2K="1024000"export CSOP3K="2048000"# felhasznaloi alapadatokexport VNEV=""export KNEV=""export UNEV=""export KORNYEZETE="/bin/false"export PASSWORDJE=""export CSOPORTJA=""# Adatok bekérése:echo "Kérem a felhasználó vezetéknevét: "read VNEVecho " "echo "Kérem a felhasználó keresztnevét: "read KNEVecho " "echo "Kérem a felhasználó user-nevét: "read UNEVcat /etc/passwd | grep $UNEVPROBA=$?case "$PROBA" in1): echo "OK!";;0): echo "Sajnálom $USERNEV felhasználó MÁR létezik!!!"; exit 1;;esacecho " "echo "Kérem a felhasználó jelszavát: "read PASSWORDJEecho " "echo " "
91
Fájl szertver feladata, telepítése, üzemeltetése
echo "Neve: " $VNEV" "$KNEV "Userneve: " $UNEV " jelszava: " $PASSWORDJE echo " "echo " "echo "Mely csoporthoz kíván felhasználót hozzáadni:"echo "1," $CSOPORT1echo "2," $CSOPORT2echo "3," $CSOPORT3echo ""read valasztascase "$valasztas" in1): export CSOPORTJA=$CSOPORT1; useradd -m -p $PASSWORDJE -s $KORNYEZETE -c $UNEV -g $CSOPORTJA $UNEV; echo $UNEV:$PASSWORDJE|chpasswd –md5; (echo $PASSWORDJE; echo $PASSWORDJE)|smbpasswd -s -a $UNEV;;2): export CSOPORTJA=$CSOPORT2; useradd -m -p $PASSWORDJE -s $KORNYEZETE -c $UNEV -g $CSOPORTJA $UNEV; echo $UNEV:$PASSWORDJE|chpasswd –md5; (echo $PASSWORDJE; echo $PASSWORDJE)|smbpasswd -s -a $UNEV;;3): export CSOPORTJA=$CSOPORT3; useradd -m -p $PASSWORDJE -s $KORNYEZETE -c $UNEV -g $CSOPORTJA $UNEV; echo $UNEV:$PASSWORDJE|chpasswd –md5; (echo $PASSWORDJE; echo $PASSWORDJE)|smbpasswd -s -a $UNEV;;esacecho ""echo "A kiválasztott csoport: $CSOPORTJA"echo " "echo "A művelet végetért... "
A teljes /etc/samba/smb.conf
It pedig egyben látható az elkészült konfgurációs állományunk, az /etc/samba/smb.conf tar-talma:
[global]interfaces = eth1 127.0.0.1/8bind interfaces only = yeshosts allow = 127.0.0.1/8 10.0.0.hosts deny = 0.0.0.0/0admin users = administratorunix password sync = yespam password change = yesnetbios name = SZERVER3server string = KOZPONTI_LINUX_SZERVERworkgroup = LOKpassdb backend = smbpasswdos level = 254preferred master = yesdomain master = yeslocal master = yessecurity = userdomain logons = yes
92
Fájl szertver feladata, telepítése, üzemeltetése
encrypt passwords = truewins support = yesname resolve order = wins bcast host lmhoststime server = yesdisplay charset = UTF8unix charset = UTF8case sensitive = nodefault case = lowerpreserve case = yesshort preserve case = yesadd machine script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false %ulogon path = \\%L\profiles\%Ulogon drive = Z:logon home = \\%L\%U\.profilesLogon script = %G.batprinting = cupsprintcap name = cupsload printers = yeslog file = /var/log/samba/log.%mmax log size = 50
[netlogon]browseable = nopath = /home/samba/netlogonread only = yeswrite list = @admins
[profiles]browseable = nopath = /home/samba/profilesread only = nocreate mask = 0600directory mask = 0700
[homes]valid users = %Scomment = Felhasznalo sajat konyvtarabrowseable = nowritable = yescreate mask = 0700directory mask = 0700
[publikalas]valid users = @tanar @admins @diakpath = /home/samba/publikalascomment = tanarok szamara publikalasrabrowseable = yescreate mask = 0755directory mask = 0755writable = yes
[adminiszt]valid users = @adminisztracio verocsek vorosdpath = /home/samba/adminisztracio
93
Fájl szertver feladata, telepítése, üzemeltetése
comment = adminisztrativ dolgozoknak, zartbrowseable = yescreate mask = 0750directory mask = 0750force group = adminisztraciowritable = yes
[adminiszt2]valid users = @adminisztracio @tanarpath = /home/samba/adminisztrac2comment = adminisztrativ dolgozoknak, nyiltbrowseable = yescreate mask = 0750directory mask = 0750writable = yesforce group = adminisztracio
[hr]valid users = balazs petrawrite list = balazs petrapath = /home/samba/hrcomment = hr-es dolgozoknakbrowseable = yescreate mask = 0770directory mask = 0770writable = yesforce group = adminisztracio
[rendszerg]path = /home/samba/rendszergazdacomment = rendszergazdai publikaciokbrowseable = yescreate mask = 0755directory mask = 0755read list = @tanar @diakok @adminisztraciowrite list = @admins writable = yes
[Deskjet_3510] comment = Kozpotni nyomtato adminisztrativ dolgozoknak igazgatasi csoport valid users = @adminisztracio @admins muszashi tami path = /var/spool/samba/ printer name = Deskjet_3510 writable = no printable = yes use client driver = yes
A konfgurációs állományunk helyességét ellenőrizhetjük a szertveren a testparm parancs kiadá-sátval.
94
Fájl szertver feladata, telepítése, üzemeltetése
Samba használataMost tehát már elkészült a konfgurációs állományunk, feltvetük az administrator és az egyéb
felhasználókat, így nincs más teendő, mint elindítani a Sambát.
Samba indítása
service samba start
tvagy a régi módon az
/etc/init.d/samba start
segítségétvel tudjuk megtenni.
Kliensek tartományba léptetése
A windowsos gépeken jelentkezzünk be rendszergazda jogú felhasználótval, hogy a gép tarto-mányba léptetését el tudjuk tvégezni. XP esetén nincs extra teendő, ugyanakkor Windows 7 alatszükséges az alábbi registry beimportálása:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters]
"DNSNameResolutionRequired"=dword:00000000"DomainCompatibilityMode"=dword:00000001
A tartományba léptetést a Vezérlőpult\Rendszer és Biztonság\Rendszer úttvonalon a számítógép-nétv módosítása alat tudjuk megtenni. A tagságot munkacsoportról tartományra kell állítani és bekell írni a tartomány netvét (LOK). Kötvetkező lépésként egy felugró ablakban meg kell adni a tar-tományi rendszergazda (administrator) netvét és jelszatvát. Ha mindent jól csináltunk, sikeresen bekell tudni lépjünk a tartományba.
Hasznos segédeszközök
Pár eszközt érdemes lehet telepíteni a szertveren. Ezek a cifs-utils csomagban találhatóak. Tele-pítsük őket a szokásos módon!
apt-get install cif-utils
Hasznos segédeszközeink egy Samba szertveren:
– smbclientSokcélú programocska, például a Samba elindítása után rögtön ellenőrizhetjük tvele, hogy mű-ködik-e: smbclient -L localhost -U administrator
– nmblookupNétvfeloldás ellenőrzésére tökéletes, például így: nmblookup -U szerver IP -A egy kliens IP
– smbtreeMegjeleníti a hálózaton létvő összes aktítv Netbios netvet
– smbstatusA legfontosabb eszköz: láthatjuk, mely felhasználók, mely gépeken, milyen megosztásokon mitcsinálnak éppen.
95
Fájl szertver feladata, telepítése, üzemeltetése
Samba 4 telepítése, konfigurálásaEbben a részben telepítünk egy Samba 4-es tartományt, gyakorlatilag ugyanazt a rendszert tvaló-
sítjuk meg a négyes Samba segítségétvel, amit az előző oldalakon a 3.6-os ismertetésénél már egy-szer létrehoztunk. Ami onnan már ismerős lehet, azt it már csak megemlítjük, részletesen nemtárgyaljuk. Főként az eltéréseken lesz ebben a részben a hangsúly. Mivel a Samba 4 még folyama-tosan változik, így az it leírt dolgok csak ebben a verzióban működnek biztosan!
Samba 4 igényeiA Samba 4 az Actitve Directory miat rengeteg komponens meglétét igényi, jótval összetetebb,
mint a korábbi sorozatok. A kötvetkezőkre tvan szüksége a megfelelő működésre:
– DNS szertver
– Kerberos
– NTP
– LDAP
– ACL és Extended AtributesA fentieken kítvül jatvasolt még a quota támogatás, és egy CUPS szertver telepítése is (nyomta-
táshoz).
Ami szerencse, hogy a Samba 4 tartalmaz LDAP-ot, tvan belső DNS szertvere is, Kerberos-t semkell telepítenünk. Természetesen lehet külső eszközöket használni, például BIND lehet a DNSszertver, azonban egy alap telepítéshez tökéletesen jól használhatóak a Samba beépítet megoldá-sai. NTP-szertvert ellenben telepítenünk kell majd, mitvel pontos idő nélkül a Kerberos nem mű-ködne helyesen (egészen pontosan arra tvan szükségünk, hogy a kliensek és a szertver órája járjonegyüt, az lényegtelen ez miként tviszonyul a tvalós időhöz). A fájlrendszer ACL és XATTR támoga-tására szükségünk tvan, mert ezen keresztül tudnak tárolódni a windowsos jogosultságok, CUPS-otis telepítenünk kell, mitvel nyomtatni szeretnénk és természetesen a quota is fontos lehet, ezértmajd azt is beállítjuk az fstab fájlban.
Samba 4 beszerzéseA Samba 4 beszerzése rögtön kihítvásokkal teli, mitvel az általunk használt stabil Debian tverzió-
ban a 3.6 az alapértelmezet és ajánlot, 4-es sorozatból csak 4.0.0 beta tvan benne, amit még a ké-szítők sem ajánlanak produktítv környezetbe. Jelenleg 2 módon lehet hozzájutni:
– forrásból telepíttve
– enterprisesamba oldalról letölttve a debian csomagokatMi az utóbbi megoldást tválasztjuk, és a kötvetkező lépéseket kötvetjük:
– Először el kell látogatni a http://enterprisesamba.com/ oldalra, és ot regisztrálni szüksé-ges. A regisztráció és a letöltés ingyenes. Miután regisztráltunk, kapunk egy jelszót, amitvel majd le tudjuk tölteni a csomagokat.
– Állítsuk be az /etc/apt/sources.list fájlban, hogy az enterprisesamba oldal is a források közöt legyen, ezt a kötvetkező sor beszúrásátval tudjuk megtenni :
deb https://USERNAME:[email protected]/packages/samba/4.0/debian
96
Fájl szertver feladata, telepítése, üzemeltetése
wheezy main
A USERNAME helyére a felhasználói netvet, az ACCESSKEY helyére a kapot jelszót írjukbe.
– Töltsük le és telepítsük a kulcsokat az alábbi parancsok begépelésétvel!
wget http://ftp.sernet.de/pub/sernet-samba-keyring_1.4_all.deb dpkg -i sernet-samba-keyring_1.4_all.deb
– Megfgyelhetjük, hogy a telepítési források htps-en keresztül érhetőek el. Ahhoz, hogy az apt kezelni tudja ezt, előbb telepíteni kell az apt-transport-htps csomagot. Tegyük meg:
apt-get install apt-transport-https
– Frissítsük a csomaglistát!
apt-get update
– Telepítsük a Sambát!
apt-get install sernet-samba-ad
– Amennyiben a Samba sikeresen települt, azt ellenőrizzük le a tverzió lekérésétvel:
samba -V
Jó esetben, tvalami ilyet kapunk tválaszul : Version 4.0.10-SerNet-Debian-8.wheezy. Tehát jelenleg a 4.0.10 a legfrissebb amihez hozzájuthatunk.
További előkészítő munkálatokMint feljebb már tvolt róla szó, szükségünk tvan egy NTP-szertverre. Ezt könnyedén telepíthetjük
az alábbi parancs begépelésétvel :
apt-get install ntp
Ha szeretnénk (nem kötelező), akkor utána a pool-kat módosíthatjuk az /etc/ntp fájlban hu ne-tvűekre így:
server 0.hu.pool.ntp.orgserver 1.hu.pool.ntp.orgserver 2.hu.pool.ntp.orgserver 3.hu.pool.ntp.org
A helyes működést ellenőrizhetjük az alábbi paranccsal:
ntpq -p
Engedélyeznünk kell a Samba számára fenntartot partíciókon az ACL és Extended Atributes, il-lettve a quota támogatást is. Ehhez előbb telepíteni kell ezeket az alábbi paranccsal:
apt-get install acl attr
Ezután szerkesszük az /etc/fstab állományt az alábbi mintához hasonlóan:
/dev/sda3 /home ext4 defaults,nodev,nosuid,usrquota,grpquota,user_xattr,acl,barrier=1 0 2
97
Fájl szertver feladata, telepítése, üzemeltetése
Ebből az acl és a user_xattr megléte most a lényeges számunkra. A barrier=1 a Samba csapatajánlása, mely szerint nélküle hirtelen áramszünetkor előfordult pár adatbázissérülés, szóval inkábbtegyük be mi is.
Ellenőrizzük, hogy a hálózati beállítások rendben legyenek. Ez alatt az értendő, hogy az /etc/re-solv.conf állományban legyen valamilyen működő DNS beállítva (ezt az értéket fogja majd a Sam-ba bemásolni az /etc/samba/smb.conf állományba), és tanácsos, ha a gép hostneve megegyezikazzal a névvel, ami a tartomány neve lesz, mert az eltérő hostnév esetenként problémát okozhat.
Ha mindezekkel megvagyunk indulhat a Samba konfigurálása!
KonfigurálásA samba-tool nevezetű programot kell használnunk az alapbeállítások elkészítéséhez. A parancs
használható interaktív módon is (samba-tool domain provision –interactive), illetve úgy is hogy rögtönmegadjuk neki a kívánt értékeket. Íme:
samba-tool domain provision --realm=lok.local --domain=lok --server-role=dc --adminpass=Tuj024b
Látható, hogy meg kell adni a teljes tartománynevet (lok.local), a tartománynevet (lok), a szerverszerepkörét (dc, azaz domain controller, tartományvezérlő) és az admin felhasználó jelszavát. Ezutóbbira külön figyeljünk, mert csak kellően bonyolult jelszót fogad el, kis- és nagybetű, valamintszám kombinációt. Gyenge jelszó esetén a folyamat, amely a parancs indítása után fog kezdődni, avége felé hibával megszakad.
Ezzel el is készült a tartományvezérlőnk, létrejön egy alap smb.conf az alábbi tartalommal:
[global]workgroup = LOKrealm = lok.localnetbios name = SZERVER4server role = active directory domain controllerdns forwarder = 8.8.4.4
[netlogon]path = /var/lib/samba/sysvol/lok.local/scriptsread only = No
[sysvol]path = /var/lib/samba/sysvolread only = No
Láthatunk itt egy új megosztást sysvol néven: ez a csoportházirendekhez kell, nélküle nem lenneAD-vezérlő a Sambánk, illetve látható egy dns forwarder bejegyzés is, amely arra a DNS-szerverremutat, ami telepítéskor be volt állítva az /etc/resolv.conf-ban, és felé irányítja a külső lekérdezése-ket.
Utómunkálatként töröljük ki az összes futási szint könyvtárából (/etc/rc könyvtárak) az összes sernet-samba-nmbd, sernet-samba-smbd, sernet-samba-winbindd-re mutató linket. A sernet-samba-ad-t viszont feltétlen hagyjuk meg, mivel ezzel tudjuk indítani, leállítani a Samba 4 szerverünket.
Szerkesszük az /etc/default/ könyvtárban a sernet-samba állományt úgy, hogy a samba_start_mode=”none” helyett „ad” legyen:
SAMBA_START_MODE="ad"
Eljött az indítást, tesztelés ideje.
98
Fájl szertver feladata, telepítése, üzemeltetése
/etc/init.d/sernet-samba-ad restart
Újraindítjuk a Samba szervert.
ps ax
A paranccsal meggyőződhetünk, hogy fut-e (ilyen sorokat kell látnunk a kimenetben /usr/sbin/samba -D).
smbclient -L 127.0.0.1 -U%
A parancs kiadására látnunk kell, hogy mi a tartomány neve, milyen megosztások vannak stb. Ha a Samba jól fut, teszteljük le még a DNS-szolgáltatását is.
host -t SRV _ldap._tcp.lok.local. 10.0.0.1
A 10.0.0.1 a saját szerverünk IP címe, hiszen tőle várunk eredményt a lekérdezésre.
host fsf.hu 10.0.0.1
...és végül ellenőriztük, hogy külső címet is helyesen old fel.
Fontos, hogy a klienseken a Samba szerver címe legyen majd megadva DNS-szervernek! Ha min-den jól működött, akkor tényleg elkészült a tartományvezérlő, mostantól be lehet léptetni a tarto-mányba a gépeket.
További globális beállítások
Érdemes azonban még további beállításokkal bővíteni a [global] szekciót. Hogy mik az alapértel-mezett beállítások, azt a hármas sorozattal ellentétben itt a samba-tool testparm -v paranccsal kapjukmeg.
Ezek a beállítások már a hármas Samba ismertetésekor említésre kerültek, így tudjuk szabá-lyozni, hogy csak a belső interfészünkön kommunikáljon a Samba:
interfaces = eth1 lobind interfaces only = yes
Az előző tverziónál ismertetet host allow, host deny-t ne kapcsoljuk be, mert akkor látszólagműködő, tallózható szertverünk lesz, ellenben mikor szeretnénk majd menedzselni windowsos kli-ensről a gépet (hamarosan), akkor nem fogja elérni a DC-t a megfelelő segédprogram.
Gyakorlatilag ennyi elég is, mitvel sok minden egész másképp zajlik a 4-es sorozatban, mint azelődben, ezt már rögtön a kötvetkező részben is láthatjuk.
Megosztások
A legfontosabb, hogy már nem kell a linuxos könyvtárszerkezetben beállítani semmilyen különös jogosultságot (csoportnak stb.), egyszerűen legyenek a könyvtáraink a root számá-ra írhatóak.
Hozzuk először létre az alaptvető működéshez szükséges megosztásokat:
[home]path = /home/samba/homeread only = No
[Profiles]path = /home/samba/Profiles/writable = yes
Majd az összes többi megosztásunkat:
99
Fájl szertver feladata, telepítése, üzemeltetése
[publikalas]path = /home/samba/publikalascomment = tanarok szamara publikalasrabrowseable = yeswritable = yes
[adminiszt]path = /home/samba/adminisztraciocomment = adminisztrativ dolgozoknak, zartbrowseable = yeswritable = yes
[adminiszt2]path = /home/samba/adminisztrac2comment = adminisztrativ dolgozoknak, nyiltbrowseable = yeswritable = yes
[hr]path = /home/samba/hrcomment = hr-es dolgozoknakbrowseable = yeswritable = yes
[rendszerg]path = /home/samba/rendszergazdacomment = rendszergazdai publikaciokbrowseable = yeswritable = yes
[Deskjet_3510]comment = Kozpotni nyomtato adminisztrativ dolgozoknak igazgatasi
csoportpath = /var/spool/samba/printer name = Deskjet_3510writable = noprintable = yes
Látható, jócskán csökkent egy-egy megosztásnál a tartalom, mitvel a tvalid user és force groupamikkel eddig tudtuk kordában tartani a megosztásokhoz tvaló csatlakozást, feleslegessé tvált, he-lyete az Actitve Directory-ban fogjuk megmondani, ki mihez férhet hozzá. (Működnek, eltvbenhasználhatóak, csak immár feleslegesek.)
Hozzuk létre a fájlrendszerben is a könytvtárakat, amelyekre a megosztások mutatnak, egyedül anyomtató megosztásnál fgyeljünk rá, hogy a csoportnak és mindenki másnak is teljes hozzáférésijoga legyen a könytvtárhoz, azaz azt így hozzuk létre:
mkdir -p /var/spool/samba/chmod 1777 /var/spool/samba/
A Samba alapból támogatja a CUPS-ot, tehát nem kell erre semmilyen konfg sort beírjunk a glo-bal szekcióban.
Tartomány kezeléseEljött az idő, hogy a tartományi rendszergazda nevében bejelentkezzünk egy windowsos gépen, és
a hármas Sambánál leírt módon beléptessük a tartományba a gépet (leszámítva, hogy már a registrykulcsot nem kell módosítsunk előtte). A tartományi rendszergazda neve: administrator, a jelszava pedig az, amit megadtunk a tartomány létrehozásakor.
100
Fájl szertver feladata, telepítése, üzemeltetése
Rsat letöltése, telepítése
Első dolgunk a beléptetés után, hogy letöltsük a Windows Remote Server Administration Tools programot.
Windows 7-re: http://www.microsoft.com/hu-hu/download/details.aspx?id=7887
Windows 8-ra: http://www.microsoft.com/hu-hu/download/details.aspx?id=28972
Akit pedig eltérő verziók érdekelnek, itt nézhet utána: https://wiki.samba.org/index.php/Samba_AD_management_from_windows
Miután telepítettük, látszólag nincsenek új programok a gépen, ugyanis előtte még a Vezérlőpult > Programok > Programok és szolgáltatások alatt a Windows-szolgáltatások be- és kikapcsolása pontban engedélyezni kell a távoli kiszolgálófelügyeletet. Ezek után a Felügyeleti eszközök alá be-kerül sok újabb lehetőség, amikkel az AD-t tudjuk elérni, vagy egyszerűen futtassuk:
dsa.msc
Ennek hatására elindul az AD felügyeletét ellátó segédprogram (Actitve Directory – felhasználókés számítógépek):
A program használata egyszerű, gyakorlatilag kattintgatással összeállítható a kívánt konfiguráció.Javasolt először létrehozni a csoportokat, azaz tanár, diak, adminisztracio, miként azt a fenti ábra ismutatja (a jobb egér gomb hatására előugró helyi menüből tudunk választani).
101
Fájl szertver feladata, telepítése, üzemeltetése
Megosztások jogai
Következő lépésként érdemes a megosztások megfelelő jogait beállítani. Erre legjobb elindítani azintézőt, majd az UNC szintaxisnak megfelelően a beviteli sorba beírni a szerver nevét. Jelen eset-ben így: \\szerver4.
Majd jobb egérgombbal kattintsunk a kívánt mappán, és a biztonság fülön kattintsunk a speciálisgombra. Valahogy így:
...majd a megosztot könytvtáraink számára állítsuk be a kítvánt jogokat!
Home és Profiles mappák jogai
A home és a profiles mappák számára a következő jogokat állítsuk be:
Profiles mappa:
– administaror (teljes hozzáférés, ez a mappa, almappa és fájljai)
– domain users (mappa bejárás, fájl tvégrehajtás, mappa listázása, adatok oltvasása, mappák lét-rehozása, adathozzáfűzés, csak ez a könytvtár)
– létrehozó tulajdonos (teljes hozzáférés, alkönytvtár és a fájljai
Ennek a példáját látjuk a fent bemutatott képen is.
Home mappa:
102
Fájl szertver feladata, telepítése, üzemeltetése
– administrator (teljes hozzáférés)
– system (teljes hozzáférés)
– hitelesítet felhasználók (teljes hozzáférés – it érdemes a hatókört a csak ez a mappára csökkenteni, így kitallóztva nem tudnak egymás könytvtárába benézegetni a felhasználók)
Home és Profil könyvtárak beállítása
Ismét indítsuk el a dsa.msc-t, és miután kiválasztottuk a felhasználót, kattintsunk a tulajdonsá-gokra, majd a profil fülre. Válasszuk ki, mely meghajtóhoz rendelje hozzá a home könyvtárat, majda csatlakoztatott mappához írjuk be az útvonalat \\szerverneve\home\felhasználói név formában.Az OK gombra kattintva elkészíti az adott felhasználó könyvtárát.
Következő lépés a Profil beállítása, amit szintén itt tudunk megtenni a Profil elérési útjához beírt\\szerverneve\Profiles\felhasználói név formában.
Nyomtatás beállítása
Következő lépésként a nyomtatókonfiguráció van hátra, ahol most maradunk a kliens oldalról tör-ténő meghajtótelepítésnél. Aki ennél többre vágyik, az itt talál információkat az automatikus meg-hajtótelepítésről: https://wiki.samba.org/index.php/Samba_as_a_print_server#General
Nekünk csak egy dolgunk van, a hálózati nyomtató használatának korlátozása az adminisztraciocsoportra, hogy rajtuk kívül más ne tudjon nyomtatni rá. Feltételezzük, hogy a CUPS-ban a meg-osztás nevével megegyező nevű nyomtató telepítésre került, és megfelelően működik.
– Tartományi rendszergazdaként lépjünk be egy kliensen, majd az intézőben natvigáljunk el a szertverünkhöz az UNC formátumú nétv beírásátval, jelen esetben \\szertver4.
– Katintsunk a tátvoli nyomtatók megtekintése pontra, és katintsunk a nyomtató tulajdonságai-ra.
103
Fájl szertver feladata, telepítése, üzemeltetése
– Válasszuk a megosztást, adjunk netvet a megosztásnak.
– A biztonság fülön jelöljük be, mely csoportok és felhasználók érhetik el a nyomtatót.
Logon szkriptek
Az utolsó lépés, hogy miként lehet a Samba 4 alatt a logon szkriptjeinket futtatni. Ami azonos, hogy a netlogon megosztásban kell őket elhelyezni, és ügyelni kell rá, hogy legyen olvasás és futta-tás jog rajta a hitelesített felhasználóknak.
Két módon tudjuk elérni, hogy lefusson egy logon szkript.
– Az egyik esetben a már ismerős Actitve Directory – felhasználók és számítógépek elindításátval, az adot felhasználóknál a profl fülön kell beírni a logon szkript netvét. Figyeljünk rá, hogy amíg a home és profles-nél a teljes UNC úttvonalat meg kellet adni, addig it csak a tényleges fájlnetvet kell és szabad, egyéb esetben nem fog lefutni! (pl. diak.bat)
– A másik lehetőség egy globális megoldás, ehhez az RSAT részeként települő csoportházirend kezelése eszköz, melyet tvagy kibogarászunk a Start menüből, tvagy írjuk be:
gpmc.msc
A feljövő ablakban válaszuk a tartományunkat, majd a jobb egér gombbal való kattintás után vá-lasszuk a csoportházirend objektum létrehozását. Adjunk neki nevet (mondjunk szkriptjeink),majd rajta jobb egérrel válasszuk a szerkesztés pontot. Menjünk a felhasználó konfigurációja pon-ton belül a házirendek → Windows beállításaiba, majd ott a parancsfájlok (bejelentkezés/kije-lentkezés) részre, és a jobb oldalon válasszuk a bejelentkezést. A hozzáadás gombbal tudjuk
104
Fájl szertver feladata, telepítése, üzemeltetése
hozzáadni a kívánt szkriptet a házirendhez. A végén a házirendbejegyzésünkön jobb egérrel kattint-va válasszuk az „érvénybe léptetve” pontot.
Ezzel gyakorlatilag el is készültünk, használatra kész a rendszerünk, amely nemcsak tudja azt amit a Samba 3 tudott, de jócskán van még benne lehetőség.
A teljes Samba 4 konfigurációs állományt azért a végére beszúrjuk:
[global]workgroup = LOKrealm = lok.localnetbios name = SZERVER4sertver role = actitve directory domain controllerdns forwarder = 8.8.4.4interfaces = eth1 lobind interfaces only = yes
[netlogon]path = /tvar/lib/samba/systvol/lok.local/scriptsread only = No
[systvol]path = /tvar/lib/samba/systvolread only = No
[home] path = /home/samba/home/read only = No
105
Fájl szertver feladata, telepítése, üzemeltetése
[Profles] path = /home/samba/Profles/writable = yes
[publikalas]path = /home/samba/publikalascomment = tanarok szamara publikalasrabrowseable = yeswritable = yes
[adminiszt]path = /home/samba/adminisztraciocomment = adminisztratitv dolgozoknak, zartbrowseable = yeswritable = yes
[adminiszt2]path = /home/samba/adminisztrac2comment = adminisztratitv dolgozoknak, nyiltbrowseable = yeswritable = yes
[hr]path = /home/samba/hrcomment = hr-es dolgozoknakbrowseable = yeswritable = yes
[rendszerg]path = /home/samba/rendszergazdacomment = rendszergazdai publikaciokbrowseable = yeswritable = yes
[Deskjet_3510]comment = Kozpotni nyomtato adminisztratitv dolgozoknak igazgatasi csoportpath = /tvar/spool/samba/printer name = Deskjet_3510printable = yes
106
Hálózati nyomtatás, szkenner szertver
Hálózati nyomtatás, szkenner szerver
Nyomtatás LinuxonLinuxon használt nyomtatási rendszer
Linuxon régebben az LPD139 nyomtatási rendszereket használtuk, de az elmúlt étvek alat fokoza-tosan kiszorítota azt a CUPS140 (Common Unix Printing System), amely rengeteg modern nyomta-tó használatát teszi lehetőtvé. Szabtványos IPP141 protokollt használ, támogatja a PostScriptnyomtatóleírást (PPD142), ráadásul egy könnyen használható webes felületű adminisztrációs rend-szert is biztosít.
A nyomtatási rendszer mellet érdemes még megemlíteni a nyomtatómeghajtókat is, melyek kö-zül a legismertebbek a gutenprint143 csomag, amely jelenleg 700 nyomtatót támogat, illettve a foo-matic144. It kell még megismerkednünk a Ghostscript145 csomaggal is, mely arra képes, hogy azalkalmazások által küldöt PostScript formátumú adatokat fordítsa le a PostScriptet nem ismerőnyomtató számára értelmezhető adatfolyammá, ezt használja például a foomatic is. (Ebből sejthe-tő, az a legegyszerűbb, ha tvalódi PostScript-képes nyomtatót tudunk használni, sajnos ezt azonbana pénztárcánk gyakran megakadályozza…) Talán ez kissé zatvaros most – ami őszintén elismertvenem csoda –, de ebből a lényeg, hogy ha nyomtatni is szeretnénk, akkor a nyomtatási rendszeren(CUPS) kítvül érdemes ezeket is feltelepítenünk, amennyiben az általunk használt Linux rendszernem tete tvolna ezt meg automatikusan a CUPS telepítésekor.
Amennyiben még nem kapkodtuk tvolna a fejünket, akkor jöjjön it be még pár szereplő! A HP-LIP146 (Hewlet-Packard's Linux Imaging and Printing), amely kimondotan a HP eszközök támo-gatására készült, nem csak nyomtatókat, de szkenner- és FAX-támogatást is tartalmaz, ésszerencsére GPL licenc alat érhető el. Jelenleg 2295 eszközt támogat, és a CUPS-ot, mint hátér -programot használja.147 Pár nyomtatót pedig az SpliX148 segítségétvel tudunk használni, amely SPL-en alapul (SamsungPrinter Language).
A fentiek fényében sejthető, hogy elég sok nyomtatót tudunk Linux alat használni, de azért ér-demes beszerzés előt tájékozódni.
1139. htp://en.wikipedia.org/wiki/Line_Printer_Daemon_protocol1140. htp://www.cups.org/1141. htp://en.wikipedia.org/wiki/Internet_Printing_Protocol1142. htp://en.wikipedia.org/wiki/PostScript_Printer_Description1143. htp://gimp-print.sourceforge.net/1144. htp://en.wikipedia.org/wiki/Foomatic1145. htp://www.ghostscript.com/Ghostscript.html1146. htp://hplipopensource.com/hplip-web/index.html1147. htp://hplip.sourceforge.net/images/hplip_architecture.png1148. htp://splix.ap2c.org/
107
Hálózati nyomtatás, szkenner szertver
Nyomtató kiválasztásaAmennyiben újonnan kerül a nyomtató beszerzésre, mindenképp győződjünk meg arról, hogy
használható-e az eszköz Linuxon.
Az egyik legismertebb oldal, ahol utána tudunk nézni, hogy mely nyomtató Linux-kompatibilis,az a kötvetkező openprinting oldal: htp://www.openprinting.org/printers
It gyártó és típus szerint tudunk keresni, azonban a legújabb nyomtatók közül meglehetősensok hiányzik. Ez azonban nem jelenti feltétlen azt, hogy azok nem működnek Linuxon. Csak más-hol is körül kell néznünk…
Szerencsére egyre több gyártó ismerte fel, hogy mennyire fontos az általa gyártot eszközök Li-nux-támogatása, így egyre több nyomtatót tudunk használni, azonban ennek a gyártó oldalán kellutánanéznünk.
Sok nyomtató, csak a gyártói oldalról (tvagy máshonnan) leszedet PPD fájllal használható; tvagypéldául a HPLIP legújabb tverziója kellhet sok korszerű nyomtatóhoz, ami esetleg ismét csak agyártói oldalról tölthető le, mert az általunk használt disztribúció csak egy régebbi tverziót tartal-maz, amitvel a nyomtató nem működik. Azt hiszem, sikerült eléggé hangsúlyozni mennyire fontosaz előzetes tájékozódás.
A gyártói oldalakról letöltöt nyomtatómeghajtók szerencsére könnyen telepíthetőek, általábanminden függőséget letöltenek maguknak, és gyakran még grafkus telepítőfelületel is rendelkez-nek (tapasztalatból jatvasolt azonban a gyártói megoldások telepítése előtt a CUPS telepítése).
Maga a telepítés egyszerűbb, mint a fentiek alapján sejteni lehetne…
CUPS telepítéseA telepítéshez használt rendszer a jelenlegi stabil Debian Linux, a Wheezy.149 A telepítéshez az
apt-t használjuk:
apt-get install cups
Vegyük észre, hogy ezzel nem csak a CUPS szertvert telepítetük, de sok más csomag mellet fel-került függőségként a printer-dritver-gutenprint, a foomatic-flters, a ghostscript-cups és a hplip is.Csupa korábbról ismerős kifejezés…
Ezek után már el is indult a gépünkön a CUPS. A
ps ax
parancs kiadása után a kötvetkezőhöz hasonló eredményt láthatunk:
/usr/sbin/cupsd -C /etc/cups/cupsd.conf
Rögtön észretvehetjük, hogy konfgurálni majd az /etc/cups/cuspd.conf fájlban tudjuk, illettve hakiadjuk a
netstat -lnp
parancsot, akkor látható, hogy jelen pillanatban a localhoston tválaszol a 631-es porton:
127.0.0.1:631 0.0.0.0:* LISTEN 5890/cupsd
1149. htps://wiki.debian.org/DebianWheezy
108
Hálózati nyomtatás, szkenner szertver
CUPS alap konfigurálásaGyakorlatilag a legegyszerűbb megoldás az, ha azon a gépen, amire telepítetük a CUPS-ot, tvan
grafkus felület és egy böngésző, mitvel a böngésző címsorába beírtva a https://127.0.0.1:631 címet betöltődik a CUPS webes adminisztrációs felülete.
Szertvereknél gyakori, hogy nincs telepíttve grafkus felület, ilyenkor engednünk kell, hogy máshelyekről is hozzá lehessen férni a webes felülethez. Ehhez először engedélyeznünk kell, hogy alocalhost-tól eltérő interfészen is lehessen kapcsolódni a CUPS-hoz, utána pedig a hozzáférési sza-bályoknál kell megadjuk, hogy mely helyekről lehet kapcsolódni a szertverhez.
Mindegyiket az /etc/cups/cupsd.conf szerkesztésétvel tudjuk megtenni.
Keressük meg a Listen sort, majd bőtvítsük:
Listen localhost:631Listen 10.0.0.1:631
Eredetileg csak a localhost sor szerepelt a konfgurációs állományban, ez után szúrtuk be a kö-tvetkező „Listen” sort, ahol megadtuk annak a csatolókártyának az IP címét, amelyen szeretnénk,hogy működjön. Ez jelenleg a teszt gépünk belső hálózat felé néző csatolókártyája.
Azonban ha ekkor elnatvigálnánk a böngészőtvel a szertver címére (htp://10.0.0.1:631), egy tvisz-szautasító üzenet tvárna minket, ugyanis engedni kell, hogy lehessen csatlakozni a szerverhez, azadminisztrációs felülethez és a konfgurációs állományhoz ::::
# Restrict access to the server...<Location /> Order allow,deny Allow from 10.*.*.*</Location>
# Restrict access to the admin pages...<Location /admin> Order allow,deny Allow from 10.*.*.*</Location>
# Restrict access to configuration files...<Location /admin/conf> AuthType Default Require user @SYSTEM Order allow,deny Allow from 10.*.*.*</Location>
A fenti három bejegyzés tvonatkozik sorban a szertver, az adminisztrációs felület és a konfguráci-ós állomány elérésére. Mi az „Allow from 10.*.*.*„ sort szúrtuk be, amitvel azt érjük el, hogy a tel-jes 10.0.0.0 hálózatból elérhetővé vált mindhárom szempont alapján. Megadható lenne példáulAllow from all, azaz mindenhonnan; tvagy Allow from 10.0.0.5, azaz csak a 10.0.0.5-ös gépről; tvagy*domain tvagy gépnétv.domain formákban is.
Ezek után már csak arra tvan szükség, hogy újraindítsuk a CUPS-ot:
/etc/init.d/cups restart
109
Hálózati nyomtatás, szkenner szertver
Etől a pontól máris tudjuk a belső hálózatunk bármely gépéről egy böngészőn keresztül admi-nisztrálni a CUPS szertvert, és persze a nyomtatókat.
CUPS webes felületeA böngészőnkbe írjuk be a CUPS szertver címét, amely jelen példában a htps://10.0.0.1:631, majd
fogadjuk el a tanúsíttványt, és máris elénk tárul a webes adminisztrációs felület.
Az adminisztráció felületen csak hitelesítés után tudunk bármit csinálni. Jelenleg egyedül a root felhasználónak van joga mindenhez, így a root nevét és jelszavát kell beírni a párbeszédablakba.
Nyomtatóadminisztrátor felhasználó beállításaAmennyiben szerencsénk tvan, és tvan kijelölt tvagy esetleg önként tvállalkozó, aki egyéb elfoglalt-
ságaink miat magára tvállalja az elakadt, rossz nyomtatások törlését, nyomtatók újraindítását stb.,tvagy mi szeretnénk inkább a saját felhasználói netvünket használni root helyet a CUPS webesadminisztrációjakor, akkor csak annyi a teendőnk, hogy a kítvánt felhasználót az lpadmin csoporttagjátvá kell tenni.
usermod -a -G lpadmin muszashi
A fenti konzolon kiadot paranccsal a muszashi netvű felhasználó mostantól tudja adminisztrálni a nyomtatókat.
110
Hálózati nyomtatás, szkenner szertver
Nyomtatók hozzáadásaMielőt bármit is tennénk, ellenőrizzük, hogy a nyomtató egyáltalán elérhető-e! Főként hálózati
nyomtatók telepítésekor fordul elő, hogy tvalami tritviális hiba miat a nyomtató nem is elérhető ahálózaton, így mielőt időt áldoznánk a hibakeresésre, a ping paranccsal nézzük meg, hogy anyomtató fzikailag elérhető-e a hálózaton (USB nyomtató esetén az lsusb paranccsal).
A telepítés it kétféleképpen történhet
– Amennyiben gyártóoldali telepítőprogramot használunk, úgy kötvessük a gyártó és a program utasításait. Ha minden jól megy, a telepítés tvégén látni fogjuk a nyomtatót a CUPS adminiszt-rációs felületén a telepítet nyomtatók közöt, és ugyanúgy tudjuk kezelni, mintha mi telepítet-tük tvolna.
– Amennyiben a nyomtató támogatot a rendszerünkön, akkor az adminisztrációs felület Nyom-tató hozzáadása alat tudjuk feltvenni a nyomtatót, 4 egyszerű lépésben:
– Válasszuk ki a nyomtató kapcsolódási pontját, majd katintsunk a folytatásra!
– Adjuk meg a nyomtató leírását és netvét! Amennyiben a nyomtatót szeretnénk megosztani, ér-demes a netvet átírni az alapértelmezeten jatvasolt nétvnél rötvidebbre, hogy könnyebb legyen arra hitvatkozni, és csökkentsük a hibalehetőséget.
111
Hálózati nyomtatás, szkenner szertver
– Válasszuk ki a nyomtatómeghajtót:::!Ezzel el is érkeztünk a kritikus kérdéshez, hogy melyik meghajtót tválasszuk. Amennyiben több lehetőségünk is tvan, akkor először tválasszuk az ajánlotat (recommended), de ha az nem mű-ködne, tvagy nem hozná a kítvánt eredményt, akkor a nyomtatót majd tudjuk módosítani, és másik meghajtót tválasztani. A különböző nyomtatóknál eltérő, hogy épp melyik meghajtó hoz jobb eredményt. A nyomtatás beállításának pont az a leglényegesebb része, hogy az adot nyomtatóhoz tvaló meghajtók mennyire felelnek meg. Szerencsére az utóbbi étvekben a gyártói (proprietary) meghajtók sokat jatvultak, az esetek nagy részében megfelelően, tán jobban is működnek, mint a foomatic/gutenprint meghajtók, így talán érdemes először azokkal próbát tenni.Van egy speciális „meghajtó” is, ez pedig a RAW. Ez gyakorlatilag semmit nem csinál, csak a beérkező adatfolyamot tváltoztatás nélkül totvábbküldi a nyomtatóra. Gyakran használjuk példá-ul akkor, ha Samban osztjuk meg a nyomtatót: ekkor ugyanis a Windows kliens oldalon feltele-pítjük az adot nyomtató meghajtóprogramját, így már eletve olyan adatfolyam érkezik, amelyeta nyomtató értelmezni tud, így azt egyszerűen módosítás nélkül kell totvábbküldenünk, no erre tvaló a RAW.Amennyiben a nyomtatóhoz PPD fájlt szereztünk, akkor azt it tudjuk feltölteni a szertverre.
112
Hálózati nyomtatás, szkenner szertver
– Állítsuk be a nyomtató alapértelmezéseit!
Amennyiben a negyedik lépésnél az állapot helyén hibaüzenet fogad, akkor
– tvagy nem érhető el a nyomtató
– tvagy telepítés után szüneteltetésre került (előfordul), engedélyezzük a folytatást a karbantartás pontban, és „megjatvul”
– indítsuk újra a CUPS szertvert
– próbálkozzunk másik meghajtótval
– Most már látjuk a telepítet nyomtatót a nyomtatók közöt. Készen is tvagyunk.Nyomtatót módosítani, adminisztrálni bármikor tudunk, amennyiben a nyomtatóra katintunk,
tvagy az adminisztráció pontban kitválasztjuk.
Amennyiben a nyomtató nem helyben, hanem hálózaton keresztül kapcsolódik, ugyanígy já-runk el, csak az első oldalon a nyomtatónak megfelelő kapcsolódási formát kell tválasztani, és megfelelő adatokkal kitölteni. Erre látható példa az alábbi nyomtató esetén:
113
Hálózati nyomtatás, szkenner szertver
Nyomtatók megosztása a hálózatonA nyomtató megosztásánál érdemes eldönteni, mit is szeretnénk pontosan. Ha cél, hogy csak bi -
zonyos felhasználók, csoportok tudjanak nyomtatni bizonyos nyomtatókra, és tvan mondjuk egySamba fájlszertverünk, akkor érdemes a nyomtatót azon keresztül elérhetőtvé tenni a kliensek szá-mára. Ez a legegyszerűbb út, és a leginkább fnomhangolható. Erről ezen kiadtvány Sambátval kap-csolatos részében lehet oltvasni.
Amennyiben csak egyszerűen azt szeretnénk, hogy a hálózatunk bármely tagja nyomtathasson anyomtatókra, akkor legegyszerűbb rögtön CUPS-on keresztül megosztani a nyomtatókat. (Termé-szetesen az elején említet módon szabályozhatjuk, a hálózat mely gépeiről, alhálózatokról érhetőel a CUPS, illettve felhasználók alapján is lehet szabályozni az elérést, de akkor inkább Sambán ke -resztül érdemes megosztani)
A megosztáshoz a webes felületen, jelöljük be a „rendszerhez csatlakozó nyomtatók megosztása” négyzetet, illettve az adot nyomtatóknál engedélyezzük a megosztást. Innentől kezdtve a kliensek elérhetik a nyomtatót, nyomtatókat.
114
Hálózati nyomtatás, szkenner szertver
Linux kliensekLinux kliens esetén gyakorlatilag semmi teendő nincs, szinte tvalamennyi grafkus nyomtatóke-
zelő programban automatikusan megjelenik a megosztot nyomtató, tvagy oda 1-2 katintássalkönnyedén feltvehető. (Amennyiben nem jelenne meg, ellenőrizzük, hogy a kliensen telepítve van-e aCUPS, illetve a htp://127.0.0.1 :631 címen elérhető a kliensen lévő CUPS, ahol az Adminisztráció >Kiszolgáló > Speciális pont alat engedélyezhetjük, hogy más szerveren megosztot nyomtatók is meg-jelenjenek a mi CUPS szerverünkön – lásd előző ábra.)
Legtöbbször semmi teendőnk nincs, automatikusan megjelenik:
Windows kliensekWindows kliensen is könnyen elérhetőtvé tehetjük a megosztot nyomtatóinkat a nyomtató hoz-
záadása ponton keresztül. Válasszuk a hálózati nyomtató hozzáadását és ot pedig a „Megosztotnyomtató kitválasztása nétv szerint pontot”. Elérkeztünk oda, ahol nem szabad kötvetni a nyomtatóeléréséhez az ablakban látható megadot mintát, ugyanis a htp://szamitogepnev/Printers/ nyom-tatonev/.printer minta nem működik!
Helyete adjuk meg a http://cups szerver neve vagy IP címe:631/printers/nyomtatónév formában,ahogy az alábbi képen is látható:
115
Hálózati nyomtatás, szkenner szertver
Ezek után a telepítés lezajlik és a nyomtató használható.
Egyéb CUPS ötletekAmennyiben szükséges, hogy a nyomtatásokat nyiltvántartsuk, akkor a webes felületen kényel-
mesen megnézhetjük minden korábbi nyomtatási munkának a bejegyzését. Néha kítvánatos, hogykimutatást tvagy egyéb jelentést készítsünk a nyomtatásokról, ilyenkor tviszont hasznosabb, haezek az adatok fájlban is megtalálhatóak. Ez a fájl létezik: a /tvar/log/cups/page_log netvezetű nap-lófájlban láthatjuk a nyomtatások naplózását. (Szintén it található a szertvert és a hozzáférést nap-lózó állomány is. {error_log és access_log}, probléma esetén ezekben keresgéljünk.)
Lehetőség tvan arra is, hogy ne webes felületen, hanem parancssorban konfguráljunk nyomta-tókat, illettve kezeljük a nyomtatásokat.
Lekérdezni a jelen példában szereplő nyomtató állapotát így lehet:
lpstat -p lj1120
116
Hálózati nyomtatás, szkenner szertver
A CUPS parancssori eszközeiről it lehet részletesebben oltvasni : htp://www.cups.org/documentation.php/options.html
Szkennelés LinuxonLinux rendszereken a szkenner használatát a SANE150 (Scanner Access Now Easy) segítségétvel
tudjuk megtvalósítani, amelynek célja az egységes hozzáférés biztosítása minden képoltvasó hard-tverhez. Igen, a SANE nem csak szkennerrel, hanem például kamerákkal is együtműködhet, itmost azonban csak a szkennerről lesz szó.
Szkenner támogatottságaMielőt eszközbeszerzésbe kezdenénk, ugyan azt kell tegyük, mint a korábbi oldalakon a nyom-
tatókkal kapcsolatban oltvasható tvolt már. Meg kell nézni, támogatja-e az eszközt a SANE jelenlegioperációs rendszerünkön található tverziója, esetleg a SANE oldaláról letölthető újabb tverzió, tvagypedig az eszköz gyártójának oldaláról letölthető-e egy Linuxos telepítőprogram. Beszerzésünketennek fgyelemtvételétvel tegyük meg.
A SANE adatbázisa a támogatot eszközökről : htp://www.sane-project.org/sane-mfgs.html
Jelen pillanatban 2036 eszközt ismer, melyből 1087 kapot teljes tvagy jó minősítést. Amelyik esz-köz ezeknél gyengébb minősítésű, annak a használata igencsak kétséges. A fenti adatbázison túlújabb eszközök használatakor ismét érdemes a gyártói weboldalakat is felkeresni, mitvel például anyomtatásnál már említet HPLIP is rengeteg képoltvasó eszköz (szkenner, multifunkciós eszköz)használatát teszi lehetőtvé.
TelepítésA SANE tulajdonképpen hátér- (backend) és előtér- (frontend) programokból áll, amelyek ko-
rábban a jól elkülönült sane-backend (tulajdonképp a szkenner elérését teszi lehetőtvé) és sane-frontend (a szkenner tényleges használatához szükséges) netveken tvoltak telepíthetőek, máraazonban már az általunk használd Debian Wheezy rendszeren is csak egyszerűen sane nétven hi-tvatkozhatunk rá.
apt-get install sane
A fenti paranccsal telepíthetjük a sane csomagot. A szükséges függőségeket hozza magátval.(Amennyiben szkennerünk igényli, ellenőrizzük, hogy a libsane-extras és a hplip telepítésre ke-rült-e. Ha nem, pótoljuk!)
KonfigurációAmennyiben a szkennerünk tvalóban támogatot, akkor az most már le is kérdezhető. Ehhez csak
a kötvetkező utasításra tvan szükség:
scanimage -L
Kilistázza az észlelt képolvasó eszközöket. Amennyiben nincs képolvasó eszköz kilistázva, akkor vagy nem támogatott az eszköz, vagy egyéb probléma van vele. Jelen példánkban ezt kaptuk a pa-rancs kimeneteként:
1150. htp://www.sane-project.org/
117
Hálózati nyomtatás, szkenner szertver
device `hpljm1005:libusb:001:005' is a Hewlett-Packard LaserJet M1120 multi-function peripheral
Szkenner használata
ParancssorbólTulajdonképpen a szkenner már használható, a működését le is tudjuk ellenőrizni a már előzőleg
megismert scanimage parancssoros eszközzel, amely lehetővé teszi a szkennelést terminálból.
scanimage --mode Color --format tiff -p -d hpljm1005:libusb:001:005 >teszt.tiff
Azaz készít egy színes képet tiff formátumban a megadott eszközzel, és a beolvasott képet teszt.-tiff néven tárolja. A -p hatására pedig lesz egy állapotjelzőnk is, amin nyomon tudjuk követni a szkennelés előrehaladását. Amennyiben a szkennelés rendben lezajlott az eszköz működőnek te-kinthető, lehet próbálkozni a grafikus eszközökkel.
Grafikus felületen
A SANE telepítésével rögtön kaptunk egy grafikus előtétprogramot is az xscanimage nevezetűt. Ezt elindíthatjuk, illetve a szkennert kezelő programok (pl. GIMP) már meg is hívják ezt az eszközt,ha a szkennert választjuk adatforrásnak. Nagyon egyszerű kis program, csak az alapvető funkciókat tudja.
1. Ábra: xscanimage
Az xsanimage programnál vannak lényegesen nagyobb tudású eszközök is, ilyen például az xsa-ne, amely amellett hogy sokkal több lehetőséggel rendelkezik, okozott már pozitív meglepetést, amikor a nem épp tökéletes eszközmeghajtó az xscanimage programmal hibásan működött, míg a xsane-vel kompromisszumok árán, de lehetett használni...
118
Hálózati nyomtatás, szkenner szertver
apt-get install xsane
A fenti paranccsal telepíthető az xsane.
2. Ábra: xsane
Látható, hogy az xsane sokkal több funkcióval rendelkezik.
Hálózati lapolvasás
Telepítés
A sane-utils csomag lehetővé teszi, hogy a gépünkhöz csatlakoztatott szkenner a hálózat többi gé-péről is elérhető legyen. Amennyiben eddig nem telepítettük fel, azt tegyük meg most az alábbi pa-rancs begépelésével:
apt-get install sane-utils
A sane utils által szállított saned151 fogja elérhetővé tenni a szkennerünket, azonban ehhez még te-lepítenünk kell a xinetd152 csomagot is (Internet superserver).
apt-get install xinetd
Most, hogy már telepítettük a sane démont és xinet démont is, csak konfigurálnunk szükséges a rendszert.
1151. htp://penguin-breeder.org/sane/saned/1152. htp://en.wikipedia.org/wiki/Xinetd
119
Hálózati nyomtatás, szkenner szertver
Konfiguráció
– Kezdjük a /etc/default/saned fájllal. Itt módosítsuk a RUN=yes sorra a korábbi RUN=none sort, ezzel elérjük, hogy elindulhasson a saned.
# Set to yes to start sanedRUN=yes
– Folytatásképp keressük meg az /etc/sane.d/saned.conf fájlt, és egyszerűen írjuk bele a hálózatunkvagy azon gépek címét vagy nevét, amely irányba elérhetővé szeretnénk tenni a szkennert.
# The hostname matching is not case-sensitive.10.0.0.0/8
A fenti beállításokkal tulajdonképp a saned konfigurációja véget ért, már csak a xinetd van hátra.
– Létre kell hoznunk egy állományt az /etc/xinetd.d/ könyvtárban, amelynek tetszőleges nevet adhatunk, de célszerű mondjuk saned-nek elnevezni (pl. touch /etc/xinetd.d/saned), majd ebbe azalább látható tartalmat elkészíteni (pl pico /etc/xinetd.d/saned):
service saned {socket_type = streamserver = /usr/sbin/sanedprotocol = tcpuser = sanedgroup = scannerwait = nodisable = no}
Gyakorlatilag a fentiek megadásával adtuk a xinetd tudtára, hogy mit és hogyan kell elindí-tania, ha kérés érkezik hozzá.
A konfigurálás elkészült, indítsuk újra a xinet démont:
/etc/init.d/xinetd restart
Kliens oldali lehetőségek
Linux kliens
Linuxos kliensen rögtön van lehetőségünk tesztelésre (természetesen ehhez a sane csomagnak te-lepítve kell lennie a kliens gépen is), adjuk ki ismét:
scanimage -L
A kiszolgálótól eltérően immár hálózati címmel látjuk a korábban telepített szkennert:
device `net:10.0.0.1:hpljm1005:libusb:001:009' is a Hewlett-Packard LaserJet M1120 multi-function peripheral
A fenti sort látva biztosak lehetünk, hogy elérjük a hálózati lapolvasót.
Ezek után a szokásos grafikus felületű eszközök közül válogathatunk, ugyan úgy fognak működni mintha helyi eszközzel dolgoznának.
120
Hálózati nyomtatás, szkenner szertver
A korábbi képhez képest csak annyiban különbözik ez, ami a hálózati kliensen készült, hogy lát-ható az xscanimage címsorában, hogy valójában egy hálózati eszközzel dolgozik (net 10.0.0.1).
Windows kliens
Windowsos kliens esetén első lehetőségként arra gondolunk, hogy az xsane rendelkezik win32-esbinárisokkal is, így akár használhatnánk azt is, de a weboldalának tanúsága szerint ezt évek óta nemfejlesztik, nem tanácsos a használata.
Helyette a sanetwain programot érdemes használni, mely elérhető az alábbi címről:
http://sanetwain.ozuzo.net/
A program letöltése és telepítése rendkívül egyszerű: amennyiben minden beállítás rendben van,azonnal működik. (Amennyiben elrontottunk valamit a kiszolgálói oldalon, vagy a kliensen hibáz-tunk a beállításokkal és a szkennert nem éri el, akkor a legváltozatosabb hibaüzeneteket produkálja,ilyenkor csak a feladatkezelőből történő kilövése segít.)
A telepítő innen érhető el: http://sanetwain.ozuzo.net/#download
121
Hálózati nyomtatás, szkenner szertver
122
3. Ábra: Sanetwain működés közben, magyar nyelven. Látható a szkenner hálózati elérésének meg-adása.
Adatbázis-kezelés
Adatbázis-kezelésAz általános defníció szerint az adatbázis-kezelő szoftverek olyan speciális alkalmazások, ame-
lyek adatok tárolására és elemzésére használhatók. Az adatbázis-kezelő rendszerek gyakran háló-zatos környezetben többfelhasználós, párhuzamos hozzáférést biztosítanak adatbázisokhoz. Angolmegnetvezésük: DBMS – Database Management System.
Történeti áttekintésMár a 20. század legelején mutatkozot igény a népesség nyiltvántartási adatok kezelése miat
adatbázisba szertvezésre. Valójában azonban csak a 1960-as étvekben alakult ki az a struktúra, amelynek nyomait a ma működő adatbázis-kezelők működési modelljeiben is megtaláljuk. Első-sorban bérszámfejtésre és adatsorok, statisztikák elkészítésére használták a lyukkártyás technoló-giát. A ma használt legnépszerűbb adatbázis-modell működési logikáját 1970-ben Edgar F. Codd153 publikálta az IBM munkatársaként. Az első modern adatbázis-kezelőt is az IBM hozta létre Sys-tem-R nétven (ma DB/2 nétven ismert). Az első nagyszabású adatbázis-kezelő mégis az Oracle154 ne-tvéhez fűződik, amelyet ma is széles körben használnak. Fejlesztésének motitvációi közöt többek közöt a CIA igényei is szerepeltek. A mai SQL alapjait azonban a System-R fejlesztői fekteték le, amelyet SEQUEL nyeltvnek netveztek el. Ma már sok kereskedelmi termék, köztük számos kitváló nyílt forráskódú rendszer is a felhasználók rendelkezésére áll. A legelterjedtebb szabad szoftverek:
– MariaDB155
– MySQL156
– PostgreSQL157
– SQLite158
Rendelkezésre áll még több olyan adatbázis-kezelő is, amely akár bizonyos felhasználószámig, tvagy bizonyos nem kereskedelmi esetekben ingyenesen használhatóak, de mitvel ezek nem szabad szoftverek, és tvagy funkció-, tvagy felhasználószám-korlátozással rendelkeznek, nem szerepelnek ebben a felsorolásban. Egy napjainkban üzemeltetet átlagos LAMP (mely a Linux, Apache, Maria-DB és PHP stack közös rötvidítése) szertveren biztosan telepíttve tvan egy adatbázis-szertver, hiszen nem csak a modern CMS, CRM és egyéb webes technológiák kötvetelik meg a DB meglétét, hanemnagy felhasználó szám esetén az FTP, MAIL és egyéb felhasználói proflokat, jelszatvakat is célsze-rű adatbázisban tartani.
Speciális igények, például nagy számú hálózati hozzáférés ideiglenes adatainak tárolása, tvagy rendkítvül nagy mennyiségű adat (big data) gyors, párhuzamos feldolgozása speciális adatároló- és kezelő alkalmazásokat hozot létre, amelyek a hagyományos adatbázis-kezelők kiegészítésére, illettve akár kitváltására is használhatók. Az első esetben a meglétvő adatbázis-kezelők gyorsítótára-
1153. http://hu.wikipedia.org/wiki/Edgar_F._Codd1154. http://hu.wikipedia.org/wiki/Oracle_Corporation1155. https://mariadb.org/1156. http://www.mysql.com/about/legal/licensing/index.html1157. http://www.postgresql.org/1158. http://www.sqlite.org/copyright.html
123
Adatbázis-kezelés
zó képességeinek teljesítményét is meghaladtva tömörebb, csak memóriában történő tárolást, és ezzel több felhasználó egyidejű kiszolgálását teszik lehetőtvé olyan gyors kulcs-érték kezelők, minta népszerű nyílt forráskódú memcached tvagy Redis. A második speciális esetben a noSQL adatbá-zis-kezelők és a kapcsolódó map-reduce feldolgozó-rendszerek, mint például a szintén nyílt for-ráskódú MongoDB és a hozzá kapcsolható Hadoop jöhetnek számításba.
MySQLA MySQL159 jelenleg az egyik leginkább ismert és elterjedt adatbázis-motor, amelynek közösségi
tváltozata (MySQL Community Edition) szabad szoftver. A jogtulajdonos Oracle nagytvállalati rész-re elérhetőtvé teszi zárt forráskóddal, klasszikus licenc tvásárlási konstrukcióban a közösségi tválto-zat kibőtvítet funkcionalitású tvariánsát. Feltehetőleg ez a fő oka, hogy a közösség a nyílt licenc alat hozzáférhető tváltozat alapjain elkezdte fejleszteni a MariaDB netvű adatbázis kezelőt, mely a jelenlegi trendek szerint tempósan elkezdte áttvenni a MySQL helyét a szabad operációs rendszer terjesztésekben és számos felhasználónál. De erről majd a kötvetkező fejezetben.
A MySQL fejlesztését a stvéd MySQL AB kezdte meg ketős licencelés alat. Lehetősége tvolt a fel-használóknak GPL szabad szoftver licenc160 alati üzleti felhasználásra tvagy zárt (tulajdonosi) li-cenccel egyéb üzleti modell megtvalósítására is. A MySQL-t 2008-ban feltvásárolta a Sun, amelyet két étvtvel később az Oracle tvásárolt fel. Így mára a MySQL fejlesztését az Oracle tvégzi, de az egy-előre nyílt forráskódú maradt. Ez egyrészt kedtvező, mitvel az Oracle egyike az adatbázis-fejlesztő cégek legnagyobbikának, másrészt pedig sok emberben kételyeket ébreszt, hogy az Oracle-nek szüksége tvan-e egy nyílt forráskódú, konkurens termékre. Mitvel azonban a MySQL totvábbra is GPL alat elérhető, így a lehetőség adot egy esetleges kódbezárás utáni a rendszer fejlesztésének szabad folytatására. Jelenleg a legtöbb platform alat futatható (Linux és Unix klónok, illettve Windows és Mac OS X alat is). Üzemeltetési szempontból a kezelése egyszerűen elsajátítható és az elérhető dokumentációk tekintetében is igen tversenyképes. Főbb tverzióit tekinttve hatalmas fej-lődésen ment keresztül az elmúlt étvekben és egyre inkább kezdenek nem kis lekérdező motorként,hanem igen komoly feladatok ellátására alkalmas DB-ként gondolni rá. Adminisztrálását számos eszköz könnyíti, többek közöt tvan általános célra használható parancssoros felülete, ahol gyakor-latilag majdnem mindent könnyen el lehet érni (az adminisztrátorok inkább ezt szeretik és hasz-nálják, mitvel SSH-n keresztül tátvolról is könnyen és biztonságosan kezelhető). A szabad szoftver MySQL GUI Tools a funkciók grafkus elérését teszi lehetőtvé, de ennek fejlesztését az Oracle leál-lítota és a részben szabad MySQL Workbench használatát ajánlják helyete, mindkét eszköz meg-található a fontosabb Linux terjesztésekben, de elérhetők a MySQL honlapjáról is. Sajnos a legtöbbesetben a phpMyAdmin161 felületen keresztül adminisztrálják, amely PHP-alapú, nyílt forrású esz-köz. Jellemzően a rendszer-üzemeltetők (az adatbázis üzemeltetőkkel szemben) nem kedtvelik, mi-tvel a biztonsági hiányosságai és azok befoltozásának gyakorisága és gyorsasága jellemzően problémás, folyamatosan tveszélyezteti az őt futató szertver és az adatbázis biztonságát egyaránt. Ennek ellenére, megfelelő környezetben használtva (SSL mögöt, Htaccess és egyéb szabályok a hozzáférés korlátozására, nem kitalálható URL stb.) ajánlható és remek eszköz a MySQL DB-admi-nok számára. Az adatbázisok mentése tviszonylag egyszerű és a gyári segédprogramokkal jól megoldható, a legtöbb mentő program képes kezelni natítvan, illettve bizonyos esetben lehetőség tvan MySQL Hotcopy-t csinálni az éppen futó adatbázisról. Az alaptelepítés minden esetben egy
1159. http://www.mysql.com/about/legal/licensing/index.html1160. GPL tv2, szerkesztési (linking) kitvétellel, amely még nagyobb teret enged az üzleti célú felhasználásnak.1161. http://www.phpmyadmin.net/
124
Adatbázis-kezelés
általános my.conf állománnyal érkezik, amely fnomhangolása feltétlen szükséges az adot rend-szer tvárható terhelése és a hardtverparaméterek függtvényében. A MySQL számos olyan képesség-gel rendelkezik, ami kiemeli a mezőnyből.162 A MySQL-hez nagytvállalatoknak szánt megoldások iselérhetők, amely segítségétvel magas rendelkezésre állású rendszereket lehet építeni. Ilyen megol-dás például a MySQL Cluster. Működése pont olyan, mint egy teljes klaszteré, azonban csak az adatbázis-motor tvan eloszttva. Kistvállalati környezetben, illetőleg ahol nincs szükség a teljes funk-cionalitás (pl. LAMP) klaszterbe szertvezésére, jó terheléselosztó módszer lehet, illettve az adatok redundáns tárolását lehet tvele megoldani. A funkció beállítása tviszonylag egyszerű, és igazi pré-mium funkcionalitást biztosít. Nagytvállalati környezetben a MySQL mellet szóló értv, hogy mitvel hazánkban is igen elterjedt, sok informatikai tvállalkozás képes támogatást nyújtani hozzá.
Telepítése és beállítása
Mitvel a MySQL minden ismertebb platformra fordítható és természetesen a legnépszerűbb ter-jesztések csomagolt részét képezi, ezért igen egyszerű:
apt-get install mysql-server mysql-client
a függőségek kezelése miat, az apt-get innentől felrakja a szükséges csomagokat. Természetesen, ha PHP alól is el akarjuk majd érni, akkor szükséges a php5-mysql csomag telepítése is, de erről bőtvebben oltvashatunk a WEB fejezetben.
A telepítő tehát letölti a függőségeket és beállítja egy alap működésre a MySQL-t, kérni fogja az installáció tvégén a MySQL root jelszatvát. Ezt érdemes legalább 10 karakteres tvéletlen jelszónak beállítani, amelyet majd a MySQL backup során is fel kell hogy használjunk, így kénytelenek le-szünk a MySQL gépen tárolni, ezért olyan állományba és könytvtárba rakjuk, ahol csak a root fel-használó oltvashatja (igaz nem ez lesz az Achilles-sarka a MySQL rendszerünknek :)
Ezt kötvetően a MySQL készen áll a működésre, azaz csak teljesen alap funkcionalitással. Ha sze-retnénk alapesetben egy kicsit biztonságosabbá tenni, akkor erre egy remek lehetőséget kínál a mysql_secure_installation script. Szintén rootként futattva, interaktítvan tudunk pár igen hasznos opciót tiltani tvagy engedni: tilthatjuk az anonymous felhasználó hozzáférését, a tátvoli root hoz-záférést, törölhetjük tvagy korlátozhatjuk a teszt adatbázishoz tvaló hozzáférést. Ezek azért fontos dolgok, mitvel többnyire egy LAMP környezet gyenge pontja (a PHP-n kítvül) általánosságban az SQL szokot lenni.
A totvábbi konfgurálást a /etc/mysql/my.cnf állományban tudjuk megtenni. A fontosabb opciók:
[mysqld]user = mysql pid-file = /var/run/mysqld/mysqld.pidsocket = /var/run/mysqld/mysqld.sockport = 3306basedir = /usrdatadir = /var/lib/mysqltmpdir = /tmplc_messages_dir = /usr/share/mysqlbind-address = 127.0.0.1
A fenti alap beállítások megtváltoztatására csak indokolt esetben tvan szükség. Ilyen lehet, ha a nem a standard 3306-os porton akarjuk, hogy tválaszoljon, tvagy ha DATADIR-t át akarjuk rakni, pl. lemez I/O tvagy telítetség miat. Fontos megjegyezni, hogy a MySQL nagyon rosszul tolerálja,
1162. http://hu.wikipedia.org/wiki/MySQL
125
Adatbázis-kezelés
ha normál üzem közben elfogy alóla a lemezterület. Ilyenkor a táblák és a DB is sérülhetnek, ezértnagyon fontos jól méretezi a DATADIR területet, tvalamint érdemes folyamatosan egyedi scriptek, tvagy nagios, tvagy munin segítségétvel fgyelemmel kísérni, nehogy kifusson a MySQL a neki fenn-tartot lemezterületből. A bind-address segítségétvel pedig beállíthatjuk, hogy a ne csak a localhos-ton hallgasson DB motor, hanem pl. a külső lábon is. Ehhez ugyan aztán a DB-n belül is engedélyezni kell. Mitvel ez egy jellemző dolog ezért a többi konfguráció előt érdemes tárgyalni. Tehát ha egy tátvoli host részére szeretnénk engedni, hogy egy adot db tvagy akár egy adot db táblájához hozzáférjen, akkor a kötvetkezőket kell tennünk:
a bind-address-t átírjuk a megfelelő IP-címre, pl.
bind-address = 192.168.1.1
majd újraindítjuk a MySQL-t: service mysql restart
Ezek után belépünk a mysql -u root -p parancs segítségétvel. Ha még nem hoztunk létre adatbázist,akkor a legegyszerűbb, ha rögtön úgy hozzuk létre, hogy ahhoz a megfelelő IP-ről hozzá is tudja-nak férni:
mysql> CREATE DATABASE webmotor;mysql> GRANT ALL ON webmotor.* TO webuser@'192.168.1.2' IDENTIFIED BY 'jelszo';mysql>flush privileges;mysql>quit;
jelen esetben tehát a webmotor db-hez a webuser felhasználónak engedtük a 192.168.1.2-ről a hoz-záférést. Ezt később bármikor módosíthatjuk a GRANT parancs segítségétvel. A tátvoli SQL hozzá-férések alapesetben titkosítatlan csatornán utaznak, azaz tökéletesen lehallgathatóak. Éppen ezért,ilyen tátvoli hozzáférést, csak VPN-en belül, tvagy belső hálózaton belül, de mégis leginkább akár ssh port forward, tvagy stunnel163 segítségétvel csináljunk csak! A tátvoli management fejezetben mindkető opció eloltvasható.
A totvábbiakban a MySQL fnomhangolását tvégezhetjük el :
max_connections = 100
alapesetben 100 db párhuzamos csatlakozást enged a szertver felé, természetesen ez akár lehet pár-huzamosan 100 db PHP kód, ami ír tvagy oltvas az SQL-ben. Éppen ezért, nagyon fontos, hogy ezt aparamétert szükség esetén emeljük fel a megfelelő számra. Nagyon gyakori hiba, hogy egy jól mé-retezet tvason a MySQL hatalmas terhelést ad, egyszerűen azért, mert elfogynak a nyitható kap-csolatok és berakja őket egy tvárakozó sorba, ami az Apache+PHP oldalon is fennakadást okoz. Ígyelőbb-utóbb megeszi az erőforrásokat, a memóriát és a CPU-t is. Egy átlagos és jól méretezet LAMP környezetben, átlagos tvasteljesítmény mellet az ideális szám 900.
connect_timeout = 5wait_timeout = 600max_allowed_packet = 16Mthread_cache_size = 128sort_buffer_size = 4Mbulk_insert_buffer_size = 16Mtmp_table_size = 32Mmax_heap_table_size = 32M
Jellemzően a timeout és cache értékek beállításai megfelelőek szoktak lenni egy teljesen alap rendszernek. Megint csak egy megfelelően megtválasztot timeout tvagy cache méretel nagy gyor-sulást lehet elérni, de ugyan akkor egy túl rötvidre tvagy hosszúra tválasztot timeout, szépen le tud-
1163. http://shellboy.com/secure-remote-mysql-connection-using-stunnel.html
126
Adatbázis-kezelés
ja ültetni a rendszert, akár csak a túl kicsi tvagy nagy cache. Ezeket szépen fokozatosan érdemes igazítani az aktuális rendszerhez, a programozókkal együtműködtve. Érdemes folyamatosan moni-torozni egy-egy átállítot paraméter hatását pl. a munin segítségétvel.
slow_query_log_file = /var/log/mysql/mysql-slow.loglong_query_time = 10
a slow query log beállítása egy befektetés a jötvőbe, hiszen utólag it lehet majd tvisszakeresni azo-kat a lekérdezéseket, amelyek tvalamiért akár percekig, tvagy órákig futotak. It megint nagy segít-séget jelenthet a Munin Slow-Qery mrtg diagramja, ahol látható hogy tvolt tvagy nem tvolt ilyen. Utána pedig oda lehet adni a programozónak a logot elemzésre. Ezen kítvül természetesen a My-SQL teljes és részleges log rögzítésre is képes, amely szintén megtalálható az alap konfguráció-ban, tviszont ezzel nagyon csínján bánjunk, ugyan is nagyon hamar a telítődhet a teljes log partíció, ha nem csak adot periódusra kapcsoljuk be a teljes logot.
A MySQL mentése
Értelemszerűen az installálás utolsó lépcsőjében érdemes egy alap mentést azonnal beállítani, amit aztán lehet bőtvíteni, tvagy mentési rendszerbe kötni. A MySQL beépítet mentési mechaniz-musát felhasználtva a kötvetkezőképpen lehet a legegyszerűbben lementeni a DB-t:
/usr/bin/mysqldump -prootjelszo webdb | /bin/gzip > /backup/mysql-webdb-$1.tgz/usr/bin/mysqldump -prootjelszo information_schema | /bin/gzip >/backup/mysql-information_schema-$1.tgz/usr/bin/mysqldump --all-databases -prootjelszo | /bin/gzip > /backup/mysql-
ALLDATABASE-$1.tgz
Mint az látható, az első két sor adot adatbázisokat ment, amelyeket a jelszó után netvesítetünk, a harmadik sor pedig az összes adatbázist menti egyben. A mentő sorok gzip tömörítést is alkal-maznak, mitvel a DB állományok akár 80-90%-os méret csökkenéssel is tárolhatóak, hiszen azok jellemzően sima text állományok. A fenti példában azért tvan külön és egyben is menttve az összes használt DB, mitvel egy esetleges részleges adat tvesztés tvagy korrupció esetén, nagyon nagy se-gítség, ha nem a teljes mentésből kell tvisszaállítani 1 táblát tvagy 1 DB-t. Viszont fontos, hogy egy teljes dump is rendelkezésre álljon. Fontos totvábbá az information_schema DB mentése is, mint azlátható, hiszen it tárolódnak a DB közöti hozzáférések és egyéb fontos információk. A teljes mentés természetesen ezt tartalmazza. A fenti sorokat érdemes tehát egy héjprogramba belemá-solni, és a megfelelő időben, amely jellemzően hajnalban üresjárati időben tvan, futatni. Akár napi, heti, hatvi rotációs tárolással.
Egy alternatítv mentési lehetőség, amikor a MysqlHotCopy164 Perl script gyűjteményt használjuk.Jellemzően ezt a módszert nem az előzőekben leírt mysqldump helyet, hanem annak kiegészíté-sére, akár napközbeni tvagy tesztelés előti gyors DB-mentésre használhatjuk bizonyos megköté-sekkel. Pl. csak MyISAM DB és Architve db típusok esetében használható.
Természetesen a komplexebb mentő eszközök kezelik a MySQL-t, de erről a Backup fejezetben oltvashatunk.
1164. http://dev.mysql.com/doc/refman/5.0/en/mysqlhotcopy.html
127
Adatbázis-kezelés
Referenciák
Néhány fontosabb referencia, ahol a MySQL-t megelégedéssel használják165::::
– WhiteHouse.Gotv
– NASA
– Department of Homeland Security
– Swedish National Police
– Ministère de la Justice (France)
– Bank of Finland
– Swedish National Police
– US Natvy
MariaDBA MariaDB166 a MySQL forráskódjából kiindult fejlesztés, mely jelenleg a MySQL-lel teljes mér-
tékben kompatibilis, közösség által fejlesztet és támogatot adatbázis szertver. A rendszer egyben kitválóan szemlélteti a szabad szoftver licencelésben rejlő hatalmas lehetőséget is. A MariaDB-t az Oracle üzleti célokat szem előt tartó lépései miat aggódó közösség hozta létre a GPL licenc elő-írásait betarttva, a MySQL forráskódjának totvábbfejlesztésétvel. A legtöbb platformra elérhető biná-rissal tvagy forráskóddal rendelkezik. Több klienssel használható, és rendelkezik a saját fejlesztésű MariaDB Client Library for Jatva Applicationsszel is. 2012 decemberében egy alapíttványt is létre-hoztak, amelynek célja a fejlesztés felügyelete, tvalamint annak háterének megteremtése. Jelenleg azonban nem minden Linux terjesztésnek része (bár ez 2013 elején gyorsan tváltozik, szinte min-den fontosabb terjesztés átállt rá MySQL-ről), tviszont minden lényeges terjesztéshez elérhető, bi-nárisan formában létvő programcsomagok szintjén (pl. Debian és Ubuntu rendszerekhez apt.sourceszinten is). Minden jel arra mutat, hogy a MariaDB a jövő szabad szofveres adatbázis-keze-lője, hiszen az Oracle MySQL fejlesztése nagyon könnyen tvehet nem tvárt fordulatot, így a fel-használók jelentős része tart a MySQL-től.
A MariaDB installálása majdnem pontosan megegyezik a MySQL beállításaitval, csupán jelenleg nem alap része a terjesztések szoftver kínálatának. Ezért első közelítésben szükséges feltvenni a MariaDB csomag tárolóit167 a rendszerbe:
sudo apt-get install python-software-propertiessudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xcbcb082a1bb943dbsudo add-apt-repository 'deb
http://ftp.heanet.ie/mirrors/mariadb/repo/5.5/ubuntu precise main'
Innentől pedig már csak telepíteni kell :
sudo apt-get updatesudo apt-get install mariadb-server
1165. http://www.mysql.com/customers/1166. https://mariadb.org/1167. https://downloads.mariadb.org/mariadb/repositories/
128
Adatbázis-kezelés
A totvábbiakban pontosan ugyanolyan parancsok és lehetőségek segítségétvel állíthatjuk be, minta MySQL esetében.
Referenciák
Számos ismert sikertörténetről oltvashatunk a MariaDB honlapján168, ezek közül néhány na-gyobb, érdekesebb:
– A Wikipédia angol és német kiadásai, tvalamint a WikiData 2013. április 22-én befejezte a Mari-aDB-re tvaló átállást169, melyet azóta is elégedeten használnak. A rendszer terhelésére jellemző, hogy az intenzítv gyorstárazás ellenére (melyet memcached és Redis segítségétvel tvalósítotak meg) az angol Wikipédia csúcsterhelése 50k lekérdezés másodpercenként.
– A 150 millió felhasználós Nimbuzz hátérrendszerén átállt MariaDB-re170.
– Az OLX, mely napi 40 millió lapot szolgál ki, szintén MariaDB-t használ171.
PostgreSQLA PostgreSQL172 fejlesztését az 1970-as étvekben kezdték meg a kaliforniai Berkeley egyetemen
Ingres nétven. A 80-as étvek közepétől több különböző kereskedelmi termék (mint a Sybase tvagy a Microsof SQL Sertver), és akkor még Postgres (Post Ingres) nétven ingyenes tverzióként élt totvább a projekt. 1996-ban kapta a manapság használt PostgreSQL netvet (a 6.0-s tverziótól). Alaptvetően egy olyan adatbázis-kezelő rendszer, amely szabtványos SQL-felületen tvezérelhető, azonban a tu-dása jótval komplexebb a függtvényrendszernek köszönhetően. A függtvények megtvalósítása több nyeltven is lehetséges (pl. Jatva, Perl, Python, Ruby, Tcl, C/C++, PL/pgSQL). Totvábbi előnyei a trig-gerek173 defniálása, a tranzakciókezelés, a komplex adatípusok használhatósága, a sémák és a replikáció. Természetesen rendelkezik a magyar nyeltv teljes körű támogatásátval DB szinten. Komplexitásának és tudásának köszönhetően gyakran tválasztják nagy teherbírású és magas ren-delkezésre állást igénylő feladatokhoz. A PostgreSQL is szabad szoftver, amelyet a MIT-stílusú (a módosítot tváltozatok zárt licencelését is megengedő) PostgreSQL174 licenc alat tesznek közzé.
Jelenleg a kötvetkező, igencsak meggyőző korlátokkal rendelkezik:
– maximális adatbázisméret korlátlan
– maximális táblaméret32 TB
– maximális sorméret 1,6 TB
– maximális mezőméret 1 GB
– sorok maximális száma táblánként korlátlan
– oszlopok maximális száma táblánként 250–1600, oszloptípustól függően
1168. https://kb.askmonty.org/en/mariadb-case-studies/1169. http://blog.wikimedia.org/2013/04/22/wikipedia-adopts-mariadb/1170. https://kb.askmonty.org/en/nimbuzz-uses-mariadb/1171. https://kb.askmonty.org/en/olx_serves_40_million_page_views_daily_MariaDB/1172. http://www.postgresql.org/1173. http://hu.wikipedia.org/wiki/Trigger_%28adatb%C3%A1zisok%291174. http://opensource.org/licenses/postgresql
129
Adatbázis-kezelés
– indexek maximális száma táblánként korlátlanRendelkezik a természetesnek számító parancssoros kezelést lehetőtvé tetvő eszközzel, és számta-
lan támogatot és igen magas szinten elkészítet GUI segédprogrammal175 is, amelyek megkönnyí-tik az adatbázis-adminisztrátorok munkáját. Az egyik ilyen igen népszerű segédprogram a phpPgAdmin176, amely akárcsak a MySQL esetében a phpMyAdmin, egy PHP alapú GUI. Érdemes megnézni a tudásmátrixot177, amely jól szemlélteti, hogy az elmúlt étvekben hatalmas fejlődésen ment keresztül, amelyet folyamatosan honorálnak is a különféle díjakkal178. A kételkedőknek pe-dig érdemes átfutni a nagyobb felhasználók179 listáját tartalmazó weboldalt, ahol meggyőződhe-tünk arról, hogy mekkora cégek döntötek a PostgreSQL mellet. Természetesen rendelkezik az összes ilyenkor eltvárható support és információs felületel, Wiki-oldallal, célzot fórumrendszer-rel. Inkább érdekesség, mint fontos információ, de a PostgreSQL team kizárólag Debian GNU/Li-nuxot használ a saját180 projektjén belül. Számos európai cég tvállal 7×24-es támogatást a PostgreSQL-re. Érdemes megemlíteni a számos gyári kiterjesztés közül a PostGIS181 kiterjesztést, amely kifejezeten földrajzi adatok kezeléséhez nyújt hathatós segítséget. Gyakorlati tapasztalat, hogy a PostreSQL a komplexebb Oracle-szintű DB kitváltására kitválóan alkalmas.
Referenciák
A rendszer honlapján számos komoly referencia tvan feltüntettve182, ezek közül néhány fonto-sabb:
– U.S. Department of Labor
– U.S. General Sertvices Administration
– U.S. State Department
– National Physical Laboratory of India
– United Nations Industrial Detvelopment Organisation
– City of Garden Grotve, California
– BASF, Agricultural Product Ditvision
– IMDB.com
– Creatitve Commons
– Greenpeace
– Fujitsu
– Cisco
1175. http://wiki.postgresql.org/wiki/Community_Guide_to_PostgreSQL_GUI_Tools1176. http://sourceforge.net/projects/phppgadmin/1177. http://www.postgresql.org/about/featurematrix/1178. http://www.postgresql.org/about/awards/1179. http://www.postgresql.org/about/users/1180. http://www.postgresql.org/about/servers/1181. http://www.postgresql.org/about/news/1387/1182. http://www.postgresql.org/about/users/
130
Adatbázis-kezelés
SQLiteAz SQLite183 egy igen széles körben használt (a többi felsorolt DB-hez képest apró) adatbázis-
kezelő függtvénykönytvtár, mely egyszerű kezelését egy parancssori adminisztrációs eszköz és egy Firefox kiegészítő (SQLite Manager) segíti. Egyéni felhasználásra szánt (bár helyben párhuzamo-san több folyamat és szál is használhatja), nem biztosít hálózati hozzáférést az egyetlen állomány-ként tárolt adatbázisaihoz. Jellemzően kliens oldali szoftverekbe építik a rendszer adatainak és a gyorsító tárnak egyszerű kezelésére. Jó példa erre a Firefox184 böngésző és Tunderbird185 letvele-zőkliens, ahol az elsődleges adatok tárolására használják. Számos más cég építi bele186 zárt tvagy szabad szoftveres termékébe. Felhasználási feltételei nincsenek187, hitvatalosan közkincs (public domain)188, amely szabad kezet ad a felhasználás tekintetében. Tudása folyamatosan fejlődik,189 és méreteihez képest igen fgyelemreméltó. Az adatbázis fájlok kényelmes elérésére használható mégaz Sqliteman190, az SQLite Studio191 és a (PHP-ban íródot) SQLiteManager192.
Számos totvábbi adatbázis-kezelő megoldás létezik szabad szoftverként, azonban egy tipikus tvál-lalati környezetben (ide nem érttve az olyan felhasználási területet, ahol párhuzamosan több ezer, százezer, tvagy millió felhasználó férhet hozzá egy időben ugyanahhoz az adatbázishoz, mint pl. a Google tvagy a Facebook esetében) jellemzően a több főkiszolgálós replikációt193 tudó adatbázis-motorokat használjuk.
Referenciák
Meglepő, hogy az SQLite teljesen észretvétlenül mennyire részétvé tvált a mindennapjainknak. A projekt honlapján található fontosabb referenciák közül194 kiemelünk néhány fontosabbat:
– Mozilla Firefox, Tunderbird, FirefoxOS - ezek az óriási felhasználói bázissal rendelkező prog-ramok és rendszerek a belső adataik tárolására használják az SQLite-ot.
– A Google számos helyen használja az SQLite-ot. A leginkább ismert felhasználási terület az Android rendszer, de ez tvégzi Google egyre népszerűbb böngészőjének, a Chrome-nak az adat-tárolását is.
– Az Apple is használja a rendszert a MacOS X, Apple Mail, Safari, iTunes szoftverekben, tvala-mint az iPhone rendszerben.
– A széles körben használt Dropbox adatmentő és szinkronizáló szolgáltatás kliens oldalán ebbentárolják az adatokat.
1183. http://www.sqlite.org/1184. http://www.mozilla.org1185. https://www.mozilla.org/hu/thunderbird/1186. http://www.sqlite.org/famous.html1187. http://www.sqlite.org/copyright.html1188. http://en.wikipedia.org/wiki/Public_Domain1189. http://www.sqlite.org/features.html1190. http://sqliteman.com1191. http://sqlitestudio.pl/index.rvt1192. http://www.sqlitemanager.org/1193. http://hu.wikipedia.org/wiki/Multi-master_replication1194. http://www.sqlite.org/famous.html
131
Adatbázis-kezelés
Hogyan válasszunk?Felmerül a kérdés, hogy a felsoroltak közül melyik az, amelyik egy adot feladatra megfelelő. Ha
hálózaton is elérhető, többfelhasználós adatbázis kezelőre tvan szükség, akkor a kérdés a Postg-reSQL és a MariaDB közöt fog eldőlni. Általánosságban elmondható, hogy mindkét rendszer ki-tválóan használható általános feladatokra. De a rendszer használatát jól ismerők nagyobb száma (korábbi MySQL DBA-k), elterjedtsége (a MySQL-t is beleérttve), illettve népszerűségének gyors nötvekedése miat a MariaDB195 a legjobb tválasztás. Ha mindenképpen szeretnénk nagytvállalati rutinnal licenctvásárlással egybekötni a támogatási igényünket, akkor jatvasolt a MySQL nagytvál-lalatoknak szánt tváltozatai közül tválasztani. A legjobb tanács, ami adható, hogy a feladathoz tvá-lasszunk eszközt, és ne fordíttva. Azaz, nézzük meg, hogy közép tátvon mire tvan szükségünk, mekkora adatmennyiség, milyen adatbázis-felépítés, milyen típusú adatbázis-kiterhelés tvárható, és ezt az ajánlásokkal és a két projekt weboldalán feltüntetet tudásmátrixszal összetvettve dönt-sünk. Fontos totvábbi szempont, hogy a MariaDB azt az utat járja, amit előte a MySQL sok sok étven át, mielőt feltvásárolták, így aki biztos szeretne lenni abban, hogy még sokáig a közösség tá-mogatását fogja éltvezni, annak érdemes megfontolni a MariaDB-re tvaló tváltást.
1195. http://db-engines.com/en/system/MariaDB%3BPostgreSQL
132
Webproxy
WebproxyProxynak196 netvezzük azokat a szoftvereket, amelyek a kliensek kéréseit köztes elemként más
szertverekhez totvábbítják. A kliens alkalmazás csatlakozik a proxy szertverhez, akár transzparenci-átval (anélkül, hogy tudná, hogy egy proxy szolgáltatásait tveszi igénybe – átlátszó), akár a kliens szoftverében rögzítet módon, majd onnan egy erőforrást, tvagy szolgáltatást igényel, amely egy tvagy több másik szertveren található. Lényegében a proxy egy erőforrást tvagy szolgáltatást oszt el.A proxy természetesen a rajta keresztüláramló adatokat és kapcsolatokat szabadon, a beállításai szerint módosíthatja. Azaz elemzés után a lokális tárolójából szolgálhatja ki a klienst anélkül, hogy a szertverhez fordult tvolna, tvagy a kérésben és/tvagy a tválaszban megtváltoztatot tvolna bár-mit. Sokszor a proxy célja a gyorsabb és erőforrás-kímélő felhasználás, de lehet korlátozás, megf-gyelés alapeszköze is. A proxy legszélesebb körben a HTTP kiszolgálásra alkalmas eszközként terjedt el az 1990-es és a 2000-es étvek elején, főként a modemes internetes időkben. Manapság azonban a legtöbb magasabb szintű tűzfal alaptvető része több fajta proxy (elemző megoldás), illet-tve használjuk tunnelezésre, tvagy erőforrások elosztására is. Másik elterjedt felhasználása, hogy az illegális szervereket rejtik el proxy szerverek mögé, főként a torrent világban. Így biztosítva azt, hogy ha az egyik vagy másik proxy kiszolgálót a hatóság le is kapcsolja, akkor nem a központi (core) mo-dulhoz (adatbázis stb.) jut el. Ugyanilyen felhasználási módja a TOR197 project megoldása, ahol szintén proxy szertvereken keresztül juthatunk el az internetre anonim módon (igaz, a működési eltvéből adódóan a mi internet hozzáférésünkön keresztül mások is forgalmazhatnak tartalmat szintén anonim módon). A proxyk tehát széles körben használatosak a szertveroldali felhasználás számtalan területén, és sok esetben egy tűzfal mögöt, tvagy egyéni alkalmazásokat használtva nincs is köztvetlen tudomásunk róluk.
A HTTP proxyTöbbgépes hálózat esetén szinte kikerülhetetlen tényező tvolt az 1990–2000-es étvek derekán,
amikor is a legtöbb cég tvagy betárcsázós analóg tvagy ISDN tvonalon osztozot, de később a bérelt tvonalak feltűnésétvel is maradt a legtöbb kistvállalkozás életében a web proxy. Tipikusan jellemző tviselkedés minta, hogy az egy területen dolgozó kollégák szabadidejükben ugyanazon oldalakat látogatják. A megfelelően beállítot proxy csak a tváltozásokat fgyeltve, mindig csak aktualizáltva a saját lokális gyorsítótárában tárolt tartalmat szolgálja ki a belső hálózatot. Így előfordulhat az, hogy bár 20 kolléga nézi meg ugyanazon híroldal nyitólapját, amelynek mérete felhasználói letöl-tésenként kb. 5 MB lenne, azonban mégsem 20×5 MB a bejötvő forgalom, mitvel a proxy lokálisan szolgál ki 19 felhasználót, és csak az első felhasználó tölti le teljesen a tartalmat, ezzel is kíméltve a sátvszélességet. Az internetszolgáltatók régebben hatalmas proxy szertvereket tartotak fenn, ugyanezen okokból, csak ot a belső hálózatot a betárcsázós modemes és ISDN/bérelt tvonali fel-használók alkoták, amíg a külső, spórolni kítvánt tvonal a nagyon drága nemzetközi sátvszélesség tvolt, amely a régebbi időkben műholdas és mikrohullámú rendszerek segítségétvel jutot el több-nyire hazánkba. Egy ilyen proxy rengeteg pénzt tudot megspórolni, és a felhasználói élményt is nagyban tudta jatvítani, hiszen a gyakran látogatot tartalmak szinte gyorsabban jötek be mint a közelebbi, ketvésbé látogatot ithoniak. Kezdetben számos zárt webproxy termék uralta a piacot,
1196. http://en.wikipedia.org/wiki/Proxy_server#Forward_proxies1197. https://www.torproject.org/
133
Webproxy
olyan cégek termékei mint a Netscape tvagy a Cisco. A szabad szoftverek közöt a legelterjedtebb mind a mai napig a Squid proxy198.
SquidAlapjai az 1996-ban lezárult Hartvest projekt keretein belül készültek el. Természetesen az elmúlt
több mint 1,5 étvtized alat a kódja teljesen átalakult. A szoftver fejlesztésért felelős Duane Wesselsaz NLANR199 munkatársa fogja össze a többi fejlesztőt. Alapja egyetlen blokkolásmentes I/O ala-pon tvezérelt folyamat, ez tvégzi el a feladatok nagy részét. Sokszor ez is jelenti a legnagyobb prob-lémát, pl. a memóriafoglalások tekintetében. Elterjedésének alapja, hogy funkcionalitása a kezdetek óta olyan bő, hogy a legtöbb zárt termék színtvonalátval nem csak feltveszi a tversenyt, ha-nem sok esetben meg is haladja azokat. Ennek köszönhető az is, hogy számtalan kereskedelmi do-bozos termék, tvagy eszköz felhasználja a Squidet.
A teljes körű szolgáltatási paletán olyan dolgok szerepelnek, mint: HTTP és FTP protokollok teljes körű kiszolgálása, az SSL kapcsolatok kezelése és gyorsítása, DNS cache, transzparens mű-ködési lehetőség. Részletesebb szakmai ismeret nélkül konfgurálható a tartalomszabályozás, és olyan népszerű gyorsítótárazási protokollok200 széles körét támogatja, mint az ICP, HTCP, CARP és WCCP. Egyszótval egy igazi szabad szoftveres sikertörténet, főként a tudása és a rendkítvül szé-les körű skálázhatósága miat: ugyanúgy használható egy 10-20 fős iroda kiszolgálójaként, mint egy 100 ezer ügyféllel rendelkező ISP201 szertvereként – természetesen más beállításokkal és merő-ben más hardtverelemekkel. A Squidre ugyan úgy jellemző, mint a Postfxre és az SSH-ra is (hogy csak két példát ragadjunk ki), hogy a tényleges tudásának csak a felszínét kapargatjuk átlagos kis-és középtvállalati üzemeltetés során.
A Squid telepítésesudo apt-get install squid3
Ahogy az már megszokot, ez a parancs a függőségekkel együt letölti a tárolókból, telepíti azt, majd alapbeállítás szerint létrehozza a cache dir környezetet és el is indítja a Squidet. Mitvel az alapbeállítások nem feltétlenül felelnek meg nekünk, ezért a legjobb, ha telepítés után rögtön le is állítjuk:
sudo service squid3 stop
A konfgurációs állomány az /etc/squid3/squid.conf úttvonalon található.
Nézzük tehát a squid.conf legfontosabb lehetőségeit:
http_port 3128
Defniálhatjuk, hogy a Squid melyik TCP porton fog hallgatni. A felhasználók ide fognak csatla-kozni a klienseikkel (böngésző stb.). Jellemzően érdemes 3128-as alapbeállításon hagyni.
hierarchy_stoplist cgi-bin \?
1198. http://www.squid-cache.org/1199. http://www.nlanr.net/1200. http://en.wikipedia.org/wiki/Web_Cache_Communication_Protocol1201. http://en.wikipedia.org/wiki/Internet_service_provider
134
Webproxy
acl QUERY urlpath_regex cgi-bin \?cache deny QUERY
Jelentése: A dinamikus tartalmat nem gyorsítótárazzuk.
access_log /var/log/squid/access.log squid
A naplót it fogjuk tárolni, ezért nagy terheltségű proxy esetében fgyeljünk arra, hogy bár a log-rotate fogja ezeket a naplókat is kezelni, de azzal együt se nőhessenek túl nagyra.
cache_mem 256 MB
A Squid által használt memóriaterület nagyságát határozhatjuk meg. Érdemes it202 tájékozódni arról, hogy mennyit érdemes beállítani. Minden rendszer egyedi, és főképpen a felhasználók szá-mától és tviselkedésüktől függ. Az úgynetvezet „hot object” méretől is és a maximálisan tárolható objektum méretétől is függ, amely a kötvetkező opciótval állítható. Azaz képzeljünk el egy olyan hálózatot, ahol tvegyesen Ubuntu kliensek és Windows kliensek használják a proxy szertvert. Jel-lemzően az Ubuntu frissítések 0,5-5 MB méretűek, esetenként egy kernel 30-50 MB méretű is le-het. Azaz legalább ennek érdemes beleférnie a memóriába, hiszen ahogy a kliensek felkapcsolódnak a hálózatra, majdnem egyszerre fognak frissíteni. Windows frissítéseknél ugyan így kell ügyelni a méretezése, azaz:
maximum_object_size 128 MB
Ide azt a legnagyobb objektumméretet írjuk be, amely jellemző a környezetünkre.
Fontos az is, hogy a maximum_object_size beleférjen a cache_mem területbe is. A Squid a cache_mem terület sokszorosát is lefoglalhatja terhelés alat. Jellemzően egy gyorsítótár-szertverbelegalább 4 GB memóriát érdemes beépíteni már 10-15 felhasználó esetében is, tvagy ha tvan rá le-hetőség, akkor ennél akár többet is, tvalamint ezzel párhuzamosan lehet nötvelni a cache_mem mé-retét is.
cache_dir ufs203 /var/spool/squid3 1024 16 256
Ezzel a beállítással megadjuk, hogy hol helyezze el az átmeneti tárolókat, tvalamint sorban a gyorsítótár mérete MB-ban, a könytvtárak és az alkönytvtárak száma. Már egy alap proxy esetében is fontos, hogy a napló és a lemezgyorsítótár jól elkülönüljön, lehetőleg más partíción, még inkábbmás lemezen legyenek tároltva, hiszen ha ugyanabban az időben fogjuk a naplót írni és a tárolt adatot írni/oltvasni, akkor a diszk oltvasófejének mozgatása két tátvoli rész közöt fölöslegesen lassí-tana. Nagyobb rendszerek esetében érdemes egy külön tvezérlőn RAID0-ba összefűzni egy na-gyobb partíciót, hiszen it az adattvesztés maximum átmeneti fennakadást okozhat csak, amíg újra megtelnek a tárolók. Érdemes totvábbá a „noatime” mount-opciót használni a külön lemezgyorsító-tárat tartalmazó fájlrendszer csatolásához, ezzel is nagyban gyorsíttva a hozzáférést. Totvábbi jó megoldás hagyományos meretvlemezek esetében, ha minél gyorsabb (ma: 15k-tval pörgő) lemeze-ket tválasztunk és a fájlrendszer foglaltságát 50% közelébe kalibráljuk be. Ugyanakkor a folyamato-san egyre megfzethetőbb SSD-tárolók térnyerésétvel érdemes elgondolkodni egy sima SSD cache_dir megoldáson, hiszen ezt közel memória sebességgel fogja a rendszer elérni. Természete-sen egy SSD Squid cache-ként tvaló használata erősen csökkenti az SSD életartamát, hiszen folya-matos írásnak/oltvasásnak tvan kitétve, így az egész rendszert nem érdemes SSD-re telepíteni, hanem kifejezeten csak a lemezgyorsítótár részt. Valamint az SSD állapotát folyamatosan monito-rozni kell, például beköttve Nagios/Icinga alá, tvagy smartmoontols-szal204 fgyelni. A fájlrendszer elkészítése során (mkfs) egy normál nem túl nagy cég kiszolgálásra alkalmas proxy beállítása ese-
1202. http://wiki.squid-cache.org/SquidFaq/SquidMemory1203. http://www.squid-cache.org/Doc/config/cache_dir/1204. http://sourceforge.net/apps/trac/smartmontools/wiki
135
Webproxy
tén használhatjuk a default paramétereket, azonban ha nagy terheltségű gyorsítót akarunk üze-meltetni akkor érdemes utánaoltvasni a blokkméretnek és úgy hozzuk létre az FS-t, hiszen jellem-zően a Squid állományai pár KB-os méretűek.
acl205 manager proto cache_objectacl localhost src 127.0.0.1/32 ::1acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1acl SSL_ports port 443 # httpsacl Safe_ports port 80 # httpacl Safe_ports port 21 # ftpacl CONNECT method CONNECThttp_access allow manager localhosthttp_access deny managerhttp_access deny !Safe_portshttp_access deny CONNECT !SSL_portshttp_access allow localhosthttp_access deny all
A fenti beállításokkal egyben határozzuk meg egyrészt a belső hálózatunkat (jelen példában csak a localhost tvan engedtve), illettve határozzuk meg azokat a portokat, amelyeket biztonságos-nak ítélünk. Majd az első szabályok segítségétvel mindent engedünk a localhost-ról, minden Safe portot engedünk és tvégül minden mást kizárunk. It sorolhatjuk fel az alhálózatainkat, úgy mint:
acl localnet src 192.168.2.0/255.255.255.0
De ebben az esetben ne feledjük a http_access allow localnet segítségétvel azt engedni:
http_access allow localnet
Roppant fontos, hogy a belső proxy, ha tvan külső lába semmiképpen se látszódjon, tvagy enged-jen forgalmat kítvülről, ugyanis előbb tvagy utóbb a szemfüles, direkt ilyen hiányosságokat, azaz kilátszó anonymous proxykat kereső emberek tvagy robotok ezt meg fogják találni és onnantól gyakorlatilag a netvünkben indíthatnak kéréseket a nagytvilág felé.
A Squid3 összekapcsolható LDAP-ból tvaló azonosítással tvagy Actitve Directory-tval206 is, így a már meglétvő felhasználó-azonosítási rendszerbe is integrálható.
Transzparens üzemmódbanHa nem szeretnénk, hogy a felhasználó maga dönthessen, hogy használja-e a proxyt, tvagy sem,
akkor kikényszeríthetjük annak használatát a helyi tűzfal és egy proxy szertver segítségétvel. A már beállítot paramétereken kítvül a Squid3-ban igazán csak a kötvetkező opcióra tvan szükség ahhoz, hogy átlátszó elemként beépüljön a hálózatunkba:
http_port 3128 transparent
Természetesen azért a tűzfalat módosítani kell, hogy a HTTP és az FTP forgalom átmenjen a proxy gépünkön. Egy aktuális LTS Ubuntuhoz készítet leírást találhatunk it207, de álljon it egy
1205. http://wiki.squid-cache.org/SquidFaq/SquidAcl1206. http://wiki.squid-cache.org/ConfigExamples/Authenticate/WindowsActiveDirectory1207. http://ubuntuserverguide.com/2012/06/how-to-setup-squid3-as-transparent-proxy-on-ubuntu-server-12-
04.html
136
Webproxy
egyszerű példa amelyet a tűzfal gépünkön kell beállítanunk, hogy a forgalom átmenjen a proxy gépen:
iptables -t nat -A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.1:3128
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
Jelen esetben a Proxy gép IP címe a 192.168.1.1 és az eth0 a WAN felöli oldal.
A transzparens proxy beállításátval lehetőség nyílik arra, hogy a teljes, titkosítatlan közegben történő felhasználói HTTP forgalmat monitorozzuk, majd elemezzük a Sarg208 segítségétvel. Ez sokesetben célratvezetőbb, mint tiltani és arra sarkalni a felhasználót, hogy keressen kiutat. Természe-tesen fgyelembe kell tvenni a hazai törtvényi környezetet, azaz a felhasználótval megfelelő módon közölni kell, hogy megfgyelés alat áll.
Proxy beállítások központosítása:A böngészők támogatnak egy úgynetvezet automatikus proxy beállítást (Proxy AutoConfgurati-
on – PAC). Ezt abban az esetben érdemes használni, ha nem tudunk tvagy nem akarunk transzpa-rens proxyt beállítani, de nem szeretnénk a klienseken az esetleges proxy IP-cím, port stb. tváltozásokat kézzel állítgatni. Az ilyen esetekben egyszer kell csak a kliens böngészőben az auto-matikus proxy beállítást kitválasztani, majd megadni a proxy beállító szkript URL-jét. A hálózaton elhelyezet (HTTP- tvagy HTTPS-protokollon elérhető) PAC209 állományból oltvassa majd fel a böngésző, hogy hol található a proxy szertver. Valamint a PAC210 szkriptben azt is ki lehet kötni, hogy amennyiben a proxy szertver nem elérhető, akkor direktben menjenek ki az internetre a gé-pek.
Weboldalak blokkolásaGyakori igény, hogy az ismertebb „sátvszélességrabló” oldalakat szükség esetén blokkoljuk, erre
a Squid többféle megoldást is kínál. A legegyszerűbb egy acl létrehozása és kitiltása:
acl block_site dstdomain "/etc/squid3/blocked-sites"http_access deny block_site
Értelemszerűen a /etc/squid3/blocked-sites állomány tartalmazza a blokkolni kítvánt oldalak lis-táját.
Ennél kifnomultabb megoldás kínál a squidguard211, amely beépülő modulként hítvható a Squid-ből, természetesen telepítés után:
apt-get install squidguard
1208. http://sarg.sourceforge.net/1209. http://wiki.squid-cache.org/SquidFaq/ConfiguringBrowsers1210. http://en.wikipedia.org/wiki/Proxy_auto-config1211. http://www.squidguard.org/
137
Webproxy
Tudása messze túlmutat az egyszerű blokkolási lehetőségeken212, hiszen adatbázisból dolgozik, így eletve mások által készítet feketelistákat is felhasználhatunk213. A Squid-del tvaló integrációja igen egyszerű, a Squid konfgurációját a kötvetkező sorral kell kiegészíteni :
redirect_program /usr/sbin/squidGuard -c /etc/squid3/squidGuard.conf
Majd a Squid újraindítása után használatba tvehetjük:
sudo service squid restart
Az /etc/squid3/squidGuard.conf fájlban beállíthatunk mások által defniált adatbázisokat, kate-góriákat is létrehozhatunk:
dbhome /usr/local/squidGuard/dblogdir /usr/local/squidGuard/log
dest gambling { log gambling domainlist gambling/domains urllist gambling/urls}
dest warez { log warez domainlist warez/domains urllist warez/urls}
acl {default {
pass !gambling !warez allredirect 302:http://gnu.hu
}}
Így ha a példában szereplő gambling/domains, gambling/urls, és warez/domains és warez/urls fájlok megfellelően ki tvannak tölttve tartomány- tvagy számítógépnetvekkel, illettve URL-ekkel, akkor pl. aszerencsejátékos és a warezoldalak egy jelentős részét tudjuk blokkolni, tvagy átirányítani akár egy meglétvő külső akár egy saját hálózatban létvő belső weboldalra, amely természetesen lehet egy fgyelmeztetés is.
Sarg214
Ez az igen hasznos alkalmazás kiegészíti a Squid naplózási képességeit. Természetesen a proxy szertver naplóállománya igen részletes, így nagy felhasználói szám mellet még a gyakorlot napló-
1212. http://www.squidguard.org/about.html1213. http://www.squidguard.org/about.html1214. http://sarg.sourceforge.net/
138
Webproxy
elemző számára is tökéletesen átláthatatlan. A Sarg ebben nyújt segítséget, mitvel grafkusan elem-zi számunkra a felhasználók szokásait. Használata és telepítése egyszerű, felépítése és konfguráci-ós állománya nagyon hasonlít a Webalizerhez215. Praktikusan éjszaka lefut, és az aznapi tetvékenységet grafkonok és táblázatok segítségétvel elhelyezi egy kiértékelés könytvtárban, ame-lyet aztán akár weblapszerűen (webszertver szükséges) tvagy lokálisan (a tartalmat saját gépre átmásoltva, pl időzítet scp, stb) egy böngészőből kiértékelhetünk különböző rendezési eltvek alap-ján. Nagyon könnyű összegezni tvele a legnagyobb letöltőt, illettve mérni tvele az esetleges nem til-tot, de nem ajánlot tartalmakon eltöltöt időt. Éppen ezért komoly tvisszaélésekre is lehet használni, hiszen a felhasználók teljes napi/heti/hatvi weben töltöt naplóját könnyen értelmezhe-tően mutatja. Tehát kezeljünk szenzitítv adatként, és mindenképpen tvédjük/tároljuk megfelelően a kiértékelt adatokat.
1215. http://en.wikipedia.org/wiki/Webalizer
139
VPN beállítás : IPSec és OpenVPN
VPN beállítás: IPSec és OpenVPNHa már eljutotunk oda, hogy az SSH alagút és az egyéb megoldások nem kínálnak kellő kom-
fortot, tvagy nem jól központosíthatóak, tvagy egész egyszerűen csak nem mindenki számára jelen-tenek könnyen kezelhető megoldást, akkor érdemes megfontolni egy olyan megoldást, amikor a teljes hálózati kommunikáció egy titkosítot magánhálózat kiépítésétvel jár együt. A VPN nem csak akkor jelent megoldást, amikor két céges alhálózatot akarunk összekapcsolni, bár tvalójában erre tertvezték. Akkor is kitválóan használható, ha az othoni gépünkkel akarunk rákapcsolódni egy céges hálózatra, illettve bizonyos esetben szertver és szertver közöti kommunikációra is hasz-nálható, de arra talán nem a legideálisabb megoldás. A fő előnye, hogy az alhálózatokat típusától függően erős titkosítással biztosítja, tvalamint minden, az adot kapcsolaton átmenő forgalom az átjáró beállításainak függtvényében a titkosítot közegben utazik. A manapság használatos VPN kliensek olyan egyszerűen kezelhetőek, hogy egy átlagos tudású felhasználónak sem okoz gondot a kezelése, természetesen ha megfelelően automatizálta a rendszergazda a felépülési folyamatot. Segítségétvel nem csak a szertvereinket érhetjük el, hanem az irodában létvő bekapcsoltva hagyot klienseket is (például egy tátvoli asztal szoftver segítségétvel). VPN megoldásokból számtalan léte-zik, mint ahogyan a VPN-protokoll használata alapján is sokrétűek (PPP, PPTP, L2TP, IPsec)216. A leginkább elterjedt és széles körben használt az OpenVPN217, amely széleskörű dokumentációtval218
rendelkezik. Az Ubuntu kliensek beépítet lehetőséggel rendelkeznek a NetworkManager progra-mon keresztül a gyakorlatilag pár katintásos VPN kapcsolat kiépítésére. A VPN technológiára is értvényes az SSH-nál már bemutatot biztonsági irányeltvek alkalmazása, azaz a lehetőségek tárhá-zából használjuk ki a lehető legtöbb azonosítási, hitelesítési eljárást és módot annak érdekében, hogy biztosak lehessünk benne, csak az jut be a hálózatunkba, akit mi be is akartunk engedni. Ha az a cél, hogy néhány felhasználó számára biztosítsuk OpenVPN-nel a tátvoli elérést, akkor a kö-tvetkező lépésekre lesz szükségünk.
OpenVPNSzertver oldalon telepítsük az OpenVPN csomagot, és hozzuk létre a fő konfgurációs fájlt, netve
tipikusan /etc/opentvpn.conf, de például Ubuntu 12.04 LTS alat /etc/opentvpn/szertvernetve.conf. A lenti konfgurációban az alapértelmezet UDP helyet TCP-t használunk. (Nincs rá általános sza-bály, hogy TCP, tvagy UDP a jó. Az OpenVPN dokumentációja az alapértelmezet UDP-t jatvasolja, tviszont elég sok tűzfalon könnyebb átengedtetni egy titkosítot IMAP-nak álcázot kapcsolatot219, mint mindenféle szedet-tvedet UDP-csomagokat. Ráadásul a tűzfalszoftverek jelentős része az SSL miat nem nagyon tudja megkülönböztetni a tvalódi IMAPS forgalmat, az annak álcázot OpenVPN forgalmától.) Az egyes klienseket tanúsíttvány segítségétvel azonosítjuk. A klienseknek 1hétig értvényes dinamikus címeket osztunk ki a 172.22.2.0/24-es tartományból. Lehetőség tvan az egyes klienseket ideiglenesen kitiltani a VPN-ből. Ehhez a Client-Confg-Dir könytvtárban létre
1216. htp://en.wikipedia.org/wiki/Virtual_pritvate_network1217. htp://opentvpn.net/1218. htp://opentvpn.net/index.php/open-source/otvertview.html1219. Ebben a példában egy működő gyakorlatot mutatunk, tviszont a helyi biztonsági házirendbe ütközhet, és az azért
felelős társaság akár támadásnak is tekintheti. Erről mindenképpen bizonyosodjunk meg, mielőt így állítanánk be. Az OpenVPN-hez a szabtványosítot szertverport az 1194-es, kétségek esetén próbálkozzunk inkább azzal (persze mind a szertver, mind a kliens oldalon azonos módon kell beállítani).
140
VPN beállítás : IPSec és OpenVPN
kell hozni a kliens tanúsíttványában szereplő nétvtvel megegyező netvű egyedi konfgurációs fájlt, amely fájlba a „disable” sort beírtva, a tiltás értvényre jut. Ha tvalamely klienst tvéglegesen ki kell tiltani, akkor jatvasolt a disable helyet a tanúsíttvány tvisszatvonásátval megoldani a dolgot.
A konfigfájlban megadandó paraméterek
Egy un. TUN eszközt használunk a kommunikációra, amikor a VPN szoftver elindul, akkor egy tunX netvű hálózati interfész jelenik meg.
dev tun
A fent említeteknek megfelelően, titkosítot IMAP protokollnak álcázzuk magunkat – ezért a TCP beállítás, és ezért kommunikálunk a 993-as porton keresztül
proto tcpport 993
A szertver ebből a címtartományból osztja a címeket a klienseknek.
server 172.22.2.0 255.255.255.0
Ezek a hitelesítés használatához szükséges fájlokat adják meg.
A Root-CA:
ca /etc/openvpn/szerverneve/keys/ca.crt
A szertver tanúsíttványa:
cert /etc/openvpn/szerverneve/keys/kompkp1.crt
A szertver tanúsíttványához tartozó kulcs:
key /etc/openvpn/szerverneve/keys/kompkp1.key
A szertvernek szükséges Dife-Hellmann paramétereket tartalmazó fájl :
dh /etc/openvpn/szerverneve/keys/dh2048.pem
Időnként szükség lehet az egyes kliensek számára egyedi paramétereket meghatározni – tvagy mint fentebb már tvolt róla szó, ideiglenes tiltáshoz is nagyon kényelmes, ha minden kliensnek tvansaját konfg fájlja. Amennyiben egy kliens csatlakozik, akkor a tanúsíttványa CN (CommonName) mezőjében szereplő netvű fájlt tveszi fgyelembe az OpenVPN szertver, ha ilyen netvű fájl nincs, ak-kor a DEFAULT netvű fájlt – és mindezeket a CCD paraméterben meghatározot könytvtárban ke-resi a szertver.
client-config-dir /etc/openvpn/szerverneve/ccd
It tárolja a szertver, hogy egyes klienseknek milyen IP-címet osztot ki, és az utolsó bejelentke-zés után mennyi ideig tárolja ezt az információt. Ha több idő telik el, a bejegyzés törlődik, ily mó-don már nem biztos, hogy a kliens ugyanazt a címet kapja megint.
ifconfig-pool-persist /etc/openvpn/szerverneve/client_ips.txt 604800
Bizonyos esetekben SIGUSR1 megszakítás generálódik, de nem szeretnénk, ha ezek a megszakí-tások különböző paraméterek módosulását eredményeznék.
persist-tunpersist-keypersist-local-ip
141
VPN beállítás : IPSec és OpenVPN
persist-remote-ip
A működési állapotra tvonatkozó információk ebbe a fájlba kerüljenek:
status /var/log/openvpn-status.log
A naplózás szintjének és helyének meghatározása:
verb 3log-append /var/log/openvpn.log
Megpróbáljuk fenntartani a hálózati kapcsolatot akkor is, ha nincs tvalódi adatforgalom az egyes kliensek irányában. Ez azért lehet érdekes, mert sok tűzfal bizonyos időtartam után, ha nincs for-galom egyszerűen lebontja a kapcsolatot.
keepalive 60 300
Ezzel a paraméterrel biztosítjuk, hogy a kliensek egymást is elérhetik, nem csak a szertvert. Nyiltván, ha szeparálni kell őket, ez az opció nem szükséges.
client-to-client
A paraméterek nélküli tömörítési opció azért jó, mert ebben az esetben akár kliensenként lehet kapcsolgatni, hogy legyen-e forgalomtömörítés. Általában érdemes bekapcsolni, de talán egy fok-kal jobb, ha ezt a kliensek DEFAULT, illettve kliens-specifkus fájljában tudjuk testre szabni, nem pedig globálisan engedélyezzük tvagy tiltjuk.
comp-lzo
A teljes VPN használatához ezen kítvül szükséges a fent hitvatkozot tanúsíttványok (és a kliensek tanúsíttványai) létrehozása. Ehhez a ma már szinte minden terjesztésben alapértelmezeten elérhe-tő OpenSSL csomag szintén openssl netvű parancsát kellene köztvetlenül használni, de használható helyete néhány könnyebben kezelhető segédprogram. Az OpenVPN terjesztés részeként elérhető az un. easy-rsa netvű parancssoros eszköz, de aki jobb szereti a grafkus eszközöket, az használhat-ja a Gnomint220 netvű grafkus eszközt is, amely sok disztribúcióban szintén bináris csomagként elérhető, kényelmesen használható segédprogram.
Easy-rsa
Nézzük az easy-rsa-t. Először keressük meg, és lehetőleg másoljuk át a feltelepítet könytvtár-struktúrát egy kényelmesebben kezelhető (és ráadásul frissítésektől nem bántot) helyre, mondjuka saját könytvtárunkba. Például Ubuntu-12.04 LTS alat a kötvetkező paranccsal:
cp -r /usr/share/doc/openvpn/examples/easy-rsa $HOME/
Noha Ubuntun elérhető a régebbi 1.0-s tverziójú easy-rsa is, jatvasolt az újabb tverziót használni. Ehhez lépjünk a másolat könytvtárba, és annak 2.0 netvű alkönytvtárába:
cd ~/easy-rsa/2.0
Legelső lépésként az it található vars netvű fájlt kell megszerkeszteni, és a különböző tanúsíttvá-nyokhoz szükséges információkat beállítani. Ehhez át kell írni a fájl tvégén található export KEY_ kezdetű sorokat, hasonlóan az it találhatóhoz:
export KEY_COUNTRY="HU"export KEY_PROVINCE="Pest megye"
1220. htp://gnomint.sourceforge.net/
142
VPN beállítás : IPSec és OpenVPN
export KEY_CITY="Budapest"export KEY_ORG="Szervezet Neve Ha Tartalmaz Szóközt Kötelező Az Idézőjel"export KEY_EMAIL="[email protected]"export KEY_CN=openvpn-serverexport KEY_NAME=vpn.example.huexport KEY_OU="szervezeti egység"export PKCS11_MODULE_PATH=changemeexport PKCS11_PIN=1234
Ha a fájl ki tvan tölttve, kezdhetjük. A legelső lépés, hogy az aktuális shellbe beoltvastatjuk a szük-séges beállításokat a kötvetkező, elég furcsa paranccsal :
. ./vars
A parancs netve „.” (azaz pont), paramétere pedig ./vars (pont-per-tvars). Ezek után első lépésként futassuk le a kötvetkező parancsot. Vigyázat, ezt a későbbiekben csak abban az esetben szabad használni, ha teljesen tiszta lappal szeretnénk kezdeni, minden korábban esetleg létrehozot kul-csot, tanúsíttványt, egyebet töröl. Még egyszer: ezt a parancsot csak most kell futatni, a későbbi-ek során már nem:
./clean-all
Miután (az egyébként tiszta) környezetünket kitakarítotuk, jöhet a munka hasznosabb része. Előállítjuk az un. root-CA-t. A parancs futása során kérdezget tőlünk, alapértelmezetként min-denhol megfelel az alapértelmezet tválasz (amiket a tvars fájlban kitöltöt adatokból állít elő):
./build.ca
Ha ezzel készen tvagyunk, állítsuk elő a szertverünk saját tanúsíttványát. Amikor jelszót kér tő-lünk a rendszer, ot is elegendő az Enter, ellenben ezt kötvetően kétszer is egyértelműen IGEN tvá-laszt („y”) kell adni: előbb a tanúsíttvány aláírásakor („Sign the certifcate”), majd pedig a tanúsíttvány elfogadtatásakor („1 out of 1 certifate requests certifed, commit”) megjelenítet üzenet-nél.
./build-key-server server
Ha ez is megtvan, gyárthatjuk a kliensek által használandó tanúsíttványokat:
./build-key egyik-kliens
./build-key masik-kliens
Amikor a tanúsíttványok már megtvannak, még egy legenerálandó adat tvan hátra. A szertver szá-mára szükséges un. Dife-Hellman paraméterek előállítása. Ehhez szintén adot egy segédprog-ram:
./build-dh
Végeredményként előálltak a kötvetkező fontos fájlok, eltvben a keys netvű alkönytvtárban:
A szertver számára szükségesek: dh*.pem (a fájl netve atól függ, hogy a vars fájlban mekkorára állítotuk a KEY_SIZE értékét – ezt az alapértelmezet 1024-ről jatvasolt megnötvelni, legalább 2048-ra), a sertver.crt és sertver.key fájlok. Minden egyes kliens számára szükséges a kliensnetve.crt és kliensnetve.key fájlok. Végül mind a szertver, mind a kliensek számára szükséges a ca.crt. (Vala-mint a tanúsíttványokat létrehozó – az eddigi példában a szertver – számára a ca.key is.) A *.key fájlokat erősen tvédeni kell, a klienseknek a sajátjukat jatvasolt tvalamilyen tvédet adatcsatornán el-jutatni (esetleg megfelelően titkosítot – például GPG221 – e-mailben). Miután mindent legenerál-
1221. Részletes GPG ismeretekért oltvassa el GPG-fejezetünket.
143
VPN beállítás : IPSec és OpenVPN
tunk, a ca.crt, sertver.crt, sertver.key és dh*.crt fájlokat helyezzük el ot, ahol a fenti opentvpn-konf-gurációs fájl szerint hitvatkozunk rájuk. A szertver beállításátval tvégeztünk, tulajdonképp a szertver elindítása és a kliensek bekonfgurálása tvan hátra.
Kliensek beállítása
A kliensekhez jutassuk el a ca.crt fájlt, és a hozzájuk tartozó client.crt és client.key fájlokat, majd pedig a kliens számára tvagy létrehozunk egy szötveges konfgurációs fájlt, amit majd az im-portál222, tvagy rábízhatjuk magukra a felhasználókra is, hogy a kítvánt adatokat adják meg kézzel. Egy tipikus kliens oldali konfguráció, it már csak a fentiekben nem tárgyalt paraméterek ma-gyarázatátval:
Ezeket a paramétereket a szertverrel összhangban kell beállítani :
dev tunproto tcp
Ez a paraméter azt jelenti, hogy a kapcsolatban mi kliensként tveszünk részt, TLS-t fogunk használni, és induláskor elkérjük a szertvertől a ránk tvonatkozó paramétereket.
client
Ehhez a szertverhez kapcsolódunk, a megadot porton.
remote 1.2.3.4 993
Véletlenszerű portot használunk a szertverrel tvaló kommunikációhoz. Bizonyos tűzfalbeállítások esetén okozhat problémát, és helyete a tűzfal adminisztrátorátval egyeztetet portot kell megadni (a port tvagy lport paraméterek segítségétvel).
nobind
A kötvetkező paraméter egyfajta plusz biztonságot nyújt, a klienseink csak olyan OpenVPN-szer-tverhez fognak csatlakozni, amelynek a tanúsíttványa szertver típusú. (Ehhez a szertver tanúsíttvá-nyát megfelelő módon kellet generálni – szerencsére mi ezt tetük.) Nyiltván a tanúsíttványok használata eletve nötveli a biztonságot, de ahogy fent már elhangzot: használjunk ki minél több biztonságot nötvelő lehetőséget, ha az nem megy a használhatóság rotvására.
ns-cert-type server
Ezek pedig már ismerősek korábbról.
persist-keypersist-tunca ca.crtcert kliens1.crtkey kliens1.keycomp-lzoverb 3
Fenti beállítások szerint a szertver az 1.2.3.4 IP-című gép 993-as portján érhető el. Az azonosítás-hoz ahogy korábban már elhangzot, tanúsíttványt használunk, ez a kliens1.crt fájlban található. A fenti VPN kliens konfguráció állományba mentése után (*.ovpn kiterjesztéssel) célszerű egy könytvtárba helyezni a kulcsokkal (crt és key fájlok), majd Ubuntu Desktop rendszer esetén az
1222. Természetesen kliens konfgot nem kell létrehozni abban az esetben, ha a felhasználók nem csak egy tviszonylag egyszerűbb importálást, hanem egy bonyolultabb, pár paraméter kitöltését igénylő műtveletet is képesek eltvégezni a NetworkManager-ben.
144
VPN beállítás : IPSec és OpenVPN
.ovpn állományt megadni a NetworkManager alkalmazás VPN kiegészítőjének. Előte azonban Ubuntu alat szükséges az NM OpenVPN kiegészítésének a telepítése a kötvetkezőképpen:
sudo apt-get install network-manager-openvpn
Ezek után a NetworkManager már felismeri az optvn állományt, amit egyszerűen az importálás menüpontban tudunk feloltvastatni tvele:
Ha szeretnénk, hogy a VPN elindítása utána, a default route-ot a VPN csak kiegészítse, és ne ál-lítsa át a VPN irányába teljesen, akkor a kötvetkező kapcsolót alkalmazzuk:
Tehát, ha az „A kapcsolat használata csak a hálózatán létvő erőforrásokhoz” pipát használtuk, egyszerre fog működni a publikus internet felé a routing és a VPN felé is. Persze sok esetben pont az a cél, hogy ha a VPN tvan életben, akkor a publikus internet felé a felhasználó ne tudjon for-galmazni, ebben az esetben célszerű ezt a kapcsolót alapállapoton – azaz kikapcsoltva – hagyni.
IPsec223
Az IPsec a nagytvállalatok és céges rendszerek elengedhetetlen kelléke, az IP protokollra épül kétmásik protokollból. Az egyik az Encapsulated Security Payload (ESP), amely a hasznos adatot cso-magolja be szimmetrikus kriptográfai algoritmussal (Blowfsh, 3DES) így tvédtve meg az IP csomagtartalmát az illetéktelenektől. A másik réteg az Authentication Header (AH), amely az IP csoma-gok fejlécének hamisítását teszi lehetetlenné egy ujjlenyomat segítségétvel.
1223. htp://hu.wikipedia.org/wiki/IPsec
145
VPN beállítás : IPSec és OpenVPN
A nagy kérdés, hogy ha az IPsec az iparági standard, akkor miért nem azzal kezdődik a VPN fe-jezet, miért azt hagytuk a tvégére? A megtválaszolása egyszerű, az OpenVPN az elmúlt étvtizedben hatalmas fejlődésen ment keresztül, együt fejlődöt a tűzfalakkal és a szolgáltatók szűrési mecha-nizmusa is egyszerűbben megkerülhető tvele, mint az IPsec esetében. Hogy egyértelmű legyen mire gondolok, álljon it egy általános példa. A legtöbb tűzfal tvagy csak csomagszűrő tvagy ha applikációs szintű, akkor sem tudja megkülönböztetni a 443, 993, 995-ös porton üzemelő SSL ala-pú letvelezéshez megnyitot portok forgalmát az ezekre a portokra felültetet OpenVPN-étől. Azaz ha a 3G szolgáltatónk borsos áron akarja eladni nekünk az amúgy is komoly összegért megtvásá-rolt 3G adat mellé a pritvát hálózat szolgáltatást, és ezt úgy éri el, hogy tiltja a tipikus VPN proto-koll portokat és esetleg csomagokat, akkor az OpenVPN-nel ezt egyszerűen ki tudjuk használni. Mint az az előzőekben bemutatásra került, a konfgurációja is igen egyszerű, és a kliens oldali megoldásai is tvannak már olyan széles körűek, mint az IPsec-kel megtvalósítot VPN esetében. Ép-pen ezért részletes konfgurációt nem közlünk, de ajánlunk pár nagyszerű HOWTO-t, amelyek alapján ki lehet építeni egy VPN kapcsolatot az IPsec segítségétvel, ha ez a szoftver szükséges:
– Hitvatalos IPsec Howto224
– Ubuntu LTS+IPsec225
– Ubuntu kliens226
Ma már jellemzően azok tválasztják az IPsec megoldást, akiknek pl Cisco tvagy Windows szertver-rel kialakítot hálózathoz kell csatlakozni, tvagy ezeket az eszközöket kell kliens módban elérni, bár erről hitvatalos statisztika nincs, azonban a fórumok és a keresőmotorok találatai szerint ez a jellemző.
1224. htp://www.ipsec-howto.org/1225. https://help.ubuntu.com/community/IPSecHowTo
1226. https://www.witopia.net/support/setting-up-and-using-your-vpn/ubuntu-linux-ipsec-setup/
146
Közös címtár LDAP segítségétvel
Közös címtár LDAP segítségével
Hasznos információk az LDAP-rólAz LDAP (Lightweight Directory Access Protocol) egy egyszerű, hierarchikus adatbázis elérését
lehetőtvé tetvő protokoll. Nagymértékben az X.500 DAP protokollján alapul, mely túlzot bonyo-lultsága miat nem igazán terjedt el.
Az LDAP egy olyan adatbázis, melyben nagyon gyorsan lehet keresni, rendkítvül rugalmas hite-lesítő és hozzáférés szabályzó rendszere miat nagyon népszerű a címtár és a központi hitelesítés (authentication) és feljogosítás (authorization) területén. Az adatbázisok felépítése miat tviszony-lag egyszerű elosztot adatbázisokat kialakítani. A jelenleg elérhető szertver szoftverek általában támogatják a replikációt (több szertver-másolat automatikus fenntartását) master-slatves, tükör, több master tvagy tvegyes megoldásban is, ezért magas rendelkezésre állású rendszerek építésére kitválóan alkalmas.
Maga a protokoll meglehetősen egyszerű ezért a fejlesztők előszeretetel használják. Megfelelő mélységű megértéséhez először meg kell ismerni néhány alapfogalmat, melyeknek a későbbiek-ben alaptvető jelentősége lesz.
objektum Az LDAP-ban az adatokat objektumokban tároljuk. Minden objektumnek tvan leg-alább egy típusa, melyet it osztálynak netveznek. Ha például egy felhasználói objek-tumot akarok létrehozni, annak az osztálya a "Person" lesz. Egy objektumnak több osztálya is lehet, ekkor az összes osztály lehetséges atribútumai adhatók meg ér-tékként.
osztály Az ~ leírja, hogy az adot tárolandó adatok milyen adatagokból -it úgy hítvják, hogy atribútum- állnak. Az osztály atribútumai lehetnek kötelezőek, ezek megadá-sa nélkül egy objektumot nem lehet feltvenni az LDAP adatbázisba.
atribútum Az ~ alaptvetően egy nétv-típus pár, ezekbe lehet az objektumok adatai pakolni. Az ~ tulajdonsága, hogy egyetlen tvagy több értéket is tartalmazhat. Egy "mail" netvű at-ribútum esetében például ésszerű, hogy több értéke is lehessen, hisz egy személy-nek több e-mail címe is lehet.
hierarchikus adatbázis
Az általánosan elterjedt relációs adatbázisokkal szemben a hierarchikus adatbázisoknem táblákban tárolják az adatokat, hanem fa szerkezetekben, melyeknek az elága-zásai (konténerei) és a letvelei is objektumok. Közismert hierarchikus adatbázis a személyi számítógépek fájlrendszere. Ehhez képest az LDAP-nál minden típusú ob-jektum lehet konténer és letvél egyaránt.
RDN Az RDN (Relatitve Distinguised Name) egy objektum egyedi netve. Minden RDN egy atribútum nétvből, egyenlőség jelből és egy értékből áll. Egy felhasználó objektumá-nak az RDN-je például lehet "[email protected]". Az objektumok RDN-jébe olyan atribútumot kell tválasztani, mely nem okozhat ütközést. A gyakran tválasztot CN (Common Name) nem szerencsés, hiszen a személyek természetes netve nem egyedi.
DN A DN (Distinguised Name) egy objektum teljes elérési útal meghatározot egyedi azonosítója. Ez RDN-ek tvesszőtvel eltválasztot sorozata, ahol jobbról balra minden szinten a tartalmazó konténer RDN-je található, az utolsó elem pedig az objektum RND-je. Íme egy minta: [email protected],OU=admins,O=FSF.hu Ebben az esetben
147
Közös címtár LDAP segítségétvel
a fa alsó szintén az O=FSF.hu szertvezetet jelképező objektum tvan, felete az OU=ad-mins a szertvezeti egység, abban pedig egy felhasználó adatait tartalmazó objektum.
sufx Az aktuális LDAP fa legalsó elágazásának DN-je, ezek alati objektumokat nem tá-rolja az LDAP. A sufx lehet több RDN-ből álló, például ha egy szertveren csak egy szertvezeti egység adatait tárolja a rendszer. Tehát értvényes sufx lehet: OU=ad-mins,O=FSF.hu
userPassword atribútum
Minden LDAP objektumnak lehet egy ~ atribútuma. Ez egy különleges, kiemelt je-lentéssel bíró érték. Ha tvalaki az LDAP szertverhez kapcsolódik, akkor az ebben tá-rolt értéket (mely lehet titkosítás nélküli szötveges is, de általában jelszó hash) hasz-nálja a rendszer a felhasználók hitelesítésére.
bind Az LDAP adatbázis esetén nem a relációs adatbázisoknál megszokot belépést használjuk, hanem bind-olunk az LDAP-hoz. Ez lehet anonymous bind, akkor nem kell jelszótval tvagy más módon hitelesíteni magunkat. Ha nem elegendő az anony-mous jogosultság, akkor egy objektumhoz bind-olunk. Ekkor a klasszikus szóhasz-nálatal a "felhasználó nétv" egy objektum DN-je lesz, a megadot jelszót pedig egy-szerű esetben az adot objektum userPassword mezőjében tárolt értékkel ellenőrzi le az LDAP szertver.
struktúra Az LDAP-ban tárolt adatok térképét netvezzük az LDAP struktúrájának. It tehát le tvan írtva, hogy a sufx alat milyen konténerek találhatók, azok mire szolgálnak, mi-lyen konténerek tvagy objektumok találhatók bennük. Szerencsés egy-egy konténer-ben azonos típusú objektumokat elhelyezni (bár erre semmi nem kötelez). A struk-túra leírása tartalmazza a konténerek és a tartalmazot objektumok osztályait is. Ha azok nem szabtványos osztályok, akkor azt is le kell írni, hogy hogyan épülnek fel.
séma Az LDAP szertverek a szabtványos és az egyéni atribútumok és osztályok leírását is az LDAP sémában tartják. Innen lehet megnézni, hogy egy-egy osztály milyen le-hetséges atribútumokat tartalmazhat, illettve it lehet saját célra speciális atribútu-mokat és osztályokat defniálni.
OID Az OID (Objektum ID) egy egyedi azonosító, mely minden atribútumnak és osz-tálynak kötelező tulajdonsága. Egy példa OID: 2.5.6.7 Ez a szertvezeti dolgozó osztá-lyának (organizationalPerson) a szabtvány azonosítója.
Az OpenLDAP szerverSzámos szabad szoftver LDAP szertver elérhető. Ezek közül kiemelkedik múltjátval, fejlesztői hoz-
záértésétvel (számos szabtványt ők írtak), jó dokumentáltságátval, nagy méretű közösségétvel az OpenLDAP.
TelepítéseAz OpenLDAP szertver telepítéséhez Ubuntu 12.04 LTS szertven a slapd csomagot tegyük fel. A
későbbiekben nagyon hasznos kiegészítő lesz az egyik LDAP parancssoros eszközkészlet, ez az ldap-utils csomagban található. Tehát:
$ sudo apt-get install slapd ldap-utils
A telepítés közben a rendszer megkérdezi az LDAP adminisztrátor jelszatvát. Ezt nagy körülte-kintéssel tválasszuk meg, nem jatvasoljuk a "test" jelszót, hisz a szertver telepítés után azonnal elér-hetőtvé tválik. Ezt a kötvetkező paranccsal ellenőrizhetjük le :
148
Közös címtár LDAP segítségétvel
$ sudo netstat -tnlp | grep ':389'tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 2388/slapdtcp6 0 0 :::389 :::* LISTEN 2388/slapd
Amint az látszik, az OpenLDAP IPtv4 és IPtv6 protokollt is használ, az alapértelmezet TCP portja a 389. Ha a tvédetebb LDAPS protokollt használjuk, akkor annak szabtványos portja a TCP/636.
Az LDIF fájlformátumAz LDIF az LDAP adatok egyszerű szötveges áttviteli formátuma. Formálisan az RFC 2849-ben
tvan leírtva. It most egy rötvid összefoglaló kötvetkezik. Egy rötvid LDIF így néz ki :
dn: cn=operators,ou=pam_group_db,ou=Accounting,ou=IT_Systems,o=Funovesztoobjectclass: topobjectclass: posixGroupcn: operatorsgidnumber: 20003memberuid: kovacsgmemberuid: ...dn: cn=kovacsg,ou=Unix_groups,o=Funovesztoobjectclass: topobjectclass: posixGroupcn: operatorsgidnumber: 10001memberuid: kovacsgdn: uid=kovacsg,ou=pam_user_db,ou=Accounting,ou=IT_Systems,o=Funovesztoobjectclass: topobjectclass: personobjectclass: posixAccountobjectclass: shadowAccountobjectclass: inetOrgPersoncn:: S292w6FjcyBHw6Fib3IKgecos: kovacsiuidnumber: 10001gidnumber: 10001homedirectory: /home/kovacsgloginshell: /bin/bashmail: [email protected]: -1shadowflag: 0shadowinactive: -1shadowlastchange: 10877shadowmax: 999999shadowmin: 0shadowwarning: 7sn:: S292w6Fjcwo=uid: kovacsguserPassword: {SSHA}FArIZeiW4NCN09Xx/lSGgEw/0LKrQo4nusercertificate;binary:: SGEgZXp0IGRla8OzZG9sdGFkLCBha2tvciBqw7MgYXJjIGxlaGV0 c3ouIEV6dCBheiDDvHplbmV0ZXQgYXR5YSBoYWd5dGEKMjAxMy0xMS0wOC3DoW4uIERvYmogZWd5 IG3DqWx0LCBob2d5IMO2csO8bGplaywgdm9sdCBpbHllbiBib2xvbmQgOkQKSWRlOiBtYXRvLnBl dGVyQGdtYWlsLmNvbQpIYSBlenQgZGVrw7Nkb2x0YWQsIGFra29yIGrDsyBhcmMgbGVoZXRzei4g RXp0IGF6IMO8emVuZXRldCBhdHlhIGhhZ3l0YQoyMDEzLTExLTA4LcOhbi4gRG9iaiBlZ3kgbcOp
149
Közös címtár LDAP segítségétvel
bHQsIGhvZ3kgw7Zyw7xsamVr ...
Minden LDAP objektum egy üres sorokkal határolt összefüggő rész, mely megnetvezés érték pá-rokból áll. Az első sor kötelezően az objektum DN-je. Ez után tetszőleges sorrendben annak atri-bútum-érték párjai. Az objektum típusát meghatározó osztály meghatározások azonos módon kerülnek be, mint az általános értékek, a netvük "objectclass".
Az LDIF fájlban minden nem ASCII karaktert base64 kódolni kell. Ha kézzel kell ilyesmit csi-nálnunk, akkor használhatjuk a coreutils csomag base64 parancsát, mely alapértelmezeten bekó-dol (encode), -d paraméterrel tvisszakódol (decode). Ilyen baes64 sztring látható Kotvács Gábor felhasználói objektumának a cn, sn és usercertifcate mezőjénél. Ezek közül az utolsó nem egysze-rűen utf8 karaktereket tartalmaz (mely egyébként általában az LDAP belső sztring formátuma, ígyaz ékezetekkel nem kell szentvedni), hanem egy bináris adat. Ezért tvan megjelöltve a ";binary" jel-zéssel. Amint az látszik, a base64 kódolt adatoknál a megnetvezés után kető darab ketőspont tvan.
Az LDAP adatbázist tvagy annak tvalamilyen szűrt részét könnyedén el tudjuk menteni LDIF fájl-ba az ldapsearch parancs tvagy tvalamilyen LDAP GUI segítségétvel. A legtöbb GUI képes adatok tvisszatöltésére is. Erre szintén használhatók a slapd tvagy az ldap-utils csomag parancsai, melyet a későbbiekben tárgyalunk.
Az LDIF formátum nem csak az adatok tárolására képes, hanem módosításokat is le lehet írni benne. Ekkor a DN után egy módosítás típus és a módosítás leírása kerül be. Ha a módosítás típu-sa tváltoztatás, akkor több tváltoztatás is bekerülhet, mindegyiket egy mínuszjel zárja. Így néz ki egy összetet LDAP módosítás LDIF-ben:
dn: uid=kovacsg,ou=pam_user_db,ou=Accounting,ou=IT_Systems,o=Funovesztochangetype: addobjectclass: topobjectclass: personobjectclass: posixAccountobjectclass: inetOrgPersoncn:: S292w6FjcyBHw6Fib3IKgecos: kovacsiuidnumber: 10001gidnumber: 10001homedirectory: /home/kovacsgloginshell: /bin/bashsn:: S292w6Fjcwo=uid: kovacsgdn: uid=kovacsg,ou=pam_user_db,ou=Accounting,ou=IT_Systems,o=Funovesztochangetype: modifyadd: mailmail: [email protected]: [email protected]: mailmail: [email protected]: mailmail: [email protected]: [email protected]: [email protected]
150
Közös címtár LDAP segítségétvel
delete: mail-dn: uid=kovacsg,ou=pam_user_db,ou=Accounting,ou=IT_Systems,o=Funovesztochangetype: remove
A fenti példában először hozzáadunk egy objektumot, majd módosítjuk azt a kötvetkezőképpen. Hozzáadunk két e-mail címet, töröljük az egyiket, majd lecseréljük az aktuális állapotot három új e-mail címre, tvégül töröljük az összes e-mail címet, melyet a mail mezőben tárol az LDAP. Ez utána kötvetkező LDIF módosítás az előzőleg feltvet objektum törlése. Ezeket a módosításokat LDAP protokollon keresztül tudjuk a szertveren eltvégezni az ldap-utils csomag ldapmodify parancsának segítéségétvel.
Alacsony szintű műveletek az adatbázissalFeltöltés LDIF-ből
Miután az OpenLDAP beállításait eltvégeztük, eltvégezhetjük az adatbázis feltöltését a kezdőada-tokkal. Ha azok a rendelkezésünkre állnak LDIF formátumban. Erre haszálható az OpenLDAP sla-padd parancsa. Ez köztvetlenül írja a szertver adatfájljait, így értelemszerűen leállítot állapotban, általában üres adatbázis feltöltésére használjuk. Több tízezer objektum kezdő feltöltésénél érdemesaz OpenLDAP adatbázisát (/tvar/lib/ldap) áthelyezni egy erre a célra létrehozot, megfelelő méretű tmpfs alá, mert így radikálisan felgyorsul az egyébként elég lassú műtvelet.
Kiírás LDIF formátumba
Az OpenLDAP adatbázisát kétféleképpen lehet elmenteni LDIF formátumba.
Akár másik fajta szertveren is használható adatátadásra kész állapotban lementhető LDIF fájl for-mátumban az ldapsearch segítéségétvel. Ha ezt helyi gépen használjuk, megfelelően feljogosítot felhasználótval, akkor az összes adatot nagyon gyorsan kiírja fájlba. Mitvel azonban ez LDAP proto-koll-t használ és a szertver működő állapotát kérdezi le, így – ha az adatok közt összefüggések tvannak, és épp egy nagyobb írás közben mentjük le az adatbázist, akkor inkonzisztens lehet az eredmény. Mégis nagy előnye, hogy az eredmény szertver típus független, és nem kell hozzá leál-lás. Ekkor azonban nem minden speciális információ kerül bele az LDIF-be, ami az OpenLDAP szertveren tárolódik.
Fájl szintű mentés, helyreállítás
Ha a konfgurációs állományban átállítotuk a szertver adatbázisának helyét (kezdőnek nem ja-tvasolt), akkor gond lehet a MAC tvédelmi rendszerek beállításai miat (Apparmor, SELinux stb., disztribúció függő). Ha egy adatbázisunk tvan (ez a tipikus), akkor jobban járunk, ha azt az alapér-telmezet helyen hagyjuk.
Ubuntu 12.04 LTS alat az OpenLDAP adatbázis alapértelmezeten a /tvar/lib/ldap könytvtárban található. Ha ezt az LDAP szertver leállítot állapotában teljes egészében elmentjük, akkor később ezt az állapotot könnyedén tvissza tudjuk majd állítani. Akár egy másik szertveren is (például a rep-likáknál lehet ez a kezdő adatfeltöltési módszer, és akkor nem kell nekik órákig húzgálni a sok tíz-ezer objektumot a hálózaton át…). Egy teljes leállítás, cp -ra majd újraindítás néhány tízezer objektumig másodpercek alat eltvégezhető, ha nincs semmi olyan kritikus rendszer, melynek fo-lyamatosan szüksége tvan az LDAP-ból adatokra, akkor ezt naponta, hajnalban gond nélkül el le-het tvégezni.
151
