How to configure Apache? (Part 2)

How Directory, Location and Files sections work

The sections <Directory>, <Location>  and <Files> can contain directives which only apply  

1.to specified directories,  

2.URLs or files respectively.  

    Also htaccess files can be used inside a directory to apply directives to that directory.

    This document explains how these different sections differ and how they relate to each other when Apache decides which directives apply for a particular directory or request URL.

Directives allowed in the sections

    Everything that is syntactically allowed in <Directory> is also allowed in <Location> (except a sub-<Files> section). Semantically, however some things, most notably AllowOverride and the two options FollowSymLinks and SymLinksIfOwnerMatch, make no sense in <Location>, <LocationMatch> or <DirectoryMatch>. The same for <Files> -- syntactically everything is fine, but semantically some things are different.



How the sections are merged?

The order of merging is:

   1. <Directory> (except regular expressions) and .htaccess done simultaneously (with .htaccess, if allowed, overriding <Directory>)

   2. <DirectoryMatch>, and <Directory> with regular expressions

   3. <Files> and <FilesMatch> done simultaneously

   4. <Location> and <LocationMatch> done simultaneously

    Apart from <Directory>, each group is processed in the order that they appear in the configuration files. <Directory> (group 1 above) is processed in the order shortest directory component to longest. If multiple <Directory> sections apply to the same directory they are processed in the configuration file order. The configuration files are read in the order httpd.conf, srm.conf and access.conf. Configurations included via the Include directive will be treated as if they were inside the including file at the location of the Include directive.

    Sections inside <VirtualHost> sections are applied after the corresponding sections outside the virtual host definition. This allows virtual hosts to override the main server configuration. (Note: this only works correctly from 1.2.2 and 1.3a2 onwards. Before those releases sections inside virtual hosts were applied before the main server).

Later sections override earlier ones.

Notes about using sections

The general guidelines are:

    * If you are attempting to match objects at the filesystem level then you must use <Directory> and/or <Files>.

    * If you are attempting to match objects at the URL level then you must use <Location>

ut a notable exception is:

    * proxy control is done via <Directory>. This is a legacy mistake because the proxy existed prior to <Location>. A future version of the config language should probably switch this to <Location>.

Note about .htaccess parsing:

    * Modifying .htaccess parsing during Location doesn't do anything because .htaccess parsing has already occurred.

<Location> and symbolic links:

    * It is not possible to use "Options FollowSymLinks" or "Options SymLinksIfOwnerMatch" inside a <Location>, <LocationMatch> or <DirectoryMatch> section (the options are simply ignored). Using the options in question is only possible inside a <Directory> section (or a .htaccess file).

<Files> and Options:

    * Apache won't check for it, but using an Options directive inside a <Files> section has no effect.

Another note:

    * There is actually a <Location>/<LocationMatch> sequence performed just before the name translation phase (where Aliases and DocumentRoots are used to map URLs to filenames). The results of this sequence are completely thrown away after the translation has completed.

How to configure Apache? (Part 1)

All about Apache Config File

    Apache is configured by placing directives in plain text configuration files. The main configuration file is usually called

httpd.conf

      
    The location of this file is set at compile-time, but may be overridden with the -f command line flag. Some sites also have srm.conf and access.conf files for historical reasons. In addition, other configuration files may be added using the Include directive. Any directive may be placed in any of these configuration files.
Changes to the main configuration files are only recognized by Apache when it is started or restarted.

    New with Apache 1.3.13 is a feature where if any configuration file is actually a directory, Apache will enter that directory and parse any files (and subdirectories) found there as configuration files. One possible use for this would be to add VirtualHosts by creating small configuration files for each host, and placing them in such a configuration directory. Thus, you can add or remove VirtualHosts without editing any files at all, simply adding or deleting them. This makes automating such processes much easier. The server also reads a file containing mime document types; the filename is set by the TypesConfig directive, and is mime.types by default.

Syntax of the Configuration Files

     Apache configuration files contain one directive per line. The back-slash "\" may be used as the last character on a line to indicate that the directive continues onto the next line. There must be no other characters or white space between the back-slash and the end of the line.

    Directives in the configuration files are case-insensitive, but arguments to directives are often case sensitive. Lines which begin with the hash character "#" are considered comments, and are ignored. Comments may not be included on a line after a configuration directive. Blank lines and white space occurring before a directive are ignored, so you may indent directives for clarity.

    You can check your configuration files for syntax errors without starting the server by using
