Posts Tagged ‘apache’

How to set repository to install binary packages on amd64 FreeBSD 9.1

Friday, January 11th, 2013

Though, it is always good idea to build from source for better performance of Apache + MySQL + PHP, its not worthy the time on installing minor things like; trafshow, tcpdump or deco (MC – midnight commander like native freebsd BSD program).

If you're on a 64 bit version of FreeBSD ( amd64) 9.1 and you try to install a binary package with;

freebsd# pkg_add -vr vim

Ending up with an error;

Error: Unable to get ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9.1-release/Latest/vim.tbz: File unavailable (e.g., file not found, no access)
pkg_add: unable to fetch 'ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9.1-release/Latest/vim.tbz' by URL
pkg_add: 1 package addition(s) failed

The error is caused by lack of special packages-9.1-release directory existing on FreeBSD.org servers. I've realized this after doing a quick manual check opening ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64. The existing URL containing working fbsd 9.1 binaries is:

ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/
h

You will have to set a repository for FreeBSD 9.1 amd64 packages manually with cmd:
freebsd# echo $SHELL
/bin/csh
freebsd# setenv PACKAGESITE ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/

If you're on bash shell use export instead:

freebsd# export PACKAGESITE="ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/"

To make ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/ as a permanent binary repository:

echo 'setenv PACKAGESITE ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/' >> /root/.cshrc

or

echo 'export PACKAGESITE="ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/"' >> /root/.bashrc

Now, pkg_add as much as you like 😉

Fixing 127.0.0.1 – – “OPTIONS * HTTP/1.0” 200 136 “-” “Apache (internal dummy connection)” / ::1 – – [-.. :- .. +0200] “OPTIONS * HTTP/1.0” 200 Apache access.log junk records

Saturday, December 1st, 2012

If you're on Debian Linux and you played with mpm_prefork_module MinSpareServers and MaxSpareServers directives, it is very likely your access.log apache log ends up with a plenty of junk messages like:

127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"

It was quite unexplainable to me what is causing all this errors. I've seen plenty of posts on the Internet discussing on that but most are somehow outdated and suggested solutions to the weird logged  internal dummy connection messages did not work well for me.

I would not care so much about the message, only if it was not creating a lot of bulk records in my logs which when later are compressed just take up useless disk space and besides that it makes following the Apache log with:

# tail -f  /var/log/apache2/access.log

hardly readable.

  • One of the many solutions and posts suggested a solution with mod_rewrite rules. It claims adding the rules to .htaccess or to apache config files (vhost confs whether multiple vhosts domains):

RewriteCond %{HTTP_USER_AGENT} ^.*internal\ dummy\ connection.*$ [NC]
RewriteRule .* – [F,L]

The full article you read the whole here.
I've tested this rules, and thought I might be doing something wrong this proved unworking for me. Besides that even if it worked I would not imply such fix, as it will be creating a useless extra load on each incoming Apache connection.

 

As a second solution as I found on stackoverflow's website is to add in apache / vhost configs:

<Limit OPTIONS Order allow,deny Deny from all </Limit> I tested this as well but it does not work either. I've seen a bunch of other posts and none seemed to be working, until I finally came across Linux Guru's blog which was discussing a similar issue suggesting a fix. The post is discussing on Apache access.log being filled with messages like: ::1 - - [13/Mar/2008:09:05:13 +0200] "OPTIONS * HTTP/1.0" 200 Which are almost the same except, the 127.0.0.1 is the IPv6's equivalent ::1. The blog provided solution is to use: SetEnvIf Remote_Addr "::1" dontlog CustomLog /var/log/apache2/access.log combined env=!dontlog What this makes is to completely clear up all occurances of ::1 in /var/log/apache2/access.log. Once it uses Apache Internal directive SetEnvIf Remote_Addr "::1" dontlog to "bind" ::1 to dontlog variable and then after the usual Log location definition – e.g. – CustomLog /var/log/apache2/access.log combined it instructs the environment not to log dontlog variable matches, i.e. env=!dontlog

