Is a caching nameserver really important?

There is some controversy about the real benefits of using a caching name server in a system, either desktop or server. In this article we keep controversy out of the discussion and focus on the performance improvement the caching of DNS information can offer to a system while performing specific tasks. For instance, a caching nameserver allows a web browser to acquire DNS information from the local DNS cache, provided that this information has already been cached, without the need to access any public DNS servers, which results in faster web browsing. Similarly, in a server environment, services like spam filters often need to perform many DNS queries for the same hostnames. The latency of the communication with the remote nameserver may add up to the total time of email processing.

BIND vs dnsmasq

BIND is the flagship of DNS servers with large deployments around the globe. I have used BIND for many years as a caching nameserver, even on my desktop, until I realized it is overkill to use BIND this way. There are lighter solutions, even all-in-one software like dnsmasq, that seem to be more suitable for setting up local DNS caching.

System preparation

So, let’s get started with the system preparation before going into the details of the dnsmasq configuration.

First of all, we need to install dnsmasq:

yum install dnsmasq

dnsmasq, when run as root, is designed to drop privileges and run as an unprivileged user. By default, this user is nobody. We use a dedicated system user to run dnsmasq.

Run the following commands as root to create such an unprivileged system user and group named dnsmasq:

groupadd -r dnsmasq
useradd -r -g dnsmasq dnsmasq

The above should be enough.

Configuration

All dnsmasq configuration options go into /etc/dnsmasq.conf. Here we write this file from scratch, so if you need to keep a copy of the original that ships with your distribution, do so with:

cp /etc/dnsmasq.conf /etc/dnsmasq.conf.orig

Now, let’s get started with adding our own dnsmasq configuration in /etc/dnsmasq.conf.

First of all, we set some options regarding the basic server operation like the interface and port on which it should bind, the unprivileged user that should run the service and a PID file:

listen-address=127.0.0.1
port=53
bind-interfaces
user=dnsmasq
group=dnsmasq
pid-file=/var/run/dnsmasq.pid

The bind-interfaces directive instructs dnsmasq to bind only to the network interface specified in the listen-address directive.

Next comes logging.

By default, dnsmasq sends its log messages to the DAEMON syslog facility (LOCAL0 when operating in debug mode). We go with the defaults here, but keep in mind that a separate log file can be set as it is shown in the configuration snippet below (currently commented out):

#log-facility=/var/log/dnsmasq.log
#log-queries

Logging to file requires some extra configuration for proper log rotation. For more information, please read Appendix II.

Finally, we set the options that configure dnsmasq’s name resolution and caching operations.

The following directives prevent dnsmasq from forwarding plain names (without any dots) or addresses in the non-routed address space to the parent nameservers.

domain-needed
bogus-priv

The no-hosts directive also instructs dnsmasq not to read any hostnames from /etc/hosts. In most systems, /etc/hosts is queried before a DNS service is used by the system for name lookups. So, all plain name to private IP mappings should normally be added in /etc/hosts. If this is not what you want, then take a look at the expand-hosts and domain directives.

no-hosts

Set the maximum number of concurrent DNS queries. The default value is 150. Adjust to your needs.

dns-forward-max=150

Set the size of the dnsmasq cache. The default is to keep 150 hostnames. By setting the cache size to 0 disables the feature (this is not what we really want). Again, adjust this value according to your needs.

cache-size=1000

The following directive controls whether negative caching should be enabled or not. Negative caching allows dnsmasq to remember “no such domain” answers from the parent nameservers, so it does not query for the same non-existent hostnames again and again. This is probably useful for spam filters or MTA services. By default, negative caching is enabled. To disable, un-comment the following directive.

#no-negcache

The neg-ttl directive sets a default TTL value to add to negative replies from the parent nameservers, in case these replies do not contain TTL information. If neg-ttl is not set and a negative reply from a parent DNS server does not contain TTL information, then dnsmasq will not cache the reply. Here we set the default TTL to 3600 seconds. Again, adjust to your specific needs.

neg-ttl=3600

Here we use a separate file where dnsmasq reads the IPs of the parent nameservers from. The syntax is the same as in /etc/resolv.conf. We do this to facilitate the manipulation of the parent nameservers that should be used by dnsmasq by using, for example, an external script. The filename we use here is resolv.dnsmasq, but this can be changed to your liking. We also set the no-poll directive here to prevent dnsmasq from polling the ‘resolv’ file for changes.

resolv-file=/etc/resolv.dnsmasq
no-poll

A full configuration file containing all the above configuration, which can can be used as a drop-in replacement of the default /etc/dnsmasq.conf, can be found in Appendix I.

Upstream Nameservers

We have used a separate file to store the IPs of the parent nameservers; that is /etc/resolv.dnsmasq. Using the same syntax as in /etc/resolv.conf add the nameserver IP addresses in resolv.dnsmasq. For example:

nameserver 192.168.0.252
nameserver 192.168.0.253
nameserver 192.168.0.254

Note that we still need to make a change in /etc/resolv.conf before the system starts using dnsmasq for domain name lookups. Read on…

Starting dnsmasq

In order to start dnsmasq, run as root:

/etc/init.d/dnsmasq start

Check the syslog or the dnsmasq logfile (if used) for any error messages.

