Note: please don't spam any of the e-mail addresses which you see here. Follow this link if you want some addresses to misuse.
From: Tyler Saxton <tls@trinity.unimelb.edu.au> Date: Thu, 15 Feb 2001 10:01:47 +1100 (EST) Subject: Re: PPR: 'Jake' mode & interface for PPR? (fwd) Hi, people. I haven't been reading from this mailing list for a while, but someone forwarded this message onto me, knowing I'd have a particular interest in it... > ---------- Forwarded message ---------- > Date: Wed, 14 Feb 2001 10:18:21 +0000 (GMT) > From: "Espen H. Koht" <ehk20@cus.cam.ac.uk> > Reply-To: ppr-list@mail.trincoll.edu > To: ppr-list@mail.trincoll.edu > Subject: PPR: 'Jake' mode & interface for PPR? > > > Somewhere in the middle of my list of useful things to do around here, I > have to see if PPR can be set up to get a few printers to work in a > 'Jake'-like mode. Before I go any further, has anyone else done something > like this? > Yes. Actually, I substantially re-wrote "Jake" a few years ago to work with ppr. The client was completely re-written, except for some of the screen display code. The version of jake I worked with was the curses/C version -- I believe there was another version which came out a bit later in an interpreted language. (But we already had the C version working, so I didn't really bother looking at that much.) The main site it's used on is Trinity College (the University of Melbourne one in Australia) and it's also at a nearby college. It's been working nicely for a few years, and accounted for, ummm... 276405 pages so far. We started out wanting a print accounting system to use with lpr/lpd, and found "jake". We run linux servers, which jake wasn't originally written for. It took a while to get the code to compile with ANSI C, and stop seg faulting all the time, but we got Jake working with lpr/lpd. Netatalk and Samba took care of connections from Apples and Windows PCs. However, we found that lpd's connection to the printer is not 8-bit clean, and some binary jobs were causing the printer to spew out garbage continually until someone turned it off! So, we found "ppr" as an alternative spooling system, and discovered that the appletalk interface of ppr would print the jobs without any trouble. (At the time, the TCP/IP interface did the same as lpd, but I believe that was corrected.) So, we switched to ppr, and I hacked at the jake client to do "ppop release" commands, etc. to manage the jobs. But we still got the odd segmentation fault in the jake client, and I thought it'd be nice to be able to use PPR's features for manipulating jobs -- so I re-wrote jake, except for some of the curses screen display stuff, to work with ppr seamlessly. Users can do some ppr-ish things like change the number of copies, number of pages per sheet, etc. The original jake counts up the number of pages by sending a PCL command to the printer to ask for its lifetime page count, before and after the job. With ppr, the client can fall back on ppr's estimation of pages if the PCL stuff doesn't work, or not attempt the PCL stuff at all. > [snip - details of how original jake works] > Since PPR is by far our printer spooler of choice, I'm basically looking > into whether it can be set up in a similar way. > > For the basic mechanism I suppose you could either force jobs to be > submitted with --hold and then have them released to start printing, or > have a permanently stopped print queue from which jobs can be moved to a > live queue to start printing. I use the hold/release mechanism. I thought about changing to a system of moving from one queue to another, but I decided that since it wasn't broken, I wouldn't mess with it. :-) > I see the latter mechanism as part of a > potential future development, where a user only needs to decide at the > point he reaches a printer that it should come out on that specific > device. ... However, I do handle this situation. On the server, there is a login for each printer, which runs only the jake client in its shell. We have at least two printers on our main site, "vesuvius" and "fuji". (I guess the volcano theme came from their tendency to erupt.) Each client can be configured to watch any number of queues. Say you print to the "vesuvius" queue, and go to the "fuji" client to authenticate -- the client will move the vesuvius job to the fuji queue, so it comes out on the fuji printer. > Initially, I'm looking at a single queue and printer scenario and > I'm not terribly worried about authentication at the time of release (for > the moment). > At the moment, all user accounts are in the shadow password file on the server which the clients run on. (The server also runs samba as an NT domain controller for Windows authentication, and a login client for the Mac whose name escapes me. MacLogin or something, shareware, I think.) So, it accepts the password from the user, encrypts it, and checks to see if it matches the encrypted version of the password. The guys who work for the college are developing some LDAP system, and when the time comes, we'll just replace one function of the code with something appropriate. > Any suggestions or comments? I love open source software. I don't know what we would have done without ppr and the original version of jake. I never quite found the time to put together a proper, public release of this stuff before I got a real job. If anyone's interested, they should contact me directly about it. Tyler.