edin.no-ip.com

I am using Debian etch for production, plus Exim4 with per user ~/Maildir support. Since I hope to forward each user message to their own public email for backup, Procmail FAQ give me a useful example.

First of all, check if your Exim4 have ~/.procmailrc supported, which usually already there. Find the follow code snippet from /etc/exim4/exim4.conf.template:

Work around together with Debian's procmail example (/usr/share/doc/procmail/examples/), just create a ~/.procmailrc as below:

Send an email to this user, check the mail log with tail -f -n 50 /var/log/exim4/mainlog and you will find that message already forward to your target public email address, with a saved local copy :-)

My Samba is working fine before but some days ago, it keep on generating some '*Zone.Identifier*' files, e.g. DskPerf.zip:Zone.Identifier:$DATA, when copy file from WinXP SP3 to Samba. I can't delete them from both Windows and Linux, and I don't even understand why it come out suddently...

Finally, openSUSE forum give me a workable solution (http://forums.opensuse.org/network-internet/387779-samba-file-transfer-c...). Just add the following line to smb.conf:

vfs objects = streams_xattr

After restart Samba no more '*Zone.Identifier*' files will be generated :-)

My Oracle 11gR1 gone crazy with 100% CPU loading when working with Debian sid. This page provide a functional solution:

Shutdown OEM, login as SYSMAN user and restart the provisioning daemon by executing the two packaged procedures

SYSMAN> execute MGMT_PAF_UTL.STOP_DAEMON

PL/SQL procedure successfully completed.

SYSMAN> execute MGMT_PAF_UTL.START_DAEMON

PL/SQL procedure successfully completed.

Start OEM again and the problem is gone.

WARNING: You must take this on your own responsibility!

So here is my detail procedures. For shutdown OEM (login as user oracle where Oracle 11gR1 installed in /u01/app/oracle/product/11.1.0/db_1/bin):

Login as SYSMAN:

Then execute the following PL/SQL commands:

Restart OEM:

Check the CPU loading and it should be fine now :-)

Debian only provide stable and testing installation CD/DVD so there is no way to install with sid directly. In order to use Debian sid, you will need to upgrade from existing installation. BTW, you may try once before but found that there was a lot of error message about package dependency, or not even able to complete the upgrade due to some tricky gap.

Here I will give you a simple guideline about how to upgrade in an elegant and stable style, from Debian stable or testing to sid.

Backup usually require for a lot of storage space, and so we always hope to preform some compression. Default style of Bacula on Debian is coming "without" compression, which means all txt/bmp/wav files will store as original size. You can configure Bacula director to use GZIP during backup, and the compression will preform in File Daemon (FD, which means your backup client) locally before send to Storage Daemon (SD) though network, which means it will also save some of your bandwidth usage. But for sure, it trade some performance for the benefits.

To configure Bacula director to use GZIP compression is quite simple: within the director configuration file (/etc/bacula/bacula-dir.conf), just add the line compression = GZIP under your FileSet ->Include -> Options section, e.g.:

Before software compression option on, your log report should have line as below:

Restart all of your Bacula daemons, and preform a full backup if possible. Now you may see the difference within the log report with line similar as:

So that's it :-)

Drupal have "Clear URL" mechanism, require for Apache mod_rewrite activated and edit local .htaccess only, which will forward request URL from:

As more elegant style:

MediaWiki also come with "Short URL" (http://www.mediawiki.org/wiki/Manual:Short_URL); BTW, it will required for Apache and root access (http://www.mediawiki.org/wiki/Manual:Short_URL#Disadvantages), so it is not suitable if you are using some virtual hosting service. There is still some other mini-HOWTO (http://www.mediawiki.org/wiki/Manual:Short_URL#Other_how-to_mini-guides), but still too complicated for me. What if we only require for something similar as Drupal's "Clear URL" in MediaWiki, how to do so?

Step 1: activate Apache's mod_rewrite

First of all, ensure your Apache's mod_rewrite is activated. It is too common and so will not detail in here.

Step 2: define rewrite rule under .htaccess

Next, create a new .htaccess under your MediaWiki root directory. E.g. If your MediaWiki is installed under /home/groups/project1/public_html/mediawiki, you will need to create the file /home/groups/project1/public_html/mediawiki/.htaccess as below:

Well... What if we only have MediaWiki installed under /public_html directly? Just use the rewrite rule as RewriteBase / (or just left it blank if you are not using VirtualDocumentRoot). BTW, this style is not recommended in MediaWiki official documents (http://www.mediawiki.org/wiki/Manual:Short_URL#URL_like_-_example.com.2F...).

How about if MediaWiki installed under /public_html/production/mediawiki? Man, you are too fancy... Use the rewrite rule as RewriteBase /production/mediawiki...

Step 3: ask MediaWiki to handle the redirect request

Finally, edit /home/groups/project1/public_html/mediawiki/LocalSettings.php and check/add the follow lines:

If you have some special case as stated above, change this 2 line accordingly ;-)

Final result

Therefore, whenever you access:

You will be forward to:

Which similar as Drupal's "Clear URL" style :-)

According to the release of Linux kernel 2.6.25 on Debian sid, it is time to upgrade my Debian server's NVIDIA display driver (on-board display of FOXCONN 6100M2MA-8EKRS2H). BTW, if combine with official stable release of NVIDIA AMD64 driver v.169.12, the installation will be fail due to not compatible. Currently we have 2 options:

1. Install v.169.12 with patch applied.
2. Install beta driver v.173.08.

Prepare your Debian sid for driver installation

For sure that I am not talking about the complete and functional installation of X11 (it is just as simple as running tasksel and choose Desktop environment...), but the prepare of gcc. Since Debian sid Linux kernel is compiled with gcc-4.1, the default linkage of gcc to gcc-4.2 will let the NVIDIA driver installer complain with it... So let's handle in a handy method... Remove the default symbolic linkage and relink to the correct version:

Don't forget to roll this back after the complete of driver installation:

rm -rf /usr/bin/gcc
ln -s /usr/bin/gcc-4.2 /usr/bin/gcc

Option 1: Install with v.169.12

Download the driver from here: http://www.nvidia.com/object/linux_display_amd64_169.12.html

Get the correct version of patch: http://www.nvnews.net/vbulletin/showthread.php?t=110088

Apply the patch and start the installation with:

Option 2: Install with v.173.08

Download the driver from here: http://www.nvidia.com/object/linux_display_amd64_173.08.html

Start the installation with:

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:

After my recent dark ages, is time to review my Debian security level... As a starting point, the Securing Debian Manual is a must for ANY Debian administrator. Moreover, there is some useful tools, e.g. tripwire, chkrootkit and fail2ban, too.