Das heutige Thema beschäftigt mit häufigen ORDS Problemen und Fehlern. Da ich schon mehrere Stunden/Tage auf der Suche nach Fehlern mit der Oracle ORDS Schnittstelle verbracht habe, möchte ich versuchen etwas zu den möglichen Lösungen beizutragen...
Übersicht:
0. Debugging einschalten
1. Datenbankbenutzer prüfen
2. Problem: Die Bilder-/ CSS-/ Java-Script-Dateien fehlen, oder liegen im falschen Verzeichnis.
3. Es kommt die Fehlermeldung, dass die Version der Bilder, nicht zur Version von APEX passt.
4. Die "ords.war"-Datei funktioniert in Verbindung mit Tomcat einfach nicht:
5. Eine ominöse CSS Datei wird nicht gefunden z.B. 56437564376.css
6. Mehrere Webserver belegen den gleichen Port
7. Ein oder mehrere Benutzer sind gesperrt oder das Passwort ist abgelaufen
8. defaults.xml Datei nicht lesbar/vorhanden
9. ORDS komplett neu aufsetzen
10. Fehler 404 The request could not be mapped to any database
11. 404 Not Found Die Anforderung konnte keiner Datenbank zugeordnet werden
12. Fehler 503 Service Unavailable
13. Internal Server Error 500
0. Debugging einschalten
Es hat sich bewährt, bei Problemen rund um APEX, REST oder dem Webserver zuerst mal Debugging einzuschalten:
Gehen Sie dazu in die Datei defaults.xml (im Ordner den sie bei der ersten Frage der Installation von ords.war angegeben haben),
dort stehen u.a. evtl folgende Zeilen:
<entry key="db.connectionType">basic</entry>
<entry key="db.hostname">my_db_server</entry>
<entry key="db.port">1521</entry>
<entry key="db.sid">o23c</entry>
Wir ergänzen die folgenden Zeilen, bzw. editieren sie, falls bereits vorhanden.
<entry key="debug.debugger">true</entry>
<entry key="debug.printDebugToScreen">true</entry>
<entry key="log.logging">true</entry>
<entry key="log.maxEntries">500</entry>
Wenn Sie Tests machen möchten, ob die Verbindung funktioniert, können sie auch das Kommandozeilen Tool curl verwenden:
curl http://myserver:8080/ords
1. Datenbankbenutzer prüfen
Prüfen Sie die Verfügbarkeit der DB-Benutzer mit folgenden SELECT:
SELECT
username, lock_date, expiry_date, account_status
FROM
dba_users
WHERE
username IN (
'ANONYMOUS',
'APEX_PUBLIC_USER',
'APEX_LISTNER',
'APEX_REST_PUBLIC_USER',
'ORDS_METADATA',
'ORDS_PUBLIC_USER'
)
ORDER BY 1;
Da sollte dann z.B. folgendes als Rückgabe erscheinen:
USERNAME | LOCK_DATE | EXPIRY_DATE | ACCOUNT_STATUS |
ANONYMOUS | 28.04.2023 | | OPEN |
APEX_PUBLIC_USER | 30.04.2023 | | OPEN |
APEX_REST_PUBLIC_USER | 30.04.2023 | | OPEN |
ORDS_METADATA | 30.04.2023 | 30.04.2023 | OPEN |
ORDS_PUBLIC_USER | 30.04.2023 | | OPEN |
Erklärung:
Wenn Sie das interne Gateway (Oracle EPG) via Oracle Listener ohne Webserver verwenden, muss der Benutzer ANONYMOUS den Status OPEN besitzen.
Wenn ein Webserver verwendet wird, kann der Benutzer ANONYMOUS gesperrt sein (LOCKED), jedoch muss der Benutzer APEX_PUBLIC_USER auf OPEN stehen.
Wenn Sie eine höhere APEX Version besitzen (5.1) werden viele interne Funktionen (auch das Bereitstellen von Bildern, CSS und Javascript z.B. bei den Application Files) via REST Schnittstellen zur Verfügung gestellt. Hier muss auch der Benutzer APEX_REST_PUBLIC_USER entsperrt sein.
Sollte die Spalte LOCK_DATE bereits ein Datum besitzen, muss der Benutzer entsperrt werden.
ALTER USER <user> ACCOUNT UNLOCK;
Sollte die Spalte EXPIRY_DATE schon in der baldigen Zukunft liegen, sollte die Account-Lebensdauer auch gleich verlängert werden:
a, Sollte das gleiche Passwort verwendet werden, hier am Beispiel mit Benutzer ANONYMOUS:
select q'!ALTER USER anonymous IDENTIFIED BY VALUES '!'||spare4||q'!' ACCOUNT UNLOCK;!'
from sys.user$
where name='ANONYMOUS';
Führen Sie das zurückgegebene Statement aus, dann wird die Lebensdauer des Accounts verlängert.
b, wenn Sie das Passwort ändern möchten (Achtung dann muss es auch in einer ORDS XML Datei synchron geändert werden!
ALTER USER ORDS_PUBLIC_USER IDENTIFIED BY owiegutdasniemandmeinpwdweiss;
2. Problem: Die Bilder-/ CSS-/ Java-Script-Dateien fehlen, oder liegen im falschen Verzeichnis.
Die Fehlermeldung lautet dann z.B.
There is a problem with your enviroment because the Application Files have not been loaded.
Prüfen Sie bitte, ob ein Ordner mit Namen "i" im Verzeichnis
.. tomcat/WebApps/ROOT
liegt, ansonsten könnte die Seite (weil die CSS-Dateien nicht geladen werden) defekt aussehen.
Wenn Sie zusätzlich den Apache als ReverseProxy einsetzen, müssen die Dateien im Apache docRoot Verzeichnis liegen (bei uns z.B. in /var/www/html)
3. Es kommt die Fehlermeldung, dass die Version der Bilder, nicht zur Version von APEX passt.
Da muss einfach der Browser Cache geleert werden. Oder Sie haben die Bilder beim Patchen nicht richtig mit den restlichen Dateien zusammenkopiert
Hinweis: Für Apex 21.2.6 sollten 16.730 Dateien im Bild-Ordner (i) liegen
In Version 22.2 sind es 15731 Dateien und 1332 Ordner = 17.063 Dateien
4. Die "ords.war"-Datei funktioniert in Verbindung mit Tomcat einfach nicht:
Prüfen Sie die Konsistenz der ords.war Datei mit:
java -jar ords.war validate
oder
java -jar ords.war validate --database o21c
Dann sollte folgende Ausgabe erscheinen:
Name des Datenbankservers eingeben [localhost]:
Listener-Port der Datenbank eingeben [1521]:
Datenbankservicename eingeben [o21c]:
Erfordert SYS AS SYSDBA, um das Oracle REST Data Services-Schema zu verifizieren.
Datenbankkennwort für SYS AS SYSDBA eingeben:
Kennwort bestätigen:
Informationen werden abgerufen.
Retrieving information.
Oracle REST Data Services will be validated.
Validating Oracle REST Data Services schema version 21.1.0.r3541002
... Log file written to /root/ords_validate_core_2021-01-16_133103_00877.log
Completed validating Oracle REST Data Services version 21.1.0.r3541002. Elapsed time: 00:00:04.798
Sie können natürlich auch noch die dazugehörige Log-Datei analysieren. Da sollte dann z.B. u.a. folgendes zu finden sein:
INFO: 08:27:22 Validating objects for Oracle REST Data Services.
VALIDATION: 08:27:22 Starting validation for schema: ORDS_METADATA
VALIDATION: 08:27:22 Validating objects
VALIDATION: 08:27:23 Validating ORDS Public Synonyms
VALIDATION: 08:27:24 Total objects: 259, invalid objects: 0
VALIDATION: 08:27:24 72 INDEX
VALIDATION: 08:27:24 1 JOB
VALIDATION: 08:27:24 11 PACKAGE
VALIDATION: 08:27:24 11 PACKAGE BODY
VALIDATION: 08:27:24 43 PUBLIC SYNONYM
VALIDATION: 08:27:24 1 SEQUENCE
VALIDATION: 08:27:24 14 SYNONYM
VALIDATION: 08:27:24 27 TABLE
VALIDATION: 08:27:24 26 TRIGGER
VALIDATION: 08:27:24 19 TYPE
VALIDATION: 08:27:24 6 TYPE BODY
VALIDATION: 08:27:24 28 VIEW
VALIDATION: 08:27:24 Validation completed.
INFO: 08:27:24 Completed validating objects for Oracle REST Data Services.
Ein Problem, was mir vier Wochen Suche beschert hat. Wir hatten bei der Installation von ORDS immer das Problem, dass sich die Installation an einer Stelle aufgehängt hatte. Sie hing ca. 15 min und stüzte dann ab mit " IO Error: Connection reset by Peer".
Das Problem war, dass Java auf unserem System (CentOS 7) mit "/dev/random" nicht genügend viele Zufallszahlen berechnen konnte und stattdessen "/dev/urandom" nehmen musste.
Dazu müssen Sie bei der Installation folgendes zuätzlich angeben:
java -Djava.security.egd=file:///dev/urandom -jar ords.war
Allerdings kann man auch dem Pool der Zufallszahlen von "/dev/random" etwas mehr Entropie verleihen und daher weiterhin "/dev/random" nutzen. Dazu installiert man sich ein entsprechendes Tool:
yum install haveged
systemctl enable haveged; systemctl start haveged;
5. Eine ominöse CSS Datei wird nicht gefunden z.B. 56437564376.css
Hier war eine fehlerhafte ords Installation schuld, es fehlte die Datei apex_rt.xml
Prüfen Sie nach der Installation, ob die folgenden Dateien im angegebenen Config Verzeichnis liegen:
- apex_al.xml <= Diese Datei wird vom APEX_LISTENER benötigt !!
- apex_pu.xml <= Diese Datei wird vom ORDS_PUBLIC_USER benötigt !!
- apex_rt.xml <= Diese wird vom APEX_REST_PUBLIC_USER benötigt !!
- apex.xml <= Diese Datei wird vom APEX_PUBLIC_USER benötigt !!
Die Dateien sehen wie folgt aus (und können auch manuell erstellt werden):
apex.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>Saved on Sat Oct 22 11:54:56 CEST 2022</comment>
<entry key="db.password">@05939D2C32A74181B5BCBA375C0794A111</entry>
<entry key="db.username">APEX_PUBLIC_USER</entry>
</properties>
apex_al.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>Saved on Sat Oct 22 11:54:56 CEST 2022</comment>
<entry key="db.password">@05B2B32CE300417F3AE4BAD1112826CB84E</entry>
<entry key="db.username">APEX_LISTENER</entry>
</properties>
apex_rt.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>Saved on Sat Oct 22 11:54:56 CEST 2022</comment>
<entry key="db.password">@0577928598D4BAB7423441C0D8DF0855F</entry>
<entry key="db.username">APEX_REST_PUBLIC_USER</entry>
</properties>
apex_pu.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<comment>Saved on Sat Oct 22 11:54:56 CEST 2022</comment>
<entry key="db.password">@05651DD1203D235C56A0585BC871A336A2</entry>
<entry key="db.username">ORDS_PUBLIC_USER</entry>
</properties>
Fehlerhafte / fehlende Dateien weden auch in der log Datei catalina.out angezeigt:
Wenn Sie übrigens das Passwort für einen dieser 4 Bebnutzer geändert haben, sollten Sie das hier in den Dateien auch durchführen. Geben Sie dazu das Passwort im KLARTEXT mit einem führenden ! in die Datei ein.
Also wenn ihr Passwort lautet: Suchmich2023## schreiben Sie in die Datei:
<entry key="db.password">!Suchmich2023##</entry>
<entry key="db.username">APEX_REST_PUBLIC_USER</entry>
Wenn Sie dann den TomCat Webserver durchbooten, sollte das Passwort wieder verschlüsselt mit einem führenden @ in der Datei stehen
systemctl stop tomcat && systemctl start tomcat
Sollte die Verschlüsselung nicht funktioniert haben, prüfen Sie doch mal bitte ob es das richtige Verzeichnis war in dem Sie die Datei editiert haben und ob TomCat schreibrechte auf dem Ordner/ den Dateien besitzt !
Bei uns stand wegen der fehlenden apex_rt.xml Datei im Logfile vom Tomcat (Datei: catalina.out):
Caused by: oracle.dbtools.url.mapping.TargetNotAvailableException: The connection pool named: apex_rt does not exist
at oracle.dbtools.url.mapping.db.PoolInjector.inject(PoolInjector.java:60)
Eine CSS Datei des Theme Rollers konnte auf einem Server teilweise nicht mehr gefunden werden. Teilweise ist immer spannend ...
Ein Blick in die catalina.out brachte etwas Licht ins Dunkel: Einige ORDS_METADATA Views waren invalid- Bei genauerer Betrachtung der Views, stellte sich heraus, dass die dazu passenden Tabellen gar nicht (mehr) da waren.
Nur wo werden diese angelegt? Nach einiger Suche habe ich beim Auspacken des ords.war Files die Datei ords_database.objects.sql im Ordner scripts/install/core gefunden.
Nachdem das Skript nochmal installiert wurde (bitte im Schema ORDS_METADATA) lief wieder alles perfekt.
Sicherheitshalber kann man natürlich einen Zusatzcheck durchführen (hier mir ORDS Version 19.4 (Stand 15.03.2020))
SELECT
object_type, COUNT(valid), COUNT(invalid)
FROM
(
SELECT object_type,
CASE
WHEN status = 'VALID' THEN 1
END AS valid,
CASE
WHEN status <> 'VALID' THEN 1
END AS invalid
FROM
dba_objects
WHERE
owner = 'ORDS_METADATA'
)
GROUP BY
object_type
ORDER BY 1;
Das Ergebnis sollte in 19.4 (für 21.2 in Klammern) dann so aussehen:
OBJECT_TYPE VALID INVALID
INDEX 75 (86) 0
JOB 1 (1) 0
LOB 3 (3) 0
PACKAGE 12 (20)0
PACKAGE BODY 12 (19)0
PROCEDURE 1 (1)0
SEQUENCE1 (1)0
SYNONYM 14 0
TABLE 27 (30)0
TRIGGER 27 (30)0
TYPE 20 (20)0
TYPE BODY 6 (6)0
VIEW28 (34)0
6. Mehrere Webserver belegen den gleichen Port
Prüfen Sie, ob das Oracle EPG evtl. den gleichen Port, wie Ihr Webserver belegt:
SELECT dbms_xdb.gethttport FROM dual;
Falls es der gleiche Port wie im Webserver ist, können Sie ihn wechseln:
EXEC dbms_xdb.sethttpport(0); -- Ausschalten des Datenbank Ports
EXEC dbms_xdb.sethttpport(9090); -- Anderer Port
oder unter Linux auf OS Ebene:
netstat -tulpn | grep 8080
7. Ein oder mehrere Benutzer sind gesperrt oder das Passwort ist falsch bzw. abgelaufen:
Benutzer APEX_PUBLIC_USER
Webserver Fehler: 503 Service Unavailable
Wenn Debugging eingeschalten ist, dann auch noch:
Der Verbindungspool namens |apex|rt| ist aufgrund der folgenden Fehler nicht korrekt konfiguriert: ORA-28000: Account ist gesperrt.
Witzigerweise kann die Fehlermeldung auch erscheinen, wenn das Passwort falsch ist!
Wenn Debugging ausgeschalten ist, bekommen Sie den Fehlertext:
Benutzer oder Kennwort für den Verbindungspool namens |apex|| ist ungültig oder abgelaufen, oder der Account wurde gesperrt
Lösung:
ALTER USER apex_public_user [IDENTIFIED BY meinpasswort] ACCOUNT UNLOCK;
Wenn Sie das Passwort auf dem Oracle Server geändert haben, muss es natürlich auch auf dem Oracle Client ( dem Webserver) geändert werden.
Dass Passwort steht in Datei mit Namen apex.xml (im Ordner den sie bei der ersten Frage der Installation von ords.war angegeben haben)
In der Datei sind u.a. folgende Zeilen:
<entry key="db.password">@0574B6939D4387C95AD95DA10B99690D65</entry>
<entry key="db.username">APEX_PUBLIC_USER</entry>
Setzen Sie das geänderte Passwort unverschlüsselt mit vorangestellten ! in die Datei ein (nur bis ords 21.3.4 !!):
<entry key="db.password">!meinpasswort</entry>
Das Passwort wird beim Neustart des Webservers automatisch verschlüsselt.
Benutzer: APEX_PUBLIC_REST_USER
Symptome: Static und Workspace Files werden nicht mehr angezeigt
Webserver Fehler: 503 Service Unavailable
Wenn Debugging eingeschalten ist, dann auch noch :
Der Verbindungspool namens |apex|rt| ist aufgrund der folgenden Fehler nicht korrekt konfiguriert: ORA-28000: Account ist gesperrt.
Witzigerweise kann die Fehlermeldung auch erscheinen, wenn das Passwort falsch ist!
Wenn Debugging ausgeschalten ist, bekommen Sie den Fehlertext:
Benutzer oder Kennwort für den Verbindungspool namens |apex|| ist ungültig oder abgelaufen, oder der Account wurde gesperrt
Lösung:
ALTER USER apex_public_user [IDENTIFIED BY meinpasswort] ACCOUNT UNLOCK;
Dass Passwort steht in Datei mit Namen apex_rt.xml (auch hier im Ordner den sie bei der ersten Frage der Installation von ords.war angegeben haben)
In der Datei sind u.a. folgende Zeilen:
<entry key="db.password">@0574B6939D4387C95AD95DA10B99690D65</entry>
<entry key="db.username">APEX_REST_PUBLIC_USER</entry>
Setzen Sie das geänderte Passwort unverschlüsselt mit vorangestellten ! in die Datei ein:
<entry key="db.password">!meinpasswort</entry>
Das Passwort wird beim Neustart des Webservers automatisch verschlüsselt.
8. defaults.xml Datei nicht lesbar/vorhanden
Prüfen Sie, ob die Konfigdatei defaults.xml lesbar und für den Webserver (z.B. TomCat) lesbar und auch im richtigen Ordner zur Verfügung steht.
Fehler: 404 Not Found
Die Anforderung konnte keiner Datenbank zugeordnet werden. Stellen Sie sicher, dass die Anforderungs-URL richtig ist und dass Zuordnungen zwischen URL und Datenbank korrekt konfiguriert wurden.
Lösung:
Stellen Sie sicher, das der Webserver (z.B. TomCat) auf die Datei zugreifen kann. Einfacher Trick: Benennen Sie die Datei um und starten
Sie den Webserver durch. Er legt selbst eine neue Datei an. Falls nicht, gibt es evtl im Verzeichnis ein Rechteproblem.
Wenn Sie nicht wissen, in welchen Verzeichnis die Datei liegt:
im Webserver liegt im ords/WEB-INF Ordner eine Datei mit Namen web.xml. Dort steht u.a.
<param-name>config.dir</param-name>
<!-- Enter the location where configuration settings should be stored -->
<param-value>c:\oracle\ords_conf</param-value>
Bei uns hatte sich ein weiterer Fehler in einem Server eingeschlichen:
Die SQL*Plus Datei pupbld.sql Datei wurde bei der Installation einer neuen Datenbank nicht installiert. Das hatte zur Folge, dass bei jeder Anmeldung eines Benutzers an der Datenbank eine Fehlermeldung:
Kennwort eingeben:
ERROR:
ORA-00942: Tabelle oder View nicht vorhanden
Fehler bei Zugriff auf PRODUCT_USER_PROFILE
Warnung: Daten zu der Tabelle Product User Profile sind nicht geladen
PUPBLD.SQL sollte als SYSTEM gestartet werden
Letzte erfolgreiche Anmeldezeit: Mi Mrz 25 2020 14:02:32 +01:00
Verbunden mit:
Oracle Database 18c Express Edition Release 18.0.0.0.0 - Production
Version 18.4.0.0.0
Nachdem wir die Datei (@?/sqlplus/admin/pupbld.sql) installiert hatten, funktionierte das Ganze nach einem Neustart des Webservers wieder.
Sie sollten bei 404 Problemen generell die Hauptverdächtigen Benutzer ( APEX_PUBLIC_USER, ORDS_PUBLIC_USER und APEX_REST_PUBLIC_USER) mal manuell an die Datenbank anmelden. Wenn es da Probleme gibt, sollte diese zuerst gelöst werden!
9. ORDS komplett neu aufsetzen:
a, Benutzer löschen
SQL> DROP USER apex_listener CASCADE;
SQL> DROP USER apex_rest_public_user CASCADE;
b, Webserver beenden
systemctl stop tomcat
b, ORDS deinstallieren:
java -jar ords.war uninstall
c, ords Configurations Verzeichnis finden und löschen
Anzeige mittels:
java -jar ords.war configdir
Rückgabe:
Mar 17, 2020 9:33:17 AM
INFO: The config.dir value is /u01/software/oracle/ords/config
d, Löschen des Verzeichnis:
rm -rf /u01/software/oracle/ords/config
Es sollte auch der ords.war und das Verzeichnis ords im Webserver (z.B. in /opt/tomcat/latest/webapps) gelöscht werden
e, APEX_REST_CONFIG Skript als SYS neu starten
SQL>@apex_rest_config.sql
f, den Oracle ORDS neu konfigurieren:
Hinweis: Packen Sie die datei ords.war immer neu aus dem Zip-Verzeichnis aus. Es könnten von der letzten Konfiguration sich fehler eingeschlichen haben.
java -jar ords.war
g, ords.war in das Webserver Verzeichnis verschieben
mv ords.war /opt/tomcat/webaps
h, Webserver (z.B. TomCat) wieder starten
systemctl start tomcat
und testen ob es nun funktioniert!
10.The request could not be mapped to any database
Der Fehler lautet: URLMappingNotFoundException [statusCode=404, reasons=[The request could not be mapped to any database. Check the request URL is correct]
Hier war der Rest-Service ausgeschalten. Sie können ihn einschalten mittels:
EXEC apex_instance_admin.set_parameter('RESTFUL_SERVICES_ENABLED','Y');
Der Fehler tritt derzeit in Apex 20.1 bis 22.2 auf.
Lösung laut Metalink Doc: ID 2685135.1:
Schalten Sie die Option Friendly URL aus (Shared Components / Application Defintion Attributes)
[Update vom 6.6.2021) Fehler 404 bei Rest Service
Diese Mal war das Kennwort des ORDS_PUBLIC_USER abgelaufen.
select username,account_status,lock_date,expiry_date
from dba_users u
where username in ('APEX_PUBLIC_USER','ORDS_PUBLIC_USER','APEX_LISTENER');
USERNAME ACCOUNT_STATUS LOCK_DATE EXPIRY_DATE
----------------- --------------- ---------- --------------------
APEX_LISTENER OPEN 10.11.2022 11:40:31
APEX_PUBLIC_USER OPEN 10.11.2022 12:12:53
ORDS_PUBLIC_USER OPEN 10.11.2022 12:13:07
12. Fehler 503 Service Unavailable
Der Datenbankbenutzer für den Verbindungspool |apex|pu| kann das Schema SCOTT nicht als Proxy verwenden.
Möglicherweise ist eine Einschränkung der maximalen Anzahl an Datenbanksessions konfiguriert, oder ein Autorisierungsfehler liegt vor.
Die Lösung war bei uns:
alter user scott grant connect through ords_public_user;
Ein ähnlicher Fehler war
13. 500 Internal Server Error
Ein unerwarteter Fehler mit der folgenden Fehlermeldung ist aufgetreten:
InternalServerException [statusCode=500, logLevel=SEVERE, reasons=[]]
Caused by: java.sql.SQLException: ORA-00604: Fehler auf rekursiver SQL-Ebene 1
ORA-01031: Nicht ausreichende Berechtigungen
...
Caused by: Error : 604, Position : 0, Sql =
select nvl(h.items_per_page,m.items_per_page) items_per_page, t.etag_type, t.etag_query, h.source_type, m.origins_allowed, cursor
(select p.name, p.bind_variable_name, p.source_type,p.access_method, p.param_type from user_ords_parameters p where p.handler_id = h.id)
parameters, h.source from user_ords_modules m, user_ords_templates t, user_ords_handlers h where m.status = 'PUBLISHED' and t.id = h.template_id and m.id = t
Hier mussten READ Rechte von allen ORDS Objekten an den Ziel-Benutzer vergeben werden.
Neuer Fehler:
500 Internal Server Error mit Fehlertext NULL
Da haben wir etwas länger gesucht. Schuld war die falsche Java Version. OpenJDK Version 11 oder 17 lief bei uns nicht, wir mussten das Oracle JDK installieren!
Prüfen Sie immer auch, ob TomCat die Rechte hat das Config File zu lesen. Eine Fehlermeldung in der Form: Konnte Config datei nicht finden oder hatte keine Rechte darauf gibt es nicht.
Stattdessen meckert der Ords, dass er keine Verbindung zur Datenbank hinbekommt!
Neuer Fehler
500 Internal Server Error (im Logfile steht dann noch ORA-1005 Null password given)
Unter Linux und Ords < 22.x darf der Parameter -Dconfig nicht verwendet werden!
Datei /etc/systemd/system/tomcat.service:
Description=Tomcat
After=syslog.target network.target
[Service]
Type=forking
User=tomcat
Group=tomcat
Environment=JAVA_HOME=/usr
Environment='JAVA_OPTS=-Djava.awt.headless=true'
#Achtung bis Ords 21.4.3 darf der Parameter hier nicht stehen, aber ab Ords 22.x muss er hier stehen !
#Environment='JAVA_OPTS=-Dconfig.url=/opt/oracle/ords'
Environment=CATALINA_HOME=/opt/tomcat/latest
Environment=CATALINA_BASE=/opt/tomcat/latest
Environment=CATALINA_PID=/opt/tomcat/tomcat/temp/tomcat.pid
ExecStart=/opt/tomcat/latest/bin/catalina.sh start
ExecStop=/opt/tomcat/latest/bin/catalina.sh stop
[Install]
WantedBy=multi-user.target
Ich hoffe ich konnte dem einen oder der anderen ein paar Stunden an Suche nach den Webserver Fehlern (404) mit diesen Tipps ersparen.
Besuchen Sie uns doch einmal in einer unserer Schulungen in München-Unterhaching. Falls Sie nicht reisen können oder dürfen,
können Sie bei unseren Schulungen auch vom Home-Office oder Ihrem Arbeitsplatz per Streaming teilnehmen.
Bei weiteren Fragen stehen wir Ihnen gerne zur verfügung. Bleiben Sie BITTE gesund!