Zyxel NSA320S és a Debian Linux – 1. rész

Nemrégiben szükségessé vált egy NAS-t beüzemelnünk az irodánkban, és hosszas keresgélés után egy kiváló ár-érték arányú Zyxel NSA325v2 lett a kiválasztott, két méretes Western Digital RED diszkkel használjuk. Nem is csalódtam benne, halk, gyors, szinte minden igényünket kielégítve működik. A típus kistestvére, az NSA320S gyári szoftverével viszont koránt sem vagyok ennyire elégedett.

A dolog előzménye, hogy maradt néhány szerverből kikerült, kihasználatlan, de kidobásra még nem érett, 750-es WD merevlemezünk, amelynek helyet kerestem. A pozitív tapasztalatok miatt a Zyxel NAS-ok irányában kezdtem gondolkodni, de most az olcsóbb, kisebb modellre került a választásom. Így került hozzám a Zyxel NSA320S, amely nem csak kinézetre szinte teljesen összetéveszthető a nagyobb testvérével, de azzal szinte azonos rendszert is futtat. Ez (sajnos) meg is látszik a működésén, mert a kevesebb rammal (256MB < 512MB) ellátott vason ugyanannak a rendszernek bizony vannak hátulütői. Érdekesség, hogy nem csak az NSA325v2, de még az NSA320 (azaz az előző modell) is 512MB rammal gazdálkodott, amihez képest (ram tekintetében legalábbis) visszalépés az újabb modell. Újabb példa rá, hogy egy újabb modell nem minden esetben jelent előrelépést.

Az NSA320S felépítése a szétszerelés során is egy átgondolt, igényes készülék benyomását keltette bennem. Ahová fém kell ott fém van, a ventilátor szabványos méretű, könnyen, forrasztgatás nélkül kicserélhető, és semmi nem tűnik vacaknak vagy lötyögősnek benne.  Talán még második nekifutásra sem igazán tudnék belekötni a kialakításába.

Miért érdemes egy NSA320S operációs rendszerét lecserélni?

Az NSA320S gyári operációs rendszere is egy Linux, amely a 2.6.31.8 kernel köré épül. Egy NAS-t nem (még ilyen apró NAS-t sem) teszünk ki a publikus hálózatra, így a NAS rendszerét érintő biztonsági hibák kiküszöbölése nem túl lényeges szempont. A garanciavesztés a rendszer buherálása ellen szól, így joggal merül fel a kérdés, hogy egyáltalán mi értelme darabjaira szedni a gyári rendszert.

Négy olyan okról tudok, amiért érdemes lehet módosítani az NSA320S operációs rendszerét:

1. Az NSA320S mindössze 256MB ramot tartalmaz, ami takarékosan használva sokmindenre bőségesen elegendő. A beépített rendszer azonban egyáltalán nem takarékos, a rendelkezésre álló memória több, mint 1/3 részét a menedzsment felületet kiszolgáló webszerver, másik 1/3 részét pedig egy Python alkalmazás (fileye.pyc) emészti fel. Igen, python! Megdöbbentően elkényelmesedtek a beágyazott rendszerek tohonya fejlesztői.
2. A NAS a behelyezett lemezeken a RAID1 kötet létrehozásakor kérdés nélkül létrehoz egy 512MB méretű SWAP particiót (-1 prioritás), majd a RAID1 tömbön lévő Ext4 fájlrendszeren egy 512 Mbyte méretű SWAP fájlt (-2 prioritás). A RAID1 tömbön létrehozott SWAP fájl hallatán nyilván minden jobbérézésű rendszermérnök felszisszen a fájdalomtól. Ennél komolyabb probléma az, hogy a NAS nagyrészt kikapcsolt szolgáltatások mellett is lassan, de biztosan felemészti a rendelkezésre álló ramot, és elkezdi használni a SWAP-et. A SWAP partició aktív használata természetesen folyamatosan visszahozza a merevlemezeket az alvó állapotukból, a dmesg parancs kimenete innentől leginkább a „HD1 stand by now!” és a „HD1 awaked by swapper!” sorok váltakozásából áll. Ez áramfogyasztás, a lemez-élettartam, melegedés és zaj szempontjából egyaránt rossz.
3. A gyári szoftver kényelmes, webes felületet kínál menedzselésre, de ennek ára van. Az erőforrások nagy részét (főleg a ramot) nem a tényleges szolgáltatások, hanem maga a menedzsment felület viszi el. Saját rendszerrel sok egyéb feladatot is elláthat a kis NAS, ha kevésbé pazarlóan bánunk az erőforrásokkal. A NAS beépített erőforrásai minden további nélkül lehetővé teszik pl. egy megfelelően titkosított, távoli mentés lehetőségét.
4. A webes felületen néhány kattintással beüzemelhetünk pl. egy RAID1 kötetet, de nincs lehetőségünk arra, hogy megfelelő particionálással pl. a kényes adatok (családi fotók?) számára fenntartott RAID1 kötet mellett egy kevésbé fontos adatoknak (filmek?) fenntartott RAID0 tömböt is létrehozzunk. Linuxon ez nem gond, de az egyébként kényelmes menedzsment felületen erre nem kapunk lehetőséget.

