Well, chmod 666 is the true evil obviously, but people who use the chmod 777 trick really don't want to bother with the different signification of x for files and folders, so they mark all files as executables. This makes ls in my terminal quite ugly, and is what motivated me to write yet another rant!

Traditionally, the web server runs with a special, underprivileged user. Now, this is totally fine — I'll get back to that later. However, when a developer starts a project, he naturally does it with his own account. This is fine, too. When he wants to test it, he installs a web server (let's say Apache and mod_php¹), and tells the web server to use the project directory. However, the web server's user can't read, or at least can't write in the directory. And here, our web developers asking for help gets recommended to "chmod 777". Symfony even has a command for doing it, and it is a real shame.

It will work. It will also make an ugly git commit, and an ugly ls. Il will create files owned by the web server, and the developer is likely to use sudo before every command to work around the problems that will ensue, and it just gets insane.

Separation of privileges is what makes UNIX systems great. Let's understand them and use them, please.

The obvious solution here is to run your development server under the development user. There is no need to separate when it's for your own usage. There is a even better solution, embraced by almost every language but PHP: a way to start a web server on demand. I believe it was started by Ruby on Rails with WEBrick, and now every non-PHP framework has it. Python, by using WSGI makes it very easy. I simulated this feature for Symfony by writing symfttpd. It's actually simpler for the developer as there is no configuration or installation at all.

Enough about developers; it's not their job to setup daemons and manage UNIX systems. Let's talk about the real accomplices of the Devil: system administrators.

Yes, there are system administrators that don't use permissions properly. And they are legion. I've seen horrors, up to "sudo svn up" on the production server, because half the files ended being owned by root. And then "chmod 777" on millions of files.

