Sunday, July 14, 2013

Starting WebLogic as a Windows Service

WebLogic can be started by different ways and "Windows Service" is one of them.

If you check to create the service during the installation time a Windows service to start a weblogic domain will be created automatically, which we normally miss :)

So by following below steps you can create a Windows Service by which you can start a WebLogic server.

Install a weblogic instance (from 8.1 or above).

Now the script that help us do this process is "installSvc.cmd" which will be present under WL_Home\server\bin

We need to make a explicit script say "services.cmd" and it should contain the below configuration.

************************
echo off
SETLOCAL
call "\bin\setDomainEnv.cmd"
set DOMAIN_NAME=
set USERDOMAIN_HOME=
set SERVER_NAME=
set WLS_USER=
set WLS_PW=
set JAVA_OPTIONS=-Dweblogic.Stdout="\stdout.out"
-Dweblogic.Stderr="\stderr.txt" %JAVA_OPTIONS%
call "\server\bin\installSvc.cmd"
ENDLOCAL
************************

Description of the above script line by line.

First we call the setDomainEnv.cmd file which will set the environment.
Then we set the Domain name, domain location, which server we want to start via service, the username and password respectively.

Option "Dweblogic.Stdout" and "Dweblogic.Stderr" and not mandatory but is recommended to have it so that we will understand if there is any issue while executing the script or starting the server.
In the end we ill call "installSvc.cmd" and which will be creating a windows service.

Save the above file as a ".cmd" file and run it.

A new service called "bea__Domain__ServerNmae" will get created.And start the service.


That's it you service has been created successfully.

If you make the service run "Automatically" then the server will startup when ever you start your Operating System.

Friday, July 12, 2013

Apache WebLogic Integration

Apache- Weblogic integration

Recently I had a chance integrate Apache and WebLogic by following below steps you too can do it :)

For this I am using weblogic 10.3.4(Doesn't really matter which WLS version you ar using) and Apache 2.0.

WebLogic server setting

1) Make sure you are 1 Admin and 1 or more managed server.
2) Deploy a sample application in Managed Server which we will     be connecting via Apache WebServer.
3) Make sure you have a valid entry in "Listen Address:" for the managed server.(You can validate the same from Admin Console--> Server-->Managed Server-->Configuration-->General)


Configure a Admin and a Managed Server and make sure its running

Make sure you have a valid entry in "Listen Address" tab of Managed Server like below.




Now deploy a sample application and try to hit the same.

I have uploaded a sample application which will give you the server and host IP address

You will get below page


Sinne you have already installed apache we are going to configure the Apache so that when you hit a request to Apache it should redirect the same to respective WebLogic server

For that we need to go to below location.

C:\Apache2\conf

Where Apache2 is where w have installed the apache.

There we should see a file called httpd.

Take a backup of the existing one and open the file.

If you go to bottom you should see a entry for "Location" and IfModule, which we need to edit it as below

<Location />
 SetHandler weblogic-handler
</Location>


<IfModule mod_weblogic.c>
 WebLogicCluster <CLuster IP address>
 Debug ON
 WLLogFile C:\Apache\logs\wlproxy.log
 WLTempDir C:\Apache\logs
</IfModule>


Now if you having one IP address then inside IFModule you should enter like below

WebLogicHost myweblogic.server.com
WebLogicPort 7001

If you have multple server in a cluster then the entry should be like

WebLogicCluster myweblogic1.server.com:7001,myweblogic2.server.com:7003,myweblogic3.server.com:7003

Keep the Debug ON and route the wlproxy logs to a location, so that incase of any issue or failure you should get the logs which shows the reason of failure.

Also for testing purpose you can add below parameter inside the IfModule

"DebugConfigInfo ON"

By which you can hit below url

 http://myWebServerServerIP:WebServerPort/myApp/index.jsp?__WebLogicBridgeConfig

But this is not recommended on production.

Also we need to load the WebLogic module in the Apache by adding below entry.

LoadModule weblogic_module modules/mod_wl_20.so

"mod_wl_20.so" file can be found unders WLS_Home\server\plugin\<Your_OS>\<Whether 32 or 64 bit>


By hitting above url we will come to know that, to waht all servers Apache is able to lookup and other tcp level parameters.

That's it , restart the Apache and try to access the application via Apache.

Now you will be able to access the application via Apache

Wednesday, July 10, 2013

JMS Bridge Creation and configuration

JMS Bridge Creation and configuration

