Sunday, November 15, 2009

Peoplesoft VM : about the App/Batch image (in VMWare)

I created an virtual machine from the App/Batch server template downloaded from edelivery (OVM_EL5U2_X86_64_AB85002_HCM91_PVM), here are my first screenshots and comments.

On the first start of the VM, go to the console, then you should see the following (be careful, I noticed some timeout if you're too slow to connect and enter a value, the DHCP configuration will be taken in account by default, sigh), and fill the requested data (fixed IP address, netmask, gateway...) :


Unfortunately, it is not working as we could expect. Indeed, the application server won't start, the process scheduler won't start neither.
Eventhough, you filled all the correct data, that won't work without manual modifications.

The App and Batch domains are owned by psadm2 user, and files located under ~/ps/pt/8.50/appserv, default app domain name is APPDOM, default prcs domain name is PRCSDOM.

Well, looking in the log file, we can see the following :
PSADMIN.2190 (0) [11/14/09 18:21:21](0) Begin boot attempt on domain APPDOM
PSAPPSRV.2242 (0) [11/14/09 18:21:49](0) PeopleTools Release 8.50.02 (Linux) starting. Tuxedo server is APPSRV(99)/1
PSAPPSRV.2242 (0) [11/14/09 18:21:49](0) Cache Directory being used: /home/psadm2/ps/pt/8.50/appserv/APPDOM/CACHE/PSAPPSRV_1/
PSAPPSRV.2242 (0) [11/14/09 18:21:53](3) File: SQL Access ManagerSQL error. Stmt #: 2 Error Position: 0 Return: 12154 - ORA-12154: TNS:could not resolve the connect identifier specified
PSAPPSRV.2242 (0) [11/14/09 18:21:53](1) GenMessageBox(200, 0, M): SQL Access Manager: File: SQL Access ManagerSQL error. Stmt #: 2 Error Position: 0 Return: 12154 - ORA-12154: TNS:could not resolve the connect identifier specified
PSAPPSRV.2242 (0) [11/14/09 18:21:53](1) GenMessageBox(0, 0, M): Database Signon: Could not sign on to database H91TMPLT with user PS.
PSAPPSRV.2242 (0) [11/14/09 18:21:53](0) Server failed to start
PSADMIN.2190 (0) [11/14/09 18:22:00](0) End boot attempt on domain APPDOM


Checking the database, from the database server point of view, whether the database name is the one you gave - here H91TMPLT, the service name is slightly different, it is postfixed by the domain name .corp.peoplesoft.com, see below :
[oracle@psovmdb ~]$ lsnrctl status

LSNRCTL for Linux: Version 11.1.0.7.0 - Production on 15-NOV-2009 12:39:08

Copyright (c) 1991, 2008, Oracle. All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=psovmdb)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 11.1.0.7.0 - Production
Start Date 15-NOV-2009 01:57:15
Uptime 0 days 10 hr. 41 min. 52 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /u01/app/oracle/product/11.1.0/db_1/network/admin/listener.ora
Listener Log File /u01/app/oracle/diag/tnslsnr/psovmdb/listener/alert/log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=psovmdb)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
Services Summary...
Service "H91TMPLT.corp.peoplesoft.com" has 1 instance(s).
Instance "H91TMPLT", status READY, has 1 handler(s) for this service...
Service "H91TMPLT_XPT.corp.peoplesoft.com" has 1 instance(s).
Instance "H91TMPLT", status READY, has 1 handler(s) for this service...
Service "XDB.corp.peoplesoft.com" has 1 instance(s).
Instance "H91TMPLT", status READY, has 1 handler(s) for this service...
The command completed successfully
[oracle@psovmdb ~]$


Let's check the tnsnames.ora file, and here what surprise, very strange to me, the Oracle client installation is owned by root... and the tnsnames.ora file in use is located under /etc/tnsnames.ora.
It is an unfortunate configuration of this file, using SID instead of SERVICE_NAME, finally, the modification give this :
[psadm2@psovmab LOGS]$ more /etc/tnsnames.ora
H91TMPLT=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.133)(PORT=1521)))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=H91TMPLT.corp.peoplesoft.com))
)
[psadm2@psovmab LOGS]$


