Questions from another newbie

[Jeremy Shoup]

> Jeremy Shoup wrote:
> > ...
> > We're currently using lprng and we have some "dummy" printers that just
> > drop jobs to /dev/null that I don't want to have to transmit on the
> > network if it can be helped.
>
> With CUPS 1.2, you can control which printers are actually shared
> ("published" is the terminology that is used on the web interface)
>
I'm running 1.1.22, but can upgrade to 1.2 if need be.  I tried to control this in my current setup by denying client access to those specific printers in /etc/cups/cupsd.conf on the print server and creating/configuring the same printers on the clients; however, it appears that as long as it can see it on the server it will attempt to use it and just returns a "denied" type message.  Are you saying that in CUPS 1.2 this has changed so that if a printer is not "published" by the print server the client will look locally for it?
>  > ...
> > Thus far when I bring down the print server and try to print
> > a job I get an error back after about 30 seconds.  With lprng, which
> > I am more used to, the jobs would queue until the print server comes
> > back.  I should imagine that is also possible in cups, but I haven't
> > figured out how yet.  Any suggestions?
>
> If you are printing directly to a server, it should keep retrying
> until the server is back up.  If you have two servers advertising
> the queue, the client should automatically bounce to the other
> server.
>
On the client system I have configured it to forward jobs to the print server using the ServerName directive in /etc/cups/client.conf.
When the print server is down and I print a job, the following is returned:
lpr: error - unable to print file: server-error-service-unavailable
I have seen no evidence that the job is queued anywhere, and when I bring the print server back up the job does not come through.  I would believe that they queue if all of the printers were setup locally on the client machine and using IPP to pass jobs to the print server, but that would mean adding all of the printers on the client and that defeats the purpose.
You indicate that this is supposed to work, so is this a bug or do I need a different configuration?
>
> > One final question... I've got
> > two servers and I'm running a high-availability tool to manage a
> > virtual IP address between them (switches to the backup if the
> > primary goes down).  Any suggestions on how I can keep the cups
> > configurations in sync between them?
>
> Most of our customers are using rsync or some similar mechanism which
> periodically syncs the changes from the "master" server to the "slave"
> servers via a cron job.
>
Is it sufficient to rsync the /etc/cups directory?  I am more familiar with lprng where all I really needed was /etc/printcap.  Do I need /etc/printcap in addition to the /etc/cups directory or will it be recreated when the CUPS service is restarted?
>
>  > Unfortunately I really have a
> > tendency to only manage the primary properly... Also, can I have a
> > "Listen" line in cupsd.conf on the backup for the virtual IP even if
> > it is not in possession of the virtual IP?
>
> No, you can't do that, and that isn't how CUPS provide high-availability
> printing...
>
Fair enough.  This is mostly for compatibility with the large number of lprng systems I have running in the field that I am not in a position to change to CUPS yet - they just forward jobs to the virtual IP since they obviously cannot take advantage of the CUPS high availability configuration.