sscott@camdev.UUCP (Steve Scott) (02/27/90)
After updating my operating system(s) from HP/UX 6.5 to HP/UX 7.0
(on HP9000 3x0 boxes), the following scenario occurs:
I have a machine (say cammax) which does not have a laser printer
connected to it. But I do have a machine (say camdev) which does.
On cammax, I put a script in /usr/spool/lp/model which contained
the following pertinent line
cat $file | remsh camdev lp
(remsh is HP's rsh (remote shell command))
Under 6.5, this worked just fine.
But, under 7.0, the weirdness begins:
On cammax, if I type
cat file_name | remsh camdev lp
everything works just fine (like it did under 6.5)
BUT:
if I say lp file_name (on cammax), nothing prints on camdev.
I have traced the problem this far:
When the remsh is performed on cammax (by hand), the temporary files
on camdev (the cAxxxxcamdev and dAxxxxcamdev ones in
/usr/spool/lp/request/lp) have permission 400 and owner = lp (grp = bin).
When the remsh is performed on cammax (via the script), the files reach
camdev BUT the cAxxxxcamdev file has permission 400 and owner = root
It appears that this causes the error:
"cannot lock file cAxxxxcamdev"
So: 1) why did this work under 6.5 and not HP/UX 7.0:
AND
2) why would the owner on the temp files be lp when remsh
executed interactively and the owner on the temp files
be root when executed via the script?
I guess I oughta tell you that I am logged in as sscott (for example),
so the owner of the file in neither case has the same owner as the
person logged in at the time of invocation
Any ideas? I'm pulling my hair out. If I haven't explained this
problem well enough, please email me at sscott@mot.com or call
--
Steve Scott UUCP: {texbell|texsun}!csccat!camdev!sscott
Motorola, Inc. Internet : sscott@mot.com Telephone : 1-817-232-6317lienhart@hpfcdc.HP.COM (Bob Lienhart) (03/01/90)
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