Le Ven 10 février 2006 13:38, Tim Waugh a écrit : > On Fri, Feb 10, 2006 at 03:48:02AM +0100, Arjan van de Ven wrote: > >> what I'd like to see is a mechanism similar to automatic http proxy >> discovery; eg allow for a "site configuration", which you pull down >> automatic (say if dhcp points you at it) if you are in a certain >> building at work, but not when you are at home (because then you want to >> pull down another printer list from your local firewall box ;) > > I can see two things you might mean: > > a. site policy tells clients about printers in the print room > > b. site policy tells clients what settings to use for any local > printers that get attached, on a model by model basis (e.g. for HP > printer with duplexer, use long-edge duplexing) > > I think that a. should be taken care of by CUPS browsing (2.7.2 Remote > Discovery). Not entirely. Cups browsing tries to "discover" printers. In this mode you find public printers, which tells you nothing about whether printing on them or not is a good idea (network locality for printers do not translate in physical locality and even less in printing policy user classes). An awful lot of printers are not centrally managed or are too dumb to do fine-grained access checks. Also some printers are not remotely discoverable The dhcp server OTOH can regognize individual systems (mac address), select the appropriate printing policy, and suggest it to the system. Sure you could also put printers on a separate network with a smart print server gateway enforcing all sorts of controls. But that's not usually the case. (my personnal opinion is relying on CUPS browsing is broken by design, because 1. most network printers do not advertise themselves 2. you definitely do *not* want every single computer in a network to aggressively scan it to find new ressources 3. you've found a printer at an IP. So what? You still need to actually locate/access it to find your printouts) > I chose interpretation b. when replying to Nicolas Mailhot in > "Persistent Settings (was ...)". I don't know if that's what you > meant, or if it's a good idea, or how to implement it if it is. :-) b. is useful too, but I don't think it was Arjan's point. Regards, -- Nicolas Mailhot
