¿Ese problema existe si no usas el servidor del cliente? Es decir, si cambias client.conf para que conecte al servidor de impresión y pase del que está en localhost, ¿tienes ese problema?

Yo sólo veo justificado un servidor en localhost si se van a utilizar impresoras conectadas localmente. En ese caso si pues tu servidor en localhost tendría tanto las impresoras locales como las remotas (esto último mejor usando browser, pues de lo contrario hay que configurar cada impresora nueva en el cups de cada cliente).

Pero si hay un servidor de impresión y todas las impresoras se conectan a ese, no veo el sentido a utilizar un servidor cups en localhost.

Saludos.

—
May the Free Software Force be with you…

El problema surge cuando hay dos servidores CUPS uno de los cuales envía trabajos al otro. Esta estructura puede surgir por varias razones.
La primera es que no todas las impresoras estén conectadas al mismo ordenador. Entonces, tenemos un servidor CUPS para cada impresora, más un servidor CUPS central al que se envían todos los trabajos (que puede coincidir con alguno de los anteriores). Es el caso presentado.
Otra razón es una red segmentada en la que los usuarios no tengan acceso al servidor de impresión, al cual, por las normas de cortafuegos, sólo se pueda acceder desde otro servidor CUPS sí accesible a los usuarios.

Estoy de acuerdo contigo en que un servidor en localhost sólo tiene sentido para impresoras locales, pero ese es justamente el caso si tienes la impresora conectada al servidor de escritorios: para los usuarios en los terminales, “localhost” es el servidor de escritorios.

En el caso presentado, los usuarios tienen a veces que imprimir en una impresora conectada a un servidor y a veces en la otra impresora conectada al otro servidor, lo cual implica que, a no ser que les hagamos cambiar de servidor CUPS cuando quieren cambiar de impresora, el 50% de las veces estarán usando una casacada de dos servidores CUPS.