-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David Boyes wrote: >> 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. In other words, a cups server on *each* subnet. Unfortunately, at our shop, that's also a model with some significant issues, both from a systems management viewpoint, and some technical issues: Technical issues first. In short it *still* doesn't (or didn't) work. My testing only had a half dozen clients trying to poll. I certainly didn't drop this system on all 400 of our hosts just as a trial. If the cups servers can't handle 6 hosts polling them, whyever would they be able to handle more than twenty? from a systems management perspective, it means we actually have to have a server, (actually two servers for redundancy) on each subnet. Adding yet another layer like this is a huge hassle to designate and maintain. I'd much rather simply get a smaller number of print server boxes pimped out with 20 or more interfaces, and pull a cable to each subnet. > It also provides a better > failure model, as the central servers can be temporarily restarted > without risking losing printing enterprise wide. One of the things I like about CUPS is the failure model -- the client can automatically select amoung servers which all publish a queue of the same name. This applies to central print servers, also. > You should also look at the multicast support in the current CUPS. Since > multicast traffic IS routable Now that is something I didn't have at the time. - -- Pat -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHHNZpNObCqA8uBswRAp3NAJ40FA/3n54gZxuDnggo1vDCnucxMQCfV77N j49NLS4s+zrYGvQh79wk450= =fc2z -----END PGP SIGNATURE----- ---------------------------------------------------------------------- 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
begin:vcard fn:Patrick Spinler n:Spinler;Patrick adr:Ozmun Center 1-12;;200 First St SW;Rochester;Mn;55905;United States email;internet:[EMAIL PROTECTED] tel;work:507-284-9485 x-mozilla-html:FALSE version:2.1 end:vcard
