Hi all,

I have a couple of machines here, grover and zaphod, both
running Solaris 9. I also have a Lexmark Optra S1255N
network laser printer. Grover is an SB 100, on which I
have installed Lexmark's Markvision software (as I have
sveeral times in the past).

The name of the printer is laser1, as is the queue.

I can print using lp from grover no problem. What I would
like to do is set up zaphod to forward all of its print
requests to laser1 on grover. I've read the lpadmin etc.
man pages, and the Sys Admin Answer book, with no joy.

To enable remote printing on zaphod, I used these commands:

# lpadmin -p laser1 -s grover
# lpadmin -d grover:laser1
# lpstat -t
scheduler is not running
system default destination: grover:laser1
system for _default: grover (as printer laser1)
system for laser1: grover
_default accepting requests since Aug 17 18:55 2003
laser1 accepting requests since Aug 17 18:55 2003
printer _default unknown state. enabled since Aug 17 18:55 2003. available.
printer laser1 unknown state. enabled since Aug 17 18:55 2003. available.

This is the error I get when I try to print a file from
zaphod using lp:

rich@zaphod4753# lp mozilla.ps
request id is laser1-17 (1 file)
Message from rich on zaphod (???) [ Sun Aug 17 18:57:22 ] ...

Error transfering print job 17
check queue for (laser1@grover)
<EOT>


Finally, here's grover's lpstat output:

# lpstat -t
scheduler is running
system default destination: laser1
device for laser1: /dev/null
device for laser1mp: /dev/null
system for _default: grover (as printer laser1)
character set
laser1 accepting requests since Sun Aug 17 16:36:56 2003
laser1mp accepting requests since Sun Aug 17 17:19:51 2003
_default accepting requests since Sun Aug 17 16:36:56 2003
printer laser1 is idle. enabled since Sun Aug 17 16:37:03 2003. available.
printer laser1mp is idle. enabled since Sun Aug 17 17:19:51 2003. available.


Can someone please tell what I'm doing wrong?

Many TIA,

--
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

Rich Teer <rich.teer@rite-group.com> writes:
>
>I can print using lp from grover no problem. What I would
>like to do is set up zaphod to forward all of its print
>requests to laser1 on grover.
>
>To enable remote printing on zaphod, I used these commands:
>
> # lpadmin -p laser1 -s grover
> # lpadmin -d grover:laser1
>

lpadmin -x laser1
lpset -x _default
lpadmin -p laser1 -s grover\!laser1
lpadmin -d laser1


-Greg
--
Do NOT reply via e-mail.
Reply in the newsgroup.

On Mon, 18 Aug 2003, Greg Andrews wrote:

> lpadmin -x laser1
> lpset -x _default
> lpadmin -p laser1 -s grover\!laser1
> lpadmin -d laser1