Following he same logic to get rid of the so annoying:

127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)"

I used as a solution adding:

SetEnvIf Remote_Addr "127.0.0.1" dontlog
CustomLog /var/log/apache2/access.log combined env=!dontlog

to /etc/apache2/sites-available/000-default (the default virtualhost), with the CustomLog directive, for more domains and more CustomLog VirtualHost definitions it might be necessary to add it to all Vhosts too.

This solution to Request of the Server to itself is also found on Apache's wiki  check what httpd wiki here.

As I've read further it appeared the same Internal Dummy Connection error is experienced on CentOS Linux too and the SetEnvIf method works there too well you can read post here.

Another possible solution though this didn't work for me is to just play with the settings of MinSpareServers and MaxSpareServers in apache2.conf (or httpd.conf on RedHats and BSD).

There is plenty of things written on the problem and it is really confusing to read about it, as most of the people writing about it were looking for the quick fix and thus just dropped few lines on what worked for them without much details on exact OS en Apache version.

The reason why:
127.0.0.1 – – [25/Nov/2012:06:27:21 +0200] "OPTIONS * HTTP/1.0" 200 136 "-" "Apache (internal dummy connection)" appear in log is due to the fact in Apache 2.x series Apache developers change the the Parent Apache controlling process to send periodic requests to its waiting idling childs, just to make the childs are still alive, this is done somehow in the very inefficient method IMHO by sending those dummy connection requests.

Maybe better and more thoroughful explanation on What is the Dummy Internal Connection and what causes it is on another Bulgarian Fellow Valery Dachev you can read his explan.

On a couple of occasions, I've experienced a very high server loads like load avarage of 180etc. , I have some suspicion that this super high loads are caused somehow by the Internal Dummy Connection thing too, though I'm not sure if my assumptions are correct. It could be I have messed up something with MaxSpareServers / MinSpareServers too, or just the hardware on the host is unable to process a sudden traffic peaks. I've red online other people who complain of similar overloads and complaininng about the Internal Dummy Connection too. But as long as my little research go, I couldn't find noone knowing anything on that. If some of the readers of this post has an idea on that please drop a comment !

Well that's it hope my little blog post sheds some more light on the topic, and lets hope in future Apache versions developers will come with less resource hungry method to do internal dummy checks for exmpl. by sending a SIGUSR signal.

Disable server side includes (SSI) in Apache on Debian GNU / Linux to Improve minor Apache performance

Thursday, November 29th, 2012

Disalable Apache Server-side includes on debian Linux disable SSI for better performance and security
By default Apache deb installable binary on Debian GNU / Linux is shipped with Apache version  (Apache 2.2.16-6+squeeze6) is configured to be able to process Server Side Include (SSIs) scripts.

For those who don't know what is a Server-Side Includes it a way giving  possibility for inclusion through .shtml or even .html files (if configured) to dynamically include and process external scripts. Most admins should have already seen SSI scripts, but it is possible they don't even know it is SSI. An example code from an SSI script looks something like:

<!--#include file="footer.html" -->

<!--#exec cgi="/cgi-bin/foo.cgi" --> <!--#exec cmd="ls -l" -->

As of time of writting (on Debian stable codename Squeeze – and I guess the unstable one too).

In Debian.BG one of my previous employment companies SSI was used on a few website Projects;  However nowadays SSI's are not so popular as they used to be and many websites using mostly PHP for a programming backend don't use / need the Server Side Includes at all. Thus it is recommended on such servers where SSIs aren't used and not planned by company to be used in short future to disable SSI  (.shtml) support completely. As the popular saying says "less is more" – having enabled SSI hanging their is simply a waste of Apache resources and just another hanging unused feature from security stand point is not good.

 SSI .shtml support in Debian is enabled via /etc/apache2/mods-available/mime.conf, not  through apache2.conf because of the modular Apache Debian build structure.

