[Pkg-cups-devel] Bug#423943: "127.0.0.1 localhost" needs to be defined in your /etc/hosts

[Kurt Pfeifle]

Your localhost/127.0.0.1 problem certainly is not an upstream issue, because
I often run pristine upstream SVN checkouts, and I test their default confi-
gurations quite often.

It is either a Debian thing (unlikely, because it would have caused lots
more report similar to yours), or it is a local mis-configuration.

Yes, 127.0.0.1 is localhost by definition. Sometimes. And only, if you run
IPv4. It is different for IPv6. And you can change that definition in your
local /etc/hosts file (for good or for bad).

Please run this command:

  ping localhost

while you have the (standard) line "127.0.0.1 localhost" commented *out*
from /etc/hosts. You will not get a response, and you will not get Apache
to respond on http://localhost/ and you will not get CUPS to respond on
http://localhost:631/ (if your network cable is disconnected).

However, you may still get the correct response of "127.0.0.1" if you ask:

  nslookup localhost

because that is what any correctly configured name server will return.
And now Apache may respond (because its default configuration setting is
to do DNS hostname lookups), but CUPS will still not respond (because
its default configuration is "HostNameLookups Off" -- if you set it to
"On" it will also respond when an external DNS server returns 127.0.0.1
for the lookup of "localhost").

Complicated? Yes. But so is TCP/IP networking in general, as soon as
you bother to go for the details.

BTW, try to ping 127.0.0.2. Do you get a response? Now ping 127.0.77.1.
And now 127.44.55.66... In case you wonder: these are all evenly "legal"
addresses to address the loopback interface ("localhost" is responding
because internally all addresses 127.0.0.2-127.255.255.254 are required
to be routed to 127.0.0.1; therefore your loopback interface will re-
spond to the pings).

Now for the "RFCs out there". Yes, they define this stuff. Please refer
to RFC 3330 if you want to learn more about special and reserved IP
addresses.

So, to summarize:

Yes, you can easily confuse CUPS (as well as any other network daemon)
by incorrectly configuring some of your loopback/localhost/127.0.0.1
stuff.

And you can equally easily confuse CUPS (as well as any other network
daemon) by misconfiguring *its* *own* config files.

Please check your /etc/hosts for the localhost IP address, and also
check your

  /etc/cups/cupsd.conf
  /etc/cups/client.conf
  ~/.cupsrc
  ~/.client.conf

files (only the first two ones are guaranteed to exist on your system,
the others are optional) for what their content is in respect to the
(CUPS) "ServerName". This will explain why in one case the web
interface may ask for a password (or may not respond at all) and in
the other case it may grant access.

Oh, and regarding the password question, where none of your passwords
works: your cupsd.conf may be using "AuthType Digest" (or "BasicDigest").
In which cases a password may need to be set by first running the
"lppasswd -a <username>" command because *Digest authentication uses
a separate user database (in order to increase security, and allow
CUPS administration without ever needing root privileges).

CUPS by default ships with "AuthType Basic" (which works with the
standard system password database). But then, *buntu does not ship
with a root password, and therefor root may be blocked from accessing
the resource for lack of a password (while cupsd.conf may only allow
the root user to access the resource).

Other points where your config may be aiding and abetting some weird
things to happen:

  * inconsistent use of both, "127.0.0.1" and "localhost", to define
    different access control schemes and AuthTypes for different
    resources
  * a setting of "HostNameLookups {On|Off|Double}" that does not work
    with your overall DNS name resolution

You very likely have fallen prey to a distro setup where the packagers
have deviated from the upstream defaults without considering the
implications of *all* their changes.

Cheers,
Kurt


P.S.: I recommend to close this bug report after double-checking for
      the correct 127.0.0.1/localhost settings in cupsd.conf and in
      /etc/hosts on default Debian installations.


-- 
Kurt Pfeifle
System & Network Printing Consultant ---- Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH  .....................  Hedelfinger Strasse 58
A RICOH Company  ...........................  D-70327 Stuttgart/Germany 
---
Infotec Deutschland GmbH
Hedelfingerstrasse 58
D-70327 Stuttgart
Telefon +49 711 4017-0, Fax +49 711 4017-5752
www.infotec.com
Geschaeftsfuehrer: Elmar Karl Josef Wanderer, Frank Grosch, Heinz-Josef Jansen
Sitz der Gesellschaft: Stuttgart, Handelsregister HRB Stuttgart 20398

Der Inhalt dieser E-Mail ist vertraulich und ist nur für den Empfänger bestimmt. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Veröffentlichen, Kopieren sowie die unbefugte Übermittlung komplett oder in Teilen sind nicht gestattet.Private Ansichten und Meinungen sind, wenn nicht ausdrücklich erklärt, die des Autors und nicht die der Infotec Deutschland GmbH oder deren verantwortliche Direktoren und Angestellte. Eine Haftung für Schäden oder Verlust von Daten durch den Gebrauch dieser Email oder deren Anhänge wird ausgeschlossen.
Weitere Informationen erhalten Sie im Internet unter www.infotec.com oder in jeder Infotec Niederlassung.
This E-Mail is for the exclusive use of the recipient and may contain information which is confidential. Any disclosure, distribution or copying of this communication, in whole or in part, is not permitted. Any views or opinions presented are those of the author and (unless otherwise specifically stated) do not represent those of Infotec Deutschland GmbH or their directors or officers; none of whom are responsible for any reliance placed on the information contained herein. Although reasonable precautions have been taken to ensure that no viruses are present, all liability is excluded for any loss or damage arising from the use of this email or attachments.
For further information please see our website at www.infotec.com or refer to any Infotec office.