Tito's Blog

We all analyze Apache logs with the popular tail -f, which to a certain point is quite neat that you can see the whole request in real time. However, there is a point where you may be interested to know more details about your web logs.

Here it is where I find really interesting GoAccess. Whilst Awstats, Analog, Webalizer all generate HTML statistics, this application will let you analyze your Apache Web server logs straight from the terminal. It generates statistics really fast and it displays them in a nice ncurses interface.

More information about this project at: http://goaccess.prosoftcorp.com/

For webmasters, bloggers or server administrators who still see the PHP errors been printed and output to web pages, here’s how to log all PHP errors to a log file, with configurable name instead.

1. Login to the web server, and edit the php.ini file with any editor such as vi.

Note: php.ini configuration file can be found at /etc/php.ini or /usr/local/lib/php.ini.
2. Locate display_errors directive, and change its value to Off so that the line looks like following (if not found, add in the line) to disable error output to web pages:

display_errors = Off
3. Locate log_errors directive, and change its value to On so that the line looks like following (if not found, add in the line) to enable error logging to file:

log_errors = On
4. Locate error_log directive, and modify its value to a preferred file name to save the error log file so that the line looks like following (if not found, add in the line):

error_log = error_log

Note: Path can be included, for example, error_log = /var/log/error_log. If no path is specified, the error log file may be stored at the same directory where PHP scripts are located.
5. Save the modified php.ini.
6. Restart the web server. For example, Apache web server restarting command is:

# /etc/init.d/httpd restart

Tip: To log the PHP errors to syslog or Windows NT or Windows Server Event Log, just uncomment or add in the following line:

error_log = syslog

Once started logging to file, the PHP error messages can be viewed at the file name specified in error_log directive, with any text editor such as vi or using tail command to get latest errors. For continuous updated display of new entry to the error log file, use the following command which will update the last 10 lines of error messages and append new lines to the display as new errors are added to the file:

tail -f /path/to/error_log

Using FilesMatch and Files in htaccess

Files and FilesMatch to target multiple files and using Regular expressions using .htaccess files on Apache.

NOTE: FilesMatch should be used instead of Files when dealing with multiple files.

Adding UTF-8 content-type and and en-US language headers to files with extensions htm, html, css, js, and php

Using the Files Directive

<Files ~ "\.(htm|html|css|js|php)$">
AddDefaultCharset UTF-8
DefaultLanguage en-US
</Files>

Using the FilesMatch Directive (preferred)

<FilesMatch "\.(htm|html|css|js|php)$">
AddDefaultCharset UTF-8
DefaultLanguage en-US
</FilesMatch>

Other Examples using Files and FilesMatch in htaccess

Target a single file admin.php

<Files admin.php>
deny from all
</Files>

Target files that start with admin or staff and end in .php

<FilesMatch "^(admin|staff)\.php$">
AuthName "Dialog prompt"
AuthType Basic
AuthUserFile /home/username/.htpasswd
Require valid-user
</FilesMatch>

Target all files that end in .html or .htm

<FilesMatch "\.(html|htm)$">
AddDefaultCharset utf-8
DefaultLanguage en-us
</FilesMatch>

<FilesMatch> Directive
Description: Contains directives that apply to regular-expression matched filenames
Syntax: <FilesMatch regex> ... </FilesMatch>
Context: server config, virtual host, directory, .htaccess

The <FilesMatch> directive limits the scope of the enclosed directives by filename, just as the <Files> directive does. However, it accepts a regular expression. For example:

<FilesMatch "\.(gif|jpe?g|png)$">

<Files> Directive
Description: Contains directives that apply to matched filenames
Syntax: <Files filename> ... </Files>

The <Files> directive limits the scope of the enclosed directives by filename. It is comparable to the <Directory> and <Location> directives. It should be matched with a </Files> directive. The directives given within this section will be applied to any object with a basename (last component of filename) matching the specified filename. <Files> sections are processed in the order they appear in the configuration file, after the <Directory> sections and .htaccess files are read, but before <Location> sections. Note that <Files> can be nested inside <Directory> sections to restrict the portion of the filesystem they apply to.

The filename argument should include a filename, or a wild-card string, where ? matches any single character, and * matches any sequences of characters. Extended regular expressions can also be used, with the addition of the ~ character. For example:

<Files ~ "\.(gif|jpe?g|png)$">

would match most common Internet graphics formats. <FilesMatch> is preferred, however.

Note that unlike <Directory> and <Location> sections, <Files> sections can be used inside .htaccess files. This allows users to control access to their own files, at a file-by-file level.

The configuration sections are applied in a very particular order. Since this can have important effects on how configuration directives are interpreted, it is important to understand how this works.

The order of merging is:

1. <Directory> (except regular expressions) and .htaccess done simultaneously (with .htaccess, if allowed, overriding <Directory>)
2. <DirectoryMatch> (and <Directory ~>)
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. So for example, <Directory /var/web/dir> will be processed before <Directory /var/web/dir/subdir>. If multiple <Directory> sections apply to the same directory they are processed in the configuration file order. 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.

Later sections override earlier ones.

Technical 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.