In this chapter I will be giving a basic idea about JMS bridge creation and configuration.

What is a JMS bridge and why JMS bridge?

JMS bridge enables you to connect between to Messaging server.

The main advantage of bridge over SAF(Store and Forward which is a WebLogic implemented Messaging Implementation) is that its server independent.

That is you can have the JMS bridge configured to connect between, WebLogic and MQ or Weblogic and JBoss etc. Although SAF can used to connect between two WebLogic servers.

HOW JMS BRIDGE CONFIGURED AND HOW IT IS ABLE TO CONNECT TO OTHER MESSAGING SERVER.

Configuring a JMS bridge is very easy, provided you have proper destination.

In a JMS bridge mainly two connections are made,
   
1) To the Source
2) To the Destination.


We can make the connection XA or non-XA, depending on the requirement and respective resource adaptor with respect to weblogic will be installed.

There are two types of adaptor

jms-xa-adp.rar     :--or which the jndi name will be "eis.jms.WLSConnectionFactoryJNDIXA"

jms-notran-adp.rar :--- for which the jndi name will be "eis.jms.WLSConnectionFactoryJNDINoTX"

Below are the steps for creating the JMS bridge

When you click Bridge from the Admin console you willget below menu

As the above picture shows a Bridge needs a Name, Source Bridge Destination and Target Bridge Destination.
Source bridge destination is from where the messages are picked up and target bridge destination is where the messages are posted to.
**One main feature of bridge is that the communication is uni-directional, i.e. On a single bridge you can’t have source bridge to receive messages from a target bridge.
If you want bi-directional communication you need to configure 2 bridges.(One for sending and other for receiving).
This is the main difference between SAF and Bridge as in SAF you can send and receive messages with one SAF agent.
Now let’s start the configuration.

When you try the create a JMS bridge below screen will appear.
Where you need to give a bridge name and Quality of Service(QOS).




QOS will determine service quality of messaging bridge.
When you are using XA transaction’s, it is always recommended to use Exactly once, which will envelops a received message and sends it within a user transaction (XA/JTA).
When you use Exactly_once mode then it ensures that the message is send only once and will rollback if there is any issue occurs during the message flow. This ensures that message will reach if the client is up and will roll back if there is any issue. Either way the message is secure are can’t be lost.
The other two QOS state are Atmost-once and Duplicate-okay. These are mainly recommended for non-XA messages.
Atmost-once :-  the resource adapter uses the AUTO_ACKNOWLEDGE mode(It will be send only once and doesn’t wait for the receiver to send a acknowledgement, which can cause message lost)
Duplicate-okay :- uses CLIENT_ACKNOWLEDGE(where there is a chance of having duplicate messages).





When you click next you see below page where you need to configure/select(if its already there) the Source Destination.
When I click “New Destination” I will get below page.

In the above page you need to add “connection url” ,”connection factory JNDI Name” and “Destination JNDI Name”
Example values
Connection_url :- t3://localhost:7001
Connection factory jndi :-  cf
Destination jndi :- “jndi configured for Queue or Topic”
The first column is the name of the Source bridge(which you give user specific if needed ) and second is the JNDI adaptor name.
As I mentioned in the beginning you can choose two adaptors, XA or non-XA

Similar for Destination

That's it with the Bridge Creation.
Now if you click bridge --> Monitoring you will be able to see the state of both Source and Destination Bridge.

Ideally if all lookup and configuration is correct the you will be seeing "Forwarding Messages".
If you start the bridge from the admin console, can will be seeing "Started by Administrator"

As we all know this will not work at when you are trying first time. So below are the main issue you could encounter.
1) Failed to connect to Source
2) Failed to connect to Destination.

If you see any above error in the "Monitoring tab" of Bridge, then the message flow will not work.
The main reason for the above issue will be the parameter that you have given in anyone of the below
“connection url” ,”connection factory JNDI Name” or “Destination JNDI Name”
Make sure you have given the connection url in the below format
“t3://localhost:7001”.
If you want to connect to multiple IP’s then you can give the url like below
“t3://<First IP Address>:<Port>,<Second IP Address>,<Port>

Also make sure the jndi names of connection factory and Queue or Topic, which you provided in the source and destination are correct.
It’s always recommended to restart the servers if you have changed any above parameters, so that binding will be refreshed.

In the logs if you see any exception with is mentioning  “eis.jms.WLSConnectionFactoryJNDIXA" or "eis.jms.WLSConnectionFactoryJNDINoTX" then it will be a problem with the adaptor.

