I installed a new system and it came with CUPS installed to handle the
printer.  It works.  But one day I rushed to "lprm" a bogus print job
to save some paper and CUPS asked me for a password and then refused
(repeatedly) to authenticate me.  I don't recall LPRng ever doing this.
And I couldn't find an obvious way to turn this off.  So now I'm
wondering why use CUPS?

I have one locally connected printer.  Printer "classes" are obviously
of no benefit.  I'm not excited by the web interface.  Does CUPS offer
any advantages over LPRng for a system with a single local printer?

adrian@cam.cornell.edu wrote:

> Does�CUPS�offer
> any advantages over LPRng for a system with a single local printer?


.... they both work. the nice thing about choices
is you get to make a decision which is best for *YOU*
-- 
<<   http://michaeljtobler.homelinux.com/   >>
Immigration is the sincerest form of flattery.
                -- Jack Paar

> ... they both work. the nice thing about choices
> is you get to make a decision which is best for *YOU*

Cetainly.  On the other hand, the >cost< of choices is
that you have to make an evaluation and figure out
which one is best for you (or if it just doesn't matter).
And making that choice requires having information
about the difference between the options.  I have
been looking over the CUPS manuals for this
information and haven't really found it.  Is there a
convenient list somewhere that shows the pros
and cons of CUPS and LRPng that would make it
readily apparent which one is appropriate for a given
situation?  If so, please post a link to it!

adrian@cam.cornell.edu wrote:

> Is�there�a
> convenient list somewhere that shows the pros
> and cons of CUPS and LRPng that would make it
> readily apparent which one is appropriate for a given
> situation?��If�so,�please�post�a�link�to�it!


.... i doubt it, unless you google :)  if you asked
this same question, "lprng vs cups" 3-4 years ago,
you might get a different response: lpr. as a matter
of fact, i'll bet if you do a search on this with
the author of 'mjt' at groups.google.com, you'll
probably see him voting for lpr over cups :)

however, there's a couple of different (and new)
thoughts about this subject. first of all, many
unix types can be heard saying, "the usefulness
of a utility is directly proportional to the 
amount of configuration proficiency" :)  IOW,
if it takes less effort to setup and maintain
one system over another, which would you choose?
of course, less effort doesnt necessarily equate
to higher quality.

