Kein Zugriff mit Cups Webinterface auf Druckserver

[Jogibär]

Hallo,

bin ein wenig ratlos.
Probiere und lese schon seit Stunden rum, aber kein Erfolg

Server:

PC mit Cups -> Drucker per USB angebunden
IP 192.168.128.2
Debian Lenny


Client:

Laptop
IP 192.168.128.129
Debian Lenny

Firewalls sind ausgeschaltet.
Ping funktioniert, ssh und nfs auch.

Ich kann einfach Cups per Browser nicht aufrufen.
Client: ->http://192.168.128.2:631 oder https...
Fehlermeldung: Verbindung fehlgeschlagen

meine cupsd.conf vom Server:

#
#
# Sample configuration file for the Common UNIX Printing System (CUPS)
# scheduler. See "man cupsd.conf" for a complete description of this
# file.
#

# Log general information in error_log - change "info" to "debug" for
# troubleshooting...
LogLevel debug

# Administrator user group...
SystemGroup lpadmin


# Only listen for connections from the local machine.
Listen localhost:631
Listen /var/run/cups/cups.sock

# Show shared printers on the local network.
Browsing On
BrowseAddress 192.168.128.255
BrowseAllow All
BrowseInterval 30
#BrowseOrder allow,deny
BrowsePort 631
# Default authentication type, when authentication is required...
DefaultAuthType Basic

# Restrict access to the server...
<Location />
Order Deny,Allow
Allow From 127.0.0.1
Allow From 192.168.128.129
</Location>

# Restrict access to the admin pages...
<Location /admin>
Order Deny,Allow
Allow localhost
Allow From 192.168.128.129
</Location>

# Restrict access to configuration files...
<Location /admin/conf>
AuthType Default
# Require user @SYSTEM
Order Deny,Allow
Allow From 192.168.128.129
Allow localhost
</Location>

# Set the default printer/job policies...
<Policy default>
# Job-related operations must be done by the owner or an administrator...
<Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job CUPS-Move-Job>
Require user @OWNER @SYSTEM
Order deny,allow
</Limit>

# All administration operations require an administrator to authenticate...
<Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default>
AuthType Default
Require user @SYSTEM
Order deny,allow
</Limit>

# All printer operations require a printer operator to authenticate...
<Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After CUPS-Accept-Jobs CUPS-Reject-Jobs>
AuthType Default
Require user @SYSTEM
Order deny,allow
</Limit>

# Only the owner or an administrator can cancel or authenticate a job...
<Limit Cancel-Job CUPS-Authenticate-Job>
Require user @OWNER @SYSTEM
Order deny,allow
</Limit>

<Limit All>
Order deny,allow
</Limit>
</Policy>

#
#

Ich komme einfach nicht weiter.
Könnte mir bitte mal jemand einen Tip geben, wie ich weiterkomme ?

Danke

Jogibär

[Danielx]

# Only listen for connections from the local machine.
Listen localhost:631

Das sagt doch schon alles!

Ändere "Listen localhost:631" in "Port 631"
Und dann cupsys neu starten:

Code: Alles auswählen

/etc/init.d/cupsys restart

Gruß,
Daniel

[rlau]

Hallo Jogibär,

es würde mich sehr interessieren, ob dieser einfache Eintrag

Code: Alles auswählen

Port 631

das Problem bei Dir behebt? Bei mir reicht das leider nicht.

@Danielx:
Könntest Du vielleicht bitte eine cupsd.conf hier her stellen, welche gar kein https benötigt?

Ja, ich habe mitbekommen - auch wenn ich die Hintergründe nicht verstanden habe -, daß cups angreifbar war. Ich bin hier aber allein in meinem Netzt und muß leider auf zwei verschiedenen Betriebssystemen arbeiten. Und da ich eh einen Linuxserver habe, hat es sich in den letzten zweieinhalb Jahren gut über cups und sarge drucken lassen. Das bekomme ich im Moment aber nicht wieder hin.

Natürlich kann man das auch alles auf der Kommandozeile konfigurieren und testen. Aber z. B. gab es unter Sarge einen generischen PostScript Druckertreiben, der meinen Lexmark E323, wenn auch mit eingeschränkter Funktionalität, ansteuern konnte. Diesen Druckertreiber finde ich bis jetzt nicht - und es probiert sich halt für mich Halblaien leichter mit dem Webinterface des cups.

