Nginx

Today I ran up to quite intresting product from Russia - Nginx.

Nginx is high performance web and proxy server and, what I have heard, it's capable to run quite high load on very low requirements. Regarding to this article, Wordpress.com is using Nginx as load balancer, handling over 8000 requests / sec. That's quite impressive!

What's best, Nginx is really lightweight. According to testimonials in Nginx wiki, this web server can be run with really low RAM. Excellent.

I'm going to screw 'round with this piece of software now. Going to report you back later!

Apache Internal Dummy Connection

Yesterday I updated our Apache HTTPD to the latest version (2.2.8). Soon after this I noticed that HTTPD's access log was logging some stange requests:

::1 - - [13/Mar/2008:09:05:13 +0200] "OPTIONS * HTTP/1.0" 200 -

And what does the request do?

[asdf@foobar logs]# telnet localhost 5453
Trying 127.0.0.1...
Connected to localhost (127.0.0.1).
Escape character is '^]'.
OPTIONS * HTTP/1.0

HTTP/1.1 200 OK
Date: Thu, 13 Mar 2008 07:06:43 GMT
Server: Apache/2.2.8 (Unix) PHP/5.2.5
Content-Length: 0
Connection: close
Content-Type: text/plain; charset=UTF-8

Connection closed by foreign host.

I did a little research on the web and came up with the following links:
http://vdachev.net/blog/2007/02/01/apache-internal-dummy-connection/
http://apache.hpi.uni-potsdam.de/document/4_3Multitasking_server.html

It seems like the request above is called "Internal Dummy Connection", and it's a way for apache to let it's children processes know it's time to die. It's usually nothing you should worry about, but if you see many child processes spawn and die, you may want to configure MinSpareServers and MaxSpareServers directives, and your MaxRequestsPerChild.

If you want to clean up your HTTPD access logs, you can do the following:

SetEnvIf Remote_Addr “::1″ dontlog
CustomLog /foo/bar/access.log combined env=!dontlog

Discovering duplicate files

A while ago I had a problem. I had to change my file servers hard drives, and I didn't have large enough hard drive to take copies of. This lead to the situation where I had copies of my data spread on various computers, and after I got my server up and running again, I realized there were quite many duplicate files on my server.

Luckily I found a nice small application called fdupes. This program goes thru directories and creates MD5 sum of every file. After the process it compares the MD5 sums and lets the user know which files are duplicates.

Fdupes can be found on regular Fedora Core yum repository and the usage of the program is quite easy:

fdupes -r /share << the directory you want to scan, recursively

The program gives you nice list of the duplicate files

Truecrypt 5.0 on Fedora Core

That's it! I've had enough with TC on my box. And all it took was six days. Before it, I ran TC on Ubuntu for one week. And now it's history!

My problems began when I was installing TC on Ubuntu. Or actually, there was no problem when installing Truecrypt. I found this version of Truecrypt, build on X86_64. The problems began when I was trying to use ext2 or ext3 -filesystem on Ubuntu. Truecrypt supports FAT32 and NTFS -filesystems straight out of the box. Can you imagine Linux box using FAT filesystem?

Well, luckily there is a way how to use some other filesystem on Truecrypt. Well, did it work? No, sir! mkfs.ext3 crashed my machine. So did mkfs.ext2. What's the solution? Reiserfs!

After few hours of struggle, I finally had my (k)Ubuntu installation with a hard drive encrypted with Truecrypt. The filesystem had to be Reiserfs, because mkfs with ext2/ext3 failed.

After few days of usage, I ran into problem that my box started to crash randomly. I thought that the problem was xscreensaver, so I disabled it. I also had problems with (k)Ubuntu's firewall >> I decided to install my beloved Fedora Core. I managed to install Truecrypt using .deb files, and I allready had my hard drives encrypted with reiserfs.

Goodbye, problems? So I thought. I started to move backups from my other boxes to ecrypted filesystems, and I ran into problems of crashing box. Again. Luckily this time I had my ssh session open with top runnig on the screen. I saw that my box's iowait was 99% and system load near 50 before crashing. Conclusion: Truecrypt doesn't like small files (like your picture collection, large amount of midi files, or even mp3 files. I tried to copy one 12gb tar archive from encrypted filesystem to "clean" filesystem, iowait 99% and crash. Again. At this point I decided that this is no time for me to use ecryption. Adios, Truecrypt! Maybe next time!

I have to say, that the usage of TC was quite easy. Point n' click. But the results were bogus. What a shame.

I must admit that I will follow truecrypt forums and if I find out that the performance problems are gone, I'll give it another shot.

Tightening SSHD security on Fedora Core

Here's few tips how to improve your SSHD security on your Fedora Core box. With these easy steps you can make sure no-one's gonna hack into your box.

1) Install fail2ban

