Ticket #843 (closed defect: wontfix)

Opened 11 years ago

Last modified 10 years ago

Non-cluster CUPS configs should distinguish real/fake Athena printers

Reported by: geofft Owned by:
Priority: low Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

This is a followup to ticket #229, which was resolved for cluster machines with cluster-cups-config, hardcoding a list of printers.

However, less-than-cluster machines still at the moment browse for printers against cluster-printers.mit.edu, and as established in that ticket, this means they also implicitly browse the local network. As long as printing exists in some form, there will exist misconfigured local machines re-advertising the Athena print queue(s) through themselves.

We should find a way to distinguish real Athena print queues from similarly-named print queues on other servers, without necessarily breaking the option to scan for printers on the local network if the admin wants to (as comment #12 alludes to). I don't have a strong preference as to whether it should be on or off by default — if we can fix the upstream CUPS bug that is unintentionally forcing it on, great.

One approach would be to prevent any other queue with a name matching the Athena print queue(s) from showing up, but let all other queues through. (This actually vaguely reminds me of nss_nonlocal, come to think of it.)

Change History

comment:1 Changed 11 years ago by jdreed

misconfigured local machines re-advertising the Athena print queue(s) through themselves

I'm not convinced this happens anywhere near as frequently anymore. Yes, misconfigurations will always happen, but I mean, we don't have debathena-don't-accept-DHCP-leases-from-192.168.1.1-config either, and I don't think we should.

The real issue here was departments concerned that their top-secret printers were showing up in the queues on the Athena machines, and that users would print to them even though the printers were behind locked doors that no student could get to. That has definitely been solved on -cluster. I don't think we're under any obligation to solve it on -workstation and lower.

If we do this, we should emulate the Mac route, which is "You can see all browsed printers when adding a new printer, but they don't show up in the Print dialog without sysadmin intervention.

comment:2 Changed 10 years ago by jdreed

  • Status changed from new to closed
  • Resolution set to wontfix
Note: See TracTickets for help on using tickets.