Mit freundlichem Dank im Voraus
Rainer

[Danielx]

Hier die cupsd.conf für den Server:
http://nopaste.debianforum.de/7293

Funktionen:
- Zugriff vom lokalen Netz möglich (bzgl. Administration: siehe unten)
- Verteilt Drucker welche mit dem Server verbunden sind im lokalen Netz
- Erlaubt entfernte Verwaltung aus lokalem Netz (wenn nur von localhost erwünscht: Zeile 21 + 29 einkommentieren; Zeile 22 + 30 auskommentieren).
- Benötigt keine Verschlüsselung (auch nicht für die Administration, zum aktivieren der Verschlüsselung: Zeile 18 einkommentieren)

Diese Config funktioniert unter Etch, ob sie unter Sarge funktioniert weiß ich nicht, konnte ich auch nicht überprüfen, da ich letzte Woche meinen letzten Rechner von Sarge auf Etch umgestellt habe.

Gruß,
Daniel

[rlau]

Hallo Danielx,

vielen Dank für Deine Hilfe, aber … die eingespielte cupsd.conf von Dir hat leider nicht die erhofften Fortschritte gebracht.

426 Upgrade Required

Um auf diese Seite zuzugreifen müssen Sie die URL https://192.168.0.4:631/admin?op=delete ... onfirm=yes verwenden.

Wirklich überrascht hat mich das nicht mehr, denn ich habe mich so gut ich das mit meinen Kenntnissen hinbekomme, in den letzten Tagen auch immer wieder wieder mit der Befehlssyntax für diese config beschäftigt - und bin zu einer ähnlichen config gekommen.

Nur um das Mißverständnis auszuschalten: Ich versuche hier nicht cups auf Sarge neu zu konfigurieren, sondern ich habe meinen Server neu mit Etch aufgesetzt und seit dem gelingt es mir nicht, den Drucker über die Webschnittstelle zu administrieren - angezeigt wird er zunächst, aber wenn ich Veränderungen vornehmen will, hängt sich das Web Interface auf … und ich vermute mal auch der cupsd. Er nimmt danach biz zu einem /etc/init.d/cupsys restart auch auf der Kommandozeile keine Befehle mehr entgegen. Deswegen denke ich, daß der Fehler noch irgendwo anders stecken muß.

Nebenbei: Einer meiner anderen Rechner ist ein Mac 10.4.11. Darauf läuft

# "$Id: cupsd.conf,v 1.47.2.1 2005/05/31 18:45:34 jlovell Exp $"

Und das läßt sich konsequent und einwandfrei so konfigurieren, daß der Webzugriff auch für Adminaufgaben möglich ist - ohne https (und von einem Laien ; - ). Das bestärkt mich in der Vermutung, daß mein Fehler irgendwo anders liegen muß.

Gruß
Rainer

edit PS:
Ich finde im Portscan auf den Server kein 443. Müßte dieser Port nicht offen sein, um den cupsd über https zu erreichen?

[Danielx]

Hier eine neue cupsd.conf (hauptsächlich für rlau interessant):
http://nopaste.debianforum.de/7296

Funktionen:
- Zugriff vom lokalen Netz möglich
- Verteilt Drucker welche mit dem Server verbunden sind im lokalen Netz
- Erlaubt entfernte Verwaltung aus lokalem Netz (wenn nur von localhost erwünscht: Zeile 27 + 37 einkommentieren; Zeile 29 + 39 auskommentieren).
- Benötigt keine Verschlüsselung, Client kann aber Verschlüsselung verlangen (zum Aktivieren der zwangsweisen Verschlüsselung der Administration: Zeile 22 einkommentieren)

Änderungen gegenüber der ersten Version:
- DefaultEncryption IfRequested
- Kommentare geändert

@Jogibär: Wie sieht es bei dir aus?
Probiere es doch auch mal mit meiner Config!

@rlau:

die eingespielte cupsd.conf von Dir hat leider nicht die erhofften Fortschritte gebracht.

426 Upgrade Required

Um auf diese Seite zuzugreifen müssen Sie die URL https://192.168.0.4:631/admin?op=delete ... onfirm=yes verwenden.

