Solved

Printing from HP-UX via Linux to JetDirect Printers

Posted on 2000-03-09
25
646 Views
Last Modified: 2013-12-15
What configuration needs to be made in order to print from HP-UX via a Red Hat 6.1 Linux system to a JetDirect controlled printer?

I am able to print successfully from Windows via Samba on Linux to these printers.  However, print jobs sent from an HP-UX system to the same printers stay in the spool folder and don't move on to the printer.  One big difference I've noticed is that the Windows print control and data files show up in the Linux queue with a "cfA..." and "dfA..." naming convention.  But the HP-UX print control and data files show up as "cA..." and "dA..." (without the "f").  I am suspecting that Linux does not know how to handle the difference in the name convention and there should be a simple configuration setting somewhere in the printcap file.

Our HP-UX boxes are using LP and our Linux box is using LPD.  By the way, I can print from the Linux box to these same printers but not from HP-UX across the net through the Linux.
0
Comment
Question by:tompet
  • 9
  • 9
  • 6
  • +1
25 Comments
 
LVL 40

Expert Comment

by:jlevie
ID: 2602055
Why not use HP's Jetdirect software on the HP-UX boxes to print directly the JetDirect?
0
 

Author Comment

by:tompet
ID: 2602240
jlevie,

Thanks for your comment.  Yes, we can do that.  But we are conducting a feasibility study to see if we can replace about a thousand HP-UX print servers and about a thousand NT print servers with about only 500 Linux print servers which could serve both sides of this heterogenous network.

Thanks in advance for any ideas.  ;-)
0
 
LVL 40

Expert Comment

by:jlevie
ID: 2603260
Okay, fair answer. I think I may have seen a way to fix the problem and I'll try to dredge up the info.
0
 

Author Comment

by:tompet
ID: 2605236
jlevie,

Thanks for your continued help.  This one is frustrating and I've even tried using ":bk:" entry in the printcap file on the Linux box which failed to produce satisfactory results.  Unfortunately, I haven't been able to find any references to this issue in the man pages or on the internet.  Could be possible that I'm just not getting that lucky hit for information because it would be hard to believe that no one else has crossed this bridge.

tompet
0
 
LVL 40

Expert Comment

by:jlevie
ID: 2609756
Yeah you'd think that there ought to be some information out there on this as a problem, but I'm not having any better luck. Have you condsidered trying Solaris 8 on intel instead of RedHat? The price is certainly right (see http://www.sun.com/software/solaris/binaries/).

Solaris is a little pickier about the hardware as it doesn't support as wide a range of devices as Linux does (see http://soldc.sun.com/support/drivers/hcl/index.html), but on the right hardware it is incredibly robust and Sun's support is excellent. Solaris uses the SysV LP model, but also provides LPR/LPD capabilities and might mesh better with HP-UX.
0
 
LVL 2

Expert Comment

by:mapc
ID: 2645372
ho well..
Moving to solaris because some little bug is a way to solve problems...
But, first of all, add ":lf=/var/log/lpd.log" or something similar to /etc/printcap, then, run lpd in debug mode (-d?), play with it, post the results back.
What are you using to print to the JetDirect printer from linux?
Are you sure that the _QUEUE_ name you're printing from HP/UX _is_ the queue you're running on linux?
0
 

Author Comment

by:tompet
ID: 2645466
Now we're getting an excellent dialogue going.  Mr. jlevie's Solaris suggestion would have been a viable consideration were it not for licensing costs.  I have to agree with him that it might mesh better with HP-UX.
Mr. mapc also provides a couple of good suggestions that I will look into.  To answer his question as to the queue naming convention, yes the queue names match up well.  In fact, when sending a print job from an HP-UX through the Linux box, the print jobs make it to the correctly named spool directory but then stick there and don't move on to the printer.
I'll try the ":lf=/var/log/lpd.log" suggestion and post back with results.  Perhaps they may prove meaningful to one or both of you gentlemen.
Thank you for your continued interest in this sticky problem.  I still feel like it's going to turn out to be one of those "kick myself" for not having thought of the simple answer.  ;-)
Regards,
tompet
0
 
LVL 40

Expert Comment

by:jlevie
ID: 2645516
Have you looked at Sun's page? There is no licensing fee for home or commercial use.
0
 
LVL 2

Expert Comment

by:mapc
ID: 2645521
As a matter of fact this _is_ going to be something simple that slipped through the fingers.
Anyhow, even if it's not, there's many other solutions, LPRng just to name one of them.
Now, is it the same lpd you're using to get the job from network and the one which dispatches the jobs?
The reason I'm asking is since on sysV, say, solaris, it's done diffenrenly - there's a lpd (get from net) and lpsched (print), in aix the lpsched is called qdaemon. Since this is linux, this is not the expected behaviour - linux always came with bsd lpd, and this is what you've described. But, worth asking.
BTW, again, what (how?) you're using to print to JetDirect? is it a script you wrote?
Other thing to check is truss (strace in linux?) -p pidoflpd and see what it does. There's simply no unsolvable issues with unix :)
0
 
LVL 2

Expert Comment

by:mapc
ID: 2645610
jlevie: quite interesting, could you provide a link? I know that we just paid for some solaris2.6 and 7 servers could we get our money back?
0
 

Author Comment

by:tompet
ID: 2645885
We've looked at Sun but there's this humongous Linux push at our company.  So we are experimenting to rapidly put Linux into places where it may serve a cost effective purpose.
Your question as to whether lpd is the same on the HP-UX as the lpd which dispatches the job (from Linux spool, I presume) is where there may be a difference.  Our HP-UX is SysV based and Linux is BSD based.  What's interesting is that print jobs sent from an NT machine show up and leave the Linux queue with a "cfA..." and "dfA..." name style.  Print jobs sent from an HP-UX machine show up and stick in the Linux queue with a "cA..." and "dA..." name style.  If the fundamental difference in the spool styles is the problem, then Linux does not know how to handle the HP-UX files when they show up so they just stick there.  It's still frustrating because you'd think someone else would have already tried this "HP-UX -> Linux -> JetDirect printer" scenario and either were successful or found a solution.
REgarding how I print to JetDirect from NT through Linux?  I've setup Samba on Linux, installed the printers using printtool as a "Remote Unix (lpd) queue" printers, and Samba very nicely presents them to the NT world.  That side works wonderfully so we could conceivably eliminate hundreds of NT print servers and save $$$$ .  This HP-UX side is the sticky wicket though.  If we can overcome this the savings for every company could be astronomical by moving to opensource Linux.
0
 
LVL 40

Accepted Solution

by:
jlevie earned 100 total points
ID: 2645918
As to the link, I already did, but here it is again: http://www.sun.com/software/solaris/binaries/

The problem with the spool file names is that NT is using LPD/LPR (BSD) semantics for the interaction and the HP-UX systems are using LP (SYSV) semantics and the two aren't compatible. The prime reason I suggested Solaris is that it has a hybrid LPD/LP printing system and can accept and/or send both types at the same time.
0
Maximize Your Threat Intelligence Reporting

Reporting is one of the most important and least talked about aspects of a world-class threat intelligence program. Here’s how to do it right.

 

Author Comment

by:tompet
ID: 2645947
That seems to be what we are zeroing in upon...Have you ever heard of this "semantics" incompatibility being overcome?  A fellow print techie suggested we might be able to write a script to overcome this because, in his opinion, the problem might have something to do with the sequencing of the print commands as presented in the data files when they show up in the Linux queue.  We would like to see Linux have the same type of hybrid LPD/LP printing system like Solaris.  If we fix this I think the three (or 4) of us should get together and consider forming a consortium ;-) .
0
 