anyway, CUPS has come up to speed and i find it
an easier system to administer. i dont see a 
difference in quality of a print job of one print
system over the other. i like the web interface
of CUPS (http://localhost:631/). i think that
specific print functions are easier to get 
working with CUPS (things like print resolution
and tray management). 

here's another thought: what is the default print 
system of choice among distro vendors these days?

you might start here for more info: http://www.linuxprinting.org/
-- 
<<   http://michaeljtobler.homelinux.com/   >>
The economy depends about as much on economists as the weather 
does on weather forecasters. - Jean-Paul Kauffmann

adrian@cam.cornell.edu writes:

>> ... they both work. the nice thing about choices
>> is you get to make a decision which is best for *YOU*

For a single printer I would vote for lprng-- or even old lpr if you could
find it. cups has severe problems with user friendlyness. Not only is its
configuration-- using their web interface of distribution"s attempts to
ammeliorate the web interface's problems-- a minor hell, there seems also
to be no way of doing the configuration by hand. It runs of doing things on
its own (ie the designers-- if that term is useable-- have some weird ideas
of how a printer interface should work). As you can guess I am no great
friend of cups.


>Cetainly.  On the other hand, the >cost< of choices is
>that you have to make an evaluation and figure out
>which one is best for you (or if it just doesn't matter).
>And making that choice requires having information
>about the difference between the options.  I have
>been looking over the CUPS manuals for this
>information and haven't really found it.  Is there a
>convenient list somewhere that shows the pros
>and cons of CUPS and LRPng that would make it
>readily apparent which one is appropriate for a given
>situation?  If so, please post a link to it!

Cups' strength is in making network printers readily (too readily)
available to you. Its weakness is the severe difficulty in eliminating
printers, and in debugging if anything does now work as you (rather than
they) would like. If you are on a net with 50 other people all of who also
have printers run by cups you will suddenly have a list of 50 printers to
choose from on a print job. And the choice of "default" sometimes is
random. 

 

> anyway, CUPS has come up to speed and i find it
> an easier system to administer. i dont see a
> difference in quality of a print job of one print
> system over the other. i like the web interface
> of CUPS (http://localhost:631/). i think that
> specific print functions are easier to get
> working with CUPS (things like print resolution
> and tray management).

Well, one thing that would seem like a big win is the ability to
control printer options like resolution without having to make a bunch
of different printers.  Like my old setup had lp300, lp600, lp2400, and
then I had a special one for 4x6 inch paper.... This was a mess.  Now I
had no trouble configuring the options to work the way I wanted.  I was
using turboprint as support for my printer with the free drivers is
apparently not great.  If there is some way to just make one printer
and control these things with options, that would be great.

But when I visit http://www.linuxprinting.org/ and follow the
directions therein: 'lp -d foo1 -o docs /etc/hosts'
I do not get the list of options.  I just get a copy of my /etc/hosts
file.

On 29 Dec 2004 06:29:15 -0800, adrian@cam.cornell.edu
<adrian@cam.cornell.edu> wrote:

>> ... they both work. the nice thing about choices
>> is you get to make a decision which is best for *YOU*
>
> Cetainly.  On the other hand, the >cost< of choices is
> that you have to make an evaluation and figure out
> which one is best for you (or if it just doesn't matter).

CUPS provides a number of things that lprng doesn't, or that lprng
doesn't provide very well.  CUPS has a capability to auto-configure
network clients.  It has some very sophisticated queue-management
capabilities.  It speaks a protocol (IPP) that interopreates well with
modern versions of Windows.

From a user perspective, if you have apps that support CUPS properly you
get much finer grained control over printing than you do with lprng.  As
a user you can select features like resolution, duplexing, staplers,
collating, etc, from a nice GUI dialog rather than trying to remmember
which queue supports what combination of features or the proper header
to prepend onto your job to make the printer do what you want.  As an
administrator you don't have to work as hard to support the features of
sophisticated printers.

How well all this works depends a lot on what software you use.  KDE for
instance has integrated CUPS support that works very well.  Other apps
may treat it just like lprng, negating some of the nifty features.  But
KDE and Gnome apps should handle it properly and others can be forced by
telling them to use "kdeprint" instead of "lpr" to print.

I switched a few years ago and really find that I prefer CUPS overall.
Setting up new clients is dead easy once the server is configured right,
and besides that I can move my laptop between home and work and it
automatically figures out where the printers are.  Obviously YMMV but I
like it.


-- 
 -| Bob Hauck
 -| To Whom You Are Speaking
 -| http://www.haucks.org/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

unruh@string.physics.ubc.ca (Bill Unruh) writes:

> adrian@cam.cornell.edu writes:
>
>>> ... they both work. the nice thing about choices
>>> is you get to make a decision which is best for *YOU*
>
> For a single printer I would vote for lprng-- or even old lpr if you
> could find it.

LPRng is very good.  All other lpr clones are buggy and obsolete;
recommending them is not sensible--their security is terrible, and
you'll get someone rooted if they follow your advice.  I'd actually
argue that for some tasks, LPRng is better in *large* installations,
due to its powerful and extensible job accounting and other features.
Setup and configuration are significantly more difficult than with
CUPS, depending on what you are doing.  Use by end-users is the same
if using lpr, but far more flexible if using a CUPS-aware print system
(e.g. KDE Print).

> cups has severe problems with user friendlyness. Not only is its
> configuration-- using their web interface of distribution"s attempts to
> ammeliorate the web interface's problems-- a minor hell, there seems also
> to be no way of doing the configuration by hand.

If you look a little closer, you'll notice that the web interface
simply edits files under /etc/cups (usually printers.conf and
classes.conf).  You are free to edit them by hand and then
reload/restart cupsd, just like with any other daemon.  You could also
use lpadmin(8).

In fact, the web interface only gives you the ability to change
classes/queues; the majority of the configuration is in fact editing
cupsd.conf by hand, though for personal use the defaults are usually
fine.


To answer the original question, authentication is controlled in
/etc/cupsd.conf.

<Location /jobs>
AuthType Basic
AuthClass User
</Location>

Change this to something like

<Location /jobs>
AuthType None
AuthClass User
</Location>

You can also do host-based access control and other stuff.  This
simply turns authentication off.


Regards,
Roger

- -- 
Roger Leigh
                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFB1DcrVcFcaSW/uEgRAkoaAKCOku6nTdbMIa3cBNpKwKt+iOFBzgCeKPtu
qeg8wM/TkltCIb66j5HY1jw=
=ZZL+
-----END PGP SIGNATURE-----

Roger Leigh <${roger}@invalid.whinlatter.uklinux.net.invalid> writes:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1

>unruh@string.physics.ubc.ca (Bill Unruh) writes:

>> adrian@cam.cornell.edu writes:
>>
>>>> ... they both work. the nice thing about choices
>>>> is you get to make a decision which is best for *YOU*
>>
>> For a single printer I would vote for lprng-- or even old lpr if you
>> could find it.

>LPRng is very good.  All other lpr clones are buggy and obsolete;
>recommending them is not sensible--their security is terrible, and
>you'll get someone rooted if they follow your advice.  I'd actually
>argue that for some tasks, LPRng is better in *large* installations,
>due to its powerful and extensible job accounting and other features.
>Setup and configuration are significantly more difficult than with
>CUPS, depending on what you are doing.  Use by end-users is the same
>if using lpr, but far more flexible if using a CUPS-aware print system
>(e.g. KDE Print).

Probably true. lpd is pretty old by now. 
I was just commenting on the ease with which you could get it working. Mind
you you first had to figure out what a printcap entry was but then it just
worked. Not terrible flexible or sophisticated but it worked. 
Cups can crash on you, go completely nuts. for example on my system for
some reason occassionally cups seems to lose the usb printer. Thereafter
the only way to get it working again is to empty printers.conf, lpoptions
and printcap restart cups and reset up the printer. Otherwise cups
absolutely refuses to recognise that printer. Who knows where it has gone
into a sulk but it does. 



>> cups has severe problems with user friendlyness. Not only is its
>> configuration-- using their web interface of distribution"s attempts to
>> ammeliorate the web interface's problems-- a minor hell, there seems also
>> to be no way of doing the configuration by hand.

>If you look a little closer, you'll notice that the web interface
>simply edits files under /etc/cups (usually printers.conf and
>classes.conf).  You are free to edit them by hand and then
>reload/restart cupsd, just like with any other daemon.  You could also
>use lpadmin(8).

No. It does not. It is very very weird. for example I just had a problem
with my printer. I emptied out printers.conf and lpoptions, and it kept
asking me about the names of the two printers that had been there. Ie, it
also seems to look at /etc/printcap and who knows where else it hides
stuff. 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

unruh@string.physics.ubc.ca (Bill Unruh) writes:

> Roger Leigh <${roger}@invalid.whinlatter.uklinux.net.invalid> writes:
>
>>unruh@string.physics.ubc.ca (Bill Unruh) writes:

>>> cups has severe problems with user friendlyness. Not only is its
>>> configuration-- using their web interface of distribution"s attempts to
>>> ammeliorate the web interface's problems-- a minor hell, there seems also
>>> to be no way of doing the configuration by hand.
>
>>If you look a little closer, you'll notice that the web interface
>>simply edits files under /etc/cups (usually printers.conf and
>>classes.conf).  You are free to edit them by hand and then
>>reload/restart cupsd, just like with any other daemon.  You could also
>>use lpadmin(8).
>
> No. It does not. It is very very weird. for example I just had a problem
> with my printer. I emptied out printers.conf and lpoptions, and it kept
> asking me about the names of the two printers that had been there.

Do you run Fedora Core?  Some distributions have automatic printer
discovery tools that screw up the printer configuration, and futz with
the config on boot, perhaps even while running.  This is independent
of CUPS, which never updates these files unless you deliberately
configure something.  This is a common problem for at least FC3, but
this is not a CUPS issue, it's a distribution too-clever-by-half bug.

I run Debian, and configured it the old-fashioned way.  The
configuration does not change behind my back!

If you run a network, it might well show broadcast queues as local
(depending on how you configured broadcasts and implicit classes).  If
they were removed, give it five minutes to refresh.  These are not
cached on disc, and are discovered after startup and periodically
refreshed.

> Ie, it also seems to look at /etc/printcap and who knows where else
> it hides stuff.

It generates a printcap for compatibility with tools that parse it (I
disable this).  It doesn't read it, it just spits out a new one when
the printer queues change.

The other location is /var/spool/cups (job spool) and /var/lib/cups
(generated SSL certificates).  That's it.

Regards,
Roger

- -- 
Roger Leigh
                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFB1IviVcFcaSW/uEgRAiTEAKC0rDSaztLZbY3sRFIXJ6tqdBT7pwCgyVtM
OExci6keUjLgCnTmmFkrEnk=
=0hEN
-----END PGP SIGNATURE-----

In article <cr1sbi$3f4$1@nntp.itservices.ubc.ca>,
 unruh@string.physics.ubc.ca (Bill Unruh) wrote:

>lpd is pretty old by now.

lpd was born old. It was a crap protocol to begin with--the RFC that 
describes isn't a spec, it's a report on somebody's reverse-engineering 
of the code.