connect to remote windows with command line

D:\SysinternalsSuite>PsExec.exe \\dweidt -u ADESA\username -p password  cmd

JBOSS domain and server group test

in first machine:
domain.bat --host-config=host-master.xml -b dwei-dt -bmanagement dwei-dt
second machine:
domain.bat --host-config=host-slave.xml

print the query been run and parameters been passed in in MyBatis

1) create a logger with package name of the sqlmap with DEBUG level
2) link it to the handler like console or file
3) this was verified from JBOSS server side logging configuration

enable application logging in JBOSS EAP 6

1) remove any loggin configuration file in application's class path(like two in class folder of axis2)
2) config logger in admin-console

add telnet into windows server 2008 R2 dataCenter

pkgmgr /iu:"TelnetClient"

list in perl

we can use the word list operator (qw||) to create lists, and any non-word characters or parentheses to delimit the list, there lists for instance, are identical.

qw|a b c d|
qw/a b c d/
qw[a b c d}

perl variable

to declare a global variable you type $var; or our $var;
and to declare a local variable you type my $var;

go though logback root and appender structures remove an Appender manually

LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
//StatusPrinter.print(lc);
List strList = new ArrayList();
    for (ch.qos.logback.classic.Logger log : lc.getLoggerList()) {
      if(log.getLevel() != null || hasAppenders(log)) {
    System.out.println("LOG:" + log.getName());
   
    Iterator> appenders = log.iteratorForAppenders();
    while(appenders.hasNext()){
    Appender ap = appenders.next();
    System.out.println("APPENDER:" + ap.getName());
    }
   
        strList.add(log.getName());
      }
    }

Creating Keystores for the service and the client

while create secure web service,we need pair of keys represented client and server,both side keep their private key in their key store and import other side's public key in their store also.

server side use its private key to assign the message to client and decrypt the message comes from client and use client public key to verify the message from client and encrypt the message send to client.

Creating Keystores for the service and the client

The signing makes sure authentication, integrity and non-repudiation for messages, which are sent between entities. For signing at the senders side the private key is being used and at the receivers side the public key is being used. Therefore, it is required to follow the following steps in order to create two key-pairs for the sender and the receiver and to extract the public key of each entity to exchange between them.

Step 1: Creating a server keystore (server.jks)

keytool -genkey -alias server -keyalg RSA -keysize 1024 -keypass password -keystore server.jks -storepass password

Step 2: Creating the client keystore (client.jks)

keytool -genkey -alias client -keyalg RSA -keysize 1024 -keypass password -keystore client.jks -storepass password

Step 3: Extract (export) server public key/ certificate from the server keystore (server.jks)

keytool -alias server -export -keystore server.jks -storepass password -file tomcatpub.cer

Step 4: Import the extracted public key to client keystore

keytool -import -alias server -file tomcatpub.cer -keystore client.jks -storepass password

Step 5: Extract (export) client public key/ certificate from the client keystore (client.jks)

keytool -alias client -export -keystore client.jks -storepass password -file client.cer

Step 6: Import the extracted public key to server keystore

keytool -import -alias client -file client.cer -keystore server.jks -storepass password

Now both server and client keystores are having public keys of each other and ready for the communication.

rampart configuration users explained

<ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy">
     <ramp:user>service</ramp:user>
     <ramp:encryptionUser>client</ramp:encryptionUser>
     <ramp:userCertAlias>client</ramp:userCertAlias>
</ramp:RampartConfig>

<ramp:user>

This is the user name used to retrieve the password from the CallbackHandler when UsernameToken security policy being configured.

<ramp:userCertAlias>

This is the key alias used to retrive the password of the corresponding private key from the CallbackHandler.

In the absence of this, <ramp:user> is used for the same purpose.

<ramp:encryptionUser>

This is the key alias of the public key used to encrypt the message.

set up keystores for client and service

(Original author is Ruchith Fernando in WSO2)

There has been many queries about setting up the keys and certificates properly for services and clients when securing Web services. By default Rampart/WSS4J supports using Java and PKCS12 keystores, to extract keys and certificates to be used by services and clients.This tutorial explains how to create key pairs for a client and a service, create keys for a certificate authority (CA), sign public key certificates of the client and the service using CA private key and import the certificates into the client at service keystores.

We will use openssl suite and Java keytool utility that is available with the JDK to create the keystores.

Step 1 : Creating Certificate Authority Keys

