NT vs. Linux - driven to Windows?
There are no intelligent answers for Windows problems.
Actually, I'm at least half serious.
I was working with an NT administrator yesterday on a Unix
problem. What had happened was that we had installed a few
things: a RealWorld upgrade, Visionfs 3.0, and Powerchute
software. After all that, people couldn't print any more.
It took me a little bit of work to track this down, because
the NT guys trouble shooting skills were poor- here's what I
was initially told:
- none of the printers work, including a serial dot matrix.
- the printers work fine from the command line, but not from RealWorld
I first had him check /usr/spool/lp/tmp and /usr/spool/lp/logs/requests and learned that nothing was backing up in the spool directory, but the log files showed that the RealWorld jobs had been printed.
My first suspicion was RealWorld configuration, but I eliminated that pretty quickly. It then turned out that all of his command line tests were done as root, and all of his RealWorld tests were done as an ordinary user. I had him try Realwoorld as root, and it worked. So the reality was now that printing worked for root, but not for ordinary users. That, of course, made my suspicious of perms on lp, but those were OK. I wasn't thinking of anything related to hpnp because the serial printer didn't work either.
Ah, but it turned out that that wasn't quite true either- the serial printer had been disabled and also was not even accepting requests. In fact, upon close reexamination, there were no entries for the serial printer in the logs. So I ran /usr/lib/accept and enabled it and now I knew that the problem really related to the HP network printers only. But it couldn't be a network problem because root could print. Therefore it had to be related to something the hp script does.
If you look at the HPNP interface script in /usr/lib/hpnp/hpnp.model, you see that it also writes its own log file in /tmp, and only removes it if the print is successful- so I looked in /tmp, but there were no hpnp log files. I then checked perms on /tmp, and saw why- it had no write permission. How did that happen? I doubted that it was RW, and it sure couldn't have been Visionfs, so that left APC Powerchute, and that indeed was the source.
The actual problem was that the Powerchute install script stupidly changes perms on the directory it is installed from (why?). It had changed /tmp and caused the failure.
Two comments the NT admin made bothered me. The first was "I wouldn't have known where to look". OK, that's fair enough, but there are two unrelated things to point out in that regard. One is that at least you CAN look (you can't look at the innards of NT's printing system). The other is that his trouble shooting wasn't very good- using root to test command line printing and an ordinary user to test RW clouded the real issue, and not noticing that the serial printer jobs did NOT appear in the lp logs also masked the real issue. But, I can't complain too much- I earn a good living because my trouble shooting skills ARE good, and I can't expect everyone to have such skills- if everyone did, I'd be broke!
It was the second comment that really bothered me: "It's this kind of stuff that drives people to NT- I've got to find an NT accounting system".
Like Powerchute or some other vendor couldn't screw up your life on NT? And if they do, just how in hell are you going to fix it? Chances are, you won't- not without help from them, assuming they even know what happened. Most NT "fixes" I've seen have been reinstalls or gross restoration of the registry- certainly the skills of a typical administrator do not allow for very much poking around to identify the real source of a problem. If something like that had happened on NT, I bet it wouldn't have been fixed for days, and probably would have required direct assistance from HP.
Oh well. I'm sure that company will dump its "awful Unix" box as soon as it can. Such a shame, isn't it?
Got something to add? Send me email.
(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version
Increase ad revenue 50-250% with Ezoic
Inexpensive and informative Apple related e-books:
El Capitan: A Take Control Crash Course
Sierra: A Take Control Crash Course
Take Control of OS X Server
Take Control of the Mac Command Line with Terminal, Second Edition
Yosemite Crash Course