Thus to disable server-side parsing on Debian (and I guess other debian derivatives);

  • Edit /etc/apache2/mods-available/mime.conf

vim /etc/apache2/mods-available/mime.conf

  • Look for file section:

#
# Filters allow you to process content before it is sent to the client.
#
# To parse .shtml files for server-side includes (SSI):
# (You will also need to add "Includes" to the "Options" directive.)
#
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
 

  • Comment out .shtml mime directives to:

#
# Filters allow you to process content before it is sent to the client.
#
# To parse .shtml files for server-side includes (SSI):
# (You will also need to add "Includes" to the "Options" directive.)
#
##AddType text/html .shtml
##AddOutputFilter INCLUDES .shtml

  •   Apply changes, with the usual apache restart:

debian:~# apache2ctl -k restart

Don't expect that disabling SSI will give a great boost to the webserver but it will definitely, do a minor performance improvement. This should be noticable on  Webserver hosts (using apache2-mpm-prefork) with thousands of Apache forks, on a little home Webserver perf change is unnoticeable.

 

w00tw00t.at.ISC.SANS.DFind in apache error.log – Filtering script kiddie port scanner on GNU / Linux

Friday, November 23rd, 2012

 

w00tw00t.at.ISC.SANS.Dinfd - Filtering script kiddies port scanners from Apache logs and servers with iptables firewall

If you get thousand of messages:

[Wed Nov 21 16:28:49 2012] [error] [client 89.136.100.192] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

 

in /var/log/apache2/error.log It is due to a script kiddie port scanner, usually such requests originate from Turkia, Romania ,Russia.. Usually, for servers getting in Apache error.log  GET /w00tw00t.at.ISC.SANS.DFind:) once in a while, it is not an issue however if you get too many of this messages it is sometimes useful to filter them with a simple iptables rule

debian:~# /sbin/iptables -A INPUT -p tcp -m tcp --dport 80 -m string --string "GET /w00tw00t.at.ISC.SANS." --algo bm --to 70 -j DROP

What above command does is it greps the 1st 70 bytes and checks, whether it contains string '/w00tw00t.at.ISC.SANS.DFind:)' , whether string is matched it jumps to DROP rule filtering the IP. Of course on busy servers checking each incoming IP client TCP/IP request for a certain string might not be very efficient and even can be a possible bottleneck. So I don't know whether filtering /w00tw00t.at.ISC.SANS.DFind:) is good or bad practice. Anyways generally it is wise to filter IPs doing the request anyways since, they could try a various script kiddie cracking tools, port scanners and even some of them might be hosts attempting DoS or DDoS.

Also it is useful to store for later the rule with:

debian:~# /sbin/iptables-save > /root/iptables_rules.txt

Then you can load up /root/iptables_rules.txt with:

debian:~# /sbin/iptables-restore < /root/iptables_rules.txt

Some common way to keep the iptables rule loaded on system boot is by adding /iptables-restore  to /etc/rc.local
 

Some alternative methods to filter IPs issuing GET  /w00tw00t.at.ISC.SANS.DFind:) to Apache is through  fail2ban, denyhosts or blockhosts or Apache mod security filters.
You can read further Information on what DFind hacktool does here

To keep an eye on all DROPped and REJECT-ed traffic (in bytes) it is useful to use:

debian:~# /sbin/iptables -L INPUT -nvx|grep -i -E 'drop|reject'
       0        0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:3306 reject-with icmp-port-unreachable
       0        0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 17
       0        0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 13
       0        0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x03/0x03
       0        0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x06
    1526    77004 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp reject-with icmp-host-prohibited
 
For filtering

How to install Awstats Apache weblog statistics on Debian Squeeze GNU Linux

Monday, October 8th, 2012

I like using Webalizer to keep an eye in web of my access.log, however since the information it shows is a bit chaotic and much less than one in Awstats statistics, I decided to install awstats. I haven’t installed awstats for a long time so I have no exact memory how I previously did it and hence run quick search too see if there is information on specifics concerning Debian Squeeze. I did not find any specific article and therefore decided to write this short one to document how awstats install is done on Debian Squeeze Linux.