A certificate authority is an entity trusted by all parties participating in a secure communication. This entity will certify the trusted party's public keys by signing them. Since the certificate authority is a trusted one it will accept the public key certificates signed by that particular CA as trusted. First we will be creating a new self signed key pair for the certificate authority. We will use openssl to create this key pair. IMPORTANT: Download the following three files and copy them to the directory that will be used to create the keys. index.txt openssl.cnf serial Try the following from the same directory that you saved the above files in:

$ openssl req -x509 -newkey rsa:1024 -keyout cakey.pem -out cacert.pem -config openssl.cnf

Now you will be asked a set of questions in creating the key pair as shown below:

Generating a 1024 bit RSA private key
...++++++
..............++++++
writing new private key to 'CAKey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank. For some fields 
there will be a default value,If you enter '.', the field will be left blank.
-----

Country Name (2 letter code) [AU]:LK
State or Province Name (full name) [Some-State]:Western
Locality Name (eg, city) []:Colombo
Organization Name (eg, company) [Internet Widgits Pty Ltd]:WSO2
Organizational Unit Name (eg, section) []:Axis2
Common Name (eg, YOUR name) []:Ruchith Fernando
Email Address []:ruchith@axis2.com

The result of the above will be two files:

• cakey.pem
• cacert.pem

The cakey.pem file contains the encrypted private key and the cacert.pem file contains the publik key certificate signed using the private key (Figure 1).

Figure 1: CA's private key and the self signed certificate

Step 2 : Client and Service Keys

Now lets create the two sets of keys for the service and the client using the 'keytool' that comes with the JDK. Lets use the 'keytool -genkey' to create a keypair and store it in a keystore using the following command:

$ keytool -genkey -alias client -keyalg RSA -keystore client.jks

Once again you will be asked a series of questions as shown below:

Enter keystore password:  changeme
What is your first and last name?
  [Unknown]:  Client
What is the name of your organizational unit?
  [Unknown]:  Axis2
What is the name of your organization?
  [Unknown]:  WSO2
What is the name of your City or Locality?
  [Unknown]:  Colombo
What is the name of your State or Province?
  [Unknown]:  Western
What is the two-letter country code for this unit?
  [Unknown]:  LK
Is CN=Client, OU=Axis2, O=WSO2, L=Colombo, ST=Western, C=LK correct?
  [no]:  yes

Enter key password for 
        (RETURN if same as keystore password):

The created keys are stored in the client.jks file (Figure 2) which is a Java keystore under the alias client.

Figure 2: Contents of a keystore with a single key entry To verify this fact we can list the contents of the keystore as shown below.

$ keytool -list -v -keystore client.jks -storepass changeme

Keystore type: jks
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: client
Creation date: Apr 12, 2006
Entry type: keyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=Client, OU=Axis2, O=WSO2, L=Colombo, ST=Western, C=LK
Issuer: CN=Client, OU=Axis2, O=WSO2, L=Colombo, ST=Western, C=LK
Serial number: 443d2226
Valid from: Wed Apr 12 21:52:06 LKT 2006 until: Tue Jul 11 21:52:06 LKT 2006
Certificate fingerprints:
         MD5:  EB:25:BA:E1:A9:7F:FB:41:2D:B9:B4:75:D4:47:88:D8
         SHA1: F2:6F:93:3F:51:FA:CC:48:AE:E1:BE:20:04:C7:0E:90:C4:2C:D2:DB


*******************************************
*******************************************

Similar to the way we created the client's keys we can create the service's keys using the following command:

$ keytool -genkey -alias service -keyalg RSA -keystore service.jks

Note that we will be using 'changeme' (without quotes) as the password of both keys and keystores.

Step 3 : Producing Signed X509 Certificates

We can create signed X509 (version 3) certificates using openssl using certificate requests. First we have to create the certificate requests using the generated keys for the client and the service.

$ keytool -certreq -keystore client.jks -storepass changeme -alias client -file client.cert.req
$ keytool -certreq -keystore service.jks -storepass changeme -alias service -file service.cert.req

The above command will create the client.cert.req and service.cert.req files which we will use in the next step to produce X509 certificates signed by the private key of the CA using 'openssl ca' command.

$ openssl ca -config openssl.cnf -out client.pem -infiles client.cert.req
$ openssl ca -config openssl.cnf -out service.pem -infiles service.cert.req

