sjs@ctt.bellcore.com (Stan Switzer) (12/04/88)
Has anyone ever tried to use the yellow pages to serve termcap, printcap, or remotes entries? It seems like an obvious enough idea. It'd be simple enough to do for /etc/termcap, and it'd be a lot nicer scheme than System V's unspeakable arrangement. With /etc/printcap a problem arises: you need to be able to somehow tailor the file a little bit for each of the print servers. What'd probably work is to have entries with names "printer@sys" override entries "printer" on system "sys". The default entry "printer" would be a remote entry, and the overrides would specify the particulars for the servers. A less complicated scheme would involve having servers specify their overrides in their local printcap files followed by a "+" entry to pull in the common (remote) entries from the yellow pages. Of course, then you'd probably want to think about fixing the print spooler so that remote prints at diskless workstations don't end up flying over the net three times. But that's a whole 'nuther issue. The way some of these things work you'd thing all anyone ever did with Suns is run "shelltool rlogin <foo>." It's going to take some INTEGRATION to make the network BE the computer. Stan Switzer sjs@ctt.bellcore.com
roy@philabs.philips.com (Roy Smith) (12/16/88)
In v7, i37, msg 12/12, sjs@ctt.bellcore.com (Stan Switzer) writes: > Has anyone ever tried to use the yellow pages to serve termcap, printcap, > or remotes entries? We put printcap into our yp maps a while ago. I'm actually rather surprised that Sun doesn't do that by default. We have the local copies of /etc/printcaps get searched first, then the YP printcap map. That way, all we need do is put an entry for each remote printer in the YP map and on the particular machines where the printers actually reside, put a local entry for that same printer in the local /etc/printcap. Got that? One of the nice things about this is it becomes easy to redirect printer output if a particular printer is down for a while. For example, laser9 is plugged into /dev/ttya on adenine. In the YP map, we have: laser9:lp=:rp=laser9:rm=adenine: while in adeine's /etc/printcap we have: laser9:lp=/dev/ttya: If for some reason laser9 is going to be down for a day or so, all I need do is change adenine's /etc/printcap to read: laser9:lp=:rp=laser10:rm=phrivax: and not bother changing the YP map. More important, I don't have to remember to change the YP map again when laser9 comes back up. Of course, that means every print job for laser9 will get sent to adenine and then turned around and get sent to phrivax to be queued on laser10, but we feel that the administrative convenience outweighs the extra network traffic (what difference does another few Mbytes a day make to an ethernet?) In fact, it doesn't even matter if we get the right machine in the "rm=" slot; if I happen to pick the wrong machine by mistake, it just means another hop across the network. Of course, if you expect the outage to last for any appreciable amount of time you will want to make the change directly in the YP map to avoid the extra hops. I didn't do the code changes; it was all done by Nomi Voroba, who no longer works here (Hi Nomi!). To tell you the truth, I havn't looked at the code much, so I don't know what kind of state it is in. I suspect that much of it is based on Sun-proprietary source, so we probably can't send it out. If I remember, I'll see about getting it all packaged up for export and then see if I can get Sun licensing to give me the go-ahead to post it. Lacking that, I could probaby just post the diffs. Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net