gzip and deflate compression support by web browsers, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Related Articles

• Use mod_deflate to Compress Web Content delivered by Apache
• Viceo Backend for SANE with libusb support
• DD-WRT support for Wireless N Routers

First of all, I needed to know whether the /etc/sysctl.conf I had on my box differed from the original one. But, before doing that, I had to know which RPM package had installed that file. So, I used the rpm command to query this file:

# rpm -qf /etc/sysctl.conf
initscripts-9.03.27-1.el6.centos.1.i686

So, the initscripts package had installed /etc/sysctl.conf.

Then I verified the initscripts package:

# rpm -V initscripts
S.5....T.  c /etc/sysconfig/init
S.5....T.  c /etc/sysctl.conf

According to the following table:

S file Size differs
M Mode differs (includes permissions and file type)
5 MD5 sum differs
D Device major/minor number mismatch
L readLink(2) path mismatch
U User ownership differs
G Group ownership differs
T mTime differs
P caPabilities differ

the attributes: size, MD5 checksum and the modification time of /etc/sysctl.conf that existed on my system differed from the attributes of the original file.

Since I had no idea the exact changes I had made to that file at some earlier time, I needed to restore the original and re-modify it from scratch. The new yum “reinstall” command could be used to to do this quite easily.

First, I kept a copy of the current file:

# mv /etc/sysctl.conf /etc/sysctl.conf.modified

Then I reinstalled initscripts using YUM’s reinstall command:

# yum reinstall initscripts
Loaded plugins: downloadonly, fastestmirror, priorities
Setting up Reinstall Process
Loading mirror speeds from cached hostfile
 * base: ftp.ntua.gr
 * epel: ftp.ntua.gr
 * extras: ftp.ntua.gr
 * ius: mirror.rackspace.co.uk
 * updates: centosr3.centos.org
6 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package initscripts.i686 0:9.03.27-1.el6.centos.1 will be reinstalled
--> Finished Dependency Resolution

Dependencies Resolved

=============================================================================================================================================================
 Package                              Arch                          Version                                           Repository                        Size
=============================================================================================================================================================
Reinstalling:
 initscripts                          i686                          9.03.27-1.el6.centos.1                            updates                          934 k

Transaction Summary
=============================================================================================================================================================
Reinstall     1 Package(s)

Total download size: 934 k
Installed size: 5.4 M
Is this ok [y/N]: y
Downloading Packages:
initscripts-9.03.27-1.el6.centos.1.i686.rpm                                                                                           | 934 kB     00:02
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : initscripts-9.03.27-1.el6.centos.1.i686                                                                                                   1/1

Installed:
  initscripts.i686 0:9.03.27-1.el6.centos.1

Complete!

Verify the initscripts package again:

# rpm -V initscripts
S.5....T.  c /etc/sysconfig/init

No verification errors for /etc/sysctl.conf. Note that reinstalling the package did not touch the /etc/sysconfig/init file. It has been mentioned previously that rpm packages do not overwrite existing configuration files.

I had the original file back and I could then start customizing it from scratch.

Restore original configuration files from RPM packages, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Related Articles

• YUM-Priorities Configuration for a CentOS Desktop
• How To Build RPM Packages on Fedora
• How to extract RPM or DEB packages
• Running supervisor 3 on CentOS 5
• RHEL kernel source released with patches already applied

<VirtualHost 123.123.123.123:80>
  ServerName example.org:80
  ...
  DocumentRoot /home/example.org/public_html
  <Directory /home/example.org/public_html>
    AllowOverride All
    ...
  </Directory>
  ...
</VirtualHost>

In order to prevent the htaccess lookups on the filesystem without losing the htaccess functionality – at least at the DocumentRoot level- I transformed the configuration to the following:

<VirtualHost 123.123.123.123:80>
  ServerName example.org:80
  ...
  DocumentRoot /home/example.org/public_html
  <Directory /home/example.org/public_html>
    AllowOverride None
    Include /home/example.org/public_html/.htaccess
    ...
  </Directory>
  ...
</VirtualHost>

Let’s see what we have accomplished with this:

1. httpd does not waste any time looking for and parsing htaccess files resulting in faster request processing,
2. the virtual host administrator can still override the configuration options of the document root manually or through the web interface of the web application.

Seems like a win-win situation performance and functionality wise.

But, as usual, there is no win-win situation without a downside. In this case, the above trick weakens the server’s security. Let’s see how.