A rendszert ezek miatt talán megéri lecserélni, ha a NAS gazdája alapszintű linuxos ismereteknek amúgy is birtokában van. Számomra a 2. és a 4. pont volt döntő.

Mi kell(het) a művelethez?

A csavarhúzó mellett néhány apróság mindenképp nélkülözhetetlen a saját telepítéshez, de szerencsés esetben azért nem kell egy elektronikai labor a művelethez.

1. Linuxos alapismeretek mindenképpen szükségesek, hiszen első körben a kényelmes, webes felület az, amitől el kell búcsúzni. Enélkül sem nagy varázslat egy NAS konfigurálása, de azért a titkárnőre egy bolondbiztos felhasználói felület hiányában nem bízható rá.
2. Az NSA320S alaplapján be van forrasztva a soros konzol tüskesora, így ezzel nem kell foglalkozni. A szétszerelés művelete nem vészes, minimális műszaki érzékkel senkinek nem okozhat gondot 12 csavar.
3. Valamilyen lehetőség, hogy az NSA320S alaplapján lévő, soros (TTL 3,3V) konzolon keresztül kommunikálni tudjunk az U-Boot loaderrel. Ehhez megfelelő egy USB RS232 TTL átalakító, amely beszerezhető akár az Ebay.com-ról is (a szállítási díjjal együtt kb. 350 Ft-ba kerül).
4. Ha sikerül levélnehezékké alakítanunk a NAS-t azzal, hogy az U-Boot loadert elflasheljük, akkor szükség lesz egy JTAG programozóra. Filléres áron készíthetünk is egyet, ha a gépünkön még van párhuzamos port, de a direkt JTAG programozókon kívül (pl. Altera USB Blaster) akár egy Raspberry Pi is alkalmas lehet a feladatra. Ezek azért valamivel komplikáltabb és drágább eszközök, mint a 3. pontban említett TTL átalakító, a dolog nehézsége mégis inkább az, hogy a JTAG használatához szükséges kábeleket bizony forrasztani kell.
5. Lemondás a garanciáról. A NAS szétszerelése során nem ütközünk sem garanciavesztésre figyelmeztető matricákba, sem lepecsételt csavarokba, de a módosított szoftver biztos út a garanciavesztés felé.
6. Kellő mennyiségű nyugalom és szabadidő.

Nos, a garanciavesztéstől én nem ijedek meg, minden egyéb meg adott a művelethez.

Milyen lehetőségeink vannak, ha nem felel meg a Zyxel által szállított rendszer?

A Zyxel NSA320S a hasonló kategóriában versenyző NAS-okhoz hasonlóan Marvell Kirkwood SoC köré, azaz ARMv5TE architektúrára épül. Bár a CPU alap architektúrája nem a legújabb (2000. évi), az 1GHz-es órajellel semmiképp nem nevezhető rossz választásnak. Félreértés ne essék, nem a SoC régi, a Marvell 88F6702 kódszámú chipje egy elég új modell, csak az ARMv5TE koros picit. A legtöbb Linux disztribúció nem elérhető erre a kissé öregecske architektúrára, a legtöbb ARM Linux disztribúció az ARMv7-et jelöli meg minimum követelményként.

