m086414@uunet.uu.net (Fred Comins) (02/17/90)
We have many printers and are getting another 45 laser jets. The problem is that all users want to be able to get to any of the printers. I'm looking for advice on the easiest way to keep this managed. Currently we were planning to use rdist with 1 master printcap with an entrie for every printer. Any better ideas?? Do I have to have a spool directory for each?? thanks
wargaski@acns.nwu.edu (Robert E. Wargaski Jr.) (02/19/90)
In X-Sun-Spots-Digest: Volume 9, Issue 50, message 2, Fred Comins writes: >We have many printers and are getting another 45 laser jets. The problem >is that all users want to be able to get to any of the printers. I'm >looking for advice on the easiest way to keep this managed. Currently we >were planning to use rdist with 1 master printcap with an entrie for every >printer. Any better ideas?? Do I have to have a spool directory for >each?? thanks I have read the introductory document for the Palladium Printing System from MIT's Project Athena; it sounds like they have the best approach to managing a large printing environment. I wish I could offer more practical advice, but we have not yet built the programs it requires (e.g. Kerberos, Zephyr, Hesiod, if recall serves me correctly). At least it is an alternative you can check out. Robert E. Wargaski Jr. | This is stupid. -- Vila wargaski@acns.nwu.edu | When did that ever stop us. -- Avon NU Distributed Systems Support | . . . #include <disclaimer.h> . . .
bob@uunet.uu.net (Bob Gregory) (02/26/90)
In article <5067@brazos.Rice.edu> pwa-b!m086414 (Fred Comins) writes: >X-Sun-Spots-Digest: Volume 9, Issue 50, message 2 > >We have many printers and are getting another 45 laser jets. The problem >is that all users want to be able to get to any of the printers. I'm >looking for advice on the easiest way to keep this managed. Currently we >were planning to use rdist with 1 master printcap with an entry for every >printer. Any better ideas? Do I have to have a spool directory for each? I tried to respond to the sender, but mail bounced, and meanwhile I've seen no response posted. Although the solution described here is not especially Sun-specific, other Sun sites with central administration of a number of similarly configured systems may find this useful. We have ~40 printers on ~20 Suns (so far). We also need to allow promiscuous printing. Deciding which printers need access from which hosts is usually more trouble than it's worth. We keep a "master" directory on a server which maintains all our printcaps. You do have to create separate spooling directories for each printer, so this directory has a sub-directory which is a "master" copy of (virgin) /{usr|var}/spool/lpd. Bad owner/modes on the spooling directory is a common mistake, so a script creates new directories there with the right modes and ownership, and this is propagated by rdist(1) along with the printcaps. If the modes get munged later, rdist will gripe about the mismatch. This has cured chronic "broken" spoolers (and found a few "fixed" with mode 777). Our README from this directory: This tree maintains /etc/printcap and the lpd(8) spooling directories across the network. printcaps for host machines of interest are the files [a-z]* in this directory. Scripts, Distfiles, or Subdirectories (e.g. Lpd) are by convention MixedCase. corollary: echo [a-z]* shows machines which may be considered. (remove editor backups or expect grumbles). to add a new host touch newhost or if it has a meaningful printcap rcp newhost:/etc/printcap ./newhost printcap files may have a host-specific part at the beginning followed by the common part. the host-specific part is required for the machine which actually spools to the printer. the common part makes printers known to other hosts for remote spooling. Adding a new printer needs a new entry in the printcap file of the host which has the printer attached. The lpr(1), etc. ignore later duplicate printcap entries, so the host-specific stuff is at the beginning of the file. Changes after the header of the Common file will be lost. Entries in Common should be created with the :rp: capability (keep all aliases the same, please). Common - defines all printers as remote. Alter this file when adding or removing printers, or changing aliases. Edit - integrate Common into all [ or a few ] printcap files. Usage: Edit [ host ... ] Makedir - create new spooling directories under Lpd to be propagated with rdist(1) via Install Usage: Makedir newlpdir [ newlpdir ... ] Install - propagate printcap and spooling directories to all [ or a few ] hosts. (hosts up? try rup(1)) Usage: Install [ host ... ] --------------- Install ------------- #!/bin/csh -f cd /usr/rdist/printcap # or wherever we are... if $#argv > 1 then set hosts = ( $* ) else set hosts = ( [a-z]* ) endif foreach host ( $hosts ) rdist -f Distfile.install -d HOST=$host -d FILE=$cwd/$host ### end rdist -f Distfile.lpd -d HOSTS="($hosts)" ------------- Edit ------------- #!/bin/csh -f cd /usr/rdist/printcap # or wherever we are... if $#argv > 1 then set hosts = ( $* ) else set hosts = ( [a-z]* ) endif foreach host ( $hosts ) awk '/common printcap/ { exit } { print }' $host > /tmp/Edit.$$ cat /tmp/Edit.$$ Common > $host end rm -f /tmp/Edit.$$ ----- Common looks something like this ----- # common printcap (don't mess with this line) # lp_mrf|mrf|Master Reference Files matrix:\ :lp=:rm=orb:rp=mrf:sd=/usr/spool/lpd/mrf:lf=/usr/adm/lpderrs: lp_lib|lib|Library Laser:\ :lp=:rm=nova:rp=lib:sd=/usr/spool/lpd/lib:lf=/usr/adm/lpderrs: ...etc... ------------- Makedir ------------ #!/bin/csh -f cd /usr/rdist/printcap/Lpd # master spooling directory foreach nudir ( $* ) if ( -d $nudir ) then echo "$nudir already exists!" else mkdir $nudir endif chown daemon.daemon $nudir && chmod 770 $nudir ls -ldg $nudir end ---------------- Distfiles called by Install --------------- Distfile.install: ${FILE} -> ${HOST} install /etc/printcap ; # optional -y , see note below Distfile.lpd: /usr/rdist/printcap/Lpd -> ${HOSTS} install /usr/spool/lpd ; NOTE: if local editing is permitted on the remotes, consider the -y flag to rdist(1), and run Install both before and after editing. Have also used the above technique for administering various other "local" files, when there is enough in common, or interrelationship, to warrant it. We usually do /etc/fstab this way. Changes to exported filesystems are more frequent than local ones, and always affect several systems (servers have clients). Most of the /etc/passwd files are identical (we use YP), and it's handy to change the root password everywhere at once. I believe this should scale well to larger networks with similar needs for centralized maintenance.
papowell@vlsi.cs.umn.edu (Patrick Powell) (03/13/90)
In article <5067@brazos.Rice.edu> pwa-b!m086414@uunet.uu.net (Fred Comins) writes: >X-Sun-Spots-Digest: Volume 9, Issue 50, message 2 > >We have many printers and are getting another 45 laser jets. The problem >is that all users want to be able to get to any of the printers. I'm >looking for advice on the easiest way to keep this managed. Currently we >were planning to use rdist with 1 master printcap with an entrie for every >printer. Any better ideas?? Do I have to have a spool directory for >each?? thanks The PLP (Public Line Printer) available from vlsi.cs.umn.edu using anonyumous ftp in pub/PLP.<release>.tar.Z has been updated to use the following technique: It has a list of printcap files it checks, starting with /usr/spool/lpd/..../printcap.<hostname>, /usr/spool/lpd/..../printcap, /usr/etc/printcap, /etc/printcap. It searches for the FIRST printcap file with an entry for the named printer. (This is available in version PLP.5Mar90.tar.Z) This allows you to 1. Create a printcap file just for a host (printcap.<hostname>) that holds the local printer information. 2. have a globally available printcap (/usr/spool/lpd/.../printcap, usr/etc/printcap, /etc/printcap) that holds global information, such as "remote printer, send to hacks.cs.berkeley.edu" types of entries. WARNING WARNING WARNING: PLP tried to use the lockf (lock daemon) to avoid problems with locking, etc. THE LOCK DAEMON as supplied by SUN DOES NOT WORK. and will hang/crash your systems with monotonous regularity. A rewrite of PLP is underway to use a new scheme that will avoid all the sillyness of having individual spool directories, etc. Patrick POWELL Prof. Patrick Powell, Dept. Computer Science, EECS 4-192, University of Minnesota, Minneapolis, MN 55455 (612)625-3543/625-4002