are there any plans for this ?

[christoph beyer]

hmm,

yes that was my first idea but a lot of applications don't run well with 600 printer queues. The drop down lists in applications are not programmed to give so many queues. Also I came across some apps which tend to query the available print queues before starting which is a killer too of course...

Are there any mechanisms to prevent this ?

cheers
christoph


> If you dont mind having a list with 600 printers, you could put a line 'Servername x.y.z.w' in /etc/cups/client.conf on the clients. This will make the clients print directly to the server, and not use their local cupsd.
>
> Why do you worry about putting all the printer queues on one server?
> If the server has to do a lot of ripping the jobs, then it will be a problem, but that part can be offloaded to other server(s)
> Samba uses about 20 MB per process, but not much CPU.
>
> Working example from real life:
> Dell 2950, 4*2 GHz, 16 GB RAM.
> cups 1.3
> 500 queues, all PostScript
> 800 samba connections
> some hundred IPP connections
> all incoming jobs authenticated with Kerberos
> up to 15000 jobs a day
> PyKota accounting system
> load average on a busy day 2
>   cupsd load  0.2
>   samba load  1
>   PyKota load 0.5
>
>
> //Bse
>
>
> >
> > > On Jan 4, 2010, at 3:11 AM, christoph beyer wrote:
> > > > Hi,
> > > >=20
> > > > sorry to bother you on the development list, I just would like to know =
> > > if there are any plans to implement this in the future:
> > > >=20
> > > > In my environment I have 600+ printerqueues on a campus with ~4.000 =
> > > users, obviously I can not put all these queues on one cupsserver,
> > >
> > > Obviously because???  We have users with 10,000 print queues and as many =
> > > users...  Combine this with allowed user/group lists and you can very =
> > > easily have automatically-available printers with users only seeing the =
> > > queues they have access to.  The main thing is that you'll need to have =
> > > network user accounts, otherwise the user/group mappings will be =
> > > impossible to manage.
> > >
> > > Also see below.
> > >
> > > > ...
> > > > Though most of my users just use 3 to 6 printers in there building and =
> > > maybe a plotting machine or a virtual log queue. Best solution for them =
> > > would be the windows-like approach to browse the printers on the server =
> > > and make an individual selection by clicking on the queuenames. =
> > > Unfortunately if you add a single printer from a remote cups server the =
> > > printer type information and queue presettings are not transfered to the =
> > > client instead the user is bothered with the usual questions (what kind =
> > > of printer and so on) which is for most users not acceptable.
> > > >=20
> > > > Are there any plans to change this in the future and does it sound =
> > > like a reasonable feature-request ???
> > >
> > > OK, so this is actually supportable today using Bonjour - the CUPS =
> > > server advertises the available printers via Bonjour, and the user can =
> > > (on Mac OS X and Winodws, at least) select a printer to use without =
> > > specifying drivers.  We don't auto-add printers like we do for CUPS =
> > > browsing, so you avoid users seeing 600 print queues.
> > >
> > > ___________________________________________________
> > > Michael Sweet, Senior Printing System Engineer
> > >
> > >
> > >
> >
>