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:shibidp:troubleshooting [2023/06/07 11:02] – [Problem mit Scripted Attributes] Link zum Plugin ergänzt Silke Meyerde:shibidp:troubleshooting [2025/10/30 09:43] (aktuell) – [Grundsätzliche Vorgehensweise bei der Fehlersuche] Doreen Liebenau
Zeile 13: Zeile 13:
   * Beobachten Sie die fortlaufenden Logdateien ''idp-process.log'' (Standardpfad: ''/opt/shibboleth-idp/logs/'') und das Tomcat-Log.   * Beobachten Sie die fortlaufenden Logdateien ''idp-process.log'' (Standardpfad: ''/opt/shibboleth-idp/logs/'') und das Tomcat-Log.
   * Setzen Sie das Loglevel auf DEBUG hoch. Warnungen und Fehler bekommen Sie auch so zu sehen, aber z.B. die Inhalte der übertragenen SAML-Assertions nicht. In vielen Fällen reicht es, dies für idp, messages und encryption zu tun:<file properties /opt/shibboleth-idp/conf/logback.xml>   * Setzen Sie das Loglevel auf DEBUG hoch. Warnungen und Fehler bekommen Sie auch so zu sehen, aber z.B. die Inhalte der übertragenen SAML-Assertions nicht. In vielen Fällen reicht es, dies für idp, messages und encryption zu tun:<file properties /opt/shibboleth-idp/conf/logback.xml>
-    <variable name="idp.loglevel.idp" value="DEBUG" /> +    <variable name="idp.loglevel.idp" value="${idp.loglevel.idp:-DEBUG}" /> 
-    <variable name="idp.loglevel.ldap" value="INFO" /> +    <variable name="idp.loglevel.ldap" value="${idp.loglevel.ldap:-WARN}" /> 
-    <variable name="idp.loglevel.messages" value="DEBUG" /> +    <variable name="idp.loglevel.messages" value="${idp.loglevel.messages:-DEBUG}" /> 
-    <variable name="idp.loglevel.encryption" value="DEBUG" /> +    <variable name="idp.loglevel.encryption" value="${idp.loglevel.encryption:-DEBUG}" /> 
-    <variable name="idp.loglevel.opensaml" value="INFO" /> +    <variable name="idp.loglevel.opensaml" value="${idp.loglevel.opensaml:-INFO}"/> 
-    <variable name="idp.loglevel.props" value="INFO" /> +    <variable name="idp.loglevel.props" value="${idp.loglevel.props:-INFO}" /> 
-    <variable name="idp.loglevel.httpclient" value="INFO" />+    <variable name="idp.loglevel.httpclient" value="${idp.loglevel.httpclient:-INFO}" />
 </file> </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.   * 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.
Zeile 169: Zeile 169:
 Weder eine Konfiguration noch das Aktivieren eines Modules sind nötig. Weder eine Konfiguration noch das Aktivieren eines Modules sind nötig.
  
-===== 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 PostgreSQL die Werte als 'large Objects' in der Systemtabelle und schreibt in die Spalte 'value' nur die Link ID. +{{tag> troubleshooting debugging debug logging }}
- +
-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. +
- +
-{{tag>idp4 troubleshooting debugging debug logging }}+
  • Zuletzt geändert: vor 2 Jahren