Archive for the ‘Novell’ Category

Novell April 1st (1992) press releases finally found…

Thursday, September 1st, 2011

I recently found Novell’s April 1st press releases – from 1992, soon a decade old -, which I think must stay accessible forever…

By the time we got them, we did what we usually did with press releases… Copied and sent them without reading… to twenty-some journalists… Then one of them [only one!] called us several days later, with “What is this hillarious nonsense?”… Then we’ve read them too…

So here they are, in text format [to feed google] and of course the scans of the originals at the bottom.


Novell Announces “WORN Disk Technology”

Düsseldorf, 1.4.1992 – Novell, Inc., developer of NetWare systems software products, today announced WORN technology. WORN is a result of Novell’s close cooperation with major disk manufacturers and implements the most recent and straightforward concepts of data storage on harddisks.

WORN technology is an ideal alternative to the high capacity CD WORM (Write Once Read Maybe) disks developed during the recent years. WORN (Write Once Read Never) is an easy to use and simple technology to store data of any kind of media. WORN has been field tested effectively in combination with Novell’s backup utilities and drivers for 3 years. Many customers reported the successful implementation of Novell’s new WORN resources.

Without data compression an effectively unlimited amount of data can be stored even on smaller disk systems. The current release allows standard hard disks and disk controllers to be used with WORN drivers supplied by Novell. Internal tests performed in the Novell labs showed that more than 200TB (terabytes) could be stored on simple 40MB harddisks.

Due to the fact that the process of storing data currently runs much faster than data retrieval, WORN disks is be especially useful for storing large amounts of data that do not have to be accessed very often. As a side effect of the new WORN technology Novell can guarantee that applications stored on WORN drives can never be infected by computer viruses.

The next WORN release will implement additional features: it will allow floppy drives on a NetWare file server to serve as WORN devices. In combination with Intel, one of the most prominent manufacturer of microchips, there will be a co-development of WOMs (Write Only Memory) that will replace standard RAMs and ROMs in most file servers. WORN and WOM technology will revolutionize data storage and data processing of the future and post another milestone of networking technology.
As network computing expands into the enterprise, there is a great need for data security and high speed data transmission. Many distributors and national reseller organizations are sponsoring Novell’s new IPX/CE seminars for resellers and end users who need this information.

“We believe in the direction Novell is taking in the security market,” said A.E.Neumann. “Their products are so strong and this promotion is such a great opportunity that we’re creating a whole new division to support it.”

Novell, Inc., (NASDAQ: NOVL) is an operating system software company and the developer of network services, specialized and general purpose operating system software products, including NetWare, DR DOS, DR Multiuser DOS and FlexOS. Novell’s NetWare networking computer products manage and control the sharing of services, data and applications among computer workgroups, departmental networks and business-wide information systems.

Contact:
Claudia Kornacker
Novell GmbH
Willstatter Str. 13
4000 Düsseldorf 11

Tel.: +49 – 211 – 5973 – 0
Fax.: +49 – 211 – 5973 -250

[NOVELL GMBH • WILLSTATTER STRASSE 13 • 4000 DUSSELDORF 11 • TELEFON: (02 11) 59 73-0 • TELEX: 8 587 570 • TELEFAX: (02 11) 5 97 32 50]


Novell Announces “IPX Compression And Encryption Technology”

Düsseldorf, 1.4.1992 — Novell, Inc., developer of NetWare© systems software products, today announced an enhanced version of Novell’s proprietary network protocol “IPX”. The new IPX/CE protocol allows NetWare file servers and workstations to compress and encrypt data packets before sending them to the network. The current release encrypts and compresses data packets of up to 1024 bytes into 1 byte packets.

Due to the innovative, high-performance technology it is impossible for any unauthorized receiver on the network to decrypt any information sent on the wire. The high compression ratio allows the use of the of the transmission media’s full bandwidth and increases the effective speed of data transfer by approximately 300-2000%.

Contact:
Claudia Kornacker
Novell GmbH
Willstatter Str. 13
4000 Düsseldorf 11

