Jeffrey J. Nonken wrote:
On Wed, 12 Oct 2005 19:32:48 -0700, Jeff Newmiller wrote:
CUPS emulates lpd. The instructions you said you had followed
pointed out that you would have to mv the lpd commands in /usr/bin
so that the CUPS equivalents from /usr/local/bin would get invoked
instead from later in the PATH.
True, though that didn't eliminate lpd itself. But I was told the same
thing yesterday on IRC, so I've killed off lpd and removed it from
rc.conf. That may have been interfering. (I'd already renamed the
related lpd commands.)
Killing off the daemon sounds appropriate.
At this point I've got it responding to shell commands and the web
interface.
. . . .
After a lot of description of further problems, I started explaining
that localhost isn't responding. Then I started fiddling, and ended up
throwing out all I'd said, because I seem to have fixed it.
[... localhost fixes omitted ...]
The CUPS web interface is now working, as is the CUPS GUI
administrator. I can pop back and forth and get the same results.
re: your other message... this stuff mostly sounds rather FreeBSD-specific.
Useful to document, but I am not qualified to comment.
Unfortunately, one of the results is that the printer isn't printing.
And NOW I feel that I've gotten enough other problems resolved to pass
along my CUPS configuration files.
First, a couple screenshots:
http://jnork.nonken.net/images/Misc/PRINT-1.GIF
This screenshot says this printer is still sending data to a socket instead
of a device. My systems only say this when the printer is on a different
machine than the one on which I am looking at the CUPS configuration... and
if browsing is enabled, CUPS will automatically make those printers
available without having a local spooling entry.
http://jnork.nonken.net/images/Misc/PRINT-2.GIF
I got the same results whether I tried to connect via USB or JetPrint.
For now I've set it to /dev/ulpt0 to reduce the number of variables.
And just to make sure, I just did
lptest 79 1 > /dev/ulpt0
and sure enough, the printer responded.
http://jnork.nonken.net/images/Misc/CUPS/
All I see in error_log is CUPS feeding data to itself as a result of the
incorrect specification of a socket instead of a physical device.
The printers.conf looks okay though, so I am thinking that perhaps the
error_log did not correspond to a test in which CUPS was configured
the way the printers.conf shows?
error_log.txt (I had to give it an extention so you could access it)
contains very little, actually. I left the CUPS GUI configurator
running, stopped cupsd, renamed the old error_log, started cupsd, and
tried printing a test page. That's pretty much all that's in there,
but at log level debug2 it's a very VERBOSE not-very-much.
It is not just verbose... it is repetitive.
--
---------------------------------------------------------------------------
Jeff Newmiller The ..... ..... Go Live...
DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go...
Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/Batteries O.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...1k
---------------------------------------------------------------------------
_______________________________________________
vox-tech mailing list
[email protected]
http://lists.lugod.org/mailman/listinfo/vox-tech
