CUPS verhält sich unterschiedlich

[newsmaker]

Ich habe einen ordentlich konfiguriertes CUPS-Server.
Ein Client (CentOS 7.9) druckt über lp auf einen vom Server freigegeben Drucker eine Datei, das schaut wie folgt aus:

/usr/bin/lp -U [UserName] -c -h SERVER:631 -d KYO03_DDH /tmp/pdf.pdf
Password for [UserName] on SERVER?
request id is KYO03_DDH-35096 (1 file(s))

Passwort wird dabei gar nicht abgefragt, er druckt sofort

Ein zweiter Client (OracleLinux 8.5)
gleicher Aufruf

/usr/bin/lp -U [UserName] -c -h SERVER:631 -d KYO03_DDH /tmp/pdf.pdf
Password for [UserName] on SERVER?
Password for [UserName] on SERVER?
Password for [UserName] on SERVER?
/usr/bin/lp: Error - The printer or class does not exist.

Was ist an dem zweiten Client falsch? Fehlt noch was?
Verhalten sollte das gleiche wie beim ersten sein, es wird beide male der gleiche User verwendet, beide Male innerhalb des erlaubten IP-Kreises

[corresponder]

/usr/bin/lp: Error - The printer or class does not exist.

entweder der client findet den Drucker nicht oder es fehlen ihm die richtige "Treiber",
erreicht der Client den Drucker über http://localhost:631 ?

[newsmaker]

Wieso über localhost:631? Der Drucker ist doch an dem Server ...

Es funktioniert doch an dem CentOS7.9 System
Kann es sein, dass direkt Client noch eine Policy-Regel aktiv ist, die dazu zwingt eine Verbindung über PW aufzubauen?
Wohlgemerkt gibt es am CUPS-Server keine Unterscheidung, beide Clients befinden sich im gleichen Netzwerkbereich und verwenden den gleichen User.

[corresponder]

Wieso über localhost:631? Der Drucker ist doch an dem Server ...

alternativ http://server:631...

[newsmaker]

Da kommt die gleiche Meldung ..

[Aqualung]

Häng Dich mal mit an die log-datei

 tail -50f /var/log/cups/error_log

auf dem Server.

Schau mal auf dem fehlerhaften Client im Vergleich zum funktionierenden Client

man lp

ob die Implentierung von lp unterschiedlich ist (keyword-Parameter).

[newsmaker]

Bei einem funktionierenden Client:
10.241.32.213 - - [28/Mar/2023:11:13:20 +0200] "POST /printers/KYO03_DDH HTTP/1.1" 200 224 Create-Job successful-ok
10.241.32.213 - - [28/Mar/2023:11:13:20 +0200] "POST /printers/KYO03_DDH HTTP/1.1" 200 201940 Send-Document successful-ok

Die Fehlversuche kommen gar nicht an ...
was ist am Client noch falsch, obwohl ServerName korrekt eingetragen ist ...

[Aqualung]

FW am Client?

[newsmaker]

Die ist nicht aktiv

[Aqualung]

lpstat -a

auf dem fehlerhaften client

[newsmaker]

Dieser Aufruf bringt folgendes zurück:
KYO03_DDH accepting requests since Mon 10 Apr 2023 11:03:07 PM CEST

Somit sollte doch der Druck funktionieren.
Aber dennoch bringt er zurück
/usr/bin/lp: Error - The printer or class does not exist.

[newsmaker]

Was ich nicht verstehe, dass hier vom neuen Client steht eine Authentifizierung gefordert wird, aber nicht vom alten ...
Auf dem Cups-Server selbst:
<Location /printers/KYO01_FH>
Order Deny,Allow
Deny From All
Allow From 127.0.0.1
Allow From All
AuthType None
</Location>

[newsmaker]

Genauso auch der Aufruf:
lpstat -l -p KYO03_DDH

printer KYO03_DDH is idle. enabled since Tue 11 Apr 2023 09:54:24 AM CEST
Form mounted:
Content types: any
Printer types: unknown
Description: Kyocera FS-2000D
Alerts: none
Location: C002
Connection: direct
Interface: /etc/cups/ppd/KYO03_DDH.ppd
On fault: no alert
After fault: continue
Users allowed:
(all)
Forms allowed:
(none)
Banner required
Charset sets:
(none)
Default pitch:
Default page size:
Default port settings:

[corresponder]

.
was ist am Client noch falsch, obwohl ServerName korrekt eingetragen ist ...

Kennt der Client den Servernamen (/etc/hosts, ping)

[newsmaker]

Er erreicht ja den Server, verlangt aber im Gegensatz zu dem anderen Client eine Authentifizierung.