Symfony Deployment Gotcha

So I've been working with Symfony in the PHP arena and I found a really obnoxious gotcha that lives at the intersection of Symfony-based tutorials and Redhad-based distros. (In this case, CentOS.)

Namely, Symfony creates a rather expansive directory structure that - for security reasons - can't all live under your web root. The solution all the tutorials have you do is to set up the actual project in your home directory and then create an Apache virtual server that points to it. Seems simple enough. And you can add it to your config without any griping from Apache. Symfony has all the global perms set, so you're good, right?

Wrong, unfortunately. I was getting "403 Forbidden" over and over. I tried a wide variety of fixes, none of which worked. Eventually, I found this post on google groups:

http://bit.ly/mNRrlV

Sure enough, I checked the root perms of my home directory and it was all tightened down:

drwx------ 17 user user 4096 May 30 06:16 user

Just goes to show you the danger of returning to "childlike innocence" with new projects.

In reality, the right way to approach this is to create a project-specific directory somewhere under /usr/local and consciously set perms for the whole thing.

Following that approach, you get the right results straight out of the gate:

[root@localhost local]# ls -ld projects/
drwxr-xr-x 3 root root 4096 May 30 07:17 projects/

[root@localhost local]# ls -ld projects/milkshake/
drwxr-xr-x 11 root root 4096 May 30 07:18 projects/milkshake/

Now, you create your Symfony project under that:

symfony generate:project --orm=Propel milkshake

And your app:

symfony generate:app frontend

Finally, you add the following to your httpd.conf:


# Be sure to only have this line once in your configuration

NameVirtualHost *:8080



# This is the configuration for your project

Listen *:8080

<VirtualHost *:8080>

DocumentRoot "/usr/local/projects/milkshake/web"

DirectoryIndex index.php

<Directory "/usr/local/projects/milkshake/web">

AllowOverride All

Allow from All

</Directory>


</VirtualHost>


This is a good lesson for everybody: please check what you write and all your other assumptions, as well.

swatch queues messages

Swatch is a fantastic tool for tailing logs for errors. But it has a surprising built-in behavior: it forcefully queues the outbound mails it generates for 30 minutes. Obviously, this stuff can be time-sensitive. I bugged some enlightened folks on the IRC channel and I got this excellent suggestion:

Create a job in root's cron to have exim flush the queue for the destionation mail addy at whatever interval you want. Here's one that does it every five minutes:

*/5 * * * * /usr/sbin/exim -qR

This solution is particularly elegant because you don't need to dig around inside swatch's guts. (Something you should never do with a package for a whole host of reasons.)

Make your own daemon

A fantastic article on swatch (http://www.linux-mag.com/id/7807) included this delightfully simple framework for rolling your own daemons. If you take a moment to read it, you'll see a lot of unix design principles relating in perfect harmony:

#!/bin/sh 

# Simple Log Watcher Program  

case "$1" in 'start')   

/usr/bin/swatch --daemon --config-file=/etc/swatch.conf --tail-file=/var/log/auth.log --pid-file=/var/run/swatch.pid   

;; 

'stop')   PID=`cat /var/run/swatch.pid`   kill $PID   

;; 

*)   echo "Usage: $0 { start | stop }   

;; 

esac 

exit 0 

Unattended Ubuntu Apt Installs

This will be short and sweet.

When you want to

apt-get install package

and you don't want to get prompted for values, etc, just add the following the front of your shell:

export DEBIAN_FRONTEND=noninteractive

Poof. Magic.

Grepping out comments and blank lines

One thing we commonly see in open-source configs is an abundance of helpful comments. Often, they dwarf the number of active parameters being set and that can make things very hard to read.

In the blessed world of unix, there is an easy solution to this: you simply use grep to remove those lines from a listing of the contents of the file.

First, grep out the comments:

grep -v \# file

Usually, that will leave you with a lot of unnecessary whitespace, as well. So just pipe that output through an enhanced grep and filter for blank lines:

grep -v \# file | egrep -v "^$"

To clarify the above, here's a break down of each component:

grep - self explanatory

-v - tells grep to remove what matches rather than show it

\ - tells the shell the special character # is to be passed to the process without interpretation

# - the near-universal symbol for "comment" in config-ese

file - a stand in for whatever conf you're digging through

| - a pipe. Tells the shell to send the output of what's to the left of the pipe to what's on its right

egrep - grep with extended regular expressions (a sophisticated text manipulation language)

-v - telling egrep to remove the matches

"" - passing what's inside to grep without shell interpretation

^ - Means "the start of the line"

$ - Means "the end of the line"

So what you're telling it, in essence, is the following:

1. Read the contents of file
2. Remove all lines with "#"
3. Pass the result to egrep
4. Egrep: remove all lines which begin and immediately end (ie, a blank line) and output the result

This is one of those little tricks that goes a long way to simplifying interactions with Unix hosts and it's actually the first thing I do when I go to read any new service's default config.

Hope it helps.