Ez az interjú része egy cikksorozatnak, amelynek célja, hogy bemutassa azokat a fejlesztőket, akik azért dolgoznak, hogy mi felhasználók jobban kihasználhassuk számítógépünk képességeit, teljesítményét. Azokról a fejlesztőkről szól akik megszállottjai, hívei az ``open source spirit"-nek. Az interjúsorozat mai alanya Kadlecsik József, az iptables egyik fő fejlesztője.
trey: Mondanál néhány szót magadról (iskolák, család), a szabad szoftverekkel kapcsolatos munkásságodról?
K.J.: Kadlecsik József vagyok, az ELTE-n végeztem, mint fizikus. A feleségemmel a budaörsi úti koliban ismerkedtünk meg, ő orosz-töri szakon végzett, de azóta elvégezte a német szakot, és most szótárakkal foglalkozik. Van két fiunk, az egyik hat éves lesz, a másik fél éves. A szabad szoftverekről később még lesz szó... :-)
trey: A KFKI-nál dolgozol. Mivel foglalkozik ez az intézet, és Neked mi a feladatod ott?
K.J.: Olyan, hogy KFKI (Központi Fizikai Kutatóintézet) már jó néhány éve nem létezik. Van egy KFKI telephely, amely otthont ad öt független kutatóintézetnek. Ezek közül az egyik a KFKI Részecske és Magfizikai Kutatóintézet (KFKI RMKI), amelyhez az összes telephely fő számítógépes és hálózati infrastruktúrájáért felelős Számítógép Hálózati Központ (SZHK) is tartozik. Utóbbinak vagyok a főosztályvezető helyettese.
Az RMKI nevéből fakadóan elsősorban részecskefizikával foglalkozik, de vannak anyagtudománnyal, plazmafizikával, biofizikával, űrkutatással, elméleti fizikával és más fizikai ágakkal foglalkozó osztályok, csoportok is. (A KFKI telephelyén lévő kísérleti reaktor kezelése és az azon folyó munkák egy másik intézethez, az ATKI-hoz tartoznak) Az intézetnek igen erős a CERN-nel való kapcsolata, sok csoport és sok kolléga vesz részt CERN-beli kísérletekben. Kis adalék, hogy a hazai Internet egyik első nemzetközi kapcsolata az (akkor még létező) KFKI-t a CERN-nel összekötő 6400 baudos bérelt vonal volt. (A csatlakozópont még mindig megtalálható a 3-as épületben - emléktábla kellene mellé :-)Az SZHK felel a telephelyi belső gerinchálózatért és a külső kapcsolatokért. Mi felelünk néhány - SPARC/Solaris és Intel/Linux alapú - szervergépért, amelyek a központi DNS, mail, interaktív bejelentkezés, stb. szolgáltatásokat nyújtják. A hálózatbiztonság első vonalat is mi alkotjuk, amelyet az RMKI és a telephely hálózatbiztonsági felelőseként én vezetek.
trey: Mikor kezdtél el a Linuxszal foglakozni?
K.J:: 1994 elején én installáltam az első Linuxot az intézetben a saját asztali gépemen. Ahogy az elején említettem, eredetileg fizikus vagyok, és általános relativitáselmélettel foglalkoztam. Reduce számítógépes algebrai nyelv alá írtam Rlispben egy szimbolikus tenzort-algebrai csomagot. Ezen dolgozván '92-93-ban egy évet Bonn mellett a GMD-ben (Gesellschäft für Mathematik und Datenverarbeitung) töltöttem. Ott találkoztam először Unixszal (SPARC/Solaris). Mielőtt hazautaztam volna, elég sokat keresgéltem a hálózaton, főként Usenet csoportokat olvasgatva, hogyan lehetne PC-n UNIX-ot installálni és futtatni. Akkor még csak egyetlen comp.linux csoport volt, elég könnyen rá lehetett találni. Mehettem volna BSD felé is, de a Linux sokkal élőbbnek tűnt, a hírcsoport sokkal pezsgőbb volt. Akkoriban kezdte az SLS mint vezető disztribúció elveszíteni a szerepét és helyette a Slackware kezdett följönni. Harminc-egynehány floppyn :-) hoztam haza '93 karácsonya előtt.
Közben '93 nyarán installáltak egy SPARCCenter 2000 számítógépet Solaris 2.3-mal (szerencsére a 2.2-esből kimaradtunk) az SZHK-ban, és visszajőve egy új nagy szervergép állt "előttem". A kollegák VAX/VMS-en nőttek föl, így számukra a UNIX talán ismeretlenebb volt, mint számomra. Valahogy adódott, hogy én telepítettem és installáltam a fordítókat, interpretereket, szerver és kliens programokat. És lassan fizikusból teljesen átvedlettem rendszergazdává és számítástechnikussá :-).
trey: Fejlesztői és felhasználói szemmel nézve mik a főbb eltérések az akkori (amikor kezdted), és a mostani Linux kernel között?
K.J.: Felhasználói szemmel a felszínen igaziból nincs olyan nagy különbség. Már akkor voltak hatékony shellek, már akkor régen létezett az XFree86. Ugyan úgy használhattam grafikus felületet, mint most. De a web még nem létezett (azt akkor már kitalálta Tim Berners-Lee a CERN-ben, de a gopher jóval ismertebb volt). Fejlesztői szempontból akkor még nem voltak kernel modulok. És mendemonda tárgya volt, hogy vajon mennyire komolyan gondolja Linus, hogy a Linux kernel verziószáma soha nem fogja elérni az 1-et, hanem mindig végtelenül közelíteni fogja alulról :-). Igazából a kérdést nem tudom jól megítélni - akkoriban sima mezei felhasználó voltam, nem dolgoztam a kernellel.
trey: A honlapodat nézegetve láttam, hogy több fejlesztői projected is van. Beszélnél ezekről?
K.J.: Négy "projektem" van, azok közül valójában kettő élő.
Egy időben nagyon foglalkoztatott az SRP (Secure Remote Password) protokoll, amely sajnos nem tudott elterjedni. Amerikában írott szoftverként a kriptológiai részét hivatalosan nem lehetett letölteni, ezért a skeleton kripto libraryjét összehoztam az SSL kripto libraryjével. Szerintem soha senki nem használta, de jó gyakorlat volt.
Az smstart a maga korában érdekes lehetett. Akkoriban még a sendmail volt az egyeduralkodó MTA, és nagyon utaltam, hogy rootként kell futtatni, ismervén a sendmail biztonsági lyukakban gazdag múltját. Azt akartam, hogy a sendmail futhasson közönséges userként, és ehhez az inn (news szerver) példáját vettem: ott is van egy nagyméretű, monolitikus program, amelyet csak azért kellene rootként indítani, hogy egy 1024 alatti portot megnyithasson. E helyett van egy picike innstart program, amelyik megnyitja a megfelelő portot, átvált a news userré és elindítja az inndt. A megnyitott file-descriptort argumentumban passzolja át. Az smstart és a patchelt sendmail ugyan ezt tudta: annyiban volt érdekesebb a dolog, hogy a sendmail néha újra akarja nyitni a portot és nem csak ezért van szükség a root jogra. Amíg nem létezett postfix, addig karbantartottam és frissítettem. A postfix megjelenésével "hivatalosan" lezártnak és okafogyottnak tekintem az smstartot.
A két élő projekt, amelyeken jelenleg dolgozom a per user uce patch a postfixhez és a netfilter/iptables.
trey: 2001. december elején megírtam a portal.fsn.hu-n, hogy a netfilter core team tagja lettél. Hogyan kezdtél el foglalkozni a netfilterrel? Mi a területed, feladatod a csapatban?
K.J.: Elég régóta keresgéltem egy jó tűzfal csomagot Linuxra. Az ipchains nem volt az, az spf ígéretes volt, de soha nem vált elterjedtté, sikeressé. Amikor a netfilter megjelent, elérhetővé vált és bele tudtam nézni, nagyon felkeltette az érdeklődésemet. Elkezdtem patcheket, javításokat írni, megpróbálni elérni, hogy azok bekerüljenek a rendszerbe, és lassan egyre jobban belefolytam a munkába.
A csapatban nincsen felosztás, hogy ki mivel foglalkozik - az érdeklődési kör határozza ezt meg. Egészséges anarchia van :-). Aki épp a legaktívabb egy területén, az foglalkozik azzal és viszi előre. Engem mindig is a connection tracking és a netfilter stateful része érdekelt, jelenleg is azon dolgozom.
trey: Hogyan kerül be egy magyar fejlesztő egy ilyen csapatba?
K.J.: Megpróbáltam előrébb vinni egy projektet és meglehetősen sokat dolgoztam rajta. Az Enshcedeben a Linux Kongress előtt tartott netfilter workshopon személyesen is megismerhettük egymást a core team tagjaival és a legaktívabb patch-írókkal - utána hívtak meg a core team-be.
trey: Rendszeresen készítesz Postfix patcheket is. Ennek mi az oka? Felhasználói elégedetlenség, vagy csak bugfixek készítése?
K.J.: Fogós kérdés! IMHO jelenleg a postfix a patch nélkül is a legjobb MTA. Nekem a KFKI telephely sajátosságai miatt extra funckionalitásra volt szükségem, és mivel Wietsenek épp elég dolga van az egész rendszerrel, ezért megírtam magam a szükséges részeket. Ebből lett a per user uce patch. Mások is elkezdtek használni, kértek új funkciókat, így egyre nőtt. Mára nagyjából elérte a felső határát: tovább bővíteni már nem érdemes. Én azt várom, hogy postfix smtpd szétválik egy smtpd/policyd párosra, és a most az smtpd-be zsúfolt funkcionalitás bekerül majd a policyd-be. Mi a patchet egy maximálisan konfigurálható spam szűrőként használjuk: bármely felhasználónk választhat, hogy mely feltételek alapján akarja a spameket kiszűrni (az SMTP HELO/EHLO nevének szintaxisa, DNS-beli regisztráltsága, az SMTP kliens DNS-beli regisztráltsága, saját telephelyi tiltólisták, RBL-szerű tiltólisták, stb., stb., stb.). Ezen felül, ha valaki akarja, a tiltófeltételei ellenére beengedhet (kivételeket tehet) E-mail címekre vagy akar egész domainekre. A felhasználók egy web-felületen állíthatják a feltételeiket/kivételeiket és napi összesítőt kapnak a kiszűrt levelekről, hogy könnyedén reagálhassanak, ha egy fontos partnerüket véletlenül kitiltottak.
trey: Beszéljünk kicsit az iptablesről. Azt mondják, hogy az iptables kódja kicsit monolitikusra sikerült. Jelen pillanatban az egész egy nagy memóriablokkban helyezkedik el, pl. az összes egyezések, targetek a láncok rulesetjei egy táblában vannak. Mi a véleményed erről? Kell ezen változtani? Vannak erre törekvések?
K.J.: A fogalmazást hogy monolitikus, szerencsétlennek tartom. Szerintem mind a netfilter, mind az iptables nagyon jól modularizált. Húsz fölött van a mainstream kernelben lévő matching/target/helper modulok száma, a patch-o-maticben pedig 70 (!) fölött van az új funkcionalitást, modult tartalmazó patchek száma. Tulajdonképpen meglepő, hogy ezek közül milyen kevés ütközik, ami a jó modularitást igazolja.
Amire Te gondolsz és a harmadik mondatodban írod is az az, hogy a kernelben az összes szabály és tábla egyetlen memóriablokkban van és a netfilter egyszerű pointer műveletekkel "közlekedik" a láncok és szabályok között. Ez egy kompakt memóriablokkot eredményez, de hátrány, hogy nem lehet láncot/szabályt egyszerűen hozzáadni: az iptables lekéri a kerneltől az élő szabályokat, elkészíti az *egész* új táblát mint memóriablokkot, átadja a kernelnek és az a régit helyettesíti az újjal. Mindez néhány száz szabály fölött egyre lassabbá teszi az új szabályok hozzáadását (törlését/módosítását). Erre egy workaround az iptables-save, iptables-restore, amelyekkel el lehet menteni és egy lépésben visszatölteni egy működő, teljes konfigurációt. Nyilván workaround, ezért a 2.5-ben várhatóan áttérünk láncolt listák használatára.
trey: Az iptablest használóknak sokszor meggyűlik a bajuk az IRC, RealAudio és egyéb galád dolgok használatával =). Úgy hallom dolgoztok egy newnat API dolgon amely segít enyhíteni ezt a problémát. Beszélnél erről?
K.J.: A netfilter/iptables több szempontból is óriási előrelépés az ipchainshez képest: ezek közül az egyik, hogy képes stateful csomagszűrésre. Azaz elegendő egy kapcsolatot *kezdeményező* csomagot engedélyeznem, a kapcsolathoz tartozó összes többi, bármely irányból jövő csomagot egyetlen további szabállyal engedélyezni tudom:
... -m state --state ESTABLISHED -j ACCEPT
Bonyolultabb protokollok azonban segéd-kapcsolatokat is használnak, amelyeknél a "szerverport" egy random port valahol 1024 fölött. Ilyen például az FTP-nél az adat-csatorna (dir/ls/get/put), vagy IRC-nél a DCC kapcsolatok, stb. A netfilternél ezekhez a protokollokhoz léteznek helper modulok, amelyek értelmezik a protokollt és a szükséges segéd-kapcsolatok fogadására felkészítik a rendszert. Ezek után többé nincs szükség az összes 1024 fölötti port nyitvahagyására, az összes ilyen kapcsolatot egyetlen szabállyal engedélyezni lehet:
... -m state --state RELATED -j ACCEPT
Azonban az eredeti netfilternél bármely protokoll esetén csak egyetlen segédkapcsolatra lehetett felkészülni, pedig léteznek olyanok protokollok is, amelyeknél több kapcsolatra kell egyidejűleg várni. Például több IRC DCC parancsot lehet kiadni anélkül, hogy várnánk az első felépülésére. Vagy a netmeeting (H.323) szinten több parallel audio és video csatornát használ. Ezeket az eredeti netfilterrel nem lehet kezelni. Félreértés ne essék: például egymás *után* természetesen több DCC parancsot le tudott kezelni, ha az adatcsatornák felépülését megvártuk:
DCC SEND ...
DCC SEND ...
Amit nem volt képes kiszolgálni, az a következő:
DCC SEND ...
DCC SEND ...
A newnat API lényege, hogy lehetővé tesszük, hogy egy protokollnál több segédcsatornára tudjon fölkészülni a rendszer.
A newnat API-t is figyelembe véve jelenleg a következő protokollokat tudjuk kezelni: FTP, IRC, talk (talk/ntalk/ntalk2), tftp, PPTP, H.323 (point-point kapcsolat esetén).
trey: Jelenleg az iptables a kernelspace-ben működik, nyilván hogy gyors legyen. Hallottam olyan törekvésekről, hogy userspace iptables. Ez mi is tulajdonképpen?
K.J.: A netfilterben elejétől fogva benne volt az a lehetőség, hogy bármely csomagot átadjon egy UP-ben futó processznek és onnan (később) visszakapva azt továbbítsa (vagy eldobja). Ez lehetőséget ad arra, hogy a kernelbeli részt tetszőleges UP-beli processzel egészítsük ki. (A forrásban több helyütt lehet olvasni, hogy az a rész lehetne a user space-ben is :-) Jelenleg az ULOG targeten kivül ez a lehetőség nincs még kihasználva.
trey: Készülőben van az iptables2. Miben lesz ez különböző, mint az elődje? Megtudhatunk erről valamit?
K.J.: Az iptables/netfilter egy remekül bővíthető rendszer. Minden új netfilter kiterjesztéshez a szerzőnek meg kell írnia a hozzá tartozó másik felet, egy iptables kiterjesztést. A jelenlegi interface-ben ezek az UP-beli kiterjesztések igen szorosan kötődnek a parancssor értelmezéséhez. Ez nehézségeket és problémákat okoz, amint valaki nem az iptables frontend segítségével akar szabályokat generálni. Ezért egy új interface készül, amelyik elrejti majd a kiterjesztéseket az alkalmazás elől és a kernel-kommunikációt több interface fogja majd támogatni (libiptc,
libnfnetlink).
trey: Az iptables a Linux csomagszűrője. Mennyire követed figyelemmel más rendszerek törekvéseit ezen a területen? Gondolok itt a multiplatformos IPF-re és az OpenBSD-s PF-re. Vesztek át egymástól ötleteket? Van valamiféle kontaktus más rendszerek fejlesztőivel?
K.J.: A TCP window trackinget az IPF-ből vettük át :-). De komolyabban véve a kérdést: valamilyen szinten követjük egymás munkáját, de egyáltalán nincs feature-war. Az erre való akar burkolt biztatást nem nagyon szeretjük ("ez és ez benne van az x szoftverben, az iptables miért nem tudja?")
trey: Ha jól tudom Rusty Russel a iptables fejlesztésének az irányítója. Ha nem létezne az iptables, és Te most kezdenél neki megalkotni, mit csinálnál máshogy?
K.J.: Én eleve láncolt listákban tárolnám a szabályokat.
trey: Ahogy a Linux kernel fejlődik, úgy változik a csomagszűrő is. Sokakban felmerül a kérdés, hogy miért hoz minden nagyobb Linux kernel release újabb kódot? Arra gondolok, hogy 2.0-as kernelben a FreeBSD-s IPFW portja volt, majd a 2.2-esben az ipchains, a 2.4-esben pedig az iptables. Mi a véleményed erről a dologról?
K-J.: Az IPFW port Alan Coxtól már az 1.1-ben benne volt. Azt javította föl Jos Vos a 2.0-ban (ipfwadm), majd - még mindig erre alapozva - írta át Rusty a 2.2-ben (ipchains). A 2.4 teljes szakítás az eredeti kóddal, abból semmilyen rész nem maradt benn a kernelben.
Ez lényegében egy természetes fejlődés volt, minőségi ugrásokkal. Nem hiszem, hogy a lépcsők kihagyhatok lettek volna.
trey: Használsz más rendszert is a Linuxon kívül?
K.J.: Igen, SPARC/Solarist. Időnként a kollégáim gépein látok Windowst is.
:-)
trey: Fejlesztéseid során milyen eszközökkel dolgozol? Gondolok itt a hardverre és szoftverekre.
K.J.: Az asztali gépem egy Athlon, az általában a külső tesztelő gép szerepet játssza, ha UML valamilyen okból nem használható. Van egy Pentium III-as laptopom, azon fejlesztek. Különösebb szoftvereket nem használok: editorok (joe, vi, mikor hogy), make, gcc, gdb, UML, célprogramok tetszőleges csomagok generálására. Csupa fapados eszköz :-).
trey: Amikor nem dolgozol, nem kódolsz, mivel töltöd az idődet?
K.J.: A gyerekeimmel, a családommal. A nagyobbik imád kirándulni: lassan a polcai már alig bírják az értékes kavicsok és kövek súlyát. A kagylóhéj-gyűjteménye is kiemelkedő, nem beszélve a törött cserepekről. :-) Az egyik "ritkaság" egy a kertben kiásott rozsdás, régi, nagyméretű kulcs - a hozzá tartozó kincsesládát még nem találtuk meg, de minden tavasszal lelkes kutatómunka folyik :-)).
trey: Több fejlesztővel is beszélve meglepődve láttam, hogy egyik sem az "otthon sötétben kódoló, soha ki nem mozduló típus". A honlapodon láttam, hogy Te is természetszerető ember vagy, szívesen jársz erdőkben, vagy ha teheted kajakozol. Mi volt a legnagyobb kalandod eddig?
K.J.: Egy Rabá-túrán kajakkal majdnem lecsorogtunk a feleségemmel egy kövekből épített duzzasztón. Ha jobban elbambulunk, akkor tényleg veszélyes lehetett volna.
Még mielőtt a Szigetközt feldúlták, részt vettünk egy Szigetköz-kerülésen: Győrből föl a Mosoni-Dunán, aztán az Öreg-Dunán vissza, de ahol csak lehet, bemenni az ágakba. Az egyiknél felfedeztünk egy víz alatti forrást, amitől a víz hőmérséklete az ágban a vele kapcsolatban lévő Dunáéhoz képest legalább 5-8 fokkal hidegebb volt. Azóta sem találkoztunk ilyennel.
trey: Úgy tudom, hogy jelenleg Svájcban vagy a CERN-nél. Mit csinálsz ott, most is dolgozol?
K.J.: A HEP (High Energy Physics) közösségbe tartozó intézeteknek mint a CERN, DESY, Fermilab, SLAC, Rutherford Lab, stb., több közös szervezete és bizottsága van. Az egyik ezek közül a HEPCCC (HEP Computing Coordinating Committee), amelynek van egy HTASC (HEPCCC Technical Advisory SubCommittee) nevű technikai tanácsadó albizottsága. Ennek a munkájában veszek reszt Magyar CERN Bizottság képviseletében. Évente két-három alkalommal találkozunk, általában a CERN-ben. A munka a legfőbb számítástechnikai kérdések számbavételéből és felméréséből áll. A mostani ülés legfontosabb pontjai a biztonsági kérdések (tűzfalak, biztonsági policyk és az autentikációk, roaming userek, VPN-ek egymással való kapcsolata) és az AFS jelene/jövője volt (a HEP közösség szinte kizárólagosan AFS-re támaszkodik, alapvető fontosságú szolgáltatás).
trey: Mi az amit egy kezdő hackernek javasolni tudnál? Hol kezdjen hozzá a dolognak?
K.J.: Válasszon ki egy létező, számára érdekes, izgalmas területet és ássa bele magát. Kövesse nyomon a fejlődését, majd próbálja jobbítani a már létező eszközöket. Aztán ha az nem az ő ízlésének megfelelő irányba megy, akkor kezdjen neki egy újnak, jobbnak :-).
trey: Esetleg szeretnél még valamit elmondani ami nem szerepelt a kérdések között?
K.J.: Ha egy tipográfus véletlenül olvasna ezt a cikket, és tenni szeretne valamit a free szoftverek és a Linux hazai jobb elterjedéséért, akkor előtte nagy lehetőségek állnak: készítsen minőségi ISO Latin 2 fontkészleteket és tegye közkinccsé azokat a lehető legtöbb formátumban úgy, hogy ugyanazokat a fontokat lehessen használni konzolon, PostScriptben, (La)TeXben, X-ben, StarOffice és leszármazottaiban egyaránt. Hú de jó is lenne...
Üdv,
Józsi
--
E-mail : kadlec@sunserv.kfki.hu, kadlec@blackhole.kfki.hu
PGP key: finger kadlec@sunserv.kfki.hu | WWW: http://www.kfki.hu/~kadlec
Address: KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
