Closed pgnd closed 1 year ago
just noticed that the 'endless stream' of blank pages is after a single page printed,
%!PS-Adobe-3.0
%%For: (guest)
%%Title: (Test Page)
%RBINumCopies: 1
%%Pages: (atend)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%% If you can read this, your printer is not a PostScript printer. %%%%
%%%% %%%%
%%%% Do not set it up with the PostScript Printer Application. %%%%
%%%% %%%%
%%%% If the PostScript Printer Application has set it up automatically, %%%%
%%%% this is a bug. Report it here: %%%%
%%%% https:://github.com/OpenPrinting/ps-printer-app/issues %%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The printer, an HP LJ 4050n
https://www.cnet.com/products/hp-laserjet-4050/
is a Postscript-capable printer; specificially, supporting
PCL 5, PCL 6, PostScript 2
On the printer you have probably some web admin interface, reachable by entering the printer's host name or IP in a web browser. You can perhaps configure there which print data formats/Page Description Languages (PDL) are actually accepted. Make sure that PostScript printing is enabled there.
Try to print a PostScript file directly to the printer, without any filtering or spooling:
nc -w1 IP_ADDRESS 9100 < /snap/ps-printer-app/current/usr/share/ps-printer-app/testpage.ps
Does it come out correctly?
Also sometimes turning off the printer and turning it on again helps.
In the Printer Application's web interface (http://localhost:8000/
) you probably did everything correct, selecting your printer as auto-discovered from the device list and let the "driver" (exactly the model) get auto-selected.
In CUPS (http://localhost:631/
) you will not need to do anything. CUPS creates a virtual print queue with the same name as the queue you defined in the Printer Application. It is correct that CUPS considers your printer a "driverless IPP" printer, "IPP Everywhere", or "AirPrint", as a Printer Application is nothing more than an emulation of a driverless IPP printer, to make non-driverless legacy printers work like driverless printers.
Also try to restart the Printer Application:
sudo snap stop ps-printer-app
sudo snap start ps-printer-app
and also assure that there are not several Printer Applications in your network using the same queue names.
Some print dialogs cannot cope with virtual CUPS queues as they use a too old API of CUPS. So these printers do not appear. Here cups-browsed
helps. This utility automatically converts virtual CUPS queues into permanent CUPS queues.
The URI of your printer (for example for the lpadmin
command of CUPS is:
ipp://localhost:8000/ipp/print/HPLJ_4050n_pappl
You find these URIs by running
ippfind
or
driverless --std-ipp-uris
If you run
driverless
you also get CUPS URIs, but based on the DNS-SD service names, independent on the port on which your Printer Application is operating.
You can manually create a permanent CUPS queue via
lpadmin -p QUEUE_NAME -E -v URI -m everywhere
where you can freely choose the QUEUE_NAME
and URI
is the URI as obtained with the methods above.
Note: The GTK print dialog (GEdit, evince, Thunderbird, ...) will handle virtual CUPS queues in Ubuntu 21.10, to be released mid-October.
@tillkamppeter
Thanks for the reply and the _very_helpful info!
On the printer you have probably some web admin interface, reachable by entering the printer's host name or IP in a web browser.
unfortunately, only the HP logo, and a blank page
You can perhaps configure there which print data formats/Page Description Languages (PDL) are actually accepted. Make sure that PostScript printing is enabled there.
In the printer's front-panel "Configuration Menu", I switched the 'Personality' setting from =PCL to =PS !
now, 'Printer Test Page' works as expected from pappl WebUI -- no more stream of blank pages.
Test page, "Printed with the OpenPrinting PostScript Printer Application" correctly reports:
Interpreter Information
PostScript: Level 2
Version: 2014.116 (0)
Product: HP LaserJet 4050 Series
Serial #: ...
Try to print a PostScript file directly to the printer, without any filtering or spooling:
testing with
nc -w1 172.28.8.101 9100 < /snap/ps-printer-app/current/usr/share/ps-printer-app/testpage.ps
works successfully, as well
In CUPS (http://localhost:631/) you will not need to do anything. CUPS creates a virtual print queue with the same name as the queue you defined in the Printer Application.
restart the Printer Application:
exec
whoami
myuser
sudo snap stop ps-printer-app
sudo snap start ps-printer-app
ps-printer-app printers
WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
HPLJ_4050n_pappl
checking
driverless --std-ipp-uris
ipp://localhost:8000/ipp/print/HPLJ_4050n_pappl
ipps://localhost:8000/ipp/print/HPLJ_4050n_pappl
in the CUPS:631 ui, there's NO printer listed.
should that 'virtual print queue' be seen/displayed at all in the CUPS UI?
Once I've exec'd
sudo snap start ps-printer-app
The printer queue does appear to apps -- and can be selected from print dialogs.
But, print jobs launched from THOSE print dialogs currently do nothing -- no traffic to the printer at all.
Double-checking at this point, a "Print Test Page" from the UI still works.
Not sure yet even where to look for debug info ...
Note: The GTK print dialog (GEdit, evince, Thunderbird, ...) will handle virtual CUPS queues in Ubuntu 21.10, to be released mid-October.
fwiw, I'm running snapd on Fedora 34 atm,
snap version
snap 2.51.7-1.fc34
snapd 2.51.7-1.fc34
series 16
fedora 34
kernel 5.13.13-200.fc34.x86_64
That the printer has no working web interface is strange. Perhaps one can also control it by the front panel. Seems to be a security feature to prevent people not having physical access to the printer changing its configuration.
By default, printers have automatic recognition of the input data format, so an admin can have changed it.
The web interface of CUPS does not show virtual queues, unfortunately. You could post a feature request on CUPS. This would make debugging printing problems much easier.
GTK of Ubuntu 21.10 is 3.24.29 and 4.3.1. I assume 3.24.29 is used for most apps though, especially Thunderbird where I have tested. So it depends on the GTK version used in your Fedora (I did not check, but I hope the fix is upstream and not a Debian/Ubuntu-specific patch).
That the printer has no working web interface is strange. Perhaps one can also control it by the front panel.
I'll poke around in there ....
So it depends on the GTK version used in your Fedora
here, for F34, it's
rpm -qa | grep -i ^gtk3
gtk3-3.24.30-1.fc34.x86_64
is there some trace/debug info I can grab that'd be useful in debugging why I've no output to the printer using the pappl-setup queue? still possible, of course, I've missed a step ...
That the printer has no working web interface is strange. Perhaps one can also control it by the front panel.
fwiw,
it appears that the webUI requires java!; challenging with a modern browser :-/
options are (1) front panel, and (2) there'a telnet interface that provides control for much of the printer config. but not all. notably, NOT the 'personality' switch between PCL <> PS.
To debug the virtual queue problem you could first simply try
lp -d HPLJ_4050n_pappl FILE
FILE
being PostScript, PDF, JPG, or PNG.
If this prints, you have an evidence that the virtual queue is there, even if it only accepts the job (not saying that the printer does not exist) is already an evidence that the virtual queue is there. The virtal queue stays for one minute of inactivity and will be removed then. During this time you can find the queue's auto-generated PPD file, /etc/cups/ppd/HPLJ_4050n_pappl.ppd
. Note that the file is only readable by root and that it is not HP's one for your printer, but a PPD file, auto-generated by CUPS, for the driverless IPP printer the Printer Application is emulating.
If you get the virtual CUPS queue but now printing, you need to switch CUPS into debug mode (cupsctl --debug-logging
) and look into the /var/log/cups/error_log
) file.
checking
driverless --std-ipp-uris
ipp://localhost:8000/ipp/print/HPLJ_4050n_pappl
ipps://localhost:8000/ipp/print/HPLJ_4050n_pappl
ps-printer-app printers
WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
HPLJ_4050n_pappl
enabling
cupsctl --debug-logging
grep debug /etc/cups/cupsd.conf
LogLevel debug
systemctl restart cups
ls -al /var/log/cups/*
ls: cannot access '/var/log/cups/*': No such file or directory
then exec of
lp -d HPLJ_4050n_pappl ./TEST.pdf
does NOT print, & eventually returns just
lp: The printer or class does not exist.
where, watching
journalctl -f grep -i cups
...
=====> https://pastebin.com/WrWFb7Sw
& verifying, print to NON-pappl printer/queue, i.e. my usual CUPS socket:// -> HPLJ 4050n works fine.
What is the output of
avahi-browse -r -t _ipps._tcp
and
avahi-browse -r -t _ipp._tcp
?
not installed
avahi-browse -r -t _ipps._tcp
bash: avahi-browse: command not found
avahi-browse -r -t _ipp._tcp
bash: avahi-browse: command not found
rpm -qa | grep -i avahi
avahi-libs-0.8-14.fc34.x86_64
avahi-0.8-14.fc34.x86_64
avahi-glib-0.8-14.fc34.x86_64
cnf avahi-browse
bash: avahi-browse: command not found...
Install package 'avahi-tools' to provide command 'avahi-browse'? [N/y] y
* Waiting in queue...
The following packages have to be installed:
avahi-tools-0.8-9.fc34.x86_64 Command line tools for mDNS browsing and publishing
The following packages have to be downgraded:
avahi-0.8-9.fc34.x86_64 Local network service discovery
avahi-glib-0.8-9.fc34.x86_64 Glib libraries for avahi
avahi-libs-0.8-9.fc34.x86_64 Libraries for avahi run-time use
^C
per cups docs,
https://www.cups.org/doc/network.html
mdns is an option
reading the pappl docs
"Avahi 0.8 or later (except on macOS) for mDNS/DNS-SD support"
iiuc, then, if not wanting to use mdns/bonjour, then avahi* is not a required install.
or, IS it for ps-printer-app ?
although, in any case, shouldn't any such req't be filled by the snap?
Does this mean that Fedora has discontinued/removed avahi-tools, and with it avahi-browse? How can a sys admin live without avahi-browse? Report a bug at Fedora.
Alternatively, you can try the GUI tool avahi-discover. It opens a window and shows a list of discovered devices, sorted by network interfaces, then by device types. Look under "Internet Printer" and "Secure Internet Printer".
DNS-SD/mDNS is essential for driverless printing, especially if you have driverless IPP network printers. You could get away without it if you only have Printer Applications and manually create queues pointing to the printers under the Printer Applications and using -m everywhere
.
But as you can see the Printer Application's printer URIs with the driverless
tool you have working Avahi on your system and so you have DNS-SD/mDNS.
The Printer Applications which are available in the Snap Store (created by Michael Sweet and by me, the latter under the devloper "OpenPrinting") have DNS-SD/mDNS support via Avahi built-in. If you install them on a machine which is running avahi-daemon (like yours) the printers get registered on avahi-damon and so CUPS sees them (or at least should see them). The avahi-daemon part is working for you as the driverless
utility sees your printer.
Does this mean that Fedora has discontinued/removed avahi-tools, and with it avahi-browse?
No idea what Fedora project's decided :-/
How can a sys admin live without avahi-browse?
Until starting to work with pappl, I've had no particular need for it.
you can try the GUI tool avahi-discover
no such pkg in Fedora
as you point out
The avahi-daemon part is working for you as the driverless utility sees your printer.
given
DNS-SD/mDNS is essential for driverless printing
it does seem the snap-installed app's tools/env are discovering -- both with ippfind
and driverless
just not printing.
so what's missing?
fyi,
Does this mean that Fedora has discontinued/removed avahi-tools, and with it avahi-browse? No idea what Fedora project's decided :-/
https://src.fedoraproject.org/rpms/avahi/blob/rawhide/f/avahi.spec#_656
It's 'in there' ... why it's not in the current installed packages, I need to poke around for
The problem seems to be the CUPS on your system. It is not generating virtual queues for your printer. If it tries and fails it would leave appropriate traces in error_log (error messages). If it does not try, it is mis-configured or stone-old.
You can, for the time being, manually create the CUPS queue via
lpadmin -p lj4050-pappl -E -v ipp://localhost:8000/ipp/print/HPLJ_4050n_pappl -m everywhere
With this you should be able to print. But note also that with such a manual queue set up you cannot investigate whether CUPS would create a virtual queue or not as CUPS does not create virtual queues to printers already covered. You have to remove it then (and probably also to restart CUPS).
For investigation about the non-creation of the virtual queue please attach the following files:
/etc/cups/cupsd.conf
/etc/cups/cups-files.conf
/var/log/cups/error_log
Note that you have to rename the copies of the files to have a .txt
extension to attach them here.
If you do not get a /var/log/cups/error_log
try restarting CUPS, check whether perhaps your disk is full, check also /etc/cups/cupsd.conf
and /etc/cups/cups-files.conf
for any mis-configuration.
@zdohnal, it looks like that we have a problem of CUPS in Fedora 34 not creating virtual queues for IPP printers advertising themselves via DNS-SD (driverless IPP printing, IPP Everywhere, AirPrint). Could you help here?
should be able to print after exec of
lpadmin -p lj4050-pappl -E -v ipp://localhost:8000/ipp/print/HPLJ_4050n_pappl -m everywhere systemctl restart cups
printer option " lj4050-pappl" does appear in apps' print dialog https://i.imgur.com/gr4hyzX.png
but, again, printing "to" it fails -- no contact/output to printer. printing via non-pappl queue (jetdirect socket://) works as usual.
For investigation about the non-creation of the virtual queue please attach the following files:
/etc/cups/cupsd.conf https://pastebin.com/x2k8drAY
/etc/cups/cups-files.conf https://pastebin.com/wRTg71Mw
/var/log/cups/error_log
ls -al /var/log/cups/error_log ls: cannot access '/var/log/cups/error_log': No such file or directory
check whether perhaps your disk is full
nope.
df -h | grep log
/dev/mapper/VG0-LV_VARLOG ext4 20G 643M 18G 4% /var/log
check also /etc/cups/cupsd.confand /etc/cups/cups-files.conffor any mis-configuration.
both (as included above) should be as-installed .... staring at them now :-/
fyi,
https://fedoraproject.org/wiki/How_to_debug_printing_problems#Location_of_CUPS_logging
Location of CUPS loggingCUPS logging is located in the system journal by default, but the logging into a file can be set in /etc/cups/cups-files.conf with directive 'ErrorLog'. If you want to change the default settings, then the name of the logging file is irrelevant, but it is recommended to put the file into path '/var/log/cups', otherwise SELinux will block cupsd from accessing it.
OK, then we know to where CUPS is logging. So then please either consult the log there and extract it from there to attach here, or change configuration to classic error_log.
Once you have found the easier method for you to handle the CUPS log, restart CUPS at first, then restart the Printer Application and look for what happens in the CUPS log by that. If all seams normal and CUPS discovers your printer the next step is try to print to the virtual queue and look into the log to find out why CUPS does not create a virtual queue.
That your printer does not print even with the manually created queue looks like that CUPS is not able to talk IPP to your printer at localhost:8000. This can be investigated in the CUPS log, too.
So then please either consult the log there and extract it from there to attach here
restart CUPS at first
systemctl restart cups
then restart the Printer Application and look for what happens in the CUPS log by that
sudo snap restart ps-printer-app
and there's a segfault!
Sep 03 18:56:39 test.loc kernel: ps-printer-app[39379]: segfault at 0 ip 00007fa02e682b02 sp 00007ffe5ab3b8d0 error 4 in libcups.so.2[7fa02e67e000+47000]
here,
locate libcups.so.2
/usr/lib64/libcups.so.2
/var/lib/snapd/snap/gnome-3-28-1804/145/usr/lib/x86_64-linux-gnu/libcups.so.2
/var/lib/snapd/snap/gnome-3-28-1804/161/usr/lib/x86_64-linux-gnu/libcups.so.2
/var/lib/snapd/snap/gnome-3-34-1804/66/usr/lib/x86_64-linux-gnu/libcups.so.2
/var/lib/snapd/snap/gnome-3-34-1804/72/usr/lib/x86_64-linux-gnu/libcups.so.2
/var/lib/snapd/snap/ps-printer-app/429/usr/lib/libcups.so.2
and there's a segfault!
testing, it's reproducible @ each snap restart ps-printer-app
as well as on several (similarly configured) machines
Could you do
sudo snap stop ps-printer-app
sudo snap start ps-printer-app
Are you able to get the Printer Application started again this way?
It's not that it's NOT restarting ... it is:
(1) ps ax | grep ps-printer-app
5230 ? Ssl 0:00 /snap/ps-printer-app/432/usr/bin/ps-printer-app -o log-level=debug -o log-file=/var/snap/ps-printer-app/common/ps-printer-app.log server
24984 ? Sl 0:01 /snap/ps-printer-app/429/usr/bin/ps-printer-app server -o private-server=true
sudo snap restart ps-printer-app
Restarted.
journalctl -f | egrep -i "cups|printer"
Sep 04 11:05:49 test.loc systemd[1]: Stopping Service for snap application ps-printer-app.ps-printer-app-server...
Sep 04 11:05:49 test.loc kernel: ps-printer-app[5230]: segfault at 0 ip 00007f2bc6cf3b02 sp 00007ffcff306e80 error 4 in libcups.so.2[7f2bc6cef000+47000]
Sep 04 11:05:49 test.loc kernel: CPU: 2 PID: 5230 Comm: ps-printer-app Tainted: P W OE 5.13.13-200.fc34.x86_64 #1
Sep 04 11:05:49 test.loc systemd[1]: snap.ps-printer-app.ps-printer-app-server.service: Main process exited, code=killed, status=11/SEGV
...
ps ax | grep ps-printer-app
24984 ? Sl 0:01 /snap/ps-printer-app/429/usr/bin/ps-printer-app server -o private-server=true
26195 ? Ssl 0:00 /snap/ps-printer-app/432/usr/bin/ps-printer-app -o log-level=debug -o log-file=/var/snap/ps-printer-app/common/ps-printer-app.log server
(2) ps ax | grep ps-printer-app
24984 ? Sl 0:01 /snap/ps-printer-app/429/usr/bin/ps-printer-app server -o private-server=true
26195 ? Ssl 0:00 /snap/ps-printer-app/432/usr/bin/ps-printer-app -o log-level=debug -o log-file=/var/snap/ps-printer-app/common/ps-printer-app.log server
sudo snap stop ps-printer-app
Stopped.
journalctl -f | egrep -i "cups|printer"
Sep 04 11:07:59 test.loc systemd[1]: Stopping Service for snap application ps-printer-app.ps-printer-app-server...
Sep 04 11:07:59 test.loc kernel: ps-printer-app[26195]: segfault at 0 ip 00007fd555e98b02 sp 00007ffd8a2b2250 error 4 in libcups.so.2[7fd555e94000+47000]
Sep 04 11:07:59 test.loc kernel: CPU: 9 PID: 26195 Comm: ps-printer-app Tainted: P W OE 5.13.13-200.fc34.x86_64 #1
Sep 04 11:07:59 test.loc systemd[1]: snap.ps-printer-app.ps-printer-app-server.service: Main process exited, code=killed, status=11/SEGV
...
sudo snap start ps-printer-app
Started.
journalctl -f | egrep -i "cups|printer"
... NO SEGAULT ...
ps ax | grep ps-printer-app
24984 ? Sl 0:01 /snap/ps-printer-app/429/usr/bin/ps-printer-app server -o private-server=true
26362 ? Ssl 0:00 /snap/ps-printer-app/432/usr/bin/ps-printer-app -o log-level=debug -o log-file=/var/snap/ps-printer-app/common/ps-printer-app.log server
Hi all,
@pgnd it would be great if you provided the following information:
From CUPS log (though it is a grep of journalctl on 'cups', so cups-browsed from cups-filters is there too - see the link you've already shared, you can get CUPS log by journalctl -u cups
) I see even cups-browsed isn't able to communicate with device created by ps-printer-app:
Sep 03 18:51:26 test.loc cups-browsed[52834]: Fri Sep 3 18:51:26 2021 get-printer-attributes: Cannot connect to printer with URI ipp://test.local:8000/ipp/print/HPLJ_4050n_pappl.
Sep 03 18:51:26 test.loc cups-browsed[52834]: Fri Sep 3 18:51:26 2021
Sep 03 18:51:26 test.loc cups-browsed[52834]: Fri Sep 3 18:51:26 2021 get-printer-attributes IPP call failed on printer HPLJ_4050n_pappl (ipp://HPLJ_4050n_pappl._ipp._tcp.local/).
Sep 03 18:51:26 test.loc cups-browsed[52834]: Fri Sep 3 18:51:26 2021 ERROR: Unable to create print queue, ignoring printer.
If my guess is correct, the core of the issue is you cannot resolve .local adress (which can be verified by the second point in the paragraph where I request more info). The current situation about .local address resolving in Fedora is that you can choose from two resolvers, both seem to work with Avahi:
1) nss-mdns - this package is a weak dependency of CUPS in Fedora, so you should get it automatically with CUPS unless you'd configured dnf to do not install weak deps. If you have nss-mdns installed and still cannot ping .local address, then inspect your /etc/nsswitch.conf and /etc/authselect/user-nsswitch.conf. If you want to modify those files, the way of how and what modify depends on whether /etc/nsswitch.conf is a symlink or not - if it is a symlink, modify only the files in /etc/authselect dir and then use authselect commands to update. If your /etc/nsswitch.conf is still a regular file (IIRC sometime around 2017-2018 authselect has started to take care of nsswitch.conf and turned it into symlink, but machines from before that time still has nsswitch.conf as a regular file), modify it directly.
2) systemd-resolved: since F33 resolved is running by default, but it doesn't take care of mDNS resolving unless you set it to. To enable resolving via resolved, you will need to set MulticastDNS=resolve in /etc/systemd/resolved.conf and then enable mdns and llmnr on the NM connection you are using.
@zdohnal
afer recent upgrades, up-to-date avahi-browse@avahi-tools pkg is installed,
which avahi-browse
/usr/bin/avahi-browse
rpm -q --whatprovides /usr/bin/avahi-browse
avahi-tools-0.8-14.fc34.x86_64
rpm -qa | grep avahi | sort
avahi-0.8-14.fc34.x86_64
avahi-glib-0.8-14.fc34.x86_64
avahi-libs-0.8-14.fc34.x86_64
avahi-tools-0.8-14.fc34.x86_64
returns
avahi-browse -avrt
Server version: avahi 0.8; Host name: dev.local
E Ifce Prot Name Type Domain
: Cache exhausted
: All for now
ping @.local
ping dev.local
ping: dev.local: Name or service not known
my machine is
hostname
dev.mylandomain.com
resolveable on my LAN, @ my local DNS
dig A dev.mylandomain.com
; <<>> DiG 9.16.20-RH <<>> A dev.mylandomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40321
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 58670dc726bfc8de010000006135f71eaf617e27d5aa17a2 (good)
;; QUESTION SECTION:
;dev.mylandomain.com. IN A
;; ANSWER SECTION:
dev.mylandomain.com. 5 IN A 172.28.10.7
;; Query time: 0 msec
;; SERVER: fd72:28:10::100#53(fd72:28:10::100)
;; WHEN: Mon Sep 06 07:10:13 EDT 2021
;; MSG SIZE rcvd: 101
is pingable
ping -6 dev.mylandomain.com -c 1
PING dev.mylandomain.com(dev.mylandomain.com (fd72:28:10::7)) 56 data bytes
64 bytes from dev.mylandomain.com (fd72:28:10::7): icmp_seq=1 ttl=64 time=0.031 ms
--- dev.mylandomain.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.031/0.031/0.031/0.000 ms
ping -4 dev.mylandomain.com -c 1
PING (172.28.10.7) 56(84) bytes of data.
64 bytes from dev.mylandomain.com (172.28.10.7): icmp_seq=1 ttl=64 time=0.023 ms
--- ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.023/0.023/0.023/0.000 ms
as is my printer
host 172.28.10.10
10.11.30.172.in-addr.arpa domain name pointer printer.mylandomain.com.
ping -4 172.28.10.10 -c1
PING 172.28.10.10 (172.28.10.10) 56(84) bytes of data.
64 bytes from 172.28.10.10: icmp_seq=1 ttl=60 time=1.37 ms
--- 172.28.10.10 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.368/1.368/1.368/0.000 ms
The current situation about .local address resolving in Fedora is that you can choose from two resolvers, both seem to work with Avahi:
systemd-resolved
not in use here,
systemctl status systemd-resolved
○ systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: disabled)
Active: inactive (dead)
Docs: man:systemd-resolved.service(8)
man:org.freedesktop.resolve1(5)
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
nss-mdns
installed
rpm -qa nss-mdns
nss-mdns-0.14.1-11.fc34.x86_64
If you have nss-mdns installed and still cannot ping .local address, then inspect your /etc/nsswitch.conf and /etc/authselect/user-nsswitch.conf.
i do not setup/use mdns/bonjour/avahi on my LAN
resolution on my LAN is, as above, restricted to use at my local nameserver
named -v
BIND 9.16.20-RH (Extended Support Version) <id:26db37f>
ls -al /etc/resolv.conf
-rw-r--r-- 1 root root 125 Aug 14 07:36 /etc/resolv.conf
cat /etc/resolv.conf
nameserver fd72:28:10::100
nameserver 172.28.10.100
search mylandomain.com
ls -al /etc/nsswitch.conf /etc/authselect/user-nsswitch.conf
-rw-r--r-- 1 root root 1.7K Aug 8 07:01 /etc/nsswitch.conf
-rw-r--r-- 1 root root 2.3K Aug 8 07:01 /etc/authselect/user-nsswitch.conf
grep ^hosts /etc/nsswitch.conf /etc/authselect/user-nsswitch.conf
/etc/nsswitch.conf:hosts: dns files [NOTFOUND=return] myhostname
/etc/authselect/user-nsswitch.conf:hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns
authselect list
- minimal Local users only for minimal installations
- nis Enable NIS for system authentication
- sssd Enable SSSD for system authentication (also for local users only)
- winbind Enable winbind for system authentication
authselect current
No existing configuration detected.
modify it directly.
to what, & where?
sounds like pappl/ps-printer-app requires mdns .local resolution, unlike CUPS itself ?
instead of changing my LAN's existing, fuinctional resolution policy/function, can pappl etc config be appropriately spec'd/changed to explicit use hostname resolution as it exists on my lan?
@pgnd I have fixed the segfault you are observing with the Printer Application Snaps in all of them. So please make sure you have the current versions. The Snap Store has already built all the three for the amd64 architecture and should do the updates on your system automatically. The "Rev" in snap list
must be 441 for ps-printer-app, 13 for hplip-printer-app, and 31 for ghostscript-printer-app.
For your printer either ps-printer-app or hplip-printer-app should provide the support.
I have fixed the segfault you are observing with the Printer Application Snaps in all of them
@tillkamppeter
Thx, will update & test in a bit ...
In general, I'm finding that the variety of older HP workhorse printers here -- PS v2 capable -- CUPS printing functions well with either PS or PCL pdl. But with PS, after send to the printer's RAM, there's a significnat processing delay -- at the printer. I'm assuming (still poking around) it's due to some combination of decompression, PS drivers lacking access to full RAM, etc. OTOH, Ghostscript PCL6 drivers seem to working really well, where, IIUC, the rasterization occurs (?) locally, before send to the printer. Seems to be handling single & multiple jobs with much less trouble.
So, atm, GS/PCL is preferable, when the choice is available.
Not yet sure what options for pappl for GS/PCL support exist; reading @ OpenPrinting now ...
EDIT: looks like this, https://github.com/OpenPrinting/ghostscript-printer-app
To get PCL drivers (PCL 6/XL, 5c/e) use the Ghostscript Printer Application instead of the PostScript Printer Application. There are generic entries if your printer is not explicitly listed. If you printer is HP, use the HPLIP Printer Application for non-PostScript printing.
If you printer is HP, use the HPLIP Printer Application for non-PostScript printing.
thought the pappl "hp-printer-app" was just a demo app -- didn't realize it was functional. the standard HPLIP pkgs, at least those for my F34 installs, provide only a pcl3 implementation. The test printer I'm working on atm, an HP LJ 4050, supports PS, PCL5 & PCL6 pdls.
I leaned to the GS drivers for the PCL6 vs PCL3 support, (ref: https://developers.hp.com/hp-printer-command-languages-pcl, https://developers.hp.com/hp-pcl-specifications/doc/differences-between-pcl56-and-pcl3), and to be (more) free of proprietary HP drivers. And yes, both are not yet quite well informed choices ...
aha,
hp-printer-app != hplip-printer app ...
The PCL printer support in HPLIP is not proprietary, only a few non-PCL-non-PS laser printers use HP's proprietary plugin (which is not yet supported in the HPLIP Printer Application).
installed the app, and created a pappl printer
snap list | grep printer-app
hplip-printer-app 1.0 13 latest/edge openprinting* -
hplip-printer-app printers
WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
HPLJ_4050n_pappl
hplip-printer-app status
WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
Running, idle since Mon, 06 Sep 2021 21:37:13 GMT
created a cups printer connected to the pappl printer instance,
Queue Name Description Location Make and Model Status
HPLJ_4050n_ipp HPLJ_4050n_ipp HPLJ_4050n_ipp LaserJet 4050 Series pcl3, hpcups 3.21.8 - IPP Everywhere
grep -i ipp /etc/cups/ppd/HPLJ_4050n_ipp.ppd
*PCFileName: "ippeve.ppd"
*NickName: "LaserJet 4050 Series pcl3, hpcups 3.21.8 - IPP Everywhere"
*ShortNickName: "LaserJet 4050 Series pcl3, hpcups 3.21.8 - IPP Everywhere"
ls -al /etc/cups/ppd/*ipp*
-rw-r----- 1 root lp 11K Sep 6 12:36 /etc/cups/ppd/HPLJ_4050n_ipp.ppd
-rw-r----- 1 root lp 11K Sep 6 12:36 /etc/cups/ppd/HPLJ_4050n_ipp.ppd.O
in any give app's Print dialog, I see & can select
HPLJ_4050n_ipp
when I Print to it, however, again, no printout/activity at the printer
for that, log shows
--> https://pastebin.com/wdb55Pyg
no more segfault afaict
Unfortunately, your error_log does not help much.
Please print a job and provide the error_log
beginning from the first occurrence of [Job XXX]
entries. XXX
is the job number which you get as naswer to the lp
command when printing from the command line or in the job list of lpstat -o
. The beginning of the job logging is important, not the infinite loop which starts with any communication failure.
Also do not provide your file via commercial third-party services like Pastebin, as they are full of ads and the files will also expire after a certain time and so this bug report gets unusable for later reference.
Instead, copy your error_log into a file in your home directory, rename it to have a .txt
file name extension (like error_log.txt
) and then attach it to this bug report (to the comment with which you answer).
for this setup,
where,
HPLJ_4050n_ipp
HPLJ_4050n_ipp (Processing, Accepting Jobs, Not Shared)
Description: HPLJ_4050n_ipp
Location: HPLJ_4050n_ipp
Driver: LaserJet 4050 Series pcl3, hpcups 3.21.8 - IPP Everywhere (grayscale, 2-sided printing)
----> Connection: ipp://localhost:8000/ipp/print/HPLJ_4050n_pappl
Defaults: job-sheets=none, none media=na_letter_8.5x11in sides=one-sided
on failed, no-output, print to ipp-everywhere instance,
lp dummy.pdf -d HPLJ_4050n_ipp
error_log
avahi-browse -avrt Server version: avahi 0.8; Host name: dev.local E Ifce Prot Name Type Domain : Cache exhausted : All for now ping dev.local ping: dev.local: Name or service not known
Ok, that explains a lot :) .
resolution on my LAN is, as above, restricted to use at my local nameserver
ls -al /etc/nsswitch.conf /etc/authselect/user-nsswitch.conf -rw-r--r-- 1 root root 1.7K Aug 8 07:01 /etc/nsswitch.conf -rw-r--r-- 1 root root 2.3K Aug 8 07:01 /etc/authselect/user-nsswitch.conf grep ^hosts /etc/nsswitch.conf /etc/authselect/user-nsswitch.conf /etc/nsswitch.conf:hosts: dns files [NOTFOUND=return] myhostname /etc/authselect/user-nsswitch.conf:hosts: files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns
modify it directly.
to what, & where?
Ok, then you have nsswitch.conf as a regular file, so any changes you make should go directly to it - the relevant directive is 'hosts:' which you found out it differs in /etc/nsswitch.conf and /etc/authselect/user-nsswitch.conf.
First, I would try changing 'hosts:' line in /etc/nsswitch.conf to look the same as 'hosts:' line in /etc/authselect/user-nsswitch.conf, (here maybe restart can be needed, I'm not sure whether services pick up nsswitch.conf changes without some 'restart') and try pinging a .local address. If the previous didn't help, you can try 'hosts:' line sequence from here - it worked for the user and I have the same configuration, which works for me.
sounds like pappl/ps-printer-app requires mdns .local resolution, unlike CUPS itself ?
No, actually CUPS uses the same .local resolution as printer applications - CUPS uses it during automatic creation of 'virtual' queues (the exact term is CUPS temporary queue) when you are about to print. The tech saves an user's work on installing printer and memory on his machine, because the queue is removed after successful printing. You can overcome mdns resolution requirement by installing the print queue manually, using non-.local hostname and 'everywhere' model, but this requires your input ( so no zero configuration anymore :) ) and makes the queue permanent, so permanently reserving some of your resources. I'm glad the queues shared from printer apps can be installed the same way - it is a relief for users which don't trust their LANs...
instead of changing my LAN's existing, fuinctional resolution policy/function, can pappl etc config be appropriately spec'd/changed to explicit use hostname resolution as it exists on my lan?
IIUC the problem with using classic hostname is that it is not shared in mDNS messages, so applications aren't able to find the info about it. Probably they could do some reverse DNS lookups to find it out from IP, which is in the message, but it is quite an overhead when .local resolving should work out of the box.
The problem here is the nss-mdns maintainer in Fedora either no longer thinks there are people with /etc/nsswitch.conf as a regular file (authselect celebrated 4 years in Fedora this August, and that's when /etc/nsswitch.conf turned into symlink on new machines - 4 years ago), so he doesn't take care of them in spec file (nss-mdns needs to update 'some' - /etc/nsswitch.conf or /etc/authselect/user-nsswitch.conf - nsswitch.conf's hosts: line to make it work) or update RPM scriptlet failed for your configuration. Either way it would be great if you reported your issue in bugzilla for Fedora.
What I would recommend is to migrate your nsswitch.conf to authselect completely - you will get automatically changes from the system and you will prevent errors about someone forgets that nsswitch.conf can be a regular file. But as I'm not authselect maintainer, I don't know about any migration guide :( - if I were you, I would file a bug in bugzilla or asked on Fedora devel list.
As I wrote above, I'm not authselect maintainer, so those pieces of advice about nsswitch.conf changes and intentions can be inaccurate, but I told you what I found out during debugging similar issues.
@zdohnal
First, I would try changing 'hosts:' line in /etc/nsswitch.conf to look the same as 'hosts:' line in /etc/authselect/user-nsswitch.conf
I'm inclined to keep my non-symlnk'd setup; need to consider it a bit more.
to be clear, then, pappl's depending on /etc/nssswitch.conf -- through services -- not explcitly on /etc/authselect/user-nsswitch.conf, correct?
You can overcome mdns resolution requirement by installing the print queue manually, using non-.local hostname and 'everywhere' model, but this requires your input ( so no zero configuration anymore :) ) and makes the queue permanent, so permanently reserving some of your resources.
This is the approach I'd prefer to take ... now to figure out the pieces to see if I can get it to work.
No, actually CUPS uses the same .local resolution as printer applications
I'm misunderstanding something on this.
Apparently, due to my current nssswitch config, '.local' resolution hasn't been allowing pappl+printer-app to function correctly
If 'CUPS uses the same .local resolution', how/why is CUPS printing here functional? Clearly something is sufficient here ... just want to get a handle on the specific difference(s).
The problem here is ... ... it would be great if you reported your issue in bugzilla for Fedora.
The assumption that mdns is/will not disabled sounds like it's the fundamental issue here.
Particularly for Zero-Trust policy, but in general as well, it's a bad assumption -- neither mandated nor recommended. Simply available as an option. Personally, I'd question that it should be a default ... but that's a different discussion.
Both CUPS and (PAPPL-based) Printer Applications are emulators of (driverless) IPP network printers. As they both orginate from the creator of all these standards, Michael Sweet, they probably even better fulfill the standards than most physical network printers.
One part of the standards is that a driverless IPP printer advertises itself via DNS-SD and provides a hostname by itself, using ZeroConf. On operating systems in their standard configuration (supporting DNS-SD and ZeroConf) they are supposed to get easily discovered, automatically set up and "just work".
But this also means that if your system does not support things like DNS-SD and/or ZeroConf, that the automatic setup will not necessarily work and you need to do manual steps.
First, the ZeroConf/DNS-SD support of CUPS is not needed if you only want to print locally with your CUPS queues, it is only needed that your CUPS queues get auto-discovered by remote clients if you share them.
The safest way to print with CUPS to the Printer Application should be to manually create the queue, if CUPS and the Printer Application are on the same machine, with "localhost" as host name and the port (usually 8000) of the Printer Application, like:
lpadmin -p lj4050-pappl -E -v ipp://localhost:8000/ipp/print/HPLJ_4050n_pappl -m everywhere
If the Printer Application is running on another machine, you need to use that machines IP (or the name assigned in your DNS) instead of "localhost".
With this, CUPS should not need any DNS-SD/Avah/Zeroconf, as it has an exact address to access the Printer Application. If this dooes not work, it seems to be some problem with your specific network configurartion or with Fedora, where probably @zdohnal is of more help than me.
Make also sure that there is no system-internal firewall or similar which blocks communication via port 8000.
you need to do manual steps. ... The safest way to print with CUPS to the Printer Application should be to manually create the queue, if CUPS and the Printer Application are on the same machine
here, atm, they are
with "localhost" as host name and the port (usually 8000) of the Printer Application, like: lpadmin -p lj4050-pappl -E -v ipp://localhost:8000/ipp/print/HPLJ_4050n_pappl -m everywhere
Make also sure that there is no system-internal firewall or similar which blocks communication via port 8000.
there isn't
telnet localhost 8000
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
with no mdns specified to be used,
grep ^hosts /etc/nsswitch.conf
hosts: dns files [NOTFOUND=return] myhostname
and services disabled, as usual here,
systemctl status -ln0 avahi-daemon cups-browsed
○ avahi-daemon.service - Avahi mDNS/DNS-SD Stack
Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; disabled; vendor preset: enabled)
Active: inactive (dead)
TriggeredBy: ○ avahi-daemon.socket
○ cups-browsed.service - Make remote CUPS printers available locally
Loaded: loaded (/usr/lib/systemd/system/cups-browsed.service; disabled; vendor preset: disabled)
Active: inactive (dead)
'plain' CUPS printing to a local CUPS queue
@ http://localhost:631/printers/HPLJ_4050n_pcl6_hp_gutenprint
HPLJ_4050n_pcl6_hp_gutenprint
HPLJ_4050n_pcl6_hp_gutenprint (Idle, Accepting Jobs, Not Shared, Server Default)
Description: HPLJ_4050n_pcl6_hp_gutenprint
Location: HPLJ_4050n_pcl6_hp_gutenprint
Driver: HP LaserJet 4050 - CUPS+Gutenprint v5.3.4 (grayscale, 2-sided printing)
Connection: socket://172.28.10.10:9100
Defaults: job-sheets=none, none media=na_letter_8.5x11in sides=one-sided
works as expected
setup & create pappl instance
@ http://localhost:8000/HPLJ_4050n_pappl
Status
HP LaserJet 4050 Series pcl3, hpcups 3.21.8
hplip-printer-app printers
WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
HPLJ_4050n_pappl
manually create permanent queue,
lpadmin -p lj4050-pappl -E -v ipp://localhost:8000/ipp/print/HPLJ_4050n_pappl -m everywhere
ls -al /etc/cups/ppd/lj4050-pappl.ppd
-rw-r----- 1 root lp 11K Sep 7 08:02 /etc/cups/ppd/lj4050-pappl.ppd
grep HPLJ_4050n_pappl /etc/cups/ppd/lj4050-pappl.ppd
*APSupplies: "http://localhost:8000/HPLJ_4050n_pappl/"
print dialog in any app does display 'lj4050-pappl'
print "to" 'lj4050-pappl' fails as before -- no output, no connection
If this dooes not work, it seems to be some problem with your specific network configurartion or with Fedora, where probably @zdohnal is of more help than me.
ping @zdohnal
@pgnd If the situation is the same as presented in the log from https://github.com/OpenPrinting/ps-printer-app/issues/9#issuecomment-913806631 , then I beg to differ that there is no connection - CUPS connected to the virtual printer advertised by hplip-printer-app on localhost:8000, got its attributes, validated the job, created job and send the document to it. In the end it asks for printer and job attributes which show the virtual printer is stopped - imho it doesn't look like a connection issue, but rather some error happened in hplip-printer-app.
@tillkamppeter is there a way how to get debug logs from hplip-printer-app?
Edit: Ok, I see the log has log from pappl too, but I'm not sure how @pgnd got it... I see from the log:
E [2021-09-06T18:25:45.185Z] [Device] Unsupported device URI scheme \'socket\'. E [2021-09-06T18:25:45.185Z] [Printer HPLJ_4050n_pappl] Unable to open device 'socket://172.28.10.10/', pausing queue until printer becomes available.
So pappl doesn't support socket
scheme here - do snaps carry their own pappl or classic installed package is used when hplip-printer-app is in the game?
I beg to differ that there is no connection
My point is simply that there is no actual ouptut to the HP printer itself. And that there's no indication of any connection or traffic at the printer's control/status panel.
As you point out, there is some connection attempt to the app
I see the log has log from pappl too, but I'm not sure how @pgnd got it
DL'd from the pappl UI's 'logs' page, @
I assume that you are using Printer Applications installed as a Snap from the Snap Store. In this case they should not log to syslog but have their own log file:
/var/snap/ps-printer-app/common/ps-printer-app.log
/var/snap/hplip-printer-app/common/hplip-printer-app.log
Printer Applications save their setup in the same directories, their state files:
/var/snap/ps-printer-app/common/ps-printer-app.state
/var/snap/hplip-printer-app/common/hplip-printer-app.state
There you can see, which URI, which device ID, option defaults, ... got saved for the print queue inside the Printer Application.
If you run Printer Applications without using a Snap, like compiling right out of the source code with a simple make; sudo make install
, the state file goes to /var/lib/ps-printer-app
(for PostScript Printer Application, otherwise with appropriate name of your Printer Application). I am not sure how PAPPL is exactly coded but possible that logging goes to syslog if not specifying a log file.
Also if you run Printer Applications without them being in a Snap, they possibly see all the PPDs, CUPS filters, and CUPS backends installed on your system and possibly therefore show you options under "Add Printer" (devices or drivers/models) which actually do not work with this Printer Application.
As you see PAPPL logging in your syslog I suspect that you are running Printer Applications without using their Snap incarnation.
URI schemes do not only exist in CUPS but also in Printer Applications. PAPPL has some internal backends, for USB, for network with DNS-SD discovery and for network with SNMP discovery. Depending on how you connect your printer, you can see it up to three times under the "Devices" ("Add Printer" web interface page) of most Printer Applications (the ones actually using PAPPL's backends, like the PostScript Printer Application or the Ghostscript Printer Application).
Each backend in PAPPL has a scheme, socket
is for SNMP-discovered network printers.
What can have happened is that you started with the PostScript Printer Application, set up your printer and later you started the HPLIP Printer Application and it somehow grabbed the state file of the PostScript Printer Application (I did not know that this can happen). The HPLIP Printer Application does not use PAPPL's built-in backends, but the CUPS backend of HPLIP instead, and therefore it does not support the socket
scheme.
If you use a Printer Application, make sure you cxreate your print queue in that Printer Application, not in another one.
One other thing: I remembered now that under the "Devices" on the "Add Printer" page there are not only the results of the auto-discovery but there is always the last item being "Network Printer". Selecting this ungrays "Hostname/IP address". If you continue then entering a host name or IP address and the completing the form, it seems that a queue with socket
scheme is created, regardless whether PAPPL's socket backend is perhaps disabled in a certain Printer Application. This is a bug in PAPPL.
I did not find a solution yet to suppress this item in the web interface. So please only use the auto-discovery results in the HPLIP Printer Application. AFAIR HPLIP uses SNMP or SLC to discover network printers by default, so your printer should appear even without running Avahi daemon.
I assume that you are using Printer Applications installed as a Snap from the Snap Store
yes
snap install hplip-printer-app --edge
snap list hplip-printer-app
Name Version Rev Tracking Publisher Notes
hplip-printer-app 1.0 16 latest/edge openprinting✓ -
In this case they should not log to syslog but have their own log file: ... Printer Applications save their setup in the same directories, their state files:
here,
ls -al \
/var/snap/hplip-printer-app/common/hplip-printer-app.state \
/var/snap/ps-printer-app/common/ps-printer-app.log \
/var/snap/hplip-printer-app/common/hplip-printer-app.log \
/var/snap/ps-printer-app/common/ps-printer-app.state
ls: cannot access '/var/snap/ps-printer-app/common/ps-printer-app.log': No such file or directory
ls: cannot access '/var/snap/ps-printer-app/common/ps-printer-app.state': No such file or directory
-rw------- 1 root root 508K Sep 8 04:41 /var/snap/hplip-printer-app/common/hplip-printer-app.log
-rw-r--r-- 1 root root 5.1K Sep 7 12:20 /var/snap/hplip-printer-app/common/hplip-printer-app.state
As you see PAPPL logging in your syslog I suspect that you are running Printer Applications without using their Snap incarnation.
I'm not sure what that means :-/
I've only installed the Printer App via snap.
What can have happened is that you started with the PostScript Printer Application, set up your printer and later you started the HPLIP Printer Application and it somehow grabbed the state file of the PostScript Printer Application (I did not know that this can happen).
there's only one instance here
find /var/snap -type d -name '*printer*'
/var/snap/hplip-printer-app
find /var/snap -type f -name '*state'
/var/snap/hplip-printer-app/common/hplip-printer-app.state
The HPLIP Printer Application does not use PAPPL's built-in backends, but the CUPS backend of HPLIP instead, and therefore it does not support the socket scheme.
I'm not sure what to do with that.
CUPS itself certainly supports the socket:// scheme.
The HP printer's got a JetDirect network card, directly accessible via socet:// -- that's how I've always connected. CUPS printing via socket:// is fine.
See my last comment. Probably you used this option to manually enter the IP which does not work in the HPLIP Printer Application.
I remembered now that under the "Devices" on the "Add Printer" page there are not only the results of the auto-discovery but there is always the last item being "Network Printer".
on the hplip-printer-app's "Add Printer" web page, there's no list of Auto-Discovered options:
on
with
i've installed the snap
the app's running
driver's availble for my printer (HPLJ 4050n),
in WebUI @
I've added the printer,
(1) In WebUI, click to send "Test Page" does connect to the printer, but triggers an endless stream of blank pages. "Cancel Job" is required to stop.
(2) I'm trying to get any app -- e.g. Firefox, Brave, Okular -- to recognize the pappl-setup printer.
IIUC (?), need to 'tell' CUPS about it: "print with CUPS, CUPS (and also cups-browsed) discover and treat the printers set up with this Printer Application as driverless IPP printers (IPP Everywhere and AirPrint)."
In CUPS webui @
I assume (?) I need to enter an "ipp://" URI. What form must that take? To date, under "just CUPS", I've always/only used "socket://I.P.addr.ess".