Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:shibidp:troubleshooting [2023/06/07 10:55] – Java 17 erfordert Nashorn-Plugin auf IdP Silke Meyer
+++ de: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.
   * 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>
   * 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 166: / Zeile 166: @@
 ===== Problem mit Scripted Attributes =====
-Wenn die ScriptedAttributes aus Ihrer ''conf/attribute-resolver.xml''-Datei nicht mehr ausgeführt werden und Sie die Fehlermeldung "No scripting engine associated with scripting language javascript" bekommen, dann haben Sie wahrscheinlich auf Java 17 (bzw. JDK 15 oder höher) aktualisiert. Die Scripting Engine "Nashorn", mit der Javascript ausgeführt werden kann, muss in dem Fall über ein IdP-Plugin ergänzt werden: Ab der IdP-Version 4.2 können Sie das direkt mit folgendem Befehl tun:<code bash>root@idp:~# /opt/shibboleth-idp/bin/plugin.sh -I net.shibboleth.idp.plugin.nashorn</code>
+Wenn die ScriptedAttributes aus Ihrer ''conf/attribute-resolver.xml''-Datei nicht mehr ausgeführt werden und Sie die Fehlermeldung "No scripting engine associated with scripting language javascript" bekommen, dann haben Sie wahrscheinlich auf Java 17 (bzw. JDK 15 oder höher) aktualisiert. Die Scripting Engine "Nashorn", mit der Javascript ausgeführt werden kann, muss in dem Fall über ein [[https://shibboleth.atlassian.net/wiki/spaces/IDPPLUGINS/pages/1374027996/Nashorn|IdP-Plugin]] ergänzt werden: Ab der IdP-Version 4.2 können Sie das direkt mit folgendem Befehl tun:<code bash>root@idp:~# /opt/shibboleth-idp/bin/plugin.sh -I net.shibboleth.idp.plugin.nashorn</code>
 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 }}

troubleshooting debugging debug logging