Regular Commands in UNIX

a)      To find out the running processes the command is                 :Ps – ef| grep java

b)       To find out the disk space the command is                           :du

c)      To find out the file system the command is                            :df

d)     To find out the network performance/port info command is   :netstat

e)      To find out the CPU utilisation the command is                     : topas/osstat

f)       To kill the running process the command is                           : kill -9 <PID>

g)      To generate heap/thresd dump the command is                    :kill -3 <PID>

h)      To  change the privileges of the file/folder the command is    : chmod

i)        To  change the owner of the file/folder the command is         :chown

j)        To  list the file the command is                                             : ls

k)      To create DIR(folder) the command is                                 :mkdir

l)        To TAR the files ,folders we use the following command

Tar –xvf  <file name with path>         --

Tar – uvf                                             --adding one or two files two folder

Tar – cvf                                              -- total folder

m)    To schedule the job in cron command is as follwos

Crontab –l ( to list all the scheduled jobs)

Crontab –e ( to edit the  scheduled job)

                        Whithin the crontab the syntax for the schedule the script as follows

Ex:  30 6  *  * 1,3,5  /usr/bin/calender

30(minutes)  6 (hours) *(day of the month)  * (month of the year) 1,3,5  (day no of the week)/usr/bin/calender

In the  above example we scheduled the script called calender which is located in the location “/usr/bin” to run every  Monday,Wednesday and friday

n)      To find fully qualified domain name (FQDN) if you know IP

$ Nslookup <IP_ADDRESS>                                    --(vice versa)

Setting webcontainer custom properties

An example jacl script which creates a webcontainer custom property, after deleting any current instances of the property being added, might contain the following but with lines 2 to 6 modified to specify appropriate values for <cell of server>, <node of server>, <server to create property for>,
<webcontainer property name> and <webcontainer property value>:

# set variables
set cellName <cell of server>
set nodeName <node of server>
set serverName <server to create property for>
set propertyName <webcontainer property name>
set propertyValue <webcontainer property value>
# define some helper variables
set a1 [list name $propertyName]
set a2 [list value $propertyValue]
set attrs [list $a1 $a2]
# get server config
set server [$AdminConfig getid
/Cell:$cellName/Node:$nodeName/Server:$serverName/]
#get the webcontainer config from the server config
set webcontainer [$AdminConfig list WebContainer $server]
# get a list of existing webcontainer properties
set webcontainerProperties [$AdminConfig list Property $webcontainer]
# Check for existing properties with the same name and delete if found
if { ${webcontainerProperties} != "" } {
foreach propertyID ${webcontainerProperties} {
set propertyIDName [$AdminConfig showAttribute $propertyID name]
set match [string match $propertyIDName $propertyName]
if { ${match} == 1 } {
$AdminConfig remove $propertyID
}
}
}
# Create the specified property
$AdminConfig create Property $webcontainer $attrs
# Save updates
$AdminConfig save

JDBC Drivers and their types

JDBC provides a standard library for accessing relational data, allowing users to develop SQL calls using the    Java Application Programming Interface (API). The JDBC driver is responsible for the data access communication interface with the database management system (DBMS).

Selecting the appropriate driver is fundamental to improving performance. According to Sun Microsystems, there are four categories of JDBC drivers (Types 1–4), and more than 177 models.

   
Type 1 – JDBC–Open Database Connectivity (ODBC) bridge: 

      Type 1 driver provides JDBC access to one or more ODBC drivers. Type 1 drivers assist companies that already possess a large ODBC population with the JDBC educational process. Type 1 drivers are slow, however, because they require JDBC-ODBC translation. As such, they are not well suited for large enterprises.

    Type 2 – Partial Java driver:

 A Type 2 driver converts the calls made from the JDBC API to the receiving machine’s API for a specific database (DB2, Oracle, Sybase, SQL Server, etc.). A Type 2 driver contains compiled code for the backend system. Type 2 drivers process more quickly than Type 1 drivers. The code must be compiled, however, for every operating system on which the application runs. In Windows NT and z/OS development, organizations may wish to develop with a Type 4 driver and then transition to a Type 2 driver for production.

    Type 3 – Pure Java driver for database middleware:

 A Type 3 driver provides connectivity to many different databases, translating JDBC calls into the middleware vendor’s protocol and then into the database-specific protocol via the middleware server. A Type 3 driver is often faster than Type 1 and 2 drivers, and is useful if an organization wishes to connect to multiple database types. Database-specific code, however, must reside on the middle tier. If the application is going to run on different operating systems, a Type 4 driver may be more appropriate.

   Type 4 – Direct-to-database Java driver:

 A Type 4 driver converts JDBC calls into packets that are transferred over the network in the database’s proprietary format, allowing a direct call from the client to the database without a middle tier. Type 4 drivers often offer better performance than Type 1 or 2 drivers; do not require additional code on client or server machines; and can be downloaded dynamically. Type 4 drivers, however, are not optimized for the operating system and are unable to take advantage of operating system features. Users also need a different driver for each different database.

