Chrome: Auto Connecting with a Client Certificate

When using client certificates in Chrome, one of the great annoyances is that it prompts you each time you first go to the secured site per session.  This is of course preferred  as a security step to confirm you are connecting with the correct certificate, but you can also configure Chrome to use the certificate you selected for each site.

AutoSelectCertificateForUrls-1

Note the added key’s “Google”, “Chrome”, & “AutoSelectCertificateForUrls”

To accomplish this, in Windows 7, we will be adding a registry keys via regedit.  You will need to first open the Registry Editor by going to Start, then start typing in the lower search box “regedit”.  Once the registry editor is opened, you will need to create a Google key, Chrome Key, and a AutoSelectCertificateForUrls key so it vaguely looks like the following example. You may have many, many, many programs under SOFTWARE and Policies, just right mouse click on Policies and choose New then Key.

Next you need to add the values to the AutoSelectCertificateForUrls key.  Right mouse click on the large white space on the right side of the screen and choose New, then String. Name the new string 1 and add the following to the value:

{"pattern":"https://example.com","filter":{"ISSUER":{"CN":"CertName"}}}

Where https://example.com is the URL of the site you are accessing, and CertName is the CN name from the certificate you are using.

Once you are finished, it should look something like this.

AutoSelectCertificateForUrls-2

WordPress: Allow Auto Updating

When WordPress is properly locked down on your server, you are often unable to automatically update the plugins or themes on your site. The problems comes in when WordPress looks to see if it is able to write to the file system. Since it can’t modify it’s own files, it requests access to the FTP server running on your web-server. My sites NEVER have a FTP server running on them for simple security reasons, so updating via FTP is not an option.

Each of my sites are locked down with the below commands. The first line modifies the file system to allow only the Owner & Group to have modify access to each file or directory. All other users only have read access. The second line changes all files and directories so to be owned by root and the root group. The 3rd line grants owner and group permissions to the user www-data; the Ubuntu default webserver user.

chmod -R ug=rwX,o=rX
chown -R root:root /var/www/example.com
chown -R www-data:www-data /var/www/example.com/wp-content/plugins \
/var/www/example.com/wp-content/themes /var/www/example.com/wp-content/upgrade \
/var/www/example.com/wp-content/uploads

So now that your site is locked down, you can’t update the plugins or themes, well; that’s where this next part comes in.

auto-update-fail

This is the error you will receive if your site is properly locked down, when you try to update a plugin or theme.

If you add the below lines to your wp-config.php file, it will tell WordPress to ignore checking it’s files to see if they are modifiable, and to just try updating the plugin or theme. This will allow you to update a plugin or theme by using the auto update method build directly into WordPress.

Add the following to your wp-config.php file, just above the /* That's all, stop editing! Happy blogging. */ line.

// Allow auto updating
define('FS_METHOD', 'direct');

This change will not allow you to update WordPress Core as the webserver still dose not have access to modify the core files. I suggest you update via SVN or GIT on a nightly bases to ensure you always have the latest version of WordPress running.

Disable Console Power Save on Ubuntu

By default Ubuntu console turns off after about 15 minutes of no keyboard commands, regardless of what may be, being displayed at the time. Often it is useful to disable this ‘feature’ on production servers to better monitor the activities being sent to the console, such as errors and logs.

There are two methods of doing this, either per session, or for the whole system.

To disable it for only the current session log in as root run the following command:

setterm -powersave off -blank 0

To disable console blacking for all session on this server and to retain this change after reboot, you will need to start by installing the console-tools packet:

apt-get install console-tools

After you have the console-tools packet installed. To stop the screen blanking both the screen saver (BLANK_TIME) and the power management standby (POWERDOWN_TIME) settings need to be disabled. If these two settings are set to zero (0) in the file /etc/console-tools/config the features will be completely disabled.

Alternatively a local settings file called /etc/console-tools/config.d/disable-blank-console can be created containing the following two lines to achieve the same affect.

POWERDOWN_TIME=0
BLANK_TIME=0

Actually you can name the file anything you want so long as the name consists of only upper/lower case letters, numbers, underscores, and hyphens.

Rackspace Cloud Backup on Ubuntu

Rackspace recently released their Cloud Backup to their normal user base.

This service will store your files on Racksapce’s cloud file service.  You will need to install drivecloud app on your server before running your backups.

To install the software, run:

sh -c 'wget -q "http://agentrepo.drivesrvr.com/debian/agentrepo.key" -O- | apt-key add -'
sh -c 'echo "deb [arch=amd64] http://agentrepo.drivesrvr.com/debian/ serveragent main" > /etc/apt/sources.list.d/driveclient.list'
apt-get update; apt-get install driveclient

You will need your username and API key to complete this step. To locate your API key, click the arrow next to your user name (at the top right of the Control Panel) and select API Keys. On the “API Access” page, click the Show Key button. Then, copy it to your clipboard.

Tip: This step will ask you to confirm that you want to overwrite your config file. Answer yes.

driveclient --configure

Start the Agent:

service driveclient start
update-rc.d driveclient defaults

After you have started the agent, go back to the Rackspace Backup Admin page to finish configuring your new setup.

cgit Installed on a Ubuntu Nginx Server

Installing spawn-fcgi

To start out with, we need to install the Nginx and the other dependencies.

apt-get install nginx fcgiwrap git

