Re: Telnet printing
From: Brian K. White (brian_at_aljex.com)
Date: 01/29/04
- Next message: Brian K. White: "Re: open command failing on serial port"
- Previous message: Joe Dunning: "Re: No longer supporting Unixware / Open Server"
- In reply to: Robert Bachellor: "Telnet printing"
- Next in thread: Scott Burns: "Re: Telnet printing"
- Reply: Scott Burns: "Re: Telnet printing"
- Reply: Bill Vermillion: "Re: Telnet printing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 28 Jan 2004 16:51:31 -0800
"Robert Bachellor" <rob@alphaomegas.com> wrote in message news:<LNWdnfBPhsoFm4XdRVn-sA@thebiz.net>...
> We have a remote client using DSL with dynamic IP addressing to telnet back
> into the SCO OS5 server. He is using ICE.TCP Pro which comes with an LPD
> program for Windows. My problem is how to define a printer on the server so
> that his reports go to his LPD interface so he can print them.
>
> Any help is greatly appreciated.
>
> Thanks,
> Rob
I would use passthru-printing before I got entangled in defining a
bunch of lpd printers to non-static ip's. You don't have to configure
printers into the spooler for that, and you don't care the slightest
little bit about what the users IP is, if it was different 10 minutes
ago, or how they are connecting to the box (serial dialup, telnet,
ssh, facetwin, local lan, internet etc...), or how they are connecting
to the internet (direct dialup, behind a firewall, port-forwarding,
nat, etc...)
But, passthru has it's own few issues. You can't just define a virtual
printer that sends the data back to your tty because applications
typically run a print job in the background and proceed to write to
the screen as normal immediately. With passthru, you send an escape
code to the terminal and some print data and another escape code.
between the two escape codes there should be only print data, but if
the application wasn't specifically programmed to provide passthru
print functionality, it won't know that it shouldn't write to the
screen while the print data is coming through. So, some applications
have a specific feature to print with passthru, or to print using a
program of your choosing, and knows enough to wait while that program
runs.
If you can't do that, then you need to do two things:
1) anyone who has a dynamic IP and want's to print to themselves via
standard lpd protocol, needs to get a dyndns.org account. That gives
you a hostname, which stays the same, which tracks the dynamic IP, as
long as the user runs a good dyndns.org updater client. If you have a
lot of cable accounts with basic internet sharing routers, some of
them have dyndns.org updaters built right in so you don't need to run
anything on any computer to update dyndns.org, but if the IP's don't
actually change very often, then the router will not update dyndns
except after a power-cycle or when the IP actually changes, which may
be several months on end with no changes or power-cycles, and in that
case, dydndns.org times-out your account after 35 days without
activity. So $10 gets you an account that won't time out.
2) the remote users either need to be directly connected to the
internet (IE: dialu-up like aol, at&t, earthlink, etc... or their PC
is directly connected to their dsl/cable modem) or, you need to
configure port-forwarding rules in the remote users router to forward
tcp port 515 from the internet in to the PC that the printer is
attached to, and that pc needs to stay turned on even when that user
is not around if you want other people in the same remote office (or
indeed other people anywhere who connect to the system) to be able to
print to that printer.
Then you go and set up the lpd server on the remote pc's (windows 2000
and xp have lpd server built-in you know, you have to install it from
"add/remove programs, windowscomponents) but it's there and you don't
even need the windows cd usually.
Then you set up the printers in unix as remote lpd printers and use
the hostname that you gave yourself in dydns.org and the printers
"share as" name in windows (if you used the built-in lpd server)
then after all that, you will very likely have to stop & restart the
unix spooler a lot to re-enable printers that get "stuck" when the
transient remote ip goes away from being powered-off or the ip changes
and dydns takes a little while to propogate the change...
It's never going to work _well_, but that's the best you can do.
hmmm....
with some fancy scripting, you *could* make it pretty reliable and not
need dyndns.org...
install rlpr:
rftp -g -bh pcunix.com /pub/bkw rlpr.tar.bz2
bzcat rlpr.tar.bz2 |tar xvf -
(if you don't have bzip2 it's available several places
including:
rftp -g -bh pcunix.com /pub/bkw bzip2.tar.Z
zcat bzip2.tar.Z |tar xvf -
)
then, look at tony lawrences web site articles about netcat, but in
the sample printer interface script replace "|nc -h $PRTHOST -p
$PRTPORT"
with "|/usr/local/bin/rlpr -H $PRTHOST -P $PRTPORT"
and comment out the part that reads /etc/printers
create a single unix printer using /dev/null as the destination device
and this interface script as the model, and name it "myprinter"
then, in /etc/profile or in individual .profiles you:
* get users ip and put it in PRTHOST and export it
PRTHOST=`who -umx | awk '{ print $6 }'` ; export PRTHOST
* define PRTPORT as the share name of the printer in windows
(in the case of the windows built-in lpd server, otherwise
it's the lpd queue name configured in the lpd server.)
PRTPORT=HP1200 ; export PRTPORT
getting the ip using the method above can be done right in
/etc/profile one time for everyone.
setting the printer share name will have to be done seperately in
users .profiles, or, some telnet clients allow you to specify
environment variables right in the client config so when you log in
they are already set and you dont do anything in either profile except
export the already set variable, or you can tell all remote users to
use the same lpd queue name in the lpd server and you could set that
name in /etc/profile.
put something in /etc/profile or maybe in the printer interface to
detect if PRTHOST or PRTPORT is undefined and use some sane default or
in the case of the printer interface you could detect that and simply
exit immediately without trying to print instead of letting errors be
generated and eventually fill your hd with mail that no one reads.
Basically, you need to do something to deal with what happens if a
user who does not have his own remote printer tries to print to
"myprinter"
then whenever any user prints to "lp -d myprinter" it goes to "their"
printer.
this will also work for everyone else in a remote office besides the
actual person with the orinter if they are sharing a single net
connection and the pc with the printer is turned on. they will all get
the same value in PRTHOST so they can print to "myprinter" as long as
that PC is turned on in their office.
This also avoids the problem of normal lpd printers self-disabling,
since the printer is created as a "local" printer to device /dev/null.
This also keeps lpstat from hanging for long times trying to get the
status of remote printers via lpd.
- Next message: Brian K. White: "Re: open command failing on serial port"
- Previous message: Joe Dunning: "Re: No longer supporting Unixware / Open Server"
- In reply to: Robert Bachellor: "Telnet printing"
- Next in thread: Scott Burns: "Re: Telnet printing"
- Reply: Scott Burns: "Re: Telnet printing"
- Reply: Bill Vermillion: "Re: Telnet printing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
