larry@pocus.uucp (Larry Williamson) (02/07/90)
john@chinet.chi.il.us (John Mundt) writes: > steve@pmday_2.Dayton.NCR.COM (Steve Bridges) writes: > >larry@focsys.uucp (I) wrote: > >> > >> text deleted about remote spooling...... > > > >We had a similiar problem here. We are using Expanded Towernet (a > > I took an even lazier approach. For each remote printer I wanted to > have people use, I created a dummy printer on the local machine. Then, > > for file in "$files" > do > cat $file | uux -n - "${DEST_MACHINE}!lp $REMOTE_PRINTER_NAME -s" > done I considered this. It is the method that the AT&T manuals recommend, but after spending some time at it, I could not figure out how to configure the uucp system to use ethernet. I know that one can do it. The manuals say so, there are config files that tease you with innuendo, but no hard examples could be found. Some kind soul has sent me a small tcp client/server package that implements a simple protocol for sending print requests to a remote machine. One simply installs the client as the lp interface program, and tells inetd on the remote end to fire up the server when the client shouts, and voila, simple remote printing, without uucp. I admit, that uucp seems like the route to go. I just could not, for the life of me, find the answers to all the questions I had about how to configure it. I received many suggestions from many people on what I should do to implement remote printing. I would like to thank all who replied. The suggestions were well received. Unfortunately, not all of them were quite what I needed. Some replies in no particular order: "just use the builtin lpr/lpd stuff". Most of my machines are System V. They do not come with lpr/lpd. "get a copy of PLP (Public Line Printer Spooler), from an comp.sources archive". I did. It looks very good. But it seemed like overkill for my needs. I did not really want to replace the entire lp system. Just add a feature. "continue to use the rsh method". There were a lot of variations here. Some suggested replacing /usr/bin/lp with a script, others said put it in the lp interface script, other said use a shell function. In all cases the problem is that the user may not have access to the remote system. There are many ways around this, but none really seem to do the task in a clean consistent manner. Then came the gem that I implemented. The client/server are very simple, essentially text book examples. But they work great. The only function that cannot be used effectively is lpstat. One cannot tell what the remote spooler has done with your file. This is a very insignificant issue for us. Thanks again to all who responded. (Unless I was unable, you've received a thankyou note already). -Larry