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

[andrejpodzimek]

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 something: Is CUPS still maintained? Or has there been a replacement I’ve missed? It doesn’t seem to be compatible with current PAM and systemd.

[michaelrsweet]

@andrejpodzimek First, you need to file this issue over in the OpenPrinting CUPS project. That's where the 2.3.3op2 release came from... (so yes, CUPS is still maintained :)

Second, the errors you are seeing indicate a far greater problem than just an issue with CUPS - key parts of your OS install seem to be missing or broken (PAM, GNU TLS, etc.) More than likely you need to contact your Linux distribution for help, as CUPS by itself depends on a large number of things working in the OS - if they are broken in some way, then naturally CUPS will not work.

[andrejpodzimek]

OK, I’ll file this in OpenPinting/cups then.

My ArchLinux install works just fine. Yes, it uses systemd-homed and other relatively modern parts, but there are no authentication problems other than the one with CUPS.

(Plus the question is whether this is an authentication problem at all — because CUPS freezes and says nothing, one can’t really tell.)

I don’t see why GnuTLS would be broken; the connection to the CUPS web UI uses the right certificate and is encrypted, so GnuTLS / OpenSSL / whatever CUPS uses seems to work fine.

Because CUPS is the only “misbehaving” daemon on the whole OS, I would not blame the OS itself before investigating why exactly CUPS is getting stuck.