Enabling Servlet Caching

server1=AdminConfig.getid('/Node:tux1Node01/Server:server1/')

print server1

mywebcont=AdminConfig.list('WebContainer', server1)

print AdminConfig.show(mywebcont)

print "now modify settings"

AdminConfig.modify(mywebcont, [['enableServletCaching', 'true']] )

AdminConfig.save()

print AdminConfig.show(mywebcont)

Changing the JDBC connection Pool Size

server1=AdminConfig.getid('/Node:Node01/Server:server1/')

print server1

jvm = AdminConfig.list('JavaVirtualMachine', server1)

print "-->  variable jvm is"

print "-->  AdminConfig.show(jvm)"

myds=AdminConfig.getid('/DataSource:TradeDataSource/')

myds=AdminConfig.getid('/DataSource:TradeDataSource/')

mydslist=AdminConfig.list('ConnectionPool',myds)

print "-->  before: "

print AdminConfig.show(mydslist)

AdminConfig.modify(myds, '[[connectionPool [[maxConnections 113]]]]')

AdminConfig.save()

#AdminConfig.modify(myds, '[[connectionPool [[minConnections 20]]]]')

#AdminConfig.save()

print "-->  after: "

mydslist=AdminConfig.list('ConnectionPool',myds)

print AdminConfig.show(mydslist)

# monitor connections at the database with the command

# watch -d -n 5 "db2 list applications | wc -l"

# or informix

# watch -d -n 5 "onstat -g ses | wc -l"

# this will include some irrelevant lines in count -- feel free to egrep them out

Increasing JVM Heap Size

Following is the script to increase the JVM Heap Size 512 to 1 GB

server1=AdminConfig.getid('/Node:tux1Node01/Server:server1/')

print server1

jvm = AdminConfig.list('JavaVirtualMachine', server1)

print " variable jvm is"

print jvm

print AdminConfig.show(jvm)

print " change jvm settings"

AdminConfig.modify(jvm, [['initialHeapSize', 512 ], ['maximumHeapSize', 1024 ]])

print "AdminConfig.show(jvm)"

print AdminConfig.show(jvm)

AdminConfig.save()

Forward Proxy

Forward Proxy

1.    A forward proxy is the most common form of a proxy server and is generally used to pass requests from an isolated, private network to the Internet through a firewall. Using a forward proxy, requests from an isolated network, or intranet, can be rejected or allowed to pass through a firewall. Requests may also be fulfilled by serving from cache rather than passing through the Internet. This allows a level of network security and lessens network traffic.

2.    An ordinary forward proxy is an intermediate server that sits between the client and the origin server. In order to get content from the origin server, the client sends a request to the proxy naming the origin server as the target and the proxy then requests the content from the origin server and returns it to the client. The client must be specially configured to use the forward proxy to access other sites.

3.    The forward proxy is activated using the ProxyRequests directive. Because forward proxies allow clients to access arbitrary sites through your server and to hide their true origin, it is essential that you secure your server so that only authorized clients can access the proxy before activating a forward proxy.

    The above image shows a forward proxy configuration. An intranet client initiates a request that is valid but is not cached on Server A (Proxy Server). The request is sent through the firewall to the Internet server, Server B (App Server), which has the information the client is requesting. The information is sent back through the firewall where it is cached on Server A and served to the client. Future requests for the same information will be fulfilled by the cache, lessening network traffic (proxy caching is optional and not necessary for forward proxy to function on your HTTP Server).

FORWARD PROXIES ARE GOOD FOR:

·         Content Filtering

·         email security

·         NAT’ing

·         Compliance Reporting

Configuring FORWARD PROXIES:

ProxyRequests On
ProxyVia On

<Proxy *>
Order deny, allow
Deny from all
Allow from internal.example.com
</Proxy>

You can control who can access your proxy via the normal <Directory> control block using the following example:

<Directory proxy:*>
Order deny,allow
Deny from all
Allow from internal.example.com
</Directory>
You can control who can access your proxy via the <Proxy> control block as in the following example:

<Proxy *>
Order Deny, allow
Deny from all
Allow from 192.168.0
</Proxy>

Reverse Proxy

Reverse proxy

In computer networks, a reverse proxy is a type of proxy server that retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client as though it originated from the reverse proxy itself. A reverse proxy is usually situated closer to the server(s) and will only return a configured set of resources.

A reverse proxy, by contrast, appears to the client just like an ordinary web server. No special configuration on the client is necessary. The client makes ordinary requests for content in the name-space of the reverse proxy. The reverse proxy then decides where to send those requests, and returns the content as if it was itself the origin.

A typical usage of a reverse proxy is to provide Internet user’s access to a server that is behind a firewall. Reverse proxies can also be used to balance load among several back-end servers, or to provide caching for a slower back-end server. In addition, reverse proxies can be used simply to bring several servers into the same URL space.

Example

A = Client Machine

B = The Reverse proxy machine

C = The Origin server

Normally, one would connect directly from A --> C

However, in some scenarios, it is better for the administrator of C to restrict disallow direct access, and force visitors to go through B first. So, as before, we have data being retrieved by B --> C on behalf of A, which chains as follows: A --> B --> C.

The difference is user A does not know he is accessing C.

A Reverse Proxy requires no configuration or special knowledge by the client, A.

The client A probably thinks he is visiting C directly (A --> C), but the reality is that B is the invisible go-between (A --> B --> C again).

Reasons to set up a reverse proxy server

1. Reverse proxies can hide the existence and characteristics of the origin server(s).
2. Application firewall features can protect against common web-based attacks. Without a reverse proxy, removing malware or initiating takedowns, for example, can become difficult.
3. In the case of secure websites, the SSL encryption is sometimes not performed by the web server itself, but is instead offloaded to a reverse proxy that may be equipped with SSL acceleration hardware.
4. A reverse proxy can distribute the load from incoming requests to several servers, with each server serving its own application area. In the case of reverse proxying in the neighborhood of web servers, the reverse proxy may have to rewrite the URL in each incoming request in order to match the relevant internal location of the requested resource.
5. A reverse proxy can reduce load on its origin servers by caching static content, as well as dynamic content. Proxy caches of this sort can often satisfy a considerable amount of website requests, greatly reducing the load on the origin server(s). Another term for this is web accelerator.
6. A reverse proxy can optimize content by compressing it in order to speed up loading times.
7. In a technique known as "spoon feeding", a dynamically generated page can be produced all at once and served to the reverse-proxy, which can then return it to the client a little bit at a time. The program that generates the page is not forced to remain open and tying up server resources during the possibly extended time the client requires to completing the transfer.
8. Reverse proxies can be used whenever multiple web servers must be accessible via a single public IP address. The web servers listen on different ports in the same machine, with the same local IP address or, possibly, on different machines and different local IP address altogether. The reverse proxy analyses each incoming call and delivers it to the right server within the local area network.

How to configure a reverse proxy in Apache

The following configuration enables the reverse proxy in apache

LoadModule proxy_module      modules/mod_proxy.so

LoadModule proxy_http_module modules/mod_proxy_http.so

LoadModule headers_module    modules/mod_headers.so

LoadFile   /usr/lib/libxml2.so

LoadModule proxy_html_module modules/mod_proxy_html.so

LoadModule xml2enc_module modules/mod_xml2enc.so

ProxyRequests off

ProxyPass /app1/ http://internal1.example.com/

ProxyPass /app2/ http://internal2.example.com/

ProxyHTMLURLMap http://internal1.example.com /app1

ProxyHTMLURLMap http://internal2.example.com /app2

<Location /app1/>

        ProxyPassReverse /

        ProxyHTMLEnable On

        ProxyHTMLURLMap  /      /app1/

        RequestHeader    unset  Accept-Encoding

