(DONE) GWES-Konfiguration über GWES-Portlet funktioniert nicht vollständig

Submitted by Andreas Felix on Tue, 20/03/2007 - 13:43.
Hi,
eine Konfiguration von GWES mit Hilfe des GWES-Portlets scheint nicht richtig zu funktionieren. Ich habe folgendes mit dem aktuellen Image beobachtet (Rev. 667):

Nach dem Aufruf von "Configuration/Test" in dem Portlet erscheint die Meldung, dass alles ok ist (The GWES is operating). Allerdings brechen dann Workflows, wie sie z.B. mit dem Povrayportlet generiert werden, ab. Es wird auch kein /tmp/.gwes-Verzeichnis angelegt. Ein Logfile des Tomcat ist zu finden unter http://wwwuser.gwdg.de/~afelix/tomcatlog_nonworking.log.

Wird die Konfiguration des GWES (nach tomcat-Neustart) allerdings über das Servlet ausgeführt, werden die Workflows abgearbeitet. Ein Log hiervon ist unter http://wwwuser.gwdg.de/~afelix/tomcatlog_working.log.
Ist das so beabsichtigt? Man muss ja bisher im Gegensatz zum Servlet beim Portlet kein Login/Passwort eingeben?!

Viele Grüße,
Andreas

myProxy vs. grid-proxy-init?

Ich habe das Gefühl, dass das mit der Umstellung auf myProxy zu tun hat. Tibor hat, glaube ich, abgeändert, dass das grid-credential /etc/x509up_gwes nun per myProxy und nicht per grid-proxy-init erzeugt wird. Es kann sein dass es da Inkompatibilitäten gibt. Eventuell hilft ein grid-proxy-init -old.

Ich schau mir das in den nächsten Tagen mal an. Vielleicht kann Tibor mal nachprüfen, was Credential-mäßig seit unserem Treffen im SVN geändert wurde.

Re: myProxy vs. grid-proxy-init?

Seit unserem Treffen habe ich 2 IG Skripte geändert, die mit Grid-Credentials was zu tun haben. Im Instant-Grid werden alle Benutzer vom 's_cluster-user.cert' Skript zertifiziert (sowohl der Knoppix, als auch die neuen Grid-Test-Benutzer, die mit dem Grid-Admin Portlet hergestellt wurden). Das Skript muss man als 'root' aufrufen und an dieser Stelle passiert ein X.509-Cert-Request vom lokalen IG-CA, Cert-Signing vom IG-CA Admin, grid-proxy-init (um lokale Proxy-Credentials zu haben) und myproxy-init (um "grid-wide" Proxy-Credentials zu haben z.B. für das Portal GridSphere). In Rev.661 habe ich die maximale Gültigkeit eines Proxy-Credentials, das aus MyProxy delegiert wurde, auf 1 Woche erhöht. In Rev.662 kam die Änderung, damit das Grid-Credential für GWES nicht einfach auf File-System-Ebene kopiert wird, sondern vom IG-MyProxy-Server delegiert wird (als Tomcat5-Benutzer wegen der Rechte und mit einer Woche Gültigkeit).
Wir haben die MyProxy delegierte Credentials für GWES bei mir zusammen nach dem Treffen ausprobiert, schien zu funktionieren. Wenn es doch problematisch ist, dann kann man etwas mit 'grid-proxy-init' basteln.

Gruss,
Tibor

PS: (wegen 'grid-proxy-init -old'):
Das RFC des Proxy-Credentials war ganz lang nur ein Draft und wurde manchmal geändert. Deshalb werden drei verschiedene Proxy Credentials/Zertifikaten vom Globus Toolkit unterstüzt:
• Old: legacy proxy certificates, abgelehnt
• GT4 Default: "fast" RFC-fähig, aber abgelehnt
• Fully RFC-fähig: sollte irgendwann das GT4-Default werden
Es gibt eine Zusammenfassung irgendwo auf der Globus-Seite über das Thema: was ist unterschiedlich zwischen Globus-GSI Implementation und Standards von IETF, GGF, usw. Jetzt finde ich das nicht, aber später kann ich noch hier linken.

GridSphere-Konfiguration und WS-GRAM

So, ich konnte jetzt das Problem zumindest mal reproduzieren. Tatsächlich, wenn man direkt GridSphere startet und dann einen WS-GRAM-Workflow startet, erhält man
org.globus.common.ChainedIOException: Authentication failed 
[Caused by: Failure unspecified at GSS-API level 
[Caused by: Bad certificate (The signature of 'O=org,OU=Instant-Grid,OU=TestGrid,CN=host/server'
 certificate does not match its issuer)]]
Wenn ich das während der GridSphere-Konfiguration für den GWES generierte Zertifikat (als Nutzer tomcat5) anschaue bekomme ich
server:1 12:08:11 ~ $ grid-proxy-info -debug -f /tmp/x509up_gwes
subject  : /O=org/OU=Instant-Grid/OU=TestGrid/CN=Knoppix User/CN=1263889371/CN=1613269145/CN=832246490
issuer   : /O=org/OU=Instant-Grid/OU=TestGrid/CN=Knoppix User/CN=1263889371/CN=1613269145
identity : /O=org/OU=Instant-Grid/OU=TestGrid/CN=Knoppix User
type     : Proxy draft (pre-RFC) compliant impersonation proxy
strength : 1024 bits
path     : /tmp/x509up_gwes
timeleft : 167:17:04  (7.0 days)
Zum Vergleich das Zertifikat vom Nutzer knoppix:
server:1 12:08:18 tmp $ grid-proxy-info -debug -f /tmp/x509up_u1000
subject  : /O=org/OU=Instant-Grid/OU=TestGrid/CN=Knoppix User/CN=1238573057
issuer   : /O=org/OU=Instant-Grid/OU=TestGrid/CN=Knoppix User
identity : /O=org/OU=Instant-Grid/OU=TestGrid/CN=Knoppix User
type     : Proxy draft (pre-RFC) compliant impersonation proxy
strength : 512 bits
path     : /tmp/x509up_u1000
timeleft : 11:16:49
Die Unterschiede sind klein, aber vielleicht relevant für das Submitten von Jobs per WS-GRAM. Ich würde vorschlagen, dass wir sicherheitshalber ausschließlich das per "grid-proxy-init" generierte Zertifikat verwenden.


Allerdings habe ich gerade festgestellt, dass nach einem tomcat-restart wieder alles funktioniert. Das spricht widerum gegen meine These mit den falschen Zertifikaten:-(

Zertifikate ebenso, wenn es funktioniert

Hi,
gegen die These spricht außerdem, dass die Zertifikate genauso aussehen, wenn man die Konfiguration nur über das Servlet und nicht über das Portlet durchführt. Und dann funktioniert WS-GRAM und Co ja.

Gruß,
Andreas

Die Lösung

Lösung des Classloader-Problems: Bitte folgende Dateien beim Installieren löschen:
rm ~tomcat5/webapps/gwes/WEB-INF/lib/cog-jglobus_gt-4.0.1.jar
rm ~tomcat5/webapps/grdb/WEB-INF/lib/cog-jglobus.jar
Die Klasse "GlobusGSSContextImpl" ist bereits in common/lib vorhanden und sollte nur von dort geladen werden!


Bitte den Fehler auf "DONE" setzen, wenn der Bug behoben wurde.