Although the configuration of a directory can be set in both httpd.conf and the directory’s htaccess file, not all directives can be used in both contexts. htaccess files support a subset of the directives that can be used in the Directory context within httpd.conf. By including the htaccess file in httpd’s configuration the vhost admin is no longer restricted to that subset of directives.

This means that by implementing the above configuration the virtual host administrator is granted more privileges regarding the configuration of the virtual host. This also means that a potential attacker, that would exploit a vulnerability of the web application, would be granted the same privileges once he got write access to that htaccess file.

So, although this trick may seem like a good idea at first, it is in fact a rather bad idea and should never be used in production, unless you trust the virtual host administrator and the web application. I do not intend to use such a configuration and I do not recommend it. There are by far better ways to speed up Apache.

Your comments and suggestions are welcome.

Speed up Apache by including htaccess files into httpd.conf, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Related Articles

• .htaccess Cheat Sheet
• SSL-enabled Name-based Apache Virtual Hosts with mod_gnutls
• Script for Apache Error Report
• Use mod_deflate to Compress Web Content delivered by Apache
• Mozilla Thunderbird speed up

- Wtf I just installed 6….
- I just installed 5.
- Once the version number is up to 50 in a short amount of time, it will become a joke, and future releases will be ignored.
- Firefox is killing themselves is what they’re doing. People use Firefox for the plugins, every new version installation kills all plugins. After I install this, there’s technically no reason for me to use Firefox over Chrome anymore. Why doesn’t Mozilla understand this???
- Pro tip: People aren’t switching from Firefox to Chrome because it’s got a “better” version number, guys.

I would add that it is not necessary to go through all the numbers from 5 to 14 to catch up with Chrome in terms of major version numbers. These could be just skipped and go straight to 14!

PS: The Firefox extension of a software I had paid for had stopped working since the FF3 -> FF4 upgrade. A workaround was released by the company for FF4, but as soon as FF5 came out it stopped working again. I’ll be straight. I’d rather use Internet Explorer or Chrome or Opera instead of asking the company for a workaround every time the Mozilla folks roll out a new major release of Firefox.

The new amateuristic release strategy of Firefox, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Related Articles

• Use the Alternatives System to switch to a custom Firefox release
• The Read-It-Later extension
• Mozilla Thunderbird speed up
• Release Time

The problem lies in the way that block ciphers are used in SSL/TLS. Block ciphers are generally operated in one of several modes that define how encrypted blocks are manipulated to ensure complete confidentiality. Cipher Block Chaining, or CBC mode, is used in SSL for all block ciphers, including AES and Triple-DES. The BEAST attack relies on a weakness in the way CBC mode is used in SSL and TLS. Non-CBC cipher suites, such as those using the RC4 stream encryption algorithm, are not vulnerable.

There have been several suggested mitigations that can be put into play from the perspective of the client, such as reorganizing the way the data is sent in the encrypted stream. Servers can protect themselves by requiring a non-CBC cipher suite. One such cipher suite is rc4-sha, which is widely supported by clients and servers.

Researchers have concluded that the RC4 (Alleged RC4) based cipher suites are not vulnerable to the BEAST attack, while CBC (Cipher Block Chaining mode) based cipher suites are. This involves both the TLS 1.0 and the SSL 3.0 protocols. On the contrary, TLS 1.1 and 1.2 have not been found to be vulnerable, but their use is very limited since they haven’t been adopted by the majority of HTTP clients and servers yet.

So, the use of RC4 based ciphers is all that is left for the moment. The security experts have released a list of cipher suites that is suitable for use in the configuration of the mod_ssl module for httpd:

SSLHonorCipherOrder on
SSLCipherSuite !aNULL:!eNULL:!EXPORT:!DSS:!DES:RC4-SHA:RC4-MD5:ALL

They have also released a one-liner list of ciphers suitable for use in the relevant fields of the Local Group Policy Editor in Windows Server boxes.

However, there is no info about configuring the mod_gnutls module for apache to use RC4 based ciphers, so, as a dedicated user of mod_gnutls, I decided to release this tip. All you have to do is set the preferred ciphers in the GnuTLSPriorities directive. In this example we use the TLS 1.0 protocol:

GnuTLSPriorities NONE:+VERS-TLS1.0:+ARCFOUR-128:+RSA:+SHA1:+COMP-NULL