Whenever you configure a XA or non-XA bridge to a server or a cluster of servers a file called jms-xa-adp.rar (for XA) or jms-notran-adp.rar(for non-XA) will be deployed automatically.

Make sure the files are in Active state in the “Deployment tab” at the Admin Console  and its targeted to correct servers where the bridge resides.

Tuesday, June 25, 2013

WebLogic Password Reset

Below is the step where we can reset the Weblogic Password, if you are not able to login to Admin Console or forget the admin password.

1.Stop all running weblogic instances.

2.Rename the ldap folder (For eg. path <Domain_home>\servers\AdminServer\data).

3.Rename boot.properties file (For eg.  <Domain_home>\AdminServer\security).

4.Go to the domain's bin directory.

5.Run setDomainEnv.cmd
   In Windows: >setDomainEnv.cmd
   In Unix: # . ./setDomainEnv.sh
 
6.Run below command. Don't forget to give a "." at the nd of the syntax, both on Unix and windows.

  For Unix: java weblogic.security.utils.AdminAccount <username> <new_password> .

  For Windows: java -cp C:\wls103\wlserver_10.3\server\lib\weblogic.jar:%CLASSPATH% weblogic.security.utils.AdminAccount <username> <new_password> .

7. A file called "DefaultAuthenticatorInit.ldift" will get created in the domain directory(from where you are ran the above command).

8.Copy it and paste it in domain security folder (For eg. <Domain_Home>\security) (Make sure you have a back up of old 7.DefaultAuthenticatorInit.ldift  file )


9.Run startWeblogic.cmd/startWeblogic.sh to start Administrator server

10.It will ask to put the user name and password. Put the new credentials.


Changes which needs to be done on the boot.properties so that server will startup  automatically.

1. Edit or create the boot.properties file under location <Domain_home>/server/<Admin_Server>/security
2. Add username and password as below:
   username=<User_Name>
   password=<New_Password>

   Make sure you are not giving any extra spaces.
 
3. Save it and again try to restart Administrator server. It will use boot.properties file and starts running.

If you check the boot.properties files after the statup you will see it encrypted.

JMS AutoMigration

JMS AutoMigration

In this I will be help you understanding the configuration and working of JMS Auto Migration.

WebLogic Server supports migration at the server level—a complete server instance, and all of the services it hosts can be migrated to another machine, either automatically, or manually. For more information
WebLogic Server supports service-level migration for JMS-related services, the JTA Transaction Recovery Service, and user-defined singleton services. These are referred to as migratable services, because you can move them from one server to another within a cluster.

For this you will need below setup configured.

1)      A WebLogic 11g or higher server

2)      1 Admin and (atleast) 2 Managed Server in a cluster.

3)      Node Manager should be configured and both the managed server should be in its server list.

Below are the steps to configure and test the JMS auto migration.

First decide which type of migration you want to use.


* Database -- requires that Data Source For Automatic Migration field is set with a valid JDBC system resource. It implies that there is a table created on that resource that migrating servers will use for leasing.
  * Consensus -- requires that all servers that are migratable, or which could host an auto-migratable target, have a Node Manager associated with them.

In my example I am using Consensus method for which you need to set the cluster -à Migration tab like
below.





1)      Make sure that the NodeManager is running and reachable.


2)      Create 2 JMS server and target them to ms1 (migratable) and ms2 (migratable) respectively.

 3)      Create a connection factory and Queue targeting to cluster and JMS server 1(JMS server 1 is inturn targeted to managed server 1)


4)      The Migration policy of both the server should be “Auto-Migrate Exactly-Once Services” (Same can be found in Admin Console-à Configuration -à  Migration page)

Also in the “Constrained Candidate Servers:” tab make sure both the server are in chosen tab.



 5)      Start both Managed servers
We can see that the JMS servers are targeted to their respective servers.



 Check the JNDI tree of both the server and confirm that the connection factory and Queue name is mapped properly





Shutdown one server (Say ms1).



Check the JMS server summary. In the Current server you will see that JMS Server-1 is now targetted to ms2 instead of ms1.
Same can be confirmed by checking the JNDI tree


Monday, June 24, 2013

Creating A Private Root CA to sign the SSL certificates using OpenSSL


Goal of the Document is to demonstrate the step-by-step procedure to create the CA using OpenSSL on Windows and getting the Certificates signed from the CA created.

NOTE:- This can only be used for testing puposes and cannot be used for Production Systems and this would be Private CA and will not be providing Security as provided by Authorised CA bodies.
Step1. Download and setup the open SSL Environment