It should be noted that the CA's configuration (openssl.cnf) file is configured to point to the cakey.pem file as the private key to use. The output produced in the client.pem and service.pem files are plain text. To import these signed certificates into the keystores we will have to convert them into the binary (DER) format using 'openssl x509' command.

$ openssl x509 -outform DER -in client.pem -out client.cert
$ openssl x509 -outform DER -in service.pem -out service.cert

Also we will have to convert the CA's certificate to the binary form to be imported to both keystores.

$ openssl x509 -outform DER -in cacert.pem -out cacert.cert

Step 4 : Importing the certificates

First we must import the CA's self signed certificate to both client and service keystores. Lets use the alias 'ca' to identify the CA's certificate.

$ keytool -import -file cacert.cert -keystore service.jks -storepass changeme -alias ca
$ keytool -import -file cacert.cert -keystore client.jks -storepass changeme -alias ca

The 'keytool' will display the information in the certificate and will ask for confirmation to import.

Owner: CN=Ruchith Fernando, OU=Axis2, O=WSO2, L=Colombo, ST=Western, C=LK
Issuer: CN=Ruchith Fernando, OU=Axis2, O=WSO2, L=Colombo, ST=Western, C=LK
Serial number: c2889b1153b983b6
Valid from: Wed Apr 12 23:10:23 LKT 2006 until: Fri May 12 23:10:23 LKT 2006
Certificate fingerprints:
         MD5:  0C:D8:14:DA:B2:32:3A:DA:F3:9B:2F:C8:B8:4E:C8:A0
         SHA1: 20:77:05:EA:50:E6:64:EE:81:05:57:EE:8B:E4:C8:7C:76:98:C0:06
Trust this certificate? [no]:  yes

When we type in 'yes' and confirm the import, the CA's certificate will be imported as a trusted certificate entry.

Certificate was added to keystore

Now we will import the signed certificates to the keystores.

$ keytool -import -file client.cert -keystore client.jks -storepass changeme -alias client
$ keytool -import -file service.cert -keystore service.jks -storepass changeme -alias service

Since the certificate being imported matches the certificate of the given alias and is signed by the trusted CA cert (which is now in the keystore) the keytool will simply import the signed certificate and respond with the following.

Certificate reply was installed in keystore

Its important to note that we must have the CA's certificate imported first before importing the other certificates. If not, when we try to import a certificate the keytool will give the following error:

keytool error: java.lang.Exception: Failed to establish chain from reply

In order to allow secure communication between the client and the service we have to make sure that each party has the other's public key with them. Now lets import the client.cert into the service's keystore and the service.cert into the client's keystore.

$ keytool -import -file client.cert -keystore service.jks -storepass changeme -alias client
$ keytool -import -file service.cert -keystore client.jks -storepass changeme -alias service

Once again since certificates added are signed by a trusted certificate it will be simply imported to the keystore and the keytool will confirm that with the following output.

Certificate was added to keystore

Now we have two keystores for the client and the service including their key pairs and the certificates of the other party and the certificate authority.

config jboss to support https in server.xml

 <!-- SSL/TLS Connector configuration using the admin devl guide keystore -->
 <Connector protocol="HTTP/1.1" SSLEnabled="true"
      port="8443" address="${jboss.bind.address}"
      scheme="https" secure="true" clientAuth="false"
      keystoreFile="${jboss.server.home.dir}\conf/\server.keystore"
      keystorePass="changeit" sslProtocol = "TLS" />

config jboss to support https with a self signed certificate

This HOWTO walks you through the HTTPS configuration using a self-signed certificate on a JBoss server.
It was tested on JBoss EAP 4.3 but should work on other versions.  Tomcat users should refer to the excellent instructions contained in the CASDemo.  To install a certificate from a recognized certificate authority you will need to modify these steps slightly.

Self-signed certificate on JBoss:

1.  The instructions assume a virgin jBoss install.
2. Identify the hostname for the computer hosting the server.  I.e.: myHostname for these instructions
3. Identify the jBoss server type (all, default, production).  I.e.: default for these instructions
4. jBoss recommends using the same file as both keystore and trustore.  This will be server.keystore.  In a virgin install there should be noserver.keystore in the default/conf folder.  If you have one, you must decide whether to delete it (to use these instructions) or whether to adapt the instructions to suit your situation.
5. Creating the keystore and private key:
   1. Open a command prompt or shell and go to the default/conf folder.
   2. keytool -genkey -alias jbosskey -keypass changeit -keyalg RSA -keystore server.keystore
   3. Answer the prompts.  Use myHostname when asked for first/last name.  This is critical.
   4. server.keystore is generated.
   5. keytool -list -keystore server.keystore
   6. You should see the PrivateKeyEntry named jbosskey in the listing.