Tel.: +49 – 211 – 5973 – 0
Fax.: +49 – 211 – 5973 -250

[NOVELL GMBH • WILLSTATTER STRASSE 13 • 4000 DUSSELDORF 11 • TELEFON: (02 11) 59 73-0 • TELEX: 8 587 570 • TELEFAX: (02 11) 5 97 32 50]


Scans:
WORN – Page 1 of 2 • WORN – Page 2 of 2IPX Compression

Egy korszak vége

Friday, July 24th, 2009

Kedden véget ért egy korszak — felszámoltuk a saját NetWare (4.11) szerverünket.
Amúgy is már EOL (End-Of-Life) termék volt vagy 10 éve, meg a diszkeknek is furcsa hangja kezdett lenni, lassan tehát úgyis “hozzá kellett volna nyúlni”.

Nagyjából minden működik eltekintve egy-két dologtól, olyan banális okok miatt, ami a harmadik évezredben eléggé röhejesnek tűnik.
Például a hálózaton lévő banki program valamilyen hülye okból a helyi gépen létrehozott könyvtárát törölni kell, majd az induláskor létrehozza és boldog lesz. Ez egy, a bank által már korábbról “ismert probléma”. Kérdés, hogy akkor miért nincs “kijavítva” a program?

Másik példa, hogy az eddig Novell NetWare szerveren tárolt Outlook Express adatbázis nem tárolható Windows szerveren. Sem menüből, sem registry átállítással nem lehet rávenni, hogy menjen. A hivatalos “magyarázat”: http://support.microsoft.com/kb/199074 – azaz “nem lehet” hálózati megosztáson.
Valószínűleg a programozó a Microsoftnál nem tekintette a Novell NetWare-t hálózati operációs rendszernek, ezért lehetett, hogy azon vígan ment… :-]

Az, hogy ugyan a felhasználónak kiosztott jogosultság azonnal, de a csoporton keresztül adott jogosultság csak újra bejelentkezés után “él”, megérne egy misét (az egész Microsoft jogosultságkezelés meg egy egész bibliát). NetWare alatt ha egy nagyobb fájt másolok és _közben_ elveszem a jogot a felhasználótól, akkor azonnal nem tudja továbbolvasni a fájlt. Windows alatt ez nem egészen így van…
(Jut eszembe, annó véletlenül kivettem egy működő NetWare szerverből egy hálózati kártyát és csak akkor vettem észre, hogy mit tettem, amikor a konzolon kiírta, hogy valami PCI event van… Aztán ijedtemben vissza is tettem, örült neki, és minden ment tovább… – Ez akkortájt volt, amikor Windows NT-n még újra kellett indítani a szervert IP cím változtatáskor…)

Azt hiszem már közeleg az az idő, melyben a kőbalta lesz a legcélszerűbb eszköz – hacsak nem kell majd illesztőprogram ahhoz is…

Ne kicsinyeskedjünk…

Tuesday, March 24th, 2009

Ez is egy régebbi anyag – na jó, baromi régi, 1991-ből a Novell NSE adatbázisából -, de az ilyeneknek egyszerűen fenn kell maradnia örökre!
Ez a hozzáállás kéremszépen, én is szeretnék sok sok ilyen “user”-t…

This is an old material too -well, extremely old, from Novell’s NSE database, 1991 -, but articles like these must be kept public forever.
This is the real attitude, I’d like to have many many users like this…

 

FYI:  “Mirror Copies of Volume Dir Dont Match” – Ontrack

DISCLAIMER 

 The origin of this information may be internal or external to Novell.  Novell makes every effort within its means to verify this information.  However, the information provided in this document is FOR YOUR INFORMATION only.  Novell makes no explicit or implied claims to the validity of this information.

 

TITLE:                                            “Mirror Copies of Volume Dir Dont Match” – Ontrack

DOCUMENT ID#:                         FYI.P.4291

DATE:                                             09OCT91

PRODUCT:                                   NetWare

