Datei-Eigentümer nach dem Patchen oder Re-Linken der Oracle RDBMS-Software
Vor einiger Zeit habe ich beim Patchen von RDBMS-Software beim Kunden die Warnung „chmod: change permissions of’/u00/app/oracle/product/11.2.0.4/bin/extjobO‘: Operation not permitted“ bekommen. Ich habe daher mal ein bisschen recherchiert, was mit den Dateiberechtigungen und dem Eigentum beim Patchen oder Re-Linken von Oracle RDBMS-Software passiert.
English translation of this post on www.markusdba.net
Wie wir alle wissen, müssen die Berechtigungen einiger Oracle-Executables unter Linux/Unix nach der Installation geändert werden. Dies geschieht mit Hilfe von „root.sh“.
Nach einer Neuinstallation und dem Ausführen von root.sh (Oracle 18c – 18.3 unter Linux) sieht $ORACLE_HOME/bin so aus:
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l |grep root
-rwxr-xr-x. 1 oracle oinstall 945 Jun 20 2016 acfsroot
-rwxr-xr-x. 1 oracle oinstall 1000 Jun 20 2016 afdroot
-rwsr-x---. 1 root oinstall 2580328 Oct 2 09:17 extjob
-rwsr-x---. 1 root oinstall 2366584 Oct 2 09:17 jssu
-rwxr-xr-x. 1 oracle oinstall 940 Jun 20 2016 okaroot
-rwxr-xr-x. 1 oracle oinstall 1007 Jun 20 2016 olfsroot
-rwsr-x---. 1 root oinstall 98210 Feb 7 2018 oradism
-rwx------. 1 oracle oinstall 2139 Sep 19 2017 rootPreRequired.sh==> „root“ ist jetzt Eigentümer von extjob, jssu und oradism
Was passiert, wenn wir einen Patch einspielen?
Nach dem Einspielen des Patches 28655784 (Database RU 18.4) haben sich die Berechtigungen geändert:
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l |grep root
-rwxr-xr-x. 1 oracle oinstall 945 Jun 20 2016 acfsroot
-rwxr-xr-x. 1 oracle oinstall 1000 Jun 20 2016 afdroot
-rwsr-x---. 1 root oinstall 2366584 Oct 2 09:17 jssu
-rwxr-xr-x. 1 oracle oinstall 940 Jun 20 2016 okaroot
-rwxr-xr-x. 1 oracle oinstall 1007 Jun 20 2016 olfsroot
-rwsr-x---. 1 root oinstall 98210 Feb 7 2018 oradism
-rwx------. 1 oracle oinstall 2139 Sep 19 2017 rootPreRequired.sh
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l extjob
-rwxr-xr-x. 1 oracle oinstall 2580328 Nov 18 11:48 extjob
==> Genauer gesagt: nur bei „extjob“ hat sich etwas geändert. Die Datei gehört jetzt „oracle“ und nicht mehr „root“.
Da externe Jobs selten verwendet werden (mein persönlicher Eindruck) sind die meisten Benutzer von diesem Problem nicht betroffen. Aber um sicher zu sein, dass die Rechte korrekt sind, halte ich es für eine gute Idee, root.sh nach dem Einspielen eines Patches erneut auszuführen (dies ist ein nicht dokumentierter Schritt nach der Patch-Installation und wahrscheinlich auch nicht für alle Patches erforderlich).
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] cd ..
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/ [rdbms18000] su
Password:
root@oramaster18:/u00/app/oracle/product/18.0.0.0/ [rdbms18000] ./root.sh
Check /u00/app/oracle/product/18.0.0.0/install/root_oramaster18.markusdba.local_2018-11-18_11-51-41-270759279.log for the output of root script
root@oramaster18:/u00/app/oracle/product/18.0.0.0/ [rdbms18000] exit
exit
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/ [rdbms18000] cd bin
/u00/app/oracle/product/18.0.0.0/bin
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l |grep root
-rwxr-xr-x. 1 oracle oinstall 945 Jun 20 2016 acfsroot
-rwxr-xr-x. 1 oracle oinstall 1000 Jun 20 2016 afdroot
-rwsr-x---. 1 root oinstall 2580328 Nov 18 11:48 extjob
-rwsr-x---. 1 root oinstall 2366584 Oct 2 09:17 jssu
-rwxr-xr-x. 1 oracle oinstall 940 Jun 20 2016 okaroot
-rwxr-xr-x. 1 oracle oinstall 1007 Jun 20 2016 olfsroot
-rwsr-x---. 1 root oinstall 98210 Feb 7 2018 oradism
-rwx------. 1 oracle oinstall 2139 Sep 19 2017 rootPreRequired.sh
Was passiert bei einem Relink der RDBMS-Software?
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] relink all
writing relink log to: /u00/app/oracle/homes/OraDB18Home1/install/relink_2018-11-18_11-52-23AM.log
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l |grep root
-rwxr-xr-x. 1 oracle oinstall 945 Jun 20 2016 acfsroot
-rwxr-xr-x. 1 oracle oinstall 1000 Jun 20 2016 afdroot
-rwxr-xr-x. 1 oracle oinstall 940 Jun 20 2016 okaroot
-rwxr-xr-x. 1 oracle oinstall 1007 Jun 20 2016 olfsroot
-rwsr-x---. 1 root oinstall 98210 Feb 7 2018 oradism
-rwx------. 1 oracle oinstall 2139 Sep 19 2017 rootPreRequired.sh
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l extjob
-rwxr-xr-x. 1 oracle oinstall 2580328 Nov 18 11:52 extjobEs ist also sinnvoll, root.sh erneut auszuführen, damit diese Dateien den korrekten Eigentümer bekommen (dies ist in MOS-Note „Executing “relink all” resets permission of extjob, jssu, oradism, externaljob.ora (Doc ID 1555453.1) beschrieben).
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] su
Password:
root@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] cd ..
root@oramaster18:/u00/app/oracle/product/18.0.0.0/ [rdbms18000] ./root.sh
Check /u00/app/oracle/product/18.0.0.0/install/root_oramaster18.markusdba.local_2018-11-18_11-56-04-603314902.log for the output of root script
root@oramaster18:/u00/app/oracle/product/18.0.0.0/ [rdbms18000] exit
exit
oracle@oramaster18:/u00/app/oracle/product/18.0.0.0/bin/ [rdbms18000] ls -l extjob
-rwsr-x---. 1 root oinstall 2580328 Nov 18 11:52 extjob
Zusammenfassung:
Obwohl es nicht dokumentiert ist, halte ich es für eine gute Idee, root.sh nach dem Patchen auszuführen (oder zumindest den Eigentümer der betreffenden Dateien zu überprüfen). Beim Relinken der RDBMS-Software (z.B. nach einem Kernel-Update) ist die anschließende Ausführung von „root.sh“ ein Muss (IMHO).
MOS-Notes
- What Are Root.sh And OrainstRoot.sh Scripts In A Standalone RDBMS Installation? (Doc ID 1493121.1)
- Why are files under $ORACLE_HOME owned by root user? (Doc ID 461144.1)
- Executing “relink all” resets permission of extjob, jssu, oradism, externaljob.ora (Doc ID 1555453.1)
- Relinking Oracle Home FAQ ( Frequently Asked Questions) (Doc ID 1467060.1)