This information was originally written by Daniel in the Tiki-Wiki:

WolfPrint

The WolfPrint? system consists of a number of pieces pulled together to form a somewhat complex system.

Quota

The entire quota database is contained in lpquota_db on the UNITY Sybase server. (the LPQUOTA Sybase server is just a reference to the UNITY server, from back when they were different servers) All of the scripts to recreate the tables and store procedures are stored at /afs/unity/project/ccctools/dbs/lpquota_db, laid out in fairly the same format as the other databases on UNITY. (the scripts that is) A backup of the quota database is made every night to /afs/unity/sadm/archive/lpquota. This is partially to have an easily restorable backup, but also for analysis purposes. The database itself is nothing but a set of tables of user data, user logs, group data, group logs, and other assorted pieces used in various places. Their uses should be described in their creation scripts. If they aren't described there, most likely you'll find them either used at the print.ncsu.edu web site, the print.ncsu.edu server installs (lprng servers), the various cron jobs run on the various cron pool servers, or sysnews tools.

The meat of the print quota system is in the stored procedures. Wherever possible, I tried to call stored procedures to get work done so that it would be easily changable on the backend in the future. For example, generally, there's a one to one relationship between a user and their quota account. However, the welcome id system accounts are "tied" to a WolfPrint? account and, as a result, follow different rules. When someone requests the quota, or uses the quota, of a "tied" account, the stored procedures compensate for that and return information about the group they're tied to.

So what about groups? Groups are jointly used quota "pots" that multiple people are allowed to print from. It's fairly hard to print through said groups unfortunately, because only the unix command line really supports picking your group. (lpr -R#### myjob.ps) The print-a-file web interface also supports group handling, but it's not really meant to be a primary printing interface. With normal membership to groups, you -may- print using the group account if you like. When you are -tied- to a group, you end up not having a choice. All of your printing will go through the group.

Quota is added by walking up to a WolfCopy representative in the library and giving them hard cash, or by using the online storefront at print.ncsu.edu.

The Storefront

The storefront used to be tied to Yahoo's small business product. Recently, we switched to Nelnet, or infiNet, depending on whether they've officially switched their name over yet or not. The old solution used to handle everything on the backend of Yahoo's servers and "send" us transactions on the fly by contacting scripts in yahoo-bin on sysnews. Normally this was immediate but sometimes there was slowdown. More importantly, the yahoo-bin directory had to be locked down to only Yahoo's servers (for hopefully obvious reasons, not letting people fake it), and often Yahoo would change their servers out from under us.

With the move to Nelnet, we now go through a little conduit that ETSS wrote. There's a shared key between us and ETSS, and then there's another shared key between ETSS and Nelnet. The ETSS front end provides an easy mechnanism to coordinate all of this across campus. The move to Nelnet was mostly spearheaded to get the entire campus using the same system for online payments, and therefore get bulk discounts and such.

We are somewhat unique in our use of online payments in that we require realtime transactions. You pay, you get your quota, immediately. No checks are accepted because we can't verify that in real time. Most others take payments and process them via some backend mechanism. Part of the whole transaction involves going from print.ncsu.edu, through ETSS, through Nelnet, through ETSS (invisibly), back to print.ncsu.edu. That last step is what officially gives them their quota. What happens if their browser crashes or something along the way? If they haven't entered their credit card info, nothing. If they have and the charge went through, there's a job that runs every morning that looks at the end of day files we get from Nelnet and gives folk their money that might have been missed. This is considered a failsafe and hopefully isn't needed often.

We also were the first to embrace this new interface, so it's unclear how things will proceed, if there are changes that will need to be made, etc.

Keeping Things In Sync

Generally every transaction in wolfprint land is proceeded with a call to lp_ndssync. This stored procedure simply inserts a username into a table in the lpquota database (aptly named ndssync), which a job reads routinely to process usernames, read in their current quota from the lpquota database, and set NDS to have the same quota. Visa versa, there are jobs that run under the Windows (NDS?) servers to watch the PCounter logs and sync up jobs printed there with the unix lpquota database. Generally we try to sync anytime anything occurs. It doesn't hurt to cause the sync so we consider it an easy thing to do. Looking users up in user lookup even causes a sync.

Print Servers

The print servers are a mixed batch. The primary print.ncsu.edu servers are run on a collection of unix print servers, whereas the Windows jobs go to NDPS servers. Unix and Mac all print to the unix servers.

