Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision |
de:shibidp3troubleshoot [2015/07/30 11:53] – wolfgang | de:shibidp3troubleshoot [2019/08/29 17:06] – [Grundsätzliche Vorgehensweise bei der Fehlersuche] Silke Meyer |
---|
======Troubleshooting====== | ~~NOTOC~~ |
* Shibboleth Wiki: [[https://wiki.shibboleth.net/confluence/display/IDP30/Troubleshooting|Seite]] ist im Aufbau begriffen | ====== Troubleshooting ====== |
* Loglevel hochsetzen und 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]]. | {{INLINETOC 2}} |
| |
| ===== Links ===== |
| |
| * [[https://wiki.shibboleth.net/confluence/display/IDP30/Troubleshooting|Troubleshooting-Seite]] im Shibboleth Wiki |
| |
| ===== Grundsätzliche Vorgehensweise bei der Fehlersuche ===== |
| * Setzen Sie das Loglevel auf DEBUG hoch. In vielen Fällen reicht es, dies für folgende drei Kanäle 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! | * 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: | 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> | <file properties /opt/shibboleth-idp/conf/idp.properties> |
# ... | # ... |
idp.xml.securityManager=org.apache.xerces.util.SecurityManager | idp.xml.securityManager=org.apache.xerces.util.SecurityManager |
# ... | # ... |
</file> | </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. |
| |
| |