Ich habe das bei mir nochmals getestet:
Wenn ich versuche einen Drucker über eine unverschlüsselte Verbindung zu löschen, dann bekomme ich auch so eine Fehlermeldung:

426 Upgrade Required

Um auf diese Seite zuzugreifen müssen Sie die URL https://rechnername.local:631/admin?op= ... onfirm=yes verwenden.

Nur werde ich dann sofort automatisch auf die verschlüsselte Verbindung umgeleitet, deswegen ist mir wohl nicht aufgefallen, dass es dann mit meiner hochgeladenen Config letztendlich auch über https läuft.
In meiner neuen cupsd.conf habe ich das geändert (Option "DefaultEncryption IfRequested")!

Warum sich bei dir dann aber CUPS aufhängt weiß ich auch nicht.
Du kannst ja mal in /var/log/cups/error_log nach einem Hinweis suchen (evtl. LogLevel auf von info auf debug stellen, wenn du keinen Hinweis findest).

edit PS:
Ich finde im Portscan auf den Server kein 443. Müßte dieser Port nicht offen sein, um den cupsd über https zu erreichen?

Nein, das ist normal, denn die Verschlüsselung läuft auch über Port 631, so sieht das bei mir aus:

Code: Alles auswählen

# netstat -tulpen | grep cupsd
tcp        0      0 0.0.0.0:631             0.0.0.0:*               LISTEN     0          10920      3694/cupsd
tcp6       0      0 :::631                  :::*                    LISTEN     0          10919      3694/cupsd
udp        0      0 0.0.0.0:631             0.0.0.0:*                          0          10923      3694/cupsd

Gruß,
Daniel

[Jogibär]

Hallo,

danke für Eure Hilfe.

Port 631 eingetragen und schon gings.

426 Upgrade Required -> habe ich auch ab und zu mal.

rlau,

brauchst Du die cupsd.conf noch ?


Jogibär

[Danielx]

angezeigt wird er zunächst, aber wenn ich Veränderungen vornehmen will, hängt sich das Web Interface auf … und ich vermute mal auch der cupsd. Er nimmt danach biz zu einem /etc/init.d/cupsys restart auch auf der Kommandozeile keine Befehle mehr entgegen.

Ich habe dazu gerade zufällig etwas Interessantes im ubuntuusers-Wiki gelesen, das damit zusammenhängen könnte:

Das SSL-Zertifikat wird nämlich erst dann erstellt, wenn es das erste Mal gebraucht wird, was zumindest auf älterer Hardware schon eine Zeitlang in Anspruch nimmt in der es scheint als hätte der Server sich aufgehängt.
(..)
Leider ist das Webfrontend in Dapper kaputt und hängt sich beim Versuch, ein Zertifikat zu erzeugen wirklich auf. Die Lösung ist, den Server anderweitig mit einem gültigen Serverzertifikat zu versorgen.

Vielleicht liegt das Problem bei dir auch nur an der Erstellung des Zertifikats?
Erstelle es doch mal manuell auf deinem Server:

Code: Alles auswählen

openssl req -new -x509 -keyout /etc/cups/ssl/server.key -out /etc/cups/ssl/server.crt -days 365 -nodes

Gruß,
Daniel

[rlau]

Hallo Danielx,

mit der letzten cupsd.conf von 14.01.2008 15:38:01 sind meine Problem endlich gelöst!! Die Webschnittstelle tut was sie soll und damit konnte ich auch flott die Treiber ausprobieren - und habe wieder einen Generic Postscript Printer gefunden, der meinen Lexmark E323 steuert.

Ich danke Dir sehr, daß hätte ich alleine sicher nicht hinbekommen!


Ich bitte um Verständnis, daß ich die Config nicht zurück bauen werde, um hppts mit einem selbst erstellten Zertifikat zu testen. Dazu ist es mir zu wichtig, daß ich hier aus dem Netz drucken kann.

Trotzdem: Wenn meine früheren Verbindungsversuche über https ein Zertifikat erzeugt hätten, dann müßte das doch laut Debianhandbuch in /etc/cups/ssl/ liegen, oder? Dieses Verzeichnis ist aber bis jetzt immer noch leer.

Code: Alles auswählen

mdj:/home/rlau# ls -l /etc/cups/ssl/
insgesamt 0

[rlau]

So, und nun habe ich dort das Zertifikat:

