Archive for March, 2007

Egy NetWare 5.1 migráció

Saturday, March 31st, 2007

Ügyfél “régi” szervere úgy kb. 2 hónaponta lefagy. Ez nem jó neki, tehát szeretne valamit. Idővel sikerül meggyőzni, hogy nem túl szerencsés kísérletezni a szerverrel, tehát kell egy új. Itt nem is “noname”, hanem “brand” low-end szervert ajánlunk. (Ez szerintem rosszabb mint a noname, mert nem lehet tudni mi van benne, egy biztos, nem “high-end” teknika…)

Első körben kapok egy Dell PowerEdge SC440 “szervert”. Szeretném a monitorátkapcsolót rákötni, és közben “feltűnik”, hogy a hátlapon a következő csatlakozók vannak (a 220-at leszámítva): UTP, VGA, 1 db COM port, és 5 db USB…
A billentyűt még megoldanám, de az ügyfélnek van egy párhuzamos portos hardverkulcsa, az könnyen belátható, hogy problémát okoz…

Add new hardware.

Következő versenyző a fentiek figyelembevételével egy IBM xSeries 100 (low-end) server. 1 db 80GB-s HDD-vel, ami értelemszerűen azonnal repül belőle. Az “brand-low-end/noname” alaplapon a következő felirat található (a sok “Made in China” feliraton kívül): M11iX GINKGO M/B. Annó egy pár éves x200-ast láttam, annak az alaplapján sem volt megtalálható “IBM” felirat. Akkor azt a szétporladt kondik miatt kellett cserélni, gondolom ez is valami hasonlót fog produkálni majd pár év múlva.

Minthogy a régi szerver HDD-i sem ősrégiek és jó eséllyel mennek majd az új szerverben, ezért a HDD-HDD másolás jelölődik ki irányvonalnak. Ha bármi gond lenne, a mirror másik része megmarad érintetlenül.

20:33 a régi szerver elindítása, hogy lássam, hogy a mirror az egyben van-e (egyben van), nincsenek-e valamelyik diszken redirected block-ok (nincsenek) és hogy a DOS particiók szinkronban vannak-e (nincsenek, ezeket szinkronizálom)
20:37 új szerver fdisk, format, stb.
20:45 kiderül, hogy az új szerverben a berakott két diszk közül az egyik diszk “problémás” (nem indul el, rángatja a fejet). Később elindul, de nem célszerű eleve igy kezdeni a szerver életét, úgyhogy csere előjegyez.
20:57 új szerverbe az egyik HDD áttesz. Csak NW51SP5 van rajta, igy a server.exe-be épített ezeréves NBI töltödik be. Gyorsan kap egy NBI frissítést is, az ideata.ham/idehd.cdm március 7.-i verzióival együtt.
SMAGIC többször hanyattdobja magát, sőt amíg az “auto restart after abend” nincs 0-ra állítva, addig újra is indul. Vagy a mirror vagy a törölt file-ok nem tetszenek neki.
21:18 Próbaképpen NetWare 4.x alatt is abendál..
21:39 Elindítok egy NetWare-es mirrort az egyik új diszkre (a móka kedvéért az egy darab SYS két NetWare partíción nyúlik keresztbe)
22:10 Mirror lemegy, elindítok egy vrepairt, hogy purge-ölje a törölt fájlokat.
22:17 Fájlok törölve, mirror szétszedve. Most már elindul SM átteszem a másik diszkre, hogy egyben legyen a volume, és a “végleges” méretében (160GB).
22:45 Másolás, átméretezés megvan.
22:55 Na ezért (is) utálom a NetWare 5-öt. Valamiért megjegyezte, hogy őt most ezentúl “33”-nak hívják. del servcfg.*. Minek kell ilyen szerkeszthetetlen szarban tárolni a konfigurációs beállításokat, így nem lehet látni, hogy mik a “default”-tól eltérő értékek, tehát “gond” esetén törölni kell, aztán lehet előről kezdeni a set-eket, amit értelmes ember amúgy is a startup/autoexec.ncf fájlokba ír be.
23:02 Broadcom B57 driver felmásol, inetcfg-ből régi interfész kigolyóz, új beállít (na ez is egyszerűbb autoexec.ncf-en keresztül). Amíg nincs tcpip-m, addig nem indul el a pserver, mert nem indul el a DS-sem… Ez is nagyon király…
NW51SP8 telepítés elindul, majdnem egy óráig megy.
Utána nem indul el csak ott áll. Egy HW reset után elindul, de startup.ncf mintha nem hajtódna végre. NetWare 5-ön az az “újítás” van még, hogy “eltűnik” a konzol, így nem lehet látni a (legalább a legutolsó) hibaüzenetet, ami kb. az, hogy a hwdetect nem tud betöltődni, mert nem találja az __U8M szimbólumot. Ez egyébként a DS.NLM-ben van, aminek nincs esélye betöltődni, ha nincs tcpip, azaz pl. lan kártya, így nem találhatja meg az új LAN kártyát magától (ami nem olyan nagy veszteség azért). Plussz kiderül, hogy a SLOT-ok “elmásztak”, így az ideata.ham megfelelő slot beírása után elindul. Persze a LAN kártya slot számát is át kell írni, addig szokásos (nincs pserver, tcpip, ds, stb.)
Éjfél után úgy tűnik van egy működőképes 160GB-s diszkem, félrerakom másnapra…

Másnap:
20:00 Rossz HDD kivétele és DOS partíciók frissítése/szinkronizálása
20:19 A jó 160-as HDD és a másik HDD tükörbe tétele, tükrözés indul
21:17 Tükrözés vége

Ezután még pár apróság, de gyakorlatilag kész van.

Egy (vagy “A”) NetWare –> Linux migráció

Thursday, March 8th, 2007

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…