From 65b81b4a41cd5dbfedb1dd5e846dfcdc6c03c084 Mon Sep 17 00:00:00 2001 From: Peter Boy Date: Aug 24 2023 14:09:15 +0000 Subject: Added metadata, moved partials into main text body. --- diff --git a/modules/ROOT/pages/_partials/2delete-con_cups-known-issues.adoc b/modules/ROOT/pages/_partials/2delete-con_cups-known-issues.adoc new file mode 100644 index 0000000..9cbbfa5 --- /dev/null +++ b/modules/ROOT/pages/_partials/2delete-con_cups-known-issues.adoc @@ -0,0 +1,231 @@ +[id='con_cups-known-issues'] += Known issues + +Here are several known issues, which arise with certain circumstances, and there isn't general solution or upstream didn't want to add the solution to its project: + +== cups-browsed + +=== Cannot print due 'No destination hostname provided by cups-browsed, is it running?' + + +cups-browsed sometimes loses connection to print server (usually with old ones, like cups-1.4.2) when laptop changes network connection (change of WiFi network or after hibernate/suspend). You can make printing working again with cancelling your jobs and restarting cups-browsed by + +---- +$ cancel -a +$ sudo systemctl restart cups-browsed +---- + +=== cups-browsed consumes large amount of CPU + +Creating local printer queues takes long time for some printers with larger PPD file, so timeout of http connection will time out and it creates infinite loop of creating local printer queues. To solve this issue, please add + +---- +HttpLocalTimeout N +HttpRemoteTimeout N +---- + +into [filename]`/etc/cups/cups-browsed.conf`, where `N` is number of seconds after which connection is timed out. Then restart cups-browsed service. This option is currently in Fedora 27 and above. + +=== [SINCE FEDORA 27] cups-browsed creates different printer queue names than before + +This issue is connected to remote cups queues, which are advertised by older CUPS version (usually below cups-1.5, e.g. RHEL 6). Cups-browsed creates local print queues named by printer's DNS-SD ID by default and naming by remote cups queue is enabled again by adding: + +---- +LocalQueueNamingRemoteCUPS RemoteName +---- + +into [filename]`/etc/cups/cups-browsed.conf` and restart cups-browsed service. + +== cups-filters + +=== Printing takes a long time or doesn't print at all + +When your printer needs a lot of time to do printing (from your POV) or doesn't print at all (some Xerox printers have such problems with gs renderer, so they are working again only with pdftops renderer), you can try to change the default postscript renderer. The default renderer in Fedora for most printers is gs filter from Ghostscript, but we have pdftops filter from Poppler for Brother, Minolta and Konica Minolta printers - this setup is called hybrid. + +Other available renderer setups are gs (from Ghostscript), pdftops and pdftocairo (from Poppler), mupdf (from mupdf) and acroread (from adobe reader, not in Fedora official repositories), then you can set different default renderer for your print queue like this: + +---- +# lpadmin -p -o pdftops-renderer-default=gs/pdftops/pdftocairo/mudpf/acroread/hybrid +---- + +*BEWARE:* Most 'slow' printing issues are caused by PDF creating applications, which generates bad PDF file - and that bad generated PDF file is mostly the core of problem. To sum it up, slow printing issue can rise again with different PDF file, then it is on user's decision: if he wants to print fast and probably sometimes change the default renderer, or slow printing is not such critical issue. + +== CUPS + +=== [Fixed in F33 and later] Firefox, Evince (PDF viewer), GVim, Gedit, Gnome Control Center show a 'dummy'/duplicate print queue, which doesn't work + +This bug is connected to every application which uses GTK print dialog. GTK dialog decided to take information about available from two sources - mDNS messages from Avahi and CUPS - this dummy/duplicate print queue is a print queue GTK created in its dialog based on Avahi messages, but it doesn't exist in CUPS, because no one created it, and later GTK behaves like it exists in CUPS. So every time an user wants to print, GTK sends a request to CUPS for this queue, but it gets dropped by CUPS because the queue doesn't exist. + +The feature which GTK is trying to do here is called CUPS temporary queues - GTK developers is currently working on a immediate fix in this https://bugzilla.redhat.com/show_bug.cgi?id=1784449[bugzilla]. The future plan is to use https://github.com/OpenPrinting/cpdb-backend-cups[cpdb-backend-cups] backend in GTK, but right now we are focusing on the intermediate fix. + +=== CUPS doesn't take nicely some kinds of FQDN + +CUPS sometimes has problems with some kinds of FQDN - that means when you use FQDN in [option]`BrowsePoll` directive in [filename]`/etc/cups/cups-browsed.conf`, CUPS doesn't recognize it as valid hostname - it is solved by adding: + +---- +ServerAlias your.own.fully.qualified.hostname.com +---- + +into [filename]`/etc/cups/client.conf` and restarting cups service. + +=== There are less options available if the device is used as driverless than with a classic driver + +The similar situation can happen with *sane-airscan* supported scanners. Some devices declare less options via protocols - f.e. IPP 2.0+, WSD, eSCL - which support driverless solutions than via classic drivers. Usually it is an issue with device's firmware, which can be verify by checking the output of the following command: + +---- +$ ipptool -tv get-printer-attributes.test +---- + +The commands does the same IPP request which is done when a temporary queue appears in the print dialog or when you install the queue permanently. The printer options are set from the IPP response for this request, so if the option is missing in the response, CUPS cannot generate such a printer option. The solution is to try to update the device firmware, report the issue to the device manufacturer and at https://bugzilla.redhat.com[bugzilla] with logs. + +=== [F33+] Printing via IPPS doesn't work + +Fedora 33 came up with a raised bar regarding crypto-policies, so SSL and older TLS protocols are disabled on system level. The change breaks printing via IPPS to devices which don't support newer protocols. You can set back legacy crypto support in crypto-policies via: + +---- +$ sudo update-crypto-policies --set DEFAULT:FEDORA32 +---- + +The policy change transitionally has an impact on devices found by cups-browsed, because the daemon prefers IPPS uris if they are reported as available by printer/server. + +== HPLIP + +First I would like to mention that we are not responsible for support HPLIP, which is downloaded and installed from HP website. Please install hplip rpms from official Fedora repositories at most cases. + +=== Hp-plugin: file does not match its checksum. File may have been corrupted or altered + +This common error is mostly caused by external causes (server outage, network outage), when wget tries to download plugin, but it returns only error message. It is connected with message: + +---- +Plugin download failed with error code = N +---- + +where `N` is return value of [command]`wget` ([command]`man wget`), which is used for downloading proprietary plugin. Solutions for this issue may vary - you can wait until servers go up again or try to install plugin, which you download manually from http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/ (select "Select and install an existing local copy of the plug-in file" during [command]`hp-setup` or [command]`hp-plugin`). + +=== Unable to load cupsext + +This error can occur when hplip is installed from HP website, or its dependencies are mixed python2 and python3 packages or installed by pip. This is solved by removing all hplip packages (hplip, hplip-gui, hplip-libs, hplip-common, libsane-hpiao) and installing them again all from repositories. + +=== Missing hplip-gui + +GUI tools and GUI parts of HP commands are moved to hplip-gui subpackage, because the main package can work without GUI, so the main package is smaller. The outcome of this decision is HP commands need to be run with `-i` option for interactive mode, or hplip-gui subpackage needs to be installed. + +Tools, which need to be run with `-i` option for CLI or need to have hplip-gui installed for GUI: + +---- +hp-align +hp-clean +hp-colorcal +hp-diagnose_queues +hp-fab +hp-firmware +hp-info +hp-plugin +hp-sendfax +hp-setup +hp-testpage +hp-unload +---- + +Tools, which are in hplip-gui: + +---- +hp-check +hp-print +hp-systray +hp-toolbox +hp-devicesettings +hp-faxsetup +hp-linefeedcal +hp-makecopies +hp-printsettings +hp-wificonfig +---- + +=== HP printer isn't discovered, doesn't print or doesn't print well + +Some HP printers don't work well with URIs provided by CUPS (dnssd, usb, ipp) or they need proprietary plugin from HP, which cannot be in Fedora because of licensing issues. For such printers please try to run: + +---- +hp-setup -i -g +---- + +for interactive mode, or: + +---- +hp-setup -g +---- + +for graphic mode. This command installs HP printers and HP scanners. If you have issue about HP printer/HP scanner, which isn't discovered, doesn't print or doesn't print well, please try to install it by [command]`hp-setup`, if it helps. If it doesn't help, please file a bugzilla, attach output of hp-setup and mention that you tried [command]`hp-setup`. + +=== Device which needs plugin does not work after HPLIP update + +Devices which need plugin can stop to work after update to newer HPLIP version - it is due the check for plugin version in the code. The check is necessary to prevent inconsitencies when new features in open sourced HPLIP need new proprietary libraries from plugin. To make your printer work again, just download and install plugin again with: + +---- +$ hp-plugin -i +---- + +=== Devices which require a binary plugin stopped to work on Fedora Silverblue/CoreOS + +Devices which require a HP close source binary plugin need to have plugin installed every time you start/restart your PC by default. HP closed source script installs the plugins into a readonly directories, so the plugins are removed once you start/restart Fedora. The workaround is to try if your device supports driverless printing and scanning, try hplip-plugin package from RPMFusion or keep installing the plugin everytime you want to print. + +== golang-github-openprinting-ipp-usb + +=== USB printer/scanner doesn't work due a conflict on USB port + +*ipp-usb* daemon keeps the USB port of IPP-over-USB device opened for any possible IPP communication in the future, which blocks the port for other drivers (f.e. HPLIP, gutenprint, sane-backends...). + +For printers the solution is to _uninstall the queue with the driver_ by: + +---- +$ lpadmin -x +---- + +and start using the one from *ipp-usb* (as a xref:cups-terminology.adoc#_temporary_print_queues[CUPS temporary queue] or install a permanent one - the default device uri is `ipp://localhost:60000/ipp/print`). + +In case of scanners *sane-airscan* automatically picks up the virtual device from *ipp-usb* if the device is capable of using WSD or eSCL protocols. However, if the scanner had been supported by classic scanner driver such as hplip or sane-backends and is now claimed by *ipp-usb* because it supports *IPP-over-USB* driverless standard, the old scanner is still shown, but it won't work for scanning due USB conflict. It happens because classic backends just list any device which they can find on USB interfaces and matches the description the backend supports, but backends don't check whether they actually can communicate with the device until they try to open the USB port for scanning process itself. This becomes a problem for scanning applications, which automatically choose the previous scanner as a default choice for scanning (such as _Simple Scan_) - users have to pick a driverless scanner from the list of available scanners before they scan. + +The scanner device discovered by classic SANE backends can be disabled from showing it among available scanners by commenting out its entry in backend's configuration file located in [filename]`/etc/sane.d` or the whole backend name in [filename]`/etc/sane.d/dll.conf`/[filename]`/etc/sane.d/dll.d`, f.e. Canon MF440 Series is reported by `pixma` and `airscan` backends, but only `airscan` works because it is a backend based on network protocol and USB interface is claimed by `ipp-usb`, so we will disable the `pixma` backend by commenting its line in [filename]`/etc/sane.d/dll.conf`: + +---- +$ cat /etc/sane.d/dll.conf +... +pint +#pixma +plustek +... +---- + +If *ipp-usb* created device doesn't match your use case (the options you use are missing, the device doesn't work even if it is IPP-over-USB supported), please report the issue together with logs from [filename]`/var/log/ipp-usb/` directory at https://bugzilla.redhat.com[bugzilla]. *ipp-usb* itself supports quirks, which allows you to set the daemon to ignore your device and you can switch back to a classic driver. The steps are following: + +- get the device model name f.e. Canon MF440 Series: + +---- +$ sudo ipp-usb check +Configuration files: OK +IPP over USB devices: + Num Device Vndr:Prod Model + 1. Bus 001 Device 005 04a9:2823 "Canon MF440 Series" +---- + +- create a quirk file in [filename]`/etc/ipp-usb/quirks` directory in the format below: + +---- +$ cat /etc/ipp-usb/quirks/canon.conf +[Canon MF440 Series] + blacklist = true +---- + +- restart the `ipp-usb` service: + +---- +$ sudo systemctl restart ipp-usb +---- + + +== sane-airscan + +=== There are less options available if the device is discovered by sane-airscan than with a classic driver + +The similar situation can happen with `everywhere` or `driverless` printer models. Some devices declare less options via protocols - f.e. IPP 2.0+, WSD, eSCL - which support driverless solutions than via classic drivers. Usually it is an issue with device's firmware, which can be verify in sane-airscan debug logs and network traffic. The solution is to try to update the device firmware, report the issue to the device manufacturer and at https://bugzilla.redhat.com[bugzilla] with logs. diff --git a/modules/ROOT/pages/_partials/2delete-con_cups-terminology-for-printing-and-scanning.adoc b/modules/ROOT/pages/_partials/2delete-con_cups-terminology-for-printing-and-scanning.adoc new file mode 100644 index 0000000..823e581 --- /dev/null +++ b/modules/ROOT/pages/_partials/2delete-con_cups-terminology-for-printing-and-scanning.adoc @@ -0,0 +1,91 @@ +[id='con_cups-terminology-for-printing-and-scanning'] += Terminology for printing and scanning + +== Printing + +=== Print queue + +Abstraction unit in CUPS for a printer - it has a device uri, which represents connection to the device, and can exist with classic driver (PPD file from different package) or without (driverless printing). The entries you see in print dialogs and settings are those _print queues_. They can be _permanent or temporary_. + +=== Permanent print queues + +The queues with classic driver or driverless print queue which need to be shared further down the network. + +=== Temporary print queues + +The queue which don't need to be installed at all - they show up during print dialog and they disappear once the printing is done successfully. They rely on _driverless printing_. + +=== Remote CUPS queue + +The queue on the different machine, where other cupsd process is running, than on the local machine. They are usually found in enterprise solutions, where printers aren't in the same network as users or if admin wants a centralized monitoring above all printers. In such solutions, users set up _cups-browsed_ to install remote CUPS queue as local queues via _BrowsePoll_ directive, or install a specific queue via GNOME. There can be a solution how to redirect mDNS messages which CUPS server advertises to the networks with users, but I haven't been to setup this correctly yet. + +=== Classic drivers + +Those are the binaries and PPD files, which need to be installed for the device to work. This is older way of supporting devices, which will go away in the future. + +=== Driverless printing (wireless/ethernet) + +Most of modern devices (2010+) complies to AirPrint, Mopria or IPP Everywhere standard, which means they don't need a classic driver for being able to print. Those devices have IPP (Internet Printing Protocol) 2.0+ implemented within, are capable to 'advertise' themselves via mDNS and they support document formats like PDF, PCLm, JPEG, Apple Raster or PWG Raster. + +There are several prerequitises which need to fulfill in OS to have an access to the driverless feature: + +* avahi-daemon must run +* there needs to be a '.local' address resolver active - systemd-resolved or nss-mdns +* the device itself must have IPP port (631) and Bonjour/MDNS enabled +* IPP and MDNS need to be enabled in firewall + +How does the driverless printing work under the roof (put it simply): + +* CUPS sees the printer in mDNS messages via Avahi +* CUPS will find out the printer capabilities via IPP +* if there is a print job, CUPS will set up the filter chain to convert the incoming file into document format which printer understands (Apple Raster, PDF, PWG Raster, PCLm, JPEG) + +In case it is needed, PPD file is generated by PPD generator in CUPS or by _driverless_ binary. + +One of the features which use driverless printing is _CUPS temporary queues_. + +See xref:cups-useful-tricks.adoc#_how_to_find_out_whether_my_printer_is_capable_of_driverless_printing[manual] how to check if your printer is capable of driverless printing. + +=== Printing using a driver + +This printing is similar to driverless printing in matter of setting up a filter chain, but: + +* it can use limited mDNS and IPP functionality or it doesn't use them at all +* all information about device capabilities is taken from PPD (Postscript Printer Description) file +* can use a specialized filters and specialized communication with the device (depends on driver) + +The downsides of this approach is to rely on 3rd party drivers, you need to always install a permanent queue for it and it will go away in the future. + +=== Raw queue + +No filters are started by CUPS if you print to such a queue, the data are sent as they are to the target, no options are applied by CUPS - all regardless of incoming document format. It is required the application you use for printing sends a printer-ready data (in the correct format, with all chosen options applied) or the destination is set to the desired settings (f.e. printer/print server is set to do two-sided-long-edge duplex with grayscale settings, so every document printed will have this settings and user won't be able to change it in an application). + +This approach is usually set for printing to older label printers via a specific application, or, in the past, for printing to remote CUPS queue. Because CUPS has no way how to provide common user experience (finding out printer properties, converting various document formats into a document format the printer accepts, setting printing options) for such queues, their usage is deprecated and it will be removed in the future (in CUPS 3.X). + +=== Raw printing + +Raw printing happens if CUPS receives a file in document format which printer accepts directly and CUPS recognizes the format based on rules from its MIME database. CUPS daemon doesn't start any filters for such a job (it might encapsulate options into IPP packet, if the connection with the printer is over IPP) with exception for PDFs, where the _pdftopdf_ filter is started to apply generic settings like scaling, rotation etc. Raw printing itself happens on print queues with classic driver and driverless print queues. This functionality stays with CUPS 3.X. + +The difference between raw printing and raw queue is the raw printing is a situation which happens if CUPS daemon gets a file in format which printer accepts, so the daemon does not spawn additional filters for such job (with PDF being an exception), and spawns filters for document formats, which are not acceptable by the printer directly, whereas the raw queue is a queue, which CUPS daemon does not spawn any filters in any circumstances, and behaves like a Unix pipeline. + +=== Printer applications + +The binaries which provide support for older devices which aren't capable of complying to driverless standards. The core idea is they will be capable of accepting the old driver and then advertise itself as a device capable of driverless printing. Then the new CUPS will be able to see them and user will be able to print via them as if they were temporary queues. The currently available printer applications in Fedora are _ippeveprinter_ (a part of CUPS - see cups-printerapp package) and _lprint_ (provides support for devices which requires raw printing - mostly label printers). Other printer applications like https://github.com/OpenPrinting/ps-printer-app[ps-printer-app], https://github.com/OpenPrinting/ghostscript-printer-app[ghostscript-printer-app], https://github.com/OpenPrinting/hplip-printer-app[hplip-printer-app] and https://github.com/OpenPrinting/gutenprint-printer-app[gutenprint-printer-app] are currently available as SNAPs until cups-filters 2.0 is released and packaged. Printer applications are, except for _ippeveprinter_, written using _PAPPL_ library, so such printer application provides CLI interface and Web Interface for users to interact with. + +=== Driverless printing (USB) + +Driverless printing has its variant for devices which are connected via USB - it is covered by 'IPP over USB' standard. For make it work, you need 'ipp-usb' package, which will register the device with Avahi on localhost - then USB device will look as a wireless/ethernet device. The discovery/printing looks the same as with a wireless/ethernet device with driverless support. + +See xref:cups-useful-tricks.adoc#_how_to_find_out_whether_my_printer_is_capable_of_driverless_printing[manual] how to check for IPP-over-USB. + +== Scanning + +=== Classic scanning (via hplip and sane-backends) + +The classic scanning works via backends, which are binaries for communication with device. There are several backends, usually created by reverse engineering communication between scanner and MS Windows driver. None of classic backends implements a protocol, which is compatible with most devices available. + +=== Driverless scanning + +The driverless scanning uses sane-escl (not built in Fedora) and sane-airscan backends for communicating with newer devices. Those newer devices usually support eSCL (based on AirScan protocol by Apple) or WSD (Web Services for Devices by Microsoft), which _sane-airscan_ is able to use. + +Regarding USB scanning, it has the same requirement as printing. The device must support IPP over USB driverless standard and _ipp-usb_ package must be installed to get driverless scanning via USB - the package is required because it creates a driverless interface over USB interface which _sane-airscan_ uses for driverless communication with device. diff --git a/modules/ROOT/pages/_partials/2delete-con_cups-useful-tricks.adoc b/modules/ROOT/pages/_partials/2delete-con_cups-useful-tricks.adoc new file mode 100644 index 0000000..12b3be6 --- /dev/null +++ b/modules/ROOT/pages/_partials/2delete-con_cups-useful-tricks.adoc @@ -0,0 +1,399 @@ +[id='con_cups-useful-tricks'] += Useful tricks + +== How to install a print queue + +The fact whether you have to install a printer or not depends on several things: + +* what is the device you want to install - a printer from remote CUPS server (called remote print queue) or a printer, +* where is the device you want to install - connected by USB to your PC, in your local network, in a different network or installed on a remote server, +* how old is the device you want to install: +** standalone printers - most SOHO (Small Office, Home Office) and office printers made after 2010 have at least one way of supporting driverless printing, older devices depend on drivers - classic or printer applications, +** remote print queues on a server - any OS with CUPS 2.2.8 and newer or OS where IPP Everywhere support was backported (f.e. RHEL 8) are capable of supporting IPP Everywhere, otherwise a combination of driver and raw queue is needed in client-server communication, +* what is the purpose of the device where you install the printer - endpoint device, which is used by user as a desktop, or a server, which shares the installed printers further, +* what are your personal preferences - using or not using IPP protocol, using or not using mDNS for autoinstallation if possible from network layout. + +So there are several user stories based on those dependencies, which are described further down. + +=== Common user stories + +==== I have a printer made after 2015, I'm at home and want to print from my PC + +* the most common setup on desktop +* the printer is new enough to support driverless standards via USB and network, so driverless support doesn't depend on your connection +* the PC is an endpoint device, I don't want to share the printer +* I don't mind using mDNS and IPP, mDNS is enabled in my firewall, IPP and mDNS (or similar settings) are enabled on the printer, and mDNS resolution works (checked by pinging .local hostname) + +CUPS temporary queues for xref:_how_to_setup_cups_temporary_queues_with_usb_printer[USB] or xref:_how_to_setup_cups_temporary_queues_with_network_printer[network] are ideal for this use case. + +==== I have an older printer, I'm at home and want to print from my PC + +* the printer doesn't have a driverless support - check via xref:_how_to_find_out_whether_my_printer_is_capable_of_driverless_printing?[ipptool] for network printers (if the printer has IPP support and you enable the port) and via xref:_how_to_find_out_if_my_usb_device_supports_ipp_over_usb[lsusb] for USB printers, +* my PC is an endpoint device + +Currently there are two options - install the printer in xref:_how_to_install_a_printer_via_printer_application_in_snap_and_making_it_available_for_cups[printer application] and CUPS will automatically see it, or install it with classic driver xref:_how_to_install_a_permanent_print_queue[permanently]. Installation with classic driver is deprecated and will be removed in CUPS 3.0. + +==== I'm in a company which has a print server where office printers are installed, I want to print to the print server - no mDNS, but with driverless + +* the print server supports IPP Everywhere and is in a different network or doesn't register on mDNS, or I don't want to use mDNS +* remote print queue has the URI ipp://:631/printers/, where is the hostname of print server and is a name of a print queue I want to connect to +* xref:_how_to_find_out_whether_my_printer_is_capable_of_driverless_printing?[ipptool] command passes if the URI is used + +Such printers has to be installed xref:_how_to_install_a_permanent_print_queue[permanently] with IPP Everywhere driver. + +==== I'm in a company which has a printer server where office printers are installed, I want to print to the print server - with working mDNS in local network + +Such remote printers are discovered automatically via mDNS and used as xref:_how_to_setup_cups_temporary_queues_with_network_printer[CUPS temporary queues] on network - they are seen on mDNS and automatically picked up by dialogs. + +==== I want to print, but I don't want to or can't use mDNS, regardless whether my printer supports driverless printing + +Every printer which can't be discovered by mDNS has to be installed xref:_how_to_install_a_permanent_print_queue[permanently] in CUPS or, in CUPS 3.0, by printer profile. + +. Driverless printers: +* all of them supported by *IPP Everywhere* model under Manufacturer entry in CUPS Web UI and as *everywhere* in CLI +* types based on origin: +** Network: +*** URI: ipp://:631/ipp/print , where is hostname or IP address of the printer +** IPP-over-USB printers via ipp-usb: +*** URI: ipp://localhost:60000/ipp/print +** Printers installed via printer application: +*** URI: ipp://localhost:8000/ipp/print/ , where is the printer name chosen in printer application + +. Remote print queues on a print server: +* URI: ipp://:631/printers/ , where is server's IP address or hostname and is a name of the print queue installed on the server +* it depends on CUPS on the server whether a local printer which points to a printer on the server can be installed as IPP Everywhere model - usually CUPS 2.2.8 and newer support driverless and some distributions such as CentOS 8 backported the functionality as well +* otherwise it depends on printer's driver on the old server - the key is to prevent applying the options multiple times (so one of the connections has to be raw and loses some of the functionality) + +. Legacy or specialized printers +* (deprecated, to be removed in CUPS 3.0) can be discovered by CUPS and installed with classic drivers +* can be installed in printer application and then installed in CUPS as a permanent queue (see driverless printers - printers installed via printer application above) + +==== Driverless options don't do the trick for me on my driverless printer, I want to use features from the driver + +The current recommended action is to install the printer via xref:_how_to_install_a_printer_via_printer_application_in_snap_and_making_it_available_for_cups[printer application], which contains the classic driver, because installation the printer permanently in CUPS with classic driver is deprecated and it will be removed in CUPS 3.0. Then mDNS can be used to catch it by CUPS or the printer from printer application has to be installed permanently in CUPS as a IPP Everywhere printer. + +In case of IPP-over-USB printers, a reject rule has to be added as described in xref:cups-known-issues.adoc#_usb_printerscanner_doesnt_work_due_a_conflict_on_usb_port[known issues]. + +==== I install the printer on a server, which will share the printer further + +Printers on the server have to be installed xref:_how_to_install_a_permanent_print_queue[permanently] to be shared. IPP Everywhere model (directly to the printer or via printer application) is the ideal, but a classic driver with standardized PPD options on a server capable of using driverless is fine as well - clients can use IPP Everywhere model when pointing to the server and options are translated properly. Otherwise there is a possibility that some options aren't applied or applied twice. Don't forget about enabling IPP in firewall, setting ACLs to the server via [filename]`/etc/cups/cupsd.conf` and attaching the daemon to port 631 instead of localhost. + +==== I'm in a company with old print server incapable of driverless, I want to print + +The important thing is to prevent applying options multiple times in this scenario. There are several ways how to do it: + +* ask your IT support for the driver (print queue on the server has to be raw) +* use *ServerName* directive in [filename]`/etc/cups/client.conf` or *CUPS_SERVER* environment variable to connect to the server directly - you won't be able to do admin tasks, but capable of printing. + +=== How to find out whether my printer is capable of driverless printing? + +Network printers have the prerequisites - enablement of IPP port on the printer is the minimum, mDNS is required for automatic printer discovery by `libcups`. + +* [command]`ipptool` command which sends IPP Get-Printer-Attributes request to the network printer passes: + +---- +$ ipptool -tv ipp://printer.example.com:631/ipp/print get-printer-attributes.test +"/usr/share/cups/ipptool/get-printer-attributes.test": + Get-Printer-Attributes: + attributes-charset (charset) = utf-8 + attributes-natural-language (naturalLanguage) = en + printer-uri (uri) = ipp://printer.example.com:631/ipp/print + requested-attributes (1setOf keyword) = all,media-col-database + Get printer attributes using get-printer-attributes [PASS] +... +---- + +, where `printer.example.com` is the hostname or IP of your network printer, + +* look for AirPrint among device specification, +* https://www.pwg.org/printers/[Officially certified printers for IPP Everywhere], +* check xref:_how_to_setup_cups_temporary_queues_with_network_printer[manual] for enabling CUPS temporary queues - if your printer is seen in the end in CUPS commands that way, your printer is capable of driverless printing, +* [USB devices only] check for IPP over USB (xref:_how_to_find_out_if_my_usb_device_supports_ipp_over_usb[manual] here). + +=== How to find out if my USB device supports IPP over USB + +Check whether your USB device has a following text in [command]`lsusb -v` output: + +---- +... + bInterfaceClass 7 Printer + bInterfaceSubClass 1 Printer + bInterfaceProtocol 4 + iInterface 0 +... +---- + +If the device has the _bInterfaceClass 7_, _bInterfaceSubClass 1_ and _bInterfaceProtocol 4_ in the sequence, it supports IPP over USB which is critical for USB device driverless printing and scanning. + +=== How to setup CUPS temporary queues + +To setup the temporary queues correctly, there are several prerequisities: + +* printer/remote print queue has a driverless support and has it enabled, +* your PC has avahi-daemon service or avahi-daemon socket running, +* your PC has cups socket or service running, +* mDNS hostnames are resolvable - test by pinging a .local hostname + +==== How to setup CUPS temporary queues with network printer + +* additional requirement: +** enable MDNS in your firewall settings + +After this the temporary queue will appear in the print dialog and you don't need to install a specific print queue unless you have a reason for it. + +You can check if your printer is seen in mDNS messages by (*avahi-tools* must be installed): + +---- +$ avahi-browse -avrt +... += enp0s25 IPv4 HP LaserJet M1536dnf MFP (42307C) _ipp._tcp local + hostname = [NPI42307C.local] + address = [192.168.1.10] + port = [631] + txt = ["UUID=434e4239-4243-4a42-5859-3c4a9242307c" "Scan=T" "Duplex=T" "Color=F" "note=" "adminurl=http://NPI42307C.local." "priority=10" "product=(HP LaserJet M1536dnf MFP)" "ty=HP LaserJet M1536dnf MFP" "URF=CP99,W8,OB10,PQ3-4-5,DM1,IS1-4,MT1-2-3-5,MT1-2-3-5,RS600" "rp=ipp/printer" "pdl=application/postscript,application/vnd.hp-PCL,application/vnd.hp-PCLXL,application/pdf,image/urf" "qtotal=1" "txtvers=1"] +... +---- + +and if CUPS or its backends see the printer by commands: + +(lists all existing print queues - permanent or temporary) + +---- +$ lpstat -e +HP_LaserJet_M1536dnf_MFP_42307C_ +---- + +or + +(lists all devices, which CUPS sees in the local network or USB) + +---- +$ lpinfo -l -v +... +Device: uri = ipp://HP%20LaserJet%20M1536dnf%20MFP%20(42307C)._ipp._tcp.local/ + class = network + info = HP LaserJet M1536dnf MFP (driverless) + make-and-model = HP LaserJet M1536dnf MFP + device-id = MFG:HP;MDL:LaserJet M1536dnf MFP;CMD:PDF,PS,PCL,AppleRaster,URF; + location = +... +---- + +==== How to setup CUPS temporary queues with USB printer + +* additional requirements: +** install *ipp-usb*, which will transform IPP over USB devices to network printer on localhost: + +---- +$ sudo dnf -y install ipp-usb +---- + +Then you can follow the steps in xref:_how_to_setup_cups_temporary_queues_with_network_printer[manual] for network printers. + +=== How to install a permanent print queue + +Prerequisties for permanent driverless printers: enable IPP in your firewall, enable IPP on your printer if possible. + +==== Installation via CUPS web UI ==== + +* start cups.service + +---- +$ sudo systemctl start cups +---- + +* go to *http://localhost:631* in your browser +* go to *Administration* tab +* click on *Add printer* +* enter your credentials +* choose the found device or the connection you prefer - for driverless permanent queue choose *Internet Printing Protocol (ipp)* +* in case you didn't choose a found device, enter the device uri at the next page - for driverless printers they usually are: + +---- +Network printers: +ipp://:631/ipp/print + +USB printers via ipp-usb: +ipp://localhost:60000/ipp/print + +Non-driverless printers via printer application: +ipp://localhost:8000/ipp/print/ + +Printers pointing to a remote CUPS server: +ipp://:631/printers/ +---- + +* choose device manufacturer and model (*IPP Everywhere* for driverless printers) +* set a different default options if needed and finish + +*Notes:* + +Adding a permanent queue for driverless USB printers or non-driverless printers installed in a printer application is usually unnecessary, because they are shared by mDNS on localhost, so any application using CUPS 2.0+ API functions (cupsGetDests(), cupsGetNamedDest(), cupsCopyDestInfo()) should be able to pick them automatically (for network printer it depends whether the device is in the same subnet as your machine). Installling them permanently should be necessary only if an application doesn't use the recent API or to work around a bug which happens when using them as temporary queues. + +If there are more devices via *ipp-usb* or printer applications, they listen on different ports - devices via ipp-usb start on port 60000, separate printer applications start on port 8000. + + +==== Installation via CLI commands ==== + +* you will need a device uri - ``, which you can find by `lpinfo -v`: + +---- +$ lpinfo -v +direct usb://HP/Officejet%20Pro%208500%20A909a?serial=NNNNNNNNN&interface=1 + ==================================================================== +network dnssd://Officejet%20Pro%208500%20A909a%20%5B43FD8E%5D._pdl-datastream._tcp.local/ + ================================================================================= +---- + +or construct it manually - f.e. for IPP printers: + +---- +ipp://:631/ipp/print +---- + +and a driver name - ``, f.e.: + +---- +$ lpinfo -m +.... +everywhere IPP Everywhere +========== +... +---- + +---- +$ lpadmin -p -v -m -E +---- + +where `` and `` are underscored strings from previous commands and `` is a print queue name, which is chosen by you. + +== How to install a printer via printer application in SNAP and making it available for CUPS + +Currently printer applications are available in SNAPs on Fedora. I'm planning to release them as RPMs, but the code base will be the same, so its testing can happen even with SNAPs. + +* install snapd, + +First we have to install snapd for testing purposes: + +---- +$ sudo dnf -y install snapd +$ sudo ln -s /var/lib/snapd/snap /snap +$ snap version +---- + +If the installation had been successful, the last command will show snapd's version. + +* install and run printer application, + +First the SNAP with printer application has to be installed and started by the commands below. All printer applications are available in SNAP Store under the same names as they are at https://github.com/orgs/OpenPrinting/repositories[OpenPrinting repositories]. We will use [filename]`ps-printer-app` printer application in the next steps. + +---- +$ sudo snapd install --edge ps-printer-app +$ sudo snapd run ps-printer-app +---- + +* go to http://localhost:8000, + +After starting the printer application its web interface becomes available at http://localhost:8000 - if user installs and runs another printer application, it will become available at localhost on the next port (8001). The printer application can contain several printers (as [filename]`cupsd` does). + +* click on `Add Printer` on the main page, +* choose the printer's name, +* select the found device or choose `Network printer` from `Device` scroll menu and provide hostname or IP of the device, +* choose to auto-detect driver or select the driver by yourself, +* click on `Add Printer`, +* now the printer should be available at least on localhost via mDNS (if [filename]`avahi-daemon` is running and `nss-mdns` is installed)- check it by [filename]`avahi-browse`(`avahi-tools` has to be installed): + +---- +$ avahi-browse -avrt +... += lo IPv4 HP Laserjet M1536 _ipp._tcp local + hostname = [fedora-2.local] + address = [127.0.0.1] + port = [8000] + txt = ["Scan=F" "PaperMax=legal-A4" "Fax=F" "product=(HP LaserJet M1536dnf MFP Postscript (recommended))" "mopria-certified=1.3" "priority=0" "qtotal=1" "txtvers=1" "Duplex=T" "Color=F" "TLS=1.2" "URF=V1.5,W8,PQ3-4-5,DM1,FN3,IS0-20,MT1-5-6-3,OB10,RS300-600" "UUID=24837a30-5f87-3ac9-6d85-086d486092dd" "pdl=image/pwg-raster,image/urf,application/vnd.printer-specific,application/pdf,application/postscript,image/jpeg,image/png" "note=" "adminurl=http://fedora-2.local:8000/HP_Laserjet_M1536/" "ty=HP LaserJet M1536dnf MFP Postscript (recommended)" "rp=ipp/print/HP_Laserjet_M1536"] +... +---- + +* and by `lpstat -e`: + +---- +$ lpstat -e +... +HP_Laserjet_M1536 +... +---- + +The available printing options for the printer installed via printer application can be checked with [filename]`lpoptions` command: + +---- +$ lpoptions -p HP_Laserjet_M1536 -l +PageSize/Media Size: 184.15x260mm 195.09x269.88mm A4 A5 B5 DoublePostcardRotated Env10 EnvC5 EnvDL EnvMonarch Executive FanFoldGermanLegal ISOB5 Legal *Letter Postcard roc16k Custom.WIDTHxHEIGHT +InputSlot/Media Source: *Auto Tray1 Auto +MediaType/Media Type: *Unspecified Stationery Light6074 MidWeight96110 Heavy111130 ExtraHeavy131175 MonochromeLaserTransparency Labels StationeryLetterhead Envelope StationeryPreprinted Prepunched Colored Bond StationeryRecycled Rough Vellum +cupsPrintQuality/cupsPrintQuality: Draft *Normal High +ColorModel/Output Mode: *Gray +Duplex/Duplex: *None DuplexNoTumble DuplexTumble +OutputBin/OutputBin: *FaceDown +---- + +== How to install a scanner + +Scanners in Linux don't have to be installed the same way as printers are if they are in the same network or connected via USB - you just need *sane-backends* to be installed and any scanning application will communicate with scanner/multifunction device via the backend which supports the scanner. + +However, the older HP scanners and multifunction devices require an additional package - *hplip* - and its binary plugins downloaded via [command]`hp-plugin -i` if they aren't supported by sane-backends already. + +=== How to find out my multifunction device or standalone scanner is capable of driverless scanning? + +* check the device specification and look for eSCL/AirScan/WSD - if any of these are mentioned, the device is capable of driverless scanning +* most devices which advertise they can do AirPrint are capable of AirScan too +* [USB devices only] check for IPP over USB (xref:_how_to_find_out_if_my_usb_device_supports_ipp_over_usb[manual] here). + +=== How to make driverless scanning work + +For LAN located and USB devices: + +* have *avahi-daemon* enabled and running + +---- +$ sudo systemctl enable avahi-daemon +$ sudo systemctl start avahi-daemon +---- + +* enable MDNS in firewall +* [USB devices only] install *ipp-usb* + +For network scanners in a different network: + +* set the scanner device uri in [filename]`/etc/sane.d/airscan.conf` - see: + +---- +man sane-airscan +---- + +== How to setup mDNS with systemd-resolved + +systemd-resolved is enabled and running by default since F33 and can be setup to work with Avahi on mDNS support which CUPS needs - Avahi does the advertising, registering and sharing devices, and resolved will handle '.local' address resolution. It will work with following steps: + +* put [option]`MulticastDNS=resolve` into [filename]`/etc/systemd/resolved.conf` + +---- +$ sudo systemctl restart systemd-resolved +$ sudo nmcli connection modify connection.mdns yes connection.llmnr yes +$ sudo systemctl restart NetworkManager +---- + +== How to compress files + +Example: + +---- +$ tar -czvf cups-information.tar.gz /etc/cups cups.logs troubleshoot.txt lpinfo.log +---- + +== Restarting cups service + +You restart cups service with: + +---- +su -c 'systemctl restart cups.service' +---- diff --git a/modules/ROOT/pages/_partials/2delete-proc_disabling-gnome-screenlock.adoc b/modules/ROOT/pages/_partials/2delete-proc_disabling-gnome-screenlock.adoc new file mode 100644 index 0000000..725ec0d --- /dev/null +++ b/modules/ROOT/pages/_partials/2delete-proc_disabling-gnome-screenlock.adoc @@ -0,0 +1,24 @@ += Disabling the GNOME Automatic Screen Lock + +In the interest of safety and privacy, the GNOME automatic screen lock is enabled by default. + +When the screen locks after a period of inactivity, you must enter your password to unlock the screen. + +You can disable this feature at any time. + +To disable the GNOME automatic screen lock, complete the following steps. + +For Fedora 31 (GNOME 3.34): + +. On the desktop, navigate to the upper-right corner of the screen, click the arrow icon to expand the desktop options and then click the *Settings* icon. +. From the the *Settings* menu, select *Privacy*. +. On the *Privacy* page, select *Screen Lock*, and toggle the *Automatic Screen Lock* switch from *On* to *Off*. +. Close the window and verify that in the *Privacy* page, the *Screen Lock* is *Off*. + +For Fedora 32 (GNOME 3.36): + +. On the desktop, navigate to the upper-right corner of the screen, click the arrow icon to expand the desktop options and then click *Settings*. +. From the *Settings* menu, select *Privacy*, and then select *Screen Lock*. +. On the *Screen Lock* page, toggle the *Automatic Screen Lock* switch from *On* to *Off* + +To enable the automatic screen lock, repeat this process and toggle the switch from *Off* to *On*. diff --git a/modules/ROOT/pages/_partials/con_cups-known-issues.adoc b/modules/ROOT/pages/_partials/con_cups-known-issues.adoc deleted file mode 100644 index 9cbbfa5..0000000 --- a/modules/ROOT/pages/_partials/con_cups-known-issues.adoc +++ /dev/null @@ -1,231 +0,0 @@ -[id='con_cups-known-issues'] -= Known issues - -Here are several known issues, which arise with certain circumstances, and there isn't general solution or upstream didn't want to add the solution to its project: - -== cups-browsed - -=== Cannot print due 'No destination hostname provided by cups-browsed, is it running?' - - -cups-browsed sometimes loses connection to print server (usually with old ones, like cups-1.4.2) when laptop changes network connection (change of WiFi network or after hibernate/suspend). You can make printing working again with cancelling your jobs and restarting cups-browsed by - ----- -$ cancel -a -$ sudo systemctl restart cups-browsed ----- - -=== cups-browsed consumes large amount of CPU - -Creating local printer queues takes long time for some printers with larger PPD file, so timeout of http connection will time out and it creates infinite loop of creating local printer queues. To solve this issue, please add - ----- -HttpLocalTimeout N -HttpRemoteTimeout N ----- - -into [filename]`/etc/cups/cups-browsed.conf`, where `N` is number of seconds after which connection is timed out. Then restart cups-browsed service. This option is currently in Fedora 27 and above. - -=== [SINCE FEDORA 27] cups-browsed creates different printer queue names than before - -This issue is connected to remote cups queues, which are advertised by older CUPS version (usually below cups-1.5, e.g. RHEL 6). Cups-browsed creates local print queues named by printer's DNS-SD ID by default and naming by remote cups queue is enabled again by adding: - ----- -LocalQueueNamingRemoteCUPS RemoteName ----- - -into [filename]`/etc/cups/cups-browsed.conf` and restart cups-browsed service. - -== cups-filters - -=== Printing takes a long time or doesn't print at all - -When your printer needs a lot of time to do printing (from your POV) or doesn't print at all (some Xerox printers have such problems with gs renderer, so they are working again only with pdftops renderer), you can try to change the default postscript renderer. The default renderer in Fedora for most printers is gs filter from Ghostscript, but we have pdftops filter from Poppler for Brother, Minolta and Konica Minolta printers - this setup is called hybrid. - -Other available renderer setups are gs (from Ghostscript), pdftops and pdftocairo (from Poppler), mupdf (from mupdf) and acroread (from adobe reader, not in Fedora official repositories), then you can set different default renderer for your print queue like this: - ----- -# lpadmin -p -o pdftops-renderer-default=gs/pdftops/pdftocairo/mudpf/acroread/hybrid ----- - -*BEWARE:* Most 'slow' printing issues are caused by PDF creating applications, which generates bad PDF file - and that bad generated PDF file is mostly the core of problem. To sum it up, slow printing issue can rise again with different PDF file, then it is on user's decision: if he wants to print fast and probably sometimes change the default renderer, or slow printing is not such critical issue. - -== CUPS - -=== [Fixed in F33 and later] Firefox, Evince (PDF viewer), GVim, Gedit, Gnome Control Center show a 'dummy'/duplicate print queue, which doesn't work - -This bug is connected to every application which uses GTK print dialog. GTK dialog decided to take information about available from two sources - mDNS messages from Avahi and CUPS - this dummy/duplicate print queue is a print queue GTK created in its dialog based on Avahi messages, but it doesn't exist in CUPS, because no one created it, and later GTK behaves like it exists in CUPS. So every time an user wants to print, GTK sends a request to CUPS for this queue, but it gets dropped by CUPS because the queue doesn't exist. - -The feature which GTK is trying to do here is called CUPS temporary queues - GTK developers is currently working on a immediate fix in this https://bugzilla.redhat.com/show_bug.cgi?id=1784449[bugzilla]. The future plan is to use https://github.com/OpenPrinting/cpdb-backend-cups[cpdb-backend-cups] backend in GTK, but right now we are focusing on the intermediate fix. - -=== CUPS doesn't take nicely some kinds of FQDN - -CUPS sometimes has problems with some kinds of FQDN - that means when you use FQDN in [option]`BrowsePoll` directive in [filename]`/etc/cups/cups-browsed.conf`, CUPS doesn't recognize it as valid hostname - it is solved by adding: - ----- -ServerAlias your.own.fully.qualified.hostname.com ----- - -into [filename]`/etc/cups/client.conf` and restarting cups service. - -=== There are less options available if the device is used as driverless than with a classic driver - -The similar situation can happen with *sane-airscan* supported scanners. Some devices declare less options via protocols - f.e. IPP 2.0+, WSD, eSCL - which support driverless solutions than via classic drivers. Usually it is an issue with device's firmware, which can be verify by checking the output of the following command: - ----- -$ ipptool -tv get-printer-attributes.test ----- - -The commands does the same IPP request which is done when a temporary queue appears in the print dialog or when you install the queue permanently. The printer options are set from the IPP response for this request, so if the option is missing in the response, CUPS cannot generate such a printer option. The solution is to try to update the device firmware, report the issue to the device manufacturer and at https://bugzilla.redhat.com[bugzilla] with logs. - -=== [F33+] Printing via IPPS doesn't work - -Fedora 33 came up with a raised bar regarding crypto-policies, so SSL and older TLS protocols are disabled on system level. The change breaks printing via IPPS to devices which don't support newer protocols. You can set back legacy crypto support in crypto-policies via: - ----- -$ sudo update-crypto-policies --set DEFAULT:FEDORA32 ----- - -The policy change transitionally has an impact on devices found by cups-browsed, because the daemon prefers IPPS uris if they are reported as available by printer/server. - -== HPLIP - -First I would like to mention that we are not responsible for support HPLIP, which is downloaded and installed from HP website. Please install hplip rpms from official Fedora repositories at most cases. - -=== Hp-plugin: file does not match its checksum. File may have been corrupted or altered - -This common error is mostly caused by external causes (server outage, network outage), when wget tries to download plugin, but it returns only error message. It is connected with message: - ----- -Plugin download failed with error code = N ----- - -where `N` is return value of [command]`wget` ([command]`man wget`), which is used for downloading proprietary plugin. Solutions for this issue may vary - you can wait until servers go up again or try to install plugin, which you download manually from http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/ (select "Select and install an existing local copy of the plug-in file" during [command]`hp-setup` or [command]`hp-plugin`). - -=== Unable to load cupsext - -This error can occur when hplip is installed from HP website, or its dependencies are mixed python2 and python3 packages or installed by pip. This is solved by removing all hplip packages (hplip, hplip-gui, hplip-libs, hplip-common, libsane-hpiao) and installing them again all from repositories. - -=== Missing hplip-gui - -GUI tools and GUI parts of HP commands are moved to hplip-gui subpackage, because the main package can work without GUI, so the main package is smaller. The outcome of this decision is HP commands need to be run with `-i` option for interactive mode, or hplip-gui subpackage needs to be installed. - -Tools, which need to be run with `-i` option for CLI or need to have hplip-gui installed for GUI: - ----- -hp-align -hp-clean -hp-colorcal -hp-diagnose_queues -hp-fab -hp-firmware -hp-info -hp-plugin -hp-sendfax -hp-setup -hp-testpage -hp-unload ----- - -Tools, which are in hplip-gui: - ----- -hp-check -hp-print -hp-systray -hp-toolbox -hp-devicesettings -hp-faxsetup -hp-linefeedcal -hp-makecopies -hp-printsettings -hp-wificonfig ----- - -=== HP printer isn't discovered, doesn't print or doesn't print well - -Some HP printers don't work well with URIs provided by CUPS (dnssd, usb, ipp) or they need proprietary plugin from HP, which cannot be in Fedora because of licensing issues. For such printers please try to run: - ----- -hp-setup -i -g ----- - -for interactive mode, or: - ----- -hp-setup -g ----- - -for graphic mode. This command installs HP printers and HP scanners. If you have issue about HP printer/HP scanner, which isn't discovered, doesn't print or doesn't print well, please try to install it by [command]`hp-setup`, if it helps. If it doesn't help, please file a bugzilla, attach output of hp-setup and mention that you tried [command]`hp-setup`. - -=== Device which needs plugin does not work after HPLIP update - -Devices which need plugin can stop to work after update to newer HPLIP version - it is due the check for plugin version in the code. The check is necessary to prevent inconsitencies when new features in open sourced HPLIP need new proprietary libraries from plugin. To make your printer work again, just download and install plugin again with: - ----- -$ hp-plugin -i ----- - -=== Devices which require a binary plugin stopped to work on Fedora Silverblue/CoreOS - -Devices which require a HP close source binary plugin need to have plugin installed every time you start/restart your PC by default. HP closed source script installs the plugins into a readonly directories, so the plugins are removed once you start/restart Fedora. The workaround is to try if your device supports driverless printing and scanning, try hplip-plugin package from RPMFusion or keep installing the plugin everytime you want to print. - -== golang-github-openprinting-ipp-usb - -=== USB printer/scanner doesn't work due a conflict on USB port - -*ipp-usb* daemon keeps the USB port of IPP-over-USB device opened for any possible IPP communication in the future, which blocks the port for other drivers (f.e. HPLIP, gutenprint, sane-backends...). - -For printers the solution is to _uninstall the queue with the driver_ by: - ----- -$ lpadmin -x ----- - -and start using the one from *ipp-usb* (as a xref:cups-terminology.adoc#_temporary_print_queues[CUPS temporary queue] or install a permanent one - the default device uri is `ipp://localhost:60000/ipp/print`). - -In case of scanners *sane-airscan* automatically picks up the virtual device from *ipp-usb* if the device is capable of using WSD or eSCL protocols. However, if the scanner had been supported by classic scanner driver such as hplip or sane-backends and is now claimed by *ipp-usb* because it supports *IPP-over-USB* driverless standard, the old scanner is still shown, but it won't work for scanning due USB conflict. It happens because classic backends just list any device which they can find on USB interfaces and matches the description the backend supports, but backends don't check whether they actually can communicate with the device until they try to open the USB port for scanning process itself. This becomes a problem for scanning applications, which automatically choose the previous scanner as a default choice for scanning (such as _Simple Scan_) - users have to pick a driverless scanner from the list of available scanners before they scan. - -The scanner device discovered by classic SANE backends can be disabled from showing it among available scanners by commenting out its entry in backend's configuration file located in [filename]`/etc/sane.d` or the whole backend name in [filename]`/etc/sane.d/dll.conf`/[filename]`/etc/sane.d/dll.d`, f.e. Canon MF440 Series is reported by `pixma` and `airscan` backends, but only `airscan` works because it is a backend based on network protocol and USB interface is claimed by `ipp-usb`, so we will disable the `pixma` backend by commenting its line in [filename]`/etc/sane.d/dll.conf`: - ----- -$ cat /etc/sane.d/dll.conf -... -pint -#pixma -plustek -... ----- - -If *ipp-usb* created device doesn't match your use case (the options you use are missing, the device doesn't work even if it is IPP-over-USB supported), please report the issue together with logs from [filename]`/var/log/ipp-usb/` directory at https://bugzilla.redhat.com[bugzilla]. *ipp-usb* itself supports quirks, which allows you to set the daemon to ignore your device and you can switch back to a classic driver. The steps are following: - -- get the device model name f.e. Canon MF440 Series: - ----- -$ sudo ipp-usb check -Configuration files: OK -IPP over USB devices: - Num Device Vndr:Prod Model - 1. Bus 001 Device 005 04a9:2823 "Canon MF440 Series" ----- - -- create a quirk file in [filename]`/etc/ipp-usb/quirks` directory in the format below: - ----- -$ cat /etc/ipp-usb/quirks/canon.conf -[Canon MF440 Series] - blacklist = true ----- - -- restart the `ipp-usb` service: - ----- -$ sudo systemctl restart ipp-usb ----- - - -== sane-airscan - -=== There are less options available if the device is discovered by sane-airscan than with a classic driver - -The similar situation can happen with `everywhere` or `driverless` printer models. Some devices declare less options via protocols - f.e. IPP 2.0+, WSD, eSCL - which support driverless solutions than via classic drivers. Usually it is an issue with device's firmware, which can be verify in sane-airscan debug logs and network traffic. The solution is to try to update the device firmware, report the issue to the device manufacturer and at https://bugzilla.redhat.com[bugzilla] with logs. diff --git a/modules/ROOT/pages/_partials/con_cups-terminology-for-printing-and-scanning.adoc b/modules/ROOT/pages/_partials/con_cups-terminology-for-printing-and-scanning.adoc deleted file mode 100644 index 823e581..0000000 --- a/modules/ROOT/pages/_partials/con_cups-terminology-for-printing-and-scanning.adoc +++ /dev/null @@ -1,91 +0,0 @@ -[id='con_cups-terminology-for-printing-and-scanning'] -= Terminology for printing and scanning - -== Printing - -=== Print queue - -Abstraction unit in CUPS for a printer - it has a device uri, which represents connection to the device, and can exist with classic driver (PPD file from different package) or without (driverless printing). The entries you see in print dialogs and settings are those _print queues_. They can be _permanent or temporary_. - -=== Permanent print queues - -The queues with classic driver or driverless print queue which need to be shared further down the network. - -=== Temporary print queues - -The queue which don't need to be installed at all - they show up during print dialog and they disappear once the printing is done successfully. They rely on _driverless printing_. - -=== Remote CUPS queue - -The queue on the different machine, where other cupsd process is running, than on the local machine. They are usually found in enterprise solutions, where printers aren't in the same network as users or if admin wants a centralized monitoring above all printers. In such solutions, users set up _cups-browsed_ to install remote CUPS queue as local queues via _BrowsePoll_ directive, or install a specific queue via GNOME. There can be a solution how to redirect mDNS messages which CUPS server advertises to the networks with users, but I haven't been to setup this correctly yet. - -=== Classic drivers - -Those are the binaries and PPD files, which need to be installed for the device to work. This is older way of supporting devices, which will go away in the future. - -=== Driverless printing (wireless/ethernet) - -Most of modern devices (2010+) complies to AirPrint, Mopria or IPP Everywhere standard, which means they don't need a classic driver for being able to print. Those devices have IPP (Internet Printing Protocol) 2.0+ implemented within, are capable to 'advertise' themselves via mDNS and they support document formats like PDF, PCLm, JPEG, Apple Raster or PWG Raster. - -There are several prerequitises which need to fulfill in OS to have an access to the driverless feature: - -* avahi-daemon must run -* there needs to be a '.local' address resolver active - systemd-resolved or nss-mdns -* the device itself must have IPP port (631) and Bonjour/MDNS enabled -* IPP and MDNS need to be enabled in firewall - -How does the driverless printing work under the roof (put it simply): - -* CUPS sees the printer in mDNS messages via Avahi -* CUPS will find out the printer capabilities via IPP -* if there is a print job, CUPS will set up the filter chain to convert the incoming file into document format which printer understands (Apple Raster, PDF, PWG Raster, PCLm, JPEG) - -In case it is needed, PPD file is generated by PPD generator in CUPS or by _driverless_ binary. - -One of the features which use driverless printing is _CUPS temporary queues_. - -See xref:cups-useful-tricks.adoc#_how_to_find_out_whether_my_printer_is_capable_of_driverless_printing[manual] how to check if your printer is capable of driverless printing. - -=== Printing using a driver - -This printing is similar to driverless printing in matter of setting up a filter chain, but: - -* it can use limited mDNS and IPP functionality or it doesn't use them at all -* all information about device capabilities is taken from PPD (Postscript Printer Description) file -* can use a specialized filters and specialized communication with the device (depends on driver) - -The downsides of this approach is to rely on 3rd party drivers, you need to always install a permanent queue for it and it will go away in the future. - -=== Raw queue - -No filters are started by CUPS if you print to such a queue, the data are sent as they are to the target, no options are applied by CUPS - all regardless of incoming document format. It is required the application you use for printing sends a printer-ready data (in the correct format, with all chosen options applied) or the destination is set to the desired settings (f.e. printer/print server is set to do two-sided-long-edge duplex with grayscale settings, so every document printed will have this settings and user won't be able to change it in an application). - -This approach is usually set for printing to older label printers via a specific application, or, in the past, for printing to remote CUPS queue. Because CUPS has no way how to provide common user experience (finding out printer properties, converting various document formats into a document format the printer accepts, setting printing options) for such queues, their usage is deprecated and it will be removed in the future (in CUPS 3.X). - -=== Raw printing - -Raw printing happens if CUPS receives a file in document format which printer accepts directly and CUPS recognizes the format based on rules from its MIME database. CUPS daemon doesn't start any filters for such a job (it might encapsulate options into IPP packet, if the connection with the printer is over IPP) with exception for PDFs, where the _pdftopdf_ filter is started to apply generic settings like scaling, rotation etc. Raw printing itself happens on print queues with classic driver and driverless print queues. This functionality stays with CUPS 3.X. - -The difference between raw printing and raw queue is the raw printing is a situation which happens if CUPS daemon gets a file in format which printer accepts, so the daemon does not spawn additional filters for such job (with PDF being an exception), and spawns filters for document formats, which are not acceptable by the printer directly, whereas the raw queue is a queue, which CUPS daemon does not spawn any filters in any circumstances, and behaves like a Unix pipeline. - -=== Printer applications - -The binaries which provide support for older devices which aren't capable of complying to driverless standards. The core idea is they will be capable of accepting the old driver and then advertise itself as a device capable of driverless printing. Then the new CUPS will be able to see them and user will be able to print via them as if they were temporary queues. The currently available printer applications in Fedora are _ippeveprinter_ (a part of CUPS - see cups-printerapp package) and _lprint_ (provides support for devices which requires raw printing - mostly label printers). Other printer applications like https://github.com/OpenPrinting/ps-printer-app[ps-printer-app], https://github.com/OpenPrinting/ghostscript-printer-app[ghostscript-printer-app], https://github.com/OpenPrinting/hplip-printer-app[hplip-printer-app] and https://github.com/OpenPrinting/gutenprint-printer-app[gutenprint-printer-app] are currently available as SNAPs until cups-filters 2.0 is released and packaged. Printer applications are, except for _ippeveprinter_, written using _PAPPL_ library, so such printer application provides CLI interface and Web Interface for users to interact with. - -=== Driverless printing (USB) - -Driverless printing has its variant for devices which are connected via USB - it is covered by 'IPP over USB' standard. For make it work, you need 'ipp-usb' package, which will register the device with Avahi on localhost - then USB device will look as a wireless/ethernet device. The discovery/printing looks the same as with a wireless/ethernet device with driverless support. - -See xref:cups-useful-tricks.adoc#_how_to_find_out_whether_my_printer_is_capable_of_driverless_printing[manual] how to check for IPP-over-USB. - -== Scanning - -=== Classic scanning (via hplip and sane-backends) - -The classic scanning works via backends, which are binaries for communication with device. There are several backends, usually created by reverse engineering communication between scanner and MS Windows driver. None of classic backends implements a protocol, which is compatible with most devices available. - -=== Driverless scanning - -The driverless scanning uses sane-escl (not built in Fedora) and sane-airscan backends for communicating with newer devices. Those newer devices usually support eSCL (based on AirScan protocol by Apple) or WSD (Web Services for Devices by Microsoft), which _sane-airscan_ is able to use. - -Regarding USB scanning, it has the same requirement as printing. The device must support IPP over USB driverless standard and _ipp-usb_ package must be installed to get driverless scanning via USB - the package is required because it creates a driverless interface over USB interface which _sane-airscan_ uses for driverless communication with device. diff --git a/modules/ROOT/pages/_partials/con_cups-useful-tricks.adoc b/modules/ROOT/pages/_partials/con_cups-useful-tricks.adoc deleted file mode 100644 index 12b3be6..0000000 --- a/modules/ROOT/pages/_partials/con_cups-useful-tricks.adoc +++ /dev/null @@ -1,399 +0,0 @@ -[id='con_cups-useful-tricks'] -= Useful tricks - -== How to install a print queue - -The fact whether you have to install a printer or not depends on several things: - -* what is the device you want to install - a printer from remote CUPS server (called remote print queue) or a printer, -* where is the device you want to install - connected by USB to your PC, in your local network, in a different network or installed on a remote server, -* how old is the device you want to install: -** standalone printers - most SOHO (Small Office, Home Office) and office printers made after 2010 have at least one way of supporting driverless printing, older devices depend on drivers - classic or printer applications, -** remote print queues on a server - any OS with CUPS 2.2.8 and newer or OS where IPP Everywhere support was backported (f.e. RHEL 8) are capable of supporting IPP Everywhere, otherwise a combination of driver and raw queue is needed in client-server communication, -* what is the purpose of the device where you install the printer - endpoint device, which is used by user as a desktop, or a server, which shares the installed printers further, -* what are your personal preferences - using or not using IPP protocol, using or not using mDNS for autoinstallation if possible from network layout. - -So there are several user stories based on those dependencies, which are described further down. - -=== Common user stories - -==== I have a printer made after 2015, I'm at home and want to print from my PC - -* the most common setup on desktop -* the printer is new enough to support driverless standards via USB and network, so driverless support doesn't depend on your connection -* the PC is an endpoint device, I don't want to share the printer -* I don't mind using mDNS and IPP, mDNS is enabled in my firewall, IPP and mDNS (or similar settings) are enabled on the printer, and mDNS resolution works (checked by pinging .local hostname) - -CUPS temporary queues for xref:_how_to_setup_cups_temporary_queues_with_usb_printer[USB] or xref:_how_to_setup_cups_temporary_queues_with_network_printer[network] are ideal for this use case. - -==== I have an older printer, I'm at home and want to print from my PC - -* the printer doesn't have a driverless support - check via xref:_how_to_find_out_whether_my_printer_is_capable_of_driverless_printing?[ipptool] for network printers (if the printer has IPP support and you enable the port) and via xref:_how_to_find_out_if_my_usb_device_supports_ipp_over_usb[lsusb] for USB printers, -* my PC is an endpoint device - -Currently there are two options - install the printer in xref:_how_to_install_a_printer_via_printer_application_in_snap_and_making_it_available_for_cups[printer application] and CUPS will automatically see it, or install it with classic driver xref:_how_to_install_a_permanent_print_queue[permanently]. Installation with classic driver is deprecated and will be removed in CUPS 3.0. - -==== I'm in a company which has a print server where office printers are installed, I want to print to the print server - no mDNS, but with driverless - -* the print server supports IPP Everywhere and is in a different network or doesn't register on mDNS, or I don't want to use mDNS -* remote print queue has the URI ipp://:631/printers/, where is the hostname of print server and is a name of a print queue I want to connect to -* xref:_how_to_find_out_whether_my_printer_is_capable_of_driverless_printing?[ipptool] command passes if the URI is used - -Such printers has to be installed xref:_how_to_install_a_permanent_print_queue[permanently] with IPP Everywhere driver. - -==== I'm in a company which has a printer server where office printers are installed, I want to print to the print server - with working mDNS in local network - -Such remote printers are discovered automatically via mDNS and used as xref:_how_to_setup_cups_temporary_queues_with_network_printer[CUPS temporary queues] on network - they are seen on mDNS and automatically picked up by dialogs. - -==== I want to print, but I don't want to or can't use mDNS, regardless whether my printer supports driverless printing - -Every printer which can't be discovered by mDNS has to be installed xref:_how_to_install_a_permanent_print_queue[permanently] in CUPS or, in CUPS 3.0, by printer profile. - -. Driverless printers: -* all of them supported by *IPP Everywhere* model under Manufacturer entry in CUPS Web UI and as *everywhere* in CLI -* types based on origin: -** Network: -*** URI: ipp://:631/ipp/print , where is hostname or IP address of the printer -** IPP-over-USB printers via ipp-usb: -*** URI: ipp://localhost:60000/ipp/print -** Printers installed via printer application: -*** URI: ipp://localhost:8000/ipp/print/ , where is the printer name chosen in printer application - -. Remote print queues on a print server: -* URI: ipp://:631/printers/ , where is server's IP address or hostname and is a name of the print queue installed on the server -* it depends on CUPS on the server whether a local printer which points to a printer on the server can be installed as IPP Everywhere model - usually CUPS 2.2.8 and newer support driverless and some distributions such as CentOS 8 backported the functionality as well -* otherwise it depends on printer's driver on the old server - the key is to prevent applying the options multiple times (so one of the connections has to be raw and loses some of the functionality) - -. Legacy or specialized printers -* (deprecated, to be removed in CUPS 3.0) can be discovered by CUPS and installed with classic drivers -* can be installed in printer application and then installed in CUPS as a permanent queue (see driverless printers - printers installed via printer application above) - -==== Driverless options don't do the trick for me on my driverless printer, I want to use features from the driver - -The current recommended action is to install the printer via xref:_how_to_install_a_printer_via_printer_application_in_snap_and_making_it_available_for_cups[printer application], which contains the classic driver, because installation the printer permanently in CUPS with classic driver is deprecated and it will be removed in CUPS 3.0. Then mDNS can be used to catch it by CUPS or the printer from printer application has to be installed permanently in CUPS as a IPP Everywhere printer. - -In case of IPP-over-USB printers, a reject rule has to be added as described in xref:cups-known-issues.adoc#_usb_printerscanner_doesnt_work_due_a_conflict_on_usb_port[known issues]. - -==== I install the printer on a server, which will share the printer further - -Printers on the server have to be installed xref:_how_to_install_a_permanent_print_queue[permanently] to be shared. IPP Everywhere model (directly to the printer or via printer application) is the ideal, but a classic driver with standardized PPD options on a server capable of using driverless is fine as well - clients can use IPP Everywhere model when pointing to the server and options are translated properly. Otherwise there is a possibility that some options aren't applied or applied twice. Don't forget about enabling IPP in firewall, setting ACLs to the server via [filename]`/etc/cups/cupsd.conf` and attaching the daemon to port 631 instead of localhost. - -==== I'm in a company with old print server incapable of driverless, I want to print - -The important thing is to prevent applying options multiple times in this scenario. There are several ways how to do it: - -* ask your IT support for the driver (print queue on the server has to be raw) -* use *ServerName* directive in [filename]`/etc/cups/client.conf` or *CUPS_SERVER* environment variable to connect to the server directly - you won't be able to do admin tasks, but capable of printing. - -=== How to find out whether my printer is capable of driverless printing? - -Network printers have the prerequisites - enablement of IPP port on the printer is the minimum, mDNS is required for automatic printer discovery by `libcups`. - -* [command]`ipptool` command which sends IPP Get-Printer-Attributes request to the network printer passes: - ----- -$ ipptool -tv ipp://printer.example.com:631/ipp/print get-printer-attributes.test -"/usr/share/cups/ipptool/get-printer-attributes.test": - Get-Printer-Attributes: - attributes-charset (charset) = utf-8 - attributes-natural-language (naturalLanguage) = en - printer-uri (uri) = ipp://printer.example.com:631/ipp/print - requested-attributes (1setOf keyword) = all,media-col-database - Get printer attributes using get-printer-attributes [PASS] -... ----- - -, where `printer.example.com` is the hostname or IP of your network printer, - -* look for AirPrint among device specification, -* https://www.pwg.org/printers/[Officially certified printers for IPP Everywhere], -* check xref:_how_to_setup_cups_temporary_queues_with_network_printer[manual] for enabling CUPS temporary queues - if your printer is seen in the end in CUPS commands that way, your printer is capable of driverless printing, -* [USB devices only] check for IPP over USB (xref:_how_to_find_out_if_my_usb_device_supports_ipp_over_usb[manual] here). - -=== How to find out if my USB device supports IPP over USB - -Check whether your USB device has a following text in [command]`lsusb -v` output: - ----- -... - bInterfaceClass 7 Printer - bInterfaceSubClass 1 Printer - bInterfaceProtocol 4 - iInterface 0 -... ----- - -If the device has the _bInterfaceClass 7_, _bInterfaceSubClass 1_ and _bInterfaceProtocol 4_ in the sequence, it supports IPP over USB which is critical for USB device driverless printing and scanning. - -=== How to setup CUPS temporary queues - -To setup the temporary queues correctly, there are several prerequisities: - -* printer/remote print queue has a driverless support and has it enabled, -* your PC has avahi-daemon service or avahi-daemon socket running, -* your PC has cups socket or service running, -* mDNS hostnames are resolvable - test by pinging a .local hostname - -==== How to setup CUPS temporary queues with network printer - -* additional requirement: -** enable MDNS in your firewall settings - -After this the temporary queue will appear in the print dialog and you don't need to install a specific print queue unless you have a reason for it. - -You can check if your printer is seen in mDNS messages by (*avahi-tools* must be installed): - ----- -$ avahi-browse -avrt -... -= enp0s25 IPv4 HP LaserJet M1536dnf MFP (42307C) _ipp._tcp local - hostname = [NPI42307C.local] - address = [192.168.1.10] - port = [631] - txt = ["UUID=434e4239-4243-4a42-5859-3c4a9242307c" "Scan=T" "Duplex=T" "Color=F" "note=" "adminurl=http://NPI42307C.local." "priority=10" "product=(HP LaserJet M1536dnf MFP)" "ty=HP LaserJet M1536dnf MFP" "URF=CP99,W8,OB10,PQ3-4-5,DM1,IS1-4,MT1-2-3-5,MT1-2-3-5,RS600" "rp=ipp/printer" "pdl=application/postscript,application/vnd.hp-PCL,application/vnd.hp-PCLXL,application/pdf,image/urf" "qtotal=1" "txtvers=1"] -... ----- - -and if CUPS or its backends see the printer by commands: - -(lists all existing print queues - permanent or temporary) - ----- -$ lpstat -e -HP_LaserJet_M1536dnf_MFP_42307C_ ----- - -or - -(lists all devices, which CUPS sees in the local network or USB) - ----- -$ lpinfo -l -v -... -Device: uri = ipp://HP%20LaserJet%20M1536dnf%20MFP%20(42307C)._ipp._tcp.local/ - class = network - info = HP LaserJet M1536dnf MFP (driverless) - make-and-model = HP LaserJet M1536dnf MFP - device-id = MFG:HP;MDL:LaserJet M1536dnf MFP;CMD:PDF,PS,PCL,AppleRaster,URF; - location = -... ----- - -==== How to setup CUPS temporary queues with USB printer - -* additional requirements: -** install *ipp-usb*, which will transform IPP over USB devices to network printer on localhost: - ----- -$ sudo dnf -y install ipp-usb ----- - -Then you can follow the steps in xref:_how_to_setup_cups_temporary_queues_with_network_printer[manual] for network printers. - -=== How to install a permanent print queue - -Prerequisties for permanent driverless printers: enable IPP in your firewall, enable IPP on your printer if possible. - -==== Installation via CUPS web UI ==== - -* start cups.service - ----- -$ sudo systemctl start cups ----- - -* go to *http://localhost:631* in your browser -* go to *Administration* tab -* click on *Add printer* -* enter your credentials -* choose the found device or the connection you prefer - for driverless permanent queue choose *Internet Printing Protocol (ipp)* -* in case you didn't choose a found device, enter the device uri at the next page - for driverless printers they usually are: - ----- -Network printers: -ipp://:631/ipp/print - -USB printers via ipp-usb: -ipp://localhost:60000/ipp/print - -Non-driverless printers via printer application: -ipp://localhost:8000/ipp/print/ - -Printers pointing to a remote CUPS server: -ipp://:631/printers/ ----- - -* choose device manufacturer and model (*IPP Everywhere* for driverless printers) -* set a different default options if needed and finish - -*Notes:* - -Adding a permanent queue for driverless USB printers or non-driverless printers installed in a printer application is usually unnecessary, because they are shared by mDNS on localhost, so any application using CUPS 2.0+ API functions (cupsGetDests(), cupsGetNamedDest(), cupsCopyDestInfo()) should be able to pick them automatically (for network printer it depends whether the device is in the same subnet as your machine). Installling them permanently should be necessary only if an application doesn't use the recent API or to work around a bug which happens when using them as temporary queues. - -If there are more devices via *ipp-usb* or printer applications, they listen on different ports - devices via ipp-usb start on port 60000, separate printer applications start on port 8000. - - -==== Installation via CLI commands ==== - -* you will need a device uri - ``, which you can find by `lpinfo -v`: - ----- -$ lpinfo -v -direct usb://HP/Officejet%20Pro%208500%20A909a?serial=NNNNNNNNN&interface=1 - ==================================================================== -network dnssd://Officejet%20Pro%208500%20A909a%20%5B43FD8E%5D._pdl-datastream._tcp.local/ - ================================================================================= ----- - -or construct it manually - f.e. for IPP printers: - ----- -ipp://:631/ipp/print ----- - -and a driver name - ``, f.e.: - ----- -$ lpinfo -m -.... -everywhere IPP Everywhere -========== -... ----- - ----- -$ lpadmin -p -v -m -E ----- - -where `` and `` are underscored strings from previous commands and `` is a print queue name, which is chosen by you. - -== How to install a printer via printer application in SNAP and making it available for CUPS - -Currently printer applications are available in SNAPs on Fedora. I'm planning to release them as RPMs, but the code base will be the same, so its testing can happen even with SNAPs. - -* install snapd, - -First we have to install snapd for testing purposes: - ----- -$ sudo dnf -y install snapd -$ sudo ln -s /var/lib/snapd/snap /snap -$ snap version ----- - -If the installation had been successful, the last command will show snapd's version. - -* install and run printer application, - -First the SNAP with printer application has to be installed and started by the commands below. All printer applications are available in SNAP Store under the same names as they are at https://github.com/orgs/OpenPrinting/repositories[OpenPrinting repositories]. We will use [filename]`ps-printer-app` printer application in the next steps. - ----- -$ sudo snapd install --edge ps-printer-app -$ sudo snapd run ps-printer-app ----- - -* go to http://localhost:8000, - -After starting the printer application its web interface becomes available at http://localhost:8000 - if user installs and runs another printer application, it will become available at localhost on the next port (8001). The printer application can contain several printers (as [filename]`cupsd` does). - -* click on `Add Printer` on the main page, -* choose the printer's name, -* select the found device or choose `Network printer` from `Device` scroll menu and provide hostname or IP of the device, -* choose to auto-detect driver or select the driver by yourself, -* click on `Add Printer`, -* now the printer should be available at least on localhost via mDNS (if [filename]`avahi-daemon` is running and `nss-mdns` is installed)- check it by [filename]`avahi-browse`(`avahi-tools` has to be installed): - ----- -$ avahi-browse -avrt -... -= lo IPv4 HP Laserjet M1536 _ipp._tcp local - hostname = [fedora-2.local] - address = [127.0.0.1] - port = [8000] - txt = ["Scan=F" "PaperMax=legal-A4" "Fax=F" "product=(HP LaserJet M1536dnf MFP Postscript (recommended))" "mopria-certified=1.3" "priority=0" "qtotal=1" "txtvers=1" "Duplex=T" "Color=F" "TLS=1.2" "URF=V1.5,W8,PQ3-4-5,DM1,FN3,IS0-20,MT1-5-6-3,OB10,RS300-600" "UUID=24837a30-5f87-3ac9-6d85-086d486092dd" "pdl=image/pwg-raster,image/urf,application/vnd.printer-specific,application/pdf,application/postscript,image/jpeg,image/png" "note=" "adminurl=http://fedora-2.local:8000/HP_Laserjet_M1536/" "ty=HP LaserJet M1536dnf MFP Postscript (recommended)" "rp=ipp/print/HP_Laserjet_M1536"] -... ----- - -* and by `lpstat -e`: - ----- -$ lpstat -e -... -HP_Laserjet_M1536 -... ----- - -The available printing options for the printer installed via printer application can be checked with [filename]`lpoptions` command: - ----- -$ lpoptions -p HP_Laserjet_M1536 -l -PageSize/Media Size: 184.15x260mm 195.09x269.88mm A4 A5 B5 DoublePostcardRotated Env10 EnvC5 EnvDL EnvMonarch Executive FanFoldGermanLegal ISOB5 Legal *Letter Postcard roc16k Custom.WIDTHxHEIGHT -InputSlot/Media Source: *Auto Tray1 Auto -MediaType/Media Type: *Unspecified Stationery Light6074 MidWeight96110 Heavy111130 ExtraHeavy131175 MonochromeLaserTransparency Labels StationeryLetterhead Envelope StationeryPreprinted Prepunched Colored Bond StationeryRecycled Rough Vellum -cupsPrintQuality/cupsPrintQuality: Draft *Normal High -ColorModel/Output Mode: *Gray -Duplex/Duplex: *None DuplexNoTumble DuplexTumble -OutputBin/OutputBin: *FaceDown ----- - -== How to install a scanner - -Scanners in Linux don't have to be installed the same way as printers are if they are in the same network or connected via USB - you just need *sane-backends* to be installed and any scanning application will communicate with scanner/multifunction device via the backend which supports the scanner. - -However, the older HP scanners and multifunction devices require an additional package - *hplip* - and its binary plugins downloaded via [command]`hp-plugin -i` if they aren't supported by sane-backends already. - -=== How to find out my multifunction device or standalone scanner is capable of driverless scanning? - -* check the device specification and look for eSCL/AirScan/WSD - if any of these are mentioned, the device is capable of driverless scanning -* most devices which advertise they can do AirPrint are capable of AirScan too -* [USB devices only] check for IPP over USB (xref:_how_to_find_out_if_my_usb_device_supports_ipp_over_usb[manual] here). - -=== How to make driverless scanning work - -For LAN located and USB devices: - -* have *avahi-daemon* enabled and running - ----- -$ sudo systemctl enable avahi-daemon -$ sudo systemctl start avahi-daemon ----- - -* enable MDNS in firewall -* [USB devices only] install *ipp-usb* - -For network scanners in a different network: - -* set the scanner device uri in [filename]`/etc/sane.d/airscan.conf` - see: - ----- -man sane-airscan ----- - -== How to setup mDNS with systemd-resolved - -systemd-resolved is enabled and running by default since F33 and can be setup to work with Avahi on mDNS support which CUPS needs - Avahi does the advertising, registering and sharing devices, and resolved will handle '.local' address resolution. It will work with following steps: - -* put [option]`MulticastDNS=resolve` into [filename]`/etc/systemd/resolved.conf` - ----- -$ sudo systemctl restart systemd-resolved -$ sudo nmcli connection modify connection.mdns yes connection.llmnr yes -$ sudo systemctl restart NetworkManager ----- - -== How to compress files - -Example: - ----- -$ tar -czvf cups-information.tar.gz /etc/cups cups.logs troubleshoot.txt lpinfo.log ----- - -== Restarting cups service - -You restart cups service with: - ----- -su -c 'systemctl restart cups.service' ----- diff --git a/modules/ROOT/pages/_partials/proc_disabling-gnome-screenlock.adoc b/modules/ROOT/pages/_partials/proc_disabling-gnome-screenlock.adoc deleted file mode 100644 index 725ec0d..0000000 --- a/modules/ROOT/pages/_partials/proc_disabling-gnome-screenlock.adoc +++ /dev/null @@ -1,24 +0,0 @@ -= Disabling the GNOME Automatic Screen Lock - -In the interest of safety and privacy, the GNOME automatic screen lock is enabled by default. - -When the screen locks after a period of inactivity, you must enter your password to unlock the screen. - -You can disable this feature at any time. - -To disable the GNOME automatic screen lock, complete the following steps. - -For Fedora 31 (GNOME 3.34): - -. On the desktop, navigate to the upper-right corner of the screen, click the arrow icon to expand the desktop options and then click the *Settings* icon. -. From the the *Settings* menu, select *Privacy*. -. On the *Privacy* page, select *Screen Lock*, and toggle the *Automatic Screen Lock* switch from *On* to *Off*. -. Close the window and verify that in the *Privacy* page, the *Screen Lock* is *Off*. - -For Fedora 32 (GNOME 3.36): - -. On the desktop, navigate to the upper-right corner of the screen, click the arrow icon to expand the desktop options and then click *Settings*. -. From the *Settings* menu, select *Privacy*, and then select *Screen Lock*. -. On the *Screen Lock* page, toggle the *Automatic Screen Lock* switch from *On* to *Off* - -To enable the automatic screen lock, repeat this process and toggle the switch from *Off* to *On*. diff --git a/modules/ROOT/pages/cups-debug-printing-issues.adoc b/modules/ROOT/pages/cups-debug-printing-issues.adoc new file mode 100644 index 0000000..7d9fb1b --- /dev/null +++ b/modules/ROOT/pages/cups-debug-printing-issues.adoc @@ -0,0 +1,549 @@ += CUPS – How to Debug Printing Issues +Brandon Nielsen ; Zdenek Dohnal +:revnumber: F35 onwards +:revdate: 2022-02-10 +:category: Printing +:tags: How-to, Printer, Troubleshooting +:page-aliases: how-to-debug-printing-problems.adoc + +If you are experiencing a problem with printing, please take a look at the https://fedoraproject.org/wiki/Bugs/Common[common bugs] page before filing a bug. If the problem you are seeing is not listed there or none of the workarounds seem to help, please consider xref:cups-filing-a-bug-report.adoc#_filing_a_bug_report[filing a bug report] to help us make Fedora run better on your hardware. + + + +== Identifying your problem area + +Printing issues can be fairly complex and active cooperation or lots of data can be requested from reporter by maintainer to helping maintainer to at least understand and (if it is not hardware specific issue) reproduce the issue, so please have a patience and try to narrow the problem as much you are able to for maintainers. + +There can be: + +* issues with seeing or connecting to the printer (it can be cups backend issues, avahi issues, libusb issues, cups-browsed issues), +* accessibility issues (correct/wrong setup in cupsd.conf or its bad interpretation by cupsd daemon, bad cooperation with NIS, SSSD...), +* printing with help of samba (issues with smb backend, which is part of samba) or with samba authenticated through Kerberos (samba_krb5_printing), +* issues with filters used during filtering the document into document format supported by printer, which influence how or if the document will be printed (issue with filters - pdftops, pdftopdf, pstops, bannertopdf etc. - or issues with binaries or libraries which filters uses - libgs, qpdf, poppler...), +* issues with Postscript Printer Description files, which are old way of defining printers capabilities like supported page sizes, borders etc... + +Not mentioning possible limitations or issues in firmware or hardware of printer itself, so any kind of data or narrowing the issue is welcomed. + +The best start is to attach files with logs described further down. + +=== CUPS logging + +All CUPS logging is redirected to journal by default since Fedora 28 (there was a redirecting of error_log to journal by default before Fedora 28). + +We need to define two different ways of capturing incident-bound CUPS whole logs - the one if the broken print queue isn't provided by HPLIP and the other if it is. They differs in the filter option of journald - if you use non-HPLIP queue for debugging, it is okay to gather the logs from cups systemd unit (by '-u cups'), because all error messages are correctly redirected to cups systemd unit logging and they are accessible in the output after unit filtering. HPLIP libraries are not implemented to do the same (upstream is unresponsive to accept a potencial fix into the project and the issue is not critical enough to drag a downstream patch forever), so their messages aren't marked for cups systemd unit and they're filtered out after calling journald with '-u cups'. For such queues journald log without filtering is required. + +[NOTE] +=============================== +Incident-bound journald log without filtering is required only for HPLIP print queues (their device uri starts with hp://) and it is unwanted for other queues, because it can be hard to read in larger cases. Please attach incident-bound journald log only when it is necessary. +=============================== + +==== Location of CUPS logging + +CUPS logging is located in the system journal by default, but the logging into a file can be set in [filename]`/etc/cups/cups-files.conf` with directive [option]`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. + +Setting the logging to a file has following cons (without further operations): + +* unable to get only logs connected to a job without chaining more commands +* unable to get logs for specified time frame without chaining more commands + +For capturing a incident-bound logs `tail -f` can be used e.g.: + +---- +tail -f /var/log/cups/error_log +---- + +==== Enable CUPS debug logging + +Enable full debugging information with: + +---- +$ cupsctl LogLevel=debug2 +---- + +==== CUPS job log + +[IMPORTANT] +=============================== +If the problem appears when you sent document to print or if you are trying to, capture logs for this job. If the job log is available, its attaching is *REQUIRED*. +=============================== + +===== Prepare CUPS for job logging + +For being able to see specific job log, please turn on: + +---- +PreserveJobFiles Yes +---- + +in your [filename]`/etc/cups/cupsd.conf` file and restart cup service. Do not forget to remove the line after you are done with debugging. [command]`lpstat -W all` seems to be empty after printing if you do not enable the directive. + +===== Get a job log for a specific job ID + +To capture job log you need to know Job ID (JID) of the job - it is the number after dash in a request ID: + +Request ID looks like this: + +---- +- +---- + +and can be seen in terminal if you send a document to print by [command]`lp` command: + +---- +$ lp -d ... +request id is - (N file(s)) +---- + +Or when you list jobs (see [command]`man lpstat`) - the latest job is at the end: + +---- +$ lpstat -W all +... +- 1024 Wed 11 Jan 2017 05:52:19 PM CET +---- + +You can get the latest job logs automatically (if you have [command]`awk` installed and [command]`lpstat -W` all returns jobs) by: + +---- +$ journalctl -u cups JID=`lpstat -W all | awk '{print $1}' | awk -F '-' '{print $NF}' | tail -n 1` > cups_job_log +---- + +Or manually, if you found JID by yourself: + +---- +journalctl -u cups JID= > cups_job_log +---- + +==== Incident-bound cupsd log (broken print queue isn't HPLIP supported) + +Sometimes we cannot bind the error with a specific print job, so the job log is uneffective. Incident-bound cupsd log is needed. + +===== How to start to capture incident-bound cupsd logging + +In new terminal/terminal tab, please issue: + +---- +journalctl -f -u cups > cups_whole_log +---- + +===== How to get incident-bound cupsd logging + +After you trigger the error condition you are trying to diagnose e.g. printing something, try to find a printer via [command]`lpinfo` etc., you terminate capturing incident-bound cupsd log from xref:_how_to_start_to_capture_incident_bound_cupsd_logging[step above] by `+`. + +==== Incident-bound cupsd log (broken print queue is HPLIP supported) + +Unfortunately, HPLIP libraries don't log into CUPS unit in journal, so if your print queue is installed with HPLIP driver (its device uri starts with `hp://`), we need incident-bound journal log. + +===== How to start to capture incident-bound journal logging + +In new terminal/terminal tab, please issue: + +---- +journalctl -f > journal_whole_log +---- + +===== How to get incident-bound journal logging + +After you trigger the error condition you are trying to diagnose e.g. printing something, running HP script etc., you terminate capturing incident-bound journal log from xref:_how_to_start_to_capture_incident_bound_journal_logging[step above] by `+`. + +==== Turning off debug logging + +Please attach [filename]`cups_job_log` for the problematic job, [filename]`cups_whole_log` or [filename]`journal_log` if you caught whole cupsd log during the problematic event to bug report as an attachment. + +Then to turn off debugging information, do this: + +---- +$ sudo sed -i 's,LogLevel debug2,LogLevel warn,' /etc/cups/cupsd.conf +$ sudo systemctl restart cups +---- + +==== More commands for working with systemd-journald + +View the log messages with: + +---- +journalctl -u cups -e +---- + +or: + +---- +journalctl -u cups --since=... +---- + +To filter out messages relating to a specific job ID, use: + +---- +journalctl -u cups JID=... +---- + +(tab completion will show you which job IDs have log messages) + +=== cups-browsed logging + +cups-browsed daemon was introduced in Fedora around cups-1.5 version. It can browse Bonjour broadcasts, CUPS broadcasts (deprecated) and LDAP servers for printers and create or remove local queues pointing to those printers. It can creates broadcasts of local CUPS queues, but it is marked as deprecated. + +For setting debug logging on you need to add: + +---- +DebugLogging stderr +---- + +to [filename]`/etc/cups/cups-browsed.conf`. + +The logs will be available in system journal after cups-browsed restart. + +=== HPLIP scripts debug logging + +Python scripts from HPLIP (e.g. [command]`hp-setup`, [command]`hp-clean`, [command]`hp-scan`) have debug logging redirected to the standard error file descriptor, so they are not logged in journal. For getting their debug logging, run the script with `-ldebug` parameter e.g.: + +---- +$ hp-setup -ldebug -i +---- + +and reproduce the issue. Then copy the messages from terminal into [filename]`hp_script_log`. Please attach the file to the bugzilla ticket too. + +=== What make and model is my printer? + +Each different printer has a model-specific Device ID. You can find out with the [command]`lpinfo` command: + +---- +su -c "lpinfo -l -v" +---- + +This command runs each of the backends in discovery mode, to get them to report devices they can automatically detect. This will output a series of blocks of lines, each one like this: + +---- +Device: uri = usb://HP/DESKJET%20990C?serial=U123456789AB + class = direct + info = HP DESKJET 990C + make-and-model = HP DESKJET 990C + device-id = MFG:HEWLETT-PACKARD;MDL:DESKJET 990C;CMD:MLC,PCL,PML;CLS:PRI +NTER;DES:Hewlett-Packard DeskJet 990C;SN:U123456789AB;S:00808880800010032C100000 +0C2000000;P:0800,FL,B0;J: ; + location = +---- + +The line which identifies this particular model type is the long one that starts "device-id =" (shown here wrapping over three lines). + +Note that if your printer cannot be automatically detected, you may still be able to find out the Device ID by running the appropriate backend with the printer hostname as the argument. The *usb*, *parallel*, *snmp*, and *dnssd* backends all try to report the actual Device ID given by the printer. + +---- +$ /usr/lib/cups/backend/snmp 10.34.18.3 + +network socket://10.34.18.3 "HP Color LaserJet CP2025dn" "HP Color LaserJet CP2025dn" +"MFG:Hewlett-Packard;CMD:PJL,PML,PCLXL,POSTSCRIPT,PCL;MDL:HP Color LaserJet CP2025dn; +CLS:PRINTER;DES:Hewlett-Packard Color LaserJet CP2025dn;MEM:MEM=55MB;COMMENT:RES=600x8;" "HP Color LaserJet CP2025dn" +---- + +Device ID is in this case (see http://www.cups.org/documentation.php/doc-1.5/man-backend.html[backend(7)]) the last but one field. + +=== Which print queues are available for me? + +The queues on your machine can be permanent ones or temporary. CUPS is capable to list all available print queues on the local network (permanent and temporary queues) by: + +---- +$ lpstat -e +---- + +For permanent queues you are able to get more info with: + +---- +$ lpstat -t +---- + +=== Which driver am I using? + +The PPD file for the printer queue can tell you which driver is in use. You can use this command to find out which driver is being used: + +---- +grep -H '^*NickName:' /etc/cups/ppd/*.ppd +---- + +You can also find this out using the [command]`system-config-printer` application. Double-click on the icon for the queue and look at the Make and Model field. + +To see the available drivers, click on the _Change..._ button next to that field. You might find it useful to try another driver to see if that shows the same problem. + +==== Driverless models + +Most printers released since 2010 are capable of AirPrint or IPP Everywhere, which means they don't need to be installed to work - the device is found by Avahi and the print capabilities are communicated via IPP protocol - they are basically driverless devices. There are two solutions in Fedora which implement IPP everywhere: + +- CUPS 'everywhere' model +- cups-filters 'driverless' driver + +===== CUPS 'everywhere' model + +It is CUPS implementation of IPP everywhere standard, available as a special printer model. The model is used when you use CUPS temporary queue for your device or if you install your device with as IPP Everywhere model in CUPS web ui or via lpadmin (using `-m everywhere`). + +Because the created PPD file depends on IPP communication with printer, we need info which is gathered from the device. You can use [command]`ipptool` for that: + +---- +$ ipptool --ippserver ipptool.attr get-printer-attributes.test +---- + +Attach the created [filename]`ipptool.attr` to the bugzilla ticket if needed. + +===== cups-filters 'driverless' driver + +Cups-filters special driver which is used for generating PPD according IPP Everywhere standard. The driver is used if you choose *driverless* model during printer installation. + +We need get-printer-attributes request output too: + +---- +$ ipptool --ippserver ipptool.attr get-printer-attributes.test +---- + +and debug logs from the driver itself when it generates PPD for your device: + +---- +$ driverless -d cat 2> driverless_debug > created_ppd +---- + +Attach all created files to the bugzilla ticket if needed. + +=== Finding where the problem lies + +When a print job is processed it is sent through a chain of _filters_ to convert the file into a format the printer can understand, and then finally sent to a _backend_, a program which can transport the data to the printer. By slightly changing how you print you can try a different printing path to see if that changes anything. If it works around the problem, you know which area the problem was in -- include that information in a bug report so that we can fix it. + +==== Application + +Try printing from a different application to see if the problem goes away or if it occurs regardless of how a file is printed. Try printing the document from the command line using the [command]`lp` command. + +==== Document format + +If you are having problems printing PDF files, try printing other types of file to see if the problem is with printing anything or if it is specific to printing PDF files. Try converting the file to a different format and printing that. + +If the problem relates to printing text files, try removing/installing the paps package. This package provides an alternative text-to-PostScript filter to the one that comes with CUPS. + +To inspect the document that was submitted to CUPS for printing, enable the [option]`PreserveJobFiles` option like this: + +---- +cupsctl PreserveJobFiles=yes +---- + +Submitted job documents will remain in `/var/spool/cups`. There are files with two types of names - [filename]`dXXXXX-YYY` and [filename]`cXXXXX`. [filename]`dXXXXX-YYY` is file which goes to CUPS system, unfiltered file - `XXXXX` is job ID, which is filled with zeros to be 5 characters long, and `YYY` is sequence number of file in the job. [filename]`cXXXXX` is file which contains printing options for a job specified by job ID in `XXXXX`. Please attach [filename]`dXXXXX-YYY` to the bug for a job when you experience the issue + +===== Running filters by hand + +More advanced users may like to try running the CUPS filters by hand and examining the data file at each step as it is converted between different formats. Here is an example of doing this for a gutenprint queue named pqueue with the CUPS test page which is its own special MIME type, `application/vnd.cups-banner`: + +First you need to know the filter pipeline for `application/vnd.cups-banner` -> `printer/pqueue` (output MIME type). You can either xref:_enable_cups_debug_logging[enable debugging], print a test page, get xref:_cups_job_log[CUPS job log] and in cups_job_log you'll find something similar to: + +---- +envp[29]="FINAL_CONTENT_TYPE=printer/pqueue" +Started filter /usr/lib/cups/filter/bannertopdf (PID 1111) +Started filter /usr/lib/cups/filter/pdftopdf (PID 1112) +Started filter /usr/lib/cups/filter/gstoraster (PID 1113) +Started filter /usr/lib/cups/filter/rastertogutenprint.5.2 (PID 1114) +---- + +or run + +---- +/usr/lib/cups/filter/bannertopdf 1 me '' 1 '' bannertopdf.pdf +cupsfilter -e -m printer/pqueue -p /etc/cups/ppd/pqueue.ppd bannertopdf.pdf > /dev/null +---- + +and you'll see: + +---- +INFO: pdftopdf (PID 1111) started. +INFO: gstoraster (PID 1112) started. +INFO: rastertogutenprint.5.2 (PID 1113) started. +---- + + +[NOTE] +=============================== +This filter pipeline is from cups-1.6. With cups < 1.6 you can see bannertops -> pstops -> pstoraster instead. +=============================== + +Now you can run filters by hand: + +---- +export PPD=/etc/cups/ppd/pqueue.ppd +/usr/lib/cups/filter/bannertopdf 1 me '' 1 '' bannertopdf.pdf +/usr/lib/cups/filter/pdftopdf 1 me '' 1 '' pdftopdf.pdf +/usr/lib/cups/filter/pdftoraster 1 me '' 1 ''out.ras +/usr/lib/cups/filter/rastertogutenprint.5.2 1 me '' 1 ''out.prn +---- + +Here, [command]`evince` or [command]`okular` can be used to examine the output after the first two filters, [command]`rasterview` can be used to examine the output of the third filter, and the last filter's output must be inspected by hand or sent directly ([command]`lpr -oraw out.prn`) to the printer. + +==== Driver + +If you have access to a different make/model of printer it might be worth trying to see if the problem occurs on both of them or just one. This can give an indication about whether it is a problem with a particular driver, or if it is a more general problem. + +Even if you only have access to the one printer there is often a choice of drivers to use for a given printer model, and trying each one in turn can be useful in narrowing down the problem. See xref:_which_driver_am_i_using[above] for how to do that. + +===== Foomatic + +For Foomatic drivers you can try enabling Foomatic debugging by editing the file [filename]`/etc/foomatic/filter.conf` and adding a line: + +---- +debug: 1 +---- + +Next time you print a job to a queue using foomatic the debugging will be put in [filename]`/tmp/foomatic-rip.log`, and the input file as received by foomatic-rip will be in [filename]`/tmp/foomatic-rip.ps`. + +==== Backend (job transport) + +It may be possible for you to try a different backend. Using [command]`system-config-printer`, double-click on the printer queue icon and click the _Change..._ button next to the _Device URI_ field. You may see a _Connection_ expander arrow near the bottom right hand corner of the window -- click that to see which backends are available. For USB-connected HP printers, typically either of the *hp* and *usb* backends can be used. + +For capturing USB communication: + +* find out the bus number where USB device is connected, f.e.: + +---- +$ lsusb +Bus 002 Device 010: ID 03f0:012a HP, Inc HP LaserJet M1536dnf MFP + + = +---- + +* start USB packet capture: + +---- +$ sudo tcpdump -i usbmonN -s0 -w usb.pcap +---- + +where N is the bus number. + +For network printers you may have different protocols you can try. + +* *socket* is for HP JetDirect (usually port 9100) +* *lpd* is for older style UNIX print shares +* *smb* is for CIFS shares from Windows systems +* *ipp* is for Internet Printing Protocol-enabled devices and also for other CUPS servers +-- You can capture the IPP traffic with [command]`tcpdump` like this (the interface name may differ from *p4p1*): + +---- + tcpdump -n -i p4p1 -U -s0 -w ipp.pcap port ipp +---- + +* *bjnp* is for Canon's proprietary bjnp network protocol (usually port 8611) + +==== Configuration tool + +If your problem relates to configuring print queues, try using one of the other methods of doing so. There are four available: + +* The GNOME 3 System Settings application (*control-center*), _System Settings_ > _Printers_ from the GNOME Shell +* [command]`system-config-printer`, _System_ > _Administration_ > _Printing_ from the GNOME menu +* the CUPS web interface, http://localhost:631/ +* the command line tools [command]`lpadmin`, [command]`lpoptions`, [command]`cupsctl`, [command]`cupsaccept`, [command]`cupsenable` etc. + + + +== User stories + +There are several common user stories when it comes to debugging printing issues. I'll mention some of them with steps how to get necessary information. + +=== I have HP printer and have a problem with HPLIP script + +Please follow the steps in the following sections: + +* xref:how-to-debug-printing-problems.adoc#_enable_cups_debug_logging[enable CUPS debug logging] +* xref:how-to-debug-printing-problems.adoc#_how_to_start_to_capture_incident_bound_journal_logging[start to capture journal logs] +* xref:how-to-debug-printing-problems.adoc#_hplip_scripts_debug_logging[run the script with enabled debugging] +* xref:how-to-debug-printing-problems.adoc#_how_to_get_incident_bound_journal_logging[get the journal logs] +* attach the files to the bugzilla ticket and xref:how-to-debug-printing-problems.adoc#_turning_off_debug_logging[turn off debug logging] +* provide printer model name and printer PPD file from `/etc/cups/ppd/` + +=== I have HP printer, installed it with HPLIP and have a problem with it + +HPLIP installed print queue has a device uri starting with hp://. + +Please follow the steps in the following sections: + +* xref:how-to-debug-printing-problems.adoc#_enable_cups_debug_logging[enable CUPS debug logging] +* xref:how-to-debug-printing-problems.adoc#_how_to_start_to_capture_incident_bound_journal_logging[start to capture journal logs] +* trigger your issue +* xref:how-to-debug-printing-problems.adoc#_how_to_get_incident_bound_journal_logging[get the journal logs] +* attach files with output of [command]`lsusb -v` and from `/var/log/ipp-usb` if the device is connected by USB +* attach the files to the bugzilla ticket and xref:how-to-debug-printing-problems.adoc#_turning_off_debug_logging[turn off debug logging] +* provide printer model name and printer PPD file from `/etc/cups/ppd/` + +=== My printer doesn't print correctly or at all, but I can see the printer in print dialog + +Please follow the steps in the following sections: + +* xref:how-to-debug-printing-problems.adoc#_enable_cups_debug_logging[enable CUPS debug logging] +* xref:how-to-debug-printing-problems.adoc#_how_to_start_to_capture_incident_bound_cupsd_logging[start to capture logs] +* trigger your issue - print the specific document to the specific print queue you have problem with +* xref:how-to-debug-printing-problems.adoc#_how_to_get_incident_bound_cupsd_logging[get the logs] +* attach the created files to the ticket and xref:how-to-debug-printing-problems.adoc#_turning_off_debug_logging[turn off debug logging] +* attach your printer PPD file from `/etc/cups/ppd/` if available +* attach the file you wanted to print +* tell what application you printed from +* mention your xref:how-to-debug-printing-problems.adoc#_which_driver_am_i_using[printer model] +* attach files with output of [command]`lsusb -v` and from `/var/log/ipp-usb` if the device is connected by USB + +=== CUPS generic issue + +For generic issues - printer wasn't found, segfault - please follow the steps in the following sections (`avahi-daemon` must run): + +* xref:how-to-debug-printing-problems.adoc#_enable_cups_debug_logging[enable CUPS debug logging] +* xref:how-to-debug-printing-problems.adoc#_how_to_start_to_capture_incident_bound_cupsd_logging[start to capture logs] +* trigger the issue - e.g. try to find printers via [command]`sudo lpinfo -l -v`, do some action in web ui - depends on your problem +* xref:how-to-debug-printing-problems.adoc#_how_to_get_incident_bound_cupsd_logging[get the logs] +* attach created files to the ticket and xref:how-to-debug-printing-problems.adoc#_turning_off_debug_logging[turn off debug logging] +* put the output of xref:how-to-debug-printing-problems.adoc#_what_make_and_model_is_my_printer[lpinfo] into a file and attach it +* put the output of xref:how-to-debug-printing-problems.adoc#_which_print_queues_are_available_for_me[both lpstat commands] into a file and attach it +* attach files with output of [command]`lsusb -v` and from `/var/log/ipp-usb` if the device is connected by USB + +=== My printer doesn't print correctly - I use 'everywhere' model + +Please follow the steps in the following sections: + +* xref:how-to-debug-printing-problems.adoc#_cups_everywhere_model[get data from get-printer-attributes request] +* xref:how-to-debug-printing-problems.adoc#_my_printer_doesnt_print_correctly_or_at_all_but_i_can_see_the_printer_in_print_dialog[follow the steps with CUPS job log user story] + +=== I have a generic problem with cups-browsed + +Please follow the steps in the following sections: + +* xref:how-to-debug-printing-problems.adoc#_enable_cups_debug_logging[enable CUPS debug logging] +* xref:how-to-debug-printing-problems.adoc#_cups_browsed_logging[enable cups-browsed logging], but don't restart cups-browsed yet. +* xref:how-to-debug-printing-problems.adoc#_how_to_start_to_capture_incident_bound_cupsd_logging[start to capture cupsd logs] +* start cups-browsed via `systemctl` and start to capture its logs: + +---- +$ journalctl -u cups-browsed -f > cups_browsed_log +---- + +* trigger the issue or wait until cups-browsed triggers the issue itself +* cancel cups-browsed and xref:how-to-debug-printing-problems.adoc#_how_to_get_incident_bound_cupsd_logging[cupsd log] captures +* attach created files [filename]`cups_whole_log` and [filename]`cups_browsed_log` to the ticket and xref:how-to-debug-printing-problems.adoc#_turning_off_debug_logging[turn off debug logging] + +=== Printer found by cups-browsed doesn't print or print badly + +The most difficult user story - we need to know how the print queue was created and how it behaves during printing. The print queue found by cups-browsed has a device uri starting with `implicitclass://`. + +Please follow the steps: + +* xref:how-to-debug-printing-problems.adoc#_cups_filters_driverless_driver[get printer info from get-printer-attributes and PPD file] +* xref:how-to-debug-printing-problems.adoc#_enable_cups_debug_logging[enable CUPS debug logging] +* xref:how-to-debug-printing-problems.adoc#_cups_browsed_logging[enable cups-browsed logging], but don't restart cups-browsed yet. +* xref:how-to-debug-printing-problems.adoc#_how_to_start_to_capture_incident_bound_cupsd_logging[start to capture cupsd logs] +* start cups-browsed via `systemctl` and start to capture its logs: + +---- +$ journalctl -u cups-browsed -f > cups_browsed_queue_creation +---- + +* give cups-browsed some time to process found devices (depends on how many devices you have in the local network or how many print queues are stored in the location you set with [option]`BrowsePoll` directive) +* cancel cups-browsed and xref:how-to-debug-printing-problems.adoc#_how_to_get_incident_bound_cupsd_logging[cupsd log] captures - save the files as `cups_queue_creation` and `cups_browsed_queue_creation` + +Now we need to capture the logs during printing: + +* xref:how-to-debug-printing-problems.adoc#_prepare_cups_for_job_logging[prepare CUPS for job logging] +* xref:cups-useful-tricks.adoc#_restarting_cups_service[restart CUPS service] +* start to capture cups_browsed logs again: + +---- +$ journalctl -u cups-browsed -f > cups_browsed_printing +---- + +* trigger your issue - print the specific document to the specific print queue you have problem with +* xref:how-to-debug-printing-problems.adoc#_get_a_job_log_for_a_specific_job_id[get the job log for the job you have just triggered] and cancel the capture of cups-browsed logging +* attach all gathered log files diff --git a/modules/ROOT/pages/cups-debug-scanning-issues.adoc b/modules/ROOT/pages/cups-debug-scanning-issues.adoc new file mode 100644 index 0000000..1c2afb6 --- /dev/null +++ b/modules/ROOT/pages/cups-debug-scanning-issues.adoc @@ -0,0 +1,123 @@ += CUPS – How to Debug Scanning Issues +Brandon Nielsen ; +:revnumber: unspecified +:revdate: 2021-06-16 +:category: Scanner +:tags: How-to, Scanner, Cups, Troubleshooting +:page-aliases: how-to-debug-scanning-problems.adoc + + + +SANE library, communication libraries and backends can turn on and off debug logging via `SANE_DEBUG_*` environment variables. + +The common environment variables: + +* `SANE_DEBUG_DLL` - enables debugging SANE library +* `SANE_DEBUG_SANEI_USB` - enables debugging communication library for USB - add the environment variable if your device is connected via USB cable +* `SANE_DEBUG_SANEI_TCP` - enables debugging communication library for wireless/ethernet - add the environment variable if your device is connected by Wifi or Ethernet + +Environment variables for enabling debugging a specific backends have a structure - `SANE_DEBUG_`, so the environment variable for f.e. *HPAIO* backend is `SANE_DEBUG_HPAIO*`. + +You can find which SANE backend supports your device http://www.sane-project.org/sane-mfgs.html[here]. If your device is HP and it isn't supported by *airscan* backend or any other SANE backend, it can be supported by *hpaio* backend from *hplip* package, see the list of supported devices https://developers.hp.com/hp-linux-imaging-and-printing/supported_devices/index[here]. + +== Debugging scanner discovery + +If you don't see your scanner in scanning application, then debugging of discovery process is in order. I prefer using [command]`scanimage` in the examples, but the similar steps can be applied for every scanning application like [command]`xsane`, [command]`scanadf`, [command]`simple-scan` etc. + +You will need to use environment variables when you start a scanning application ([command]`scanimage` in this case). The environment variables used with [command]`scanimage` command depends on how your scanner is connected and which backend suppose to support it. So for getting debug logs for HP LaserJet device, *connected via Ethernet/Wifi and supported by HPAIO backend*, use command: + +---- +$ SANE_DEBUG_DLL=255 SANE_DEBUG_HPAIO=255 SANE_DEBUG_SANEI_TCP=255 scanimage -L &> discovery_output +---- + +or, f.e. if you have CanoScan 8600F, connected by USB and supported by genesys backend, use command: + +---- +$ SANE_DEBUG_DLL=255 SANE_DEBUG_GENESYS=255 SANE_DEBUG_SANEI_USB=255 scanimage -L &> discovery_output +---- + +Please attach the created [filename]`discovery_output` file as an attachment to the bugzilla ticket. + +== Debugging scanning process + +If the scanner is found, but an issue happens during scanning itself, we need to debug scanning process itself - which means debugging communication between backend and scanner when you start scanning a document. + +The debugging scanning itself looks similar as discovery - setup the environment variables before running the command/scanning application and catch logs into a file. The possible command can be (f.e. if you have *network scanner supported by HPAIO backend*): + +---- +$ SANE_DEBUG_DLL=255 SANE_DEBUG_HPAIO=255 SANE_DEBUG_SANEI_TCP=255 xsane &> debug_log +---- + +or (once you find out device uri from [command]`scanimage -L` - see the xref:_getting_a_scanner_device_uri[next section]): + +---- +$ SANE_DEBUG_DLL=255 SANE_DEBUG_HPAIO=255 SANE_DEBUG_SANEI_TCP=255 scanimage -d > out.pnm 2> debug_log +---- + +, where you substitute `` for the actual device uri, f.e. 'hpaio:/net/laserjet_m1536dnf_mfp?ip=192.168.1.112'. + +Please attach the created file - [filename]`debug_log` - as an attachment to the bugzilla ticket. + +== Getting a scanner device uri + +This point is basically a manual how to get a scanner uri for debugging scanning itself via [command]`scanimage`. You don't need to provide a scanner uri in GUI applications like [command]`xsane` or [command]`simple-scan`, because the application will do it for you or you can choose the scanner by a mouse click. + +The [command]`scanimage -L` command returns an output where device uri of the device is shown, f.e.: + +---- +$ scanimage -L +device `v4l:/dev/video0' is a Noname Integrated Camera: Integrated C virtual device +device `hpaio:/net/laserjet_m1536dnf_mfp?ip=192.168.1.112&queue=false' is a Hewlett-Packard laserjet_m1536dnf_mfp all-in-one +---- + +F.e.the string 'hpaio:/net/laserjet_m1536dnf_mfp?ip=192.168.1.112&queue=false' is a device uri for for Hewlett-Packard laserjet_m1536dnf_mfp all-in-one scanner. + +== Debugging HP scanner if it is supported by HPLIP + +The hplip package doesn't have unified logging, so some logs come out of HPAIO backend to standard output and HP internal utilities logs come to journal. So we need to capture both to get the understanding of situation. + +It can be done this way: + +* start capturing journal logs at background: + +---- +$ journalctl -f > journal_logs & +---- + +* trigger an action (xref:_debugging_scanner_discovery[discovery] or xref:_debugging_scanning_process[scanning]) +* kill the journalctl process, f.e. this way (if there is only one journactl process) + +---- +$ kill `pidof journalctl` +---- + +then attach the created file - [filename]`journal_logs` - as an attachment to the bugzilla ticket. Please do only one action per capture - that means if you are asked to attach log files for HP scanner discovery and scanning supported by hplip, you will attach as an attachment four files - [filename]`discovery_output`, [filename]`journal_logs` for discovery output, [filename]`debug_logs` and [filename]`journal_logs` for debug_logs. + +== Debugging sane-airscan + +If your device supports eSCL or WSD (you can find it out from device specification - look for the mentioned protocols or AirScan), then its scanning functionality is supported by *sane-airscan*. Regarding debugging, on the top of usual logging sane-airscan gathers a communication dump and output image, which is helpful during investigation. + +sane-airscan debugging can be enabled in [filename]`/etc/sane.d/airscan.conf` by setting: + +---- +[debug] +trace = /path/to/dir/where/debugfiles/will/be/saved +enable = true +---- + +Then do trigger your issue (xref:_debugging_scanner_discovery[discovery] or xref:_debugging_scanning_process[scanning]), go to the dir you defined in [filename]`/etc/sane.d/airscan.conf`, take all files from there and attach them to the bug ticket. + +== How to divide logs + +In case your debug log is too big for bugzilla to attach (because your issue doesn't happen with the lowest settings or logs are big even with the lowest settings), do divide the logs to three files like this: + +---- +$ grep dll debug_log > debug_log_dll +$ grep debug_log > debug_log_connection +$ grep debug_log > debug_log_backend +---- + + is the name of backend which supports your scanner (pixma, genesys, plustek, hpaio, airscan etc.), is the type of connection you use for the device (tcp, usb). + +The division makes the investigation more difficult (the person needs to have three opened files at the same time), so do divide the logs only if log file is too big. + diff --git a/modules/ROOT/pages/cups-filing-a-bug-report.adoc b/modules/ROOT/pages/cups-filing-a-bug-report.adoc index 065af88..343e99a 100644 --- a/modules/ROOT/pages/cups-filing-a-bug-report.adoc +++ b/modules/ROOT/pages/cups-filing-a-bug-report.adoc @@ -1,10 +1,10 @@ -= Filing a CUPS Bug Report += CUPS – Filing a Bug Report Brandon Nielsen :revnumber: all :revdate: 2022-05-15 -:category: Bugs -:tags: How-to Bug-Report cups -//:imagesdir: ./images +:category: Printing +:tags: How-to Bug-Report Cups + // include::partial$attributes.adoc[] diff --git a/modules/ROOT/pages/cups-known-issues.adoc b/modules/ROOT/pages/cups-known-issues.adoc index eb1504c..4cc3d4e 100644 --- a/modules/ROOT/pages/cups-known-issues.adoc +++ b/modules/ROOT/pages/cups-known-issues.adoc @@ -1,10 +1,237 @@ -ifdef::context[:parent-context: {context}] -:context: cups-known-issues -[id='cups-known-issues'] -= Known issues -:toc: += CUPS – Known Issues +Brandon Nielsen +:revnumber: F31 onwards +:revdate: 2021-06-16 +:category: Printing +:tags: How-to, Cups, Workstation, Gnome -include::{partialsdir}/con_cups-known-issues.adoc[leveloffset=+1] -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] +Here are several known issues, which arise with certain circumstances, and there isn't general solution or upstream didn't want to add the solution to its project: + +== cups-browsed + +=== Cannot print due 'No destination hostname provided by cups-browsed, is it running?' + + +cups-browsed sometimes loses connection to print server (usually with old ones, like cups-1.4.2) when laptop changes network connection (change of WiFi network or after hibernate/suspend). You can make printing working again with cancelling your jobs and restarting cups-browsed by + +---- +$ cancel -a +$ sudo systemctl restart cups-browsed +---- + +=== cups-browsed consumes large amount of CPU + +Creating local printer queues takes long time for some printers with larger PPD file, so timeout of http connection will time out and it creates infinite loop of creating local printer queues. To solve this issue, please add + +---- +HttpLocalTimeout N +HttpRemoteTimeout N +---- + +into [filename]`/etc/cups/cups-browsed.conf`, where `N` is number of seconds after which connection is timed out. Then restart cups-browsed service. This option is currently in Fedora 27 and above. + +=== [SINCE FEDORA 27] cups-browsed creates different printer queue names than before + +This issue is connected to remote cups queues, which are advertised by older CUPS version (usually below cups-1.5, e.g. RHEL 6). Cups-browsed creates local print queues named by printer's DNS-SD ID by default and naming by remote cups queue is enabled again by adding: + +---- +LocalQueueNamingRemoteCUPS RemoteName +---- + +into [filename]`/etc/cups/cups-browsed.conf` and restart cups-browsed service. + +== cups-filters + +=== Printing takes a long time or doesn't print at all + +When your printer needs a lot of time to do printing (from your POV) or doesn't print at all (some Xerox printers have such problems with gs renderer, so they are working again only with pdftops renderer), you can try to change the default postscript renderer. The default renderer in Fedora for most printers is gs filter from Ghostscript, but we have pdftops filter from Poppler for Brother, Minolta and Konica Minolta printers - this setup is called hybrid. + +Other available renderer setups are gs (from Ghostscript), pdftops and pdftocairo (from Poppler), mupdf (from mupdf) and acroread (from adobe reader, not in Fedora official repositories), then you can set different default renderer for your print queue like this: + +---- +# lpadmin -p -o pdftops-renderer-default=gs/pdftops/pdftocairo/mudpf/acroread/hybrid +---- + +*BEWARE:* Most 'slow' printing issues are caused by PDF creating applications, which generates bad PDF file - and that bad generated PDF file is mostly the core of problem. To sum it up, slow printing issue can rise again with different PDF file, then it is on user's decision: if he wants to print fast and probably sometimes change the default renderer, or slow printing is not such critical issue. + +== CUPS + +=== [Fixed in F33 and later] Firefox, Evince (PDF viewer), GVim, Gedit, Gnome Control Center show a 'dummy'/duplicate print queue, which doesn't work + +This bug is connected to every application which uses GTK print dialog. GTK dialog decided to take information about available from two sources - mDNS messages from Avahi and CUPS - this dummy/duplicate print queue is a print queue GTK created in its dialog based on Avahi messages, but it doesn't exist in CUPS, because no one created it, and later GTK behaves like it exists in CUPS. So every time an user wants to print, GTK sends a request to CUPS for this queue, but it gets dropped by CUPS because the queue doesn't exist. + +The feature which GTK is trying to do here is called CUPS temporary queues - GTK developers is currently working on a immediate fix in this https://bugzilla.redhat.com/show_bug.cgi?id=1784449[bugzilla]. The future plan is to use https://github.com/OpenPrinting/cpdb-backend-cups[cpdb-backend-cups] backend in GTK, but right now we are focusing on the intermediate fix. + +=== CUPS doesn't take nicely some kinds of FQDN + +CUPS sometimes has problems with some kinds of FQDN - that means when you use FQDN in [option]`BrowsePoll` directive in [filename]`/etc/cups/cups-browsed.conf`, CUPS doesn't recognize it as valid hostname - it is solved by adding: + +---- +ServerAlias your.own.fully.qualified.hostname.com +---- + +into [filename]`/etc/cups/client.conf` and restarting cups service. + +=== There are less options available if the device is used as driverless than with a classic driver + +The similar situation can happen with *sane-airscan* supported scanners. Some devices declare less options via protocols - f.e. IPP 2.0+, WSD, eSCL - which support driverless solutions than via classic drivers. Usually it is an issue with device's firmware, which can be verify by checking the output of the following command: + +---- +$ ipptool -tv get-printer-attributes.test +---- + +The commands does the same IPP request which is done when a temporary queue appears in the print dialog or when you install the queue permanently. The printer options are set from the IPP response for this request, so if the option is missing in the response, CUPS cannot generate such a printer option. The solution is to try to update the device firmware, report the issue to the device manufacturer and at https://bugzilla.redhat.com[bugzilla] with logs. + +=== [F33+] Printing via IPPS doesn't work + +Fedora 33 came up with a raised bar regarding crypto-policies, so SSL and older TLS protocols are disabled on system level. The change breaks printing via IPPS to devices which don't support newer protocols. You can set back legacy crypto support in crypto-policies via: + +---- +$ sudo update-crypto-policies --set DEFAULT:FEDORA32 +---- + +The policy change transitionally has an impact on devices found by cups-browsed, because the daemon prefers IPPS uris if they are reported as available by printer/server. + +== HPLIP + +First I would like to mention that we are not responsible for support HPLIP, which is downloaded and installed from HP website. Please install hplip rpms from official Fedora repositories at most cases. + +=== Hp-plugin: file does not match its checksum. File may have been corrupted or altered + +This common error is mostly caused by external causes (server outage, network outage), when wget tries to download plugin, but it returns only error message. It is connected with message: + +---- +Plugin download failed with error code = N +---- + +where `N` is return value of [command]`wget` ([command]`man wget`), which is used for downloading proprietary plugin. Solutions for this issue may vary - you can wait until servers go up again or try to install plugin, which you download manually from http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/ (select "Select and install an existing local copy of the plug-in file" during [command]`hp-setup` or [command]`hp-plugin`). + +=== Unable to load cupsext + +This error can occur when hplip is installed from HP website, or its dependencies are mixed python2 and python3 packages or installed by pip. This is solved by removing all hplip packages (hplip, hplip-gui, hplip-libs, hplip-common, libsane-hpiao) and installing them again all from repositories. + +=== Missing hplip-gui + +GUI tools and GUI parts of HP commands are moved to hplip-gui subpackage, because the main package can work without GUI, so the main package is smaller. The outcome of this decision is HP commands need to be run with `-i` option for interactive mode, or hplip-gui subpackage needs to be installed. + +Tools, which need to be run with `-i` option for CLI or need to have hplip-gui installed for GUI: + +---- +hp-align +hp-clean +hp-colorcal +hp-diagnose_queues +hp-fab +hp-firmware +hp-info +hp-plugin +hp-sendfax +hp-setup +hp-testpage +hp-unload +---- + +Tools, which are in hplip-gui: + +---- +hp-check +hp-print +hp-systray +hp-toolbox +hp-devicesettings +hp-faxsetup +hp-linefeedcal +hp-makecopies +hp-printsettings +hp-wificonfig +---- + +=== HP printer isn't discovered, doesn't print or doesn't print well + +Some HP printers don't work well with URIs provided by CUPS (dnssd, usb, ipp) or they need proprietary plugin from HP, which cannot be in Fedora because of licensing issues. For such printers please try to run: + +---- +hp-setup -i -g +---- + +for interactive mode, or: + +---- +hp-setup -g +---- + +for graphic mode. This command installs HP printers and HP scanners. If you have issue about HP printer/HP scanner, which isn't discovered, doesn't print or doesn't print well, please try to install it by [command]`hp-setup`, if it helps. If it doesn't help, please file a bugzilla, attach output of hp-setup and mention that you tried [command]`hp-setup`. + +=== Device which needs plugin does not work after HPLIP update + +Devices which need plugin can stop to work after update to newer HPLIP version - it is due the check for plugin version in the code. The check is necessary to prevent inconsitencies when new features in open sourced HPLIP need new proprietary libraries from plugin. To make your printer work again, just download and install plugin again with: + +---- +$ hp-plugin -i +---- + +=== Devices which require a binary plugin stopped to work on Fedora Silverblue/CoreOS + +Devices which require a HP close source binary plugin need to have plugin installed every time you start/restart your PC by default. HP closed source script installs the plugins into a readonly directories, so the plugins are removed once you start/restart Fedora. The workaround is to try if your device supports driverless printing and scanning, try hplip-plugin package from RPMFusion or keep installing the plugin everytime you want to print. + +== golang-github-openprinting-ipp-usb + +=== USB printer/scanner doesn't work due a conflict on USB port + +*ipp-usb* daemon keeps the USB port of IPP-over-USB device opened for any possible IPP communication in the future, which blocks the port for other drivers (f.e. HPLIP, gutenprint, sane-backends...). + +For printers the solution is to _uninstall the queue with the driver_ by: + +---- +$ lpadmin -x +---- + +and start using the one from *ipp-usb* (as a xref:cups-terminology.adoc#_temporary_print_queues[CUPS temporary queue] or install a permanent one - the default device uri is `ipp://localhost:60000/ipp/print`). + +In case of scanners *sane-airscan* automatically picks up the virtual device from *ipp-usb* if the device is capable of using WSD or eSCL protocols. However, if the scanner had been supported by classic scanner driver such as hplip or sane-backends and is now claimed by *ipp-usb* because it supports *IPP-over-USB* driverless standard, the old scanner is still shown, but it won't work for scanning due USB conflict. It happens because classic backends just list any device which they can find on USB interfaces and matches the description the backend supports, but backends don't check whether they actually can communicate with the device until they try to open the USB port for scanning process itself. This becomes a problem for scanning applications, which automatically choose the previous scanner as a default choice for scanning (such as _Simple Scan_) - users have to pick a driverless scanner from the list of available scanners before they scan. + +The scanner device discovered by classic SANE backends can be disabled from showing it among available scanners by commenting out its entry in backend's configuration file located in [filename]`/etc/sane.d` or the whole backend name in [filename]`/etc/sane.d/dll.conf`/[filename]`/etc/sane.d/dll.d`, f.e. Canon MF440 Series is reported by `pixma` and `airscan` backends, but only `airscan` works because it is a backend based on network protocol and USB interface is claimed by `ipp-usb`, so we will disable the `pixma` backend by commenting its line in [filename]`/etc/sane.d/dll.conf`: + +---- +$ cat /etc/sane.d/dll.conf +... +pint +#pixma +plustek +... +---- + +If *ipp-usb* created device doesn't match your use case (the options you use are missing, the device doesn't work even if it is IPP-over-USB supported), please report the issue together with logs from [filename]`/var/log/ipp-usb/` directory at https://bugzilla.redhat.com[bugzilla]. *ipp-usb* itself supports quirks, which allows you to set the daemon to ignore your device and you can switch back to a classic driver. The steps are following: + +- get the device model name f.e. Canon MF440 Series: + +---- +$ sudo ipp-usb check +Configuration files: OK +IPP over USB devices: + Num Device Vndr:Prod Model + 1. Bus 001 Device 005 04a9:2823 "Canon MF440 Series" +---- + +- create a quirk file in [filename]`/etc/ipp-usb/quirks` directory in the format below: + +---- +$ cat /etc/ipp-usb/quirks/canon.conf +[Canon MF440 Series] + blacklist = true +---- + +- restart the `ipp-usb` service: + +---- +$ sudo systemctl restart ipp-usb +---- + + +== sane-airscan + +=== There are less options available if the device is discovered by sane-airscan than with a classic driver + +The similar situation can happen with `everywhere` or `driverless` printer models. Some devices declare less options via protocols - f.e. IPP 2.0+, WSD, eSCL - which support driverless solutions than via classic drivers. Usually it is an issue with device's firmware, which can be verify in sane-airscan debug logs and network traffic. The solution is to try to update the device firmware, report the issue to the device manufacturer and at https://bugzilla.redhat.com[bugzilla] with logs. + diff --git a/modules/ROOT/pages/cups-terminology.adoc b/modules/ROOT/pages/cups-terminology.adoc index 6562646..09c7783 100644 --- a/modules/ROOT/pages/cups-terminology.adoc +++ b/modules/ROOT/pages/cups-terminology.adoc @@ -1,10 +1,99 @@ -ifdef::context[:parent-context: {context}] -:context: cups-terminology -[id='cups-terminology'] -= Printing and scanning terminology -:toc: += CUPS – Printing and Scanning Terminology +Brandon Nielsen +:revnumber: F31 onwards +:revdate: 2021-06-16 +:category: Printing +:tags: How-to, Cups, Workstation, Gnome + + +== Printing + +=== Print queue + +Abstraction unit in CUPS for a printer - it has a device uri, which represents connection to the device, and can exist with classic driver (PPD file from different package) or without (driverless printing). The entries you see in print dialogs and settings are those _print queues_. They can be _permanent or temporary_. + +=== Permanent print queues + +The queues with classic driver or driverless print queue which need to be shared further down the network. + +=== Temporary print queues + +The queue which don't need to be installed at all - they show up during print dialog and they disappear once the printing is done successfully. They rely on _driverless printing_. + +=== Remote CUPS queue + +The queue on the different machine, where other cupsd process is running, than on the local machine. They are usually found in enterprise solutions, where printers aren't in the same network as users or if admin wants a centralized monitoring above all printers. In such solutions, users set up _cups-browsed_ to install remote CUPS queue as local queues via _BrowsePoll_ directive, or install a specific queue via GNOME. There can be a solution how to redirect mDNS messages which CUPS server advertises to the networks with users, but I haven't been to setup this correctly yet. + +=== Classic drivers + +Those are the binaries and PPD files, which need to be installed for the device to work. This is older way of supporting devices, which will go away in the future. + +=== Driverless printing (wireless/ethernet) + +Most of modern devices (2010+) complies to AirPrint, Mopria or IPP Everywhere standard, which means they don't need a classic driver for being able to print. Those devices have IPP (Internet Printing Protocol) 2.0+ implemented within, are capable to 'advertise' themselves via mDNS and they support document formats like PDF, PCLm, JPEG, Apple Raster or PWG Raster. + +There are several prerequitises which need to fulfill in OS to have an access to the driverless feature: + +* avahi-daemon must run +* there needs to be a '.local' address resolver active - systemd-resolved or nss-mdns +* the device itself must have IPP port (631) and Bonjour/MDNS enabled +* IPP and MDNS need to be enabled in firewall + +How does the driverless printing work under the roof (put it simply): + +* CUPS sees the printer in mDNS messages via Avahi +* CUPS will find out the printer capabilities via IPP +* if there is a print job, CUPS will set up the filter chain to convert the incoming file into document format which printer understands (Apple Raster, PDF, PWG Raster, PCLm, JPEG) + +In case it is needed, PPD file is generated by PPD generator in CUPS or by _driverless_ binary. + +One of the features which use driverless printing is _CUPS temporary queues_. + +See xref:cups-useful-tricks.adoc#_how_to_find_out_whether_my_printer_is_capable_of_driverless_printing[manual] how to check if your printer is capable of driverless printing. + +=== Printing using a driver + +This printing is similar to driverless printing in matter of setting up a filter chain, but: + +* it can use limited mDNS and IPP functionality or it doesn't use them at all +* all information about device capabilities is taken from PPD (Postscript Printer Description) file +* can use a specialized filters and specialized communication with the device (depends on driver) + +The downsides of this approach is to rely on 3rd party drivers, you need to always install a permanent queue for it and it will go away in the future. + +=== Raw queue + +No filters are started by CUPS if you print to such a queue, the data are sent as they are to the target, no options are applied by CUPS - all regardless of incoming document format. It is required the application you use for printing sends a printer-ready data (in the correct format, with all chosen options applied) or the destination is set to the desired settings (f.e. printer/print server is set to do two-sided-long-edge duplex with grayscale settings, so every document printed will have this settings and user won't be able to change it in an application). + +This approach is usually set for printing to older label printers via a specific application, or, in the past, for printing to remote CUPS queue. Because CUPS has no way how to provide common user experience (finding out printer properties, converting various document formats into a document format the printer accepts, setting printing options) for such queues, their usage is deprecated and it will be removed in the future (in CUPS 3.X). + +=== Raw printing + +Raw printing happens if CUPS receives a file in document format which printer accepts directly and CUPS recognizes the format based on rules from its MIME database. CUPS daemon doesn't start any filters for such a job (it might encapsulate options into IPP packet, if the connection with the printer is over IPP) with exception for PDFs, where the _pdftopdf_ filter is started to apply generic settings like scaling, rotation etc. Raw printing itself happens on print queues with classic driver and driverless print queues. This functionality stays with CUPS 3.X. + +The difference between raw printing and raw queue is the raw printing is a situation which happens if CUPS daemon gets a file in format which printer accepts, so the daemon does not spawn additional filters for such job (with PDF being an exception), and spawns filters for document formats, which are not acceptable by the printer directly, whereas the raw queue is a queue, which CUPS daemon does not spawn any filters in any circumstances, and behaves like a Unix pipeline. + +=== Printer applications + +The binaries which provide support for older devices which aren't capable of complying to driverless standards. The core idea is they will be capable of accepting the old driver and then advertise itself as a device capable of driverless printing. Then the new CUPS will be able to see them and user will be able to print via them as if they were temporary queues. The currently available printer applications in Fedora are _ippeveprinter_ (a part of CUPS - see cups-printerapp package) and _lprint_ (provides support for devices which requires raw printing - mostly label printers). Other printer applications like https://github.com/OpenPrinting/ps-printer-app[ps-printer-app], https://github.com/OpenPrinting/ghostscript-printer-app[ghostscript-printer-app], https://github.com/OpenPrinting/hplip-printer-app[hplip-printer-app] and https://github.com/OpenPrinting/gutenprint-printer-app[gutenprint-printer-app] are currently available as SNAPs until cups-filters 2.0 is released and packaged. Printer applications are, except for _ippeveprinter_, written using _PAPPL_ library, so such printer application provides CLI interface and Web Interface for users to interact with. + +=== Driverless printing (USB) + +Driverless printing has its variant for devices which are connected via USB - it is covered by 'IPP over USB' standard. For make it work, you need 'ipp-usb' package, which will register the device with Avahi on localhost - then USB device will look as a wireless/ethernet device. The discovery/printing looks the same as with a wireless/ethernet device with driverless support. + +See xref:cups-useful-tricks.adoc#_how_to_find_out_whether_my_printer_is_capable_of_driverless_printing[manual] how to check for IPP-over-USB. + +== Scanning + +=== Classic scanning (via hplip and sane-backends) + +The classic scanning works via backends, which are binaries for communication with device. There are several backends, usually created by reverse engineering communication between scanner and MS Windows driver. None of classic backends implements a protocol, which is compatible with most devices available. + +=== Driverless scanning + +The driverless scanning uses sane-escl (not built in Fedora) and sane-airscan backends for communicating with newer devices. Those newer devices usually support eSCL (based on AirScan protocol by Apple) or WSD (Web Services for Devices by Microsoft), which _sane-airscan_ is able to use. + +Regarding USB scanning, it has the same requirement as printing. The device must support IPP over USB driverless standard and _ipp-usb_ package must be installed to get driverless scanning via USB - the package is required because it creates a driverless interface over USB interface which _sane-airscan_ uses for driverless communication with device. + -include::{partialsdir}/con_cups-terminology-for-printing-and-scanning.adoc[leveloffset=+1] -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] diff --git a/modules/ROOT/pages/cups-useful-tricks.adoc b/modules/ROOT/pages/cups-useful-tricks.adoc index f69c303..b40e8a1 100644 --- a/modules/ROOT/pages/cups-useful-tricks.adoc +++ b/modules/ROOT/pages/cups-useful-tricks.adoc @@ -1,10 +1,405 @@ -ifdef::context[:parent-context: {context}] -:context: cups-useful-tricks -[id='cups-useful-tricks'] -= Useful tricks -:toc: += CUPS – Useful Tricks +Brandon Nielsen +:revnumber: F31 onwards +:revdate: 2021-06-16 +:category: Printing +:tags: How-to, Cups, Workstation, Gnome -include::{partialsdir}/con_cups-useful-tricks.adoc[leveloffset=+1] -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] +== How to install a print queue + +The fact whether you have to install a printer or not depends on several things: + +* what is the device you want to install - a printer from remote CUPS server (called remote print queue) or a printer, +* where is the device you want to install - connected by USB to your PC, in your local network, in a different network or installed on a remote server, +* how old is the device you want to install: +** standalone printers - most SOHO (Small Office, Home Office) and office printers made after 2010 have at least one way of supporting driverless printing, older devices depend on drivers - classic or printer applications, +** remote print queues on a server - any OS with CUPS 2.2.8 and newer or OS where IPP Everywhere support was backported (f.e. RHEL 8) are capable of supporting IPP Everywhere, otherwise a combination of driver and raw queue is needed in client-server communication, +* what is the purpose of the device where you install the printer - endpoint device, which is used by user as a desktop, or a server, which shares the installed printers further, +* what are your personal preferences - using or not using IPP protocol, using or not using mDNS for autoinstallation if possible from network layout. + +So there are several user stories based on those dependencies, which are described further down. + +=== Common user stories + +==== I have a printer made after 2015, I'm at home and want to print from my PC + +* the most common setup on desktop +* the printer is new enough to support driverless standards via USB and network, so driverless support doesn't depend on your connection +* the PC is an endpoint device, I don't want to share the printer +* I don't mind using mDNS and IPP, mDNS is enabled in my firewall, IPP and mDNS (or similar settings) are enabled on the printer, and mDNS resolution works (checked by pinging .local hostname) + +CUPS temporary queues for xref:_how_to_setup_cups_temporary_queues_with_usb_printer[USB] or xref:_how_to_setup_cups_temporary_queues_with_network_printer[network] are ideal for this use case. + +==== I have an older printer, I'm at home and want to print from my PC + +* the printer doesn't have a driverless support - check via xref:_how_to_find_out_whether_my_printer_is_capable_of_driverless_printing?[ipptool] for network printers (if the printer has IPP support and you enable the port) and via xref:_how_to_find_out_if_my_usb_device_supports_ipp_over_usb[lsusb] for USB printers, +* my PC is an endpoint device + +Currently there are two options - install the printer in xref:_how_to_install_a_printer_via_printer_application_in_snap_and_making_it_available_for_cups[printer application] and CUPS will automatically see it, or install it with classic driver xref:_how_to_install_a_permanent_print_queue[permanently]. Installation with classic driver is deprecated and will be removed in CUPS 3.0. + +==== I'm in a company which has a print server where office printers are installed, I want to print to the print server - no mDNS, but with driverless + +* the print server supports IPP Everywhere and is in a different network or doesn't register on mDNS, or I don't want to use mDNS +* remote print queue has the URI ipp://:631/printers/, where is the hostname of print server and is a name of a print queue I want to connect to +* xref:_how_to_find_out_whether_my_printer_is_capable_of_driverless_printing?[ipptool] command passes if the URI is used + +Such printers has to be installed xref:_how_to_install_a_permanent_print_queue[permanently] with IPP Everywhere driver. + +==== I'm in a company which has a printer server where office printers are installed, I want to print to the print server - with working mDNS in local network + +Such remote printers are discovered automatically via mDNS and used as xref:_how_to_setup_cups_temporary_queues_with_network_printer[CUPS temporary queues] on network - they are seen on mDNS and automatically picked up by dialogs. + +==== I want to print, but I don't want to or can't use mDNS, regardless whether my printer supports driverless printing + +Every printer which can't be discovered by mDNS has to be installed xref:_how_to_install_a_permanent_print_queue[permanently] in CUPS or, in CUPS 3.0, by printer profile. + +. Driverless printers: +* all of them supported by *IPP Everywhere* model under Manufacturer entry in CUPS Web UI and as *everywhere* in CLI +* types based on origin: +** Network: +*** URI: ipp://:631/ipp/print , where is hostname or IP address of the printer +** IPP-over-USB printers via ipp-usb: +*** URI: ipp://localhost:60000/ipp/print +** Printers installed via printer application: +*** URI: ipp://localhost:8000/ipp/print/ , where is the printer name chosen in printer application + +. Remote print queues on a print server: +* URI: ipp://:631/printers/ , where is server's IP address or hostname and is a name of the print queue installed on the server +* it depends on CUPS on the server whether a local printer which points to a printer on the server can be installed as IPP Everywhere model - usually CUPS 2.2.8 and newer support driverless and some distributions such as CentOS 8 backported the functionality as well +* otherwise it depends on printer's driver on the old server - the key is to prevent applying the options multiple times (so one of the connections has to be raw and loses some of the functionality) + +. Legacy or specialized printers +* (deprecated, to be removed in CUPS 3.0) can be discovered by CUPS and installed with classic drivers +* can be installed in printer application and then installed in CUPS as a permanent queue (see driverless printers - printers installed via printer application above) + +==== Driverless options don't do the trick for me on my driverless printer, I want to use features from the driver + +The current recommended action is to install the printer via xref:_how_to_install_a_printer_via_printer_application_in_snap_and_making_it_available_for_cups[printer application], which contains the classic driver, because installation the printer permanently in CUPS with classic driver is deprecated and it will be removed in CUPS 3.0. Then mDNS can be used to catch it by CUPS or the printer from printer application has to be installed permanently in CUPS as a IPP Everywhere printer. + +In case of IPP-over-USB printers, a reject rule has to be added as described in xref:cups-known-issues.adoc#_usb_printerscanner_doesnt_work_due_a_conflict_on_usb_port[known issues]. + +==== I install the printer on a server, which will share the printer further + +Printers on the server have to be installed xref:_how_to_install_a_permanent_print_queue[permanently] to be shared. IPP Everywhere model (directly to the printer or via printer application) is the ideal, but a classic driver with standardized PPD options on a server capable of using driverless is fine as well - clients can use IPP Everywhere model when pointing to the server and options are translated properly. Otherwise there is a possibility that some options aren't applied or applied twice. Don't forget about enabling IPP in firewall, setting ACLs to the server via [filename]`/etc/cups/cupsd.conf` and attaching the daemon to port 631 instead of localhost. + +==== I'm in a company with old print server incapable of driverless, I want to print + +The important thing is to prevent applying options multiple times in this scenario. There are several ways how to do it: + +* ask your IT support for the driver (print queue on the server has to be raw) +* use *ServerName* directive in [filename]`/etc/cups/client.conf` or *CUPS_SERVER* environment variable to connect to the server directly - you won't be able to do admin tasks, but capable of printing. + +=== How to find out whether my printer is capable of driverless printing? + +Network printers have the prerequisites - enablement of IPP port on the printer is the minimum, mDNS is required for automatic printer discovery by `libcups`. + +* [command]`ipptool` command which sends IPP Get-Printer-Attributes request to the network printer passes: + +---- +$ ipptool -tv ipp://printer.example.com:631/ipp/print get-printer-attributes.test +"/usr/share/cups/ipptool/get-printer-attributes.test": + Get-Printer-Attributes: + attributes-charset (charset) = utf-8 + attributes-natural-language (naturalLanguage) = en + printer-uri (uri) = ipp://printer.example.com:631/ipp/print + requested-attributes (1setOf keyword) = all,media-col-database + Get printer attributes using get-printer-attributes [PASS] +... +---- + +, where `printer.example.com` is the hostname or IP of your network printer, + +* look for AirPrint among device specification, +* https://www.pwg.org/printers/[Officially certified printers for IPP Everywhere], +* check xref:_how_to_setup_cups_temporary_queues_with_network_printer[manual] for enabling CUPS temporary queues - if your printer is seen in the end in CUPS commands that way, your printer is capable of driverless printing, +* [USB devices only] check for IPP over USB (xref:_how_to_find_out_if_my_usb_device_supports_ipp_over_usb[manual] here). + +=== How to find out if my USB device supports IPP over USB + +Check whether your USB device has a following text in [command]`lsusb -v` output: + +---- +... + bInterfaceClass 7 Printer + bInterfaceSubClass 1 Printer + bInterfaceProtocol 4 + iInterface 0 +... +---- + +If the device has the _bInterfaceClass 7_, _bInterfaceSubClass 1_ and _bInterfaceProtocol 4_ in the sequence, it supports IPP over USB which is critical for USB device driverless printing and scanning. + +=== How to setup CUPS temporary queues + +To setup the temporary queues correctly, there are several prerequisities: + +* printer/remote print queue has a driverless support and has it enabled, +* your PC has avahi-daemon service or avahi-daemon socket running, +* your PC has cups socket or service running, +* mDNS hostnames are resolvable - test by pinging a .local hostname + +==== How to setup CUPS temporary queues with network printer + +* additional requirement: +** enable MDNS in your firewall settings + +After this the temporary queue will appear in the print dialog and you don't need to install a specific print queue unless you have a reason for it. + +You can check if your printer is seen in mDNS messages by (*avahi-tools* must be installed): + +---- +$ avahi-browse -avrt +... += enp0s25 IPv4 HP LaserJet M1536dnf MFP (42307C) _ipp._tcp local + hostname = [NPI42307C.local] + address = [192.168.1.10] + port = [631] + txt = ["UUID=434e4239-4243-4a42-5859-3c4a9242307c" "Scan=T" "Duplex=T" "Color=F" "note=" "adminurl=http://NPI42307C.local." "priority=10" "product=(HP LaserJet M1536dnf MFP)" "ty=HP LaserJet M1536dnf MFP" "URF=CP99,W8,OB10,PQ3-4-5,DM1,IS1-4,MT1-2-3-5,MT1-2-3-5,RS600" "rp=ipp/printer" "pdl=application/postscript,application/vnd.hp-PCL,application/vnd.hp-PCLXL,application/pdf,image/urf" "qtotal=1" "txtvers=1"] +... +---- + +and if CUPS or its backends see the printer by commands: + +(lists all existing print queues - permanent or temporary) + +---- +$ lpstat -e +HP_LaserJet_M1536dnf_MFP_42307C_ +---- + +or + +(lists all devices, which CUPS sees in the local network or USB) + +---- +$ lpinfo -l -v +... +Device: uri = ipp://HP%20LaserJet%20M1536dnf%20MFP%20(42307C)._ipp._tcp.local/ + class = network + info = HP LaserJet M1536dnf MFP (driverless) + make-and-model = HP LaserJet M1536dnf MFP + device-id = MFG:HP;MDL:LaserJet M1536dnf MFP;CMD:PDF,PS,PCL,AppleRaster,URF; + location = +... +---- + +==== How to setup CUPS temporary queues with USB printer + +* additional requirements: +** install *ipp-usb*, which will transform IPP over USB devices to network printer on localhost: + +---- +$ sudo dnf -y install ipp-usb +---- + +Then you can follow the steps in xref:_how_to_setup_cups_temporary_queues_with_network_printer[manual] for network printers. + +=== How to install a permanent print queue + +Prerequisties for permanent driverless printers: enable IPP in your firewall, enable IPP on your printer if possible. + +==== Installation via CUPS web UI ==== + +* start cups.service + +---- +$ sudo systemctl start cups +---- + +* go to *http://localhost:631* in your browser +* go to *Administration* tab +* click on *Add printer* +* enter your credentials +* choose the found device or the connection you prefer - for driverless permanent queue choose *Internet Printing Protocol (ipp)* +* in case you didn't choose a found device, enter the device uri at the next page - for driverless printers they usually are: + +---- +Network printers: +ipp://:631/ipp/print + +USB printers via ipp-usb: +ipp://localhost:60000/ipp/print + +Non-driverless printers via printer application: +ipp://localhost:8000/ipp/print/ + +Printers pointing to a remote CUPS server: +ipp://:631/printers/ +---- + +* choose device manufacturer and model (*IPP Everywhere* for driverless printers) +* set a different default options if needed and finish + +*Notes:* + +Adding a permanent queue for driverless USB printers or non-driverless printers installed in a printer application is usually unnecessary, because they are shared by mDNS on localhost, so any application using CUPS 2.0+ API functions (cupsGetDests(), cupsGetNamedDest(), cupsCopyDestInfo()) should be able to pick them automatically (for network printer it depends whether the device is in the same subnet as your machine). Installling them permanently should be necessary only if an application doesn't use the recent API or to work around a bug which happens when using them as temporary queues. + +If there are more devices via *ipp-usb* or printer applications, they listen on different ports - devices via ipp-usb start on port 60000, separate printer applications start on port 8000. + + +==== Installation via CLI commands ==== + +* you will need a device uri - ``, which you can find by `lpinfo -v`: + +---- +$ lpinfo -v +direct usb://HP/Officejet%20Pro%208500%20A909a?serial=NNNNNNNNN&interface=1 + ==================================================================== +network dnssd://Officejet%20Pro%208500%20A909a%20%5B43FD8E%5D._pdl-datastream._tcp.local/ + ================================================================================= +---- + +or construct it manually - f.e. for IPP printers: + +---- +ipp://:631/ipp/print +---- + +and a driver name - ``, f.e.: + +---- +$ lpinfo -m +.... +everywhere IPP Everywhere +========== +... +---- + +---- +$ lpadmin -p -v -m -E +---- + +where `` and `` are underscored strings from previous commands and `` is a print queue name, which is chosen by you. + +== How to install a printer via printer application in SNAP and making it available for CUPS + +Currently printer applications are available in SNAPs on Fedora. I'm planning to release them as RPMs, but the code base will be the same, so its testing can happen even with SNAPs. + +* install snapd, + +First we have to install snapd for testing purposes: + +---- +$ sudo dnf -y install snapd +$ sudo ln -s /var/lib/snapd/snap /snap +$ snap version +---- + +If the installation had been successful, the last command will show snapd's version. + +* install and run printer application, + +First the SNAP with printer application has to be installed and started by the commands below. All printer applications are available in SNAP Store under the same names as they are at https://github.com/orgs/OpenPrinting/repositories[OpenPrinting repositories]. We will use [filename]`ps-printer-app` printer application in the next steps. + +---- +$ sudo snapd install --edge ps-printer-app +$ sudo snapd run ps-printer-app +---- + +* go to http://localhost:8000, + +After starting the printer application its web interface becomes available at http://localhost:8000 - if user installs and runs another printer application, it will become available at localhost on the next port (8001). The printer application can contain several printers (as [filename]`cupsd` does). + +* click on `Add Printer` on the main page, +* choose the printer's name, +* select the found device or choose `Network printer` from `Device` scroll menu and provide hostname or IP of the device, +* choose to auto-detect driver or select the driver by yourself, +* click on `Add Printer`, +* now the printer should be available at least on localhost via mDNS (if [filename]`avahi-daemon` is running and `nss-mdns` is installed)- check it by [filename]`avahi-browse`(`avahi-tools` has to be installed): + +---- +$ avahi-browse -avrt +... += lo IPv4 HP Laserjet M1536 _ipp._tcp local + hostname = [fedora-2.local] + address = [127.0.0.1] + port = [8000] + txt = ["Scan=F" "PaperMax=legal-A4" "Fax=F" "product=(HP LaserJet M1536dnf MFP Postscript (recommended))" "mopria-certified=1.3" "priority=0" "qtotal=1" "txtvers=1" "Duplex=T" "Color=F" "TLS=1.2" "URF=V1.5,W8,PQ3-4-5,DM1,FN3,IS0-20,MT1-5-6-3,OB10,RS300-600" "UUID=24837a30-5f87-3ac9-6d85-086d486092dd" "pdl=image/pwg-raster,image/urf,application/vnd.printer-specific,application/pdf,application/postscript,image/jpeg,image/png" "note=" "adminurl=http://fedora-2.local:8000/HP_Laserjet_M1536/" "ty=HP LaserJet M1536dnf MFP Postscript (recommended)" "rp=ipp/print/HP_Laserjet_M1536"] +... +---- + +* and by `lpstat -e`: + +---- +$ lpstat -e +... +HP_Laserjet_M1536 +... +---- + +The available printing options for the printer installed via printer application can be checked with [filename]`lpoptions` command: + +---- +$ lpoptions -p HP_Laserjet_M1536 -l +PageSize/Media Size: 184.15x260mm 195.09x269.88mm A4 A5 B5 DoublePostcardRotated Env10 EnvC5 EnvDL EnvMonarch Executive FanFoldGermanLegal ISOB5 Legal *Letter Postcard roc16k Custom.WIDTHxHEIGHT +InputSlot/Media Source: *Auto Tray1 Auto +MediaType/Media Type: *Unspecified Stationery Light6074 MidWeight96110 Heavy111130 ExtraHeavy131175 MonochromeLaserTransparency Labels StationeryLetterhead Envelope StationeryPreprinted Prepunched Colored Bond StationeryRecycled Rough Vellum +cupsPrintQuality/cupsPrintQuality: Draft *Normal High +ColorModel/Output Mode: *Gray +Duplex/Duplex: *None DuplexNoTumble DuplexTumble +OutputBin/OutputBin: *FaceDown +---- + +== How to install a scanner + +Scanners in Linux don't have to be installed the same way as printers are if they are in the same network or connected via USB - you just need *sane-backends* to be installed and any scanning application will communicate with scanner/multifunction device via the backend which supports the scanner. + +However, the older HP scanners and multifunction devices require an additional package - *hplip* - and its binary plugins downloaded via [command]`hp-plugin -i` if they aren't supported by sane-backends already. + +=== How to find out my multifunction device or standalone scanner is capable of driverless scanning? + +* check the device specification and look for eSCL/AirScan/WSD - if any of these are mentioned, the device is capable of driverless scanning +* most devices which advertise they can do AirPrint are capable of AirScan too +* [USB devices only] check for IPP over USB (xref:_how_to_find_out_if_my_usb_device_supports_ipp_over_usb[manual] here). + +=== How to make driverless scanning work + +For LAN located and USB devices: + +* have *avahi-daemon* enabled and running + +---- +$ sudo systemctl enable avahi-daemon +$ sudo systemctl start avahi-daemon +---- + +* enable MDNS in firewall +* [USB devices only] install *ipp-usb* + +For network scanners in a different network: + +* set the scanner device uri in [filename]`/etc/sane.d/airscan.conf` - see: + +---- +man sane-airscan +---- + +== How to setup mDNS with systemd-resolved + +systemd-resolved is enabled and running by default since F33 and can be setup to work with Avahi on mDNS support which CUPS needs - Avahi does the advertising, registering and sharing devices, and resolved will handle '.local' address resolution. It will work with following steps: + +* put [option]`MulticastDNS=resolve` into [filename]`/etc/systemd/resolved.conf` + +---- +$ sudo systemctl restart systemd-resolved +$ sudo nmcli connection modify connection.mdns yes connection.llmnr yes +$ sudo systemctl restart NetworkManager +---- + +== How to compress files + +Example: + +---- +$ tar -czvf cups-information.tar.gz /etc/cups cups.logs troubleshoot.txt lpinfo.log +---- + +== Restarting cups service + +You restart cups service with: + +---- +su -c 'systemctl restart cups.service' +---- + diff --git a/modules/ROOT/pages/debug-wayland-problems.adoc b/modules/ROOT/pages/debug-wayland-problems.adoc index b141c69..7b408e8 100644 --- a/modules/ROOT/pages/debug-wayland-problems.adoc +++ b/modules/ROOT/pages/debug-wayland-problems.adoc @@ -1,4 +1,10 @@ = How to debug Wayland problems +N.N. +:revnumber: unspecified +:revdate: 2020 +:category: Troubleshooting +:tags: How-to, Workstation, Wayland +//:imagesdir: ./images //FIXME * xref:debug-wayland-problems.adoc[How to debug Wayland problems] - note: maintained on wiki, does not fit quick-docs IMHO diff --git a/modules/ROOT/pages/disabling-automatic-screenlock.adoc b/modules/ROOT/pages/disabling-automatic-screenlock.adoc index c62fb05..59b4247 100644 --- a/modules/ROOT/pages/disabling-automatic-screenlock.adoc +++ b/modules/ROOT/pages/disabling-automatic-screenlock.adoc @@ -1,8 +1,31 @@ -ifdef::context[:parent-context: {context}] -:context: disabling-automatic-screenlock - = Disabling the GNOME automatic screen locking +Oğuz Ersen +:revnumber: F31,F32 +:revdate: 2020-04-09 +:category: Administration +:tags: How-to, Customization, Workstation, Gnome + + + +In the interest of safety and privacy, the GNOME automatic screen lock is enabled by default. + +When the screen locks after a period of inactivity, you must enter your password to unlock the screen. + +You can disable this feature at any time. + +To disable the GNOME automatic screen lock, complete the following steps. + +For Fedora 31 (GNOME 3.34): + +. On the desktop, navigate to the upper-right corner of the screen, click the arrow icon to expand the desktop options and then click the *Settings* icon. +. From the the *Settings* menu, select *Privacy*. +. On the *Privacy* page, select *Screen Lock*, and toggle the *Automatic Screen Lock* switch from *On* to *Off*. +. Close the window and verify that in the *Privacy* page, the *Screen Lock* is *Off*. + +For Fedora 32 (GNOME 3.36): + +. On the desktop, navigate to the upper-right corner of the screen, click the arrow icon to expand the desktop options and then click *Settings*. +. From the *Settings* menu, select *Privacy*, and then select *Screen Lock*. +. On the *Screen Lock* page, toggle the *Automatic Screen Lock* switch from *On* to *Off* -include::{partialsdir}/proc_disabling-gnome-screenlock.adoc[leveloffset=+1] -ifdef::parent-context[:context: {parent-context}] -ifndef::parent-context[:!context:] +To enable the automatic screen lock, repeat this process and toggle the switch from *Off* to *On*. \ No newline at end of file diff --git a/modules/ROOT/pages/how-to-debug-printing-problems.adoc b/modules/ROOT/pages/how-to-debug-printing-problems.adoc deleted file mode 100644 index c5c1bb3..0000000 --- a/modules/ROOT/pages/how-to-debug-printing-problems.adoc +++ /dev/null @@ -1,549 +0,0 @@ -= How to debug printing issues -Brandon Nielsen ; Zdenek Dohnal -:revnumber: F35 onwards -:revdate: 2022-02-10 -:category: Troubleshooting -:tags: How-to printer - - -If you are experiencing a problem with printing, please take a look at the https://fedoraproject.org/wiki/Bugs/Common[common bugs] page before filing a bug. If the problem you are seeing is not listed there or none of the workarounds seem to help, please consider xref:cups-filing-a-bug-report.adoc#_filing_a_bug_report[filing a bug report] to help us make Fedora run better on your hardware. - - - -== Identifying your problem area - -Printing issues can be fairly complex and active cooperation or lots of data can be requested from reporter by maintainer to helping maintainer to at least understand and (if it is not hardware specific issue) reproduce the issue, so please have a patience and try to narrow the problem as much you are able to for maintainers. - -There can be: - -* issues with seeing or connecting to the printer (it can be cups backend issues, avahi issues, libusb issues, cups-browsed issues), -* accessibility issues (correct/wrong setup in cupsd.conf or its bad interpretation by cupsd daemon, bad cooperation with NIS, SSSD...), -* printing with help of samba (issues with smb backend, which is part of samba) or with samba authenticated through Kerberos (samba_krb5_printing), -* issues with filters used during filtering the document into document format supported by printer, which influence how or if the document will be printed (issue with filters - pdftops, pdftopdf, pstops, bannertopdf etc. - or issues with binaries or libraries which filters uses - libgs, qpdf, poppler...), -* issues with Postscript Printer Description files, which are old way of defining printers capabilities like supported page sizes, borders etc... - -Not mentioning possible limitations or issues in firmware or hardware of printer itself, so any kind of data or narrowing the issue is welcomed. - -The best start is to attach files with logs described further down. - -=== CUPS logging - -All CUPS logging is redirected to journal by default since Fedora 28 (there was a redirecting of error_log to journal by default before Fedora 28). - -We need to define two different ways of capturing incident-bound CUPS whole logs - the one if the broken print queue isn't provided by HPLIP and the other if it is. They differs in the filter option of journald - if you use non-HPLIP queue for debugging, it is okay to gather the logs from cups systemd unit (by '-u cups'), because all error messages are correctly redirected to cups systemd unit logging and they are accessible in the output after unit filtering. HPLIP libraries are not implemented to do the same (upstream is unresponsive to accept a potencial fix into the project and the issue is not critical enough to drag a downstream patch forever), so their messages aren't marked for cups systemd unit and they're filtered out after calling journald with '-u cups'. For such queues journald log without filtering is required. - -[NOTE] -=============================== -Incident-bound journald log without filtering is required only for HPLIP print queues (their device uri starts with hp://) and it is unwanted for other queues, because it can be hard to read in larger cases. Please attach incident-bound journald log only when it is necessary. -=============================== - -==== Location of CUPS logging - -CUPS logging is located in the system journal by default, but the logging into a file can be set in [filename]`/etc/cups/cups-files.conf` with directive [option]`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. - -Setting the logging to a file has following cons (without further operations): - -* unable to get only logs connected to a job without chaining more commands -* unable to get logs for specified time frame without chaining more commands - -For capturing a incident-bound logs `tail -f` can be used e.g.: - ----- -tail -f /var/log/cups/error_log ----- - -==== Enable CUPS debug logging - -Enable full debugging information with: - ----- -$ cupsctl LogLevel=debug2 ----- - -==== CUPS job log - -[IMPORTANT] -=============================== -If the problem appears when you sent document to print or if you are trying to, capture logs for this job. If the job log is available, its attaching is *REQUIRED*. -=============================== - -===== Prepare CUPS for job logging - -For being able to see specific job log, please turn on: - ----- -PreserveJobFiles Yes ----- - -in your [filename]`/etc/cups/cupsd.conf` file and restart cup service. Do not forget to remove the line after you are done with debugging. [command]`lpstat -W all` seems to be empty after printing if you do not enable the directive. - -===== Get a job log for a specific job ID - -To capture job log you need to know Job ID (JID) of the job - it is the number after dash in a request ID: - -Request ID looks like this: - ----- -- ----- - -and can be seen in terminal if you send a document to print by [command]`lp` command: - ----- -$ lp -d ... -request id is - (N file(s)) ----- - -Or when you list jobs (see [command]`man lpstat`) - the latest job is at the end: - ----- -$ lpstat -W all -... -- 1024 Wed 11 Jan 2017 05:52:19 PM CET ----- - -You can get the latest job logs automatically (if you have [command]`awk` installed and [command]`lpstat -W` all returns jobs) by: - ----- -$ journalctl -u cups JID=`lpstat -W all | awk '{print $1}' | awk -F '-' '{print $NF}' | tail -n 1` > cups_job_log ----- - -Or manually, if you found JID by yourself: - ----- -journalctl -u cups JID= > cups_job_log ----- - -==== Incident-bound cupsd log (broken print queue isn't HPLIP supported) - -Sometimes we cannot bind the error with a specific print job, so the job log is uneffective. Incident-bound cupsd log is needed. - -===== How to start to capture incident-bound cupsd logging - -In new terminal/terminal tab, please issue: - ----- -journalctl -f -u cups > cups_whole_log ----- - -===== How to get incident-bound cupsd logging - -After you trigger the error condition you are trying to diagnose e.g. printing something, try to find a printer via [command]`lpinfo` etc., you terminate capturing incident-bound cupsd log from xref:_how_to_start_to_capture_incident_bound_cupsd_logging[step above] by `+`. - -==== Incident-bound cupsd log (broken print queue is HPLIP supported) - -Unfortunately, HPLIP libraries don't log into CUPS unit in journal, so if your print queue is installed with HPLIP driver (its device uri starts with `hp://`), we need incident-bound journal log. - -===== How to start to capture incident-bound journal logging - -In new terminal/terminal tab, please issue: - ----- -journalctl -f > journal_whole_log ----- - -===== How to get incident-bound journal logging - -After you trigger the error condition you are trying to diagnose e.g. printing something, running HP script etc., you terminate capturing incident-bound journal log from xref:_how_to_start_to_capture_incident_bound_journal_logging[step above] by `+`. - -==== Turning off debug logging - -Please attach [filename]`cups_job_log` for the problematic job, [filename]`cups_whole_log` or [filename]`journal_log` if you caught whole cupsd log during the problematic event to bug report as an attachment. - -Then to turn off debugging information, do this: - ----- -$ sudo sed -i 's,LogLevel debug2,LogLevel warn,' /etc/cups/cupsd.conf -$ sudo systemctl restart cups ----- - -==== More commands for working with systemd-journald - -View the log messages with: - ----- -journalctl -u cups -e ----- - -or: - ----- -journalctl -u cups --since=... ----- - -To filter out messages relating to a specific job ID, use: - ----- -journalctl -u cups JID=... ----- - -(tab completion will show you which job IDs have log messages) - -=== cups-browsed logging - -cups-browsed daemon was introduced in Fedora around cups-1.5 version. It can browse Bonjour broadcasts, CUPS broadcasts (deprecated) and LDAP servers for printers and create or remove local queues pointing to those printers. It can creates broadcasts of local CUPS queues, but it is marked as deprecated. - -For setting debug logging on you need to add: - ----- -DebugLogging stderr ----- - -to [filename]`/etc/cups/cups-browsed.conf`. - -The logs will be available in system journal after cups-browsed restart. - -=== HPLIP scripts debug logging - -Python scripts from HPLIP (e.g. [command]`hp-setup`, [command]`hp-clean`, [command]`hp-scan`) have debug logging redirected to the standard error file descriptor, so they are not logged in journal. For getting their debug logging, run the script with `-ldebug` parameter e.g.: - ----- -$ hp-setup -ldebug -i ----- - -and reproduce the issue. Then copy the messages from terminal into [filename]`hp_script_log`. Please attach the file to the bugzilla ticket too. - -=== What make and model is my printer? - -Each different printer has a model-specific Device ID. You can find out with the [command]`lpinfo` command: - ----- -su -c "lpinfo -l -v" ----- - -This command runs each of the backends in discovery mode, to get them to report devices they can automatically detect. This will output a series of blocks of lines, each one like this: - ----- -Device: uri = usb://HP/DESKJET%20990C?serial=U123456789AB - class = direct - info = HP DESKJET 990C - make-and-model = HP DESKJET 990C - device-id = MFG:HEWLETT-PACKARD;MDL:DESKJET 990C;CMD:MLC,PCL,PML;CLS:PRI -NTER;DES:Hewlett-Packard DeskJet 990C;SN:U123456789AB;S:00808880800010032C100000 -0C2000000;P:0800,FL,B0;J: ; - location = ----- - -The line which identifies this particular model type is the long one that starts "device-id =" (shown here wrapping over three lines). - -Note that if your printer cannot be automatically detected, you may still be able to find out the Device ID by running the appropriate backend with the printer hostname as the argument. The *usb*, *parallel*, *snmp*, and *dnssd* backends all try to report the actual Device ID given by the printer. - ----- -$ /usr/lib/cups/backend/snmp 10.34.18.3 - -network socket://10.34.18.3 "HP Color LaserJet CP2025dn" "HP Color LaserJet CP2025dn" -"MFG:Hewlett-Packard;CMD:PJL,PML,PCLXL,POSTSCRIPT,PCL;MDL:HP Color LaserJet CP2025dn; -CLS:PRINTER;DES:Hewlett-Packard Color LaserJet CP2025dn;MEM:MEM=55MB;COMMENT:RES=600x8;" "HP Color LaserJet CP2025dn" ----- - -Device ID is in this case (see http://www.cups.org/documentation.php/doc-1.5/man-backend.html[backend(7)]) the last but one field. - -=== Which print queues are available for me? - -The queues on your machine can be permanent ones or temporary. CUPS is capable to list all available print queues on the local network (permanent and temporary queues) by: - ----- -$ lpstat -e ----- - -For permanent queues you are able to get more info with: - ----- -$ lpstat -t ----- - -=== Which driver am I using? - -The PPD file for the printer queue can tell you which driver is in use. You can use this command to find out which driver is being used: - ----- -grep -H '^*NickName:' /etc/cups/ppd/*.ppd ----- - -You can also find this out using the [command]`system-config-printer` application. Double-click on the icon for the queue and look at the Make and Model field. - -To see the available drivers, click on the _Change..._ button next to that field. You might find it useful to try another driver to see if that shows the same problem. - -==== Driverless models - -Most printers released since 2010 are capable of AirPrint or IPP Everywhere, which means they don't need to be installed to work - the device is found by Avahi and the print capabilities are communicated via IPP protocol - they are basically driverless devices. There are two solutions in Fedora which implement IPP everywhere: - -- CUPS 'everywhere' model -- cups-filters 'driverless' driver - -===== CUPS 'everywhere' model - -It is CUPS implementation of IPP everywhere standard, available as a special printer model. The model is used when you use CUPS temporary queue for your device or if you install your device with as IPP Everywhere model in CUPS web ui or via lpadmin (using `-m everywhere`). - -Because the created PPD file depends on IPP communication with printer, we need info which is gathered from the device. You can use [command]`ipptool` for that: - ----- -$ ipptool --ippserver ipptool.attr get-printer-attributes.test ----- - -Attach the created [filename]`ipptool.attr` to the bugzilla ticket if needed. - -===== cups-filters 'driverless' driver - -Cups-filters special driver which is used for generating PPD according IPP Everywhere standard. The driver is used if you choose *driverless* model during printer installation. - -We need get-printer-attributes request output too: - ----- -$ ipptool --ippserver ipptool.attr get-printer-attributes.test ----- - -and debug logs from the driver itself when it generates PPD for your device: - ----- -$ driverless -d cat 2> driverless_debug > created_ppd ----- - -Attach all created files to the bugzilla ticket if needed. - -=== Finding where the problem lies - -When a print job is processed it is sent through a chain of _filters_ to convert the file into a format the printer can understand, and then finally sent to a _backend_, a program which can transport the data to the printer. By slightly changing how you print you can try a different printing path to see if that changes anything. If it works around the problem, you know which area the problem was in -- include that information in a bug report so that we can fix it. - -==== Application - -Try printing from a different application to see if the problem goes away or if it occurs regardless of how a file is printed. Try printing the document from the command line using the [command]`lp` command. - -==== Document format - -If you are having problems printing PDF files, try printing other types of file to see if the problem is with printing anything or if it is specific to printing PDF files. Try converting the file to a different format and printing that. - -If the problem relates to printing text files, try removing/installing the paps package. This package provides an alternative text-to-PostScript filter to the one that comes with CUPS. - -To inspect the document that was submitted to CUPS for printing, enable the [option]`PreserveJobFiles` option like this: - ----- -cupsctl PreserveJobFiles=yes ----- - -Submitted job documents will remain in `/var/spool/cups`. There are files with two types of names - [filename]`dXXXXX-YYY` and [filename]`cXXXXX`. [filename]`dXXXXX-YYY` is file which goes to CUPS system, unfiltered file - `XXXXX` is job ID, which is filled with zeros to be 5 characters long, and `YYY` is sequence number of file in the job. [filename]`cXXXXX` is file which contains printing options for a job specified by job ID in `XXXXX`. Please attach [filename]`dXXXXX-YYY` to the bug for a job when you experience the issue - -===== Running filters by hand - -More advanced users may like to try running the CUPS filters by hand and examining the data file at each step as it is converted between different formats. Here is an example of doing this for a gutenprint queue named pqueue with the CUPS test page which is its own special MIME type, `application/vnd.cups-banner`: - -First you need to know the filter pipeline for `application/vnd.cups-banner` -> `printer/pqueue` (output MIME type). You can either xref:_enable_cups_debug_logging[enable debugging], print a test page, get xref:_cups_job_log[CUPS job log] and in cups_job_log you'll find something similar to: - ----- -envp[29]="FINAL_CONTENT_TYPE=printer/pqueue" -Started filter /usr/lib/cups/filter/bannertopdf (PID 1111) -Started filter /usr/lib/cups/filter/pdftopdf (PID 1112) -Started filter /usr/lib/cups/filter/gstoraster (PID 1113) -Started filter /usr/lib/cups/filter/rastertogutenprint.5.2 (PID 1114) ----- - -or run - ----- -/usr/lib/cups/filter/bannertopdf 1 me '' 1 '' bannertopdf.pdf -cupsfilter -e -m printer/pqueue -p /etc/cups/ppd/pqueue.ppd bannertopdf.pdf > /dev/null ----- - -and you'll see: - ----- -INFO: pdftopdf (PID 1111) started. -INFO: gstoraster (PID 1112) started. -INFO: rastertogutenprint.5.2 (PID 1113) started. ----- - - -[NOTE] -=============================== -This filter pipeline is from cups-1.6. With cups < 1.6 you can see bannertops -> pstops -> pstoraster instead. -=============================== - -Now you can run filters by hand: - ----- -export PPD=/etc/cups/ppd/pqueue.ppd -/usr/lib/cups/filter/bannertopdf 1 me '' 1 '' bannertopdf.pdf -/usr/lib/cups/filter/pdftopdf 1 me '' 1 '' pdftopdf.pdf -/usr/lib/cups/filter/pdftoraster 1 me '' 1 ''out.ras -/usr/lib/cups/filter/rastertogutenprint.5.2 1 me '' 1 ''out.prn ----- - -Here, [command]`evince` or [command]`okular` can be used to examine the output after the first two filters, [command]`rasterview` can be used to examine the output of the third filter, and the last filter's output must be inspected by hand or sent directly ([command]`lpr -oraw out.prn`) to the printer. - -==== Driver - -If you have access to a different make/model of printer it might be worth trying to see if the problem occurs on both of them or just one. This can give an indication about whether it is a problem with a particular driver, or if it is a more general problem. - -Even if you only have access to the one printer there is often a choice of drivers to use for a given printer model, and trying each one in turn can be useful in narrowing down the problem. See xref:_which_driver_am_i_using[above] for how to do that. - -===== Foomatic - -For Foomatic drivers you can try enabling Foomatic debugging by editing the file [filename]`/etc/foomatic/filter.conf` and adding a line: - ----- -debug: 1 ----- - -Next time you print a job to a queue using foomatic the debugging will be put in [filename]`/tmp/foomatic-rip.log`, and the input file as received by foomatic-rip will be in [filename]`/tmp/foomatic-rip.ps`. - -==== Backend (job transport) - -It may be possible for you to try a different backend. Using [command]`system-config-printer`, double-click on the printer queue icon and click the _Change..._ button next to the _Device URI_ field. You may see a _Connection_ expander arrow near the bottom right hand corner of the window -- click that to see which backends are available. For USB-connected HP printers, typically either of the *hp* and *usb* backends can be used. - -For capturing USB communication: - -* find out the bus number where USB device is connected, f.e.: - ----- -$ lsusb -Bus 002 Device 010: ID 03f0:012a HP, Inc HP LaserJet M1536dnf MFP - - = ----- - -* start USB packet capture: - ----- -$ sudo tcpdump -i usbmonN -s0 -w usb.pcap ----- - -where N is the bus number. - -For network printers you may have different protocols you can try. - -* *socket* is for HP JetDirect (usually port 9100) -* *lpd* is for older style UNIX print shares -* *smb* is for CIFS shares from Windows systems -* *ipp* is for Internet Printing Protocol-enabled devices and also for other CUPS servers --- You can capture the IPP traffic with [command]`tcpdump` like this (the interface name may differ from *p4p1*): - ----- - tcpdump -n -i p4p1 -U -s0 -w ipp.pcap port ipp ----- - -* *bjnp* is for Canon's proprietary bjnp network protocol (usually port 8611) - -==== Configuration tool - -If your problem relates to configuring print queues, try using one of the other methods of doing so. There are four available: - -* The GNOME 3 System Settings application (*control-center*), _System Settings_ > _Printers_ from the GNOME Shell -* [command]`system-config-printer`, _System_ > _Administration_ > _Printing_ from the GNOME menu -* the CUPS web interface, http://localhost:631/ -* the command line tools [command]`lpadmin`, [command]`lpoptions`, [command]`cupsctl`, [command]`cupsaccept`, [command]`cupsenable` etc. - - - -== User stories - -There are several common user stories when it comes to debugging printing issues. I'll mention some of them with steps how to get necessary information. - -=== I have HP printer and have a problem with HPLIP script - -Please follow the steps in the following sections: - -* xref:how-to-debug-printing-problems.adoc#_enable_cups_debug_logging[enable CUPS debug logging] -* xref:how-to-debug-printing-problems.adoc#_how_to_start_to_capture_incident_bound_journal_logging[start to capture journal logs] -* xref:how-to-debug-printing-problems.adoc#_hplip_scripts_debug_logging[run the script with enabled debugging] -* xref:how-to-debug-printing-problems.adoc#_how_to_get_incident_bound_journal_logging[get the journal logs] -* attach the files to the bugzilla ticket and xref:how-to-debug-printing-problems.adoc#_turning_off_debug_logging[turn off debug logging] -* provide printer model name and printer PPD file from `/etc/cups/ppd/` - -=== I have HP printer, installed it with HPLIP and have a problem with it - -HPLIP installed print queue has a device uri starting with hp://. - -Please follow the steps in the following sections: - -* xref:how-to-debug-printing-problems.adoc#_enable_cups_debug_logging[enable CUPS debug logging] -* xref:how-to-debug-printing-problems.adoc#_how_to_start_to_capture_incident_bound_journal_logging[start to capture journal logs] -* trigger your issue -* xref:how-to-debug-printing-problems.adoc#_how_to_get_incident_bound_journal_logging[get the journal logs] -* attach files with output of [command]`lsusb -v` and from `/var/log/ipp-usb` if the device is connected by USB -* attach the files to the bugzilla ticket and xref:how-to-debug-printing-problems.adoc#_turning_off_debug_logging[turn off debug logging] -* provide printer model name and printer PPD file from `/etc/cups/ppd/` - -=== My printer doesn't print correctly or at all, but I can see the printer in print dialog - -Please follow the steps in the following sections: - -* xref:how-to-debug-printing-problems.adoc#_enable_cups_debug_logging[enable CUPS debug logging] -* xref:how-to-debug-printing-problems.adoc#_how_to_start_to_capture_incident_bound_cupsd_logging[start to capture logs] -* trigger your issue - print the specific document to the specific print queue you have problem with -* xref:how-to-debug-printing-problems.adoc#_how_to_get_incident_bound_cupsd_logging[get the logs] -* attach the created files to the ticket and xref:how-to-debug-printing-problems.adoc#_turning_off_debug_logging[turn off debug logging] -* attach your printer PPD file from `/etc/cups/ppd/` if available -* attach the file you wanted to print -* tell what application you printed from -* mention your xref:how-to-debug-printing-problems.adoc#_which_driver_am_i_using[printer model] -* attach files with output of [command]`lsusb -v` and from `/var/log/ipp-usb` if the device is connected by USB - -=== CUPS generic issue - -For generic issues - printer wasn't found, segfault - please follow the steps in the following sections (`avahi-daemon` must run): - -* xref:how-to-debug-printing-problems.adoc#_enable_cups_debug_logging[enable CUPS debug logging] -* xref:how-to-debug-printing-problems.adoc#_how_to_start_to_capture_incident_bound_cupsd_logging[start to capture logs] -* trigger the issue - e.g. try to find printers via [command]`sudo lpinfo -l -v`, do some action in web ui - depends on your problem -* xref:how-to-debug-printing-problems.adoc#_how_to_get_incident_bound_cupsd_logging[get the logs] -* attach created files to the ticket and xref:how-to-debug-printing-problems.adoc#_turning_off_debug_logging[turn off debug logging] -* put the output of xref:how-to-debug-printing-problems.adoc#_what_make_and_model_is_my_printer[lpinfo] into a file and attach it -* put the output of xref:how-to-debug-printing-problems.adoc#_which_print_queues_are_available_for_me[both lpstat commands] into a file and attach it -* attach files with output of [command]`lsusb -v` and from `/var/log/ipp-usb` if the device is connected by USB - -=== My printer doesn't print correctly - I use 'everywhere' model - -Please follow the steps in the following sections: - -* xref:how-to-debug-printing-problems.adoc#_cups_everywhere_model[get data from get-printer-attributes request] -* xref:how-to-debug-printing-problems.adoc#_my_printer_doesnt_print_correctly_or_at_all_but_i_can_see_the_printer_in_print_dialog[follow the steps with CUPS job log user story] - -=== I have a generic problem with cups-browsed - -Please follow the steps in the following sections: - -* xref:how-to-debug-printing-problems.adoc#_enable_cups_debug_logging[enable CUPS debug logging] -* xref:how-to-debug-printing-problems.adoc#_cups_browsed_logging[enable cups-browsed logging], but don't restart cups-browsed yet. -* xref:how-to-debug-printing-problems.adoc#_how_to_start_to_capture_incident_bound_cupsd_logging[start to capture cupsd logs] -* start cups-browsed via `systemctl` and start to capture its logs: - ----- -$ journalctl -u cups-browsed -f > cups_browsed_log ----- - -* trigger the issue or wait until cups-browsed triggers the issue itself -* cancel cups-browsed and xref:how-to-debug-printing-problems.adoc#_how_to_get_incident_bound_cupsd_logging[cupsd log] captures -* attach created files [filename]`cups_whole_log` and [filename]`cups_browsed_log` to the ticket and xref:how-to-debug-printing-problems.adoc#_turning_off_debug_logging[turn off debug logging] - -=== Printer found by cups-browsed doesn't print or print badly - -The most difficult user story - we need to know how the print queue was created and how it behaves during printing. The print queue found by cups-browsed has a device uri starting with `implicitclass://`. - -Please follow the steps: - -* xref:how-to-debug-printing-problems.adoc#_cups_filters_driverless_driver[get printer info from get-printer-attributes and PPD file] -* xref:how-to-debug-printing-problems.adoc#_enable_cups_debug_logging[enable CUPS debug logging] -* xref:how-to-debug-printing-problems.adoc#_cups_browsed_logging[enable cups-browsed logging], but don't restart cups-browsed yet. -* xref:how-to-debug-printing-problems.adoc#_how_to_start_to_capture_incident_bound_cupsd_logging[start to capture cupsd logs] -* start cups-browsed via `systemctl` and start to capture its logs: - ----- -$ journalctl -u cups-browsed -f > cups_browsed_queue_creation ----- - -* give cups-browsed some time to process found devices (depends on how many devices you have in the local network or how many print queues are stored in the location you set with [option]`BrowsePoll` directive) -* cancel cups-browsed and xref:how-to-debug-printing-problems.adoc#_how_to_get_incident_bound_cupsd_logging[cupsd log] captures - save the files as `cups_queue_creation` and `cups_browsed_queue_creation` - -Now we need to capture the logs during printing: - -* xref:how-to-debug-printing-problems.adoc#_prepare_cups_for_job_logging[prepare CUPS for job logging] -* xref:cups-useful-tricks.adoc#_restarting_cups_service[restart CUPS service] -* start to capture cups_browsed logs again: - ----- -$ journalctl -u cups-browsed -f > cups_browsed_printing ----- - -* trigger your issue - print the specific document to the specific print queue you have problem with -* xref:how-to-debug-printing-problems.adoc#_get_a_job_log_for_a_specific_job_id[get the job log for the job you have just triggered] and cancel the capture of cups-browsed logging -* attach all gathered log files diff --git a/modules/ROOT/pages/how-to-debug-scanning-problems.adoc b/modules/ROOT/pages/how-to-debug-scanning-problems.adoc deleted file mode 100644 index a64c313..0000000 --- a/modules/ROOT/pages/how-to-debug-scanning-problems.adoc +++ /dev/null @@ -1,122 +0,0 @@ -= How to debug scanning issues -Brandon Nielsen ; -:revnumber: unspecified -:revdate: 2021-06-16 -:category: Troubleshooting -:tags: How-to scanners - - - -SANE library, communication libraries and backends can turn on and off debug logging via `SANE_DEBUG_*` environment variables. - -The common environment variables: - -* `SANE_DEBUG_DLL` - enables debugging SANE library -* `SANE_DEBUG_SANEI_USB` - enables debugging communication library for USB - add the environment variable if your device is connected via USB cable -* `SANE_DEBUG_SANEI_TCP` - enables debugging communication library for wireless/ethernet - add the environment variable if your device is connected by Wifi or Ethernet - -Environment variables for enabling debugging a specific backends have a structure - `SANE_DEBUG_`, so the environment variable for f.e. *HPAIO* backend is `SANE_DEBUG_HPAIO*`. - -You can find which SANE backend supports your device http://www.sane-project.org/sane-mfgs.html[here]. If your device is HP and it isn't supported by *airscan* backend or any other SANE backend, it can be supported by *hpaio* backend from *hplip* package, see the list of supported devices https://developers.hp.com/hp-linux-imaging-and-printing/supported_devices/index[here]. - -== Debugging scanner discovery - -If you don't see your scanner in scanning application, then debugging of discovery process is in order. I prefer using [command]`scanimage` in the examples, but the similar steps can be applied for every scanning application like [command]`xsane`, [command]`scanadf`, [command]`simple-scan` etc. - -You will need to use environment variables when you start a scanning application ([command]`scanimage` in this case). The environment variables used with [command]`scanimage` command depends on how your scanner is connected and which backend suppose to support it. So for getting debug logs for HP LaserJet device, *connected via Ethernet/Wifi and supported by HPAIO backend*, use command: - ----- -$ SANE_DEBUG_DLL=255 SANE_DEBUG_HPAIO=255 SANE_DEBUG_SANEI_TCP=255 scanimage -L &> discovery_output ----- - -or, f.e. if you have CanoScan 8600F, connected by USB and supported by genesys backend, use command: - ----- -$ SANE_DEBUG_DLL=255 SANE_DEBUG_GENESYS=255 SANE_DEBUG_SANEI_USB=255 scanimage -L &> discovery_output ----- - -Please attach the created [filename]`discovery_output` file as an attachment to the bugzilla ticket. - -== Debugging scanning process - -If the scanner is found, but an issue happens during scanning itself, we need to debug scanning process itself - which means debugging communication between backend and scanner when you start scanning a document. - -The debugging scanning itself looks similar as discovery - setup the environment variables before running the command/scanning application and catch logs into a file. The possible command can be (f.e. if you have *network scanner supported by HPAIO backend*): - ----- -$ SANE_DEBUG_DLL=255 SANE_DEBUG_HPAIO=255 SANE_DEBUG_SANEI_TCP=255 xsane &> debug_log ----- - -or (once you find out device uri from [command]`scanimage -L` - see the xref:_getting_a_scanner_device_uri[next section]): - ----- -$ SANE_DEBUG_DLL=255 SANE_DEBUG_HPAIO=255 SANE_DEBUG_SANEI_TCP=255 scanimage -d > out.pnm 2> debug_log ----- - -, where you substitute `` for the actual device uri, f.e. 'hpaio:/net/laserjet_m1536dnf_mfp?ip=192.168.1.112'. - -Please attach the created file - [filename]`debug_log` - as an attachment to the bugzilla ticket. - -== Getting a scanner device uri - -This point is basically a manual how to get a scanner uri for debugging scanning itself via [command]`scanimage`. You don't need to provide a scanner uri in GUI applications like [command]`xsane` or [command]`simple-scan`, because the application will do it for you or you can choose the scanner by a mouse click. - -The [command]`scanimage -L` command returns an output where device uri of the device is shown, f.e.: - ----- -$ scanimage -L -device `v4l:/dev/video0' is a Noname Integrated Camera: Integrated C virtual device -device `hpaio:/net/laserjet_m1536dnf_mfp?ip=192.168.1.112&queue=false' is a Hewlett-Packard laserjet_m1536dnf_mfp all-in-one ----- - -F.e.the string 'hpaio:/net/laserjet_m1536dnf_mfp?ip=192.168.1.112&queue=false' is a device uri for for Hewlett-Packard laserjet_m1536dnf_mfp all-in-one scanner. - -== Debugging HP scanner if it is supported by HPLIP - -The hplip package doesn't have unified logging, so some logs come out of HPAIO backend to standard output and HP internal utilities logs come to journal. So we need to capture both to get the understanding of situation. - -It can be done this way: - -* start capturing journal logs at background: - ----- -$ journalctl -f > journal_logs & ----- - -* trigger an action (xref:_debugging_scanner_discovery[discovery] or xref:_debugging_scanning_process[scanning]) -* kill the journalctl process, f.e. this way (if there is only one journactl process) - ----- -$ kill `pidof journalctl` ----- - -then attach the created file - [filename]`journal_logs` - as an attachment to the bugzilla ticket. Please do only one action per capture - that means if you are asked to attach log files for HP scanner discovery and scanning supported by hplip, you will attach as an attachment four files - [filename]`discovery_output`, [filename]`journal_logs` for discovery output, [filename]`debug_logs` and [filename]`journal_logs` for debug_logs. - -== Debugging sane-airscan - -If your device supports eSCL or WSD (you can find it out from device specification - look for the mentioned protocols or AirScan), then its scanning functionality is supported by *sane-airscan*. Regarding debugging, on the top of usual logging sane-airscan gathers a communication dump and output image, which is helpful during investigation. - -sane-airscan debugging can be enabled in [filename]`/etc/sane.d/airscan.conf` by setting: - ----- -[debug] -trace = /path/to/dir/where/debugfiles/will/be/saved -enable = true ----- - -Then do trigger your issue (xref:_debugging_scanner_discovery[discovery] or xref:_debugging_scanning_process[scanning]), go to the dir you defined in [filename]`/etc/sane.d/airscan.conf`, take all files from there and attach them to the bug ticket. - -== How to divide logs - -In case your debug log is too big for bugzilla to attach (because your issue doesn't happen with the lowest settings or logs are big even with the lowest settings), do divide the logs to three files like this: - ----- -$ grep dll debug_log > debug_log_dll -$ grep debug_log > debug_log_connection -$ grep debug_log > debug_log_backend ----- - - is the name of backend which supports your scanner (pixma, genesys, plustek, hpaio, airscan etc.), is the type of connection you use for the device (tcp, usb). - -The division makes the investigation more difficult (the person needs to have three opened files at the same time), so do divide the logs only if log file is too big. -