[Samba] Print limiting

[John H Terpstra]

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 <Joel at HammersHome.com>
> > To: Vasco Macaringue <macaring at nambu.uem.mz>, samba at lists.samba.org
> > 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: jht at samba.org