Pages

Tuesday, October 28, 2014

JPS-01050: Opening of wallet based credential store failed. Reason java.io.IOException: PKI-02002: Unable to open the wallet. Check password

Hi, All today I hit with very wired problem and later got solution using some Oracle post, so though to share in my blog as well.

I just did fresh domain creation and while starting the domain using ./startWeblogic.sh script I was getting below error.

Initially I though, while creating domain I gave some wrong password for "weblogic" user, so deleted the domain and re-created again, but again while starting I got same error. Second time I again thought I might gave wrong password while creating domain, I deleted it again and created Domain third time.

However, this time also same error poped-up, then I started googling on this issue and found solution. 

Error Message:

<Oct 28, 2014 12:44:48 AM EDT> <Critical> <WebLogicServer> <BEA-000386> <Server subsystem failed. Reason: weblogic.security.SecurityInitializationException: The loading of OPSS java security policy provider failed due to exception, see the exception stack trace or the server log file for root cause. If still see no obvious cause, enable the debug flag -Djava.security.debug=jpspolicy to get more information. Error message: JPS-01050: Opening of wallet based credential store failed. Reason java.io.IOException: PKI-02002: Unable to open the wallet. Check password.
weblogic.security.SecurityInitializationException: The loading of OPSS java security policy provider failed due to exception, see the exception stack trace or the server log file for root cause. If still see no obvious cause, enable the debug flag -Djava.security.debug=jpspolicy to get more information. Error message: JPS-01050: Opening of wallet based credential store failed. Reason java.io.IOException: PKI-02002: Unable to open the wallet. Check password.
        at weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.loadOPSSPolicy(CommonSecurityServiceManagerDelegateImpl.java:1402)
        at weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.initialize(CommonSecurityServiceManagerDelegateImpl.java:1022)
        at weblogic.security.service.SecurityServiceManager.initialize(SecurityServiceManager.java:873)
        at weblogic.security.SecurityService.start(SecurityService.java:141)
        at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
        Truncated. see log file for complete stacktrace

Solution:

open putty session from root user and run below command -

root> chmod -R 777 /tmp

Note: I really don't know relation between the weblogic error message and the solution which works for this, however above solution work in my case, and I was able to start the Admin server.
Refer below thread as well -

https://community.oracle.com/message/11006215




Monday, August 25, 2014

Mounting the NFS shared folder from Net Gear ReadNAS Device




This document illustrate how to create a shared folder in Netgear ReadyNAS device and mount it to virtual host or physical host.

We can create either shared folder in NAS or a new volume, in my case I have created a shared folder coz creating multiple volume option was not available on the NAS device which I was using
.
Go to NAS device admin page and crate a folder, and enable NSF protocol to access that folder.







Note:

Make sure you have given proper access and allowed all the IPs address from which you want to access the NAS device shared folder using NAS admin page under NFS protocol 


 



Once creation of folder, protocol enabling and security provisioning is done, then we can login to putty session for a host where we want to map this NAS folder.



There must be two service up and running on the host e.g. ‘rpcbind’ and ‘nfs’, check these service using below command given in snap –











If the service are not running, then install ‘nfs-utils’ package.
 





Check the service ‘rpcbind’ and ‘nfs’ service status now, it’s must be available but stopped now





Start ‘rpcbind’ and ‘nfs’ service 

 


Once the services started then we can use below command to mount the folder which we have created initially.

Create ‘u02’ folder in host using this command ‘mkdir ‘u02’
“mount -t nfs 192.168.1.XXX:/data/soa_repo /u02”

Explanation of above command –

Mount – its OS command to use to mount a folder, for more details say ‘man mount’

‘-t’ option for indicating type of file system. In this case its ‘nfs’
 
192.168.1.XXX – Is the IP the NAS 

Data- is the volume name on NAS under which shared folder been created. 

‘soa_repo’ is the shared folder name which we have created. 

/u02 – the local folder under which we want to mount shared NAS folder.

verify the mounted folder using ‘df –h’ option




Configuration related to auto mount a device during restart of machine/server/vServer


In most of OS there is file located under /etc directory called ‘fstab’. This file contains descriptive information about file system. ‘fstab’ file get utilized when we run mount, umount and fsck utility.
For Auto mount configuration, also this file has a parameter which need to be setup. Please add below line considering mounting ‘nfs’ file system.

fpnas:/data/soa_repos                                 /u02       nfs          defaults               0              0

In above syntax ‘default’ is the parameter which will help to auto mount.

Default represent these option - rw,suid,dev,noexec,auto,user,async

For more details check ‘man fstab’

Of this blog have detail info about fstab file.


http://community.linuxmint.com/tutorial/view/1513


Points to consider while uploading data from iSCSI volume to NAS volume


The points which I am going to describe here does vary from NAS drive to NAS drive. For NetGearReady NAs I have observed below –

When I copied data from local mount point to NAS mount point e.g. ‘cp –R --preserve /Local /NAS’, by mistake I did via root OS user, once data got copied into NAS drive, the ownership of all the files and folders was set to ‘nobody’ user. Now this nobody ownership if we try to change using command e.g. ‘chown –R oracle:oinstall /u02’ then it does not allow to change even from root user.

This has happened because I have copied data into NAS using root user, if you run copy command using different OS user e.g. ‘oracle’ user then the file which get transferred on NAS does maintain existing ownership but if you do via root user its change the ownership to ‘nobody’ irrespective of what parameter you are using with ‘cp’ command. If you use argument ‘--preserve’ even then also its does change ownership of the files once it get copied to NAS.

NAS has provision to create user and groups but in our case I don’t find any relation between OS user group to NAS user groups, they both are isolated to each other.