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.

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

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

#! /usr/bin/env bash
#
# Error Report for httpd
#
# Requires:
#   - scanerrlog - http://www.librelogiciel.com/software/ScanErrLog/action_Presentation
#   - jaxml - http://www.librelogiciel.com/software/jaxml/action_Presentation
#
 
cat /var/log/httpd/error_log \
    /var/www/vhosts/*/log/error_log \
    | python /usr/local/bin/scanerrlog.py -f text \
    | /bin/mail -s "`hostname` - Apache Error Report" root@localhost
 
exit 0

Some notes:

1. Make sure that this cronjob runs before log rotation takes place.
2. The above shell script concatenates the error_log files from the main web server and all virtualhosts. Edit the paths to reflect your server configuration and virtualhost layout.
3. Edit the path to scanerrlog.py.

Scanerrlog has some quite nice features that let you further customize the report. Make sure you read the help message.

Related Articles

• SELinux audit reports script
• Strange mod_dav_svn error
• Speed up Apache by including htaccess files into httpd.conf
• SSL-enabled Name-based Apache Virtual Hosts with mod_gnutls
• How to integrate seaudit-report in logwatch

function rsse_add_related_posts($PostBody) {
  if (!rsse_verify_feed()) { return $PostBody; }
  if (function_exists('yarpp_related')) {
    $PostBody .= yarpp_related(array('post'),array(),false,false,'rss');
  }
  return $PostBody;
}
 
add_filter('the_content', 'rsse_add_related_posts', 252);

This code used a function of another plugin to attach a ‘related posts‘ section at the end of the full content of each feed entry. As soon as I commented out the above filter and started attaching the related-posts section to the feed content through the YARPP plugin’s administration interface, everything was normal again. No more php-cgi processes timing-out or over-consuming the CPU cycles.

The following graph shows clearly the problematic period:

php-cgi processes consuming the CPU

The httpd error_log included many errors like the following:

[...]
Allowed memory size of 33554432 bytes exhausted (tried to allocate 18893 bytes)
[...]
mod_fcgid: process ... exit(communication error), terminated by calling exit(), return code: 1
[...]
[warn] (104)Connection reset by peer: mod_fcgid: read data from fastcgi server error.
[...]
[warn] mod_fcgid: stderr: PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 4864 bytes)
[...]
Premature end of script headers: index.php
[...]

Note that these errors might appear in several occasions.

In my case, finding that faulty piece of code was a huge relief, I can tell you.

Related Articles

• WordPress 2.0.6 – Feed Issues Resolved
• G-Loaded Feeds
• Redmine deployment delayed
• Issue addressed: Author feeds deliver full content
• Status of content availability via feeds

I use mod_fcgid to run PHP in fastcgi mode, but I cannot let it run the same amount of Redmine instances as it will bring the server to its knees. Redmine is not a blog. It’s a whole project hosting platform. Each instance will require about 45MB of RAM. I have already experimented with another Apache module that can manage Rails applications, but this will require some extra testing and this is exactly what I am going to do in the following days.

The most unfortunate thing is that I have removed the old platform and, for a couple of weeks now, CodeTRAX serves a 503 Service Unavailable error document, which I consider bad for the website. I hope I find the time to fix this soon.

Related Articles

• Redmine deployment meets social media
• Redmine
• Some Preliminary Redmine Customizations
• delayed-shutdown initscript
• Issues with the feeds are now resolved

Configuration

The procedure must be performed by root.

First of all, you need to edit the /etc/sysconfig/clock file:

ZONE="Etc/GMT"
UTC=true

Please, read the notes below for more information about the settings above.

Then run the tzdata-update utility. This copies the correct zonefile to /etc/localtime:

/usr/sbin/tzdata-update

Finally, update the system time by either running ntpd or the ntpdate utility. Both are part of the ntp RPM package, so if this is not installed, just use “yum install ntp” to get it installed.

/usr/sbin/ntpdate -b pool.ntp.org

This will make sure your time is correct.

You can set a cronjob to update the system’s time using ntpdate, like this:

#
# Update the system time
#
55 23 * * * root /usr/sbin/ntpdate -4 -b pool.ntp.org 2>&1 >> /var/log/ntpdate.log

Notes

Here are some notes about the configuration of the timezone:

1. You can find the valid timezones by changing to the /usr/share/zoneinfo/ directory. From there, any relative path to a timezone file is a valid timezone. For example, “Etc/GMT“, “Europe/Athens“, “America/New_York” et cetera.
2. GMT and UTC time are practically the same and they both refer to the Greenwich Mean Time, so setting the timezone to “Etc/UTC” or “Etc/GMT” is practically the same.
3. In /etc/sysconfig/clock you can set whether the hardware clock is set to UTC/GMT time or to Local Time. I am not sure in what way the hardware clock gets involved is the time of the Operating System. But, anyway, if you know how the hardware clock is configured, set this accordingly to true or false. Usually, if I set the OS to use GMT time, I also set this to true regardless of the actual hardware clock configuration. More info on this is still needed.
4. In /etc/sysconfig/clock you may see the options ARC=false and SRM=false. These change the way the “epoch” is assumed by the console on Alpha systems and have no effect if you do not use such a platform. Delete them or leave as is, unless you know you need to set one of them to true.
5. In order to set the correct timezone, you could just create a symlink at /etc/localtime pointing to the correct timezone file in /usr/share/zoneinfo/. Then again, this would render the system configuration file /etc/sysconfig/clock (and thus all other applications that use it) useless and ineffective, so this method is generally not recommended.

Final thoughts

Setting your server to use the correct time is very important. Generally, I hate it when I see web sites or other services having incorrect time. This reveals the web server or the web application administrator’s laziness or inability to properly configure the time. I hope this guide will help get rid of this issue.

Related Articles

• Maxmind’s GeoIP.dat.gz location change
• Change console font in Fedora
• Assign Virtual IPs to your NIC
• How to Disable IPv6 in Fedora and CentOS
• How to change the expiration date of a GPG key

Having used Red Hat Linux, CentOS and Fedora over time I have finally come to several conclusions about each of them (well RHL has reached EOL). Below, I try to summarize the advantages and downsides of each of the last two distributions both as an operating system for a server and as a project to which you might want to contribute (since you use it on your boxes):

CentOS

Advantages:

• Almost guaranteed stability. The distribution includes old but proven versions of software which are very unlikely to have serious security or blocker bugs. “Almost” is used because you get true guaranteed stability only by using Red Hat Enterprise Linux (RHEL), which is available under contract by Red Hat Inc.
• The CentOS or better the RHEL Life-Cycle is 7 years.

Disadvantages:

• The included software on the base repositories does not fully cover the needs of a modern server. Using software from 3rd party repositories has become a common practice among CentOS users. There are some well-known repositories, but it may happen that you have to use a package from a repository that is not so popular or (many times) completely unknown. Using software from 3rd party repositories renders your installation less secure.
• If a bug is not security-related, it may take several months (sometimes more than a year) to get fixed. Although the sources are the same with RHEL, except for the artwork, logos and release notes, CentOS has its own bug tracking system, which is completely unrelated to the Red Hat bug tracking system, meaning that they do not monitor or notify each other for bug submissions and fixes, despite the fact that the two OSes are almost alike. In practice, this is worse than it sounds. Things *could* be better.
• The organization of the community behind CentOS is not very clear. Even if you want to contribute some time and effort you will have to accept some things “as is”. In general, it is nowhere near the organization and openness of the Fedora community.
• CentOS does not differ from the vast majority of Linux distributions when it comes to your relationship as a contributor to the project, which is mostly governed by “bro” rules and practices.

Fedora

Advantages:

• Software availability. The project’s repositories contain a huge amount of packages, which have been built with common, well-documented packaging guidelines. Almost any software a modern server may require can be found in the main RPM repository. Only in rear occasions you will need a 3rd party repo.
• A well-organized community around the project. All procedures are open and well-documented.
• Professional procedures and practices govern your relationship to the project as a contributor.
• Bugs are resolved rather quickly, especially blocker bugs.

Disadvantages:

• Short life-cycle of about 13 months.
• Theoritically, less stable versions of software than CentOS or RHEL. Even the server software is updated too often. Despite of the high quality of the server software, the frequent updates makes it “feel” less stable. From my own experience though, I’d say that, if CentOS gets an “100% Stable” label, a Fedora Server gets a 99.5%. Personally, although I had set up several services on the box, I never had any stability issues, but that does not necessarily mean that they do not exist.

As you can see, both distributions have their downsides. Now that I have written all the above, I think that there is a gap between the two OSes, which could be filled by a 3rd operating system. A system that would be more modern than CentOS, but less “cutting edge” than Fedora, and which would have a life-cycle of about 3-4 years. That would be very interesting.

Personally, I have successfully used both operating systems as servers for several years. I cannot make up my mind and decide which one better meets a server’s requirements. As I have previously mentioned, I decided to fully switch to CentOS because of the significantly longer life-cycle.

Related Articles

• Sticking with CentOS, RPMforge and yum-priorities for now
• CentOS, Debian, FreeBSD, OpenSolaris
• CentOS – Community ENTerprise Operating System
• Almost saying goodbye to innovation
• How to Disable IPv6 in Fedora and CentOS

On the other hand, about 4+ years ago I had switched from Microsoft Windows to Fedora for my desktop needs. My experience with Fedora as a desktop so far has shown that this operating system does not actually help me meet my goals as far as the desktop computer is concerned. Fedora is one of those OSes where all the development and testing takes place. Its own goal is to be innovative and provide the user with the latest technologies. But, this inevitably makes it a rather buggy operating system. Things that work today may be broken tomorrow. I have tried really hard to get used to this unpredictable way of computing, but I cannot do it any more. So, I have decided to switch back to something more stable and predictable.

Two of the candidates for my desktop are CentOS and Windows Vista. I chose those two because I know them very well. My decision is not driven by my intention to contribute back to the community through this particular use of one of the aforementioned operating systems. If that was the goal, I would stay with Fedora or migrate to Ubuntu, OpenSuse, Gentoo or any other Linux distribution that represents the so called “cutting edge”. I need a desktop operating system that is reliable, stable, predictable and easy to use. As far as CentOS is concerned, this comes at the cost of using older versions of software (by default), for instance it ships with OpenOffice 2.3 (it is easy to upgrade though). In the case of Windows, stability, reliability and predictability have to be bought and also the “license to use” is bound to the hardware. Well, nothing is really free in this world. Everybody has to make choices.

Strictly judging by the use of a particular operating system as a desktop, one thing I would like to put some emphasis on is that a CentOS user does not differ much from a Windows user. Both choose a predictable system and pay the necessary cost (whatever it might be) in order to accomplish their goals. Moreover, since both of those OSes have already been extensively tested by others, the users’ primary goal is not to contribute back to the community in the form of bug-hunting or beta-testing, which is probably one of the most important parts of the software development process. Of course, both CentOS and Windows have bugs, but it would be a joke to compare the type and the number of problems that arise in these OSes to the issues a Fedora/Ubuntu/OpenSuse/Gentoo etc user has to face.

If any user of a conservative Linux distribution (Debian-testing included) feels insulted by being compared to a Windows user, I apologize. It was not my intention to insult you or make you feel uncomfortable in any way. A user of a conservative Linux distribution may contribute to the FOSS development by other means, but what I try to analyse here are the criteria upon which the choice of an operating system is made and what that choice practically means.

But, that is enough with this topic.

What this post is about is my announcement that I officially migrate to CentOS for both the server and the desktop. I am also considering migrating to Windows Vista as far as my desktop is concerned, but this will depend on how my desktop experience with CentOS will be. Time permitting I will be closely following the development of Fedora through virtualization and, as usual, report any issues I encounter.

Related Articles

• Almost saying goodbye to innovation
• Fedora Server vs CentOS
• CentOS, Debian, FreeBSD, OpenSolaris
• Sticking with CentOS, RPMforge and yum-priorities for now
• Running supervisor 3 on CentOS 5

One way to resolve the issue mentioned above is to inject our own authorization code into the relevant phase of the HTTP request processing. What this authorization code is going to do is to dynamically construct the path to the requested repository’s authz file, parse the authz file, determine the level of access the user may get in accordance to the HTTP request type and, finally, return an OK or an error code back to Apache.

Tonight I’ve spent several hours on this. Although, the appropriate approach would be to patch mod_authz_svn, I am not that excited about such an approach as I would need several days of hard work to modify an existing apache module. Instead, I have almost finished an authorization handler and an authz file parser (only basic syntax is supported), both written in python, which can be used by apache with the help of mod_python.

This is not finished yet. As you might have assumed I need this piece of code for Project CodeTRAX. Although, I had decided not to release anything related to that project until it is finished, I might make an exception and release this piece of python code in order to get some valuable feedback about if and how secure it is.

Related Articles

• Strange mod_dav_svn error
• Search for a string in multiple files
• A change of plans regarding a web-based VCS manager
• VeriTAR – Verify checksums of files within a TAR archive
• rsapiget downloads files using the new Rapidshare API

$ ps -ef | grep httpd | grep -v grep
root      1926     1  0 Dec03 ?        00:00:55 /usr/sbin/httpd.worker
apache    2608  1926  0 14:31 ?        00:00:06 /usr/sbin/httpd.worker
apache   22192  1926  0 01:05 ?        00:00:02 /usr/sbin/httpd.worker

So, in my case the child processes are run by user “apache“. This could also be determined by the user and group directives inside Apache’s configuration file, /etc/httpd/conf/httpd.conf:

User apache
Group apache

So, in order to make a directory writable by the webserver we have to set the directory’s owner or group to Apache’s owner or group and enable the write permission for it. Usually, we set the directory to belong to the Apache group (apache or www-data or whatever user is used to launch the child processes) and enable the write permission for the group.

chgrp apache /path/to/mydir
chmod g+w /path/to/mydir

In many cases, usually in shared hosting environments, it is not possible to change the ownership of files and directories. In those cases you could just set the write permission for everyone (others):

chmod o+w /path/to/mydir

Which method is more secure depends on how /path/to/mydir is accessed.

If it is accessed through the web server with an HTTP request it does not really matter which of the above methods has been used in order to make /path/to/mydir writable by the web server, because, in any case, the web server will be able to write to /path/to/mydir.

If the directory is accessed by other means, for instance by another local program which is run by an untrusted local user, then, obviously, the first method is more secure.

I guess this explains how to make a directory or file writable by the web server process.

Related Articles

• Redmine deployment delayed
• .htaccess Cheat Sheet
• Issues with the feeds are now resolved
• File and Directory diff in color in Midnight Commander
• Script for Apache Error Report