This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

OES 2015 SP1 Server, Can't lpr to iPrint lpr Enabled Printer

OES 2015 SP1 server with iPrint installed.
Novell Open Enterprise Server 2015 (x86_64)
VERSION = 2015.1
PRETTY_NAME="SUSE Linux Enterprise Server 11 SP4"
SUSE Linux Enterprise Server 11 (x86_64)

Two iPrint printers are lpr enabled to allow printing from the server to iPrint printers.
Printing from server via lpr or lp has stopped working. Here is test example:

ratchford:~ # lpstat -t
scheduler is running
no system default destination
members of class LaserJet-4345MFP:
members of class LaserJet-Flow-MFP-M630z:
device for LaserJet-4345MFP: ipp://
device for LaserJet-Flow-MFP-M630z: ipp://
LaserJet-4345MFP accepting requests since Wed 31 Dec 1969 07:00:00 PM EST
LaserJet-Flow-MFP-M630z accepting requests since Wed 31 Dec 1969 07:00:00 PM EST
printer LaserJet-4345MFP is idle. enabled since Wed 31 Dec 1969 07:00:00 PM EST
Idle, Subunit Almost Empty
printer LaserJet-Flow-MFP-M630z is idle. enabled since Wed 31 Dec 1969 07:00:00 PM EST
Idle, Subunit Power Saver
lpstat: Success
ratchford:~ # lpr -P LaserJet-Flow-MFP-M630z test.txt
lpr: Forbidden
ratchford:~ # lp -d LaserJet-Flow-MFP-M630z test.txt
lp: Forbidden

Workstations on the network can print to iPrint printers, the same ones, with no problems.


  • Do you have a listener on port 515? If so, which is the owning daemon?
    What does
    iprintman psm -l
    tell you after authenticating?
  • Yes, there is a listener on port 515.
    ratchford:~ # netstat -a -n -p|grep :515
    tcp 0 0* LISTEN 5184/ilprsrvrd
    This is the LPR enabled printers daemon.
    This is the last few lines of the ilprsrvrd.log file.
    Apr 14 23:17:07 2019 WARNING The lpr daemon received signal: 15 from process (5066) running with uid (111).

    Apr 14 23:17:07 2019 INFO ilprsrvrd - LPR Server Daemon is unloading.
    Apr 15 00:50:28 2019 INFO ILprListeningMain() done with socket().

    Apr 15 00:50:28 2019 INFO ILprListeningMain() done with bind().

    These are the only lines in the ilprsrvrd.log file, just repeated over and over.

    Here is the output of the iprintman psm -l.
    ratchford:~ # iprintman psm -l -u cn=admin,ou=ratchford_may,o=ratchford_corp
    Authentication required for ratchford.ratchford-may.local
    Enter your password:
    Name Status Default
    CN=iPrintPrintManager,OU=ratchford_may,O=ratchford_corp RUNNING Yes
    The iPrint PrintManager is running.
    These are the last few line in the ipsmd.log file.
    Apr 14 23:17:06 2019 WARNING The monitor process (5065) received signal: 15 from process (7100) running with uid (0).

    Apr 14 23:17:06 2019 WARNING The print manager (5066) received signal: 15 from "unknown" process (5065) running with uid (111).

    Apr 14 23:17:06 2019 WARNING The print manager (5066) received signal: 17 from "iprintgw" process (5206) running with uid (111).

    Apr 14 23:17:06 2019 WARNING PSMChildSigHandler1: child with pid 5206 exited with exit status 0
  • It seems you haven't configured a (client-side) LPR queue on the box.

    device for LaserJet-4345MFP: ipp://
    should rather read
    device for LaserJet-4345MFP: lpd://
    to have a local queue to lpr to. At least as for specifying to protocol. You won't be able to use dashes in LPR queue names IIRC.
  • I don't think that you understand the problem.

    This is the OES 2015 SP1 server machine with iPrint installed on this machine. Since iPrint is installed on this machine, printer configuration is all done through iPrint because CUPs is disabled on the machine when iPrint is installed.

    In iPrint there is no configuration of the LPR queue. It is automagically configured by iPrint when the "Enable LPR/LPD Client support" box is checked in the IPrint printer configuration.

    As for dashes in the LPR queue name, that has been working since this server was installed 3 years ago. Is the non-use of dashes a recent change?

    This has been working for three years. It just stopped working a couple of weeks ago. It is used to print out faxes when they are received by Hylafax which is running on this server. I occasionally used it to print out stuff when working on the server.

    So..., I can't change the LPR queue configuration. Any other thoughts?
  • First of all, this issue is by no means related to LPR support (which doesn't harm, of course), as you've never printed to the iPrint's LPR daemon when this worked.
    As your lpstat statement shows
    device for LaserJet-4345MFP: ipp://
    you've always printed via IPP. As we now have LPR, queue names a.s.o. out of the game, there's absolutely a change in behaviour which must have been introduced somewhen in the last 10-12 weeks. I can't seem to dupe this on systems with an older codebase but can consistently dupe it on anything newer. Tracing what's going on i see apache throwing a 403 on a print attempt, in response to a request including "printers" in the URL. In fact, connecting with a browser to throws an error on the affected systems but presents the same content as on the older ones. Without too much apache knowledge i simply changed the

    <LocationMatch /(ids|ipp)>
    statement in /etc/opt/novell/httpd/conf.d/iprint_g.conf
    <LocationMatch /(ids|ipp|printers)>
    restarted apache and was able to successfully print via "lpr -P" again. You might want to check if this works for you. But even if this helps:
    - there are for sure more elegant ways to accomplish this
    - i have no clue whether this new behaviour could be desired by development
    - it's absolutely possible that this sort of handling (maybe just for localhost) is some sort of security measurement

    So even if it helps you for the moment you should still open a SR...
  • Thanks for your help. I can print now.

    I have submitted a Service Request. # 101234168231

    Like you, I don't believe that this is the root cause of this problem.
  • I'd suspect that noone ever think about a usecase for the "printers" URL. Please keep us informed.
  • Got an update today. Still waiting on Engineering.
  • Thanks for the feedback.
  • Got an email on 01/23/2020 that the defect has been patched with the following patches:

    Update 37 - OES 2015 SP1 - iPrint - Recommended (Open Enterprise Server 2015.1 (OES 2015 SP1) x86-64)

     iPrint 3.2 Patch 4 (iPrint Appliance 3.0 x86-64)

     Update 12 - OES 2018 - iPrint - Recommended (Open Enterprise Server 2018 x86-64)

    Update 4 - OES 2018 SP1 - iPrint - Recommended (Open Enterprise Server 2018.1 x86-64)

     iPrint 4.0 Patch 4 (iPrint Appliance 4.0 x86-64)

    So I removed the workaround that had been previously suggested, restarted Apache2, verified that the problem existed, installed patches, restarted Apache2, verified that problem was fixed.