swondemand-Seite wird nicht angezeigt.

[ueluekmen]

Hi,

Designfehler

das ist so nicht ganz richtig, das Modul tut genau das, wofür es designed und beauftragt wurde.

localhost:4441 das Zertifikat ist aber auf <hostname>.<domain> ausgestellt ! Wenn man das Zertifikat importiert wird trotz dem jeder Browser meckern. Außer man ruft die Seite mit <hostname>.<domain>:4441 auf

Dies werden wir nochmal prüfen, allerdings kann man im aktuellen opsi-client-agent-Paket das erstellen dieses Links unterdrücken, wenn man per Paket das Zertifikat importiert kann man auch den Link bzw. eine Verknüpfung anlegen.

User <-- unverschluesselt --> http://localhost:4441/swondemand <-- verschluesselt --> OPSI webservice

Dies stellt aus zwei Gründen keine Option dar:
1.) Ist diese Seite auch überall vom Netz zugänglich. Dies war der Wunsch damals vom beauftragenden Kunden, wenn ich mich richtig erinnere, damit er a) die Seite prüfen kann und b) auch dies fernsteuern kann. Einziger Unterschied ist, dass nur Zugriffe von localhost ohne Credentials durchgelassen werden.
2.) Würde dies bedeuten, man müsste einen eigenen Webservice oder mini-Webserver auf dem Client implementieren, das wäre über den clientagent allgemein kein Problem, aber man müsste ein zusätzlichen Port auf dem Client binden, das haben wir von Anfang an, in jedem Bereich von opsi versucht zu vermeiden, weil der nächste dann ankommt und meckert, weil er zuviele Ports bei seinen Freischaltungen beachten muss.

Wie ich schon vorher schrieb, wir können uns gerne gegen Geld über einen Auftrag eine Lösung für das Problem ausdenken, aber über den freien Support wird Grundsätzlich an dem Modul nichts verändert, es sei denn es ist ein Bug an der Stelle!

[tobias]

Hi,

Designfehler

das ist so nicht ganz richtig, das Modul tut genau das, wofür es designed und beauftragt wurde.

ja schon aber das mit dem Zertifikat ist nicht optimal gelöst. Aber ne andere Idee außer externe Anwendung hätte ich da auch nicht.
Und das wär dann ja wie du schreibst nicht im Sinne es ursprünglichen Auftraggebers.

localhost:4441 das Zertifikat ist aber auf <hostname>.<domain> ausgestellt ! Wenn man das Zertifikat importiert wird trotz dem jeder Browser meckern. Außer man ruft die Seite mit <hostname>.<domain>:4441 auf

Dies werden wir nochmal prüfen, allerdings kann man im aktuellen opsi-client-agent-Paket das erstellen dieses Links unterdrücken, wenn man per Paket das Zertifikat importiert kann man auch den Link bzw. eine Verknüpfung anlegen.

jo ich werds da noch einbauen. Wenn man standardmäßig den Hostname verlinkt muss man natürlich bedenken, dass dieser nicht mehr stimmt wenn man diesen ändern sollte.

Wie ich schon vorher schrieb, wir können uns gerne gegen Geld über einen Auftrag eine Lösung für das Problem ausdenken, aber über den freien Support wird Grundsätzlich an dem Modul nichts verändert, es sei denn es ist ein Bug an der Stelle!

Vollkommen verständlich. Mit dem Zertifikatsproblem kann ich jez leben. Hab ja eine Lösung gefunden.
Man könnte sich aber über die Seite selber sich noch unterhalten.
Mir fehlen da: Benutzer Gruppen & SoftwareGruppen
Eine lange Liste ist IMHO nicht so schön.

Ist aber eher ein nice to have als ein must have also glaub eher nicht das ich da zeitnah Geld für locker machen könnte.... OPSI selber hat ja schon 3 1/2 Jahre gedauert

[embl-structures]

User <-- unverschluesselt --> http://localhost:4441/swondemand <-- verschluesselt --> OPSI webservice