Download the required binaries from the below link:

This link will also offers you to download “Visual C++ 2008 Redistributable for Windows” without which you will not be able to run openssl binaries and will hit the below Error. So download the openssl appropriate for your machine along with the Visual C++ Redistributable   :-



Once Installation is completed you will get the folder name “C:\OpenSSL-Win64” created under C:/ by default. (Name may vary according to the binaries used)
In order to identify the windows to openssl commands set the C:\OpenSSL-Win64\bin in your computer system PATH variable

Step 2 : Create Root CA Certificate and key
Open a DOS Command Prompt
Navigate to the OpenSSL Binaries directory type

cd  C:\OpenSSL-Win64\bin

Create the private key. Type

openssl genrsa -des3 -out PrivateRootCA.key 4096

This will create a Private Key named “RootCA.key”

When prompted enter a *very* strong password

And then verify the password

Create the public key. Type

openssl req -new -x509 -days 365 -key PrivateRootCA.key -out PrivateRootCA.cer

When prompted enter the *very* strong password

For Country Name enter the international standard two letter abbreviation (use GB, NOT UK if in the UK)
For State enter the state name in full, or for IN the county name
For Locality, enter where your company is registered, town or city
For organization name enter either the full company name e.g. Mycompany LTD
For organization unit enter Development or Support
For common name use your domain name e.g mycompany.com
For email address enter a valid address e.g. support@mycompany.com Or you can leave this blank and hit Enter

This will create a Public Key for the root ca named “PrivateRootCA.cer”

Now you are done with creation of a Root CA who can sign your Certificates.

You can verify the Root CA by double clicking on RootCA.cer and you would see Issuer and Owner to be same as below:-







From above screen shots you it can be verified as the Subject Type is CA.


Step3:-  Trusting the New CA in Windows trust Store
In order to use this certificate as trusted certificate for your windows  machine please install the certificate in to your Windows trusted CA list as below:-

1. Double Click on the certificate named RootCA.cer
2. Click on “Install Certificate” button at the bottom in the General Tab




3.You will get below screen and click on “Next”



4.Clicking on the next you will get below screen in this select “Place all certificate in the following store” and in the popup window select “Trusted Root certification Authorities” and click “Ok” and Finsh





5.Once you finish importing the new Trusted Root CA into the store you will get below warning appearing into the windows





Please read through the same and say yes if you are fine with this.If not please do not import the Rot CA into your  Windows trust Store.

Step4:- How to get your Self-Signed certificate Signed from this CA?

Generate a self signed certificate using

keytool -genkey -alias server_cert -keyalg RSA -keypass privatepassword -keystore keystore.jks -storepass password ( create a key pair )

