“What happened to printconf-tui?”

This question seems to keep cropping up. I’ll explain why printconf-tui is no longer in Red Hat Enterprise Linux, and what its replacement is.

In Red Hat Enterprise Linux there used to be a command line tool for importing and exporting CUPS configuration. In fact it was part of the printconf system: the previously-exported XML file would be imported into printconf’s own configuration, and printconf would then write new CUPS configuration based on that.

Red Hat Enterprise Linux 5 provides a re-written printing administration tool (still called system-config-printer), avoiding the many problems of the “separate configuration” approach. Now CUPS is configured directly using IPP, and this can be done remotely. The new system-config-printer tool does things in the same way as the CUPS web interface and the CUPS command line tools, and so they can all be used interchangeably.

As a result, importing and exporting queues is much more flexible and predictable. So what’s the new approach for performing the tasks that printconf-tui used to accomplish?

Copying CUPS configuration from one computer to another

If this is the task you want to perform, the first question I want to ask you is if you are sure. You might find that CUPS browsing lets you achieve the same thing more dynamically. However, if you really want to copy all of the queues to another RHEL-5 machine, copy these: /etc/cups/ppd/*.ppd /etc/cups/printers.conf /etc/cups/classes.conf — and optionally /etc/cups/cupsd.conf for the server settings (e.g. whether to publish shared queues).

Make sure you set their SELinux file contexts correctly on the target machine. Just use /sbin/restorecon -vR /etc/cups.

Creating new queues from a script

It can be useful to set up new queues on a machine at installation time. Whereas printconf-tui could be used in a kickstart script, admittedly that is no longer as easy because the CUPS daemon needs to be running before any of the tools can work. This can be worked around by setting up a script to be run on reboot.

The basic usage is: lpadmin -p queuename -v device_uri -m PPD

You can use the lpinfo command to see a list of available device URIs and PPDs. Use lpinfo -v to see the device URIs and lpinfo -m |sort|less to see the PPDs (it is a long list!). All of the PPDs on the system, including those generated on demand by Foomatic, are available to CUPS. For example:

/usr/sbin/lpadmin -p deskjet -v usb://HP/DeskJet%206940 \
                  -m foomatic:HP-DeskJet_6940-hpijs.ppd
/usr/sbin/lpadmin -p deskjet -o printer-is-shared=true
/usr/sbin/cupsenable deskjet
/usr/sbin/accept deskjet

Managing queues on a headless print server

Often a print server will be installed with as little software as possible, and this means no graphical utilities. There are two ways to configure the CUPS server in this case: the most obvious one is to use the CUPS web interface on that machine. On a graphical desktop machine, point a web server to http://the-printer-server:631 and configure away.

The other way is to use system-config-printer on the desktop machine, but tell it to configure the print server’s CUPS instance rather than the one on the local machine (“Goto Server”). Just make sure to allow remote administration on the print server first; you can do that via the CUPS web interface.

6 Responses to ““What happened to printconf-tui?””

  1. Lucky Leavell says:

    Your suggestions for moving queue defintions from one RHEL5 system to another are noted but we are in the process of moving our primary CUPS server from RHEL ES4.6 (cups v1.1) to RHEL 5.1 (cups v1.2). Will the method outlined above (moving /etc/cups/ppd/*.ppd and /etc/cups/printers.conf still work? (Our classes.conf is null.)

  2. tim says:

    Yes, that will still work, although any filters referenced by the PPDs (e.g. foomatic, gimp-print, etc) will need to be installed in the new system.

  3. Ross says:

    Just a response to the question “why you might need to copy CUPS config to other machines”: we had been using the config-printer-tui export/import utility to duplicate CUPS config to each of our “clients”, which are actually application servers, and I’ve now converted these to use browsing instead. I still want some redundancy if I lose my master CUPS server, hence I want to duplicate my master CUPS config to a second server and make use of implicit printer classes on the clients.

    We also setting up a DR site in another city and will use this site for some load balancing as well, so we will probably be copying our central CUPS config to a server there as well.

    What would be very nice would be to have a CUPS server sync feature built into system-config-printer to do this task.

  4. tim says:

    Yes, that’s a good idea. I’ve re-opened a ticket for import/export that had been closed previously:

  5. areamike says:

    How can we manage printers in text based mode now?

  6. tim says:

    areamike: did you read the article?