PRODUCT VERSION:                v3.11

SUPERSEDES:                           NA

SYMPTOM:                                   

The user had extremely sensitive data stored on a file server in Kuwait. Thinking something was wrong, the user turned off the power to the server.  After powering the machine back up, the system displayed the following error message:

┌───────────────────────────────────────┐
│Mirror copies of volume dir dont match │
└───────────────────────────────────────┘

ISSUEPROBLEM

The Novell technician told the user to run VREPAIR because it fixes this problem 99 percent of the time.  The user did not want take the 1 percent risk of running VREPAIR.

SOLUTION

The user flew a team from Ontrack to Kuwait and they successfully recovered 100 percent of the data.

Ontracks data recovery phone numbers are the following:

      USA                   1-800-872-2599

      International  1-612-937-5161

      FAX                    1-612-937-5750

Ontrack has two offices in the U.S. and one in Europe.

      Ontrack London office

      Phone: 44-81-549-3444

            Fax:   44-81-546-6642

mystery solved: NetWare 3.x/4.x remirror starting at 88%

Tuesday, July 17th, 2007

Finally I took some minutes and checked that cosmetic issue, which symptoms in showing 88% percent remirror status right after the start of a remirroring (where it should be 0%) on earlier NetWares.

If install.nlm shows 42.949.680 or more data blocks (that is 171.798.720 sectors, approximately 163,84 GB) for a partition, then mirror algorithm will fail to correctly calculate the percentage.

Let’s say, we have 48.832.973 (0x2E921CD) data blocks, with 6627 (0x19E3) redirection blocks.
Then according to server.exe’s calculation, ~48.408.845 (~0x2E2A90D) “mirror blocks” should be mirrored.
There is an instruction “IMUL EBX*64h” which multiplies this value by 100 (0x64), but then the value will overflow the poor 32bit register, resulting in 0x1208A0914.
Then dividing the remaining 32bit part only (0x208A0914) by the number of data blocks (0x2E921CD) would result in 11 (0xB) which would be 99-11=88% complete.
So from then on, it will reach 99% by about mirrorring the 0xA699D-th block, then at next block it would “jump to” 12% (0xffffe10/0x2E921CD=0x57=87 -> 99-87=12%)
Then it would go to 99% “normally”

This only affects the calculation and display of the status percentage, not the mirroring procedure itself.
So even 3.x/4.x NetWares – more precisely the NetWare traditional file system – can handle large harddisk/block size, but seems like who wrote the “display percentage calculation” part wasn’t prepared enough…

Traditional file system’s “most important” size related limitations:
Maximum device size recognized (physical or logical): 2 TB
Maximum partition size: 1 TB
Maximum volume size: 1 TB
Maximum file size: 4 GB

Here is a more detailed comparsion on traditional FS versus NSS.

Nprinter history and comment page

Friday, May 11th, 2007

This page is to let people know what happened (and what not) in connection with the problem that exhibits when using Nprinter (for NT) on an XP with Novell Client 32. (Eg.: blue screen – DRIVER_IRQL_NOT_LESS_OR_EQUAL)
Here you can also express your comments regarding to this issue.
Since the current status of this issue at Novell is “Closed” (unresolved), please do leave your comment here, to raise the chance of this issue to be fixed.

