> In other words, a cups server on *each* subnet. At least a system that is designated to perform the distribution of printer information. It does not have to be dedicated, and it does not have to be the same server at any given time. It also gets little extra load to get the information, so it's negligible. But, this sounds more like a political problem than a technical one...8-)
> 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. Certainly not. I am surprised, though. I have clients that have much larger print environments than yours (2x or 3x) that are using CUPS just fine. I'd really like to see your cupsd.conf and printers.conf files, if you can share them. > 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. Linux support for VLAN tagging is your friend. Multiple physical interfaces are hard to manage. > > 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. It's not all that recent. It certainly isn't the default, and you do have to have working multicast routing infrastructure to use it, but it's really, really effective for one-to-many tasks like this. ---------------------------------------------------------------------- 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