1. Installing awstats deb package

There is already a deb package so no need to hunt for specific perl CPAN modules and manually fulfill dependencies.

Installation is as straight as any other deb package:


debian:~# apt-get install --yes awstats
...

2. Change basic awstats.conf configurations to make it properly working

First thing to do immediately after install is to set the primary SiteDomain= for which Awstats will process site statistics.

For that in the beginning (first line) of /etc/awstats/awstats.conf add directive:


SiteDomain="www.your-domain-name.com"

Substitution www.your-domain-name.com with whatever your primary domain will be.

Next in /etc/awstats/awstats.conf change value for DNSLookup. By default DNSLookup is 1, which means each of the IP request in /var/log/apache2/access.log is attempted be resolved via separate DNS request; Most IP Addresses that have quieried Apache webserver however miss proper PTR DNS record and hence attempts to be resolved fail after 10 to 20 seconds.
The overall result of this is processing execution of /var/log/apache2/access.log takes hours in case access.log is >100MB or so. This slow processing slowness is due to failed DNS requests. Besides that it does useless hundreds of queries to DNS servers which take up bandwidth for nothing …

To prevent this I disabled immediately DNSLookup right after install by substituting


DNSLookup=1

with:


DNSLookup=0

Other thing is by default Awstats is set to use LogFormat=4. As you can read in awstats.conf (Comments section) 4 stands for:


# 4 - Apache or Squid native common log format (NCSA common/CLF log format)

However in Debian Linux Apache2 default config is done in a way that Apache keeps logged requests formatted in combined (not in common log

Here is LogFormat directive extracted from /etc/apache2/apache2.conf:


LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

With that said in awstats.conf to match (combined) Apache set logging change LogFormat to 1:


LogFormat=1

3. Generate manual AWStats access.log statistics for first time

You will have to run as superuser following cmd:


debian:~# /usr/lib/cgi-bin/awstats.pl -config=/etc/awstats/awstats.conf
Create/Update database for config "/etc/awstats/awstats.conf" by AWStats version 6.95 (build 1.943)
From data in log file "/var/log/apache2/access.log"...
Phase 1 : First bypass old records, searching new record...
Searching new records from beginning of log file...
Phase 2 : Now process new records (Flush history on disk after 20000 hosts)...
Flush history file on disk (unique url reach flush limit of 5000)
Flush history file on disk (unique url reach flush limit of 5000)
Flush history file on disk (unique url reach flush limit of 5000)
Flush history file on disk (unique url reach flush limit of 5000)
Flush history file on disk (unique url reach flush limit of 5000)
Flush history file on disk (unique url reach flush limit of 5000)
Flush history file on disk (unique url reach flush limit of 5000)
Flush history file on disk (unique url reach flush limit of 5000)
Flush history file on disk (unique url reach flush limit of 5000)
Flush history file on disk (unique url reach flush limit of 5000)
Jumped lines in file: 0
Parsed lines in file: 602983
Found 8 dropped records,
Found 5 corrupted records,
Found 0 old records,
Found 602970 new qualified records.

4. Access awstats statistics in Web Browser

Once the command execution completes, open in Epiphany, Firefox or whatever browser you like URL:


http://www.your-domain-name.com/cgi-bin//awstats.pl?config

If all is okay you should see some numbers on Unique Visitors like in below browser screenshot:

Screenshot Awstats example Statistics for www.pc-freak.net in Epiphany

5. Set ScriptAlias for easier awstats access path and set directory permissions

In /etc/apache2/apache2.conf or in VirtualHost file, lets say /etc/apache2/sites-enabled/your-domain-name.com, place following configs:


Alias /awstats-icon/ /usr/share/awstats/icon/
ScriptAlias /awstats/ /usr/lib/cgi-bin/

Options None
AllowOverride None
Order allow,deny
Allow from all

For new configs to take effect as usual Apache should be restarted:


debian:~# /etc/init.d/apache2 restart
....

From now on Awstats can be accessed via the much easier to remember access URL:


http://your-domain-name.com/awstats/awstats.pl

6. Protecting Awstats statistics with Apache HTACCESS password

It is a must to protect awstats statistics with password via .htaccess and htpasswd

a.) Use htpasswd to generate user/pass:


linux:~# htpasswd -c /etc/apache2/awstats.passwd admin
New password:
Re-type new password:
Adding password for user admin

b.) Create /usr/lib/cgi-bin/.htaccess with following content:


linux:~# vim /usr/lib/cgi-bin/.htaccess

AuthType Basic
AuthUserFile /etc/apache2/awstats.passwd
AuthGroupFile /dev/null
AuthName "Please Enter Password to access AWstat"
AuthType Basic
Require valid-user

7. Set awstats to generate statistics via daily cron job:

awstats binary deb automatically installs a cron job in /etc/cron.d/awstats:


linux:~# cat /etc/cron.d/awstats
*/10 * * * * www-data [ -x /usr/share/awstats/tools/update.sh ] && /usr/share/awstats/tools/update.sh
# Generate static reports:
10 03 * * * www-data [ -x /usr/share/awstats/tools/buildstatic.sh ] && /usr/share/awstats/tools/buildstatic.sh

I prefer not to use it but use a custom root cron job. To stop /etc/cron.d/awstats from executing I move it to /root:


mv /etc/cron.d/awstats /root

Then I set a new root user cron job to process Apache access.log. The reason I use root user crontab, instead of Apache’s www-data is with www-data user, /var/log/apache2/access.log is unreadable ,…


linux:~# crontab -u root -e
8,18,27,38,48,59 * * * * [ -x /usr/lib/cgi-bin/awstats.pl -a -f /etc/awstats/awstats.conf -a -r /var/log/apache2/access.log ] && /usr/lib/cgi-bin/awstats.pl -config=awstats -update >/dev/null

This cron makes awstats web statistics be refreshed every our in minutes 8,18,27,38,48,59.

That’s it. Enjoy 🙂

Allow Directory Listing in Apache Webserver / Get around Directory index forbidden by Options directive

Thursday, October 4th, 2012

I have configured Apache VirtualHost, inside the VirtualHost hosted domain, it is supposed to be a directory, where Directory Listing has to be allowed. My VirtualHost configuration looks like so:


NameVirtualHost *

ServerAdmin my-email@domain-name.com
ServerName www.pc-freak.net
ServerAlias www.domain-name.com domain-name.com
DocumentRoot /var/www
DirectoryIndex index.html index.htm index.php index.html.var

Options FollowSymLinks
AllowOverride All
Order allow,deny
allow from all


Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all


Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all

ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/access.log combined

I have a directory (/var/www/directory), there I store various files and I prefer this directory to be enabled to support Directory listing. I have the whole situation on Debian Linux. By default in Debian Apache is configured to disable directory listing for subdirectories to both default host and Virtualhosts

In order to enable /var/www/directory, accessed inside browser via web address http://wwww.domain-name.com/directory/ I had to add inside my Virtualhost /etc/apache2/sites-available/domain-name.com following Apache directive:



AddDefaultCharset UTF-8
Options FollowSymLinks Indexes
AllowOverride All

As you can see I included also AddDefaultCharset UTF-8, because inside /directory I have files in cyrillic and, if I don’t explicitly set the encoding to UTF-8, the htmls are improperly shown in browsers.

The exact directive that enables directory listing in Apache is:


Options Indexes

Setting Indexes to -Indexes disables directory listing, e.g.



Options -Indexes

BTW if you need to make certain directory accessible for default set Apache Options (permissions) should be set in /etc/apache2/apache2.conf



Options Indexes
...

This will set Apache directory permissions for all Virtualhost, useful if all virtualhosts share common ServerRoot and the directory has to be accessible via all vhosts.
Well that’s all Cheers 😉

