stevec@sfu_cmpt.cs.sfu (09/18/87)
I don't know if this is the correct forum, but here goes
nothink.
We run a net of about 50 odd suns. Most have their own
/etc/printcap files, other symlink it to a some commonly
NFS-mounted directory.
Now the only reason this is necessary at all is that
printjob(), the workhorse in the lpd is to dumb to
check for itself if the "rm" entry refers to "me" or
some truly remote machine. If the "lp" entry is defined,
it just tries to write to the device named there.
So, I have made some trivial changes to the lpd, so that it
does the obvious check. (actually, by introducing a level of
indirection in the /etc/printcap files, the same thing can
be accomplished without modifying the source, at the cost of
a doubling in network traffic)
I am interested in seeing some discussion of the issues that
seem to arise from this.
1) How far should we go towards a more distributed environment.
2) What other places in the system are such needless host
dependencies built in?
3) your ideas here.
Steve Cumming
{backbone}ubc-vision!fornax!stevecroy@phri.UUCP (Roy Smith) (09/21/87)
In article <81900001@sfu_cmpt> stevec@sfu_cmpt.cs.sfu describes how some
of his 50-odd Suns have private /etc/printcaps, and some share a common
/etc/printcap via NFS, and the problems therein.
We took a different approach. We (actually I had little to do with
it; phri!nomi did all the hard work) hacked up lpr to use the Yellow Pages.
BTW, printcap seems like such a natural for YP that I'm really surprised
that Sun doesn't ship systems with it already set up. All of the lpr suite
of programs now know to look in the local /etc/printcap first to resolve a
printer name and then to query the YP. Thus, we list all our printers in
the YP and for each host which actually has a printer, we put an entry in
the local /etc/printcap for the printer. Most hosts don't have local
printers so they don't have /etc/printcaps at all (or zero-length ones) For
example, our YP has the following entry:
laser9|ps9: \
:lp=:rm=adenine:rp=laser9:\
:sd=/usr/spool/laser9:lf=/usr/spool/laser9/log:
but adenine's /etc/printcap looks like:
laser9|ps9:\
:lp=:rm=phri:rp=laser10:\
:sd=/usr/spool/laser9:\
:lf=/usr/spool/laser9/log:
#laser9|ps9|postscript|PostScript:\
# :lp=/dev/ttya:sd=/usr/spool/laser9:\
# :lf=/usr/spool/laser9/log:af=/usr/adm/laser9.acct:\
# :br#9600:rw:fc#0000374:fs#0000003:xc#0:xs#0040040:mx#0:sf:sb:\
# :if=/usr/local/lib/ps/psif:\
# :of=/usr/local/lib/ps/psof:gf=/usr/local/lib/ps/psgf:\
# :nf=/usr/local/lib/ps/psnf:tf=/usr/local/lib/ps/pstf:\
# :rf=/usr/local/lib/ps/psrf:vf=/usr/local/lib/ps/psvf:\
# :cf=/usr/local/lib/ps/pscf:df=/usr/local/lib/ps/psdf:
Actually, I happened to pick an example which is a bit more
interesting than I intended, but illustrates something worth talking about.
Usually, adenine's /etc/printcap is just the commented out entry. It just
so happens that laser9 is down for a few days right now so we're rerouting
jobs sent there to laser10, which is on host "phri".
It's not very efficient (the jobs get sent to adenine, which then
turns them around and ships them to phri), but it's only for a few days and
we're willing to put up with the extra network traffic for a while in
return for the administrative convenience. The efficient alternative would
have been to change the YP entry for laser9 to point to phri:laser10, but
then I would have had to change the local entry on adenine as well.
One minor wart in this approach. We use /etc/printcap on our
master YP server as the source for the YP printcap map. Since a machine
with a local printer needs a printcap entry for that printer different from
what's in the YP map, this only works as long as we don't have a printer on
our master YP server. If we ever do that, we'll have to switch over to
keeping the map source file someplace other than /etc/printcap.
Please do not construe my advocacy of YP in this situation to mean
that I think YP is any more than an ugly hack. The idea is nice, but the
implementation is disgusting. I've seen YP programs fail in all sorts of
strange and wonderful (and decidedly non-intuitive) ways. For example,
"getpwuid (getuid)" can fail (with errno set to all sorts of
non-informative things) if you don't have things set up properly.
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016mjr@osiris.UUCP (Marcus J. Ranum) (09/22/87)
In article <2902@phri.UUCP>, roy@phri.UUCP (Roy Smith) writes: > In article <81900001@sfu_cmpt> stevec@sfu_cmpt.cs.sfu describes how some > of his 50-odd Suns have private /etc/printcaps, and some share a common > /etc/printcap via NFS, and the problems therein. We used to use rdist(ucd) at my last site. I had a crontab entry that called rdist with a distfile containing a whole bunch of files, incl. printcap, hosts, .rhosts, hosts.equiv, etc, etc, etc. --mjr(); -- If they think you're crude, go technical; if they think you're technical, go crude. I'm a very technical boy. So I get as crude as possible. These days, though, you have to be pretty technical before you can even aspire to crudeness... -Johnny Mnemonic
treese@athena.mit.edu (Win Treese) (09/30/87)
In article <2902@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >In article <81900001@sfu_cmpt> stevec@sfu_cmpt.cs.sfu describes how some >of his 50-odd Suns have private /etc/printcaps, and some share a common >/etc/printcap via NFS, and the problems therein. > > We took a different approach. We (actually I had little to do with >it; phri!nomi did all the hard work) hacked up lpr to use the Yellow Pages. [...stuff deleted...] >Roy Smith, {allegra,cmcl2,philabs}!phri!roy At Project Athena, we have built a general-purpose nameserver (called "Hesiod") on top of the BIND nameserver from 4.3BSD. It is currently in use for a large number of things, including information about /etc/printcap. Because the underlying system is BIND, it also behaves better than Yellow Pages in larger environments (e.g, ~400 workstations scattered all over campus). In particular, YP seems to have severe problems working across gateways between subnetworks. Win Treese MIT Project Athena Internet: treese@athena.MIT.EDU UUCP: {backbones!mit-eddie!mit-athena!treese