Unix (and Mac)

The unix print servers run Linux and LPRng. LPRng does most of the dirty work accepting jobs over LPR, requiring Kerberos if the print queue is charged, and interacting with the filters underneath it and making connections to the printers themselves. ifhp sits under LPRng and does the meat of the work ... converting jobs to postscript if need be and communicating with the printer to get page counts before and after the job so we can see how many pages were printed. ifhp.conf is what you might refer to as the "driver" of the whole thing. It more or less tells ifhp how to talk to the printer. Models come from ifhp.conf. All of the config files are auto-generated from the printer database (described later) and/or /afs/bp/adm/printing/etc, for 'static' type config files (like ifhp.conf and header/footer 'templates' for auto-generated config files) Local config files are updating on the print servers and LPRng is instructed to reread it's config if there were any changes.

Plotter/large format jobs are handled via a different mechanism than regular jobs. Regular jobs involve a page count request to the printer, the job is sent, we wait for an end of job, and then another page count is requested. You can generally see the results of this interaction in the spool directory (/local/lprng/spool/QUEUE) in the acct file. The first page count is subtracted from the last and we get how many pages are printed. Large format jobs don't go by "page counts". In fact their printers don't even return page counts. Instead, we render the job in memory upon receiving it, determine how many square feet the job is, hold onto that number, and after the job is 'finished', we charge the user that amount. It's a much larger load on the server, but it does the trick. (and the servers barely notice it unless a ton of it is going on)

Generally you won't need the local commands for the print servers. All of the functionality is generally available via the Printer Status Page tool. I'll go into that more later. One thing to make note of is that we have multiple print servers and one print.ncsu.edu IP address. We send all requests to print.ncsu.edu through the keepalived service. Requests are routed to a specific server and load balancing is achieved. However, that means that when you do a standard lpq, you end up only talking to one of the servers and don't get a clear picture of what's going on. That's why we wrote wrapper scripts in /afs/bp/contrib/lprng for lpq, lprm, etc to hide that from the end user. Those scripts talk to all of the print servers and get the list of jobs and such collected into one output. You may notice that the real job id might be 123, but the provided job id is 02123, which means that it's on uni02ps and is job id 123. The big caveat here is that there's no real way to tell what order jobs will come out. Likewise, if someone tends to print a lot that's expected to come out in a specific order, they may need to be pointed at a particular print server. This is "sort of" not an issue because we use keepalived's persistence to retain a bias towards the print server you just printed to, so all should come out of the same print server in the "proper" order.

Related Jobs

A number of jobs run related to the printing system. All of them should be found under the printing directory on the unprivileged cron server. Accounts are created via stored procedures in hes_db, making calls to procs in lpquota_db. The jobs should be pretty self-explanatory via comments or their names so I will not reexplain them here.

Printer Database