Disable Apache access.log and error.log logging on Debian Linux and FreeBSD

Tuesday, September 25th, 2012

Disable Apache logging Debian and FreeBSD Linux logo

Many times disabling logging on a busy websites is quite beneficial, especially if more than few Gigabytes are written in Apache visitors log (access.log) every day. Too much visitors to Apache webserver could pose significantly increase disk writes and be negative for overall server performance.

Disabling the log is handy also for websites which already integrate a different type of visitors logging lets say – via MySQL, PostgreSQL (SQL) …

From security perspective disabling logging is a very stupid idea thought, however on systems which are experiencing high load and you need to sacrifice logging to reduce a bit the load (especially if you cannot afford to get a new server hardware), disabling it is an option.

1. Disabling access.log and error on Debian Linux

a) Disabling access.log logging
As most Debian users already know on Debian GNU Linux Apache logs all incoming (port 80) Apache requests to /var/log/apache2/access.log and /var/log/apache2/error.log

Disabling logging is very simple, just comment out line in /etc/apache2/sites-enabled/000-default:


CustomLog ${APACHE_LOG_DIR}/access.log combined

to


#CustomLog ${APACHE_LOG_DIR}/access.log combined

Then restart the webserver to re-read new config value:


# /etc/init.d/apache2 restart
....

Of course this is one of the ways to disable access.log logging. Other ways are to make logging gets logged in good old /dev/null. To use /dev/null forwardingp put Customlog /dev/null in /etc/apache2/sites-enabled/000-default


CustomLog /dev/null

In Debian Lenny and older Debian releases Customlog Apache directive is found in /etc/apache2/apache2.conf.

b) Disabling error.log logging

Same procedure applies for disabling error.log, comment out default ErrorLog directive, restart Apache and you’re done:


ErrorLog ${APACHE_LOG_DIR}/error.log

should become:


ErrorLog /dev/null

Usually just comming ErrorLog ${APACHE_LOG_DIR}/error.log is supposed to work, unfortunately for reason on Debian Squeeze this worked not commenting it and restarting Apache failed to restart apache with error:


# /etc/init.d/apache2 restart
Restarting web server: apache2 ... waiting (2)No such file or directory: apache2: could not open error log file /etc/apache2/logs/error_log.
Unable to open logs
Action 'start' failed.
The Apache error log may have more information.
failed!

Thus to disalbe error.log you need to add ErrorLog /dev/null in /etc/apache2/apache2.conf and once again restart Apache.


ErrorLog /dev/null


# /etc/init.d/apache2 restart