keytool -export -alias server_cert -file self-signed.cer -keystore keystore.jks ( export the certificate from keystore keystore into a file, say self-signed.cer

keytool -certreq -v -alias server_cert -file server.csr -keypass privatepassword -storepass password  -keystore keystore.jks

Once above 3 commands executed you will get three files named

keystore.jks
self-signed.cer
server.csr

Now double click on the file named “self-signed.cer” and click on “Details” Tab inside details tab click on the “Serial number” on the lower box you will find a hex values something like
“‎4f b9 da 8c “ and keep it saved somewhere we would need it in the next step.





Now copy the file named “server.csr” to location “C:\OpenSSL-Win64\bin”

Execute the below command:-

openssl x509 -req -days 365 -in server.csr -CA PrivateRootCA.cer -CAkey PrivateRootCA.key -set_serial 0x4fb9da8c -out server.cer

NOTE:- Please look at the parameter named “-set_serial” which is given a value “0x4fb63530” which is nothing but the Serial Key which we had saved earlier as “4f b6 35 30″ from the self-signed certificate so as to generate the signed-certificate with the same key as we need to import this back to the keystore.It is prefixed with 0x to support the Hex value as 0x is not needed if you  Serial value if in Decimal format.
Once above command is executed successfully you will get a file named “server.cer” created on the same location.

Double Click on the file named “server.cer” and you will see as below:-




Where the things to be noticed are “Issued to” and Issued by” which are showing it as the signed by Private RootCA Ltd.

Now go to “Details” tab and check whether the signed certificate has been generated with the same Serial as self-signed certificate:-



Check in the Certification Path and you would be able to see hierarchy of the certification:-





NOTE:- You might not see the chain directly and would see only one cert in the list that happens because the CA (Our  own created) is not known to windows Trust store so in order to get away with that you would have to add this CA into Windows Trust store. (As mentioned above step-by-step) in Step 3


Step 5:- Importing the Signed Certificate into your Keystore to create a cert-chain  and use the same

Now copy the server.cer and PrivateRootCA.cer file to the location where you have created/generated  your keystore.

Execute below command to import the RootCA.cer certificate into your keystore as this is needed to be present in the keystore before importing the signed certificate.

keytool -import -v -noprompt -trustcacerts -alias rootcacert -file PrivateRootCA.cer -keystore keystore.jks -storepass password

Output Would be as below:-
Certificate was added to keystore
[Storing keystore.jks]

Now import the Signed certificate into your keystore

keytool -import -v -alias server_cert -file server.cer -keystore keystore.jks -keypass privatepassword -storepass password


Output would be as below:-

Certificate reply was installed in keystore
[Storing keystore.jks]

Which implies the Signed certificate had been imported successfully.

Now list the keystore and verify that the certificate chain had been created successfully in the keystore:-
keytool -list -v -keystore keystore.jks  -alias server_cert  -storepass password
You would see the output as below:-

D:\keystore>keytool -list -keystore keystore.jks -v -alias server_cert
Enter keystore password:
Alias name: server_cert
Creation date: May 21, 2012
Entry type: PrivateKeyEntry
Certificate chain length: 2
Certificate[1]:
Owner: CN=My.Machine.Host.Name, OU=Support, O=Oracle, L=KA, ST=Ban, C=IN
Issuer: CN=Private RootCA Ltd., OU=Support, O=Oracle, L=BAN, ST=KA, C=IN
Serial number: 4fb9da8c
Valid from: Mon May 21 11:44:04 IST 2012 until: Tue May 21 11:44:04 IST 2013
Certificate fingerprints:
MD5:  5F:FF:6F:8A:C5:22:3D:51:23:A8:FF:AF:96:5A:98:BB
SHA1: 29:4A:14:5A:42:31:57:94:57:3A:CA:B4:E2:AB:00:90:D5:69:96:1C
Signature algorithm name: SHA1withRSA
Version: 1
Certificate[2]:
Owner: CN=Private RootCA Ltd., OU=Support, O=Oracle, L=BAN, ST=KA, C=IN
Issuer: CN=Private RootCA Ltd., OU=Support, O=Oracle, L=BAN, ST=KA, C=IN
Serial number: 9126d09b3c5e8c3c
Valid from: Mon May 21 11:40:41 IST 2012 until: Tue May 21 11:40:41 IST 2013
Certificate fingerprints:
MD5:  7A:8E:2A:3B:19:51:8C:F7:B3:3A:31:CE:78:30:DF:E6
SHA1: B7:7D:58:B2:85:EC:44:15:FB:78:F6:B3:4E:A3:AD:A4:25:5C:B4:C2
Signature algorithm name: SHA1withRSA
Version: 3
Extensions:
#1: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 99 A1 64 8D 58 58 2F AE   05 04 4B 3D C4 35 EA 39  ..d.XX/...K=.5.9
0010: 04 E3 8F 7F                                        ....
]
]
#2: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:true
PathLen:2147483647
]
#3: ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 99 A1 64 8D 58 58 2F AE   05 04 4B 3D C4 35 EA 39  ..d.XX/...K=.5.9
0010: 04 E3 8F 7F                                        ....
]
]
D:\keystore>
Where you can see the Certificate[1] as your server certificate and Certificate[2] as RootCA certificate who signed the certificate.


Step 6:- Configuring and using the Keystore and Certificates created
From the Admin console, go to your server page, and in the Keystore&SSL tab choose:
Custom Identity and Custom Trust
Custom Identity
Custom Identity Key Store File Name:  keystore.jks
Custom Identity Key Store Type: jks
Custom Identity Key Store Pass Phrase:  password
Confirm Custom Identity Key Store Pass Phrase: password
Custom Trust
Custom Trust Key Store File Name:  keystore.jks
Custom Trust Key Store Type: jks
Custom Trust Key Store Pass Phrase:  password
Confirm Custom Trust Key Store Pass Phrase: password
Private Key Alias: server_cert
Passphrase: password  privatepassword
Confirm Passphrase:   privatepassword

Ensure that SSL Listen Port Enabled is selected, then restart your server.
You are done.
WebLogic is now configured successfully to do one-way SSL (no client authentication).