If everything seems to be OK, set the dnsmasq service to start on boot:

chkconfig dnsmasq on

This command might be Red-Hat specific, so consult your distribution’s documentation about how to set services to start on boot.

Switch name resolution to dnsmasq

What we have done so far is set up the dnsmasq service. For hostnames that do not exist in /etc/hosts the system still uses the nameserver inside /etc/resolv.conf for name resolution.

To start using dnsmasq, edit /etc/resolv.conf, remove all nameservers and add only the IP of our dnsmasq service:

nameserver 127.0.0.1

From now on, the system will use dnsmasq for domain name resolution. You can un-comment the log-queries option in order to confirm the dnsmasq operation.

Appendix I – Full configuration file

This is the complete configuration file containing the configuration that has been discussed in this article. Note that it can be used as is to replace the default /etc/dnsmasq.conf.

#
# Configuration file for dnsmasq acting as a caching nameserver.
#
# Format is one option per line, legal options are the same
# as the long options legal on the command line. See
# "/usr/sbin/dnsmasq --help" or "man 8 dnsmasq" for details.
#
# Updated versions of this configuration file may be available at:
#
#   http://www.g-loaded.eu/2010/09/18/caching-nameserver-using-dnsmasq/
#
#
# Basic server configuration
#
listen-address=127.0.0.1
port=53
bind-interfaces
user=dnsmasq
group=dnsmasq
pid-file=/var/run/dnsmasq.pid
#
# Logging
#
#log-facility=/var/log/dnsmasq.log
#log-queries
#
# Name resolution options
#
domain-needed
bogus-priv
no-hosts
dns-forward-max=150
cache-size=1000
#no-negcache
neg-ttl=3600
resolv-file=/etc/resolv.dnsmasq
no-poll

This file is meant to be used both on servers and desktops.

Appendix II – Logging to file

Before dnsmasq starts logging to file it is required to set the path to the logfile in the log-facility option inside /etc/dnsmasq.conf.

log-facility=/var/log/dnsmasq.log

To ensure proper rotation of the log file you should use the following logrotate configuration:

/var/log/dnsmasq.log {
    monthly
    missingok
    notifempty
    delaycompress
    sharedscripts
    postrotate
        [ ! -f /var/run/dnsmasq.pid ] || kill -USR2 `cat /var/run/dnsmasq.pid`
    endscript
    create 0640 dnsmasq dnsmasq
}

Save the above configuration in /etc/logrotate.d/dnsmasq. Also, adjust the log filename or the path to the PID file in case you have used custom names, but make sure you do not change the USR2 signal that is sent to the dnsmasq process in the post-rotation script.

Final Thoughts

dnsmasq is a very lightweight service. Therefore, you can run it on any system, either server or desktop without any noticeable impact on system resources. In this guide we used it as an internal system service bound to the loopback interface, without permitting direct access from the outside. This along with the fact that dnsmasq is mature software that has been around for several years makes our setup rather secure.

Several people might argue that the performance improvement a local caching nameserver offers in terms of name lookup speed is insignificant. This might be true in some cases, but there are times that this performance improvement is noticeable, especially when the quality of the network connectivity between the current machine and the upstream nameserver is an issue, or when the upstream name server is overloaded. On the other hand, it is almost certain that a local caching DNS server can in no way make name resolution slower, unless perhaps a huge cache is being used. Generally, I find keeping such a service operational a good idea.

In this article we discussed about one of the dnsmasq features: DNS caching. dnsmasq is a lot more than just that. Check the whole feature set in the dnsmasq homepage. Perhaps, in the future, more guides covering other features of this software are published. Until then, enjoy local DNS caching!!!

Related Articles

• Set up an anonymous FTP server with vsftpd in less than a minute
• How to integrate seaudit-report in logwatch
• Assign Virtual IPs to your NIC
• Use wget or curl to download from RapidShare Premium
• SSL-enabled Name-based Apache Virtual Hosts with mod_gnutls

vsftpd Configuration

Assuming vsftpd has already been installed in the standard location, the directory /etc/vsftpd/, which contains its configuration files, should exist. You can edit vsftpd’s default configuration file (/etc/vsftpd/vsftpd.conf), but in this example, we will create a new configuration file from scratch.

Create a new configuration file named /etc/vsftpd/vsftpd-anon.conf and open it in your favourite text editor and write down the directives that follow:

Set the server to run in standalone mode. This means that vsftpd will run into the background and handle the incoming requests on its own. The alternative method (listen=NO) would require you to set up a xinetd service. This would not be a bad idea, but for the sake of this example, it would be a waste of time.

listen=YES

The following directives prevent local users from logging in and enables anonymous access respectively.

local_enable=NO
anonymous_enable=YES

The following directive disables write access to the ftp server’s filesystem. This is a global switch, so noone will be able to upload or modify any files on your ftp site.

write_enable=NO

Sets the root directory for anonymous connections. By default, this is /var/ftp/.

anon_root=/var/ftp

The following configuration directives are optional and can be safely omitted.

Limit the rate at which anonymous users can retrieve files.

anon_max_rate=2048000

Enable logging information about user logins an file transfers. The log file is located at /var/log/vsftpd.log.

xferlog_enable=YES