Thanks, but still no joy. :-( I get exactly the same
error.

I must be missing something really dumb...

--
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

Rich Teer <rich.teer@rite-group.com> writes:
>
>Thanks, but still no joy. :-( I get exactly the same
>error.
>

On grover, run these commands:

pmadm -r -p tcp -s lpd
pmadm -r -p tcp -s lp
pmadm -r -p tcp -s 0 <-- that's a zero

And then make sure grover's inetd is running in.lpd for connections
to the "printer" service. The third field should be "tcp6".

-Greg
--
Do NOT reply via e-mail.
Reply in the newsgroup.

In comp.unix.solaris Rich Teer <rich.teer@rite-group.com> wrote:
> Hi all,

Hi! Excitement! (giggle)

> To enable remote printing on zaphod, I used these commands:
>
> # lpadmin -p laser1 -s grover
> # lpadmin -d grover:laser1
> # lpstat -t
> scheduler is not running
> system default destination: grover:laser1
> system for _default: grover (as printer laser1)
> system for laser1: grover
> _default accepting requests since Aug 17 18:55 2003
> laser1 accepting requests since Aug 17 18:55 2003
> printer _default unknown state. enabled since Aug 17 18:55 2003. available.
> printer laser1 unknown state. enabled since Aug 17 18:55 2003. available.
>
> This is the error I get when I try to print a file from
> zaphod using lp:
>
> rich@zaphod4753# lp mozilla.ps
> request id is laser1-17 (1 file)
> Message from rich on zaphod (???) [ Sun Aug 17 18:57:22 ] ...
>
> Error transfering print job 17
> check queue for (laser1@grover)

Some hacking around to try...

Go into lpc and issue starts. "Unknown state" is something to fix.
Try lpr instead of lp. I keep getting confused on that.

Good luck! I take it you've got no book chapter on this. ;-)

-am © 2003

HI,


Rich Teer wrote:
> On Mon, 18 Aug 2003, Greg Andrews wrote:
>
>
>>lpadmin -x laser1
>>lpset -x _default
>>lpadmin -p laser1 -s grover\!laser1
>>lpadmin -d laser1
>
>
> Thanks, but still no joy. :-( I get exactly the same
> error.
>
> I must be missing something really dumb...
Make your life easy and see the light in printer admin.

http://www.easysw.com/printpro/


http://www.cups.org/


/michael

In article <iz%%a.24606$dP1.54941@newsc.telia.net>,
Michael Laajanen <michael_laajanen@yahoo.com> writes:
> HI,
>
>
> Rich Teer wrote:
>> On Mon, 18 Aug 2003, Greg Andrews wrote:
>>
>>
>>>lpadmin -x laser1
>>>lpset -x _default
>>>lpadmin -p laser1 -s grover\!laser1
>>>lpadmin -d laser1
>>
>>
>> Thanks, but still no joy. :-( I get exactly the same
>> error.
>>
>> I must be missing something really dumb...
> Make your life easy and see the light in printer admin.
>
> http://www.easysw.com/printpro/
>
>
> http://www.cups.org/
>


No doubt it's great, but you do _not_ need to replace the existing
printing subsystem; you just need to learn a few tricks and make it
work. The problem isn't that it's not flexible enough, it's that
damn near nobody seems to actually understand it!

--
mailto:rlhamil@mindwarp.smart.net http://www.smart.net/~rlhamil

HI,

> No doubt it's great, but you do _not_ need to replace the existing
> printing subsystem; you just need to learn a few tricks and make it
> work. The problem isn't that it's not flexible enough, it's that
> damn near nobody seems to actually understand it!
Yes, you are right it is as flexible as the whole Unix system

But sometimes it is wise to take a shortcut )

/michael

On Mon, 18 Aug 2003, Greg Andrews wrote:

> On grover, run these commands:
>
> pmadm -r -p tcp -s lpd
> pmadm -r -p tcp -s lp
> pmadm -r -p tcp -s 0 <-- that's a zero
>
> And then make sure grover's inetd is running in.lpd for connections
> to the "printer" service. The third field should be "tcp6".

Bingo - success! Many thanks. Now I have some man pages
to read, as I thought that the port monitor was associated
with serial terminals (ahh, but on reflection, that's ttymon).

It would be nice if the printing part of the Sysadmin Docs
mentioned these handy commands, though...

Thanks again,

--
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

Rich Teer <rich.teer@rite-group.com> writes:
>On Mon, 18 Aug 2003, Greg Andrews wrote:
>
>> On grover, run these commands:
>>
>> pmadm -r -p tcp -s lpd
>> pmadm -r -p tcp -s lp
>> pmadm -r -p tcp -s 0 <-- that's a zero
>>
>> And then make sure grover's inetd is running in.lpd for connections
>> to the "printer" service. The third field should be "tcp6".
>
>Bingo - success! Many thanks. Now I have some man pages
>to read, as I thought that the port monitor was associated
>with serial terminals (ahh, but on reflection, that's ttymon).
>
>It would be nice if the printing part of the Sysadmin Docs
>mentioned these handy commands, though...
>

The TCP listeners should have defaulted to off back in Solaris 2.6,
when they were obsoleted in favor of the in.lpd daemon that's run
out of inetd. However, someone dropped the ball and they were left
on.

Most of the time, they don't cause a problem. Inetd is started in
the middle of the /etc/rc2.d scripts and the TCP listeners aren't
started until long afterward, when sac is started after all the
/etc/rc2.d and /etc/rc3.d scripts are finished. So the problem is
hidden most of the time. Inetd wins the race to bind to the socket,
and is able to invoke the proper daemon - in.lpd.

Until you kill and re-invoke inetd. While inetd is down, the "lpd"
TCP listener grabs the printing socket. Since the Unix domain socket
and other behind-the-scenes support for the old TCP listener is no
longer there, it can't do anything useful with the socket. It just
accepts connections, errors out, and breaks the connections.


Turning off the TCP listeners with those pmadm commands kills them
for good. They won't come back unless you re-install or some other
software turns them back on.

-Greg
--
Do NOT reply via e-mail.
Reply in the newsgroup.