LVL 40

Expert Comment

by:jlevie
ID: 2646127
It's more than just the queue names. By semantics I was referring to the entire process including the protocol differences. And yes I'm certain I could solve the problem in some manner (modifying the print system source if necessary). But, you have to consider how supportable the result will be. If source changes are necessary, those changes may or not make their way into the distributions. If the Linux community as a whole doesn't see the need for them they won't be accepted. Then you are in the position of having to support it yourself, which means that you'll need to examine & modify the source for each new release and replace the distributed version with your custom version. ...Just some food for thought...
0
 
LVL 2

Expert Comment

by:mapc
ID: 2648807
excuse me, jlevie, but what you're saying is nonsense.
I invite you to check:
http://www.faqs.org/rfcs/rfc1179.html
Which is the RFC for line printer protocol.
The local handling of print jobs is different accross platforms, but, lp protocol is unifiorm.
Ok, now you've two choices:
Go with LPRng:
http://www.astart.com/lprng/LPRng.html
It has both BSD and SysV support, and should be generally better.
Oo, enable more aggressive logging, and, perhaps strace -p pidoflpd , send jobs, etc. and post it back, then, perhaps some changes
Some other question..
Since jobs from windows travel across SMB, and then send to printer as local jobs using lpr command, and HPUX are delivered through lpd (port 515) there's a big difference.
Try printing VIA this print server FROM another linux, or solaris, or even windows LP client.
Post back the results.
Take care.
(I suspect a bug in LPD)
0
 
LVL 40

Expert Comment

by:jlevie
ID: 2648942
And you're wrong mapc. That RFC states very specifically that it documents the Berkeley LPR/LPD protocol, not the SYSV LP protocol. I almost know it by heart as I've written both an LRR/LPD and an LP mini-spooler for use in an embedded processor, and the two protocols are different, period.
0
 

Author Comment

by:tompet
ID: 2649496
Yet another excellent exchange of intellectual ideas, theorems, and suggestions at this forum!  Both of you have provided invaluable information thus far.  I'm going to accept both of your considerate and thoughtful input and start crunching now.  I'll post back with results in a few days.  One more thing, I'm hailing from Colorado Springs, CO.  Where are you guys operating out of?
Best regards,
tompet
0
 
LVL 40

Expert Comment

by:jlevie
ID: 2650467
I'm in Huntsville, AL
0
 
LVL 2