Set the interface and port the service will listen on. By default, vsftpd will bind to all local network interfaces on port 21, which is the standard port of the File Transfer Protocol. Note that listen_address accepts only numeric IP addresses (no hostnames).

listen_address=192.168.0.100
listen_port=21

The entire vsftpd-anon.conf file

#
# Sample anonymous FTP server configuration
#
# Mandatory directives
#
listen=YES
local_enable=NO
anonymous_enable=YES
write_enable=NO
anon_root=/var/ftp
#
# Optional directives
#
anon_max_rate=2048000
xferlog_enable=YES
listen_address=192.168.0.100
listen_port=21

Start or Stop the FTP server

Assuming you have created the supplementary vsftpd-anon.conf configuration file, run as user root:

vsftpd /etc/vsftpd/vsftpd-anon.conf

To stop the service run:

killall vsftpd

Alternatively, you can send the SIGTERM signal to a specific vsftpd process.

On the other hand, if you had edited vsftpd’s default configuration file, you could start/stop the service using the /etc/init.d/vsftpd initscript.

Sharing files and directories

An FTP server without any files is like having a swimming pool without any water in it. In order to make some files and directories available through your FTP service you have two options:

1. Copy or move the files or directories inside the anon_root directory.
2. Create bind mounts of the directories you want to share in the anon_root directory.

You may wonder why you cannot just create some symbolic links inside anon_root pointing to the directories you want to share. Even if you created those symlinks and connected to the service using an FTP client, you would notice that you are not permitted to reach the linked location. This happens because anonymous users are restricted (chrooted) to anon_root and, therefore, no location outside this directory is accessible using symlinks.

Bind mounts are the solution to this problem. When bind-mounting, you mount a directory (A) to another directory (B) on the same or different filesystem, so that the contents of directory A appear as contents of directory B. It’s like a symlink, but at a lower level of the filesystem and that’s why you can reach locations outside the chroot jail.

In our scenario, the installation tree of a Linux distribution is shared through the FTP service. It is assumed that the installation medium has been inserted into the drive and either the system or you have mounted it, for example, to the directory /media/CentOS/. We want the contents of the DVD to be accessible through the FTP server, so we need to bind-mount the DVD contents to a directory inside anon_root. As user ‘root‘ issue the following command:

mount --bind /media/CentOS /var/ftp/pub

Now, connecting to the FTP service you will notice that the contents of the pub/ directory is the CentOS installation tree.

It is quite obvious that, despite the fact that vsftpd does not support the creation of a virtual filesystem (mainly a virtual directory structure) internally, one can be easily implemented with bind-mounts.

Do not forget the firewall

When we run a server temporarily on the desktop computer, we tend to forget to open the necessary ports on the filewall. In the case of vsftpd, you should open port 21 or the port number you have assigned to the listen_port configuration directive. Please consult the documentation of your firewall management application about how to perform this action.

Further Reading

• All the supported configuration directives for vsftpd.

Related Articles

• When it comes to error messages…
• Caching Nameserver using dnsmasq
• Setup the SSH server to use keys for authentication
• Set up the VNC Server in Fedora
• Making a directory writable by the webserver

Update: Firefox 3.0 final has become available from the official fedora updates repository. It seems that the technical issues of the past do not exist any more! Kudos! This tutorial will still give you an idea though about how to quickly and easily switch between the default and custom versions of the same software in your system.

Fedora 9 has been used as the desktop system for this article. The provided information will certainly work in CentOS and RHEL, but might also work for other linux distributions which use the alternatives system, such as Debian, Ubuntu, OpenSUSE etc. As far as I know, Gentoo and its derivatives use their own system.

In order to check if “alternatives” is available in your system, try one of the following commands:

which alternatives
which update-alternatives

Firefox Installation

First of all, we install a precompiled (binary) Firefox distribution, downloaded from mozilla.org, in the /opt directory. All the following commands should be issued by ‘root‘ or by your regular user using ‘sudo‘.

Change to the /opt directory, download and extract the firefox package:

cd /opt/
wget ftp://ftp.mozilla.org/pub/firefox/releases/3.0/linux-i686/en-US/firefox-3.0.tar.bz2
tar -xjf firefox-3.0.tar.bz2

Now change to the /opt/firefox/ directory, delete the plugins/ subdirectory and create a symlink to the system’s directory containing the firefox plugins (/usr/lib/mozilla/plugins/ in Fedora).

cd firefox/
rm -fr plugins
ln -s /usr/lib/mozilla/plugins/ plugins

The installation of the custom Firefox version is complete.

Set the system-wide default Firefox version

In this section we will use the alternatives system in order to provide us with two options:

1. Use Fedora’s default Firefox release. This means that /usr/bin/firefox should be executed whenever we issue the ‘firefox‘ command.
2. Set our custom Firefox release as the system’s default. This means that /opt/firefox/firefox should be executed whenever we issue the ‘firefox‘ command.

Note: Describing the details of the alternatives system is out of the scope of this article, so it is highly recommended that you study the alternatives manual page (man 8 alternatives)