Bear in mind that if you use some custom virtualhosts which has the ErrorLog directive in (let’s say /etc/apache2/sites-enabled/{website-domain.com,website-domain1.com} etc. you need to change there too.
2. Disabling access.log and error.log logging on FreeBSD
On FreeBSD to disable access.log add CustomLog /dev/null to /usr/local/etc/httpd.conf and just like on Linux restart Apache:


freebsd# /usr/local/etc/rc.d/apache2 restart
....

Disaling error.log on BSD is done by changing:


ErrorLog /var/log/httpd-error.log

to


ErrorLog /dev/null

BTW disaling error.log is quite a stupid idea but in some situation, where you don’t update software versions and don’t change often webserver script interpreter and (processed) server side executables / PHP scripts it could be ok.
Still it is much better to change the amount of Apache logged information and keep error.log logging by changing:


LogLevel crit

Using LogLevel crit, will prevent Apache from logging numerous not so useless warnings in error.log, so if you have a very busy server with high loads you better use it.

Don’t expect that disabling logging will drastically improve performance usually even on Apache servers which serve more than 20 000 of requests daily disabling access.log / error.log could would probably reduce load with from 00.1 to maximum 2-3 percentage.

How to copy / clone installed packages from one Debian server to another

Friday, April 13th, 2012

1. Dump all installed server packages from Debian Linux server1

First it is necessery to dump a list of all installed packages on the server from which the intalled deb packages 'selection' will be replicated.

debian-server1:~# dpkg --get-selections \* > packages.txt

The format of the produced packages.txt file will have only two columns, in column1 there will be the package (name) installed and in column 2, the status of the package e.g.: install or deinstall

Note that you can only use the –get-selections as root superuser, trying to run it with non-privileged user I got:

hipo@server1:~$ dpkg --set-selections > packages.txt
dpkg: operation requires read/write access to dpkg status area

2. Copy packages.txt file containing the installed deb packages from server1 to server2

There is many way to copy the packages.txt package description file, one can use ftp, sftp, scp, rsync … lftp or even copy it via wget if placed in some Apache directory on server1.

A quick and convenient way to copy the file from Debian server1 to server2 is with scp as it can also be used easily for an automated script to do the packages.txt file copying (if for instance you have to implement package cloning on multiple Debian Linux servers).

root@debian-server1:~# scp ./packages.txt hipo@server-hostname2:~/packages.txt
The authenticity of host '83.170.97.153 (83.170.97.153)' can't be established. RSA key fingerprint is 38:da:2a:79:ad:38:5b:64:9e:8b:b4:81:09:cd:94:d4. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '83.170.97.153' (RSA) to the list of known hosts. hipo@83.170.97.153's password:
packages.txt

As this is the first time I make connection to server2 from server1, I'm prompted to accept the host RSA unique fingerprint.

3. Install the copied selection from server1 on server2 with apt-get or dselect

debian-server2:/home/hipo# apt-get update
...
debian-server2:/home/hipo# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
debian-server2:/home/hipo# dpkg --set-selections < packages.txt
debian-server2:/home/hipo# apt-get -u dselect-upgrade --yes

The first apt-get update command assures the server will have the latest version of the packages currently installed, this will save you from running an outdated versions of the installed packages on debian-server2

Bear in mind that using apt-get sometimes, might create dependency issues. This is depending on the exact package names, being replicated in between the servers

Therefore it is better to use another approach with bash for loop to "replicate" installed packages between two servers, like so:

debian-server2:/home/hipo# for i in $(cat packages.txt |awk '{ print $1 }'); do aptitude install $i; done

If you want to automate the questioning about aptitude operations pass on the -y

debian-server2:/home/hipo# for i in $(cat packages.txt |awk '{ print $1 }'); do aptitude -y install $i; done

Be cautious if the -y is passed as sometimes some packages might be removed from the server to resolve dependency issues, if you need this packages you will have to again install them manually.

4. Mirroring package selection from server1 to server2 using one liner

A quick one liner, that does replicate a set of preselected packages from server1 to server2 is also possible with either a combination of apt, ssh, awk and dpkg or with ssh + dpkg + dselect :

a) One-liner code with apt-get unifying the installed packages between 2 or more servers

debian-server2:~# apt-get --yes install `ssh root@debian-server1 "dpkg -l | grep -E ^ii" | awk '{print $2}'`
...

If it is necessery to install on more than just debian-server2, copy paste the above code to all servers you want to have identical installed packages as with debian-server1 or use a shor for loop to run the commands for each and every host of multiple servers group.

In some cases it might be better to use dselect instead as in some situations using apt-get might not correctly solve the package dependencies, if encountering problems with dependencies better run:

debian-server2:/home/hipo# ssh root@debian-server1 'dpkg --get-selections' | dpkg --set-selections && dselect install

As you can see using this second dselect installed "package" mirroring is also way easier to read and understand than the prior "cryptic" method with apt-get, hence I personally think using dselect method is a better.

Well that's basically it. If you need to synchronize also configurations, either an rsync/scp shell script, should be used with all defined server1 config files or in case if a cloning of packages between identical server machines is necessery dd or some other tool like Norton Ghost could be used.
Hope this helps, someone.

Troubled Day

Thursday, April 5th, 2007