After that change, we can connect onto the database from the App/Batch server, then go to $PS_HOME/appserv, run ./psadmin and reconfigure the application server domain and process scheduler.
Finally, everything should start and work fine.

Next step, PIA server.

Enjoy,

13 comments:

Nicolas Gasparotto said...

An other slight note, the client is 10.2.0.1 64-bit, whereas the database is 11.1.0.7 64-bit, I thought having different versions was not certified...

Unknown said...

Hi,

after the modification of /etc/tnsnames.ora in the App/Batch VM :

psadm2@psovmab LOGS$ more /etc/tnsnames.ora
H91TMPLT=
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.133)(PORT=1521)))
(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=H91TMPLT.corp.peoplesoft.com))
)

I can't start server domain and process scheduler :

NLS:4: Cannot open message catalog TMADMIN_CAT, set 1, num 197; check TUXDIR=/opt/oracle/psft/appbatch/bea/tuxedo, LANG=en_US.UTF-8
NLS:4: Cannot open message catalog TMADMIN_CAT, set 1, num 198; check TUXDIR=/opt/oracle/psft/appbatch/bea/tuxedo, LANG=en_US.UTF-8


thank you

Nicolas Gasparotto said...

As I said in the thread on OTN forum you created
http://forums.oracle.com/forums/thread.jspa?threadID=1006968&tstart=0
You should set LANG to C :
export LANG=C
and restart the AppServer.

But, everything should be well by default on Peoplesoft OVM, looks like you modified the .bash_profile of psadm2 user.

Nicolas.

Anonymous said...

Hi Nicolas,

where can I find how to configure the APP Server ans Process scheduler domain, for theses VM's?

Thanks,
RTG

Nicolas Gasparotto said...

RTG, except if you have specific needs, you should not configure them, they are already configured as they should be, and they work fine like that.

Nicolas.

Anonymous said...

Hi Nicolas,

thanks for your quick respond and the great guide. Since I am new to ppsft and following your guide quite exactly I did the change in the /etc/tnsnames.ora and was wondering wne your wrote to reconfigure the domain via ./psadmin.
So a restart would be just enogh?

Thank,
RTG

Nicolas Gasparotto said...

RTG, good catch, I'm not sure anymore now why I wrote this, sorry :)
But most likely (re)start the domains should be enough.

Nicolas.

Anonymous said...

sorry for my last post, my keyboard language was wrong. However if I call ./psadmin and try to configure a domain. It only lists APPDOM as a domain. Is this the right one?

Nicolas Gasparotto said...

Yes, APPDOM is the application server domain. PRCSDOM the process scheduler domain.

Nicolas.

Anonymous said...

Hi Nicolas,

it seems that configuration also works if the definition in the tnsnames.ora is following:

H91TMPLT=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=host.domain.nga)(PORT=1521)))(CONNECT_DATA=(SERVER=DEDICATED)(SID=H91TMPLT)))

And the only thing required is to put the DB Host IP into /etc/hosts entries and add the SID definition to the environment:
export ORACLE_SID=H91TMPLT.
On the DB side an optional setting might be to grant the create session right to the "PS" user. Once we were able to connect to the db from the app server, the domain loaded sucessfully.
Now everything is up and running. Next step is to install the APP Designer on an external windows box.

Again, thanks for providing these guides through your blog, they rock.

RTG

Anonymous said...

Nicolas,
I noted your comment about the timeout on the template network configuration. So, I deleted my VM, rebuilt it and started it again. I then switched to VNC immediately. Despite this, I get no prompt for network values, the boot process doesn't stop until it asks for the DB name. Is there a way to force it to ask for network configuration ?

Thanks.

Nicolas Gasparotto said...

Are you saying you are never prompted for the DHCP (y/n) configuration despite you tunred to VNC fast enough ? Well that's rather strange, and maybe something you could report in the Peoplesoft OVM forum (http://forums.oracle.com/forums/forum.jspa?forumID=830) with all your configuration settings descriptions.
Anyway, this can be fixed later on manually directly in the network config files (i.e ifcfg-eth0).

Nicolas.

Unknown said...
This comment has been removed by the author.