Hello World

Here’s the tcsh script I usually use for all my tcsh shells.

Sets some sane default and graceful fallback on non-capable terminals (esp. for setting window title). Tested on various Linux distro, *BSD, and OpenSolaris.

Additional, machine specific settings can be put at .tcsh_exec. This way I can just update the main script without worrying about modifications.

nginx [engine x] is a HTTP and reverse proxy server, as well as a mail proxy server written by Igor Sysoev. It has been running for more than five years on many heavily loaded Russian sites including Rambler (RamblerMedia.com). According to Netcraft nginx served or proxied 4.24% busiest sites in January 2010. Here are some of success stories: FastMail.FM, Wordpress.com.

nginx about page

Basically it handles (in its http):

• Serving static files
• Passing/returning (proxy) dynamic requests somewhere else

What does it mean?

• it doesn’t know anything about PHP/Python/Ruby/whatever – the dynamic contents of a site
• it can passes such requests to the responsible ‘backend’ though

In short, you configure nginx to:

• serve static (or cached) contents as efficient as possible
• passes correct dynamic requests to ‘backend’

And that’s all.

PHP is one of the worst to be combined with nginx – mainly because many of PHP applications are designed with Apache in mind (think .htaccess).

This is it for today. Also read this for basic introduction .

Introduction

(Hey this is the first post!)

Unlike Apache/mod_php and lighttpd with FastCGI autospawn, you’re forced to run nginx and PHP as separate thing: nginx for static contents, PHP (-fcgi) for dynamic contents. Running these two as separate process has advantage: they can be run under separate user. The result is you can have better file permission control compared to running as one process.

Simply put, you can set up the file permission in a way so web applications (will be explained later) won’t be able to mess with each other. Of course this doesn’t apply if all (or many) web applications you’re running is php-based and you’re too lazy to set up php for each applications or it’s infeasible to do so (memory, etc). At least the static contents server process can’t mess with dynamic contents server process – whatever benefit it has is another matter, though.

How?

Say you’re running a webserver, serving pages at /srv/www and everything inside it is php applications. You’re running the nginx as user www (with group www) and php-fcgi as user php (with group php).

Run these commands as root:

chown -R php:www /srv/www
find /srv/www -type d -exec chmod 710 {} \;
find /srv/www -type f -exec chmod 640 {} \;
find /srv/www -type f -name '*.php' -exec chmod 600 {} \;

Commands above will:

• Change files and directories owner to user php and group www.
• Disable access of the files for everyone not in group www or user php.
• Disable read permission for directories on group www. You don’t need it since read permission is only used when you’re using autoindex on server level
• User php has full access to everything
• Members of group www can only read the files…
• …except for php files, which are only readable by the owner, php.

Conclusion

Why give read (or even write!) permission of files that are dynamically generated to static contents server process ;)