Hello,
What I see is that on my i, I would run the ssh -L oricess, listening
to some specified port that was used in the created DEVD.
Sorry, I was under the impression that you were using LPR. The PORT
specified on a DEVD is not for LPR, it's for one of PJL, IPP or SNMP.
You can't do LPR with a DEVD.
I think I would still need to spawn that ssh -L process to allow use
of user name and password verification on the remote system, wouldn't I?
Yes, you'd have one job that's keeping the SSH tunnel open (via Expect
script most likely.) And another job that's doing the actual printing.
So, I think I would create a DEVD with port 21345 (for example) on
local system, then the ssh command would then use 21345 instead of 7777
in your example. Also, instead of using port 515, I would use anotehr
port, such as 29488 on the remote system. Assuming the firewall was
allowing that port, an additional ssh -L on that system would then
redirect the received data stream from 29488 to a specific IP address
inside their firewall and also back to port 515.
How does does having a separate ssh -L on the remote system help?! You
only need one ssh -L as far as I can tell.
Assuming you don't really need LPR (which was the big unsolvable
problem) and are able to use a DEVD-type connection then you could do this:
CRTDEVPRT DEVCLS(*LAN) LANATTACH(*IP)
RMTLOCNAME('127.0.0.1') PORT(21345)
SYSDRVPGM(*IBMPJLDRV)
(fill in other parameters, above, appropriately)
This says that when the writer is running, it makes a connection to the
SAME COMPUTER (127.0.0.1) on port 21345. That means that as far as the
writer knows, it's not connecting to a remote system at all, it's
connecting to the local computer. And that's what you want.
Before starting the writer, you do something like this (via an Expect
script, spawned and waiting in the background)
ssh -L 21345:RemotePrinterIP:9100 -l userid RemoteSSHDComputer
This ssh connection, while active, opens up a tunnel from port 21345 on
your local computer. It sends it across the Internet on port 22 (SSH)
until it gets to the Remote SSD computer. While travelling through that
port 22, the data is encrypted, protected, etc. The remote SSHD
computer then decrypts it and forwards the data on to port 9100 on
RemotePrinterIP.
Note that I change the port to 9100, which is a more likely port if
you're using PJL.
The problem here is that you said you wnated to use LPR. CRTDEVPRT
cannot create LPR connections. You have to use one of the SNDTCPSPLF,
LPR, or a remote output queue if you want to do LPR. And these don't
let you specify a port.
For PJL, it should work fine.
midrange.com