Ok, here we go, lets start out by creating a place to play with source, I always build in /var/src/ but your welcome to do this anywhere you wish.

/etc/sysconfig/spawn-fcgi:

FCGI_SOCKET=/var/run/fcgiwrap.socket
FCGI_PROGRAM=/usr/local/sbin/fcgiwrap
FCGI_USER=nginx
FCGI_GROUP=nginx
FCGI_EXTRA_OPTIONS="-M 0700"
OPTIONS="-u $FCGI_USER -g $FCGI_GROUP -s $FCGI_SOCKET -S $FCGI_EXTRA_OPTIONS -F 1 -P /var/run/spawn-fcgi.pid -- $FCGI_PROGRAM"

Configuring Nginx

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

    fastcgi_param    DOCUMENT_ROOT    /var/www/code.example.com;

    rewrite ^/secure/ https://code.example.com$request_uri permanent;

    location /cgit.css { expires 180d; }
    location /code-logo.png { expires 180d; }
    location /robots.txt { expires 180d; }

    # Serve static files
    location ~* ^.+.(css|png|ico)$ {
        root /var/www/code.example.com;
        expires 30d;
    }

    location / {
        #rewrite ^/([^?/]+/[^?]*)?(?:?(.*))?$ /cgit?url=$1&$2 last;
        include         "fastcgi_params";
        fastcgi_pass    unix:/var/run/spawn-fcgi.socket;
        fastcgi_index   /;
        fastcgi_param   SCRIPT_FILENAME /var/www/code.example.com/cgit.cgi;
        fastcgi_param   PATH_INFO       $uri;
        fastcgi_param   QUERY_STRING    $args;
    }
}

Using the Git Stash command

The git stash command is used to store changes to a dirty git tree when pulling changes[ref]http://man.github.com/git/git-stash.html[/ref].

For example, if you are working on a repository, but are not ready to commit your changes, you may run.

git stash

This will store the changes you have made since the last revision and allow you to start back fresh at the point of your last commit.

Once you are done, you may run

git stash pip

That will restore your repository back to where you were when you ran git stash.

WordPress: Add footer text to feed posts

Here’s a small code snippet for adding text to the bottom of each post in your rss feed. This will not affect the post content shown on your site.

The below should be added to your themes function.php file.

/********************************************************************************
* Add Footer to RSS feed
*/

function mdr_postrss($content) {
    if(is_feed()){
        $site_name = get_bloginfo_rss('name');
        $post_title = get_the_title_rss();
        $home_url = home_url('/');
        $post_url = post_permalink();
        $content = $content.'<a href="'.$post_url.'">'.$post_title.'</a> is a post from: 
<a href="'.$home_url.'">'.$site_name.'</a> which is not allowed to be copied on other sites.';
    }
    return $content;
}
add_filter('the_excerpt_rss', 'mdr_postrss');
add_filter('the_content', 'mdr_postrss');

Or may be found on github.

Git: Configuring native git commit emails

To start out, move the post-receive.sample script from your git hooks directory to just plain post-receive like so:

mv post-receive.sample post-receive

Then in your git config file add the below, below any existing configuration items. Note, you will need to change the URL and repository name (currently named “git-repository”) before this will work.

[hooks]
        mailinglist = email@example.com
        emailprefix = "git-repository: "
        showrev = "t=%s; printf 'https://example.com/secure/?p=git-repoistory;a=commitdiff;h=%%s' $t; echo;echo; git show -C $t; echo;"

And there you go, when you now push to the repository, you will receive an email send to “mailinglist” with the changes made in a nice diff and a link back to your main git repository site.

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.

GoDaddy SSL Certificate with Nginx

Installing a SSL certificate from Go Daddy is a bit different then other providers.  With Go Daddy you must install a intermediate or chain certificate addition to your CA certificate. Nginx does not have a option, how Apache dose, for chain certificates. So to accomplish this, we look to the Nginx documentation:

If intermediate certificates should be specified in addition to a primary certificate, they should be specified in the same file in the following order: the primary certificate comes first, then the intermediate certificates.[ref]Nginx Module ngx_http_ssl_module[/ref]

What that means is this.  Download your CA from with your private certificate from Go Daddy.  Next download the gd_bundle.crt from https://certs.godaddy.com/anonymous/repository.seam.

After you have download the gd_bundle.crt file, copy it to the same directory on your Nginx server and run something similar to:

cat godaddy-ca.crt > godaddy-chain.crt && cat gd_bundle.crt >> godaddy-chain.crt

Now just add this new certificate to your nginx.conf per normal

ssl_certificate godaddy-chain.crt

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 
--auth=*,/var/www/trac.example.com/projects/.htpasswd,trac.example.com 
--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 127.0.0.1:3050;
   }
   
   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;
       }
   }

Custom 404 errors pages in Nginx

Here’s a quick how-to on creating a custom 404 error page on a Nginx server.

To display a single page for a site, add the below to your server’s config. The below config assumes /404.html is in the root of the current site.

server {
    ...
    error_page 404 /404.html;
    ...
}

The error page it self doesn’t have to be anything special, just a clear message for the user to know that this page dose not exist.

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 127.0.0.0:8000), 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;
        break;
    }

    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.

application/config/config.php:

$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.

/etc/nginx/nginx.conf:

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

/etc/nginx/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;
                break;
        }
}

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.