Kurt, You input on this list is MOST appreciated. Thank you so much.
I added you past advice to the samba documentation and will do so again with this information. Contributions like this are a marvelous help. - John T. Samba-Team On Fri, 22 Nov 2002, Kurt Pfeifle wrote: > On Fri, Nov 22, 2002 at 11:44:31AM +0200, Vasco Macaringue wrote on Samba-Digest: > > > Message: 12 > > Date: Fri, 22 Nov 2002 07:18:34 -0500 > > From: Joel Hammer <[EMAIL PROTECTED]> > > To: Vasco Macaringue <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > > Subject: Re: [Samba] Print limiting > > > > I have never seen that feature discussed on this board. I may have missed it. > > It would be doubtful if samba could do what you want. Samba is a rather brain > > dead print server. All it does is: > > 1. Accepts a filtered print job from the client. > > 2. Invokes the server's printing command to print it. I don't think samba can > > tell how many pages are in the document. I suspect you will have to delve into > > the workings of your server's printing software to find a solution > > Joel > > The feature you want is dependent on the real print subsystem > you're using. Samba's part is always to receive the job files > from the clients (filtered *or* unfiltered) and hand it over > to this printing subsystem. > > Of course one could "hack" things with one's own scripts. > > But there is CUPS (Common Unix Printing System). CUPS supports "quotas". > Quotas can be based on sizes of jobs or on the number of pages or both, > and are spanning any time period you want. > > This is an example command how root would set a print quota in CUPS, > assuming an existing printer named "quotaprinter": > > lpadmin -p quotaprinter -o job-quota-period=604800 -o job-k-limit=1024 -o >job-page-limit=100 > > This would limit every single user to print 100 pages or 1024 KB of > data (whichever comes first) within the last 604.800 seconds ( = 1 week). > > For CUPS to count correctly, the printfile needs to pass the CUPS > "pstops" filter, otherwise it uses a "dummy" count of "1". (Some > printfiles don't pass it -- f.e. image files -- but then those are > mostly 1 page jobs anyway). This also means, proprietary drivers for > the target printer running on the client computers and CUPS/Samba > then spooling these files as "raw" (i.e. leaving them untouched, not > filtering them), will be counted as "1-pagers" too! > > You need to send PostScript from the clients (i.e. run a PostScript > driver there) for having the chance to get accounting done. If the > printer is a non-PostScript model, you need to let CUPS do the job to > convert the file to a print-ready format for the target printer. This > will be working for currently ~1.000 different printer models, see > > http://www.linuxprinting.org/printer_list.cgi > > Before CUPS-1.1.16 your only option was to use the Adobe PostScript > Driver on the Windows clients. The output of this driver was not always > passed thru the "pstops" filter on the CUPS/Samba side, and therefor was > not counted correctly (the reason is that it often --- depending on the > "PPD" being used --- did write a "PJL"-header in front of the real > PostScript which made CUPS to skip the pstops and go directy to > the "pstoraster" stage). > > From CUPS-1.1.16 onward you can use the "CUPS PostScript Driver > for Windows NT/2K/XP clients" (it is tagged in the download area of > http://www.cups.org/ as the "cups-samba-1.1.16.tar.gz" package). > It is *not* working for Win9x/ME clients. But it.... > > ...it guarantees to not write an PJL-header; > ...it guarantees to still read and support all PJL-options named > in the driver PPD with its own means; > ...it guarantees the file going thru the "pstops" filter on the > CUPS/Samba server; > ...it guarantees to page-count correctly the printfile... > > You can read more about the setup of this combination in the > manpage for "cupsaddsmb" (only present with CUPS installed, only > current with CUPS 1.1.16). > > These are the items CUPS logs in the "page_log" for every single > *page* of a job: > > * Printer name > * User name > * Job ID > * Time of printing > * the page number > * the number of copies > * a billing info string (optional) > > Here is an extract of my CUPS server's page_log file to illustrate > the format and included items: > > infotec_IS2027 kurt 40 [22/Nov/2002:13:18:03 +0100] 1 2 #marketing > infotec_IS2027 kurt 40 [22/Nov/2002:13:18:03 +0100] 2 2 #marketing > infotec_IS2027 kurt 40 [22/Nov/2002:13:18:03 +0100] 3 2 #marketing > infotec_IS2027 kurt 40 [22/Nov/2002:13:18:03 +0100] 4 2 #marketing > infotec_IS2027 kurt 40 [22/Nov/2002:13:18:03 +0100] 5 2 #marketing > infotec_IS2027 kurt 40 [22/Nov/2002:13:18:03 +0100] 6 2 #marketing > > This was Job ID "40", printed on "infotec_IS2027" by user "kurt", > a 6-page job printed in 2 copies and billed to "#marketing"... > > Which flaws or shortcomings are there? > > * the ones named above; > * CUPS really counts the job pages being *processsed in software* > (going thru the "RIP") rather than the physical sheets successfully > leaving the printing device -- if there is a jam while printing > the 5th sheet out of 1000 and the job is aborted by the printer, > the "page count" will still show the figure of 1000 for that > job; > * all quotas are the same for all users (no flexibility to > give the boss a higher quota than the clerk) > * no support for groups; > * no means to read out the current balance or "used-up" > number of current quota; > * a user having used up 99 sheets of 100 quota will still be > able to send and print a 1.000 sheet job; > * a user being denied a job because of a filled-up quota > doesn't get a meaningful error message from CUPS other than > "client-error-not-possible". > > But this is the best system out there currently. And there are > huge improvements under development: > > --> page counting will go into the "backends" (these talk directly > to the printer and will increase the count in sync with the > actual printing process -- a jam at the 5th sheet will lead > to a stop in the counting...) > > --> quotas will be handled more flexibly; > > --> probably there will be support for users to inquire their > "accounts" in advance; > > --> probably there will be support for some other tools around > this topic... > > Other than the current stage of the CUPS development, I don't > know any other ready-to-use tool which you could consider. > > I hope this clarifies the options. > > Cheers, > Kurt > > > On Fri, Nov 22, 2002 at 11:44:31AM +0200, Vasco Macaringue wrote: > > > >> Hi all > >> This is my first time writting to samba > >> > >> I'd like to get a quickly help in this: > >> Where can I find a program or how can I configure my samba server in order > >> to limit the number of pages to be printed by users. > >> > >> Best regards > >> > >> > >> > >> -- > >> To unsubscribe from this list go to the following URL and read the > >> instructions: http://lists.samba.org/mailman/listinfo/samba > > > > > > > > -- John H Terpstra Email: [EMAIL PROTECTED] -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