</Location>

<Location /app2/>

        ProxyPassReverse /

        ProxyHTMLEnable On

        ProxyHTMLURLMap /       /app2/

        RequestHeader   unset   Accept-Encoding

</Location>

Explanation for above configuration

1).Loading Modules

Apache Module mod_proxy implements a proxy for Apache. In keeping with Apache's modular architecture, mod_proxy is itself modular and a typical proxy server will need to enable several modules. For Example

a.    mod_proxy: The core module deals with proxy infrastructure and configuration and  managing a proxy request

b.    mod_proxy_http: This handles fetching documents with HTTP and HTTPS.

c.    mod_proxy_ftp: This handles fetching documents with FTP.

d.    mod_proxy_connect: This handles the CONNECT method for secure (SSL)  Tunneling

e.    mod_proxy_ajp: This handles the AJP protocol for Tomcat and similar backend servers.

f.     mod_proxy_balancer: implements clustering and load-balancing over multiple back ends.

g.    mod_cache, mod_disk_cache, mod_mem_cache: this deal with managing a document cache. To enable caching requires mod_cache and one or both of disk_cache and mem_cache.

h.    mod_proxy_html: This rewrites HTML links into a proxy's address space.

i.      mod_xml2enc: This supports internationalization (i18n) on behalf of mod_proxy_html and other markup-filtering modules. space.

j.     mod_headers: This modifies HTTP request and response headers.

k.    mod_deflate: Negotiates compression with clients and back ends.

As with any modules, the first thing to do is to load them in httpd.conf (Of course, you may not need all the modules). 

LoadModule    proxy_module           modules/mod_proxy.so

LoadModule   proxy_http_module    modules/mod_proxy_http.so

LoadModule   headers_module         modules/mod_headers.so

LoadModule   deflate_module           modules/mod_deflate.so

LoadFile        /usr/lib/libxml2.so (For windows libxml2.dll and iconv.dll and xlib.dll)

LoadModule   xml2enc_module        modules/mod_xml2enc.so

LoadModule   proxy_html_module    modules/mod_proxy_html. So

2).Basic Configuration part

The ProxyRequests directive should usually be set off when using ProxyPass. Do not set "ProxyRequests On". It turns your server into an Open Proxy.

                       ProxyRequests off

3). ProxyPass

The fundamental configuration directive to set up a reverse proxy is ProxyPass.

ProxyPass       /app1/ http://internal1.example.com/

ProxyPass       /app2/  http://internal2.example.com/

This directive allows remote servers to be mapped into the space of the local server; the local server does not act as a proxy in the conventional sense, but appears to be a mirror of the remote server. Path is the name of a local virtual path; url is a partial URL for the remote server and cannot include a query string.

Suppose the local server has address http://example.com/ ; then

ProxyPass /mirror/foo/  http://backend.example.com/

Will cause a local request for http://example.com/mirror/foo/bar  to be internally converted into a proxy request to http://backend.example.com/bar

The ! Directive is useful in situations where you don't want to reverse-proxy a subdirectory, e.g.

ProxyPass /mirror/foo/i !
ProxyPass /mirror/foo http://backend.example.com

Will proxy all requests to /mirror/foo to backend.example.com except requests made to /mirror/foo/i.

4).ProxyPassReverse

ProxyPass just sends traffic straight through. So when the application servers generate references to themselves (or to other internal addresses), they will be passed straight through to the outside world, where they won't work

For example, an HTTP redirection often takes place when a user (or author) forgets a trailing slash in a URL. So the response to a request for http://www.example.com/app1/foo proxies to http://internal.example.com/foo which generates a response:

        HTTP/1.1 302 Found

        Location: http://internal.example.com/foo/

        (etc)

The command to enable such rewrites in the HTTP Headers is ProxyPassReverse. The Apache documentation suggests the form:

            ProxyPassReverse /app1/ http://internal1.example.com/

            ProxyPassReverse /app2/ http://internal2.example.com/

5).ProxyHTMLURLMap

