Need help with weird lp problem
Bob Lienhart
lienhart at hpfcdc.HP.COM
Thu Mar 1 05:20:56 AEST 1990
The root of the problem here is that user "lp" can not print!
Sounds kind of foolish, but on most systems lp is a pseudo-user.
The problem was introduced when the long-standing defect related
to "I can't print a file that I do not own, but I can read". This
has been corrected, but now user "lp" can't print.
In the example refered to in the basenote, the interface script with
the remsh call is being executed by user "lp" -- hence the aborted
execution. In this case there is a simple fix. Use the new sys
admin manager program, sam, to delete the old printer. Then use
sam again to add a remote printer, choosing the default remote model.
This should work well, especially since the old remsh method already
required proper access on the remote system.
But this problem also shows up in other instances. If any pre-formatting
is performed by a pseude-printer, for example a troff pre-processor, the
call to an actual printer device will be executed by user "lp". If this
happens, then I would suggest the following work around:
chown lp /usr/bin/lp
chgrp bin /usr/bin/lp
chmod 6555 /usr/bin/lp
This will of course break the original fix, but I have seen no further
side effects as of yet.
Bob Lienhart
More information about the Comp.unix.wizards
mailing list