$Id: printer_setup.txt,v 1.1 2004/01/22 19:27:41 jmates Exp $ How to setup Print Queue 1. Pick a queue name for the printer. Pick something logical. The current format is GROUP-ID, where GROUP is the group that the printer belongs to (admin, outreach, etc.), and ID represents a virtual location "office" or "lab," or in the case where people will have a printer of some kind in that location, a room name like "k355." Queue names for departmental printers lack the GROUP tag (e.g. "duplex"). Queue names are limited to DNS characters, so it's best to stick to a-z, -, and numbers, provided neither the numbers nor the hyphens come first in the name. Upper case is annoying, as you have to use the shift key. Don't go there. 2. Add a entry into the DNS tables for this new queuename, such that the printer appears as: QUEUENAME.p.example.org A typical forward DNS entry would look something like: duplex.p IN A 10.0.0.236 while the reverse would look like: 236 IN PTR duplex.p.example.org. Keeping printers under the .p subnet prevents namespace clashes that might occur between general hosts and printers. Printer names can only clash in error, as the queuename must be unique in the /etc/printcap file as well. And then restart the DNS server to make the changes take effect. Don't forget to update the serial number! 3. Add client/server entires into the departmental printcap files. Hacking the printcap files should be straightforward; on the client side simply copy a entry into the appropriate group section for this printer, and change the queue names (both for the name of the queue and it's name in the lp= field, which should be the same). For the server printcap file, find a similar model entry (the :ifhp=model=* line), copy and paste it, then adjust the four or so queue name entries that need to be adjusted. If the model is a new one, try looking in /etc/ifhp.conf for a similar entry that can be used for the printer in question. Failing that, you can either upgrade to the latest ifhp filters package (same site as LPRng), or figure out how to write your own /etc/ifhp.conf entry for the printer in question. Luckily, most common printers are already supported. :) Then, copy the new printcap files into /etc/printcap (or /usr/local/etc/printcap if they install LPRng wrong). On the client side, nothing will have to be done, as the printcap file is read with each lpr call; on the server, however, the following commands should be run to ensure that the various daemons involved pick up on the changes properly: # checkpc -f -V # only if you've just created a new queue # but it doesn't hurt otherwise # lpc reread all # tell running lpd daemon to reread printcap file And assuming that Samba is running on the print server as well (it should be, as it can reread the /etc/printcap for you, and setting up a Print NetBios server is easy): # /etc/rc.d/init.d/smb restart 4. Hack the DHCP/TFTP server to support the new printer The /etc/dhcpd.conf file will have to be changed on the DHCP server, as well as the addition of a TFTP boot file for the printer (assuming the printer supports TFTP boot config files!) Currently, all the printers are grouped together at the bottom of the /etc/dhcpd.conf file. Creating a new entry is simply a matter of copying the format of the other printers, and filling out similar values appropriate to the printer: # Comment describing what kind of printer/where for ref purposes host QUEUENAME { hardware ethernet SOME_LONG_STRING; fixed-address IP_ADDR; option option-144 "hpnp/QUEUENAME"; } The option-144 is for HP (and possibly other) printers to specify a TFTP file the printer will contact the DHCP server for; you should create this file before the DHCP server is restarted. The TFTP server files are located under /tftpboot: allow: 128.95.231.4 banner: 0 idle-timeout: 300 location: HSC K313 contact: CFM Group ipx/spx: 0 dlc/llc: 0 ethertalk: 1 set-community-name: print-fu authentication-trap: on ews-config: 0 telnet: 0 However, there are many different HP JetDirect cards, each of which supports some or more of the above options, so there's generally a restart-hack config loop until the printer stops sending messages like: Jan 19 15:09:10 pharm-lab.p.example.org printer: config file error line: 12 CF ERR - UNKNOWN KEYWORD "ews-config: 0" to syslog as it fails to parse it's config file. See the JetDirect manual on the printer in question for more details. The best idea is to find a machine of similar model, and copy that config file over for the new printer. The allow: line is important; it lists which hosts are allowed TCP access to the printer in question, and is essential if you want to properly setup a centralized printing service, as otherwise people can gum up the queues by simply printing directly to the printers. See the JetDirect docs for the uses/limitations of the allow: lines; I have yet to study the ramifications of setting an allow line on a printer and then the printer moving off to some other area! Once /etc/dhcpd.conf and the TFTP boot file is in place, restart the DHCP server to pick up on the changes. The server side of things should be ready to go. 5. Check the printer config The final step is to visit the printer manually, and configure it to have everything but TCP/IP turned off (AppleTalk on as well if it's supporting Mac OS). Then, restart the printer, and check the syslog file to make sure there were no boot file errors. If not, try printing to the printer from unix/windows to make sure the other components (Samba, LPRng, etc.) are working properly. Conclusion This is a lot of extra initial work to get a printer up and running; however, there are long term benefits to this system assuming the various components (Samba/LPRng/DNS/DHCP/TFTP) are kept running properly, such as: * Easier printer upgrades (DHCP MAC entry and maybe ifhp model) * Easy job control on single central machine (with lpc) * Great potential for automatic generation of these various config files in the future due to structured layout (e.g. from LDAP) * Makes job accounting possible * Clients see a consistent interface (LPRng on all the unix hosts, \\Print\QUEUENAME under Microsoft OS's). The major disadvantages are: * Print server going down a Bad Thing, as nobody can print. Solution is to use CNAME as print server, and have "hot spare" print server machines waiting in the wings. Update DNS CNAME, printing works again. Assumes you've planned ahead with the allow: lines on the printers, or just hijack the same IP. * Someone has to administer the system (hey, job security...) * Lots of different software parts relyed on, instead of some massive package that "does it all." * Some folks don't like centralized services on their printers, and will resist/deny efforts to implement this.