Forgot the password and cannot access WebSphere Application Server administrative console.

CauseAfter enabling WebSphere Application Server with security, the administrator forgot the user id and password and could no longer access the server.

Resolving the problemWARNING: Please use this as the last resort and make sure the server is not in the middle of processing any transactions.

1. Create a copy for security.xml file, in case you need to roll back.
2 Disable the security from the security.xml file (change the very first occurrence of… enabled=”true” to enabled=”false”)
3. Restart the servers.
4. Enable the security from administrative console.
5. Restart the servers.

Taken from IBM site

Yorum (comment) (0)

1- Add the  following settings in the httpd.conf file: 

  • For releases of IBM HTTP Server V1.3.12, 1.3.19, 1.3.26, 1.3.28:

LoadModule rewrite_module    libexec/mod_rewrite.so
AddModule mod_rewrite.c

  • For releases of IBM HTTP Server V2.0x, 6.0x, 6.1x and 7.0x:   

LoadModule rewrite_module    modules/mod_rewrite.so

2-Add following global scope for any 80 port :

RewriteEngine on
RewriteCond %{SERVER_PORT} =80
RewriteRule ^(.*) https://}%{SERVER_NAME}%{REQUEST_URI

3- If you use Plugin , remove 80 port from virtual hosts configuration.

Yorum (comment) (0)

The Session ID but not the session data, can be shared across Web Applications.

In a clustered environment, any HTTP requests associated with an HTTP session must be routed to the same Web application in the same JVM. This ensures that all of the HTTP requests are processed with a consistent view of the user’s HTTP session. The exception to this rule is when the cluster member fails or has to be shut down.

WebSphere is able to assure that session affinity is maintained in the following way: Each server ID is appended to the session ID. When an HTTP session is created, its ID is passed back to the browser as part of a cookie or URL encoding. When the browser makes further requests, the cookie or URL encoding will be sent back to the Web server. The Web server plug-in examines the HTTP session ID in the cookie or URL encoding, extracts the unique ID of the cluster member handling the session, and forwards the request.

The JSESSIONID cookie can be divided into four parts: cache ID, session ID, separator, clone ID, and partition ID (new in V6). JSESSION ID will include a partition ID instead of a clone ID when memory-to-memory replication in peer-to-peer mode is selected. Typically, the partition ID is a long numeric number.

For example the JSESSIONID cookie value of 0000HHAnbYWnNxGD-iVupvcArfr:14dtuueci is made up of these four parts
Cache ID 0000

Session ID: HHAnbYWnNxGD-iVupvcArfr

separator :

Clone ID: 14dtuueci

Yorum (comment) (0)

1) Stop WAS.

2) Reboot the server. If the system has been up for a long time it might not be possible to get a contiguous section of memory to allocate the large pages in. You will see this because if you run the sysctl command below it will fail to work. So it is recommended but not critical that the first step is to reboot the server.

3) Run the command:

echo 1536 >  / proc / sys / vm / nr_hugepages

Where 1536 denotes the number of 2MB large pages required, in this case 3GB worth. This setting will not be permanent so you will have to add this to the boot options for the server (/ etc / init.d / boot.local or equivalent).

4) Run more / proc / meminfo and check that it looks something like this at the bottom of the output:

HugePages_Total: 1536

HugePages_Free: 1536

Hugepagesize: 2048kB

Yazının tamamını okuyun (read more) »

Yorum (comment) (0)

For encode:  <WASROOT>java/bin/java -cp <WASROOT>/deploytool/itp/plugins/com.ibm.websphere.v6(xxx)/ws_runtime.jar com.ibm.ws.security.util.PasswordEncoder  <password>

result:   decoded password == “password”, encoded password == “{xor}Mzs+Lz47MjYx”

For decode: <WASROOT>java/bin/java -cp <WASROOT>/deploytool/itp/plugins/com.ibm.websphere.v6(xxx)/ws_runtime.jar com.ibm.ws.security.util.PasswordDecoder   {xor}Mzs+Lz47MjYx

result:      encoded password == “{xor}Mzs+Lz47MjYx”, decoded password == “password”

Yorum (comment) (0)

If you have a stash file (*.sth) you can use this perl script to learn password:

#!/usr/bin/perl -w

use strict;

die “Usage: $0 <stash file>\n” if $#ARGV != 0;

my $file=$ARGV[0];
open(F,$file) || die “Can’t open $file: $!”;

my $stash;
read F,$stash,1024;

my @unstash=map { $_^0xf5 } unpack(“C*”,$stash);

foreach my $c (@unstash) {
    last if $c eq 0;
    printf “%c”,$c;
}
printf “\n”;

Yorum (comment) (0)

The heap is divided into two spaces:

  1. The new space.
  2. The tenured space.

The new space is further divided into two zones:

  1. Allocate space.
  2. Survivor space.

image

Initially, the survivor space is completely empty. A new object is always created in the allocate space.

image

If when creating a new object an allocation failure takes place in the allocate space, a minor GC called scavenge is started. Scavenge works as follows.

image
Yazının tamamını okuyun (read more) »

Yorum (comment) (1)

You can use -Xloratio parameter For WebSphere Application Server V6.0, V5.1 and V5.0 (Java 1.4.2) .If your WAS version is WebSphere Application Server V7.0, V6.1 (Java V1.6, V1.5) ,There is no need to explicitly set the size. The value can be manually limited with using the -Xloainitial and -Xloamaximum, however it is not recommended.

The detailed technote :
http://www-01.ibm.com/support/docview.wss?uid=swg21236509&myns=swgws&mynp=OCSSNVBF&mynp=OCSSEQTP&mync=E

Yorum (comment) (1)

Search folder in jar file example:
find folder -name ‘*.jar’ -o -name ‘*.war’ -o -name ‘*.ear’ -type f | xargs -i bash -c “java path -tvf {}| tr / . | grep searched data && echo {}”

find /opt/WebSphere60/PortalServer/ -name ‘*.jar’ -o -name ‘*.war’ -o -name ‘*.ear’ -type f | xargs -i bash -c “/opt/WebSphere60/AppServer/java/bin/jar -tvf {}| tr / . | grep EDataObjectHbtrImpl$EDataObjectExternalizable && echo {}”

Search a word in gzip files without extract example :
zcat compressed folder | grep -i searched data | wc -l
zcat SystemOut.log.gz | grep -i Enes | wc -l

Yorum (comment) (0)

1- Create a group (ihsgrp) and a user (ihsadm) for the IHS (IBM Http Server)

2- Change owner for IHS
chown –R ihsadm:ihsgrp /opt/IBMIHS61

3- Edit the httpd.conf file so that the web server runs with the user ihsadm and the group ihsgrp
User ihsadmin
Group ihsgrp

4- Edit visudo to add belowed line for linux:
wasadm ALL=NOPASSWD: /opt/IBMIHS60/bin/apachectl -k start -f /opt/IBMIHS60/conf/httpd.conf, /opt/IBMIHS60/bin/apachectl -k stop -f /opt/IBMIHS60/conf/httpd.conf

5- Create run.sh file in IHS/bind directory and add this command:
/usr/bin/sudo /opt/IBMIHS61/bin/apachectl “$@”

6- Change owner for run.sh so wasadm user can execute
chown wasadm:wasgrp run.sh

7- Change startCommand and stopCommand parameter values:
Go webserver properties page of the admin console
Web servers > TWSWKI0101TR > Process Definition

startCommand : ${WEB_INSTALL_ROOT}/bin/run.sh
stopCommand : ${WEB_INSTALL_ROOT}/bin/run.sh

Yorum (comment) (0)