There are many solutions there; group inheritance with the setgid bit, forcing the users to su as the web server user, or a deployment script (I've used the three of them for different situations).

Why is this important? Because it is often useful to separate users (one should not have access to the other's projects in reading or writing), or to separate projects for security (one hacked project should not give access to the others).

I've seen it… done wrong:

• safe_mode for PHP. It doesn't work and will disappear in newer versions anyway.
• Only allowing FTP access to users, who can still upload a PHP script which will have access to everything (if run through the web server). Oh, and FTP sucks. Same issue with SSH and chroot.
• Add the users to the group the web server is running as. Allows SSH access. Nice, but the PHP script trick will, again, defeat it.

There is only one solution: use the "group" solution, but run a different PHP instance for each user. It is quite rarely used because the convenience of Apache and mod_php. But running PHP in the same process as the web server feels quite dangerous for me too. I think mod_php is an abomination.

I've done it for years with Lighttpd, PHP and FastCGI with a few alterations to Gentoo's spawn-fgci init script (which is now able to handle multiple configurations without any alteration since a few months). My setup is very similar to that one.

Note that while I mention PHP, this issue is not strictly related to PHP, yet seems widespread in PHP communities.

1. I don't like much both of them, but more on that later

Something that always annoyed me is how tedious it is to install a Symfony project on a machine. Since I frequently need to intervene quickly on a project for work, and I was getting a brand-new machine, I really didn't want to create an apache vhost (let alone install Apache: it's painfully slow and its configuration is obscure and hard to debug), edit my /etc/hosts file, etc. for each project.

Moreover, developers are not system administrators and should not have to do complicated setups, especially when it turns out to be badly set up, and problems are "resolved" by "chmod 777" or "chmod 666" (which is indeed evil), a very sad but true practice promoted even by the developers of Symfony since there is a symfony fix-perms command that basically does that. It should have been named symfony break-perms or symfony please-make-things-insecure-i-want-to-go-back-to-windows or never been made.

On most non-PHP frameworks, there is a small embedded webserver that you can run on-demand. No configuration needed. Moreover, no special rights needed: a simple user can start it.

Since there was no such webserver written in PHP that was able to run Symfony properly, I chose to auto-configure lighttpd with a simple tool called symfttpd. The genconf tool was born.

However, I encountered another issue I didn't think of before: for each project, I had to create symbolic links to the Symfony source code (another practice of the Symfony community, and there is no proper alternative in the PHP world). Hence, I created mksymlinks. For the developer, it is very simple to use: configure once on the machine, once per project, and that's it.

genconf only generates a configuration, which is still very practical for a system administrator; moreover it is flexible and well-tested. But it still required the develop to configure something, and there still was the rights problem.

Hence I created spawn which handles starting and stopping the webserver, just like non-PHP frameworks do. As a nice addition, it keeps server and PHP logs in the logfolder of the project.

symfttpd has even more uses; one I didn't think of at first was that it can automate the installation of a project on a continuous integration platform, and can start a webserver for functional testing (both are used daily at work).

One of the most important aspects of symfttpd is that all tools are independent: you can use only mksymlinks or genconf (though spawn more or less requires the use of both, it isn't set in stone). A system administrator will find use in mksymlinks and genconf, and a developer more in mksymlinks and spawn.

You'll find extensive documentation on the project page; what will follow is a quick tutorial for developers.

Install the necessary packages:

 
# Debian/Ubuntu
aptitude install php5-cgi php5-cli lighttpd
 
# Gentoo
emerge php # with USE="cli cgi"
emerge lighttpd # with USE="fastcgi"
 
# Macports
port install php5 +fastcgi && port install lighttpd
 
# Windows
Nice try.
 

Get the symfttpd source code:

 
cd && git clone git://github.com/laurentb/symfttpd.git
 

There are also archives you can download here if you want to avoid git or bleeding-edge changes.

Basic configuration:

 
# notice the dot before symfftpd.conf.php
$EDITOR ~/.symfftpd.conf.php
 

Enter something like that:

 
<?php
$options['sf_path']['1.0'] = '/home/myuser/symfony/1.0';
$options['sf_path']['1.4'] = '/home/myuser/symfony/1.4';
 

Of course, you have to have to adapt it to the Symfony versions you have installed and where you put them.

Configure the project:
If the project is using Symfony 1.4 in the lib/vendor/symfony, you don't need to do anything. In case it is different, or to be on the safe side, create the file config/symfttpd.conf.php in your project. After, add the file to your project's version control repository. If you're lucky, someone already did it for you.

 
cd ~/myproject
# this time, no dot
$EDITOR config/symfttpd.conf.php
 

 
<?php
$options['want'] = '1.3'; // The version of Symfony used by your project
$options['lib_symlink'] = 'lib/vendor/symfony'; // lib/vendor/symfony will lead to the "lib" directory of Symfony
 

 
~/symfttpd/mksymlinks
 

You're done.
It will create symbolic links for plugins too, even if the version of Symfony (1.0 for instance) doesn't handle them!

To start the server:

 
~/symfttpd/spawn
 

It will then tell you how to access it. It's time to stop fighting with old, unpredictable software like Apache and start developing again!

What's coming in future releases:

• Colors
• Interactive configuration
• Server/PHP logs displayed in the terminal
• Handling "sample" files
• Custom configuration support on various places

Contributors are welcome.

Update: I have written a tool than can generate automatically the proper configuration and much more!

I've seen some articles on how to configure lighttpd to serve a Symfony project, however they usually did at least one mistake:

• Assuming that requests with periods ('.') are for static files (the period is a default separator in Symfony, and is extensively used in the new admin generators).
• Ignoring parameters after a '?' (they are not widely used, except... in the new admin generators, and can be very useful if your application)

For the first part, there is a much simpler solution to handle static files: most of them are in specific directories, except for a very limited number of ones.

My solution also handles assets published by plugins (you might want to edit the corresponding line to a more liberal one though).

You might want to add your sitemap.xml.gz or robots.txt to this list if you generate them statically.

For the second part, you simply have to match explicitly the '?' part.

Here is the magic:

 
alias.url = (
  "/sf/" => "/home/web/symfony_12/data/web/sf/"
)
 
url.rewrite-once = (
  "^/css/.+" => "$0", # directories with static files
  "^/js/.+" => "$0",
  "^/images/.+" => "$0",
  "^/uploads/.+" => "$0",
  "^/favicon\.ico$" => "$0", # static file example
  "^/sf[A-z]+Plugin.*" => "$0", # plugins
  "^/sf/.+" => "$0", # symfony assets
  "^/backend\.php(/[^\?]*)(\?.*)?" => "/backend.php$1$2", # allow access to another application
  "^(/[^\?]*)(\?.*)?" => "/index.php$1$2" # default application
)
 

I guess the usage of periods in the rules also had the benefit of allowing the access to any alternative application automatically. With my solution you have to add each appname.php file manually, unless you use:

 
  "^/([a-z]+)\.php(/[^\?]*)(\?.*)?" => "/$1.php$2$3", # any app (prod)
 

Or for allowing any environment:

 
  "^/([a-z_]+)\.php(/[^\?]*)(\?.*)?" => "/$1.php$2$3", # any app (any env)
 

Note: your application must contain only lowercase letters, but you're free to adapt it to your own usage.

Seconds, really.

First, why stop using BIND? For me it just happened because I couldn't understand why BIND wasn't working (again). However there are many other reasons to make the switch before it's too late. BIND has a bad security history, PowerDNS's code is more "modern" and its various parts are well-separated (for example, you are not obligated to even install the recursor, it's another daemon).

PowerDNS now has a BIND zone backend, and it works with both primary (master) and secondary (slave) zones. Before that, only database or other fancy backends were available; for hosting only some small domains it would be overkill and a pain to manage.
However the documentation wasn't really clear. Here is how to do it.

How to do it

You should have this in your pdns.conf file:

# Start the bind backend (you can load multiple backends)
launch=bind
# Path to your BIND named.conf
bind-config=/etc/bind/named.conf
# PowerDNS will check if the zones are modified automatically. No need to reload the daemon!
bind-check-interval=300

And... that's it, you're done.

But don't forget to set allow-axfr-ips with the IPs of the secondary DNS servers of your primary domains in pdns.conf (that's allow-transfer in named.conf).

More details

The only thing needed in named.conf are zone entries, anything else is ignored. For example:

zone "example.com" IN {
    type slave;
    file "/etc/bind/sec/example.com.zone";
    masters { 1.3.3.7; };
};
 
zone "example.net" IN {
    type master;
    file "/etc/bind/pri/example.net.zone";
};

If you want to create your first zone file, you can use the BIND zone file creator.

I also encourage you to try out the pdns_control tool that is bundled with PowerDNS.