Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
de:shibidp3troubleshoot [2019/08/29 17:11]
Silke Meyer
— (aktuell)
Zeile 1: Zeile 1:
-~~NOTOC~~ 
-====== Troubleshooting ====== 
-{{INLINETOC 2}} 
- 
-===== Links ===== 
- 
-  * [[https://​wiki.shibboleth.net/​confluence/​display/​IDP30/​Troubleshooting|Troubleshooting-Seite]] im Shibboleth Wiki 
- 
-===== Grundsätzliche Vorgehensweise bei der Fehlersuche ===== 
-  * Beobachten Sie die fortlaufenden Logdateien ''​idp-process.log''​ (Standardpfad:​ ''/​opt/​shibboleth-idp/​logs/''​) und das Tomcat-Log. 
-  * Setzen Sie das Loglevel auf DEBUG hoch. In vielen Fällen reicht es, dies für idp, ldap und opensaml zu tun:<​file properties /​opt/​shibboleth-idp/​conf/​logback.xml>​ 
-    <​variable name="​idp.loglevel.idp"​ value="​DEBUG"​ /> 
-    <​variable name="​idp.loglevel.ldap"​ value="​DEBUG"​ /> 
-    <​variable name="​idp.loglevel.messages"​ value="​INFO"​ /> 
-    <​variable name="​idp.loglevel.encryption"​ value="​INFO"​ /> 
-    <​variable name="​idp.loglevel.opensaml"​ value="​DEBUG"​ /> 
-</​file>​ 
-  * Stoßen Sie das Neuladen des Servlets manuell an (''​touch /​opt/​shibboleth-idp/​war/​idp.war''​) oder warten Sie bis zum automatischen Reload der Logging-Konfiguration. Die Reload-Intervalle sind in ''/​opt/​shibboleth-idp/​conf/​services.properties''​ konfigurierbar. Für die ''​conf/​logback.xml''​ sind standardmäßig 5 Minuten eingestellt. 
-  * Appender definieren in conf/​logback.xml (wird alle 5 Minuten neu geladen), siehe auch im Shibboleth Wiki unter [[https://​wiki.shibboleth.net/​confluence/​display/​IDP30/​LoggingConfiguration|LoggingConfiguration]] und [[https://​wiki.shibboleth.net/​confluence/​display/​IDP30/​AdvancedLogging|AdvancedLogging]]. 
-  * Werte in Property Files: Trailing Space Characters (Blank) unbedingt vermeiden. Ein Blank hinter einem Passwort macht dieses ungültig! 
- 
-Bei Java-Installationen,​ die nicht aus dem Sun/​Oracle-Kontext stammen, muss ggf. eine alternative Xerces Bean Class konfiguriert werden: 
- 
-<file properties /​opt/​shibboleth-idp/​conf/​idp.properties>​ 
-# ... 
-idp.xml.securityManager=org.apache.xerces.util.SecurityManager 
-# ... 
-</​file>​ 
- 
-===== opensaml::​SecurityPolicyException ===== 
- 
-"​opensaml::​SecurityPolicyException Message was signed, but signature could not be verified."​ 
- 
-Diese Fehlermeldung erscheint, wenn das Zertifikat, das Sie beim IdP in der Metadatenverwaltung publiziert haben, nicht mit dem Zertifikat übereinstimmt,​ das am IdP für die SAML-Kommunikation verwendet wird. Bei der IdP-Installation wird automatisch ein selbstsigniertes Zertifikat generiert und in ''​conf/​idp.properties''​ vorkonfiguriert. Dort müssen Sie die Pfadangaben zu Ihrem PKI-Zertifikat einstellen. 
- 
-Übrigens: Die Datei ''​metadata/​idp-metadata.xml''​ wird ebenfalls automatisch angelegt und mit den initialen Metadaten des IdP befüllt. In der DFN-AAI wird diese Datei aber ignoriert. Was dort drinsteht, ist also irrelevant. Für den IdP "​gelten"​ die Metadaten, die Sie in der Verwaltung einpflegen und aktuell halten. 
- 
-===== JPAStorage mit PostgreSQL ===== 
- 
-Ohne zusätzliche Konfiguration (ORM Workaround),​ wie beschrieben von den Schweizer Kollegen [[https://​www.switch.ch/​aai/​guides/​idp/​installation/#​ormxmlworkaround|https://​www.switch.ch/​aai/​guides/​idp/​installation/#​ormxmlworkaround]] speichert PostgeSQL die Werte als 'large Objects'​ in der Systemtabelle und schreibt in die Spalte '​value'​ nur die Link ID. 
- 
-Um die korrekte Funktion sicher zu stellen, **muss obiger Workaround dringend angewendet werden**. 
- 
-Leider sind hinterher die Daten der Datenbank nicht mehr kompatibel. D.h. vor dem Neustart des IdP müssen die Werte der Spalte ''​value'' ​ in der Tabelle ''​storagerecords'' ​ konvertiert werden. 
- 
-Eine Möglichkeit geht wie folgt direkt auf der schon vorhandenen Datenbank: 
- 
-DB als postgres Nutzer öffnen, da die Daten in der Systemtabelle ''​pg_largeobject'' ​ liegen:<​code>​ 
-psql -Upostgres shibboleth 
-</​code>​ 
- 
-Temporär werden die Werte decodiert mit den ID's in eine neue Tabelle geschrieben. Diese neue Tabelle gehört postgres, daher evtl. danach den Owner aktualisieren:​ 
- 
-<​code>​ 
-shibboleth=>​ create table new_table as (select context, id, value, encode(data,​ '​escape'​) as new_value from storagerecords left join pg_largeobject on oid(value) = loid); 
-shibboleth=>​ alter table new_table owner to shibboleth; 
-</​code>​ 
- 
-Jetzt anhand der values die ID's durch deren Inhalte aus der neuen Tabelle ersetzen: 
- 
-<​code>​ 
-shibboleth=>​ update storagerecords set value = new_table.new_value from new_table where storagerecords.value = new_table.value;​ 
-</​code>​ 
- 
-Die Temporäre Tabelle wieder löschen: 
- 
-<​code>​ 
-shibboleth=>​ drop table new_table; 
-</​code>​ 
- 
-Danach den IdP (tomcat) neu starten. Die Session und Attribute-Constent Daten sind weiterhin (wieder) verfügbar. 
- 
  
  • Zuletzt geändert: vor 11 Monaten