Hi Jörg und Johannes, vielen Dank nochmal für Eure Anregungen, die zu Lösung meines Problems viel beigetragen haben! Joerg Thuemmler schrieb:
Thomas Michalka schrieb: ...
Zusammenfassend bleiben also folgende Fragen:
1) Wie erlaubt man uneingeschränkten Zugriff auf den Druck-Server einer SuSE 7.3 / cups 1.1.10 im LAN (hier auf helix)?
2) Wie erlaube ich uneingeschränkten Zugriff auf den neuen Druck-Server einer oS-11.2 / cups 1.3.11 im LAN (hier auf helix)? ^^^^^ Den Host-Namen hatte ich hier falsch: muss terrix heißen.
Wüsste ich 2), dann bräuchte ich 1) nicht mehr zu lösen.
Hi,
das sollte eigentlich bei beiden gleich sein:
Bei beiden Fällen möchte ich "uneingeschränkt" relativieren, d.h. beschränkt wissen auf Root und das LAN. Zum obigen Fall 1) (CUPS-Server * 1.1.10 * auf helix): ------------------------------------------------------ Der Grund, warum ich diesen nur von einem einzigen Rechner erreichen und administrieren konnte, war, dass ich in /etc/cups/cupsd.conf folgende Einträge hatte: <Location /> Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 192.168.x.y Allow From .domain.local </Location> <Location /admin> AuthType Basic AuthClass System Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 192.168.x.y Allow From .domain.local </Location> Eigentlich hätte ich durch die jeweils letzten Zeile vor </Location> Zugriff von allen Rechnern meiner lokalen Domain haben sollen, aber es war ein dafür entscheidender Eintrag falsch gesetzt bzw. 'falsch' voreingestellt, nämlich HostNameLookups Off (default) Der hätte auf 'On' gesetzt sein müssen, was ich aber vor fast zwei Jahren schon übersehen und nur nicht bemerkt habe, weil ich immer nur von der Adresse 192.168.x.y aus administriert habe, und das auch nur extrem selten. Apropos "übersehen": Ich hätte eher erwartet, dass ein Eintrag, wie "Allow From .domain.local" entsprechende Hostname Lookups impliziert. Ich habe den Kommentar in cupsd.conf offenbar nicht gelesen -- Asche auf mein Haupt ... ;-) Diese implizite Setzung könnte in den Versionen Realität geworden sein, siehe meine Erfahrungen mit diesen Versionen unten.
wenn, wie Du sagst, auf helix http://localhost:631 geht, mußt Du dort unter "Verwaltung" auf jeden Fall freigeben (Häkchen setzen): - "Verteile publizierte Drucker welche mit diesem System verbunden sind" wenn Du auch auf Jobs etc. zugreifen willst: - "Erlaube entfernte Verwaltung"
Zum obigen Fall 2) (CUPS-Server * 1.3.11 * auf terrix): ------------------------------------------------------- Obwohl ich, wie ich schon schrieb, die von Dir genannten Settings eingestellt habe, konnte ich nicht remote auf diesen Server zugreifen (403 Forbidden schon bei der Startseite). Nachdem ich die Einträge in den Locations so geändert habe, wie sie in der cupsd.conf des CUPS-Servers 1.1.10 auf helix stehen, klappt's auch beim terrix mit dem Remote-Zugriff. Das gilt in gleicher Weise für CUPS 1.3.7 auf neptix. Noch etwas bemerkenswertes, was ich nicht verstehe: Beide CUPS-Server auf terrix (1.3.11) und neptix (1.3.7) konnten zunächst nur die Startseite http://<rechner>.domain.local:631 an den Browser in korrekter Darstellung (die Links funktionierten dennoch) liefern, wenn 'HostNameLookups Off' eingestellt war. Seiten, wie http://<rechner>.domain.local:631/admin wurden falsch dargestellt, so, als wenn CSS-Dateien nicht gefunden wurden. Mit ausschließlicher Verwendung von IP-Nummern anstatt FQHNs hat es dann aber funktioniert. CUPS 1.3.7 und 1.3.11 leiten bei Eingabe obiger Admin-Adresse auf die entsprechende SSL-verschlüsselte Seite um (wohl wegen Encryption IfRequested), wobei bei 1.3.11 das Umleitungsziel anders lautet, nämlich https://192.168.x.y:631/admin. Bei CUPS 1.3.7 wird der FQHN nicht durch die zugehörige IP-Nummer ersetzt, weshalb die Darstellung auch solcher Seiten falsch war. Erst, wenn 'HostNameLookups On' eingestellt war, war die Darstellung der Seiten korrekt. Seltsamerweise war dies dann nicht mehr der Fall für Web-Adressen _mit_ IP-Nummer -- und dies reproduzierbar! CUPS 1.3.11 konnte jetzt also seine Web-Seiten nicht mehr korrekt liefern, während es bei CUPS 1.3.7 funktionierte, weil hier ja das Umleitungsziel https://<rechner>.domain.local lautet. Mit der Adresse http://localhost:631/admin war die Darstellung immer korrekt, aber halt nur lokal. Dann wurde es aber seltsam: Mittlerweile werden alle Web-Seiten beider CUPs-Server remote korrekt dargestellt, und zwar unabhängig von der Web-Adresse und unabhängig von http oder https. Ich kann 'HostNameLookups' nach Belieben ein und ausschalten, egal ob ich die CUPS-Server-Web-Seiten numerisch oder namentlich, ob SSL-verschlüsselt abfrage oder nicht -- das habe ich eigentlich von Haus aus so erwartet, nur: Warum nicht gleich so?
Natürlich muss bei den Druckern dann auch "Drucker publizieren" eingestellt sein, sonst kannst Du den von außen nicht sehen
Das gibt es in Version 1.1.10 noch nicht als expliziten Schalter bei den einzelnen Druckern (Menü 'Drucker'), wie das in 1.3.x der Fall ist.
außerdem solltest Du mal die /etc/cups/cupsd.conf mal durchsehen. Die Optionen dort sind relativ selbsterklärend.
Nachdem ich das nun, wenn auch nicht erschöpfend, getan habe, verstehe die Wirkung etlicher Direktiven noch nicht, und das trotz Doku -- die finde ich eher zu knapp :-( Aber ich habe mich auch noch nicht durch alles durchgearbeitet. Übrigens war bei der 1.1.10 die mitgelieferte Config wesentlich gesprächiger als bei den Versionen 1.3.x und ich habe daraus fast mehr gelernt, als aus der mitgelieferten Doku, zumindest bei den von mir benutzten Konfigurationsdirektiven. Dennoch kann ich jetzt 1. von allen Rechnern über den alten CUPS-Server (1.1.10) drucken, 2. von allen Rechnern aus den alten CUPS-Server (1.1.10) verwalten, 3. einen neuen CUPS-Server (1.3.11) mit der Funktionalität von 1. und 2. einrichten, was das Ziel war :-D Ich bedanke mich nochmals herzlich für Eure Anregungen. Viele Grüße, Tom P.S.: Jetzt muss ich /nur/ noch die PPD meines neuen Netzwerkdruckers verstehen lernen, denn da gibt es einige sehr kryptisch formulierte Treiberoptionen. Außerdem habe ich Probleme mit einer zweiten Queue mit Tonerspareinstellungen für meinen Netzwerkdrucker; Aufträge darüber werden stillschweigend und noch vor dem Druck abgebrochen, obwohl das Drucken über die erste Queue geht, auch wenn ich im KDE-Druckdialog die Treibereinstellungen auf die Werte ändere, die ich in der zweiten Queue voreinstelle. Also scheint es nicht an den PPD-Einstellungen zu liegen -- aber das ist ein anderes Thema, wo vielleicht auch der Support des Herstellers mitwirken muss. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org