PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : CUPS verhält sich unterschiedlich


newsmaker
27.02.23, 20:14
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
03.03.23, 15:12
/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
08.03.23, 21:49
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
09.03.23, 10:55
Wieso über localhost:631? Der Drucker ist doch an dem Server ...

alternativ http://server:631...
newsmaker
28.03.23, 08:59
Da kommt die gleiche Meldung ..
Aqualung
28.03.23, 10:07
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
28.03.23, 11:13
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
28.03.23, 13:49
FW am Client?
newsmaker
28.03.23, 13:52
Die ist nicht aktiv
Aqualung
30.03.23, 07:53
lpstat -a

auf dem fehlerhaften client
newsmaker
11.04.23, 08:50
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
11.04.23, 09:41
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
11.04.23, 09:52
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
11.04.23, 12:27
.
was ist am Client noch falsch, obwohl ServerName korrekt eingetragen ist ...

Kennt der Client den Servernamen (/etc/hosts, ping)
newsmaker
11.04.23, 12:32
Er erreicht ja den Server, verlangt aber im Gegensatz zu dem anderen Client eine Authentifizierung.
Aqualung
13.04.23, 08:02
Schau Dir mal die Lösung dieses Falls an:

https://superuser.com/questions/1677772/linux-printing-remotely-with-lp-command-to-cups-server-not-working
(https://superuser.com/questions/1677772/linux-printing-remotely-with-lp-command-to-cups-server-not-working)
newsmaker
13.04.23, 08:57
Die /etc/cups/client.conf ist korrekt gesetzt.
Er erreicht ja den Server. Wenn ich dann den Root-User verwende und mich entsprechend mit PW authentifiziere funktioniert es.
Ich möchte es aber ohne PW tun können, wie es bei all den anderen Clients möglich ist ...