Virtual Appliance for Peoplesoft – few issues

Hereafter few issues I’ve seen so far on the VirtualBox Appliances for Peoplesoft. Some are on FSCM92000 only, some on both (HCM92 and FSCM92), and some only when you have the two running in same time.
From the errors/issues/problems described below have more or less impact on the system, I’d say one on Samba (the VBOX registration) and the non-working auto-start application on FSCM92 are the most annoying.

FSCM92000 is a VirtualBox Appliance for Peoplesoft, it should be exactly the same as HCM92000 that I showed how it can be moved from VirtualBox to ESXi.
A lot are already configured by default, it can easily be up and running.
However, for some reason, FSCM92000 is a little bit less configured (buggy?).

1) SELinux
On the boot of the Appliances (either HCM92 and FSCM92), you may see several errors such as (check file in /var/log/messages)
Apr 27 10:31:33 localhost kernel: type=1400 audit(1367073093.328:11): avc:  denied  { write } for  pid=3437 comm="smbd" name="log" dev=sda2 ino=31163 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir
Apr 27 10:31:33 localhost kernel: type=1400 audit(1367073093.328:12): avc:  denied  { add_name } for  pid=3437 comm="smbd" name="samba.log.192.168.1.204" scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir
Apr 27 10:31:33 localhost kernel: type=1400 audit(1367073093.328:13): avc:  denied  { create } for  pid=3437 comm="smbd" name="samba.log.192.168.1.204" scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file
 
And also

Whether they can be ignored, it can be solved later on, as following (I explained here some times ago):
Edit the file /etc/selinux/config, you’ll see

For some reason, SELINUX variable is not set, give it the value “disabled” and reboot, no more messages should come out. 

After rebooting, the error is gone
 

2) Report node definition
Unlike HCM92, on FSCM92, the report node is not defined:

You should add it manually:

Of course, now this report node must be linked to the server definition (server in use PRCS2951) :
 
And do not forget to give a password to the local node definition:

Restart the Process Scheduler, and that’s it.

Reports are now posted:


3) Samba 
There are several samba errors such as (/var/log/messages):
Apr 27 14:09:52 hcm92000 smbd[3729]: [2013/04/27 14:09:52, 0] printing/print_cups.c:cups_connect(69)
Apr 27 14:09:52 hcm92000 smbd[3729]:   Unable to connect to CUPS server localhost:631 - Connection refused
Apr 27 14:09:52 hcm92000 smbd[3729]: [2013/04/27 14:09:52, 0] printing/print_cups.c:cups_connect(69)
Apr 27 14:09:52 hcm92000 smbd[3729]:   Unable to connect to CUPS server localhost:631 - Connection refused 
It comes from the Samba compilation options for printer sharing. Most likely you don’t want it. To fix it, connect as root, then modify the file/etc/samba/smb.conf, add the line “printing = bsd” :
[root@fscm92000 samba]# pwd
/etc/samba
[root@fscm92000 samba]#
[root@fscm92000 samba]# more smb.conf
[global]
workgroup = WORKGROUP
netbios name = VBOX
security = user
map to guest = Bad User
username map = /etc/samba/smbusers
guest account = nobody
guest ok = yes
log file = /var/log/samba.log.%m
log level = 2
max log size = 1000
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
printing = bsd
[client]
path = /opt/oracle/psft/pt/tools/setup/Client
writeable = no
available = yes
[ca]
path = /opt/oracle/psft/pt/tools/setup/PsCA
writeable = no
available = yes
[oracle-client]
path = /opt/oracle/psft/pt/oracle-client/windows
writeable = no
available = yes
[root@fscm92000 samba]#
The error shoud gone on next reboot (and/or next samba service start, see below).

4) Samba (bis)
You also may see several of the following errors (/var/log/messages):
Apr 27 13:16:57 fscm92000 nmbd[3798]: [2013/04/27 13:16:57, 0] nmbd/nmbd_nameregister.c:register_name_response(130)
Apr 27 13:16:57 fscm92000 nmbd[3798]:   register_name_response: server at IP 192.168.1.20 rejected our name registration of VBOX<20> IP 192.168.1.21 with error code 6.
Apr 27 13:16:57 fscm92000 nmbd[3798]: [2013/04/27 13:16:57, 0] nmbd/nmbd_mynames.c:my_name_register_failed(36)
Apr 27 13:16:57 fscm92000 nmbd[3798]:   my_name_register_failed: Failed to register my name VBOX<20> on subnet 192.168.1.21.
Apr 27 13:16:57 fscm92000 nmbd[3798]: [2013/04/27 13:16:57, 0] nmbd/nmbd_namelistdb.c:standard_fail_register(304)
Apr 27 13:16:57 fscm92000 nmbd[3798]:   standard_fail_register: Failed to register/refresh name VBOX<20> on subnet 192.168.1.21
I notice these errors only when I started HCM (here the IP=192.168.1.20) and FSCM (here IP=192.168.1.21) in the same time. If I start only one of them, then no errors appear.
It all comes because both have the same registration name – here VBOX – addressed to the DNS server, obviously the DNS does not like it. 
So, go to /etc/samba, edit smb.conf file and replace the “netbios name” parameter to something unique across your VMs (or network). For instance :
From
[global]
workgroup = WORKGROUP
netbios name = VBOX
…
To
[global]
workgroup = WORKGROUP
netbios name = FSCM92000
…
Restart the Samba service as following :
[root@hcm92000 samba]# /etc/rc.d/init.d/smb restart
Shutting down SMB services:                                [  OK  ]
Shutting down NMB services:                                [  OK  ]
Starting SMB services:                                     [  OK  ]
Starting NMB services:                                     [  OK  ]
[root@hcm92000 samba]#
Error is gone.

5) Auto-start
Last but not least, on the system reboot of FSCM92, whether the database is automatically restarted, the AppServer, Process Scheduler and WebServer are not (it is working on HCM92000).
To make sure they all are started on server boot, do the following (as root):
[root@fscm92000 ~]# cd /etc/init.d
[root@fscm92000 init.d]# ln -s /opt/oracle/psft/vm/appbatch-start .
[root@fscm92000 init.d]# cd ../rc3.d
[root@fscm92000 rc3.d]# ln -s ../init.d/appbatch-start S98appbatch-start
[root@fscm92000 rc3.d]# cd ../rc5.d
[root@fscm92000 rc5.d]# ln -s ../init.d/appbatch-start S98appbatch-start
It should make the trick on next server start.

6) Documentation
Very minor, on page 23 of the documentation provided along the VMs, it is mentioned the Peopletools client is in the folder /opt/oracle/psft/pt/tools/setup/client. But it does not work:
[root@fscm92000 ~]# cd /opt/oracle/psft/pt/tools/setup/client
-bash: cd: /opt/oracle/psft/pt/tools/setup/client: No such file or directory
[root@fscm92000 ~]#
The folder is /opt/oracle/psft/pt/tools/setup/Client… (note the Client with C in upper case, yes, Linux is case sensitive).

Enjoy,

Nicolas.