root / pykota / trunk / FAQ @ 1282

PyKota's FAQ :

  # $Id$
  
  * Is print accounting ever exact ?
  
    No. Print accounting is **never** exact, because it depends
    on external factors like the presence of paper in the printer,
    the quantity of remaining ink in the print cartridge, paper
    jams, etc... All these things are very difficult to account
    for correctly, and no print accounting package deals with
    these artefacts correctly in all situations.
    We are however confident that PyKota is one of the more
    exact print accounting software, because by default it
    asks the printers for how many pages they have really printed.
    
  * Can PyKota account for ink usage ?  
  
    No. Actually PyKota doesn't account for ink usage, but this
    may come in a future release. PyKota only accounts for pages
    printed and/or money spent.  If ink accounting is a necessity
    for you, PrintBill is recommended instead of PyKota. PrintBill
    allows you to bill differently per color, and to bill depending
    on the percent of the ink covered part of the pages.
    
  * What is a 'dumb printer' ?
  
    In PyKota, the term 'dumb printer' defines a printer which doesn't 
    understand PostScript AND doesn't have an internal page counter, AND 
    for which you don't know how to compute a job's size in number of 
    pages by analyzing its content. Any printer which is not a
    'dumb printer' according to the above definition is supported 
    with PyKota.

  * How can I make PyKota work with my non-postscript printer under 
    CUPS ?  
  
    From version 1.16alpha7, PyKota includes a CUPS backend which
    allows you to use any type of printer and any driver, provided
    your printer is not a 'dumb printer' (see above).
    
  * How can I use my 'dumb printer' with CUPS and PyKota.  
  
    The solution is to plug the pykota filter into the
    filtering chain when the print job is still in 
    PostScript format, before being converted to the
    dumb printer's native format. You can't use the
    cupspykota CUPS backend with 'dumb printers'.
    
    Here's how to do :
    
        - Disable raw mode by modifying *.convs and
          *.types files in /etc/cups, then restart
          CUPS.
          
        - If you print from Windows through Samba, 
          don't put '-o raw' in the print command 
          definition in smb.conf
          
        - Under Windows, use a PostScript driver  
          set to maximum compatibility mode.
          
        - Modify *.convs and *.types files to  
          insert the pykota filter into the
          filtering chain, as described
          here (url should be on a single line) :
          
          http://cgi.librelogiciel.com/pipermail/  ...
             ... pykota/attachments/20030721/753239b5/attachment.eml
          
          and restart CUPS.
          
  * I've got a great number of users. How can I automatically
    set an initial print quota for them on first print ?
    
    You have to define an external policy for unknown users,
    to automatically add them to the Print Quota database.
    The sample configuration file contains examples to do this.
    
  * How can I diagnose the problem when something goes wrong ?
  
    Put "LogLevel debug2" in cupsd.conf (usually in /etc/cups/).
    Then put "logger: system" and "debug: yes" in 
    /etc/pykota/pykota.conf.
    Finally restart CUPS.
    CUPS' error_log file will now contain many informations which
    will help diagnose your problem. Also your syslog's output for 
    the LPR facility (usually /var/log/lpr.log) will contain 
    PyKota's debug messages, notably all database related queries
    and their result, be your database PostgreSQL or OpenLDAP.
    With these two files the problem can usually be diagnosed within
    minutes. Send them to the mailing list and wait for an answer.
    
  * Some, not all, print jobs are never accounted for, why ?
  
    From version 1.16alpha7, you can now use the cupspykota
    CUPS backend, which ensures that all print jobs will be
    accounted for. The use of the old pykota filter is deprecated
    with CUPS. It remains the filter of choice for LPRng though,
    or when you absolutely need to support a 'dumb printer' (see
    definition above).
    
  * When printing from Windows, the jobs are never accounted for,
    but from *nix they are. Could you explain the reason for this ?
    
    First refer to the point above. If this doesn't solve your
    problem, try to set your print driver to PostScript mode
    and check the "maximum compatibility" box in its configuration,
    instead of "maximum speed". Often HP printers come with both
    a PCL and a PostScript driver under Windows. Don't install the 
    PCL one.
    
  * How can I share print quota between some printers only (not all) ?   
  
    To do this you have to put the printers into a printers group, and
    set quota on the printer group, instead of (or in addition to)
    the printers themselves.
    
  * What is a printer group ?
  
     A printer group is exactly like a normal printer, but is
     unknown by the printing system. You can use printer groups
     to share print quota between printers.
    
  * How can I create a printer group ?   
  
    Just use edpykota, like for normal printers.
 
  * How can I put a printer into a printer group ?
  
    Use the new -G|--pgroups command line option to edpykota
    You can put sereval printers into several printers groups
    in one command using the following syntax :
    
      $ edpykota --pgroups pg1[,pg2,pg3,...] --printers p1[,p2,p3,...]
        
    What is between square brackets is optional.    
    Both p1,p2 and pg1,pg2 can contain wildcards.
    
  * How quota checking and update is done with printer groups ?   
  
    Print accounting and quota checking is done for a printer and
    all the printers groups it belongs to, recursively.
    If quota is reached on ANY of these printers for the current user,
    printing is denied.

  * Is this feature robust ?
  
    It should be. However, beware of integrity problems. LDAP has no 
    sense of database integrity, and PostgreSQL constraints have not 
    yet been fully implemented. The code actually *tries* to forbid 
    circular printers groups, but if you create printer groups with
    another tool (e.g. psql or gq), then you are mostly on you 
    own to not create infinite loops.
    
  * My question isn't answered there, can you help ?  
  
    Sure. Ask your question to the mailing list. If this is a
    frequently asked question, or if your problem is on the contrary
    very specific, it will probably be added to this document.
    
    You can also ask questions by IRC :
    
        /server irc.freenode.net
        /join #pykota
        
Send any new questions to Jerome Alet - <alet@librelogiciel.com>