Date: Fri, 14 Jul 2000 19:20:46 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, current@FreeBSD.ORG Subject: Re: Request for comments: new `lpd' suite feature Message-ID: <v0421010db59547b0a7e1@[128.113.24.47]> In-Reply-To: <200007142139.RAA88779@khavrinen.lcs.mit.edu> References: <200007142139.RAA88779@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
At 5:39 PM -0400 7/14/00, Garrett Wollman wrote: >Around here, we have a convention that each printer has a record >in the DNS for printername.lpd-spooler which points to the print >server for that printer. It occurred to me that, if there are no >local printers, no additional information is needed for lpr and >lpd to operate -- thus obviating the need for that pesky >`/etc/printcap' file which never seems to be stay up-to-date. and in the update, he wrote comments which said: > This is intended for large sites where distributing the > printcap file is a pain; it will infer from the presence > of spool directories in _PATH_DEFSPOOLDIR a printcap entry > with rm=%s.lpd-spooler and rp=%s (following the convention > used at MIT-LCS where the author currently works). I can sympathize with the idea of getting rid of /etc/printcap, but I admit this strategy perplexes me. How is it easier for you to keep the "presence of spool directories" up to date, than it is to keep /etc/printcap up-to-date? Speaking for my lpd use here at RPI, it is MUCH easier for us (RPI) to keep printcap files in sync than it is to rely that the contents of a directory on the local hard disk is magically correct. Further, if you really CAN keep that up-to-date easier, then it seems to me pretty trivial to write some perl script or routine in chkprinter which simply creates /etc/printcap from those directories. From my reading of your update, you have this "synthetic" printcap file which lpd knows about, but you never write that out anywhere. At least at RPI, we do have other processes which check the /etc/printcap file to make decisions. If that file does not exist, or is not accurate, then those other processes will not work right. I would also say that here at RPI (at least), we have plenty of things in the printcap entries which are not covered by this strategy. Most notably, printer aliases. Every printer we have has multiple names. How are multiple names handled in this situation? Obviously I am just writing the first things which come to my mind in ten minutes of me looking at this update (late on a friday evening!), but it strikes me that this is too much a matter of codifying into freebsd's lpd something which is rather specific to MIT practices. This may very well be useful for other people too, but I can't imagine how I would make any use of this at RPI. That by itself is not important, but (if I am reading your update correctly) it means that there are now "two ways" that the code will deal with printcap files. When someone makes an update (such as adding new fields to 'struct printer'), they will have to be sure to make the update in both places. This makes me queasy. Also, I wonder how all this fits in with the discussion in -arch which has been going (on and off) about replacing lpr in FreeBSD with lprNG. That's not my idea, but I do know I have been holding off some lpr/lpd updates of my own until I have some idea what is going to happen with that. If freebsd is going to switch to lprNG, then this is just one more little oddity which (I think) lprNG will not handle quite the same way. Me, I am interested in ways to make printcap files more automated, but this strategy which may work well in MIT's environment would not make any sense in ours... Disclaimer Reminder: I've only SKIMMED through the actual update, so I may misunderstand what it's doing... Apologies if I have done that. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v0421010db59547b0a7e1>