Fail2ban is a script, that actively tracks the connections against sshd. If someone tries to scan your sshd using many different account names and passwords, fail2ban denies connections from that IP for 15 minutes.

You can install fail2ban easily with yum:
[root@machine ssh]# yum install -y fail2ban.noarch

You can start using fail2ban straight after installation is complete:

[root@machine ssh]# /etc/init.d/fail2ban start

The log file is found at /var/log. Fail2ban can also send email with information about banned IP-addresses.

2) Restricted ssh connections

You can allow ssh connections only for specified accounts.

Emacs your /etc/ssh/sshd_config and add following line:

AllowUsers username1 username2

You should allso make sure Root cannot access your ssh:

PermitRootLogin no


After this, restart your sshd.

3) Change your SSHD port

By default, SSHD is located at port 22. Many port scanners try to locate ssh servers running at that address. If you change your sshd to a high port (above 1024), you get rid of many port scanning attempts. For example, nmap cannot scan ports above 1024.

In sshd_config, change:

#Port 22 >> Port 1100

Restart your sshd.


4) Allow only specific hosts to connect using TCP wrappers

You should allow SSH connections to your machine only from wanted IP addresses. Anything else is unwanted, and possibly hazadrous. For this you can use two files: /etc/hosts.deny and /etc/hosts.allow

Hosts.deny controls which traffic you want to deny, and /etc/hosts.allow which traffic you want to allow.

Here's an example how to deny all ssh access. Simply type the following to your hosts.deny:

sshd: ALL

Now, after you restart your sshd, all sshd traffic is blocked.

If you want to have access from your IP-addresses 192.168.1.1 and some public address, simply type the following to your hosts.allow:

sshd: 192.168.1 xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy

If you want to allow all traffic from .se -domains, simply type this to your hosts.allow:

sshd: .se

This can be done allso with hosts.deny:

sshd : ALL EXCEPT .se

And if you want to block traffic from some countries but allow everything else, you can type this to hosts.allow

# Allow SSH (http://en.wikipedia.org/wiki/Country_code_top-level_domain)
sshd : ALL EXCEPT .br .cl .cn .hk .in .kr .mx .my .ro .ru .tw .ua

# Allow everything else
ALL : ALL

Fixing Joomla + JCE + madeyourweb center align

I wanted to use Joomla + JCE editor + madeyourweb -template on a web site.

After installing all necessary stuff, I realized that JCE editor uses madeyourweb -template's align=center - setting. Here's two ways to fix this:

1) Open Joomla administrator >> goto Mambots >> Site Mambots and open JCE Editor Mambot

On left side there's a text saying "Template CSS classes", change this setting to No, and Voilá, align is left again.

Here's more advanced option:

2) Edit your template_css.css and change align=center to align=left

Or

3) Copy your template_css.css to another file, edit this file and force JCE Mambot to use this CSS file in "Custom CSS Classes" -option.

Installing x11vnc on Fedora Core

This is a very short guide how to install x11vnc to your Fedora Core.

x11vnc allows one to view remotely and interact with real X displays (i.e. a display corresponding to a physical monitor, keyboard, and mouse) with any VNC viewer. In this way it plays the role for Unix/X11 that WinVNC plays for Windows.

x11vnc is by far the easiest available vnc server for Linux. Just download, configure/make, and off you go! And it works like a charm over ssh tunnel!

Here's how I installed x11vnc on my FC8:

1) Download .tar.gz from http://www.karlrunge.com/x11vnc/

2) Make sure you have X Software Development packets installed on your FC. To be sure, just open your sytem >> add/remove software, scroll down to development, and make sure you have X on your "x11 development".

3) After downloading http://www.karlrunge.com/x11vnc/x11vnc-0.9.4.tar.gz, just tar zxvf x11vnc-0.9.4.tar.gz, ./configure, make and make install

4) Now you have your x11vnc server ready to be tested... It's propably installed at /usr/bin/x11vnc, and you can test drive it by just typing the command "x11vnc".