No way to add printers: Add Printer (and other Administration pages) freeze the whole web UI

[andrejpodzimek]

This was originally filed as apple/cups#5927 (wrong project 😁).

The entire CUPS web interface freezes when I try to do (almost) anything on the Administration tab. Sometimes at least the non-Administration tabs start working after a few minutes (without the need to kill the daemon), but sometimes they don’t. There is no way to add printers or otherwise make CUPS work. 😠

From the error_log file:

E [09/Jun/2021:14:22:31 +0200] [Client 2] pam_authenticate() returned 9 (Authentication service cannot retrieve authentication info)
E [09/Jun/2021:14:22:31 +0200] [Client 9] Unable to encrypt connection: Error in the push function.
E [09/Jun/2021:14:24:06 +0200] [Client 8] pam_authenticate() returned 9 (Authentication service cannot retrieve authentication info)
E [09/Jun/2021:14:24:37 +0200] [Client 1] pam_authenticate() returned 9 (Authentication service cannot retrieve authentication info)
E [09/Jun/2021:14:26:40 +0200] [Client 2] pam_authenticate() returned 9 (Authentication service cannot retrieve authentication info)
E [09/Jun/2021:14:26:40 +0200] [Client 7] Unable to encrypt connection: Error in the push function.
E [09/Jun/2021:14:26:40 +0200] [Client 8] Unable to encrypt connection: Error in the push function.

Debug logs:

• loading the default page (https://server.domain.name.in.certificate:632)

• clicking on the Admin tab for the first time

• clicking on Add Printer button (after which it freezes):

  D [09/Jun/2021:15:48:17 +0200] [Client 1] POST /admin/ HTTP/1.1
  D [09/Jun/2021:15:48:17 +0200] cupsdSetBusyState: newbusy="Active clients", busy="Not busy"
  D [09/Jun/2021:15:48:17 +0200] [Client 1] Read: status=200, state=6
  

  This is all. Afterwards it’s completely frozen.

Non-default settings in cupsd.conf (which worked fine in ~2017, so I’m just reusing them):

[...]

Listen /run/cups/cups.sock
Listen localhost:631
SSLListen localhost:632
SSLListen [2a02:xxxx:yyyy:1::abcd]:632
SSLListen [2a02:xxxx:yyyy:2::abcd]:632
SSLListen [2a02:xxxx:yyyy:3::abcd]:632
SSLListen [2a02:xxxx:yyyy:4::abcd]:632

ServerName server.domain.name.in.certificate
ServerAdmin admin@domain.name.in.certificate

[...]

# Restrict access to the server...
<Location />
  Order allow,deny
  Allow [::1]/128
  Allow [2a02:xxxx:yyyy:1::]/64
  Allow [2a02:xxxx:yyyy:2::]/64
  Allow [2a02:xxxx:yyyy:3::]/64
  Allow [2a02:xxxx:yyyy:4::]/64
</Location>

# Restrict access to the admin pages...
<Location /admin>
  Order allow,deny
  Allow [::1]/128
  Allow [2a02:xxxx:yyyy:1::]/64
  Allow [2a02:xxxx:yyyy:2::]/64
  Allow [2a02:xxxx:yyyy:3::]/64
  Allow [2a02:xxxx:yyyy:4::]/64
  Encryption required
</Location>

# Restrict access to configuration files...
<Location /admin/conf>
  AuthType Default
  Require user @SYSTEM
  Order allow,deny
  Allow [::1]/128
  Allow [2a02:xxxx:yyyy:1::]/64
  Allow [2a02:xxxx:yyyy:2::]/64
  Allow [2a02:xxxx:yyyy:3::]/64
  Allow [2a02:xxxx:yyyy:4::]/64
  Encryption required
</Location>

# Restrict access to log files...
<Location /admin/log>
  AuthType Default
  Require user @SYSTEM
  Order allow,deny
  Allow [::1]/128
  Allow [2a02:xxxx:yyyy:1::]/64
  Allow [2a02:xxxx:yyyy:2::]/64
  Allow [2a02:xxxx:yyyy:3::]/64
  Allow [2a02:xxxx:yyyy:4::]/64
  Encryption required
</Location>

[...]

The ~same configuration used to work fine back in 2017.

Adding Allow @LOCAL doesn’t help.

Removing Encryption required doesn’t “help”.

Sometimes a password prompt is shown and then it freezes. Sometimes there’s no password prompt and it freezes immediately. (This may be just the browser’s password caching.)

Typing user credentials (from wheel) or root credentials has the same effect; it just freezes.

TLS works fine; the CUPS website is properly encrypted and the supplied certificate is used.

The distro is ArchLinux, with its standard CUPS packages:

cups 1:2.3.3op2-3
cups-filters 1.28.8-1
cups-pdf 3.0.1-6
cups-pk-helper 0.2.6-4
cups-xerox-b2xx 1.0-1
libcups 1:2.3.3op2-3

As for cups-pk-helper, it is mentioned here and I thought it could resolve the authentication problem, but it has no effect whatsoever.

It looks like CUPS won’t work on current systems. I haven’t used it for ~4 years now, so maybe I have missed / misconfigured something. It doesn’t seem to be compatible with current PAM and systemd. (Or could systemd-homed be an issue for CUPS? It doesn’t apply to root or to the cups user, so I don’t think that’s a problem.)

[andrejpodzimek]

To narrow this down: localhost:631 (unencrypted) seems to work, to an extent. Authenticating a user from wheel won’t help though; it will freeze (only) for a couple of seconds and then show an authentication dialog again. (Which is unexpected, because cups-files.conf has SystemGroup sys root wheel.) Typing in the root credentials (what if a distro doesn’t have a root password?) appears to work though.

So the question is why Administration freezes with TLS enabled (even though the default page loads just fine with TLS).

[andrejpodzimek]

And after a few further minutes of poking around, all CUPS TLS pages stopped working. They just freeze and so does cupsd (i.e., it cannot be restarted without brute force).

There has been no change to the certificate files and/or configuration since previous experiments.

How can CUPS break itself at random? Are there any cache directories I need to wipe out?

[michaelrsweet]

@andrejpodzimek What version of GNU TLS are you using?

CUPS won't break itself at random. But if your system is misconfigured or cannot generate sufficient entropy to support a TLS connection, that might appear to be "breaking" CUPS...

Also, have you reported this to the ArchLinux folks?

[michaelrsweet]

Closed due to lack of response.

[andrejpodzimek]

Sorry for the radio silence; I should have closed this issue back in June. As mentioned in #198, I no longer have a printer and therefore a possibility or motivation to test things. I will avoid CUPS and home printing in the future, because neither the hardware support part nor the configuration part worked for me and the time lost was already worth more than years of copy-center fees.

I used CUPS on an (almost) daily basis between 2007 and 2017 (also with weird GDI-only printers) and it had always worked flawlessly and out-of-the-box back then. This year’s experience was totally different, sadly enough.