edin.no-ip.com

This simple HOWTO will guide you about how to setup Apache2.2 + PHP5.2 + pgsql/pdo_pgsql from sketch. Compile all package from tarball can give you the maximum flexibility of functionality, e.g. you can enable both mysql/mysqli/pgsql/oci8/pdo_mysql/pdo_pgsql/pdo_oci within single installation.

Before start, I will assume you have Debian sid and Postgresql8.3 installed correctly, which will not detail within this document. In case of Debian, Postgresql8.3 installation is just as simple as a single command:

apt-get install postgresql-8.3 postgresql-client-8.3 postgresql-contrib-8.3 postgresql-common

After installation, you should also initialize your user accounts and database. Please refer to my other article for more information.

This HOWTO is highly similar as my other article which target for install Apache2.2 + PHP5.2 + OCI8/PDO_OCI from sketch on Debian sid. Therefore some duplicated section will directly refer to there, and only mention those different in case for PostgreSQL in here.

This simple HOWTO will guide you about how to setup Apache2.2 + PHP5.2 + mysql/mysqli/pdo_mysql from sketch. Compile all package from tarball can give you the maximum flexibility of functionality, e.g. you can enable both mysql/mysqli/pgsql/oci8/pdo_mysql/pdo_pgsql/pdo_oci within single installation.

Before start, I will assume you have Debian sid and MySQL5 installed correctly, which will not detail within this document. In case of Debian, MySQL5 installation is just as simple as a single command:

apt-get install mysql-server-5.0 mysql-client-5.0 mysql-common

This HOWTO is highly similar as my other article which target for install Apache2.2 + PHP5.2 + OCI8/PDO_OCI from sketch on Debian sid. Therefore some duplicated section will directly refer to there, and only mention those different in case for MySQL in here.

This simple HOWTO will guide you about how to setup Apache2.2 + PHP5.2 + OCI8/PDO_OCI from sketch. Compile all package from tarball can give you the maximum flexibility of functionality, e.g. you can enable both mysql/mysqli/pgsql/oci8/pdo_mysql/pdo_pgsql/pdo_oci within single installation.

Before start, I will assume you have Debian sid and Oracle 11gR1 installed correctly, which will not detail within this document. If you really need some help for that, please refer to my other article for more indeed guideline.

DDoS attack (http://en.wikipedia.org/wiki/Denial-of-service_attack) is all around the Internet and no one can escape from it. What we can do is trying to protect ourself whenever happened. On the other hand, DDoS attack to Apache is also very common so what can we do for it? Let's try mod_evasive (http://www.zdziarski.com/projects/mod_evasive/).

The installation of mod_evasive under Debian is very simple:

After install try this command and you will find that Debian have already active mod_evasive for us by default:

So what we only need to do is restart the Apache and let mod_evasive active:

For testing the effect of mod_evasive, you can try this command (you will have HTTP/1.1 302 Found at beginning but soon become HTTP/1.1 403 Forbidden):

Since a long days before I keep on using Apache's mod_access for spam or bad robot filtering (http://edin.no-ip.com/content/block-apache-visiting-abnormal-user-agent). It is quite handy and simple; BTW, you need to configure it manually. The benefit of the model is you only need to have a functional Apache installed then you can set it up without any special difficult and dependence; and the drawback is simple that it is not flexible.

As Debian's Fail2ban already come with apache-badbots.conf, why not utilize it? As it will function in firewall level, rather than application level (Apache), using this model would be more secure and stable, too.

Setting this up is very simple. In case of Debian, install Fail2ban with:

Then check /etc/fail2ban/filter.d/apache-badbots.conf and you will find a well pre-defined blocking list, which fetched from http://www.user-agents.org. What you need to do is active this filtering rule within your Fail2ban configuration. As mentioned in the header section of /etc/fail2ban/jail.conf, we should create a file called as /etc/fail2ban/jail.local which contain our changes for override, e.g.:

After restart Fail2ban with /etc/init.d/fail2ban restart, check your iptables with iptables -nvL and you should have similar result:

In order to check for ban/unban record, try cat /var/log/fail2ban.log | grep WARNING. E.g. soon after I have install Fail2ban it catch 1 IP for ban, due to rule of apache-overflows:

AWstats is a good replacement of Analog and Webalizer: it provide a good interface, and can analyze different type of log files, including HTTP, FTP and SMTP. It is not too difficult to setup under Debian etch, but need some tricky skill. On the other, AWstats provide an official Webmin module. So may we make use of both Webmin and AWstats, for a handy configuration and management?

This mini-HOWTO will cover the required step for installing AWstats and its Webmin module, also a simple example for how to make use all of this.

When will you need an automatically HTTPS redirection for your web service? Which means whenever client try to access the HTTP version, Apache will handle its redirection and forward them to HTTPS version. This technical is well known for most public web service which related to sensitives personal information, e.g. webmail, ebussiness, and epayment.

This simple mini-HOWTO will guide you though this useful skill with Apache 2.2 and Debian etch.

This is just a very fast and rough simple guideline for setting up Mailman + Exim4 based on Debian etch. For sure that we will also configure Apache2 for Mailman web interface. Not much detail will be mentioned, please refer to corresponding document if you hope to understand more. Debian also come with a handy guideline from /usr/share/doc/mailman/README.Exim4.Debian, so you should have a look with it before follow this guideline :)

My site is being attack by some abnormal client, with some invalid user-agent. They keep on scanning my server, and just keep on pushing up the server loading.

There is a lot of different defense method, and here is one of the simple solution (http://httpd.apache.org/docs/2.0/mod/mod_access.html). Just add the following lines (I just list those are required):

And so Apache will happily block those unfriendly user agents ;-)