Results 11 to 17 of 17
My main resource for learning about lpr/lpd printing has been The Printing HowTo at tidp.org. It's easy to google. As mentioned earlier I want to squeeze what I can out ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 09-04-2009 #11
OK, after about a dozen tries and several pieces of paper, I managed to solve the main problem with using the default virtual printer in /etc/printcap. It's designed for a text/only printer (dot matrix), and there are line feed problems if you use it with a DeskJet or a Laser.
As per the Printing HowTo, I set up a second virtual printer to the same device and added a line which specified a filter. The filter is intended to deal with the line feed problem. My original was based on the example in section 8.2.1 of the HowTo, as follows. First the original example from the HowTo, this is the virtual printer, not the filter.
lp|dj|deskjet:\ :sd=/var/spool/lpd/dj:\ :mx#0:\ :lp=/dev/lp0:\ :if=/var/spool/lpd/dj/filter:\ :sh:
hp:\ :sd=/var/spool/lpd/dj:\ :mx#0:\ :hp=/dev/usb/lp0:\ :if=/var/spool/lpd/hp/filter:\ :sh:
My filter script was much like that in section 8.2.1. I knew when finally my filter was being recognized because the page would start but would not feed through. Implementing the author's "suggestion": You might also want to end with a form feed: print "\f"; solved that.
OK, so now I have a really boring printer that handles only plain text. One step at a time.
There is one problem I couldn't figure out. How to restart the lpd daemon after editing printcap? I found several recommendations that say execute the lpd startup script with a restart switch. e.g. /etc/init.d/lpd restart, but when I try that I get an error lpd: port # restart is invalid. I'll find it eventually, unless someone here knows the answer.
also, "losing" lp0 and having /dev/usb disappear altogther continues to be an issue, it happened a couple of times today. Somehow my system loses contact with the USB printer, and I have to reseat the usb cable and reboot my computer. It does not seem to be just a "sleep" issue.
- 09-04-2009 #12
Very nice. I don't see any obvious mistakes but then again I can't really test it either because my wife confiscated my printer yesterday and I'm too lazy to walk 50 feet to get it back from her.
It's weird that you keep losing /dev/usb and lp0, have you had this problem with any other distro? Maybe try re-installing your USB packages?
- 09-04-2009 #13
as for "losing" lp0 and the /usb directory there is some indication that it can happen when the printer goes into a power save mode, although that mode doesn't always cause the problem. It also happened when I had to fiddle with the printer to remove a stuck page, although I didn't power off. Preliminary research suggests the problem is known, but I haven't had time to look into it. The printer is the only USB device I have right now.
- 09-04-2009 #14
- 09-05-2009 #15
Thanks Mike, I'll look into those USB packages.
Anyways, The next stage of printing was a battle, I had to ask for extra help, and learned a lot about networking in the process.
OK, the goal is to establish lpr printing from my Windows XP workstation to the lpd service running on Linux as a print server.
This requires the installation of Print Services for Unix on my Windows Box, followed by the creation of an lpr port there. It's pretty routine stuff. But try as I might, I could not get a connection to the lpd service on Linux. I won't describe in detail all the things I tried, just focus on the essentials of what I got hung up on.
ok, by typing ps -ef | grep lpd I get the following line of output, which confirms the lpd service is running
lp 2317 1 0 09:23 ? 00:00:00 /usr/sbin/lpd -s
Someone pointed out the -s option at then end of the output for ps -ef. if you look at the man page for lpd it says about the -s option:
The -s flag selects ``secure'' mode, in which lpd does not listen on a TCP socket but only takes commands from a UNIX domain socket.
Then there is the -b option:
Normally, if the -s option is not specified, lpd will listen on all
network interfaces for incoming TCP connections. The -b option,
followed by a bind-address specifies that lpd should listen on that
address instead of INADDR_ANY.
So the next step is to find out where the -s option is actually defined. presumably it is in a startup script somewhere. OK, so /etc/init.d/lpd is the startup script for the lpd service. it contained the following lines...
PATH=/bin:/usr/bin:/sbin:/usr/sbin DAEMON=/usr/sbin/lpd OPTIONS="" . /etc/default/lpd
OK I should point out that there are better more modern way of doing network printing. I just want to cover all the options. Who knows, someday I may be asked to support some ancient Unix print server that hasn't been updated in 15 years. Also, for now I am working with bare bones tcp/ip. At such time as I set up a Linux Domain, or install Samba, then I guess I'll be doing the networking differently.
- 09-06-2009 #16
OK, the next task was mercifully easy. I want to create a virtual printer in /etc/printcap that will handle any kind of formatted output from Windows. Intuitively I seems I shouldn't have to do anything at all with the file, just pass the print job on to the device (lp0) with no modifications. So that's more or less what I did. One line to point to the spool directory, one line to point to lp0, and I did have to have one line to supress a formfeed that lpr/lpd adds, so that I am only using the formfeed that is put into the printjob by the windows driver.
here's the printer definition I created in /etc/printcap
hp1:\ :lp=/dev/usb/lp0:\ :sd=/var/spool/lpd/hp1:\ :sf:\
OK that will keep me going for a while. I can have my laptop anywhere in the house, and print across the wireless to my linux attached printer. My linux box is primarily a dev (practise) server, so on the off chance I need formatted print from Linux, I will have to transfer the file over to Windows and run it through a windows driver.
There's a certain irony here I could have accomplished the same thing without doing anything at all. Sort of. From Windows I just print whatever to a file, it will be fully formatted by the Windows driver. Then all I would need to do is some kind of file copy or put directly to the lp0 device, and bypass lpr/lpd altogether. For example cp test.prn /dev/usb/lp0 works just fine also.
That's it for now. I can print. More later when I get around to simulating a proper network domain.
- 01-07-2010 #17
OK, I recently went through this whole process of setting up the old BSD style lpr/lpd printing (not CUPS) again, just for the hell of it, and I realised I had left out a key step.
The only way I could establish lpr communications from Windows XP to my Linux box was to create a file /etc/hosts.lpd, and in that file enter the host name of the Windows client. Then I had to create an entry (host name and ip) for the client in /etc/hosts. No changes were made to hosts.allow.
I didn't find this documented anywhere, I got the idea from a Usenet thread. It strikes me as kind of odd to have to make an entry for each client in two files. No problem on my home LAN but would be decidedly inconvenient for a large network
So my question is if this sort of thing is normal in Linux networking, having to specify details of a client machine in a configuration file on the server. I suppose if I had a proper domain with samba/cups then this sort of fiddling might not be necessary?