apachectl configtest or the -t command line option.

root@host1:[/usr/apache2/2.2/bin]#./apachectl configtest

Syntax OK

root@host1:[/usr/apache2/2.2/bin]#

Modules

Related Modules : mod_so

Related Directives :
AddModule

ClearModuleList

<IfModule>

LoadModule



    Apache is a modular server. This implies that only the most basic functionality is included in the core server. Extended features are available through modules which can be loaded into Apache. By default, a base set of modules is included in the server at compile-time. If the server is compiled to use dynamically loaded modules, then modules can be compiled separately and added at any time using the LoadModule directive. Otherwise, Apache must be recompiled to add or remove modules. Configuration directives may be included conditional on a presence of a particular module by enclosing them in an <IfModule> block.

To see which modules are currently compiled into the server, you can use the -l command line option.

root@host1:[/usr/apache2/2.2/bin]#./apachectl -l

Compiled in modules:

  core.c

  prefork.c

  http_core.c

  mod_so.c

root@host1:[/usr/apache2/2.2/bin]#

<IfModule>  directive

Syntax: <IfModule [!]module-name> ... </IfModule>

Default: None

Context: all

Status: Core

Compatibility: IfModule is only available in 1.2 and later.

    The <IfModule test>...</IfModule> section is used to mark directives that are conditional. The directives within an IfModule section are only processed if the test is true. If test is false, everything between the start and end markers is ignored.

    The test in the <IfModule> section directive can be one of two forms:

    * module name

    * !module name

In the former case, the directives between the start and end markers are only processed if the module named module name is included in Apache -- either compiled in or dynamically loaded using LoadModule. The second format reverses the test, and only processes the directives if module name is not included. The module name argument is the file name of the module, at the time it was compiled. For example, mod_rewrite.c. <IfModule> sections are nest-able, which can be used to implement simple multiple-module tests.

Scope of Directives

Related Directives:

<Directory>

<DirectoryMatch>

<Files>

<FilesMatch>

<Location>

<LocationMatch>

<VirtualHost>

    Directives placed in the main configuration files apply to the entire server. If you wish to change the configuration for only a part of the server, you can scope your directives by placing them in <Directory>, <DirectoryMatch>, <Files>, <FilesMatch>, <Location>, and <LocationMatch> sections.  These sections limit the application of the directives which they enclose to particular filesystem locations or URLs. They can also be nested, allowing for very fine grained configuration. Apache has the capability to serve many different websites simultaneously. This is called Virtual Hosting. Directives can also be scoped by placing them inside <VirtualHost> sections, so that they will only apply to requests for a particular website.

    Although most directives can be placed in any of these sections, some directives do not make sense in some contexts. For example, directives controlling process creation can only be placed in the main server context. To find which directives can be placed in which sections, check the Context of the directive. For further information, we provide details on How Directory, Location and Files sections work.
.htaccess Files

Related Directives :

AccessFileName

AllowOverride

    Apache allows for decentralized management of configuration via special files placed inside the web tree. The special files are usually called .htaccess, but any name can be specified in the AccessFileName directive. Directives placed in .htaccess files apply to the directory where you place the file, and all sub-directories. The .htaccess files follow the same syntax as the main configuration files. Since .htaccess files are read on every request, changes made in these files take immediate effect.

    To find which directives can be placed in .htaccess files, check the Context of the directive. The server administrator further controls what directives may be placed in .htaccess files by configuring the AllowOverride directive in the main configuration files.

https://sugarcrm-ooo-integration.dev.java.net/

This open source project is aimed at creating a OpenOffice.org Extension for Sugar CRM(open source CRM product). I am committed to contribute for this cause. Any one who is interested can participate and contribute.

Project Home URL
https://sugarcrm-ooo-integration.dev.java.net

Developer Guide(How to setup build environment?)
https://sugarcrm-ooo-integration.dev.java.net/files/documents/8056/134956/file_134956.dat/Developers_Guide%20_OpenOffice.org_Extension_for_SugarCRM.pdf