In “short” (but really…):

  • I created “my” webpage on Nprinter on 2004.JUN.07. This is approximately more than a year after I needed to have nprinter on Windows 2000 and XP. Later on I started experiencing this issue on XP machines…
  • Time passed, I got mails and I also experienced the problem at other customers too.
  • I experienced a problem at a customer, where finally we had to buy some print servers to solve the problem, so I got “pissed off”, then I reported “NWClient 491SP2+PKA – nwsipx32.sys – DRIVER_IRQL_NOT_LESS_OR_EQUAL” to: Novell’s patchfeedback address on: Wednesday, May 24, 2006 11:44 AM (with screenshots and other details)
  • Same day I got answer from Earle Wells congratulating on how I detailed the problem and that I should use NDPS.
  • After several more letters on the same day, I “achieved” that we’ve reached to: “Good news! Engineering is willing to take a look at a kernel memory dump”
  • I sent dump, next day he informed me that they found the bug, but it would be too problematic to fix it and probably would never be fixed. An internal TID was also created, and service request ticket was closed.
  • I got several more letters from other “nprinter fan-s” and on 2006 August 17, I contacted my Novell “internal” / “problem-solver” friend to check if there is anything more we could do. Next day he wrote me back, that it is in the “wontfix” category, and he could talk about it in more detail for hours…
  • So I called him. As far as I remember, he explained that it is not even clear that this is a nwsipx32 bug (as sometimes it happens in tdi.sys which is XP’s part), and it is low priority and obsolete and so on (which I’ve already known/suspected).
    I also tried to ask what would be the cost of fixing this, but it is not the matter of money. I also got the internal mailing on this, saying:
       > The particular point at which the NULL pointer is being
       > dereferenced is within a Microsoft-supplied TDI compile-
       > time macro, and between the complexity of it & the fact that
       > this is release code with full optimization, its going to take a
       > couple hours of de-compiling the previous instructions to
       > root out what exactly was being referenced that was NULL.
       > After that of course comes “why”.
       > So it’s not something that is a slam-dunk or quickly
       > actionable, which doesn’t bode well for an NWSIPX32
       > issue being observed primarily
  • So the same day (2006.AUG.18) I contacted another friend of mine – who is my partner’s brother and working for Microsoft at Seattle -, asking whether there is any bugreport on TDI.SYS [based on: http://support.microsoft.com/kb/829120/en-us] or a patch/beta release of the file.
  • Next day I got a negative answer and also a suggestion that I should contact MS support starting from “support.microsoft.com“.
  • I answered that I don’t “believe” in having any result of a noname guy opening incident via web support, and even if I would, where to start at all…
  • Two days later (AUG.21) he mailed that he don’t really know where to start (and via OEM, VAP, Technet or what other channel) and he will ask around.
  • On 22nd, another friend of mine called me. I didn’t have any news on what he is doing lately, but it turned out that he is the Director of Support at Microsoft Hungary
  • He guided me what link should I use to let them have green light on this problem and he called me after he “saw” the incident getting started in their system. Then a hour later a support guy called me, I said I didn’t have much more information, but I made dumps available for them to download.
  • We agreed that they should look into dumps only where the BSOD happens in TDI.SYS (and not in NWSIPX32.SYS) as the issue exhibits itself sometimes in TDI.SYS, sometimes in NWSIPX32.SYS
  • On 23rd I got called from MS Hun. tech support that they need to escalate the problem to higher level, to debug the dump more thoroughly, and also because this really seems to be a “bug”, not a “support incident”. [id: SRQ060822600811]
  • On 24th, I got called saying the dump has been done, and the BSOD is Novell’s fault. I asked more (written) technical data, then later I got a a forwarded mail with also not to much technical information, mainly saying: “… basically the problem is caused by a novell driver that is not compatible to windows xp.”
  • Then I replied that I would really need more technical info to be able to “bounce back” the problem to Novell.
  • Finally I got a Windebug analysis with some comments.
    The most important was:
    “f88a9dac 805ce794 f8b79298 00000000 00000000 nwsipx32+0x4d3a < ---   Here we see the 3rd party driver loaded - but as we do not have the source code / symbols we cannot see the arguments passing up"
  • Then I realized I can also do a windebug analyze, so I downloaded and installed Windebug and some other required tools. I “analyzed” the rest of my dumps and created a very detailed analysis and comparsion on the different dumps.
  • On 28th, I forwarded my results to my friend at Novell Hungary.
  • On Sep. 1 MS contacted me to ask if they can close the incident.
  • I asked my friend at Novell on where are we. He said, his guy is on vacation, so I should hold on.
  • Time passed, then on Oct 11, I got an information from Novell that they assigned a priority to the bug. Even very low, but anyting can be higher than “wontfix”…
  • On FEB 23, 2007, I got a mail that says the bug is planned to be fixed in 4.91SP5.
    Though I don’t have permission to bugzilla, the link is here, and it’s main content is:
       What                 |Removed         |Added
    ———————————————————————
    Fixed in Milestone|—                     |4.91 SP5
  • Beginning of May I was informed that the status of this “issue” is “closed”. Not a “wontfix”, but basically closed without a solution.
  • I was also suggested that everyone having this problem should contact Novell and open an incident…

Since I believe it would be harder to convince people to do so I tried to support my already opened incident with the dozens of mails I received relating to this issue and I still would like your comment and some data (number of computers affected, maybe company name). The email field at the comment will not be published, so feel free to use your valid address if you would like to be notified upon any advancement.

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…

Last Christmas (I gave you my heart…)

Wednesday, January 31st, 2007

A következő egy gyors összefoglaló egy olyan (NetWare-es) hardver migrációról, ami a várakozásokkal ellentétben kissé hosszúra sikeredett, szemben az egyik előző migrációval, ahol meglepően gyorsan mentek a dolgok. A régi szerverben 5GB-s merevlemezek voltak(tükrözve), kevesebb mint 20%-os kihasználtsággal, tehát az adatmennyiség kb. egy CD-re ráfért volna…

December 27. – merthogy mi mást csináljon az ember a születésnapján, mint migráljon…

18:30 – Felkészülés a migrációra, gépek oldalának leszerelése, felkábelezés (billentyű, vga, 220), “apróságok” (ezek is jól el tudják vinni az időt)
18:47 – A régi gép sikeresen elindul. 1998 szeptember 12.-ei az installáció és a gép is.

Belseje, de még a külseje alapján is úgy látszik, hogy azóta vélhetőleg nem is tisztította senki.

Találok a gépen egy SCAN319-et, elmerengek a régi szép időkön…

18:52 – Kis gondolkodás, hogyan is „támadjunk”. TAO: Amíg nem tudod pontosan mit akarsz csinálni, ne csinálj semmit.
Ha lehet, akkor a legkevésbé célszerű nyúlni a “régi” szerverhez, főleg, ha semmi baja nincs, mert előfordulhat, hogy valami miatt az eredeti állapotot kell produkálni.
19:15 – Az új szerveren DOS partició meg egyebek előkészitése
15:30 – Marvell Yukon driver vadászat új szerverre (DOS ODI / LAN)
19:51 – IP cím egyeztetések, RA indítás
20:02 – Másolás indul
20:20 – Másolás végén FAT hibával leállás

20:22 – Régi szerveren Vrepair futtatása, majd második nekifutás
20:36 – Másodszorra is FAT Error
20:39 – leállítás, újrainditás, harmadik nekifutás
20:56 – Még mindig FAT Error(*)
21:25 – Kis pihenés, egyik régi HDD átrakása az új szerverbe, mirror szétszedése.
21:42 – Új szerverben az ideata.ham (még mindig) nem szereti a sata-t. HDD csere, SATA diszkek ki, PATA diszkek be. (Később újabb e-mail az ideata.ham fejlesztőnek ICH6/SATA kompatibilis driverért rimánkodva. Alaplapot már küldtem…)
21:48 – Régi diszk mountolása új ideatával.
21:53 – Másolás elkezdése Server magic-kel. Szinte azonnal abendál.
21:56 – Partició másolása a NetWare saját mirrorjával…
22:06 – Mirror kész
22:13 – Driverek és SP9 installációja az új szerver-re tükrözött particióra
22:45 – SP végez (elég sokáig tartott…)
22:49 – C: -> D: DOS másolása
22:50 – A második 300-as PATA-ra mirror készítése átméretezés előtt (biztos ami biztos, ne kelljen már megint hozzányúlni a régi diszkhez)
22:53 – Remirror kész, második diszk biztonságba helyezése.
23:02 – Első diszken partició kihúzása 300GB-re, SYS 40GB-re állitása (nem lenne szerencsés, ha egy 300GB-s SYS lenne). DATA és INSTALL volume-ok létrehozása. Minden sikerül, így nem kell már a második diszken archívált partició
23:14 – Második diszken a NetWare partició törlése
23:30 – Tükrözés a második diszkre (ennek a végét már nem várom meg, kb. 2 óra lehet), Marvell Yukon LAN driver beállitás, SET-ek, teszt.

És már kész is vagyunk…

(*) Utólag: Arra tippelek, hogy egy “vrepair/purge deleted files” után jó lett volna a másolás, dehát:
a) mint az elején írtam a lehető legkevésbé célszerű “szétbarmolni” a meglévő állapotot
b) utólag könnyű okosnak lenni… :-)