In the following steps we will add a group, named “firefox“, of alternative options for the location of the firefox executable. These options are actually filesystem locations which will be linked by the /usr/local/bin/firefox symlink. Note that we use the /usr/local/bin/… path for our symlink, because /usr/bin/firefox is occupied by fedora’s firefox executable. The latter will not be called directly any more, as the executables located in /usr/local/bin/ override the ones located in /usr/bin/, so whenever the command ‘firefox‘ is invoked, /usr/local/bin/firefox will actually be used. The latter is a symlink, which links to either fedora’s firefox executable or our custom firefox executable.

So, we add the ‘firefox‘ group of options:

/usr/sbin/alternatives --install /usr/local/bin/firefox firefox /usr/bin/firefox 10
/usr/sbin/alternatives --install /usr/local/bin/firefox firefox /opt/firefox/firefox 20

Now we can manually set which firefox executable to use as the system’s default. In other words, the following command links /usr/local/bin/firefox to the desired executable (/opt/firefox/firefox in our case):

/usr/sbin/alternatives --set firefox /opt/firefox/firefox

Instead of the --set option as shown above, we can use the –config option, so that a list of the available alternatives is displayed and we are prompted to make a selection:

# /usr/sbin/alternatives --config firefox
There are 2 programs which provide 'firefox'.
  Selection    Command
-----------------------------------------------
   1           /usr/bin/firefox
*+ 2           /opt/firefox/firefox
Enter to keep the current selection[+], or type selection number: 2

Finally, we can issue the following command to get an overview of our current configuration for the group ‘firefox‘:

# /usr/sbin/alternatives --display firefox
firefox - status is manual.
 link currently points to /opt/firefox/firefox
