Der Autor hatte bei seinem Kunden bereits vor längerer Zeit die SQLNET.ORA-Datei angepasst, damit eine alte Applikation, die sehr eng mit einer Oracle9i-Datenbank verknüpft ist, auf eine 19c-Datenbank zugreifen kann:
# Enable logon with old client versions
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8
SQLNET.ALLOWED_LOGON_VERSION_SERVER=8
Die Lösung funktioniert und alle waren glücklich.
Einige Monate später kam der Kunde wieder, nach einen Betriebssystem-Update funktioniert die Lösung leider nicht mehr, was kann da passiert sein? Wie hat der Betriebssystem-Update dort sein Unwesen getrieben?
Dem Autor war bewusst, nach Änderung dieser Parameter müssen DB und Listener neu gestartet werden. Wir sind auf dem Testsystem, gesagt, getan, und ja, alles war wieder gut.
Dann trat doch die erste Ratlosigkeit ein, warum funktioniert es nach einem einfachen Neustart wieder? Sind es doch die magischen Hände des Consultants, das kann doch eigentlich nicht sein.
Nach mehreren Minuten Nachdenken, Brainstormen und Diskutieren kam dann die erste Idee.
Erster Versuch
Nach Einspielen des Betriebssystem-Update wurde der Server rebooted und die DB dabei automatisch neu gestartet, nur war in diesem Fall das Environment und ganz besonders TNS_ADMIN nicht gesetzt und somit wurde auch die SQLNET.ORA mit den Einträgen nicht herangezogen.
Ok, was war zu tun? Es musste sichergestellt werden, dass beim Starten des Servers das richtige Environment mit TNS_ADMIN gesetzt wird. Und auch da gab es eine Hilfe, eine Zusatzsoftware hatte genau das in Ihrem Portfolio, die oracle.service-Datei musste nur in ¨/usr/lib/systemd/system/¨ kopiert und dann der Service mit ¨systemctl start oracle¨ installiert und gestartet werden.
Das ging auch fix, noch ein Reboot und alles war perfekt. Danach musste nur noch ein Termin gefunden werden, um die Änderungen und den Test auch auf dem Produktionsserver durchzuführen. Es ist ja alles klar, das machen wir dann mal schnell in der Mittagspause (der geneigte Leser ahnt schon, welches Wort in diesem Zusammenhang mal wieder falsch war).
Ein paar Tage später, Mittagspause und los geht’s.
Die Vorbereitungen waren schnell gemacht, warten bis die Applikation gestoppt wurde, den Service starten und dann passiert das:
Loaded: loaded (/usr/lib/systemd/system/oracle.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2023-04-05 13:32:12 CEST;
Apr 05 13:32:12 XXXXXX.xx.xxx systemd[1]: Starting Oracle services started
Apr 05 13:32:12 XXXXXX.xx.xxx systemd[1]: oracle.service: Control process exited, code=exited status=1
Apr 05 13:32:12 XXXXXX.xx.xxx systemd[1]: oracle.service: Failed with result 'exit-code'.
Apr 05 13:32:12 XXXXXX.xx.xxx systemd[1]: Failed to start Oracle services
[root@XXXXXX ~]# systemctl enable oracle
[root@XXXXXX ~]# systemctl start oracle
Job for oracle.service failed because the control process exited with error code.
See "systemctl status oracle.service" and "journalctl -xe" for details.
Jetzt war guter Rat teuer.
Ein neuer Versuch
Nächster Ansatzpunkt - /var/log/messages, dort dann der Eintrag ¨[Permission denied]¨.
Wie war das möglich? Das hat doch auf dem Testsystem alles so gut funktioniert und die Server sind doch gleich aufgesetzt. Was war jetzt zu tun? Zuerst mal die ganze Übung abbrechen, die Applikation musste wieder laufen.
Jetzt ging es auf die Fehlersuche, waren die Systeme wirklich gleich aufgesetzt? Wo gibt es eventuell doch Unterschiede?
Ansatzpunkt waren hier die fehlenden Zugriffsberechtigungen, es musste vermutlich am User liegen.
Ein einfaches¨Id¨ brachte dann die Lösung, hier waren die Unterschiede:
Testserver:
id uid=502(oracle) gid=501(oinstall) groups=501(oinstall),502(dba),503(oper), 506(asmdba)
Produktionsserver:
id uid=502(oracle) gid=501(oinstall) groups=501(oinstall),502(dba),503(oper), 506(asmdba) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
und dann nach etwas googlen war klar, auf dem Produktionsserver war SELinux eingeschaltet.
In der config-Datei /etc/selinux/config musste folgendes geändert werden:
SELINUX=disabled
Statt
SELINUX=enforcing
Danach ein Reboot des Servers und jetzt war wirklich alles gut!
Quintessenz
Was lernen wir daraus:
- Vertraue nie auf die Aussage: Die Server sind gleich (Der Linux-Betreuer war bei der ganzen Aktion nicht anwesend und konnte somit nicht unterstützen).
- "Ich mach mal schnell!" funktioniert meistens so nicht.
- Sicherheitsfeature (SELinux) sind zwar schön, können einen aber ganz schön ins Schwitzen bringen, wenn man nicht damit rechnet.
- Ein verständnisvoller Kunde, der den Consultant nicht verteufelt, nur weil er nicht nach 5 Minuten die Lösung hat, sondern als Sparringpartner mithilft und Denkanstöße gibt.
Jürgen Vitek
Stellv. Themenverantwortung Hochverfügbarkeit, Stellv. Themenverantwortung Open-Source
----
Bild von Emilian Robert Vicol auf Pixabay