Java.Util.Logging Example

This example is a simple illustration for using Java.Util.Logging. Java.Util.logging comes with J2SE.

create the following directory structure

->loggingdemo
&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp|->Main.java
&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp|->logging.properties

logging.properties

# Java Logging Properties
# Author : Deepak Dhanukodi
handlers=java.util.logging.FileHandler, java.util.logging.ConsoleHandler
# Default global logging level.
.level=SEVERE
# Loggers.
loggingdemo.level=ALL
# --- ConsoleHandler ---
# Override of global logging level
java.util.logging.ConsoleHandler.level=ALL
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
# --- FileHandler ---
# Override of global logging level
java.util.logging.FileHandler.level=ALL
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter
# Unlimiting size for output file
java.util.logging.FileHandler.limit=0
# Number of output files to cycle through, by appending an
# integer to the base file name:
java.util.logging.FileHandler.count=1
# Append to already existing file
java.util.logging.FileHandler.append=true
java.util.logging.FileHandler.pattern=system.log

Main.java

package loggingdemo;
import java.io.IOException;
import java.io.InputStream;
import java.util.Properties;
import java.util.logging.Filter;
import java.util.logging.Level;
import java.util.logging.LogManager;
import java.util.logging.LogRecord;
import java.util.logging.Logger;

/**
* Java.utils.logging Demo
* @author Deepak Dhanukodi
*/
public class Main {
static String LOGGING_PROPERTIES = "loggingdemo/logging.properties";
private LogManager logManager;
private Logger logger;
/**
* @param args the command line arguments
*/
public void initialize() throws IOException
{
logManager = LogManager.getLogManager();
Properties prob = new Properties();
InputStream inputStream = this.getClass().getClassLoader().getResourceAsStream(LOGGING_PROPERTIES);
logManager.readConfiguration(inputStream);
logger = Logger.getLogger(this.getClass().getName());
}
public void log()
{
logger.log(Level.WARNING, "I have hit a warning here.");
logger.warning("Same warning again");
//User defined filter
Filter filter= new Filter() {

public boolean isLoggable(LogRecord record) {
// Allow only FINE and filter the rest
if(Level.FINE == record.getLevel())
return true;
return false;
}
};
Filter oldFilter = logger.getFilter();
logger.setFilter(filter);
logger.severe("You can't reach me.");
logger.finer("You can't reach me, either.");
logger.fine("Horray,I am through.");
logger.setFilter(oldFilter);
logger.severe("You can reach me.");
logger.finer("You can reach me, either.");
logger.fine("Horray,I am through,again.");
}
public static void main(String[] args) throws IOException {
Main main = new Main();
// Initialize logger
main.initialize();
main.log();
}
}

Run

D:\>javac /loggingdemo/Main.java -d .

D:\>java -cp . loggingdemo.Main
15 Jun, 2009 5:10:53 PM loggingdemo.Main log
WARNING: I have hit a warning here.
15 Jun, 2009 5:10:53 PM loggingdemo.Main log
WARNING: Same warning again
15 Jun, 2009 5:10:53 PM loggingdemo.Main log
FINE: Horray,I am through.
15 Jun, 2009 5:10:53 PM loggingdemo.Main log
SEVERE: You can reach me.
15 Jun, 2009 5:10:53 PM loggingdemo.Main log
FINER: You can reach me, either.
15 Jun, 2009 5:10:53 PM loggingdemo.Main log
FINE: Horray,I am through,again.

D:\>

system.log

This log file is created in the same dir where you had executed java process.

15 Jun, 2009 5:10:53 PM loggingdemo.Main log
WARNING: I have hit a warning here.
15 Jun, 2009 5:10:53 PM loggingdemo.Main log
WARNING: Same warning again
15 Jun, 2009 5:10:53 PM loggingdemo.Main log
FINE: Horray,I am through.
15 Jun, 2009 5:10:53 PM loggingdemo.Main log
SEVERE: You can reach me.
15 Jun, 2009 5:10:53 PM loggingdemo.Main log
FINER: You can reach me, either.
15 Jun, 2009 5:10:53 PM loggingdemo.Main log
FINE: Horray,I am through,again.

