Headless CUPS configuration

395 views
Skip to first unread message

Timothy Rice

unread,
Oct 20, 2019, 6:51:50 PM10/20/19
to MLUG
Hey all,

I recently picked up a HP Envy 7640 for my soho. I can configure it from my graphical workstation okay in the usual way: fire up a browser and navigate to localhost:631 and work through the Add Printer dialog.

The working configuration looks like so:

$ lpoptions -d hp_envy_7640 | xargs -n1
copies=1
device-uri=ipp://printer:631
finishings=3
job-cancel-after=10800
job-hold-until=no-hold
job-priority=50
job-sheets=none,none
marker-change-time=1571608266
marker-colors=#00FFFF#FF00FF#FFFF00,#000000
marker-high-levels=100,100
marker-levels=-1,-1
marker-low-levels=1,1
marker-names=tri-color\ ink,black\ ink
marker-types=ink-cartridge,ink-cartridge
number-up=1
printer-commands=AutoConfigure,Clean,PrintSelfTestPage
printer-info=HP Envy 7640
printer-is-accepting-jobs=true
printer-is-shared=false
printer-is-temporary=false
printer-location=Right behind you
printer-make-and-model=HP Envy 7640 Series hpijs, 3.19.8
printer-state=3
printer-state-change-time=1571608266
printer-state-reasons=wifi-not-configured-report,media-empty-report
printer-type=10522652
printer-uri-supported=ipp://localhost/printers/hp_envy_7640

However, I have a headless box which I would also like to be able to print from. It is being a bit difficult.

First, I tried following instructions to run lpadmin like so:

lpadmin -p hp_envy_7640 -E -v ipp://printer:631 -m "drv:///hp/hpijs.drv/hp-envy_7640_series-hpijs.ppd"

(I have /etc/hosts and dnsmasq configured to find the printer by name.)

After I set up the printer with that lpadmin command, then set it to be the default printer with `lpoptions -d hp_envy_7640`, a test print job goes into the queue but never actually prints.

I also tried manually copying settings from /etc/cups/printer.conf on the working machine to the headless box, and restarted cupsd. I checked with lpoptions and as far as could tell, the configuration was identical on both machines after I manually edited the printer.conf. This did not solve the problem.

Now I wondered if it might be possible to serve the cups page from the headless machine over the network, and use a browser on the graphical workstation to do the config. So, I tried changing Listen setting in /etc/cups/cupsd.conf to *:631 and opened port 631 in iptables to the LAN.

When navigating to http://headless:631 this just gives errors like "forbidden" and "bad gateway" (or something like that -- I'm not at home at the second to copy-paste the exact error).

I tried tcpdumping traffic to and from the printer on each box. As expected, the working machine generated a lot of noise when successfully running a print job. The headless box printed out a few lines like so and then nothing:

09:15:48.129808 IP 192.168.0.1.36624 > printer.acausal.realm.snmp: GetRequest(29) 43.10.2.1.4.1.1
09:15:48.226355 IP printer.acausal.realm.snmp > 192.168.0.1.36624: GetResponse(30)
43.10.2.1.4.1.1=10
09:15:52.968448 ARP, Request who-has printer.acausal.realm tell 192.168.0.1, length 28
09:15:52.968606 ARP, Reply printer.acausal.realm is-at 98:e7:f4:aa:5f:c9 (oui Unknown), length 46

Does anyone have enough experience with network printers or cups to give me ideas on what else to try? Is it really impossible to access the cups configuration page over the network? Anything I might have overlooked when running lpadmin/lpoptions?

~ Tim

Malcolm Herbert

unread,
Oct 20, 2019, 7:37:10 PM10/20/19
to mlu...@googlegroups.com
On Sun, Oct 20, 2019 at 10:51:39PM +0000, Timothy Rice wrote:
|Does anyone have enough experience with network printers or cups to
|give me ideas on what else to try? Is it really impossible to access
|the cups configuration page over the network? Anything I might have
|overlooked when running lpadmin/lpoptions?