What your mother didn’t tell you about ArcServe 6.x for NetWare…

Wednesday, October 18th, 2006

Yesterday I ran into that problem (again) that I cannot restore with ArcServe 6.x from other than session 1.

In case you’re also using a skeleton NetWare with a similarly old ArcServe and Google to search :-), here are the error messages:

E1058 Failed to read from media – Filemark detected
E1112 Failed to find session 2.
E0015 Job xxxx: Restore Operation Failed

As far as I remember, last time when I tried to look for the solution I failed, but now I found a relatively fresh solution/explanation at:
http://www.tek-tips.com/viewthread.cfm?qid=1238418&page=7
It refers to
http://software.groupbrowser.com/archive/t-110093.html as partial source.

I also devoted some more slice of my life to get further information on this, here is the compacted result.

When a tape drive is not recognised by tapesvr.nlm, then it uses the default settings, which is 1024 bytes for block size and “VTABLE” for format type as CA’s TEC356365 “explains”:

Prior to the latest device patch, if the tape device could not be matched to the Tapelist.dat file, Tapesvr.nlm would still load, but the device would be initialized with generic information for that device type. In those cases, drives could be initialized with an incorrect format type of VTABLE (instead of FSTSEEK) and an incorrect block size. The results could range from poor drive performance to the inability to restore backed up data.

