Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:shibidp3troubleshoot [2016/07/04 14:59] – Petra Berg
+++ de:shibidp3troubleshoot [2019/07/31 15:47] – Silke Meyer
@@ Zeile 1: / Zeile 1: @@
-======Troubleshooting======
+====== Troubleshooting ======
   * Shibboleth Wiki: [[https://wiki.shibboleth.net/confluence/display/IDP30/Troubleshooting|Seite]] ist im Aufbau begriffen
   * 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]].
@@ Zeile 5: / Zeile 6: @@
 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
 # ...
@@ Zeile 12: / Zeile 14: @@
 ===== JPAStorage mit PostgreSQL =====
-Ohne zusätzliche Konfiguration (ORM Workaround), wie beschrieben von den Schweizer Kollegen [[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.
+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.
-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:
+DB als postgres Nutzer öffnen, da die Daten in der Systemtabelle ''pg_largeobject''  liegen:<code>
-  psql -Upostgres shibboleth
+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:
-  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>
+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:
-  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:
+shibboleth=> update storagerecords set value = new_table.new_value from new_table where storagerecords.value = new_table.value;
-  shibboleth=> drop table new_table;
+</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.