Installing PHP as a Shared Module in APACHE HTTPD Server @ Open Solaris/ Solaris 10

Environment Details

cc = /usr/bin/cc
make = /usr/bin/make
Apache root = /export/home/Apache2.2.9/httpd-2.2.9_build/php
Src php = /export/home/php-5.2.6/php-5.2.6
Src Apache httpd= /export/home/Apache2.2.9/httpd-2.2.9_src

Setting the PATH

bash-3.2# export PATH=/usr/bin/cc:/usr/bin/make:$PATH

Building Apache httpd

bash-3.2#/export/home/Apache2.2.9/httpd-2.2.9_src/configure --prefix=/export/home/Apache2.2.9/httpd-2.2.9_build
bash-3.2#make
bash-3.2#make all

Start Apache HTTPD Server

bash-3.2#/export/home/Apache2.2.9/httpd-2.2.9_build/bin/apachectl start

Go to the following URL at Browser

http://localhost

The response at the browse should be "It works!".

Stop Apache HTTPD Server

/export/home/Apache2.2.9/httpd-2.2.9_build/bin/apachectl stop

Building PHP

./configure --prefix=/export/home/Apache2.2.9/httpd-2.2.9_build/php --with-apxs2=/export/home/Apache2.2.9/httpd-2.2.9_build/bin/apxs --with-config-file-path=/export/home/Apache2.2.9/httpd-2.2.9_build/php

bash-3.2# make
bash-3.2# make all

Configure Apache HTTPD with PHP

Add the following line to file 'Apacheroot/conf/httpd.conf'

LoadModule php5_module modules/libphp5.so

Note : # is a comment here @ Apache conf file...

Add the following mapping for PHP to invoke PHP parser for PHP files in the same conf file.
AddType application/x-httpd-php .php

Create PHP file

create a file named info.php @ /Apacheroot/htdocs
phpinfo();
?>

cp /export/home/php-5.2.6/php-5.2.6/php.ini-dist /export/home/Apache2.2.9/httpd-2.2.9_build/php/php.ini

Restart Apache HTTPD Server

$ /export/home/Apache2.2.9/httpd-2.2.9_build/bin/apachectl restart

Access the pho file as
http://localhost/info.php in a browser

The response shows the php configuration.

Export/Import data in MYSQL

EXPORT
mysqldump -u<user name>
-p<password> <dbname> > <dbname.sql with file path>
eg. mysqldump -uroot -padmin mydb > /mydb.sql

IMPORT
mysql -u<user name> -p<password> < <dbname.sql>
eg.
mysql -uroot -padmin < /mydb.sql

RUN SQL COMMAND FROM CONSOLE
mysql-u<user name> -p<password> -e "SQL Command"
eg.
mysql-uroot -padmin -e "INSERT
INTO NAME VALUES(10,20,'TEST');"

Understanding Open file limit in Solaris 10/ Open solaris

Shell level changes

To specify the file limit use

ulimit -n &lt no of files&gt

To see the changes made

ulimit -a

These limits are set and controlled by the user's shell to limit the system resources consumed by the current shell process and all it's descendants.

System level changes

To make the changes persistent across the whole machine, you'd need to tune the following settings in /etc/system

/etc/system:

rlim_fd_max
Description: "Hard" limit on file descriptors that a single process might have to open.
Minimum: 1
Maximum: MAXINT
Default: 65,536

rlim_fd_cur
Description: "Soft" limit on file descriptors that a single process can
have open.
Minimum: 1
Maximum: MAXINT
Default: 256

save and exit
reboot

Note that these settings are per process.

The plimit command can be used to find out the limitations imposed on a particular process. e.g.
plimit 1556
1556: /usr/apache2/2.2/bin/httpd -f /etc/vpanels/httpd.conf -DSSL -k start
resource current maximum
time(seconds) unlimited unlimited
file(blocks) unlimited unlimited
data(kbytes) unlimited unlimited
stack(kbytes) 10240 unlimited
coredump(blocks) unlimited unlimited
nofiles(descriptors) 65536 65536
vmemory(kbytes) unlimited unlimited