Visiting a secure web site that has been configured using any of the methods described above and by checking the information of the secure connection to that website, you should see the following message:

Firefox message about using RC4 encryption cipher

This means that everything is working correctly.

As always, comments and suggestions are welcome and appreciated.

How to configure mod_gnutls to use the RC4 cipher to mitigate the SSL/TLS vulnerability, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Related Articles

• Using SSH for networking
• SSL-enabled Name-based Apache Virtual Hosts with mod_gnutls
• Critical vulnerability in Adobe Reader
• mod_gnutls binary for Apache
• How to configure and use LIRC

gfx.direct2d.disabled
layers.acceleration.disabled

Also, open the Add-on Manager (tools/add-ons/plugins) and disable all plugins that do not need to be enabled in your email client. Note that the plugins are a different thing than the extensions. I disabled them all in my TB.

Finally, restart Thunderbird.

This has worked for me. Thunderbird 6 now feels as responsive as TB3 was.

Mozilla Thunderbird speed up, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Related Articles

• Mozilla Thunderbird 3 is out!
• Speed up Apache by including htaccess files into httpd.conf
• Be cautious with Notepad++

wget ftp://ftp.cc.uoc.gr/mirrors/linux/fedora/linux/development/rawhide/source/SRPMS/supervisor-3.0-0.4.a10.fc16.src.rpm

The simplest way to build an RPM for our CentOS release is to use the --rebuild option of rpmbuild:

rpmbuild --rebuild supervisor-3.0-0.4.a10.fc16.src.rpm

Wait a few seconds for it to finish and then your binary RPM package will be in ~/<your_building_env>/RPMS/....

To satisfy dependencies, you will also need the package python-meld3. So, download and rebuild it:

wget ftp://ftp.cc.uoc.gr/mirrors/linux/fedora/linux/development/rawhide/source/SRPMS/python-meld3-0.6.7-4.fc16.src.rpm
rpmbuild --rebuild python-meld3-0.6.7-4.fc16.src.rpm

Having built RPM packages for supervisor and python-meld3, you can now transfer them to a testing box and install them:

yum localinstall /path/to/supervisor.rpm /path/to/python-meld3
yum install python-elementtree

We also installed elementtree as this is a dependency missing from the supervisor spec file (note to self: file a bug report).

Finally, try to start supervisord:

/etc/init.d/supervisord start

Surprisingly, it complains about the missing elementtree!

Starting supervisord: Traceback (most recent call last):
  File "/usr/bin/supervisord", line 5, in ?
    from pkg_resources import load_entry_point
  File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 2479, in ?
    working_set.require(__requires__)
  File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 585, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.4/site-packages/pkg_resources.py", line 483, in resolve
    raise DistributionNotFound(req)  # XXX put more info here
pkg_resources.DistributionNotFound: elementtree

Checking the requirements file at: /usr/lib/python2.4/site-packages/supervisor-3.0a10-py2.4.egg-info/requires.txt there are no special version requirements:

meld3 >= 0.6.5
elementtree

[iterparse]
cElementTree >= 1.0.2

After some investigation on the supervisor-users mailing list, I found a message that indicated that setuptools.setup() should be used instead of distutils.core.setup() in the setup.py script.

So, the dependency resolution depends on the way the package has been installed! I didn’t even bother to patch setup.py… Knowing that the dependencies are correctly installed, I commented out the elementtree line and also the meld3 line as this caused the same error.

So, my /usr/lib/python2.4/site-packages/supervisor-3.0a10-py2.4.egg-info/requires.txt file looks like this:

#meld3 >= 0.6.5
#elementtree

[iterparse]
cElementTree >= 1.0.2

Now supervisor starts without errors:

# /etc/init.d/supervisord start
Starting supervisord:                                      [  OK  ]
# cat /var/log/supervisor/supervisord.log
2011-05-12 02:56:08,221 CRIT Supervisor running as root (no user in config file)
2011-05-12 02:56:08,267 INFO RPC interface 'supervisor' initialized
2011-05-12 02:56:08,267 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2011-05-12 02:56:08,271 INFO daemonizing the supervisord process
2011-05-12 02:56:08,272 INFO supervisord started with pid 21337

This is what it takes to run supervisord 3 in CentOS 5 or RHEL 5. If you have any comments and suggestions, please let me know in the comments below.

Running supervisor 3 on CentOS 5, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Related Articles

