Modify existing printer settings in CUPS on RHEL4

Due to some network changes one of our printers has a new IP. A user came to me today with the following quote: "I can't print from the linux." The IP was changed a month ago and apparently we don't do much printing from "the linux." All of that aside, I want to go into cups and change the IP address but before I proceed I want to know the current settings.

When "modifying" the printer from the cups web interface I essentially get to change everything but the name while all I need to do is change the IP address. I wouldn't be terribly concerned but this is a Dell 5210n which doesn't have a native driver. It does work with whatever ppd file is in use now but I don't have the desire to use trial and error to figure out what it is using. So my questions are as follows:

Is there a way (either command line or gui) to see what the current settings are for this particular printer?

Can I change just the IP address without having to make choices about what type of printer it is (5210n is not an option through modify printer)?

Can I do something with the existing ppd file to create a new queue using the appropriate IP address.

Is there a better way to do this?

The pertinent information is network connected Dell 5210n on a Dell server running RHEL 4 update 3 and that version of cups.

From the command line you can see the installed printers with this command:

lpinfo -v

You can change the configuration like this:

lpadmin -p <printer name> <options>

You are probably interested in changing the device uri. This should contain the IP address. Change it like this:

lpadmin -p <printer name> -v <new uri>

Printer configuration is stored in /etc/cups/printers.conf You could also look around in there for the current configuration. See the CUPS documentation here for details:

http://www.cups.org/documentation.php/doc-1.4/ref-printers-conf.html

I know I am nercoposting, however, I have had this exact same question multiple times and I would love to see someone answer it. I have CUPS servers on Red Hat Enterprise Linux 5 and I'm afraid the situation with wanting to only change the URI but being forced to go through the driver panel is pretty stupid. If all I want to change is the IP address, why should I risk breaking the printer driver?

Using lpadmin -p -v is fantastic, but this should work consistently from the GUI... I should be able to change only the URI from the GUI if I can do it from CLI.

Anyway, the printer.conf configuration file contains no information about what existing PPD is being used. However, there is a directory on my system called /etc/cups/ppd/ and in that directory there is a copy of each existing PPD file used. They are all renamed after the queue name. So, the current PPD driver for the "Queue1" printer is located at /etc/cups/ppd/Queue1.ppd.

But where did it come from? What is the corresponding make/model that the GUI so mysteriously asks for? For this, I found a directory at /usr/share/cups/model/ where there are a bunch of files named *.ppd.gz. I believe that when you select a make and model from the GUI, the gzipped copy is ungzipped and copied to /etc/cups/pdd/Queue1.ppd.

In my case, I copied them all to my home directory and ungzipped them all.

$ for file in $(ls *.gz); do gunzip $file; done

And began comparing the resulting files from /usr/share/cups/model/ against the currently in-use files in /etc/cups/ppd.

For me, nothing matched. So I am back to square one.

I can only assume now that the person who configured these queue made use of the "Or Provide a PPD File:" Upload link, and provided a third-party PPD file which I, of course years later have no clue where that is.

So, the safest thing to do would be to:

1) get a copy of of the current ppd from /etc/cups/ppd and re-upload it via GUI 2) forgo the GUI and use lpadmin -p -v 3) forgo the GUI and modify the IP in the DeviceURI setting in the /etc/cups/printers.conf file and then bounce cups with sudo /sbin/service cups restart

Either way, kind of stupid to make the GUI such that we risk changing the driver when we have no intent to. Hopefully this is fixed in more current versions of CUPS... on Red Hat Enterprise Linux 5 my cups version is 1.3.7.