printing

KB5005573 broke our M$-Windows due to Windows' broken printing subsystem and Microsoft's refusal to migrate to Open solutions such as IPP & cupsd. Suddenly M$-Windows clients were failing to connect to printers with an extremely helpful and illuminating error code of 0x0000011b.

The assignment of print queues to device URIs can be listed from a CUPS server using the "-v" option.

The following authenticates to the CUPS server cups.example.com as user adam and lists the queue and device URI relationships.

Listing completed jobs

By default the lpstat command lists the queued/pending jobs on a print queue. However the completed jobs still present on the server can be listed using the "-W completed" option.

For example, to list the completed jobs on the local print server for the queue named "examplep":

Create A Print Queue

[root@host ~]# /usr/sbin/lpadmin -U adam -h cups.example.com:631 -p examplelm1 -E \
  -m "foomatic:HP-LaserJet-laserjet.ppd" -D "Example Pick Ticket Printer"\
   -L "Grand Rapids" -E -v lpd://printer.example.com/lp

This will create a queue named examplelm1 on the host cups.example.com as user adam.

There are few things in IT more utterly and completely baffling than the AIX printer subsystem.  While powerful it accomplishes its task with more arcane syntax and scattered settings files than anything else I have encountered.

If you have a Python app, or almost any kind of app, the accepted manner for printing is to use some kind of subprocess to invoke some command-line utility to submit the print job. Of course this requires that the underlying subsystems are aware of printers [and thus run a printer subsystem]. It also assumes the name of the command-line utility, the permissions are adequate to execute it, and all manner of other things. To put it simply: this is terrible! Why does my web server, workflow server, etc... need to run a print service?