/usr/bin/firefox - priority 10
/opt/firefox/firefox - priority 20
Current `best' version is /opt/firefox/firefox.

Revert to the original state

If for any reason you need to revert things back to the default state, all you have to do in order to remove all the “alternatives” we had configured in the previous section is the following:

/usr/sbin/alternatives --remove firefox /opt/firefox/firefox
/usr/sbin/alternatives --remove firefox /usr/bin/firefox

No other configuration is required. From now on, whenever the ‘firefox‘ command is invoked, fedora’s old /usr/bin/firefox is executed.

Final Thoughts

Technical issues in the linux distribution preparation process might limit the user to certain software versions. The alternatives system provides users with the choice to configure the system in a way that it is extremely easy to switch between default and custom versions of the same software.

Related Articles

• The new amateuristic release strategy of Firefox
• Using setenforce to switch SELinux mode wisely
• Using a switch to prevent system shutdown/reboot/suspend
• Local YUM Repository
• The use of the uppercase X in chmod

First, is the cipler-none patch that adds none as a valid argument to the -c command line option. By using it, the transferred data is not encrypted. Pros: eliminates the data encryption overhead. Cons: totally insecure method of transferring sensitive data.

cipher-none-patch

Note: the OpenSSH server, even if it has been patched with this code, does not accept unencrypted connections by default. This has to be enabled explicitly in the sshd configuration (sshd_config) by adding the none “cipher” to the list of the accepted ciphers:

Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr,none

Note2: here is step-by-step guide how to configure the SSH authentication using public keys.

Second, is a set of patches, created at the Pittsburgh Supercomputing Center, which eliminate the bottlenecks caused by some of the internal buffers that control data flow in network connections through OpenSSH. This project is called High Performance SSH/SCP (aka HPN-SSH). Benchmarks show that even encrypted network connections using HPN-SSH perform extraordinarily better than the usual encrypted OpenSSH connections.

OK, this info exists here for completeness, as those HPN-SSH patches have not been designed for home networks! Possibly it might make no difference if you use the regular OpenSSH or HPN-SSH in your home LAN.

Note: the HPN-SSH patches also contain code that adds the none cipher, similar to the cipher-none patch, so, if you intend to use HPN-SSH, it is not required to apply both on the OpenSSH source.

Finally, apart from all these, if you ever decide to use SSH for networking seriously consider using SSHfs (see also SSHfsFAQ).

Related Articles

• How to configure mod_gnutls to use the RC4 cipher to mitigate the SSL/TLS vulnerability
• Assign Virtual IPs to your NIC
• Setup the SSH server to use keys for authentication
• Encrypt devices using dm-crypt and LUKS
• TrueCrypt on 2.6.18 kernels

Check if the module is loaded

IPv6 functionality is being made available to the system by the ipv6 kernel module. To check if this module is currently loaded in your system, issue the following command as root:

lsmod | grep ipv6

If you see ipv6 in its output, then the module is loaded.

Performing this check is absolutely not necessary. It is included in this article for completeness.

Disable IPv6

You can prevent a module from being inserted into the kernel by either blacklisting it or by completely disabling it.

In this case, since you will most probably turn off the IPv6 firewall (ip6tables) as well, it is highly recommended to completely disable the ipv6 module, to avoid any accidental loading of the IPv6 stack without any firewall protection at the same time.

How the module blacklist works

This information about blacklisting a kernel module exists here for educational purposes. It has been mentioned above that for ipv6 it is important to completely disable it.

From the modprobe.conf man page:

Modules can contain their own aliases: usually these are aliases describing the devices they support, such as “pci:123…”. These “internal” aliases can be overridden by normal “alias” keywords, but there are cases where two or more modules both support the same devices, or a module invalidly claims to support a device: the blacklist keyword indicates that all of that particular module’s internal aliases are to be ignored.

So, blacklist indicates that a module’s aliases should be ignored. But, what happens if an application requires to load that specific module or if root uses modprobe to load it on demand? Let’s test it…

To blacklist the module, simply save the following line in a file inside /etc/modprobe.d:

blacklist ipv6

Next, disable any services that use IPv6, eg ip6tables or any IPv6-enabled network interfaces and reboot (mandatory).

After you’ve logged-in again, try, for example, to load the ipv6 module with the modprobe command (as root):

[root@centos]# modprobe -v ipv6
insmod /lib/modules/2.6.18-53.1.14.el5/kernel/net/ipv6/ipv6.ko
[root@centos]# lsmod | grep v6
ipv6                  251393  8

The blacklisted module has been loaded. This is what happens if it is needed by a system service, regardless of the fact that it has been blacklisted. In the case of ipv6 this could be a security risk, provided that the ipv6 firewall has been turned off but some network interfaces still use IPv6. So, frankly, it is suggested to read on how to disable the module more aggressively…

Completely disable the ipv6 module

To completely disable IPv6 in your system, all you have to do is save the following line in a file inside /etc/modprobe.d/.

install ipv6 /bin/true

The above line means: whenever the system needs to load the ipv6 kernel module, it is forced to execute the command true instead of actually loading the module. Since /bin/true, does absolutely nothing, the module never gets loaded.

Again, it is required to reboot for the changes to take effect.

It is obvious that this is an aggressive method to disable kernel modules, but it guarantees that the module never gets loaded.

This is the recommended way to disable IPv6.

Other Configuration Tasks

Since the IPv6 functionality has been disabled, you can disable the ip6tables service (IPv6 Firewall). Issue the following command as root:

chkconfig ip6tables off

It is also a good idea, since the ip6tables service has been turned off, to disable any IPv6-related functionality in the network interface configuration. Even if you do not do this, the IPv6 stack will not be initialized because the ipv6 module cannot be loaded. But, generally, you could set the following options to “no” inside your network interface scripts, for example: /etc/sysconfig/network-scripts/ifcfg-eth0

IPV6INIT=no
IPV6_AUTOCONF=no

Finally, In fedora 8 or newer you can safely remove the following option from the /etc/sysconfig/network file, if it exists:

NETWORKING_IPV6=no

Final Thoughts

Using the instructions above, you can completely disable IPv6 in your system. On the other hand, you should understand that IPv6 is not an evil thing… It exists in order to address certain issues. If you ever think about actually trying to configure and use it instead of just disabling it every time you install your Linux operating system, here is a good place to start…

Related Articles

• Fedora Server vs CentOS
• The Complete Fedora Kernel Headers
• Creative PC-CAM 750 on Fedora 10
• High CPU usage while running CentOS as guest on Virtualbox or VMware
• Set up the VNC Server in Fedora

Introducing mod_deflate

Apache prepares the response that will be sent back to the client in several stages. One of those stages involves the modification or conversion of the data using output filters. mod_deflate, once loaded and activated, inserts such a filter, named DEFLATE, in Apache’s chain of output filters, which compresses all data that goes through it according to some rules the web server administator has defined. For instance, one can set the compression level, restrict the compression to particular MIME types or prevent some problematic web browsers or other HTTP clients from receiving compressed data from the server.

mod_deflate also offers an input filter which can be used to decompress compressed HTTP requests, but this feature is outside of the scope of the current document.

Here follow some instructions on how to configure mod_deflate. Most of it can be found inside HTTPd’s official documentation, so you’d better read this resource as well.

Note that all of the following configuration directives can be inserted in Apache’s main server context or can be saved to a file that will be loaded from within the main server or any other virtual host context. If the configuration directives are inserted in the main server context, then they will be inherited by all virtual hosts.

Load mod_deflate

mod_deflate can be loaded like any other Apache module:

LoadModule deflate_module modules/mod_deflate.so

Please note that this directive can only exist in the main server configuration.

Enable Compression

The compression of the data can be enabled for all data that goes through the DEFLATE filter or selectively depending on its MIME type.

To enable the compression for any type of content, insert the following directive:

 SetOutputFilter DEFLATE

Alternatively, to define which filetypes should pass through the DEFLATE output filter use the AddOutputFilterByType directive. The following is an example:

AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

Set the Compression Level

Generally, the deflate compression algorithm is fast enough, so setting the compression level to the maximum (9) will not cause any noticeable trouble, even to relatively old hardware.

DeflateCompressionLevel 9

Custom Rules for problematic browsers

The compression can be turned-off or be restricted to files of type text/html for known problematic web browsers. These are taken from the official documentation.

BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

Keep track of the compression

Finally you can keep track of the compression in order to evaluate the effectiveness of the use of mod_deflate in your server.

The following directives define some variables, such as:

• instream : the size in bytes of the data as received by the DEFLATE filter.
• outstream : the size in bytes of the compressed data as returned from the DEFLATE filter.
• ratio : the compression ratio, (Output/Input)x100

DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio

Finally, you can define a custom logformat so to be able to record the aforementioned values to a logfile:

LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate

The deflate logformat can be used for the main server’s or for any vhost;s logfile.

Effectiveness of Compression

It is well known that not all document types can benefit the same from compression. Generally, the deflate algorithm can compress text surprisingly fast and with a very high efficiency ratio. On the other hand, it is almost useless when used to compress images which have been prepared for the web such as PNG, JPEG, GIF and generally all other image types in which the data has already been compressed. The same goes for compressed audio files, such as MP3, AAC, OGG, videos, PDF documents and all other already compressed files.

So, the benefits of using mod_deflate to reduce the bandwidth usage and speed up the content delivery are heavily dependent on the type of files your web server delivers.

Browser Support

A web server that sends compressed data to clients would be completely useless if the HTTP clients couldn’t decompress that data. All modern and popular web browsers support accepting content that has been compressed using the gzip or deflate algorithms, so there should be no problem at all.

Appendix I

Here is the complete mod_deflate configuration as described in this article. Save it in a file, named deflate.conf and import it in the main server’s configuration using the Include directive

(Include /path/to/deflate.conf):

#
# mod_deflate configuration
#
LoadModule deflate_module modules/mod_deflate.so
<IfModule mod_deflate.c>
        AddOutputFilterByType DEFLATE text/plain
        AddOutputFilterByType DEFLATE text/html
        AddOutputFilterByType DEFLATE text/xml
        AddOutputFilterByType DEFLATE text/css
        AddOutputFilterByType DEFLATE application/xml
        AddOutputFilterByType DEFLATE application/xhtml+xml
        AddOutputFilterByType DEFLATE application/rss+xml
        AddOutputFilterByType DEFLATE application/javascript
        AddOutputFilterByType DEFLATE application/x-javascript
        DeflateCompressionLevel 9
        BrowserMatch ^Mozilla/4 gzip-only-text/html
        BrowserMatch ^Mozilla/4\.0[678] no-gzip
        BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
        DeflateFilterNote Input instream
        DeflateFilterNote Output outstream
        DeflateFilterNote Ratio ratio
        LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
</IfModule>

This configuration will be inherited by all virtual hosts.

To disable it just comment out the line that loads the mod_deflate module (#LoadModule ...).

To record mod_deflate‘s specific variable (instream, outstream, ratio) values for a virtual host, just add a new log file of type deflate:

CustomLog /path/to/vhost/logs/deflate_log deflate

This will give you an idea of how efficient is the use of mod_deflate in that particular vhost.

Related Articles

• Optimize and Compress CSS Files
• SSL-enabled Name-based Apache Virtual Hosts with mod_gnutls
• Script for Apache Error Report
• Speed up Apache by including htaccess files into httpd.conf
• Check Server HTTP Headers with CURL

RPM

For RPMs you need two command line utilities, rpm2cpio and cpio. Extracting the contents of the RPM package is a one step process:

rpm2cpio mypackage.rpm | cpio -vid

If you just need to list the contents of the package without extracting them, use the following:

rpm2cpio mypackage.rpm | cpio -vt

The -v option is used in order to get verbose output to the stdout. If you don’t need it, you can safely omit this switch. For more information about the cpio options, please refer to the cpio(1) manual page.

DEB

DEB files are ar archives, which contain three files:

• debian-binary
• control.tar.gz
• data.tar.gz

As you might have already guessed, the needed archived files exist in data.tar.gz. It is also obvious that unpacking this file is a two-step process.

First, extract the aforementioned three files from the DEB file (ar archive):

ar vx mypackage.deb

Then extract the contents of data.tar.gz using tar:

tar -xzvf data.tar.gz

Or, if you just need to get a listing of the files:

tar -tzvf data.tar.gz

Again the -v option in both ar and tar is used in order to get verbose output. It is safe not to use it. For more information, read the man pages: tar(1) and ar(1).

If anyone knows a one step process to extract the contents of the data.tar.gz, I’d be very interested in it!

Update

As Jon suggested in the comment area, the contents of data.tar.gz can be extracted from the DEB package in a one step process as shown below:

ar p mypackage.deb data.tar.gz | tar zx

That will do it.

Related Articles

• Choosing a format for data backups – tar vs cpio
• How To Build RPM Packages on Fedora
• VeriTAR – Verify checksums of files within a TAR archive
• Verify a burned CD/DVD image on Linux
• Linux Tips – Pack I

Driver History

Here goes some brief history about the driver.

The E3 driver was initially developed by Steven Ellis (http://viceo.orcon.net.nz/). 0.6 was the last released version (2002), which lacked support for libusb. It seems that Steven abandoned the development of the driver at that point. Until a few days ago, the 0.6 release was what I had considered as the latest available version of the E3 driver.

What I missed, was the fact that Jimmy Nguyen had modified the 0.6 driver and had added support for libusb. I had spent countless hours searching the web in the past but I could not locate such a release of the driver. Anyhow, Jimmy’s patch was released in 2004 for sane-backends-1.0.14.

The rest has been already described above.

Supported Devices

This driver works with USB scanners equipped with the E3 chipset. Some of these scanner models (if not all) are the following:

• Genius Vivid Pro USB
• Primax Colorado USB 19200
• Visioneer OneTouch 7600
• Visioneer OneTouch 6100
• IBM IdeaScan 2000 USB
• LG Electronics Scanworks 600U

Download

I have modified the original patch in order to make it work with sane-backends-1.0.18 and also wrote a SPEC file for RPM packaging. Using a package will greatly simplify the installation procedure.

Here follows a list of files you can download:

RPM – sane-backends-viceo-1.0.18-0.7-rcnst.1.i386.rpm

RPM package of Viceo backend. Requires sane-backends-1.0.18. Installs the Viceo backend only and will not touch any other files. Please read the Installation and Configuration sections for instructions.

DEB – TODO

A DEB file for debian-based distributions is not currently available. You can still generate a deb package from the RPM using alien. In order to convert the the RPM package to a DEB, use alien like: alien -k sane-backends-viceo-1.0.18-0.7-rcnst.1.i386.rpm and a deb package will be generated for you. You can install the DEB package with: dpkg -i sane-backends-viceo-1.0.18-0.7-rcnst.1.i386.deb. Please note that this procedure has not been tested.

SPEC – viceo.spec

Required if you need to build the RPM package.

Patch – sane-backends-1.0.18-viceo.diff.gz

New Viceo backend patch for sane-backends 1.0.18. Note, that in addition to the required modifications in order to make this patch suitable for sane-backends-1.0.18, this diff does not include the modifications of the core SANE file sanei/sanei_usb.c. Everything seems to work just fine without having to patch any core SANE file.

Patch – viceoDriver4Sane1.0.14.tar.gz

Old package with Viceo patch for sane-backends 1.0.14 and some notes by Jimmy Nguyen about the release. Reading them is recommended.

All versions are available from the development web site’s download area.

Installation

Using the RPM or DEB package (see above for info) is the recommended method of installing. This package has been built in Fedora 8, but, since it is rather generic and does not contain any Fedora-specific information, it should work on any RPM-based distribution.

Using the RPM

The package sane-backends-1.0.18 is a dependency. Make sure you have installed it.

# wget http://www.codetrax.org/attachments/download/42/sane-backends-viceo-1.0.18-0.7-rcnst.1.i386.rpm
# rpm -ivh sane-backends-viceo-1.0.18-0.7-rcnst.1.i386.rpm

Please make sure you read the Configuration section for instructions on how to setup the scanner.

Manual installation

This information has been written with as much detail as possible, if you still have questions, please use the forums.

Note: The compilation of the backend should be performed by a regular user and not root.

First, download and extract the required packages. Although the sane-backends-1.0.18 package is used, we will only use it in order to build the Viceo backend.

$ wget ftp://ftp.sane-project.org/pub/sane/sane-backends-1.0.18/sane-backends-1.0.18.tar.gz
$ tar -xzf sane-backends-1.0.18.tar.gz
$ wget http://www.codetrax.org/attachments/download/41/sane-backends-1.0.18-viceo.diff.gz
$ gunzip sane-backends-1.0.18-viceo.diff.gz

Patch the sane-backends source code:

$ patch -p1 -b -d sane-backends-1.0.18/ < sane-backends-1.0.18-viceo.diff

Change to the sane-backends source code top-directory:

$ cd sane-backends-1.0.18/

We only care to build the Viceo backend, so set the BACKENDS environment variable to “viceo“.

$ export BACKENDS=viceo

Compile the backend:

$ ./configure --prefix=/usr --sysconfdir=/etc
$ make

We perform an installation in a temporary directory (1_test_install). This will help you pick up the correct files for the manual installation later. Also, you do not need root privileges for this.

$ mkdir 1_test_install
$ make DESTDIR="$PWD/1_test_install" install

Now, SANE and the viceo backend have been temporarily installed in the 1_test_install/ directory.

The following actions need to be performed by root or you can use sudo.

Make sure that sane-backends has been installed using your distribution’s package manager. Then copy the following files to the proper locations:

# cp 1_test_install/etc/sane.d/{e1.ini,lut.plg,viceo.conf} /etc/sane.d/
# cp 1_test_install/usr/lib/sane/libsane-viceo.so.1.0.18 /usr/lib/sane/

Finally, create a needed symbolic link to libsane-viceo.so.1.0.18.

# ln -s /usr/lib/sane/libsane-viceo.so.1.0.18 /usr/lib/sane/libsane-viceo.so.1

Update the library database. Run:

# ldconfig

That will be it.

SANE Configuration

The scanner configuration needs to be performed by root or you need to use sudo
The first thing to do is to add the viceo backend in /etc/sane.d/dll.conf. Note that the RPM will not do this, so you need to perform this step manually. Either add the work “viceo” (without quotes) at the end of /etc/sane.d/dll.conf or use the following command:

# echo "viceo" >> /etc/sane.d/dll.conf

If your scanner is not connected, please do so now.

Run the following command:

# sane-find-scanner

Your scanner should be identified:

[...]
found USB scanner (vendor=0x0461 [Primax], product=0x0360 [Colorado USB 19200]) at libusb:002:003
[...]

Take a note of the vendor and product codes and add a line using the following format to /etc/sane.d/viceo.conf:

usb <vendor> <product>

For me, that line inside /etc/sane.d/viceo.conf should be:

usb 0x0461 0x0360

Now list the available imaging devices. You scanner should be listed:

# scanimage -L

And this was the device listing:

device `viceo:usb 0x0461 0x0360' is a Visioneer Genius ColorPage-Vivid Pro USB flatbed scanner

