NT vs. Linux - driven to Windows?
There are no intelligent answers for
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
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
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
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.
Increase ad revenue 50-250% with Ezoic
More Articles by Tony Lawrence
Find me on Google+
© 2013-08-18 Tony Lawrence