It was a day full of waiting. The Admin/tech support personel in sofia is a real pain in the ass. I waited half a day for a simple debian base install. The guy installed debian over already installed freebsd on a server we sent destined for colocation in evolink. The machine is great dual 3ghz Xeon with 3 x 70 gb SCSI discs. In 4:00 o’clock I received a mail with username and password of the server, but the system was unaccessible for 1 more hour. I got really nervous I received tons of calls from the boss, our project Manager, Vladi the PHP programmer. I logged to the server in 5:00 and configured apache with mysql upto 10:00 o’clock then did a little walk with nomen in the central park and drinked one beer per capita. I had to meet Static and Amri in 6:00 o’clock but I was busy configuring the new rack so I missed a great oportunity to have fun with old friends. ORDER has to come back to Bulgaria, today or even he maybe is already in Varna. I’m quite impatient to see him! In the afternoon I went to some spiritual downfalls but now Thanks to God I’m alive and well. The pozvanete site already points to the new rack so I hope the machine would be able to serve it’s goal perfect. This will be made clear in the morning. Soon I’m going to bed. Glory be to God for fulfilling me with his love and sustaining my life and keeping me from evil! END—–

How to list enabled VirtualHosts in Apache on GNU / Linux and FreeBSD

Thursday, December 8th, 2011

How Apache process vhost requests picture, how to list Apache virtualhosts on Linux and FreeBSD

I decided to start this post with this picture I found on onlamp.com article called “Simplify Your Life with Apache VirtualHosts .I put it here because I thing it illustrates quite well Apache’s webserver internal processes. The picture gives also a good clue when Virtual Hosts gets loaded, anways I’ll go back to the main topic of this article, hoping the above picture gives some more insight on how Apache works.;
Here is how to list all the enabled virtualhosts in Apache on Debian GNU / Linux serving pages:

server:~# /usr/sbin/ apache2ctl -S
VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:* is a NameVirtualHost
default server exampleserver1.com (/etc/apache2/sites-enabled/000-default:2)
port * namevhost exampleserver2.com (/etc/apache2/sites-enabled/000-default
port * namevhost exampleserver3.com (/etc/apache2/sites-enabled/exampleserver3.com:1)
port * namevhost exampleserver4.com (/etc/apache2/sites-enabled/exampleserver4.com:1)
...
Syntax OK

The line *:* is a NameVirtualHost, means the Apache VirtualHosts module will be able to use Virtualhosts listening on any IP address (configured on the host), on any port configured for the respective Virtualhost to listen on.

The next output line:
port * namevhost exampleserver2.com (/etc/apache2/sites-enabled/000-default Shows requests to the domain on any port will be accepted (port *) by the webserver as well as indicates the <VirtualHost> in the file /etc/apache2/sites-enabled/000-default:2 is defined on line 2 (e.g. :2).

To see the same all enabled VirtualHosts on FreeBSD the command to be issued is:

freebsd# pcfreak# /usr/local/sbin/httpd -S VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:80 is a NameVirtualHost
default server www.pc-freak.net (/usr/local/etc/apache2/httpd.conf:1218)
port 80 namevhost www.pc-freak.net (/usr/local/etc/apache2/httpd.conf:1218)
port 80 namevhost pcfreak.afraid.org (/usr/local/etc/apache2/httpd.conf:1353)
...
Syntax OK

On Fedora and the other Redhat Linux distributions, the apache2ctl -S should be displaying the enabled Virtualhosts.

One might wonder, what might be the reason for someone to want to check the VirtualHosts which are loaded by the Apache server, since this could be also checked if one reviews Apache / Apache2’s config file. Well the main advantage is that checking directly into the file might sometimes take more time, especially if the file contains thousands of similar named virtual host domains. Another time using the -S option is better would be if some enabled VirtualHost in a config file seems to not be accessible. Checking directly if Apache has properly loaded the VirtualHost directives ensures, there is no problem with loading the VirtualHost. Another scenario is if there are multiple Apache config files / installs located on the system and you’re unsure which one to check for the exact list of Virtual domains loaded.