So, when you try to restore from other than session 1 (eg.: session 2, 3, etc.), then you get the above mentioned error messages (the “inability to restore backed up data” part).
However, you can still restore files from any session, by issuing a “tapesvr enable vtrestore n” command on the NetWare console, obviously “n” is the session number to be deal with. (You should get a message like “VOLUME TABLE restore of session #n has been enabled”)

I strongly suspect, that this is not just 6.1/6.6, but (BAB-BrightStor ARCserve Backup) 11.x too.
As described in CA’s TEC356365, they “realised” that this is not good, so they created a patch, which instead of letting tapesvr.nlm start with the “standard settings” (1024/VTABLE), now display you the following warning message and tapesvr unloads.
“E6918: An un-certified/un-supported device has been detected! Check the Computer Associates technical support website for more information… ”

They also created an tapesvr.cfg option:
UnSupportedDeviceOverride=ENABLED” as they say: “ONLY to allow users to be able to use ‘certified’ devices without having to immediately down the server and remove the ‘uncertified’ devices in order to allow tapesvr to load“.

In fact, as TEC356365 also says, having an unsupported device, with default settings have the only problems of “poor drive performance” and “inability to restore backed up data“.

The latter was discussed previously, but actually I don’t really understand why ArcServe cannot just simply restore that damn session in VTABLE format automatically, why do I have to enter that cryptic “tapesvr enable vtrestore n” command?

As for speed, with the 1K/VTABLE settings I got “92,320 files 11,346,014 KB written to FULLSYS @190,742 KB/min”. After changing to 16K/FTSEEK, I got “92,349 files 11,211,035 KB written to FULLSYS @192,574 KB/min”.
Not much of a change. (I use CANWPABD by the way.)

Now you got the question, how can you change from 1K/VTABLE to bigger buffer and FTSEEK.
The answer is relatively easy. Use the latest tapelist.dat and see if you tape drive is in the file. I mean, yes, no matter what version of ArcServe you use, grab the latest tapelist.dat you can. Currently the newest seems to be available from “BrightStor ARCserve Backup r11.1 SP2 for NetWare [build 961]“.
I understand if you wouldn’t like the idea to download an 500MB kit to get that 30K file, so here is it for you: tapelist.dat [29688 bytes, 2006.SEP.12].

Copy the file to ARCSERVE.6\NLM directory, unload and reload tapesvr.nlm.
To check the settings, remove any tape from the device, then go to “Tape Server”, “Tape Device Management”, “Tape Drive Status” menu.

If you see change, then you can go to have fun. If you don’t you’re out of luck. You can get your favourite hexeditor, and overwrite a similar entry’s id [name] in the tapelist.dat and hope it would work, or wait for a newer tapelist.dat.

Passing by, I noticed an article on “validate.nlm” which you might also like. Quote:

What is VALIDATE.nlm?

In the distant past, …
… Therefore VALIDATE.nlm was never used for its intended purpose. ARCserve still requires VALIDATE.NLM. VALIDATE.nlm simply tells ARCserve that all drives are acceptable.

Good job, validate.nlm!

Már megint szervercsere… II.

Saturday, September 23rd, 2006

Ugyanaz az ügyfél, ugyanolyan (új) szerver, másik telephely (de szokás szerint péntek délután/este).
Itt egy NetWare 4.11-es migrációja a feladat, viszonylag új a “régi” szerver is, 2*120-as diszkkel, itt (is) a Gigabit ethernet miatt kell hardvert cserélni.

Az új szervert a másik szerver migrációjának idején (üresen) kiszállítottuk, most visszakerült az is, mint detektáltam abban is Gigabyte GA-8I915ME-G alaplap van, aminek a chipset-jén SATA diszkekkel elhasal az ideata.ham NetWare 4.x-szel. (Ez már régebb óta így van, múlt héten rendeltem egy ilyen alaplapot az ideata.ham fejlesztőjének otthonra Orem-be, hogy legyen végre rá megoldás… :-)
Szóval gyorsan elszaladtunk még 2 db 200GB-s PATA diszkért mert már jellemzően csak SATA-kat tartunk raktáron. Ezért is jó lesz, ha az ideata “meggyógyul”…

Ez is egy hosszú életű NetWare 4.11, lassan 10 éves lesz, már több vas volt alatta cserélve. Legutoljára 2004 júliusában, ezért még újnak mondható.

A “bemosakodás” majd egy óra volt, és minthogy a régi szerveren már UDMA-ban ment az ideata.ham, úgy találtam, hogy a benne lévő két diszk mellé felrakva az egyik új diszket, a szerveren belüli másolás lesz a legfájdalommentesebb.
És így is lett! Soha nem volt még ilyen gyors migrációm.
Részletek:

kb. 17:00 – “bemosakodás”, BIOS setup, driverek másolása, DOS partició, stb.
17:41 – servermagic betölt, 20GB-s (9.7 használva) SYS másolása

17:50 – kész
17:51 – az új 200GB-s HDD-n az NW partíció maximalizálása
17:52 – új SYS átméretezése (40GB)
17:53 – USER volume másolása (80GB, kb. félig van adatokkal)
18:13 – új USER átméretezése (150GB-re)
18:14 – kész.
 … kis pihenés (mást is csinálok közben) …
18:32 – Új szerverben a HDD-k véglegesítése, DOS a
            D:-re, HDD-k felcímkézése, új ideata, LAN driver…
18:50 – server start, NW particiók tükrözése

Tükrözés kb. 20:35-re végzett a két 200GB-s diszkkel, közben foglalkoztam “lájtosan” az újabb gigabit kártya driver letöltésével és beállításával, “frissítettem” a TCPIP.NLM-et, mert nem akarta az IP-ket bind-olni a kártyákhoz, meg egyéb apróságokkal.

Kicsivel 10 után már az ügyfélnél a portással egyezkedtünk és az új szerver elhelyezésre lelt egy bukszus mellett…