Dies stellt aus zwei Gründen keine Option dar:
1.) Ist diese Seite auch überall vom Netz zugänglich. Dies war der Wunsch damals vom beauftragenden Kunden, wenn ich mich richtig erinnere, damit er a) die Seite prüfen kann und b) auch dies fernsteuern kann. Einziger Unterschied ist, dass nur Zugriffe von localhost ohne Credentials durchgelassen werden.

...und das muesste man jetzt "lediglich" um das Feature ergaenzen, dass nur localhost ohne SSL zugreifen kann.

2.) Würde dies bedeuten, man müsste einen eigenen Webservice oder mini-Webserver auf dem Client implementieren, das wäre über den clientagent allgemein kein Problem, aber man müsste ein zusätzlichen Port auf dem Client binden, das haben wir von Anfang an, in jedem Bereich von opsi versucht zu vermeiden, weil der nächste dann ankommt und meckert, weil er zuviele Ports bei seinen Freischaltungen beachten muss.

Aber ein Webservice ist ja bereits implementiert, sonst koennte man nicht mit einem Browser auf localhost:4441 zugreifen. Es braucht auch keinen zusaetzlichen Port, "nur" die Moeglichkeit, ueber diesen einen Port auch ohne SSL zu kommunizieren.

Gut: Vielleicht unterschaetze ich den Implementationsaufwand fuer eine SSL/nicht-SSL Kommunikation ueber ein- und denselben Port und/oder ich habe ein groesseres Verstaendnisproblem, wie denn der lokale Webservice funktioniert. Bei uns ist es aber ein Fakt, dass die Browserwarnung bei sicher 50% der Benutzer dazu fuehrt, dass sie die Finger von swondemand lassen. Das finde ich sehr schade, denn der Service hat extrem viel Potential und m.E. ist es im Prinzip eines der besten Features von OPSI.

frank

[tobias]

Gut: Vielleicht unterschaetze ich den Implementationsaufwand fuer eine SSL/nicht-SSL Kommunikation ueber ein- und denselben Port und/oder ich habe ein groesseres Verstaendnisproblem, wie denn der lokale Webservice funktioniert. Bei uns ist es aber ein Fakt, dass die Browserwarnung bei sicher 50% der Benutzer dazu fuehrt, dass sie die Finger von swondemand lassen. Das finde ich sehr schade, denn der Service hat extrem viel Potential und m.E. ist es im Prinzip eines der besten Features von OPSI.

frank

Was hindert dich daran das Zertifikat zu importieren so wie ichs mit dem Paket beschrieben hab?

[ueluekmen]

Hi,

Vielleicht unterschaetze ich den Implementationsaufwand fuer eine SSL/nicht-SSL Kommunikation ueber ein- und denselben Port

sehe ich auch so

Meines Wissens, kann mich jetzt aber auch Irren, sind HTTP und HTTPS verschiedene Protokolle und können somit nicht über den selben Port bedient werden. Sonst hätte man sich im Internet auch nicht so die Arbeit gemacht und hätte zwei verschiedene Ports als Standardports definiert.

Nur weil der Browser keinen Port im normalen Internet anzeigt heißt das nicht, dass er keinen Benutzt:
http://localhost --> http://localhost:80
https://localhost --> https://localhost:443

Wir sind ja offen für Vorschläge, wenn es so eine Möglichkeit gäbe, hätten wir das schon in Betracht gezogen, aber das ist leider technisch not possible.

Einzige Möglichkeit die ich sehe ist, auch wie schon Tobias schrieb, dass Zertifikat vom clientagent importieren und den Link auf den FQDN vom Client legen. Im übrigen, wenn der Client einen neuen Namen bekommt, dann ist nicht nur der Link falsch, sondern dann muss in diesem Falle auch das Zertifikat erneuert und neu importiert werden.

Oder man baut sich (wie schon erwähnt) komplett eigene Zertifikate, die man selber Unterschreibt, dass ist um einiges komplizierter, bietet aber mehr flexibilität in der Anwendung.

Noch zum Schluss:

Man könnte sich aber über die Seite selber sich noch unterhalten.
Mir fehlen da: Benutzer Gruppen & SoftwareGruppen
Eine lange Liste ist IMHO nicht so schön.

Wie schon gesagt, wenn du gute Ideen hast und noch bisschen Geld locker machen kannst, können wir uns gerne darüber unterhalten

