FC3 (I need a more stable system than Rawhide) has about the correct printing detection. What happens if you have several hundred printers on a network. You do not want detection as these are likely to be light duty, private printers. Currently, CUPS publishes those printers that are marked shared queue and these are picked up by all machines on the network. This is fine but searching for and publishing printers that just have a lan address is wrong. On a large lan this could take hours and result in a long printer listing.
On Fri, 07 Jan 2005 09:28:18 -0500, gslink gslink@one.net wrote:
This is fine but searching for and publishing printers that just have a lan address is wrong. On a large lan this could take hours and result in a long printer listing.
And your suggestion to fix this is? Are you suggesting that auto-detection not be done? Are you suggesting that listing of auto-detected printers not be done?
Network detection has to be done at some point to compile a list of available printers so there is no getting around the issue of it taking a long time to get the printers available on the network without a centralized listing to communicate to.
I'm much more interested in preventing a default long list of available network printers. But to do that there must be a way in the ui to hide and to unhide individual ques in the browsable list. I would also love to be able to see the ip address of device where the que is being browsed from, and I would love to be able to 'hide' all ques from specific ip addresses.
In a large network I can not rely on the Description string that shows up in the s-c-printer listing to be correct, its just a fact of life on a big network. If i could see the ip address in the listing I could at least track down the devices location that is broadcasting and inform IT about its misconfigured cups ques and make some progress either getting the que removed or its Description corrrected.
Right now... sitting on a large network with my fc2 or fc3 machine... my cups listing is a wasteland of auto-detected cups ques from linux machines in offices with locally attached printers with Descriptions like 'location unknown' and que names like 'printer' and 'printer1'. Intermixed with listings from an IT department controlled cups system that I actually want to interact with. I typically need to use 3 printers on the network, a fast black and white, a color phaser and a plotter. The black and white is the default.. and the default works just fine. But negotiating the 300+ list of printers every time i want to print to the plotter is an annoyance, especially when the list isn't static and i can't assume the plotter i want is going to show up in relatively the same place bracketted by the same list neighbors.
In a better world i would be able to hide cups servers and individual ques that I don't want to see on the client computer I control in my office. In a perfect world there would be a way in the ui to seperate a listing of 'available' printers from the printers i have selected already to be usable on my client. Hidden printers would be listed in the very long 'available' list while printers I have selected are in the default list shown in s-c-printer and the appliction print dialogs. Thus preventing me from having to see a list of 300+ printers on the network unless I want to select a new printer to use from the 'available' list. In my perfect world. my s-c-printer list and my printing dialog list would by default show exactly 3 printers, the printers i use. If i need to use a 4th printer. i'd hop over to the available list and select it to be usable.
-jef
What if there was some kind of "chanel" system - i.e. you could join the "physics department" chanel, and only printers shared to this channel, would be seen.
fre, 07.01.2005 kl. 16.10 skrev Jeff Spaleta:
On Fri, 07 Jan 2005 09:28:18 -0500, gslink gslink@one.net wrote:
This is fine but searching for and publishing printers that just have a lan address is wrong. On a large lan this could take hours and result in a long printer listing.
And your suggestion to fix this is? Are you suggesting that auto-detection not be done? Are you suggesting that listing of auto-detected printers not be done?
Network detection has to be done at some point to compile a list of available printers so there is no getting around the issue of it taking a long time to get the printers available on the network without a centralized listing to communicate to.
I'm much more interested in preventing a default long list of available network printers. But to do that there must be a way in the ui to hide and to unhide individual ques in the browsable list. I would also love to be able to see the ip address of device where the que is being browsed from, and I would love to be able to 'hide' all ques from specific ip addresses.
In a large network I can not rely on the Description string that shows up in the s-c-printer listing to be correct, its just a fact of life on a big network. If i could see the ip address in the listing I could at least track down the devices location that is broadcasting and inform IT about its misconfigured cups ques and make some progress either getting the que removed or its Description corrrected.
Right now... sitting on a large network with my fc2 or fc3 machine... my cups listing is a wasteland of auto-detected cups ques from linux machines in offices with locally attached printers with Descriptions like 'location unknown' and que names like 'printer' and 'printer1'. Intermixed with listings from an IT department controlled cups system that I actually want to interact with. I typically need to use 3 printers on the network, a fast black and white, a color phaser and a plotter. The black and white is the default.. and the default works just fine. But negotiating the 300+ list of printers every time i want to print to the plotter is an annoyance, especially when the list isn't static and i can't assume the plotter i want is going to show up in relatively the same place bracketted by the same list neighbors.
In a better world i would be able to hide cups servers and individual ques that I don't want to see on the client computer I control in my office. In a perfect world there would be a way in the ui to seperate a listing of 'available' printers from the printers i have selected already to be usable on my client. Hidden printers would be listed in the very long 'available' list while printers I have selected are in the default list shown in s-c-printer and the appliction print dialogs. Thus preventing me from having to see a list of 300+ printers on the network unless I want to select a new printer to use from the 'available' list. In my perfect world. my s-c-printer list and my printing dialog list would by default show exactly 3 printers, the printers i use. If i need to use a 4th printer. i'd hop over to the available list and select it to be usable.
-jef
On Sun, 09 Jan 2005 18:29:57 +0100, Kyrre Ness Sjobak kyrre@solution-forge.net wrote:
What if there was some kind of "chanel" system - i.e. you could join the "physics department" chanel, and only printers shared to this channel, would be seen.
This idea doesn't solve any of the problems I express if the broadcasting cups server gets to select for itself which channel it is in. Active channels can still be dynamic membership and too long to be usably browsable in the print dialog ui. Active channels still require that every broadcasting cups server on the network be correctly configured to mean anything. On large de-centralized networks... clients can not depend on any broadcasting service to be correctly configured. And its absolutely worse on networks that merely tolerate linux installs but do not have centralized support for linux at all. Administrators for linux machines acting a clients for a service such as cups needs to have an easy way to say 'ignore that specific cups server at ip address W.X.Y.Z its clearly misconfigured and being run by as gentoo zealot who doesn't know how to tie their own shoes and since there is no way I can talk sense into them to reconfigure their cups I need to take local action and disable their cups ques from showing up on my systems to avoid my users acidently trying to use that moron's private printer'
I should be able to 'register' selected printers individually and hide the rest. Active channels just complicate the problem by adding yet another piece of information that can be misconfigured on the broadcasting cups server my client computer has the misfortune to notice. The simpliest control on the client side.. is to be able to register individual ques or individual cups servers... and hide the rest from view until a new printer needs to be found.
-jef"hostile de-centralized networks do exist....for services that broadcast.. local clients need to have tools that can be taught how to ignore rogue broadcasting servers"spaleta
On Sun, 2005-01-09 at 13:36 -0500, Jeff Spaleta wrote:
On Sun, 09 Jan 2005 18:29:57 +0100, Kyrre Ness Sjobak kyrre@solution-forge.net wrote:
What if there was some kind of "chanel" system - i.e. you could join the "physics department" chanel, and only printers shared to this channel, would be seen.
This idea doesn't solve any of the problems I express if the broadcasting cups server gets to select for itself which channel it is in. Active channels can still be dynamic membership and too long to be usably browsable in the print dialog ui. Active channels still require that every broadcasting cups server on the network be correctly configured to mean anything. On large de-centralized networks... clients can not depend on any broadcasting service to be correctly configured.
We have had the local intranet with several thousand machines connected brought to its knees more than once by a cups server broadcasting its printers at ~1ms intervals. Of course this is partly due to brain-dead network admins who have failed to segment the network in a sane manner.
And its absolutely worse on networks that merely tolerate linux installs but do not have centralized support for linux at all. Administrators for linux machines acting a clients for a service such as cups needs to have an easy way to say 'ignore that specific cups server at ip address W.X.Y.Z its clearly misconfigured and being run by as gentoo zealot who doesn't know how to tie their own shoes and since there is no way I can talk sense into them to reconfigure their cups I need to take local action and disable their cups ques from showing up on my systems to avoid my users acidently trying to use that moron's private printer'
Yup, no central policy is what makes our local machines see several dozen to hundreds of cups printer to choose from, without local action to limit what is browsed.
I should be able to 'register' selected printers individually and hide the rest. Active channels just complicate the problem by adding yet another piece of information that can be misconfigured on the broadcasting cups server my client computer has the misfortune to notice. The simpliest control on the client side.. is to be able to register individual ques or individual cups servers... and hide the rest from view until a new printer needs to be found.
Amen brother!
-jef"hostile de-centralized networks do exist....for services that broadcast.. local clients need to have tools that can be taught how to ignore rogue broadcasting servers"spaleta
Have been able to get such limits to work, but some good tools that made it easy and did not clobber hand-edits to config files would be much appreciated.
Phil
On Sun, 2005-09-01 at 15:09 -0500, Phil Schaffner wrote:
On Sun, 2005-01-09 at 13:36 -0500, Jeff Spaleta wrote:
On Sun, 09 Jan 2005 18:29:57 +0100, Kyrre Ness Sjobak kyrre@solution-forge.net wrote:
What if there was some kind of "chanel" system - i.e. you could join the "physics department" chanel, and only printers shared to this channel, would be seen.
This idea doesn't solve any of the problems I express if the broadcasting cups server gets to select for itself which channel it is in. Active channels can still be dynamic membership and too long to be usably browsable in the print dialog ui. Active channels still require that every broadcasting cups server on the network be correctly configured to mean anything. On large de-centralized networks... clients can not depend on any broadcasting service to be correctly configured.
We have had the local intranet with several thousand machines connected brought to its knees more than once by a cups server broadcasting its printers at ~1ms intervals. Of course this is partly due to brain-dead network admins who have failed to segment the network in a sane manner.
Use tcpdump to find it, then then have it shut down.
It is a good idea to segregate traffic between school rooms and departments. A Linksys router in each classroom would block the broadcast traffic from leaving the class room. If you can't live with NAT in each classroom the Lynksys router can be configured to work as a normal router and not a NAT Firewall.
And its absolutely worse on networks that merely tolerate linux installs but do not have centralized support for linux at all. Administrators for linux machines acting a clients for a service such as cups needs to have an easy way to say 'ignore that specific cups server at ip address W.X.Y.Z its clearly misconfigured and being run by as gentoo zealot who doesn't know how to tie their own shoes and since there is no way I can talk sense into them to reconfigure their cups I need to take local action and disable their cups ques from showing up on my systems to avoid my users acidently trying to use that moron's private printer'
Yup, no central policy is what makes our local machines see several dozen to hundreds of cups printer to choose from, without local action to limit what is browsed.
Again if the traffic is segregated you won't see them. But you should also campaign for a good policy. If your driven completely mad, you could print off H4x0r messages on the printer to "scare" the troglodytes into getting there systems fixed {you might even put up a business card on the notice board ahead of time, and make some spare cash fixing the H4x0r3d machines}.
I should be able to 'register' selected printers individually and hide the rest. Active channels just complicate the problem by adding yet another piece of information that can be misconfigured on the broadcasting cups server my client computer has the misfortune to notice. The simpliest control on the client side.. is to be able to register individual ques or individual cups servers... and hide the rest from view until a new printer needs to be found.
Amen brother!
-jef"hostile de-centralized networks do exist....for services that broadcast.. local clients need to have tools that can be taught how to ignore rogue broadcasting servers"spaleta
Have been able to get such limits to work, but some good tools that made it easy and did not clobber hand-edits to config files would be much appreciated.
Phil
On Fri, Jan 07, 2005 at 09:28:18AM -0500, gslink wrote:
FC3 (I need a more stable system than Rawhide) has about the correct printing detection. What happens if you have several hundred printers on a network. You do not want detection as these are likely to be light duty, private printers.
Why would private printers be being broadcast in the first place?
Currently, CUPS publishes those printers that are marked shared queue and these are picked up by all machines on the network. This is fine but searching for and publishing printers that just have a lan address is wrong. On a large lan this could take hours and result in a long printer listing.
I'm not quite sure what behaviour you are seeing that you think is incorrect. Could you be a bit more specific please?
Tim. */
Tim Waugh wrote:
On Fri, Jan 07, 2005 at 09:28:18AM -0500, gslink wrote:
FC3 (I need a more stable system than Rawhide) has about the correct printing detection. What happens if you have several hundred printers on a network. You do not want detection as these are likely to be light duty, private printers.
Why would private printers be being broadcast in the first place?
Currently, CUPS publishes those printers that are marked shared queue and these are picked up by all machines on the network. This is fine but searching for and publishing printers that just have a lan address is wrong. On a large lan this could take hours and result in a long printer listing.
I'm not quite sure what behaviour you are seeing that you think is incorrect. Could you be a bit more specific please?
Tim. */
I see nothing that I think needs to be changed. In replying to a request to change how printers are picked up I merely point out that CUPS allows connection in many ways. Only those printers where specific action has been taken should be picked up without intervention. I know of an installation that has several hundred printers that are directly lan connected. These printers use JetDirect. Others use Novell, or Unix. In most cases you do not want these printers to be public but they are. You don't want Linux to search for them. CUPS finds public printers now but only those that are declared public by CUPS. I believe the whole business should be left the way it is. Before someone asks for it, you can share printers over a lan without implementing any other kind of lan connection.
On Fri, 2005-07-01 at 11:08 -0500, gslink wrote:
Tim Waugh wrote:
On Fri, Jan 07, 2005 at 09:28:18AM -0500, gslink wrote:
FC3 (I need a more stable system than Rawhide) has about the correct printing detection. What happens if you have several hundred printers on a network. You do not want detection as these are likely to be light duty, private printers.
Why would private printers be being broadcast in the first place?
Currently, CUPS publishes those printers that are marked shared queue and these are picked up by all machines on the network. This is fine but searching for and publishing printers that just have a lan address is wrong. On a large lan this could take hours and result in a long printer listing.
I'm not quite sure what behaviour you are seeing that you think is incorrect. Could you be a bit more specific please?
Tim. */
I see nothing that I think needs to be changed. In replying to a request to change how printers are picked up I merely point out that CUPS allows connection in many ways. Only those printers where specific action has been taken should be picked up without intervention. I know of an installation that has several hundred printers that are directly lan connected. These printers use JetDirect. Others use Novell, or
That is the Network administrators fault, not Linux or FC3.
Unix. In most cases you do not want these printers to be public but they are. You don't want Linux to search for them. CUPS finds public
If the network was designed properly, then yes I would.
printers now but only those that are declared public by CUPS. I believe the whole business should be left the way it is. Before someone asks for it, you can share printers over a lan without implementing any other kind of lan connection.
Windows, Appletalk/Ethertalk, Jetdirect and Novell sharing systems are "chatty" and should be avoided in large numbers on a network segment. These protocols use IP,IPX,DDP and/or Ethernet broadcasting to announce themselves on a regular basis. I have seen situations where networked printers and fax machines have rendered networks useless due to there constant "bleating".
If possible a static IP address and only LPR should be configured on network printers. If they need to be shared on other protocols then they should be setup to be shared from a file or print server and there should only be one file server and or print server per work-group.
Segregating work-groups helps to keep the broadcast traffic down and improves network efficiency.
I have worked on many different kinds of networks using different topologies and protocols for over 20 years now. For the past 9 years I have maintained a very large group of networks. Good network design requires a lot of hard work to setup, and is not plug and play. For small segregated networks plug and play is fine and works well, but for medium to large networks plug and play will cause you more trouble than it would take to just take time to set things up properly the first time. Eight years ago I setup a Linux machine to act as a file and print server for all our Apple, Windows and Unix workstations and all our Unix and new Linux Servers. It was difficult to setup at the time, but extended the life of our local 10b2 LAN. Of course now it's all 100bT, 1000bT and Fibre but we still only need one file and print server.
Proper network design can simplify your network and improve it's performance.
On Fri, 7 Jan 2005 15:35:16 +0000, Tim Waugh twaugh@redhat.com wrote:
Why would private printers be being broadcast in the first place?
Simple answer... misconfiguration by the person admining that box.
On a network tightly controlled by an IT department that actually employs staff to support linux installs.. there is a clear place to go to get that misconfiguration corrected... IT can help you sort it out and browbeat the person misconfiguring their cups server.
But in networks where linux is merely tolerated so long as the linux workstation does not impact the windows clients IT does support, figuring out whom to talk to about reconfiguring the misconfigured private printer is a chore since system-config-printer doesn't give me any information to figure out which printer server is serving up the que i shouldn't be seeing. I can't walk over to the IT helpdesk on-site and complain about someone's misconfigured cups printer, the IT department does not touch any linux workstation install issues.
And this gets even more complicated as the network becomes less and less centralized and more and more open.... educational nets with lots of student machines... even if you could track down the admin of a particular broadcasting print server convincing them to see reason and change their configs so you don't see their printer on your box could be a problem, with no network policy to support your request.
The question becomes... how important is it for the service detection tools to accomedate poorly managed servers that are beyond the control of the admin of the client machine? On large de-centralized networks.. like the ones I'm on at work... its somewhat important to be able to limit on the client which cups servers im pulling printers from lto be usable at all. Just as its useful for the service configuration tools to be able to ALLOW/DENY client access based on ip address.. i think its equally useful for clients to allow/deny browsing of broadcasting print servers based ip address of the print server.
-jef
-
gslink -
Guy Fraser -
Jef Spaleta -
Kyrre Ness Sjobak -
Phil Schaffner -
Tim Waugh