6. Generating and storing the certificate.
   1. keytool -export -alias jbosskey -keypass changeit -file server.crt -keystore server.keystore
   2. server.crt is generated.
   3. keytool -import -alias jbosscert -keypass changeit -file server.crt -keystore server.keystore
   4. You receive a warning that it already exists in the keystore.  Ignore it.  It is because Java expects separate keystore adn trustore files and we are using only one.
   5. keytool -list -keystore server.keystore
   6. You should see a TrustedCertEntry named jbosscert in the listing.
7. Ensure that you start the server with:
   1. -c default -b 0.0.0.0 -Djavax.net.ssl.trustStore="/server/default/conf/server.keystore"
   2. Where -c specfies your server type
   3. Where -b is required to use the server as anything but localhost, with a server name if you only have 1 network card, with 0.0.0.0 if you have multiple network cards
   4. -Djavax.net.ssl.trustStore specifies the location of your truststore.
   5. In Windows you may place these parameters in a shortcut you use to execute run.bat.
   6. In Unix you may place them in your startup script.
   7. In Eclipse, RAD or any other Eclipse-derivative your best bet is to use the jBossTools plugin.
      1. Go to the jBossServer view
      2. Double-click on the server
      3. Verify that your hostname is set to myHostname
      4. Click OpenLaunchConfiguration
      5. Add to the program arguments.
8. Enable jBoss' Tomcat for HTTPS:
   1. Edt "/server/default/deploy/jboss-web.deployer/server.xml"
   2. Uncomment the section that begins with 
   3. At the end of the section (but still inside of it) add:
      1. keystoreFile="${jboss.server.home.dir}\conf/\server.keystore""
      2. keystorePass="changeit"
9. Post-setup tests:
   1. All of these test should succeed.  If they fail, you probably made a mistake in the previous steps.  Your browser will warn you about untrusted sites/certificates - this is OK, you are using a self-signed certificate. If you want to get rid of the warnings you must get a certificate from a certificate authority.
   2. Vanilla access to jBoss' home page:   _http://myHostname:8080_
   3. HTTPS access to jBoss' home page:  _https://myHostname:8443_
   4. Vanilla access to a non-CAS application:  _http://myHostname:8080/myApp_
   5. HTTPS access to a non-CAS application:  https://myHostname:8443/myApp
   6. Vanilla access to CAS:
      1. _http://myHostname:8080/login_
      2. _http://myHostname:8080/logout_
   7. Access a CAS-enabled application: 
      1. _http://myCAS-enabledApp_
      2. Unprotected pages should be accessible without going to CAS.
      3. You should be redirected to the CAS login the first time you access a protected page.  After the login you should reach the page.
      4. Subsequent accesses to protected pages should not redirect you to the CAS login unless you time out or close your browser.

 Certificate from a Certificate Authority (CA):

scp copy a folder

scp -r user@your.server.example.com:/path/to/foo /home/user/Desktop/

linux file permission disgram

extract xml data from log file

have a case that xml content has been put in log file,while I search log file,I need extract those data out of the log file,xml data is correct formatted and cross multiple lines in log file.
normal linux tool is not working with multiple line data extract and xml data.

have to create a java code to extract data i want.



import java.io.BufferedReader;
import java.io.File;
import java.io.FileReader;
import java.io.IOException;


public class Test {

/**
* @param args
* @throws IOException
*/
public static void main(String[] args) throws IOException {
File file = new File(args[0]);
        BufferedReader br = new BufferedReader(new FileReader(file));
        String line;
        boolean print=false;
        while ((line = br.readLine()) != null) {
            if (line.equals("<WatchList>")){
                print=true;
            }
            if(print){
                System.out.println(line);
            }
            if(line.equals("</WatchList>")){
                print=false;
            }
            br.close();
        }

}

}

install sqlloader from oracle 11g client package

default installation of oracle 11g client installation will not install sqlloader, you must select options from customization installation,or extract and copy from win64_11gR2_client\client\stage\Components\oracle.rdbms.util\11.2.0.1.0\1\DataFiles\filrgroup8.jar