Expert Comment

by:mapc
ID: 2652641
I'm from Israel.
jlevie: the network lp protocol is uniform, for example: we always printed from DEC UNIX 4.0f via AIX 4.2.1, and never had problems.
In another installation FreeBSD happily prints via Solaris. This is BSD->SysV though. In another place IRIX to Linux, thus we have it all. SysV->BSD.
I didn't see HP/Ux to bsd though.
Anyhow, I still *think* that there's a bug in this linux lpd.
tompet: have you tried printing from another bsd unix via this linux print server?
0
 

Author Comment

by:tompet
ID: 2653309
We don't have any BSD HP-UX boxes.  But we are setting up another BSD Linux system and once it has been properly configured and joined to the network I'll try to print from it via the first Linux box.  Then we can try vice-versa with a different neetwork printer installed on the second Linux box.  This could prove your possibility of a bugged lpd on the first Linux installation.  We'll try this today.
0
 
LVL 4

Expert Comment

by:kiffney
ID: 2653368
just a comment - mapc has suggested LPRng a couple of times, and I've used it here for a couple of intractible jetdirect problems - specifically, printing to some older jetdirect internal cards that have to have their data stuffed into port 9100 (I think it was).  LPRng handled that fine but the linux lpd could not deal with it.  The newer jetdirect cards run their own lpd - I'm just wondering why you don't just print directly to the jetdirect daemon and skip the print servers entirely?  (I'm sure there's a good reason - I've just never worked in that big an environment and am curious why that wouldn't work)
0
 

Author Comment

by:tompet
ID: 2653703
Good question.  It may seem like we're trying to do it the hard way but there's a method to our madness.  Here's what we have to deal with, a worldwide enterprise heterogenous network with HP-UX workstations, HP-UX servers, NT Workstations, NT Servers, and Windows 98 laptops.  Consider the licensing cost of just one HP-UX OS and the motivation to try Linux quickly becomes apparent.  Now let's say your workstation is an HP-UX machine and you normally print through another HP-UX print server for desktop applications.  Now through into that your coworker works on an NT Workstation and he prints to the same printer, except through an NT print server.  The duplication of two different OS servers to offer printing for the same printer is a cost redunduncy.  Now multiply that situation by around a thousand and you see why.  Although I'm just a support grunt in the spool print services of our company who is trying to pare this down to just one server, I still feel like a lone wolf because everyone else seems to be happy with the way things are.
My vision?  One Linux print server for each 50 printers serving both Windows and HP-UX Unix environments.  It can be done and I've proven the Windows side on a small scale (using Samba) and only have left to integrate Unix to print through the Linux box.
Hope that helps to answer why.  ;-)
0
 
LVL 2

Expert Comment

by:mapc
ID: 2654784
kiffney: yes, but it's not "older" but "cheaper" jetdirect cards.
They expect print job on port 9100 without any protocol.
The freebsd handbook has a simple perl script for an input filter for those beasts.
tompet: I suspect that the lpd is buggy in this linux distribution.
Depends on your taste, you may either modify/fix your current lpd, or go with lprng as I mentioned earlier.
We're waiting for you.
0
 

Author Comment

by:tompet
ID: 2822685
Comment for jlevie, mapc, and kiffney:

It seems like a long time but have found a solution to printing from HP-UP (SysV) through a Linux (BSD) box to a jetdirect network printers.  It seems the solution is to tell HP-UX that the printer you are setting up is going through a BSD server thusly:

On Unix when setting up the printer:

lpadmin -p{localprintername} -v/dev/null -mrmodel -orm{remote.server.name.com} -orp{remoteprintername} -ocmrcmodel -osmrsmodel -ob3 [ENTER]

The key switch is "-ob3" which tells Unix that the printer you are setting up is going through a BSD style remote print server (ie: Linux).
0
 
LVL 40

Expert Comment

by:jlevie
ID: 2824019
Yep, that is what's needed as ordinarily UP-UX is going to use SysV lp/lpsched protocols which is incompatible with Linux's BSD lpr/lpd implementation.
0

Featured Post

Do You Know the 4 Main Threat Actor Types?

Do you know the main threat actor types? Most attackers fall into one of four categories, each with their own favored tactics, techniques, and procedures.

Join & Write a Comment

I am a long time windows user and for me it is normal to have spaces in directory and file names. Changing to Linux I found myself frustrated when I moved my windows data over to my new Linux computer. The problem occurs when at the command line.…
Over the last ten+ years I have seen Linux configuration tools come and go. In the early days there was the tried-and-true, all-powerful linuxconf that many thought would remain the one and only Linux configuration tool until the end of times. Well,…
Learn how to get help with Linux/Unix bash shell commands. Use help to read help documents for built in bash shell commands.: Use man to interface with the online reference manuals for shell commands.: Use man to search man pages for unknown command…
This demo shows you how to set up the containerized NetScaler CPX with NetScaler Management and Analytics System in a non-routable Mesos/Marathon environment for use with Micro-Services applications.

757 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

22 Experts available now in Live!

Get 1:1 Help Now