Tapasztalataim alapján az összes platformcserés migráció amikbe eddig beletenyereltem exponenciális méretű cumilehetőségeket hordoz magában, itt is vannak/voltak ilyenek, bár ezek nagy részével már régebben, egy NetWare szerverként funkcionálandó Linux szerver installációjánál találkoztam, illetve lekűzdöttem.
Ilyenek voltak pl., hogy a Novell-es RPL nem működik automatikusan a Linuxos rpld-vel, vagy hogy annó a Novell kliens hibája miatt nem lehetett 3.x-es NetWare szerverre (így az azt emuláló mars_nwe-re sem) csatlakozni…
Itt azon banális ok miatt “kell” lecserélni a NetWare-t (3.12), mert 5 nyomtató van rajta (4 soros, 1 párhuzamos) és egy mai (nem ISA-s) gépbe nem nagyon lehet megvalósítani 4 standard soros portot úgy, hogy azt a NetWare is lássa és a soros kártya ne kerüljön többe mint maga a szerver. Plussz az 5 felhasználó is kevéske, de az még elmenne.
Most nem térek ki részletesen arra, hogy miért nem kell az ügyfélnek a “sokkal többet tudó” (de itt felesleges) új NetWare (vagy egyéb) szerver OS, talán annyit, hogy ide a legjobb lenne egy ROM-ból induló “beágyazott” NetWare 3.12 (amiből még így is lehetne mit kivenni), hogy bombabiztos fájl és nyomtatószerverünk legyen.
Ügyfél (étterem) gyakorlatilag éjfélig dolgozik és ez hétvégén is így van. Ez nem segít sokat a migrációban, minthogy éjfélkor lehet érdemben kezdeni.
Ennek megfelelően kellő fáradsággal eltelve az “első nap” banális kernelforditásí problémákkal telik el. Ezt ne is vegyük értelmesen eltöltött időnek, bár az kiderül, hogy a linux elkezeli a berakott “gagyi” plussz soros portokat is. Amúgy a standard dolgokon felül kell a kernelbe IPX támogatás (802.2 és NCPFS nem kell, még az RPL miatt sem), a mars-nwe configban a 21-es opció alatt a nyomtatók a linux-mars szerverhez fizikailag csatlakoztatott helyi nyomtatókra vonatkoznak, lpr legyen fennt, /var/spool alatt a könyvtárak legyenek meg, printcap szerkesztés, ilyesmi… (2006.08.01)
[2006.08.08]
A ”második nap” eljutunk már addig, hogy fájlokat átmásolva, 1-2 felhasználót “kézzel” (syscon) felvéve, jogosultságokat megadva, nyomtatókat beállítva bebootol rpl-lel az egyik (diszknélkül) munkaállomás, elindul rajta a szoftver, csak rossz kernelt használunk ergó nem jönnek ki a nyomtatások amik a múltkor pedig mentek. Plussz kiderül, hogy a MARS-ban nincs SPX támogatás, így az rprinter nem használható, az egyik soros porthoz kell egy 25-ös átalakító és a BNC-s szegmenshez vagy egy HUB, vagy egy BNC-s kártya. Tehát ma sem lesz végleges átállás…
[2006.08.23]
Másnap rájövök, hogy rossz kernelt használtunk, abban nem volt belefordítva a párhuzamos és soros port támogatás… Így nehéz nyomtatni.
BNC-s hubot “újonnan” nem lehet szerezni. Kártya még akad.
Közben találok egy rcprn nevezetű printer alternatívát is, két apró baja van, az egyik, hogy queue-hoz kapcsolódik, nem “printerhez”, így csak egy queue-t tud kiszolgálni. Viszont elindíthatom kétszer (háromszor, stb.) is, így mégiscsak ki tud szolgálni több queue-t.
A másik baja, hogy csak párhuzamos nyomtatást tud, ez érdekesebb, mert itt soros blokknyomtatókkal kell dolgoznia.
Mit tesz ilyenkor az egyszeri ember, hát fogja az assembly forrásszöveget és beleírja a sorosnyomtatás támogatását, lefordítja, leteszteli, átírja (és kijavítja) a readme-t, összecsomagolja, majd elküldi az eredeti fejlesztőnek és elérhetővé teszi mások számára, plussz leírja a blogjában… :-)
Szóval a projekt fizikailag még nincs befejezve, de látom az alagút végén a fényeket és az vélhetőleg nem a vonat…
A negyedik helyi próba után elhozom az új vasat, hogy legalább valami tesztrendszert tudjak csinálni belőle, amivel nem csak éjfél után lehet foglalkozni.
Az már tisztán látszik, hogy nem lesz benne két hálókártya, mert egyrészt az rpld csak az egyikkel működik, másrészt a mars indulása után pár perccel akkora “pánik” lesz IPX routolást emlegetve, hogy még olyat nem láttam. Feltételezem, hogy azért ennek kéne mennie, de egyszerűbb felszámolni a BNC-s szegmenst…
[2006.11.07]
Úgy tűnik véglegesen sikerült a csere, nem kevés probléma lekűzdése után.
Pl. ugye volt a BNC szegmens felszámolása (amiért nem kár), meg aztán kiderült, hogy jó lenne az rcprn, de mégsem, mert 1) lassú, 2) ha fut a clipperes számlázó, akkor a háttérben nem nyomtat, csak kilépéskor… Itt a clipperes program nyomtatását kellett kicsit átvariálni, ez is egy sikertelen migrációpróbát jelentett [2006.10.02], plussz 1 hetet.
Most mennek a remote boot-os DOS-os gépek, a nyomtatás is mindegyik nyomtatóra, az XP-s gépeknek van egy-két nyígja, működnek, de login közben 89fc és 8819-es hibákat dobnak… Ezt még leellenőrzöm, és megnézem mit lehet csinálni velük.
De a “fő” része megy, úgyhogy nagyjából sikeresnek ítélem a projektet, de a cikk eleji pesszimista várakozás beigazolódott.
—
Másnapra kiderül, hogy mégsem túl sikeres a projekt, mert 99%-ban jó minden, de az 1K méret fölötti számlák a POS nyomtatókon “szemetet nyomtatnak”. A gyors megoldás a “vissza az egész”, ami persze eléggé lelohasztó dolog.
—
Karácsony is eltelik különböző gépek, nyomtatók, kábelek, soros-portok és kernelek tesztelgetésével, közben helyenként nincs teszt nyomtató, illetve a Star SP500 nem produkálja a hibát, csak a régebbi Epsonok, tehát “döcögve” halad a feladat megoldása…
Februárban végre megvan minden, sikerül reprodukálni a hibát és kizárásos alapon a nyomtató (kommunikációja) a hibás. A probléma áthidalását “megsejtettem” már november 24.-én. (A serial és printing FAQ-k nem szólnak a problémámról érdemben). Tehát a “nyerő” megoldás a:
(stty 9600 ixon ixoff crtscts -ixany; sleep 99999999) < /dev/ttyS0 &
futtatása inditáskor (a többi 3 ttyS-re is). Ebből valószínüleg a "crtscts" segített, de igazából most már mindegy, fő, hogy megy. Előtte még sikerült egy alternatív megoldást kreálni, ami gyakorlatilag soronként nyomtatta ki a nyomtatandót (megfelelő időzítések közbeiktatásával) és úgy sem történt "buffer overflow", de végül ez nem kellett.
2007.03.07 - És a “kezdettől” kicsit több mint 7 hónap elteltével a végre beállítottuk végre a NetWare 3.12 helyett, most már 99.99%-osan működik… (Néha a clipper program bizonyos menüi 1-2 mp késedelmet szenvednek, unalmas óráimban esetleg megpróbálom kitalálni miért…)
NetWare 3.12 - nyugodj békében…
—
Update: 2007.06.23 - A Clipper valószínűleg azért lassú, mert maga a mars_nwe hálózatkezelése is az…
