WordPress Correct File Permissions

To lock down the permissions on your WordPress install, from inside the WordPress site directory, run the below commands.

chown -R root:root .
chown -R nginx:nginx wp-content wp-admin/update.php wp-admin/update-core.php 
wp-admin/network/update.php wp-admin/network/update-core.php

Note, the above command assumes you are running under Nginx, if you are under Apache, please run the 2nd command replacing nginx with apache

The above command will change all the files in your WordPress root to the ROOT user, then change only the needed files back to user your web server is running as. This will allow you to update themes & plugins, and will also let you upload images, but you will not be able to update WordPress without changing the owner/group back to nginx on your WordPress root.

Trac Installed on a Nginx Server

Over the last few weeks I have been converting all my different sites from Apache to Nginx. The nice part of this plan is as I move on from system to system, each change over get’s easier then the last.

This how-to will walk you threw how to instal Trac on a Nginx server. The plan here is to proxy your trac site back to tracd running server. Only proxy the files that are not real and can not be served by nginx alone.

To start out, install python and some python tools to your server

yum -y install python python-genshi python-setuptools 
subversion python-setuptools-devel

Now you need to download and install trac from svn

svn checkout http://svn.edgewall.org/repos/trac/trunk/ trac
cd trac

After you have the current version, compile and install trac

python ./setup.py install

This how-to assumes you already have a working trac profile to host on this site. If you do not already have a trac profile, please look at trac-admin /path/to/websites/directory initenv.

After you have trac installed, you need to start it.

export TRAC_ENV_INDEX_TEMPLATE=/var/www/trac/projects_list_template.html
/usr/bin/python /usr/bin/tracd -d -p 3050 
--protocol=http -e /var/www/trac.example.com/projects