Scanning

You can use the scanner either from the command-line or from within GIMP, provided that you have installed the xsane-gimp package.

If you use the scanner from the command line, wherever a device name is needed, use the device name that scanimage -L lists. For example:

# scanimage -d "viceo:usb 0x0461 0x0360" --mode Color --format=tiff --resolution 200 > z_out.tiff

Alternatively, you can set the following environment variable:

# export SANE_DEFAULT_DEVICE="viceo:usb 0x0461 0x0360"

Please read the SANE documentation for more information.

Licensing

The viceo backend is accompanied by two files which were included in the drivers for Windows, e1.ini and lut.plg. Although, you, as the owner of the hardware may use these files since you have paid for them, it is unclear whether there is a problem or not with distributing these files separately from the Windows driver package. The fact that these files are available from the home of the E3 driver v0.6, and are also included in sane-backends-1.0.14-viceo.diff, has led me to the conclusion that there is no problem in distributing these files. So, they are included in the my modified patch and RPM package. Please note that the aforementioned files e1.ini and lut.plg have neither been released nor distributed under the terms of a free license, eg GPL, so they are not free software.

Conclusion

Although the scanner is pretty old, it performs quite well. The driver won’t let you use resolutions over 600dpi, but I guess this is acceptable.

This article has been written in a fast pace. I have tried to provide as much detail as possible. If you still need help, please use our forums for your questions.

