Aki nem tudja, mi az az OpenWRT, annak úgysem lehet érdekes ez a blog, úgyhogy nem részletezem, mi az.
Szándékaim szerint, itt rögzítem azt a küzdelmet, amelyet egy tplink routerrel és a rá telepített OpenWRT-vel folytatok annak érdekében, hogy egy mini szervert készítsek belőle, aztán kukázzam az egészet (legalábbis a beleölt munkát) és vegyek egy normális szervert. Mit értek szerver alatt? Egy caching proxy-t, ami reklámblokkolónak is jó (squid volt betervezve), egy logszervert (tervek szerint syslog-ng3), egy mini web szervert, aminek a feladata kb. kimerülne a semmiben, de jó, ha van :) és egy FreeRADIUS-t, hogy végre a wifi-m ne jelszóval, hanem tanúsítvánnyal tudjon authentikálni. Korábban már volt valami hasonlóm egy másik routeren és Tomato + entware felhasználásával. Sajnos az entware-es squid bugos volt, túl sűrűn resetelte magát a router miatta, meg hardveresen is valamivel gyengébb volt, ezért nem is foglalkoztam vele mélyebben.
Első menet. Korábban a Barrier Breakert használtam, de megjelent a Chaos Calmer és én azonnal váltottam. Mert újabb, új a kernel, csak jobb lehet. Vettem először egy pendrive-ot, hogy jó lesz az diszknek, aztán sürgősen éltem az elállási jogommal, mert a pendrive (Sandiskből valami 32GB-os, ultra pici példány) pusztán attól, hogy húsz percet eltöltött a routerben, tűzforró lett, szó szerint megégette az ujjam, mikor kivettem. Ha valakit érdekel, talán még meg tudom keresni a pontos típust, nehogy feleslegesen vegye meg még valaki. Most van egy külső, USB házba szerelt 120G-s SSD-m, ami alig volt drágább az említett pendrive-nál, viszont a S.M.A.R.T. működik benne és nem melegszik. Anyázás már itt indult, mert vettem hozzá új házat, de abban nem működött a S.M.A.R.T. adatok lekérdezése, a régiben meg az SSD TRIM nem megy. Na, döntsem el, mi a fontosabb, úgy döntöttem, a TRIM mégis inkább kell, mint az állapot, úgyhogy vissza az új házba. Szerencsére vannak olyan mazochista hajlamaim, hogy ha valami nem megy, hajlamos vagyok addig erőltetni amíg vagy elindul vagy tönkremegy :D Most az előbbi jött be: smartctl -A -d sat /dev/sda parancs szükséges a lekérdezéshez. Hogy erre hogy jöttem rá, az örök rejtély marad számomra. Nem kicsit voltam dühös... na jó, egy dolgon túl vagyok, jöhet a lényeg.
Először is az OpenWRT extroot, hogy legyen hová tenni cache-t, logokat stb. Csinálom a leírás szerint (nagyjából), épp csak a "block detect >/etc/config/fstab" után sürgősen újraformáztam a partíciót és elfeledkeztem arról az apróságról, hogy ez a nyomorult UUID alapján mountol, az mkfs.ext4 viszont újat ad neki. Úgyhogy rövid anyázás után ("faszé' nem megy ha a leírás alapján csinálom?"), kiszúrtam a megváltozott UUID-t, újabb block detect, reboot és juhéééé! Máris 50GB-om van a router pár megabájtja helyett. Eddig heppi.
És itt kezdődött az a folyamatos anyázásom az openwrt fejlesztői irányába, ami azóta sem szűnik és ezt a blogot ihlette. Mert ha már belekezdtem, végigcsinálom, szerver lesz a routerből, ha beledöglök is, de....
1. Hol a 'csába vannak olyan programok, mint syslog-ng3, netstat-nat, whob és még a halál tudja, hány, gyakran használt segédprogram? Ja... nincs maintainerük, így már a Barrier Breakerben is az oldpackages könyvtárban voltak csak elérhetőek. Még szerencse, hogy a többségük a BB repoból gond nélkül települ, szóval a dolog nagyja ezzel letudva, bár itt már kezdett gyanússá válni, hogy ebből éles szerver nem lesz.2. Kezdeném a squid-del... kicsit megváltozott a korábbihoz képest. Régebben egy kulturált, felkommentezett konfigja volt, most meg odahánytak egy pár soros default konfigot, kommentek nélkül, aztán ha kell valami, akkor kezdd bányászni a doksiból. Jó, hogy szuvenire nyihuhu, nyikukucsku protku, na de azért... és bizonyos paraméterek nem működnek igazán. Pl. a logjait syslog szerverre akarom küldeni, a doksi szerinti formában adom meg, ez meg közli, hogy nem tudja megnyitni a "syslog:daemon.debug" fájlt. (ilyen formátumban kéri a specifikációt, ha syslog-ra küldöm). Másik lognál meg valami /usr/lib/logfile_daemon-t hiányol, ami persze nem létezik a kész bináris csomagban, újra kellene fordítani hozzá a squid-t. Cross compile valahogy nem az esetem, sikerül ugyan létrehozni a környezetet, amin egy helloworld.c-t lefordítva a routeren működő programot kapok, de a squid-t forrásból már nem tudom lefordítani rajta, olyan hibákat dobál, amikkel nem tudok mit kezdeni. Közben a routeren is piszkáltam kicsit a squid konfigot, végül sikerült annyira kiherélni, hogy elinduljon.
3. Végre megy, az alkotó megpihen és hagyja járni a gépet. Elég hamar feltűnt, hogy időnként fél-egy percre leszakadok a netről, de ha mellőzöm a proxy-t, akkor nincs ilyen gond. Hát a default konfiggal, a gyakorlatilag üres routeren sem igazán működőképes, felzabálja a memóriát. Aztán ha elfogyott, akkor szerencsére nem az egész routert, csak saját magát indítja újra.
4. Mivel eleinte nem látszott, mennyi memóriát használ valójában (a leállítása után sem szabadult fel jelentős mennyiségű memória), keresni kezdtem egy monitorozó programot, de ehhez már nem volt sok türelmem, maradt a collectd. De mire megtaláltam, hogy a LuCi-ban a luci-app-statistics modul kell, hogy a collectd által begyűjtött infókból grafikont készítsen... és még így is van egy csomó, amit hiába raktam fel, a LuCi-ban nem tudom megnézni. Arra már nem volt energiám, hogy utánamenjek, hogy tudnék mindent, részletesen, grafikus formában lekérni... majd máskor...
5. Kiderült, hogy sajnos akármit csinálok, nem tudom annyira redukálni a squid memóriaigényét, hogy használható maradjon (bár itt még van egy kérdőjeles pont, lehet, hogy én csesztem el amikor a rock store-t is beállítottam, ennek majd utánajárok), kell egy másik proxy, ami URL alapján szűr + cache-el. Tinyproxy. Ja, nem, az nem cache-el. Ö... kifogytam a lehetőségekből... ja, mégsem: polipo (folyton Polio-ként jut eszembe, ami az ukrajnai járvány miatt lehet :( ). Hát izé... Úgy szidom a fejlesztőjének a jó édes szüleit, nagyszüleit stb., hogy még a fal is belepirul... Elvileg diszkre cache-el. Gyakorlatilag nem. Jó néhány órám ráment, úgy tűnik, nem csak nekem, mert a neten csak panaszokat, kérdéseket találtam, megoldást nem, hogy miért nem megy... minden létező variációt kipróbáltam, de nem, nem és nem... aztán egyszercsak elindult. WTF??? (azt most nem részletezem, hogy a saját, belső DNS-e miatt mit szoptam). Kiderült, hogy az openwrt csomagban lévő default konfig nem azonos azzal, amit a /etc/init.d/polipo start felszed. Az eredetivel valamiért működött a diszkes cache, az openwrt-ssel nem. Kb. tíz eltérés volt köztük, úgyhogy relative hamar kiderült: van benne egy web szerver, amit ha letiltok (nem adok a localDocumentRoot paraméternek egy létező, valós, tehát nem a /dev/null-ra mutató könyvtárat, akkor szarik a cache-re, holott dokumentáltan a cache-nek csak a diskCacheRoot-nak kell jó helyre mutatnia.
6. Hurrá, végre megy! A filter kipróbálásához már nem jutottam el, mert eszembe jutott pár kellemetlen mellékhatása a polipo webszerver bekapcsolásának. Ez egy primitív kis szerver, biztonságra valószínűleg nem adott annyira a fejlesztője, hiába adok neki egy üres könyvtárat, a franc tudja, milyen disznóságra lehet felhasználni. Na mindegy, végül is egyedül használom, annyira nem izgalmas. Hmmm... a proxy porton érhető el a webszerver is. Ha a http://proxy-cime:proxy-port/polipo/ címre hivatkozom, egy kurva szó nélkül a pofámba tol egy admin felületet a proxy-hoz, ahol még néhány paraméterét is át tudom írni... authentikáció, authorizáció meg minek egy ilyen laphoz? Kurrrva jó. Egy kikapcsolhatatlan backdoor, amit miután nem localhoston terveztem használni... Hát nagyon gyorsan jött az opkg remove polipo. Anyád, az, már megint! Nem tudja eltávolítani a csomagot, használjam a --force-remove kapcsolót, pedig semmiféle függősége nincs.... valószínűleg a módosított konfig fájlok miatt.
Folyt. köv. ha addig nem kukázom az egészet, hogy a helyére tegyek valami barebone vasat egy normális debiannal...