The printer database is stored on mysql02 in the status_db database. There are a number of tables preceded with printer_ that make up the database. All unix configs are generated from this information and should all be editable via management tools on Sysnews. However, there is one event that requires manual intervention for proper configuration. Load balanced queues are set up by editing the printer_database by hand and setting the loadbalanced field of all of the printers in question to the name of the load balanced queue. (typically just the first two parts of the name... if it's hlb-209-1 and hlb-209-2 that are being balanced, typically the queue is set to hlb-209) Beyond that, the tools to manage the database are under "Printing System" on Sysnews. Nagios uses the printer database to generate it's list of printers to monitor as well. Departments listed in the printer_realmdepts table are showed on sysnews.ncsu.edu's main page when they are down. printer_supported provides a mapping of ifhp.conf model names to "pretty" model names, and also provides a list of printers are know we support. Generally new printers have to be added here and ifhp.conf. printer_bldgids maps short building ids to full names. The short building id is pulled directly from facilities building abbreviation database. printer_addrtoprinter is used by print.ncsu.edu to attempt to detect if a user is coming from a unity lab and, if so, to display their active jobs from the Windows side on print.ncsu.edu. printer_servers is literally a list of unix print servers for use in various tools that need to know the list of print servers. printer_filters and printer_filters_default are used to store custom displays for the printer status page.

Sysnews Tools

There are quite a few tools available on Sysnews that tie into the printing system. The quota administration tool is primarily used by WolfCopy to add quota when folk walk up to them, or to look at a person's current quota balance and/or logs. It's very useful for debugging what users are complaining about. There's a group tool that allows owners of quota groups or WolfCopy staff to administer who is a member of a print quota group account. Most of the tools are self explanatory though. The printer status page is the big one. The printer status page taps into the printer database and nagios's database to display the status of all of the printers supported by WolfPrint?. When you click on a printer in question, a number of tools become available to try to determine what might be wrong with the printer. There's also queue management tools available. It's really best left to "play" with it and see what it can do.

Support

WolfCopy regular goes around to check the printers for functionality and paper restocking. The distributed support WolfCopy representative monitors the printer status page and submits remedy calls to WolfCopy when there are problems detected remotely, which WolfCopy uses to dispatch field techs to printers having problems. Sometimes we enlist the local support personnel to investigate the printers in their labs. Generally it's a gray area as to who exactly supports the network setup. Generally a printer is dropped off and a configuration page is delivered to the DS WolfCopy representative, who sets up the printer on our end and coordinates getting it set up with Windows. After that generally the lab staff is who plugs the printer's network cable in or does whatever is necessary to activate the port. We try to get as much of that stuff done ourselves though. We link between the lab admins and us is pretty crucial for tracking down issues.

Mailing Lists

admin+printing gets most of the output from printing jobs that run regularly. printsys@lists.ncsu.edu is where I generally communicate to the wolfprint admin customer base. (anyone who maintains printers in their labs generally)

The Web Interface (print.ncsu.edu)

The web interface, print.ncsu.edu, is focused on the end user. It tries to provide them with a "pretty" overview of their print quota account, what jobs are printing, easily accessible documentation, problem reporting forms, and the ability to purchase quota online. It's generally straightforward except for the print-a-file tool. It's provided mostly as a "last ditch attempt" for folk who can't seem to print via standard means. For example, a student might print to the sullivan lab from their room via this information and walk down to the lab to get their printout from the "good printer" downstairs. That said, while it says it supports PDFs, it has to convert them on the backend and ghostscript has to do that and it's not always all that good at it. We get a lot of complaints from that. There's another caveat about print-a-file... see below.

The scripts for print.ncsu.edu, and the index.php file, are maintained in subversion at https://svn.unity.ncsu.edu/svn/print/trunk/

The documentation and other relatively 'flat' info is located in /afs/unity.ncsu.edu/www/print

Weird Stuff

There's a lot of weird printing related stuff that comes about from time to time. I'm trying to document some of it here.

End of Job

The "End of Job" message that is watched for by ifhp on the unix print servers is a tad weird. If you ever actually watch the traffic, you'll often see -two- end of job messages. One is right, the other is wrong. The first one is generally a "I received the job and spooled it", the second is the -real- end of job. This weird behavior started only recently with HP printers. They used to behave better than that. Sometimes it's not something to worry about though. ifhp knows how to deal with it. However this is one of the big problems with other printer vendors that come about. Their printers throw end of job after spooling, not after the job is really done printing, so there's no way to get a good page count.

Cheating

There still exists the ability to wait for a job to be spooled to the printer, then remove it from the queue using lprm. That way you don't get charged but the job still comes out. There is, unfortunately, no easy way to get LPRng to handle this better because of the way it's designed.

Orientation

Every year all of the orientation students are given something like 24 cents to print out things for orientation. Terri Riley handles this.

Add Quota To My Students

Sometimes folk will come along and say they want to subsidize their students for an upcoming semester. Generally this is done by getting Jimmy Hennis's approval to do it, getting a list of user ids from the requestor and how much to add, performing the adds using a perl script or something to call the lp_increaseuser command on the sybase server for each user, calculating the total, and sending that to Jimmy to bill the requestor. It's rare for this to come up.

"Print to File"

Joe Flowers created some sort of print tool for CHASS that uses the print.ncsu.edu web print-a-file tool to print jobs. As of early 2009, several groups on campus are using this for their student printing. We can't easily change things about print-a-file without messing up his tool and causing problems for others.

Future Plans

The future plans were to move to an entirely CUPS based infrastructure, with Samba handling jobs coming from the Windows work to the unix print servers. All jobs would come to the same place and it should work out well. Just recently CUPS 1.3 was released with Kerberos support which is what we were waiting on. Also were going to move to blades. There were plans to pretty up print.ncsu.edu a little bit at some point as well.