[comp.sys.hp] Bug:

krishnan@uceng.UC.EDU (Ramaswamy Krishnan) (04/11/90)

In article <1768@sparko.gwu.edu> kelso@seas.gwu.edu (John Kelso) writes:
>
>When printing to an HP 835 running HP-UX 3.1 using the remote printer
>capability, we have noticed that if the remote machine has a hostname
>of more that 8 characters, the file is never printed.  The file is
>transferred to the HP's /usr/spool/lp/request/printer directory, but
>the printer software chokes, leaving a df and tf file, and a zero size
>cf file.

We had the same problem here when we installed 3.1 last year, and
the response center could not help.  They claimed it was some file
ownership/mode problem in our system and asked us to reinstall the
lp part, but that did not help (just wated an afternoon).  Anyway,
we finally set up a simple rsh hack.

But with the upgrade to 7.0, this problem seems to be solved!

But of course... we have a new one now.
Users now cannot print from our HPtoday database program.

-------- begin problem statement ------------------

We set up a queue called hpt_lp (actually HPtoday did) as follows:

$ /usr/lib/lpadmin -phpt_lp -v/dev/null -mhpt_lp

and here is the main line from the interface file for hpt_lp :

lp -d"$reqdevice" -o"$optionlist" -n"$copies" -t"$title" $files

WHERE files ARE DATA FILES IN THE hpt_lp QUEUE.

So, essentially the interface file uses the lp command to print
the data files in the hpt_lp queue (now, please don't ask me why
set up hpt_lp at all - HPtoday needs it).

Here is my script recording :

$
$ who | lp -dhpt_lp
request id is hpt_lp-22 (standard input)
$
$ ll /usr/spool/lp/request/hpt_lp
total 4
   2 -r--r-----   1 lp       bin          100 Apr 10 22:44 cA0022uceng
   2 -r--r-----   1 lp       bin          520 Apr 10 22:44 dA0022uceng
$
$ ll /usr/spool/lp/request/lp
total 4
   2 -r--r-----   1 root     bin          166 Apr 10 22:44 cA0023uceng
   2 -r--r-----   2 lp       bin          520 Apr 10 22:44 dA0023uceng
$
$ tail -3 /usr/spool/lp/log
hpt_lp-22	krishnan	hpt_lp	Apr 10 22:44
lp-23		lp		lp	Apr 10 22:44
/usr/lib/lpsched: Unable to open and lock "request/lp/cA0023uceng"

== and ... I get a mail : "error 1 from printer for hpt_lp-22..."
== See the problem ?  cA0023uceng is owned by root!
== ... so lp cannot open/lock it.
==
== Q : how come the interface file is exec'd by lp (assured
==     by 2nd line in the above tail command where user is lp) ?
== A : probably because /usr/bin/lp is suid (see further below)
==
== Now for the regular lp command (which works correctly) :

$
$ who | lp
request id is lp-24 (standard input)
$
$ ll /usr/spool/lp/request/lp
total 4
   2 -r--r-----   1 lp       bin           96 Apr 10 22:45 cA0024uceng
   2 -r--r-----   1 lp       bin          572 Apr 10 22:45 dA0024uceng

Here, the cA.. file is owned by lp so there is no problem!

If it is of any relevence :

$ uname -a
HP-UX uceng A.B7.00 C 9000/840 5296
$
$ ll /usr/bin/lp
 272 -r-sr-xr-x   1 root     bin       126976 Nov 22 03:00 /usr/bin/lp
$
$ ps -ef |grep lpsched
      lp 11233     1  0 14:19:59 ?        0:11 /usr/lib/lpsched
$
$ lpstat -t  (partial listing)
scheduler is running
system default destination: lp
device for lp: /dev/lp0
device for hpt_lp: /dev/null
lp accepting requests since Mar  3 04:49
hpt_lp accepting requests since Apr 10 14:19
printer lp is idle.  enabled since Apr 10 16:39
	fence priority : 0
printer hpt_lp is idle.  enabled since Apr 10 16:54
	fence priority : 0


---------------- end of problem statement -------------

Any suggestions/comments/fixes ?   advaTHANKSnce !!

Yes, we are on our way to the response center, but just
cheking here too.  But right now, we are compiling a list
of problems we face right now.  From what it looks like
for now, please hang on... may be you can help us ;-) :-)

--
Ramaswamy Krishnan				Krishnan@UC.EDU (ARPA)
College of Engineering				 uceng!krishnan (UUCP)
Univ. of Cincinnati				 krishnan@ucbeh (BITNET)
____EarthDay_is_coming____plant_a_tree_today____and_earn_your_breath____