Happy scanning!

Related Articles

• pdf2email CUPS Backend
• Meld…
• Creative PC-CAM Series webcams in linux
• DD-WRT support for Wireless N Routers
• Kernel 2.6.17 and lirc_gpio driver

So, since email notifications are preconfigured, the first thing to do after a clean Linux system installation is to set the email redirection. This can be done with the following:

# echo "root:   youruser" >> /etc/aliases
# newaliases

If it happens that you find root’s or any other user’s mailbox with tons of email notifications from your system, you can delete them by entering the console mail client “mail“:

# mail

…and enter the following command at its prompt:

& delete *

I guess there are many desktop users out there with their root account’s mailbox full of system notifications. At least, for desktop systems, there should a note about setting up the redirection of root’s email to your user’s mailbox.

Related Articles

• Problems using libnotify for User to User Notifications
• Organizing Mailing List messages with Evolution
• SELinux audit reports script
• Free Personal Email Certificates Program discontinued by Thawte
• High traffic on the email server

• By directly manipulating the WordPress database. This is the quickest and most professional way, but running SQL statements is not everyone’s cup of tea.
• The second way is not actually about moving the comments, but rather about moving the post itself out of its comments. This is the simplest of the ways and requires zero knowledge of SQL.

Both ways are very safe.

The SQL Way

