server {
    listen        80;
    server_name   nginx.org  www.nginx.org;
    root          /data/www;

    location / {
        index     index.html  index.php;
    }

    location ~* \.(gif|jpg|png)$ {
        expires   30d;
    }

    location ~ \.php$ {
        fastcgi_pass   localhost:9000;
        fastcgi_param  SCRIPT_FILENAME
                       $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
}

nginx first searches for the most specific location given by literal strings regardless of the listed order. In the configuration above the only literal location is “/” and since it matches any request it will be used as a last resort. Then nginx checks locations given by regular expression in the order listed in the configuration file. The first matching expression stops the search and nginx will use this location. If no regular expression matches a request, then nginx uses the most specific literal location found earlier.

File excerpt: nginx.conf location directives

location / { }
location /images/ { }
location /blog/ { }
location /planet/ { }
location /planet/blog/ { }

location ~ IndexPage\.php$ { }
location ~ ^/BlogPlanet(/|/index\.php)$ { }

location ~* \.(pl|cgi|perl|prl)$ { }
location ~* \.(md|mdwn|txt|mkdn)$ { }

location ^~ /images/IndexPage/ { }
location ^~ /blog/BlogPlanet/ { }

location = / { }

The first five examples are “literal string” matches, and match the beginning part of the request following the host portion. In a hypothetical request for http://ducklington.org/, assuming that there is a server_name for ducklington.org, the “location /” directive will catch this request. Nginx will always fulfill a request with most specific match. A request for http://ducklington.org/planet/blog/ and http://ducklington.org/planet/blog/about/ will be fulfilled by the “location /planet/blog/” even though “location /planet/” also fills this request.

When a location directive is followed by a tilde (e.g. ~) as in the fourth group of examples, nginx performs a regular expression match. These matches are always case sensitive, so in the first example requests ending in IndexPage.php would match, but indexpage.php would not. In the second the regular expression ^/BlogPlanet(/|index\.php)$ will match requests for /BlogPlanet/ and /BlogPlanet/index.php, but not /BlogPlanet, /blogplanet/, or /blogplanet/index.php. Nginx uses Perl Compatible Regular Expressions (PCRE).

Using a tilde-asterisk (e.g. ~*) as an argument to a location directive, as in the third group of examples, removes case sensitivity from the matches. These examples all specify how nginx should process requests that end in a particular file extension. In the first example, any file ending in: .pl, .PL, .cgi, .CGI, .perl, .Perl, .prl, and .PrL (among others) will match the request.

In the next group of examples, the caret-tilde argument (e.g. ^~) to location functions like the literal string matches of the first group. However, when used, they force nginx to stop searching for more specific matches. So in these examples, the location directives for “^~ /images/IndexPage/” and “^~ /blog/BlogPlanet/” would be used even though the request matches another location directive. See below for more information about the order and priority of location directive processing.

Finally, using the equal sign (e.g. =) as an argument to location forces an exact match with the path requested and then stops searching for more specific matches. For instance, the final example will only match http://ducklington.org/ but not http://ducklington.org/index.html. Using exact matches can speed up request times slightly especially when some requests are particularly popular.

Directives are processed in the following manner:

• Exact string matches are processed first. If a match is found, nginx stops searching and fulfills the request.
• Remaining literal string directives are processed next. If the “^~” argument is used, then ngnix stops here and fulfills the request. Otherwise, nginx continues to process location directives.
• All location directives specified by regular expressions (with the ~ and ~* arguments) are processed. If a regular expression matches the request, nginx stops here and fulfills the request.
• When there are no regular expressions, or no regular expressions match, the most specific literal string match is used.

It is incumbent upon the administrator to ensure that possible location directives will match for every resource nginx is to provide for a given domain within the server block. Additionally, while nginx’s configuration parser is capable of reading nested location blocks, using location directives in this manner is not a supported behavior.

location / {
    root   html;
    index  index.html index.htm;
}

location / {
    root   /srv/www/ducklington.org/public_html;
    index  index.html index.htm;
}

location ~ \.pl$ {
    gzip off;
    include /etc/nginx/fastcgi_params;
    fastcgi_pass  127.0.0.1:8999;
    fastcgi_index index.pl;
    fastcgi_param  SCRIPT_FILENAME  /srv/www/ducklington.org/public_html$fastcgi_script_name;
}

Reference:

nginx.conf.zip

http://nginx.org/en/docs/http/request_processing.html

http://library.linode.com/web-servers/nginx/configuration/basic#location_configuration

http://articles.slicehost.com/2009/3/5/ubuntu-intrepid-nginx-configuration

http://blog.rackcorp.com/?p=31

Reference:

http://www.cyberciti.biz/tips/howto-linux-kill-and-logout-users.html

Generic Status: Library Open failed, Library Name: /dctm65/shared/java/1.5.0_12/jre/lib/i386/libjava.so, Platform Status: libjvm.so: cannot open shared object file: No such file or directory

IDQL failed to run.  dmAPIInit() returned a failed status.

” was thrown when executing IDQL command.

I came across this issue after I installed one docbase on linux server.

It seemed that IDQL read the .so file in the wrong place.

I used the link command to resolve this problem:

ln -s /dctm65/shared/java/1.5.0_12/jre/lib/i386/server/libjvm.so /dctm65/shared/java/1.5.0_12/jre/lib/i386/libjvm.so

Set the file’s owner:
$ chown username somefile
After giving this command, the new owner of a file called somefile will be the user username. The file’s group owner will not change. Instead of a user name, you can also give the user’s numeric ID here if you want.

You can also set the file’s group at the same time. If the user name is followed by a colon and a group name, the file’s group will be changed as well.
$ chown username:usergroup somefile
After giving this command, somefile‘s new owner would be user username and the group usergroup.

You can set the owner of a directory exactly the same way you set the owner of a file:
$ chown username somedir
Note that after giving this command, only the owner of the directory will change. The owner of the files inside of the directory won’t change.

In order to set the ownership of a directory and all the files in that directory, you’ll need the -R option:
$ chown -R username somedir
Here, R stands for recursive because this command will recursively change the ownership of directories and their contents. After issuing this example command, the user username will be the owner of the directory somedir, as well as every file in that directory.

Tell what happens:

$ chown -v username somefile
changed ownership of 'somefile' to username

Here, v stands for verbose. If you use the -v option, chown will list what it did (or didn’t do) to the file.

The verbose mode is especially useful if you change the ownership of several files at once. For example, this could happen when you do it recursively:

$ chown -Rv username somedir
changed ownership of 'somedir/' to username
changed ownership of 'somedir/boringfile' to username
changed ownership of 'somedir/somefile' to username

As you can see, chown nicely reports to you what it did to each file.

To resolve this error, first boot in single user mode:

1. In GRUB menu select Red Hat Linux with the version of the kernel that you wish to boot and type e for edit. You will be presented with a list of items in the configuration file for the title you just selected.
2. Select the line that starts with kernel and type e to edit the line.
3. Go to the end of the line and type single as a separate word. Press enter to exit edit mode.
4. Back at the GRUB screen, type b to boot into single user mode.

Next, edit /etc/X11/xorg.conf and replace set the Driver to “vesa”.  Also, set the DefaultDepth to 16 from 24.  The implementation of the S3 hardware doesn’t support a colordepth of 24 and will cause the error 13.

grep -lir “some text” *

The -l switch outputs only the names of files in which the text occurs (instead of each line containing the text), the -i switch ignores the case, and the -r descends into subdirectories.

In order for a script to be very useful, you will need to be able to test the conditions of variables. Most programming and scripting languages have some sort of if/else expression and so does the bourne shell. Unlike most other languages, spaces are very important when using an if statement. Let’s do a simple script that will ask a user for a password before allowing him to continue. This is obviously not how you would implement such security in a real system, but it will make a good example of using if and else statements.

#!/bin/sh
# This is some secure program that uses security.

VALID_PASSWORD="secret" #this is our password.

echo "Please enter the password:"
read PASSWORD

if [ "$PASSWORD" == "$VALID_PASSWORD" ]; then
	echo "You have access!"
else
	echo "ACCESS DENIED!"
fi

Remember that the spacing is very important in the if statement. Notice that the termination of the if statement is fi. You will need to use the fi statement to terminate an if whether or not use use an else as well. You can also replace the “==” with “!=” to test if the variables are NOT equal. There are other tokens that you can put in place of the “==” for other types of tests. The following table shows the different expressions allowed.

Comparisons:

File Operations:

Let’s try using a couple of these in a script. This next script will ask for a user name, if there is not a file that exists with the name “username_DAT”, the script will prompt the user for their age, it will then make sure that they are old enough to use this program and then it will write their age to a file with the name “username_DAT”. If the file already exists, it will just display the age of the user.

#!/bin/sh

# Prompt for a user name...
echo "Please enter your name:"
read USERNAME

# Check for the file.
if [ -s ${USERNAME}_DAT ]; then
        # Read the age from the file.
        AGE=`cat ${USERNAME}_DAT`
        echo "You are $AGE years old!"
else
        # Ask the user for his/her age
        echo "How old are you?"
        read AGE

	if [ "$AGE" -le 2 ]; then
		echo "You are too young!"
	else
		if [ "$AGE" -ge 100 ]; then
			echo "You are too old!"
		else
        		# Write the age to a new file.
        		echo $AGE > ${USERNAME}_DAT
        	fi
        fi
fi

Run this program a couple of times. First run it and give it the user name of “john”. When it asks for an age, enter the age “1″. Notice that it will say that you are too you and then exit. Now run the program again with the name “john” and the age 200. This time the script will tell you that you are too old and exit. Now run the the script again with the name of “john”, enter the age 30. The script exits normally this time, the program created a file called “john_DAT” which contains the text “30″. Finally run the program one more time and give it the name “john”. This time it will not prompt you to enter an age, instead it will read the age from a file and say “Your are 30 years old!”.

We introduced something else new in this script. On line 10 of the file, we see the code:

	AGE=`cat ${USERNAME}_DAT`

This is how you execute a command and put the text output from the command into a variable. The unix command cat reads the file named ${USERNAME}_DAT and outputs it to the console. Instead of putting it to the console in our script, we wrap the command with the character `, this puts the text into our variable AGE.

You can test multiple expressions at once by using the || (or) operator or the && (and) operator. This can save you from writing extra code to nest if statements. The above code has a nested if statement where it checks if the age is greater than or equal to 100. This could be changed as well by using elif (else if). The structure of elif is the same as the structure of if, we will use it in an example below. In this example, we will check for certain age ranges. If you are less than 20 or greater than 50, you are out of the age range. If you are between 20 and 30 you are in your 20′s and so on.

#!/bin/sh

# Prompt for a user name...
echo "Please enter your age:"
read AGE

if [ "$AGE" -lt 20 ] || [ "$AGE" -ge 50 ]; then
	echo "Sorry, you are out of the age range."
elif [ "$AGE" -ge 20 ] && [ "$AGE" -lt 30 ]; then
	echo "You are in your 20s"
elif [ "$AGE" -ge 30 ] && [ "$AGE" -lt 40 ]; then
	echo "You are in your 30s"
elif [ "$AGE" -ge 40 ] && [ "$AGE" -lt 50 ]; then
	echo "You are in your 40s"
fi

Y
2Y
10Y
yG

To paste the text contained in the buffer above (uppercase P) or below the current cursor position (lowercase p), respectively:

P
p

It is also possible to yank text within a line. The following commands yank text from the current cursor position to the end of the word and the end of the line, respectively:

yw
y$

The same commands paste the text within a line. Lower case p pastes after the cursor position and upper case P pastes before.

Paste will also work with deleted text, either lines or parts of lines. Be careful not to execute any other commands prior to pasting as this will empty the buffer.