And here’s a simple example Nginx config for your new trac setup.

   # trac.example.com
   upstream trac.example.com {
   server {
       listen 80;
       server_name trac.example.com;
       root /var/www/trac.example.com;
       location /html/ { 
       	expires 180d;
       location /favicon.ico { }
       location /robots.txt { }
       location / {
               proxy_pass        http://trac.example.com;
               proxy_set_header  X-Real-IP  $remote_addr;

Gallery3 Installed on a Nginx Server

A few months ago I converted my web cluster from Apache to Nginx. Initially I was only concerned with my WordPress sites as they get, by far the most traffic. Their conversion went well, with only very minor issues.

Since I was happy with the results, I moved to quickly to my MediaWiki site. It’s conversion went very well and actually end up allowing the site to accept requests with and without index.php in them.

During this time, my other random sites, using odd or old software, was simply proxied back to the still running Apache install on my server. Using nginx’s proxy configuration, i was able to just change the port Apache listen on and left the old configurations as they were.  This allowed me to stay up, but didn’t give me any of the benefits of nginx.  Images from the my Gallery3 gallery were still being served from Apache, threw Nginx.

After getting everything working, I decided to start on Gallery3, since Gallery3 uses .htaccess files to secure images, I wasn’t sure how I would be able to go about this.  After some investigating I found that Gallery3 only uses the .htaccess files to block downloading of the actual images them self’s, the php pages are still secured threw normal permissions.

Configuring Nginx

Setting up Gallery3 under Nginx is pretty straightforward, when ignoring the .htaccess file talked about above.  As with all my Nginx setup’s, im using php-fpm via a UNIX sock.  Switching to a TCP connection (such as, can be substituted with only minor tweaks.

To start out, create a new file in your nginx configuration directory, named gallery3.conf.  This file will be generic enough that you will be able to use it for any Gallery3 install on the server. Your site specific information will live in your main nginx.conf file.

Create a new file named gallery3.conf, and copy the below into it:

location ~* .(js|css|png|jpg|jpeg|gif|ico|ttf)$ {
    expires 180d;
#    if_modified_since off;
#    add_header Last-Modified "";

if (!-e $request_filename) {
    rewrite ^/(.+)$ /index.php?kohana_uri=$1 last;

location /var/ {
    try_files $uri /index.php?kohana_uri=$2;

location = /downloadalbum/zip/album/1 {
    return 404;

location  ~* .php$ {
    include fastcgi_params;
    fastcgi_index  index.php;
    fastcgi_split_path_info ^(.+.php)(.*)$;
    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    fastcgi_param  PATH_INFO        $fastcgi_path_info;
    fastcgi_pass php;

    index index.php;

    if (-f $request_filename) {
        rewrite ^/var/albums/(.*)$ /file_proxy/$1 last;
        expires max;

    if (!-e $request_filename) {
        rewrite ^/(.+)$ /index.php?kohana_uri=$1 last;

Now you need to setup your new site in Nginx’s main config file.  Below is the most basic setup, it assumes you have a running Nginx server and are only adding this site to it.  Note the name of the server and the root location of the files needs to be updated.

Added to nginx.conf:

server {
    listen 80;
    server_name gallery.example.com;
    root /var/www/gallery.example.com;
    include gallery3.conf;

This next part really sucks and I wish there was a way around it, in your Gallery3 installation, go into applications/config/config.php and modify the “index_page” setting as shown below.


$config["index_page"] = "";

What sucks about this is you will need to do it after EVERY UPDATE. If after you update Gallery3 and you loose your style sheet and java scripts, this is why.

The config file should not live in a location that get’s updated automatically with new versions of software.

MediaWiki Installed on a Nginx Server

Here is my quick guide to use MediaWiki on a Nginx server using php-fpm.

There are many ways of doing this. I like pretty url’s, so this configuration will remove the index.php from the url. This is great, but it will not redirect links to index.php to the new none index.php links. You also need to configure MediaWiki to use short urls. Also, the below configuration dose assume your using Unix socket connections to php-fpm.

So here we go, inside your http { block, add the following.


    server {
        listen 80;
        server_name wiki.example.com;
        root /var/www/wiki.example.com;
        include mediawiki.conf;


# MediaWiki Config
location ~ .htaccess {
        deny all;

location ~* /sitemaps/ {
        autoindex  on;

# Remote index.php from URI
rewrite ^/index.php/(.*) /$1  permanent;

location / {
        if (!-e $request_filename) {
                rewrite ^/([^?]*)(?:?(.*))? /index.php?title=$1&$2 last;
        if ($uri ~* ".(ico|css|js|gif|jpe?g|png)(?[0-9]+)?$") {
                expires max;

location ~* .php$ {
        if (!-e $request_filename) {
                return 404;

        include /etc/nginx/fastcgi_params;

        fastcgi_pass  unix:/var/run/php-fpm.socket;
        fastcgi_index index.php;

        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;

If you only have a single wiki on your server, there’s really no reason to create a new mediawiki.conf file, but instead just add it to the server block.

Installing WordPress on Nginx

I, like most people, started out by using Apache and really didn’t see anything wrong with it.  It’s relatively easy to setup, it’s used by most sites so support is a snap and a default and it’s already installed on most distributions. The thing is, it’s slow, the easy of use is paid for by speed.

So this is where Nginx comes in.  Nginx is not the easiest software to setup.  It requires you to tell it what different file types you will be using and how to handle them.  It requires you to tell it where scripts live and where static files live.  It also requires you to use an external php server, such as FastCGI.


Nginx does not provide FastCGI for you (FastCGI is what your web server uses to interact with WordPress’s PHP code), so you’ve got to have a way to spawn your own FastCGI processes.

My preferred method is using of running FastCGI is with php-fpm.  Since I’m using Fedora, and there is a yum packet already built for php-fpm, it’s quick and easy to install.

Installing php-fpm is pretty straightforward:

yum install php-fpm

After installing php-fpm you have to start it. The rpm for php-fpm installs the service script for you, you only need to enable starting at boot, and start the process.

chkconfig php-fpm on
service php-fpm start


The next part is to install Nginx on your server.  This is as straightforward as installing php-fpm on Fedora, when using yum.

yum install nginx

Once Nginx is installed, you need to set it up to server your site.

Configuring Nginx for WordPress

So we now have the needed software installed, next we need to set it all up. Below is the config for a standard, simple WordPress site named example.com.

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] $http_host "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;
    sendfile        on;
    #tcp_nopush     on;
    rewrite_log     on;
    keepalive_timeout  5;
    index              index.php index.html index.htm;

    # Upstream to abstract backend connection(s) for PHP.
    upstream php {
        server unix:/var/run/php-fpm.socket;

    server {
        listen 80;
        server_name example.com;
        server_name www.example.com;
        root /var/www/example.com;

        if ($http_host != "example.com") {
                rewrite ^ http://example.com$request_uri permanent;

        include wordpress.conf;


# WordPress single blog rules.
# Designed to be included in any server {} block.

# Deny all attempts to access hidden files such as .htaccess, .htpasswd, .DS_Store (Mac).
location ~ /. {
        deny all;
        access_log off;
        log_not_found off;

# Deny access to any files with a .php extension in the uploads directory
location ~* ^/wp-content/uploads/.*.php$ {
        deny all;
        access_log off;
        log_not_found off;

# Deny access to any files with a .php extension in the uploads directory for multisite
location ~* /files/(.*).php$ {
        deny all;
        access_log off;
        log_not_found off;

# This order might seem weird - this is attempted to match last if rules below fail.
# http://wiki.nginx.org/HttpCoreModule
location / {
        try_files $uri $uri/ /index.php?$args;

# Add trailing slash to */wp-admin requests.
rewrite /wp-admin$ $scheme://$host$uri/ permanent;

# Directives to send expires headers and turn off 404 error logging.
location ~* .(js|css|png|jpg|jpeg|gif|ico|ttf)$ {
        expires 180d;
        log_not_found off;

# Pass all .php files onto a php-fpm/php-fcgi server.
location ~ .php$ {
        # Zero-day exploit defense.
        # http://forum.nginx.org/read.php?2,88845,page=3
        # Won't work properly (404 error) if the file is not stored on this server, which is entirely possible with php-fpm/php-fcgi.
        # Comment the 'try_files' line out if you set up php-fpm/php-fcgi on another machine.  And then cross your fingers that you won't get hacked.
        try_files $uri =404;

        fastcgi_split_path_info ^(.+.php)(/.+)$;
        #NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini

        include fastcgi_params;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
#       fastcgi_intercept_errors on;
        fastcgi_pass php;

Setting up CGIT to show root directories only

CGIT is a nice, quick, and easy way of displaying git repositories. After much fighting I figured out how to allow CGIT to display URLs such as http://code.example.com/repository.git (the git is optional).

Below is the Apache config for code.example.com:

<VirtualHost *:80>
    ServerName code.example.com
    DocumentRoot /var/www/code.example.com
    CustomLog logs/code.example.com.access_log combined
    ErrorLog logs/code.example.com.error_log
    SetEnv CGIT_CONFIG          /var/www/code.example.com/cgitrc
    Alias /cgit.css             /var/www/code.example.com/cgit.css
    Alias /cgit.png             /var/www/code.example.com/cgit.png
    Alias /favicon.ico          /var/www/code.example.com/favicon.ico
    Alias /robots.txt           /var/www/code.example.com/robots.txt
    Alias /                     /var/www/code.example.com/cgit.cgi/
    <Directory /var/www/code.example.com>
      Options Indexes FollowSymLinks
      Options +ExecCGI
      Order allow,deny
      Allow from all
      AddHandler cgi-script .cgi
      DirectoryIndex cgit.cgi

Installing the git, cgit web interface on a Fedora

cgit is fast web interface for the git. cgit has built a cache and is compiled in c so it’s very quick.

To start out, download the current version of cgit via git

git clone git://hjemli.net/pub/git/cgit

Next you need to setup the git submodule

cd cgit
git submodule init
git submodule update

Once your done, run get-git

make get-git

Then compile the software


And install it

make install

After you have installed cgit, you will need to setup Apache to run cgit. This is pretty easy, just edit your /etc/httpd/conf/httpd.conf file and add the following for the site you wish to run cgit on.

<Directory "/var/www/code.mattrude.com/">
      AllowOverride None
      Options ExecCGI
      Order allow,deny
      Allow from all

Once your done setting up cgit in Apache, you may configure cgit by creating a cgitrc file at /etc/cgitrc. Below is the example config file.


# Enable caching of up to 1000 output entriess

# Specify some default clone prefixes
clone-prefix=git://foobar.com ssh://foobar.com/pub/git http://foobar.com/git

# Specify the css url

# Show extra links for each repository on the index page

# Show number of affected files per commit on the log pages

# Show number of added/removed lines per commit on the log pages

# Add a cgit favicon

# Use a custom logo

# Enable statistics per week, month and quarter

# Set the title and heading of the repository index page
root-title=foobar.com git repositories

# Set a subheading for the repository index page
root-desc=tracking the foobar development

# Include some more info about foobar.com on the index page

# Allow download of tar.gz, tar.bz2 and zip-files
snapshots=tar.gz tar.bz2 zip

## List of common mimetypes


## List of repositories.
## PS: Any repositories listed when section is unset will not be
##     displayed under a section heading
## PPS: This list could be kept in a different file (e.g. '/etc/cgitrepos')
##      and included like this:
##        include=/etc/cgitrepos

repo.desc=the master foo repository

repo.desc=the bars for your foo

# The next repositories will be displayed under the 'extras' heading

repo.desc=a set of extensions for bar users

repo.desc=the wizard of foo

# Add some mirrored repositories

repo.desc=the dscm

repo.desc=the kernel

# Disable adhoc downloads of this repo

# Disable line-counts for this repo
repo.enable-log-linecount=0# Restrict the max statistics period for this repo

Auto Update Script for MiniMyth

This script will download the newest version of MiniMyth and update your tftp directory.

It first downloads the version file and compares that version number to the current install version of MiniMyth install.  If it determines that the version dose not match it will then download the current release, untar it and move the files to their current locations. It dose not delete any older versions on your server.

  • The TFTPDIR variable is the location on your tftp server where the MiniMyth files are stored.
  • The URL variable is the MiniMyth directory that the install of MiniMyth you wish to use lives.

You may also download the full directory structure with this script from my github repository or from my server.

# /bin/bash
# Matt Rude <m@mattrude.com> 11-Nov-2009
if [ -e $TFTPDIR/version ]; then
 mv $TFTPDIR/version $TFTPDIR/version.last
 rm -rf $TFTPDIR/verstion.md5
 touch $TFTPDIR/version.log
 touch $TFTPDIR/version.last

wget -nc $URL/version > /dev/null 2>&1
VER=`cat $TFTPDIR/version`
OLDVER=`cat $TFTPDIR/version.last`

if [ "$VER" = "$OLDVER" ]; then
 chown -R apache:apache $TFTPDIR/*
 exit 0
 echo "`date` Upgraded to version: $VER" >> version.log

 rm -rf $TFTPDIR/ram-minimyth-*.tar.bz2.md5
 wget -nc $URL/ram-minimyth-$VER.tar.bz2 > /dev/null 2>&1
 wget -nc $URL/ram-minimyth-$VER.tar.bz2.md5 > /dev/null 2>&1
 MD5STAT=`md5sum -c ram-minimyth-$VER.tar.bz2.md5 |awk ' {print $2 }'`
 if [ "$MD5STAT" = "OK" ]; then
  rm -f $TFTPDIR/kerne*
  rm -f $TFTPDIR/rootf*
  rm -fr $TFTPDIR/conf/default/theme*
  tar -xjf ram-minimyth-$VER.tar.bz2
  rm -rf ram-minimyth-$VER.*
  echo "`date` Minimyth Version $VER Failed the MD5 check" >> version.log
  echo "" > $TFTPDIR/version
  exit 1


 mkdir -p $TFTPDIR/conf/default
 cp $RAMDIR/kernel $TFTPDIR/kernel-$VER
 cp $RAMDIR/rootfs $TFTPDIR/rootfs-$VER
 cp -r $RAMDIR/themes $TFTPDIR/conf/default/themes-$VER

 ln -s kernel-$VER kernel
 ln -s rootfs-$VER rootfs
 cd $TFTPDIR/conf/default
 ln -s themes-$VER themes
 #mythtvosd --template=scroller --scroll_text="minimyth upgraded to: $VER" > /dev/null
mv version.log version.tmp
tail -2 version.tmp > version.log
rm -rf version.tmp
chown -R apache:apache $TFTPDIR/*
exit 0