First of all, create a new post as usual and add any amount of content in it. What you will do is to attach the comments from the old page to the new one.

You will need to know the IDs of your new and old posts. It might not be possible to determine the post ID from the post’s URL as it might not be included in the permalink structure you use. In that case, examine the hyperlinks of the posts in question under the “Manage menu” in the WordPress administration panel.

In the following SQL queries, substitute OLD_ID and NEW_ID according to your posts’ IDs.

Transfer the comments with the following statement:

UPDATE wp_comments SET comment_post_ID=NEW_ID WHERE comment_post_ID=OLD_ID;

That’s it. The comments have been transfered, but we are not done yet.

WordPress keeps the number of each post’s comments hard-coded into the post’s record. This probably serves as a performance booster, but it is necessary to take care of it as well.

Run the following query and take a note of the number in the output. This represents the number of comments under the old post.

SELECT comment_count FROM wp_posts WHERE ID=OLD_ID;

Assume that the numeric result is COMCOUNT.

Then adjust the hardcoded number of comments under the two posts by substituting COMCOUNT, NEW_ID, OLD_ID in the following statements as appropriate:

UPDATE wp_posts SET comment_count=comment_count+COMCOUNT WHERE ID=NEW_ID;
UPDATE wp_posts SET comment_count=comment_count-COMCOUNT WHERE ID=OLD_ID;

You are set.

The WordPress Way

This is called the “WordPress way” because everything takes place within the WordPress administration panel. The general idea is to create a new post identical to the old one and change the old post, which actually has the comments, appropriately so that it is considered as a new post by WordPress.

1. First of all, create the new post and add content as appropriate.
2. Second and most important, take a good note of the old post’s “Title“, “Post Slug” and “Post Timestamp“.
3. Edit the old post‘s “Title“, “Post Slug” and “Post Timestamp” (make sure the “Edit timestamp” checkbox is checked) to some new values and save it.
4. Edit the new post‘s “Title“, “Post Slug” and “Post Timestamp” to the exact values of the old post (remember the note you had taken?) and publish it.

Done.

Conclusion

This is not a task WordPress users have to accomplish everyday. But, when there is need for it, you will know how to do it. Both ways are safe and complete. Use the one that suits you better.

Related Articles

• WordPress Tip: Schedule the publishing of a post
• Modifying Your Name In The WordPress Comments
• Simple-Recent-Comments WordPress Plugin
• More Themes using the Simple Recent Comments plugin
• Backslashes inside pre HTML tags in WordPress