Yes, as far as I understand it, CUPS binds to localhost only to minimise
security issues - there are things that CUPS does in the background
which print systems typically do as root and unless absolutely required,
it's not a good idea to put services onto the external network
interfaces unless you really really need to.

In this case you might be able to get away with using SSH port
forwarding to get to the headless host and be able to get at
localhost:631 on the remote host from your local workstation.

IF the CUPS web UI is coded properly, it shouldn't matter whether you
talk at it via localhost:631 or some other port, so the following should
work:

ssh -L localhost:10631:localhost:631 remotehost

once you've connected, your browser should be able to talk to
http://localhost:10631 and be routed via the SSH tunnel to the CUPS
admin interface on the remote host

https://help.ubuntu.com/community/SSH/OpenSSH/PortForwarding has a
better description, but for now, here's a summary:

ssh -L nearhost:nearport:farhost:farport sshhost

-L sets up an SSH port-forwarding tunnel - you will need
AllowTcpForwarding set to true in /etc/ssh/sshd_cofnig on sshhost for
this to work

nearhost:nearport is the local end of the SSH tunnel, 127.0.0.1:10631

farhost:farport is the remote end of the SSH tunnel[1], which we are
pointing at sshhosts' 127.0.0.1:631 which is your CUPS web UI

sshhost is the host to which you're logging in - this case your CUPS
host

Hope that helps,
Malcolm

[1] in general, this doesn't necessarily have to be localhost - it could
be any host/IP available to sshhost

--
Malcolm Herbert
mj...@mjch.net

Timothy Rice

unread,
Oct 20, 2019, 8:31:21 PM10/20/19
to mlu...@googlegroups.com
> IF the CUPS web UI is coded properly, it shouldn't matter whether you
> talk at it via localhost:631 or some other port, so the following should
> work:
>
> ssh -L localhost:10631:localhost:631 remotehost
>
> once you've connected, your browser should be able to talk to
> http://localhost:10631 and be routed via the SSH tunnel to the CUPS
> admin interface on the remote host

Hi Malcolm,

Thanks, that's a good idea. I'll try it out when I get home later.

~ Tim

zak martell

unread,
Oct 20, 2019, 8:54:55 PM10/20/19
to mlu...@googlegroups.com
Ssh tunnel is most secure of course but otherwise, you missed Apache config. I have headless pi as print server 


--
You received this message because you are subscribed to the Google Groups "mlug-au" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mlug-au+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mlug-au/20191021003109.GB16698%40thelema.

Timothy Rice

unread,
Oct 20, 2019, 9:21:44 PM10/20/19
to mlu...@googlegroups.com
On Mon, Oct 21, 2019 at 11:54:42AM +1100, zak martell wrote:
> Ssh tunnel is most secure of course but otherwise, you missed Apache
> config. I have headless pi as print server
>
> http://thismightbehelpful.blogspot.com/2008/09/remote-access-to-cups-web-interface.html?m=1

Awesome. By the looks of that, maybe all I was missing was the `Port 631` and `Allow all` settings. Something else to check out this afternoon.

(Earlier Malcolm mentioned security concerns. This is on an ethernet-only LAN where I'm the only user, so I think it should be safe enough to expose the configuration for ten minutes and then lock it up again afterwards.)

~ Tim

Timothy Rice

unread,
Oct 22, 2019, 3:40:00 PM10/22/19
to mlu...@googlegroups.com
Hi all,

Thanks for the help. I can print from the headless box now.

At first I tried changing the cups config with the `Port 631` and `Allow
all` settings, assuming this would be easiest. However, when I went to add
a printer, the cups configuration page tried switching to https, and would
not proceed.

Presumably, there is some way to make cups work nicely in this situation,
but I decided to try Malcolm's ssh tunnel suggestion instead. This did the
trick.

Set up the tunnel like so:

ssh -L 1234:<headless-box>:631 <headless-box>

Then point a browser to localhost:1234.

There was an unexpected catch, easily resolved: since it is a headless box,
I had never bothered to install any fonts. So, when I tested printing some
plain text, I got the error: `No usable fonts available'.

This is covered at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516335. Installing the freefont package fixed it.

~ Tim

Reply all
Reply to author
Forward
0 new messages