Best of the Newsgroups: remote lpd dhcp without vpn

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: brian@aljex.com (Brian K. White)
Subject: Re: Telnet printing
Date: 28 Jan 2004 16:51:31 -0800
Message-ID: <60bd4c6b.0401281651.7c32ea18@posting.google.com> 
References: <LNWdnfBPhsoFm4XdRVn-sA@thebiz.net> 

"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.

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.