[tobias]

Wie schon gesagt, wenn du gute Ideen hast und noch bisschen Geld locker machen kannst, können wir uns gerne darüber unterhalten

Ideen habe ich viele nur Geld ist immer schwierig. Naja kommt halt auch immer auf die Summe drauf an

Aktuell ist es so:
Software wird der gruppe "Software_on_Demand" hinzugefügt und taucht im Kiosk auf

Meine Idee die das ganze recht Flexibel machen würde:
Nicht nur eine Software Gruppe sondern mehrere Software Gruppen die dann im Kiosk als Kategorien dargestellt werden
Könnte man z.B. so machen das alle Gruppen die mit dem Prefix SoD_ beginnen automatisch Kiosk Gruppen sind das SoD_ müsste dann natürlich im Kiosk Abgeschnitten werden so das nur die Kategorie angezeigt wird.

Berechtigungen könnte man ganz einfach via Host-Parameter setzen: Dort einfach die Gruppen angeben auf die der Lokale Webservice zugreifen darf.

[ueluekmen]

Ok, aber nur mal so... du hast schon verstanden, dass du jetzt auch schon bei den Hostparameter die:

software-on-demand.product-group-ids

mehrere Gruppen als Liste übergeben kannst und diesen (wie bei opsi-Hostparametern gewohnt) pro Client überschreiben kannst ?!

Einzig bei der gruppierten Darstellungen, da diese Seite intern aufgebaut wird, gibt es so etwas (noch) nicht.

Es wäre sogar denkbar den Webservice an einer bestimmten Stelle zu überladen und diese Gruppen dynamisch zu verteilen, aber dafür brauchts dann einen guten Grund und einen guten Programmierer oder eine Anfrage über den "bezahlbaren" Support!

Opsi setzt der Fantasie nur selten Grenzen

[tobias]

Ok, aber nur mal so... du hast schon verstanden, dass du jetzt auch schon bei den Hostparameter die:

software-on-demand.product-group-ids

mehrere Gruppen als Liste übergeben kannst und diesen (wie bei opsi-Hostparametern gewohnt) pro Client überschreiben kannst ?!

Einzig bei der gruppierten Darstellungen, da diese Seite intern aufgebaut wird, gibt es so etwas (noch) nicht.

Es wäre sogar denkbar den Webservice an einer bestimmten Stelle zu überladen und diese Gruppen dynamisch zu verteilen, aber dafür brauchts dann einen guten Grund und einen guten Programmierer oder eine Anfrage über den "bezahlbaren" Support!

Opsi setzt der Fantasie nur selten Grenzen

Das würde das Berechtigungs"problem" lösen. Aber Kategorien hab ich dadurch ja nicht das wäre ab einer gewissen anzahl an Softwareprodukten im Kiosk interessant.
Wie aufwändig wäre das ?
Ich spreche das intern mal an ob wir das brauchen ich wurde darauf auf jeden Fall schon mal angesprochen von einem Kollegen der diese lange Liste auch nicht so toll fand.

[ueluekmen]

so ein großer Aufwand ist das nicht, mach doch einfach mal ein Ticket mit der Anfrage auf und wir schätzen das einfach mal ab, dann hast du eine Hausnummer und kannst nochmal entscheiden, bzw. entscheiden lassen

[tobias]

eventuell nochmal zur Ergänzung.
Mein Workaround über einfach das Zertifikat importieren funktionierte nicht mehr - über <hostname>:4441 kam nun immer eine Passwortabfrage - warum das auf einmal kommt keine ahnung.

Ich habe daher mein Paket wiki/userspace:zertifikats_import abgeändert so das es ein komplett neues Zertifikat generiert welches sowohl auf den Hostnamen als auch auf Localhost (als alias) ausgestellt ist.
Das Zertifikat wird dann importiert und man ist die Meldung (jedenfalls in Browsern die auf den Windows Zertifikats speicher zurückgreifen) los.
Man muss nur beachten das OPSI das mit jeder client-agent Installation überschreibt und man daher das Paket erneut auf Setup setzen muss.

Vielleicht hilft das ja dem einen oder anderen