What I mean by prompt-free here ?
Well, simply not being prompted during the very first Peoplesoft Appliance VM startup. I find it rather annoying, especially if we have to do it on regular basis. Yes, we do have to commit the agreement, choose a root password, DHCP or fixed IP address, db name, SES... please see part 8 of this previous posts.
The beauty here is that without prompts we could have a script, schedule it in the evening (download files from MOS, doing all the required tasks to move to ESXi as I explained in an other blog entry, and start the VM; all automatically), come back the day after and the VM is ready to be used without anything else to do manually.
You could be right to say it's useless (and probably painful) since you always can create a VM and do snapshots or backup.
But you may also think about creating multiple VMs from the same appliance, where you should each time enter manually all the prompts with different IP address and hostname... I much prefer something like a configuration file defined in advance.
Needless to say it's a nice challenge. Don't you like challenge ?
Even if you are not interested by avoiding prompts, it's always interesting to investigate what Peoplesoft is providing to us for the PUM - Peoplesoft Update Manager - environment. It is finally worth to go through this (long) journey.
So, we will go through a 5 posts series to explain as much details as possible what need to be done.
The very first step is to get a picture of what is delivered.
As I explained in part 4 of the other post, the delivered OVA file is nothing but an archive of VMDKs (disks).
There are 5 of them. Which one is what ? What is the content and description of each disk ? This is what we need to define before going further.
The header of each files gives a first answer:
[root@omsa HCM92000]# for i in `ls HCMDB-SES-85302d-disk?.vmdk`; do head -27 $i >> vmdk.txt; done
[root@omsa HCM92000]# more vmdk.txt
KDMV
version=1
CID=dd143577
parentCID=ffffffff
isNativeSnapshot="no"
createType="streamOptimized"
# Extent description
RDONLY 14733312 SPARSE "HCMDB-SES-85302d-disk1.vmdk"
# The Disk Data Base
#DDB
ddb.longContentID = "19c1a3f4136bd9ec953c84f1dd143577"
ddb.encoding = "UTF-8"
ddb.comment = "Converted image from System.img"
ddb.uuid.parentmodification = "00000000-0000-0000-0000-000000000000"
ddb.uuid.modification = "00000000-0000-0000-0000-000000000000"
ddb.uuid.parent = "00000000-0000-0000-0000-000000000000"
ddb.uuid.image = "022ac6dc-7b31-4d2b-ab4c-3c71e5c9f1b5"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "16"
ddb.geometry.cylinders = "14616"
ddb.adapterType = "ide"
ddb.virtualHWVersion = "4"
<...>
KDMV
version=1
CID=b38c7d38
parentCID=ffffffff
createType="streamOptimized"
# Extent description
RDONLY 11294720 SPARSE "HCMDB-SES-85302d-disk2.vmdk"
# The disk Data Base
#DDB
ddb.virtualHWVersion = "4"
ddb.adapterType="ide"
ddb.geometry.cylinders="11205"
ddb.geometry.heads="16"
ddb.geometry.sectors="63"
ddb.uuid.image="2190202e-f3a8-413b-be1c-50409d983202"
ddb.uuid.parent="00000000-0000-0000-0000-000000000000"
ddb.uuid.modification="00000000-0000-0000-0000-000000000000"
ddb.uuid.parentmodification="00000000-0000-0000-0000-000000000000"
ddb.comment="Converted image from Oracle11gR2.img"
<...>
KDMV
version=1
CID=c0b779ea
parentCID=ffffffff
createType="streamOptimized"
# Extent description
RDONLY 71698432 SPARSE "HCMDB-SES-85302d-disk3.vmdk"
# The disk Data Base
#DDB
ddb.virtualHWVersion = "4"
ddb.adapterType="ide"
ddb.geometry.cylinders="16383"
ddb.geometry.heads="16"
ddb.geometry.sectors="63"
ddb.uuid.image="a91009aa-d8f8-424a-b61c-1cdc5fd56eb5"
ddb.uuid.parent="00000000-0000-0000-0000-000000000000"
ddb.uuid.modification="00000000-0000-0000-0000-000000000000"
ddb.uuid.parentmodification="00000000-0000-0000-0000-000000000000"
ddb.comment="Converted image from HCMDB.img"
<...>
KDMV
version=1
CID=1d37be00
parentCID=ffffffff
createType="streamOptimized"
# Extent description
RDONLY 25624576 SPARSE "HCMDB-SES-85302d-disk4.vmdk"
# The disk Data Base
#DDB
ddb.virtualHWVersion = "4"
ddb.adapterType="ide"
ddb.geometry.cylinders="16383"
ddb.geometry.heads="16"
ddb.geometry.sectors="63"
ddb.uuid.image="b68f6e0b-4349-4d76-8f7e-29ab8c475d6d"
ddb.uuid.parent="00000000-0000-0000-0000-000000000000"
ddb.uuid.modification="00000000-0000-0000-0000-000000000000"
ddb.uuid.parentmodification="00000000-0000-0000-0000-000000000000"
ddb.comment="Converted image from TOOLS.img"
<...>
KDMV
version=1
CID=8ea5f943
parentCID=ffffffff
createType="streamOptimized"
# Extent description
RDONLY 35842048 SPARSE "HCMDB-SES-85302d-disk5.vmdk"
# The disk Data Base
#DDB
ddb.virtualHWVersion = "4"
ddb.adapterType="ide"
ddb.geometry.cylinders="16383"
ddb.geometry.heads="16"
ddb.geometry.sectors="63"
ddb.uuid.image="a44bf647-058d-4909-b4f5-781bea534e93"
ddb.uuid.parent="00000000-0000-0000-0000-000000000000"
ddb.uuid.modification="00000000-0000-0000-0000-000000000000"
ddb.uuid.parentmodification="00000000-0000-0000-0000-000000000000"
ddb.comment="Converted image from SES.img"
<...>
It looks like all the disks have been initiated on Oracle VM (see the comment, “Converted” as well as the extension file img in comment line is typically an Oracle VM template). Rather interesting, Oracle developed everything on Oracle VM and moved all to VirtualBox.
Each disk has its own dedicated area :
1st one, “Converted image from System.img”, this disk contains the all system OS and the required scripts used for the deployment. This is the one we should go deeper later on for what we have to do. That one is defined as IDE disk.
2nd one, “Converted image from Oracle11gR2.img”, the database installation software.
3rd one, “Converted image from HCMDB.img”, the database.
4rth one, “Converted image from TOOLS.img”, the Peopletools installation software.
5th one, “Converted image from SES.img”, the SES software installation.
So, to go further in the automation, we should go and investigate further into the 1st disk, used to host the system and boot drive.
I’m using VMWARE ESXi, there’s a nice and small utility, vmware-mount (coming with Virtual Disk Development Kit) to work on disk.
Let’s use it and see the disk in details:
[root@omsa:HCMDB-SES-85302d]# vmware-mount -p HCMDB-SES-85302d-disk1.vmdk
Nr Start Size Type Id Sytem
-- ---------- ---------- ---- -- ------------------------
1 63 208782 BIOS 83 Linux
2 208845 10313730 BIOS 83 Linux
3 10522575 4209030 BIOS 82 Linux swap
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCMDB-SES-85302d]#
Let’s forget the 3rd mount point, it’s nothing but swap space.
We should check the first two to see which one is our for scripts hosting.
About the first mount point:
[root@omsa:HCMDB-SES-85302d]# mkdir /mnt/HCMDB-SES-85302d
[root@omsa:HCMDB-SES-85302d]# vmware-mount HCMDB-SES-85302d-disk1.vmdk 1 /mnt/HCMDB-SES-85302d
[root@omsa:HCMDB-SES-85302d]# ls –l /mnt/HCMDB-SES-85302d
total 18912
-rw-r--r--. 1 root root 67258 Jul 25 2011 config-2.6.18-274.0.0.0.1.el5xen
-rw-r--r--. 1 root root 98997 Jul 28 2011 config-2.6.32-200.13.1.el5uek
drwxr-xr-x. 2 root root 1024 Apr 1 07:50 grub
-rw-------. 1 root root 3322413 Sep 9 2011 initrd-2.6.18-274.0.0.0.1.el5xen.img
-rw-------. 1 root root 2963880 Sep 9 2011 initrd-2.6.32-200.13.1.el5uek.img
-rw-------. 1 root root 2976036 Sep 9 2011 initrd-2.6.32-200.13.1.el5uek.img.pvhvm
drwx------ 2 root root 12288 Sep 9 2011 lost+found
-rw-r--r--. 1 root root 115821 Jul 25 2011 symvers-2.6.18-274.0.0.0.1.el5xen.gz
-rw-r--r--. 1 root root 161244 Jul 28 2011 symvers-2.6.32-200.13.1.el5uek.gz
-rw-r--r--. 1 root root 1230605 Jul 25 2011 System.map-2.6.18-274.0.0.0.1.el5xen
-rw-r--r--. 1 root root 2437866 Jul 28 2011 System.map-2.6.32-200.13.1.el5uek
-rw-r--r--. 1 root root 2195174 Jul 25 2011 vmlinuz-2.6.18-274.0.0.0.1.el5xen
-rwxr-xr-x. 1 root root 3677280 Jul 28 2011 vmlinuz-2.6.32-200.13.1.el5uek
[root@omsa:HCMDB-SES-85302d]# vmware-mount -d /mnt/HCMDB-SES-85302d
Hmmm, nothing much interesting for us here.
And about the second mount point:
[root@omsa:HCMDB-SES-85302d]# vmware-mount HCMDB-SES-85302d-disk1.vmdk 2 /mnt/HCMDB-SES-85302d
[root@omsa:HCMDB-SES-85302d]# ls –l /mnt/HCMDB-SES-85302d/opt/oracle/psft/vm
total 200
-rwxr-xr-x 1 root root 3600 Apr 1 04:54 appbatch-start
-r--r--r-- 1 root root 32 Apr 1 07:50 appliance.props
-rwxr-xr-x 1 root root 366 Apr 1 04:54 apply-hotfix.sh
-rwxr-xr-x 1 root root 10195 Apr 1 04:54 cmppropsfile.py
-rwxr-xr-x 1 root root 521 Apr 1 04:54 expect-sftp
-rwxr-xr-x 1 root root 459 Apr 1 04:54 expect-ssh
-rwxr-xr-x 1 root root 4064 Apr 1 04:54 installpia.sh
-rwxr-xr-x 1 root root 1514 Apr 1 04:54 network-update
-rwxr-xr-x 1 root root 23945 Apr 1 04:54 oraclevm-template-appbatch.sh
-rwxr-xr-x 1 root root 5695 Apr 1 04:54 oraclevm-template-db.sh
-rwxr-xr-x 1 root root 17248 Apr 1 04:54 oraclevm-template-env.sh
-rwxr-xr-x 1 root root 3816 Apr 1 04:54 oraclevm-template-ext.sh
-rwxr-xr-x 1 root root 13853 Apr 1 04:54 oraclevm-template-pia.sh
-rwxr-xr-x 1 root root 2230 Apr 1 04:54 oraclevm-template-search.sh
-rwxr-xr-x 1 root root 0 Apr 1 04:54 oraclevm-template-ses.sh
-rwxr-xr-x 1 root root 21569 Apr 1 04:54 oraclevm-template.sh
-rwxr-xr-x 1 root root 28642 Apr 1 04:54 oraclevm-template-utils.sh
-rwxr-xr-x 1 root root 2146 Apr 1 04:54 ptem_variables.properties
-rwxr-xr-x 1 root root 4649 Apr 1 04:54 README
drwxr-xr-x 2 root root 4096 Apr 1 05:36 sql
-rwxr-xr-x 1 root root 1586 Apr 1 04:54 template-cleanup.sh
-rwxr-xr-x 1 root root 140 Apr 1 04:54 tnsnames.ora
-rwxr-xr-x 1 root root 175 Apr 1 04:54 tnsnames.ora.exa
-rwxr-xr-x 1 root root 3495 Apr 1 04:54 updatepiahost.sh
[root@omsa:HCMDB-SES-85302d]# vmware-mount -d /mnt/HCMDB-SES-85302d
[root@omsa:HCMDB-SES-85302d]# rmdir /mnt/HCMDB-SES-85302d
Yeap, here we go. It contains all what is used during the Appliance deployment. This is the one we want to go to through if we want to go further in the vm scripts modifiation.
NB: we could do the same exercise of mounting other disk (2, 3, 4, and 5) to check their exact content, but it’s not really what we are looking for right now, we have enough information.
We could go straight away, but it’s not that simple. The given vmdk are “compressed”. The utility vmware-mount can only mount the disk in read only mode ! Not very useful if we want to modify the content.
In the next step, we will have to find a workaround which allow the files modification.
Nicolas.
No comments:
Post a Comment