• High CPU usage while running CentOS as guest on Virtualbox or VMware
• Sticking with CentOS, RPMforge and yum-priorities for now
• YUM-Priorities Configuration for a CentOS Desktop
• Awaiting CentOS 6
• My running dog

ntfs-3g and ntfsprogs projects merge, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Related Articles

• The importance of regular data backups

• Save pages to a reading list to read when you have time.
• Offline reading mode lets you read the items you’ve saved for later on the plane, train, or anywhere without an internet connection.
• Sync your list to all of your computers, at work or home.
• Sync your list to Read It Later apps for iPhone, iPod, iPad, Android and more.
• After reading, bookmark pages on your preferred bookmarking service or share them with friends.
• Click to Save Mode lets you quickly batch a reading list just by clicking on interesting links.
• Text view strips away images, ads, and layout from articles and presents them in an easy to consume way.

Until today I have been keeping content that I wished to read at a later time in the browser’s bookmark system or I left yet another tab open or stored the URL in a text file. This plugin seems that it will provide a decent solution and eliminate the trouble. I haven’t used the remote service yet and I am not sure if I will ever do. The local “read queue” works really well.

The Read-It-Later extension, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Related Articles

• Tab Links extension for the Epiphany browser
• Tab Session Management extension for Epiphany

So, TOR can provide anonymity as far as the user’s ISP is concerned, but is it a secure way to communicate with remote services? If no extra encryption is used, then it is quite obvious that using remote services through the TOR network is totally insecure. Here is why.

The TOR exit-node is a key point in the communication between the user and the remote service. This is where the user’s data exits the TOR tunnel and continues its way to the remote service through the 3rd party ISP’s network. It is also the place where data from the remote service leaves the 3rd party ISP’s network and enters the TOR tunnel in order to reach the end user. If no encryption is used, it is possible for the exit-node operator to sniff this network traffic. This means that it is technically possible for an evil exit-node operator to:

• know which web pages the user visits
• read the messages the user exchanges through unencrypted IM networks
• read the emails the user sends
• if the user authenticates to any services without encryption, the evil exit-node operator could for example find out his mailbox or FTP account password or the passwords the user uses for authentication to web sites
• even if the authentication to a web service has taken place through an encrypted SSL tunnel, if the rest of the communication with this specific web service is not encrypted, the evil operator could grab a copy of the user’s session cookie for this service and access it pretending to be him

These are some of the nasty things that can happen when you access remote services through a proxy server which you do not control.

Is there any guarantee that exit node operators do not sniff network traffic?

Even if the exit-node operators are cool, who can guarantee that the network traffic is not monitored within the 3rd party ISP‘s network? If the user accesses personalized services without encryption, then, even if the user’s real IP and thus his real name is not known, various pieces of collected data can be combined together and possibly reveal his real identity. This process is widely known as re-identification.

Is there any guarantee that the ISP providing internet access to a TOR exit node does not collect and sell information to “marketers and identity thieves”?

I consider the TOR project quite important. But, since typical internet users are urged to use the TOR network in order to browse the internet, the involved risks have to be explained in detail.

On the other hand, I’d like to urge internet users to spend some time to familiarize themselves with the basics of the HTTP protocol, the concepts of HTTP authentication and cookie based authentication and the importance of encrypted HTTP connections through SSL or TLS tunnels. Since the internet has become part of your lives, regardless of your profession, you need to be educated about these things, so as to be able to realize when your communication with the various internet services is vulnerable. You don’t have to be gurus, but rather get an idea of what is going on.

So far, it is quite clear that the only way to stay on the safe side while using anonymizing proxies on which you usually do not have full control, like TOR, is to connect to any remote services using encrypted connections only, usually through SSL or TLS tunnels. Personally, I never use anonymizing networks or third party proxies. This is because I never really had the need to hide my real location. Furthermore, I find it pointless as I don’t believe that such a thing as anonymity is really feasible. If I had to use TOR, I would try to find a way to connect to the remote service over an encrypted connection. In general, whenever I need a secure SOCKS proxy, for example when I have to use a public network to access personalized internet services, which do not offer full SSL access, I use OpenSSH client’s -D switch while logging in to a SSH server which I own and fully control and thus I have all the security I need.

How secure is the TOR network for everyday internet browsing?, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Related Articles

• Set up the VNC Server in Fedora
• Auto-closing SSH tunnels