[cups.general] Re: Connection to CUPS server failed

[Christopher Singley]

Kurt,

Thanks for your reply.

I should have mentioned that I'd already added user 'cupsys' to the  
'shadow' group, and added my user account to the 'lpadmin' group; my  
problem connecting with the CUPS server seems to lie elsewhere.

I tried flipping the 'RunAsUser' directive in cupsd.conf and restarting  
cups, but that seems not to have done the trick.

I hear you about overzealous security, but in fact when I first installed  
Ubuntu, I was able to connect to the CUPS server both via KDE system  
settings and via port 631.  I was trying to set up a connection to a  
network printer shared over SAMBA.  I wasn't able to get it set up, and  
CUPS subsequently stopped working.  I think it's something that I did, but  
I can't recall what!

So I'm looking for some "bottoms-up" tips on debugging CUPS.  I could  
reinstall the OS, but I'd rather not.

Any help is much appreciated.

Thanks,

Chris

Christopher Singley <csingley at gmail.com> wrote (Friday 16 June 2006 23:27):

> I've newly installed Ubuntu 5.10 "Breezy Badger", running kernel
> v2.6.12-10, and I seem to have done something bad to CUPS.  I cannot
> connect to the server via the web interface on port 631, or via the KDE
> system settings print admin (i.e. the connection times out in either
> case).

No.

I'd rather guess that the Ubuntu packagers of the CUPS software have
done something bad and user-unfriendly to CUPS (their officially given
justification is "increased security").

Not sure about Breezy...

.....but Dapper has a "/usr/share/doc/cupsys/README.Debian.gz" file
which (at its end) outlines how you are supposed to get the CUPS web
based admin functions back. You could try to run these two commands:

   sudo adduser cupsys shadow
      # this adds user "cupsys" to the "shadow" group so that it can
      # read the /etc/shadow file to verify authentication data

   sudo adduser christopher lpadmin
      # this adds user "christopher" to the "lpadmin" group of CUPS
      # administrators so you don't need to become root for accessing
      # the admin functions

> I can't figure out why this should be the case; inspecting the logs isn't
> proving informative.  Searching the web hasn't turned up much applicable,
> and I've exhausted my limited CUPS troubleshooting skills.  Can anyone
> give me some clues how to get connected to CUPS?
>
> My /etc/cups/cupsd.conf:
> ========================
> ConfigFilePerm 0600
> DefaultCharset notused
> #LogLevel info
> LogLevel debug
>
> Printcap /var/run/cups/printcap
> RunAsUser Yes

"RunAsUser Yes" is supposed to make your setup ultra-secure. It makes
cupsd run as non-root (and deprives it from the ability to read the
/etc/shadow file holding the encrypted passwords. The "AuthType Basic"
used further below does rely on this /etc/shadow file.

There are serious doubts if that setup chosen by the Ubuntu packager
geeks really improves security so considerably.

But there is no doubt at all that...
  ...this is a very user-unfriendly configuration
  ...this is taking a way a big part of CUPS' uniq features from users
  ...this provokes most support + and help calls from (K)Ubuntu users
     to come in due to that particular default setup

> Listen 127.0.0.1
> Include cupsd-browsing.conf

BTW, this included file by default has "Browsing Off". That's another
example of supposedly increased security traded for a considerable
loss in user friendlyness and usability. Set "Browsing On", and your
box will automatically "see" and be able to use all printers which
are shared by other CUPS servers in your environment.

> BrowseAddress @LOCAL

Comment this out if you do not want to announce and share your own
printers.

> <Location />
> Order Deny,Allow
> Deny From All
> Allow From 127.0.0.1
> </Location>
>
> <Location /jobs>
> AuthType Basic
> AuthClass User
> </Location>
>
> <Location /admin>
> AuthType Basic

(An alternative, and maybe less confusing, easier for usability, and
even more secure, would be to use "AuthType Digest" or "AuthType
BasicDigest" which would use a separate password file in
/etc/cups/passwd.md5 -- but you'd have to populate it before first
use running the "sudo lppasswd -a root" and "sudo lppasswd -a
christopher" commands...)

> AuthClass System
> Order Deny,Allow
> Deny From All
> Allow From 127.0.0.1
> </Location>

Cheers,
Kurt