[cups.general] recommendations for best cups references for admins

[Tim Mooney]

All-

I'm looking for any and all recommendations on the best in-depth
references on CUPS for system administrators.  I'm relatively new to CUPS,
though I have a long history of running central print servers in a campus
environment.  We're currently using LPRng, and I have experience with its
predecessors (both PLP and the traditional BSD and SysV spooling systems).
Our print servers are all Linux-based (RHEL 5 currently, potentially RHEL
6 if it releases soon enough).  Our main print server uses GoPrint
(www.goprint.com) cost-recovery software + LPRng, and can receive
5000-10000 print jobs a day during busy parts of the semester.

Obviously it's going to take a while and a lot of experimentation to get
the same level of knowledge and comfort with CUPS as I currently have with
BSD-like spoolers (e.g. LPRng), but I'm looking for recommendations on
what to read to help jump-start that process.

For example, is Michael Sweet's CUPS book still accurate and relevant?
It's from nine years ago and some review comments on Amazon indicate that it's
slanted toward developers rather than system administrators, so I'm a
little hesitant to just pull the trigger and hope it meets my needs.  Is
an updated version of the book in the works?

Anyone have Ankur Shah's "CUPS Administrative Guide" and care to comment
on how up to date, useful, and relevant that is, especially in comparison
to other reference materials?

What other reference materials do people recommend?  Obviously I've
looked through the various sections of the FAQ, especially the HOW-TO
section, and the online documentation and man pages that come with CUPS,
but those tend to be narrowly focused or task-based.  I guess I'm looking
for something that's similar to the LPRng HOWTO -- both an overview of
all the pieces and how they fit together, as well as detailed information
on each of the pieces and how it works.

I'm certainly capable of going to the source code if needed, but I prefer
to do that to debug why something works the way it does or isn't working
as expected, rather than trying to understand the software as a whole.

Any and all recommendations appreciated,

Tim
-- 
Tim Mooney                                             Tim.Mooney at ndsu.edu
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, IACC Building                             701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164