Mod_proxy_html is based on a SAX parser: specifically the HTMLparser module from libxml2 running in SAX mode (any other parse mode would of course be very much slower, especially for larger documents). It has full knowledge of all URI attributes that can occur in HTML 4 and XHTML 1. Whenever a URL is encountered, it is matched against applicable ProxyHTMLURLMap directives. If it starts with any from-pattern, that will be rewritten to the to-pattern. Rules are applied in the reverse order to their appearance in httpd.conf, and matching stops as soon as a match is found.

Here's how we set up a reverse proxy for HTML. Firstly, full links to the internal servers should be rewritten regardless of where they arise, so we have:

ProxyHTMLURLMap http://internal1.example.com /app1

ProxyHTMLURLMap http://internal2.example.com /app2

Note that in this instance we omitted the "trailing" slash. Since the matching logic is starts-with, we use the minimal matching pattern. We have now globally fixed case 3 above.

Case 2 above requires a little more care. Because the link doesn't include the hostname, the rewrite rule must be context-sensitive. As with ProxyPassReverse above, we deal with that using <Location>

<Location /app1/>

        ProxyHTMLURLMap / /app1/

</Location>

<Location /app2/>

        ProxyHTMLURLMap / /app2/

</Location>

Class Loadres

Class loading

Class loaders are part of the Java virtual machine (JVM) code and are responsible for finding and loading class files. Class loaders enable applications that are deployed on servers to access repositories of available classes and resources. Application developers and deployers must consider the location of class and resource files, and the class loaders used to access those files, to make the files available to deployed applications.

 Class loaders affect the packaging of applications and the runtime behavior of packaged applications of deployed applications

Class loaders

The runtime environment of WebSphere Application Server uses the following class loaders to find and load new classes for an application in the following order:

1.    The bootstrap, extensions, and CLASSPATH class loaders created by the Java virtual machine
A.   Bootstrap: uses the boot class path (typically classes in jre/lib) to find and load classes.
B.    Extensions: uses the system property java.ext.dirs (typically jre/lib/ext) to find and load classes.
C.    CLASSPATH: class loader uses the CLASSPATH environment variable to find and load classes. The CLASSPATH class loader loads the Java 2 Platform, Enterprise Edition (J2EE) application programming interfaces (APIs) provided by the WebSphere Application Server product in the j2ee.jar file

2.      WebSphere extensions class loader

A.   The WebSphere extensions class loader loads the WebSphere Application Server classes that are required at run time. This class loader uses a ws.ext.dirs system property to determine the path that is used to load classes. Each directory in the ws.ext.dirs class path and every Java archive (JAR) file or ZIP file in these directories is added to the class path used by this class loader.

B.   The WebSphere extensions class loader also loads resource provider classes into a server if an application module installed on the server refers to a resource that is associated with the provider and if the provider specifies the directory name of the resource drivers.

3.    Application module class loaders

A.   The application elements can be Web modules, enterprise bean (EJB) modules, resource adapter archives (RAR files), and dependency JAR files. Application class loaders follow J2EE class-loading rules to load classes and JAR files from an enterprise application

4.    Web module class loaders

A.   Web module class loaders load the contents of the WEB-INF/classes and WEB-INF/lib directories. Web module class loaders are children of application class loaders.

Class loaders used and the order of use

                  
   A.   Each class loader is a child of the previous class loader. That is, the application  module class loaders are children of the WebSphere extensions class loader, which  is  a child of the CLASSPATH Java class loader.
B.   Whenever a class needs to be loaded, the class loader usually delegates the request to its parent class loader. If none of the parent class loaders can find the class, the original class loader attempts to load the class. Requests can only go to a parent class loader; they cannot go to a child class loader.
C.    If the WebSphere extensions class loader is requested to find a class in a J2EE module, it cannot go to the application module class loader to find that class and a ClassNotFoundException error occurs.
D.    After a class is loaded by a class loader, any new classes that it tries to load reuse the same class loader or go up the precedence list until the class is found.

Class loader mode:

1.    Parent first (Also known as Classes loaded with parent class loader first):

The Parent first class-loader mode causes the class loader to delegate the loading of classes to its parent class loader before attempting to load the class from its local class path. This value is the default for the class-loader policy and for standard JVM class loaders.

2.    Parent last(Also known as Classes loaded with application class loader first):

The Parent last class-loader mode causes the class loader to attempt to load classes from its local class path before delegating the class loading to its parent. Using this policy, an application class loader can override and provide its own version of a class that exists in the parent class loader.