Az alábbi OS lehetőségeink vannak:

1. Zyxel gyári OS. Elfér a 128Mbyte méretű beépített flashen, de aktívan használja a diszkeket is (nem csak SWAP funkcióra), emellett kissé pazarlóan bánik az erőforrásokkal. Persze számos gyári és hackelt csomag elérhető hozzá, ilyen pl. az FFP is.
2. Arch Linux ARM, mely egy pendrive segítségével talán telepíthető a NAS megbontása nélkül is. Azért írom, hogy talán, mert sikeres visszajelzésről nincs tudomásom, az Arch Linux leírásban szereplő NSA320 pedig egyáltalán nem NSA320S.
3. Debian Wheezy Linux ARM EABI portjának telepítése. Ezt biztosan nehézkesebb telepíteni, de ha sikerül akkor több mint 25000 Debian csomag között válogathatunk.

Finoman szólva sem vagyok Debian rajongó, sosem tudtam egyetérteni a Debian maintainerek sajátságos logikája szerint összerakott csomagokkal. Most mégis a 3. pontra esett a választásom, talán mert ebben van leginkább kihívás, hiszen egyelőre nem kering infó sikeres Debian 7.8 Wheezy telepítésekről a NSA320S-re.

Az előre látható nehézségek

A módosításnak sejthetően vannak nehézségei. Az első, hogy tudomásom szerint az NSA320S-re még nem telepítettek sikeresen Debian rendszert, csak zsákutcába futott kísérletekről és félsikerekről tudok. Az NSA320-ra van bejárt út, de az NSA320 és NSA320S között a nevükön kívül nem sok hasonlóság van, a lenti képet érdemes összevetni egy NSA320 alaplapjának a fotójával. Látható, hogy teljesen más az alaplap, más a SoC (NSA320 = HSBGA tokozású 88F6281, NSA320S = LQFP tokozású 88F6702), kevesebb a ram, nem sok egyezés van.

Csak néhány a nehezítő tényezők közül:

1. Az LQFP tokozású 88F6702-A1 chipet több eszközben is használják (pl. D-Link DNS320L, LaCie CloudBox), de a chip dokumentációja egyelőre nem hozzáférhető a halandók számára. Sebaj, legfeljebb ezen a blogon lesz kint elsőként 1-2 infómorzsa erről a Kirkwood SoC-ról.
2. Már több hozzáértőbb próbálkozás futott zátonyra a Zyxel itt-ott bugos U-Boot loadere és kernel problémák miatt.
3. Az NSA320S alaplapon az előző modellekkel ellentétben nincs elkülönített JTAG csatlakozósor, csupán 11 db TP1-TP11 jelöléssel ellátott ellenőrzőpont, a TP2 ráadásul az alaplap hátoldalán. Beszédes adatlap nélkül nem túl reményteli nekiállni egy ilyen szoftvermódosításnak, de abból főzünk, amink van.

A dolog tehát elsőre nem tűnik egyszerűnek, de az egyszerű dolgokban nincs is kihívás. Leszögezem, hogy a módosítást még nem csináltam meg ezen bejegyzés írásakor, így elképzelhető, hogy a következő bejegyzésem csak a zsákutcába fulladt kísérletem magyarázata lesz. Meglátjuk.

Folytatás következik…

Hivatkozások:

http://www.madadmin.com/zyxel-nsa320s-es-debian-linux-2-resz/
http://www.madadmin.com/zyxel-nsa320s-es-debian-linux-3-resz/
http://www.madadmin.com/zyxel-nsa320s-es-debian-linux-4-resz/
http://www.madadmin.com/zyxel-nsa320s-es-debian-linux-5-resz/
http://www.zyxel.com/
http://zyxel.nas-central.org/
http://zyxel.nas-central.org/wiki/FFP-stick
https://wiki.debian.org/EmDebian/CrossDebootstrap