Code: Alles auswählen

mdj:/home/rlau# openssl req -new -x509 -keyout /etc/cups/ssl/server.key -out /etc/cups/ssl/server.crt -days 365 -nodes
Generating a 1024 bit RSA private key
.............++++++
................++++++
writing new private key to '/etc/cups/ssl/server.key'
-----
…
mdj:/home/rlau# ls -l /etc/cups/ssl/
insgesamt 8
-rw-r--r-- 1 root root 1196 2008-01-14 21:33 server.crt
-rw-r--r-- 1 root root  887 2008-01-14 21:33 server.key
mdj:/home/rlau# 

Viellicht mache ich mich doch noch mal an den https Test - aber heute nicht mehr.


Nochmals vielen Dank, ich hoffe ja immer, daß ich auch mal irgendwas beitragen kann. Vielleicht gibt's mal was auf nem Mac zu testen …

Rainer

[Danielx]

Freut mich, dass ich dir weiterhelfen konnte.

Wenn meine früheren Verbindungsversuche über https ein Zertifikat erzeugt hätten, dann müßte das doch laut Debianhandbuch in /etc/cups/ssl/ liegen, oder? Dieses Verzeichnis ist aber bis jetzt immer noch leer.

Ja, das spricht doch sehr für meine Vermutung!

Viellicht mache ich mich doch noch mal an den https Test - aber heute nicht mehr.

Ja, das fände ich sehr gut!
Wenn du ein Backup deiner cupsd.conf machst, gehst du ja keinerlei Risiken ein.

Gruß,
Daniel

[rlau]

So und nun auch hier die letzten Worte:

Heute Morgen ist die Hardware gar nicht mehr hochgefahren. Vielleicht hatte sie schon länger Macken und deswegen trat der Fehler mit https auf.
Meine Fähigkeiten Hardwarefehler am PC zu erkennen sind bescheiden. Aber auf Mac's gab es das Problem schon, daß beim Einsatz minderwertiger Speicher plötzlich Probleme bei einem Systemupgrade auftraten, weil der Arbeitsspeicher höher gefordert wurde. Die Folgen waren instabile Systeme mit völlig unspezifischen Fehlern. Vielleicht hatte mein Rechner bereits so einen instabilen Zwischenstatus, bevor er heute völlig den Geist aufgegeben hat.

Was ich damit eigentlich sagen will? Nun, der "https-Fehler" muß vielleicht nicht unbedingt vom cupsd gekommen sein - vielleicht war irgendwas nicht sauber installiert.

Ja - und den fehlenden Test mit den händisch angelegten Zertifikaten, den kann ich nun nicht mehr nachholen.

Es ist trotzdem ein gutes Gefühl zu wissen, daß da draußen meißtens Hilfe ist.
Ich fang also wieder von vorn an. Entweder, wenn ich den HW-Fehler beseitigt habe, oder mit einem neuen Rechner. Das übt.

Rainer

[rlau]

Allerletzte Worte:

Gerät ausgebaut, alle Peripherie abgezogen, Gerät geöffnet, unter Spannung gesetzt um zu messen, wo noch Spannung anliegt … zum Test noch mal den Startknopf gedrückt … und das Gerät bootet wieder.
Ich sollte mir Gedanken darüber machen, daß ich diesen Rechner als Server in meinem Netzwerk bezeichnet habe; das hat mit dem hier behandelten Thema nun aber wirklich nichts mehr zu tun - außer das ich den https-Test nun doch noch machen könnte.

Rainer

[Danielx]

Ich fang also wieder von vorn an. Entweder, wenn ich den HW-Fehler beseitigt habe, oder mit einem neuen Rechner.

So ist es eben leider manchmal. Kaum ist das eine Problem gelöst, taucht auch schon ein anderes auf...

Das übt.

Aber du siehst wenigstens auch etwas Positives daran.

Gruß,
Daniel

[Danielx]

außer das ich den https-Test nun doch noch machen könnte.

[rlau]

Mein Test der Webverbindung zu cupsd mittels https auf der Basis der händisch erzeugten Zertifikate hat funktioniert; die Verbindung reagiert aber deutlich träge. (Habe deshalb die cupsd.conf wieder zurückgesetzt zu "ohne https".)

Rainer

[Danielx]

Ok, danke für die Info!