Hallo Klaus,
CUPS verwendet meiner Meinung nach DBUS vor allem zur Integration mit PolicyKit bzgl. der administrativen Rechte. Falls also die Konfiguration von CUPS per Automaten / Konfigurationsdateien erfolgt, oder über die Web-Oberfläche, erwarte ich aktuell keine groÃen Einschränkungen.
Sollten sich die Benutzer jedoch direkt am CUPS-Server anmelden und dort mit CUPS interagieren, sähe die Situation anders aus. Aufgrund der erwähnten Randparameter gehe ich aktuell jedoch eher von einem separaten, direkt von SAP aus angesprochenen CUPS-Server aus.
Ich habe bei SUSE u.a. um Informationen gebeten, ob das Problem in der Ãbergabe des Benutzernamens an CUPS liegen kann (z. B. UTF8 erwartet, ISO8859-15 geliefert) - insofern könnte die Ursache dann tatsächlich auch im SAP liegen. DBUS aus der Kette zu nehmen wäre dann reine Problemvermeiderei, während ich eine Beseitigung der Ursachen bevorzugen würde.
Ich kann mir vorstellen, dass die Diskussion mit SUSE auch Daten erfordern kann, die nicht öffentlich gemacht werden sollen. Daher an dieser Stelle der Hinweis: Ich bin zwar kein SUSE-Mitarbeiter (ich arbeite für die NDE AG, die kundenspezifisch Lösungen für hochautomatisierten Systembetrieb bereitstellt), unterliege aber als “Knowledge Partner” einer strikten Verschwiegenheitsvereinbarung gegenüber SUSE. Alle Informationen, die z. B. in diesem Fall über mich laufen, werden entsprechend streng vertraulich behandelt. Solche Daten sollten dann auch nicht per Forum ausgetauscht werden, sondern z. B. per E-Mail (jmozdzen@nde.ag).
Sobald ich Antworten aus dem SUSE-Umfeld vorliegen habe, melde ich mich selbstverständlich umgehend.
Bzgl. der Lizenzen: Besteht Interesse an einem “upgrade” auf eine Lizenzierung, bei der auch direkt gegenüber SUSE Störungsmeldungen aufgemacht werden dürfen? Ist eigentlich nicht mein Thema, aber ich kann auf Wunsch auch diese Fragestellung weiterleiten.
Viele GrüÃe
Jens