Closed finduramit closed 7 years ago
biemond
commented
7 years ago Hi,
indeed I do this , https://github.com/biemond/biemond-oradb/blob/puppet4_3_data/manifests/opatch.pp#L73
can you use opatch_auto , which should be run by root. but maybe the extract look at opatch auto and use the user or as root.
finduramit
commented
7 years ago Hello
I tried using opatch auto but that gave me the same error message.
class uos_create_oradb::apply_psu_patch {
oradb::opatch{'25171037_db_patch':
ensure => 'present',
oracle_product_home => '/oracle01/app/Oracle/product/12cR1',
patch_id => '25171037',
patch_file => 'p25171037_121020_Linux-x86-64.zip',
user => 'oracle',
group => 'oracle',
download_dir => '/home/oracle',
ocmrf => false,
use_opatchauto_utility => true,
puppet_download_mnt_point => '/media/sf_software_mnt/patch', }}What I have found that in the file opatch.pp if I add two below lines in the first “if” block it then works fine. Is there any other way to fix this? I would use the oradb module as it is.
user => $user,
group => $group,
case $facts['kernel'] {
'Linux', 'SunOS': {
if $ensure == 'present' {
if $remote_file == true {
exec { "extract opatch ${patch_file} ${title}":
command => "unzip -n ${download_dir}/${patch_file} -d ${download_dir}",
require => File["${download_dir}/${patch_file}"],
creates => "${download_dir}/${patch_id}",
path => $exec_path,
** user => $user, **
** group => $group, **
logoutput => false,
before => Db_opatch["${patch_id} ${title}"],
}
} else {
exec { "extract opatch ${patch_file} ${title}":
command => "unzip -n ${puppet_download_mnt_point}/${patch_file} -d ${download_dir}",
creates => "${download_dir}/${patch_id}",
path => $exec_path,
user => $user,
group => $group,
logoutput => false,
before => Db_opatch["${patch_id} ${title}"],
} } }that is strange with opatch auto it extracts and runs as root.
maybe split up this to this and make it readonly for everyone
output_pre = chmod -R +r #{extracted_patch_dir}
output = su - #{user} -c 'export ORACLE_HOME=#{oracle_product_home_dir}; cd #{oracle_product_home_dir}; #{command}'
finduramit
commented
7 years ago Hello
Thanks for your quick reply. Problem is, it extract the patch as root but before changing the folder permission user is switched using su - $user . This $user might not have access to change folder permissions.
I got it to work now after changing the file opatch.pp with two lines that I mentioned above.
Just one last question the “oradb::opatch” does not perform post install steps i.e “%./datapatch –verbose” ? Is there a way to do this using biemond-oradb-puppet4_3 ?
Regards
biemond
commented
7 years ago Hi,
root should extract it ( because of some previous issue ) . and root is allowed to do chmod -R +r #{extracted_patch_dir} and give read only access to all after that the patch should be applied as root or not, it just should work.
thanks
finduramit
commented
7 years ago Hello Thanks for your quick reply. opatch works fine for me now.
is there a way to do the post install sqlpatch step in the PSU using the datapatch utility ?
Regards Amit
biemond
commented
7 years ago great,
that will be hard, I don't know if the patch has one and I don't know how to check if it is already applied.
finduramit
commented
7 years ago Datapatch is the new command by Oracle that sits in the opatch directory. It needs to be executed after every PSU. So once the psu is applied and database is started, oracle documentation says execute below command
% ./datapatch -verbose
This will take care of whatever sql that needs to be loaded into the database after PSU patching. There is no checking needed as data patch will handle that automatically.
So after oradb::opatch this is a simple step to start the database and execute above command. I see if i am able to write this code myself, I am new to puppet so might take a while :-)
biemond
commented
7 years ago Thanks , good to know. mostly I do patching before I create a database.
On a running DB it will be hard too automate this. Mostly you need to plan this, make a backup, stop db, patch, startdb and then this. So I guess this will always be a manual action and I think creating DB after the patch should not require this patch.
biemond
commented
7 years ago simple patching works like this: Stop the database Execute opatch apply Start the database Execute datapatch [-verbose] done
Alternatively you can also execute opatchauto, as this runs both the opatch and the datapatch subsequently.
opatchauto should do the trick
finduramit
commented
7 years ago Hi
Thanks for your quick reply. Please can you tell me how do I use opatchauto to achieve this?
I tried below code, but this applied the opatch patch but did not execute datapatch afterwards.
oradb::opatch{'25171037_db_patch': ensure => 'present', oracle_product_home => '/oracle01/app/Oracle/product/12cR1', patch_id => '25171037', patch_file => 'p25171037_121020_Linux-x86-64.zip', user => 'oracle', group => 'oracle', download_dir => '/home/oracle', use_opatchauto_utility => true, puppet_download_mnt_point => '/media/sf_software_mnt/patch', }
Thanks
finduramit
commented
7 years ago I just checked Oracle document says opatch auto must be run from a grid infrastructure home so for a single instance, non RAC database this will not work.
biemond
commented
7 years ago ok, good to know.
so the patch was still applied and executed by root. Still we need to find out how we can do this in the normal puppet flow with a running DB. I don't see a solution
sivasamysubramaniam
commented
7 years ago Sorry, I opened an another issue for this permission problem. Can you add those two lines which Amit mentioned into opatch.pp to make oracle owner extract and own the patches?
biemond
commented
7 years ago that is not a good solution , it goes wrong with multiple oracle home
I will do the chmod as root and remove it from oracle command
sivasamysubramaniam
commented
7 years ago Ok..thanks Ed.. I am fine with it..
biemond
commented
7 years ago So I fixed it and also added fuser creation which was required by opatch. see 7ee746c0a62ea5133b8acbe8851a64601e72cd6f you can download the latest oradb version from github
I will also check grid patching
==> dbcdb: Notice: /Stage[main]/Oradb_cdb/Oradb::Opatch[25171037_db_patch]/Exec[extract opatch p25171037_121020_Linux-x86-64.zip 25171037_db_patch]/returns: executed successfully
==> dbcdb: Info: search for patchid 25171037
==> dbcdb: Info: opatch_status for patch 25171037 command: /oracle/product/12.1/db/OPatch/opatch lsinventory -patch_id -oh /oracle/product/12.1/db -invPtrLoc /etc/oraInst.loc
==> dbcdb: Info: opatch_status output NotFound for patchId 25171037
==> dbcdb: Info: opatch action: present with command /oracle/product/12.1/db/OPatch/opatch apply -silent -oh /oracle/product/12.1/db /var/tmp/install/25171037
==> dbcdb: Info: opatch result: Oracle Interim Patch Installer version 12.2.0.1.9
==> dbcdb: Copyright (c) 2017, Oracle Corporation. All rights reserved.
==> dbcdb:
==> dbcdb:
==> dbcdb: Oracle Home : /oracle/product/12.1/db
==> dbcdb: Central Inventory : /oracle/oraInventory
==> dbcdb: from : /oracle/product/12.1/db/oraInst.loc
==> dbcdb: OPatch version : 12.2.0.1.9
==> dbcdb: OUI version : 12.1.0.2.0
==> dbcdb: Log file location : /oracle/product/12.1/db/cfgtoollogs/opatch/opatch2017-07-09_13-53-06PM_1.logMany Thanks Just tested all seems to work fine now. I am working on developing our local version to patch a running DB with PSU that we can use every patching cycle.
biemond
commented
7 years ago nice , let me know if you know a flow which works well with a running DB instance.
SujitKJSingh
commented
5 years ago This error could also be there because of multiple patches in one patch directory, in that case go-to that main patch directory simply use napply.
umaha01
commented
4 years ago Hello All, On this same subject - i have a scenario - if any of you have some insight can you please share it back.
Appreciate your inputs and insights around this.
Hello Puppet Version 4.10.4 mod 'biemond-oradb', ' 3.0.9' Red Hat Enterprise Linux Server release 7.3 (Maipo)
I am facing an issue while trying to apply database PSU patch on oracle 12.1.0.2 database using oradb::opatch It’s just a single instance database without any RAC/clusterware and there is only one database home.
We are using definition below in our class file
Problem is when puppet agent run we get an error below
I figured out that this is being generated from db_opatch.rb line 45
I can see that problem is that puppet downloads the patch zip file as root user and extract the zip file which results in the patch folder still being owned by the “root” user. Now opatch cannot read these files and hence the error message. so unless the owner of patch directory is changed to oracle this will fail.
Please can you suggest if this is a bug or am I doing something wrong?
Many Thanks