> the problem appeared to be related to this, but not between the CUPS > servers. Specifically, since CUPS' default broadcast behavior doesn't > work across subnets, and since most of my hosts wanting to print to > CUPS weren't on those subnets, the client hosts had to be configured > to poll, and that broke the cups servers.
Yeah, that configuration would cause a problem with 10K printers and lots of clients hammering the CUPS servers. That's also not the way CUPS is designed to work. The way to do this (this is now in the sysadmin manuals) for large numbers of printers is to designate one or two hosts per subnet as printer info servers, and have them redistribute the information they receive to the local subnet via directed broadcast/multicast. That reduces the load on the central servers that actually route the output (because the definitions also include the correct URI, which won't involve the "local" servers in any queuing). It also provides a better failure model, as the central servers can be temporarily restarted without risking losing printing enterprise wide. There's no harm to installing both CUPS server and client code on each host. If you never define a printer on the host, the server is quiet and does nothing, and in a pinch you can use it as a distribution point if the usual servers are unavailable. You should also look at the multicast support in the current CUPS. Since multicast traffic IS routable (broadcasts are not, at least w/o bridging), this reduces the load on the central servers w/o the pain of messing with distribution of /etc/printcap. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
