1. spawn-fcgi: there's a package for it so I just used that :
   PLAIN TEXT
   CODE:

   1. sudo apt-get install spawn-fcgi

2. the stop/start script complained when adding it to the boot/shutdown cycle, but one posted in the comments worked:
   PLAIN TEXT
   CODE:

   1. #!/bin/bash
   2. ### BEGIN INIT INFO
   3. # Provides: php-fastcgi
   4. # Required-Start: $all
   5. # Required-Stop: $all
   6. # Default-Start: 2 3 4 5
   7. # Default-Stop: 0 1 6
   8. # Short-Description: starts the php-fastcgi process
   9. # Description: starts php-fastcgi using start-stop-daemon
   10. ### END INIT INFO
   11. PHP_SCRIPT=/usr/bin/php-fastcgi
   12. FASTCGI_USER=www-data
   13. RETVAL=0
   14. case "$1" in
   15. start)
   16. su - $FASTCGI_USER -c $PHP_SCRIPT
   17. RETVAL=$?
   18. ;;
   19. stop)
   20. killall -9 php5-cgi
   21. RETVAL=$?
   22. ;;
   23. restart)
   24. killall -9 php5-cgi
   25. su - $FASTCGI_USER -c $PHP_SCRIPT
   26. RETVAL=$?
   27. ;;
   28. *)
   29. echo "Usage: php-fastcgi {start|stop|restart}"
   30. exit 1
   31. ;;
   32. esac
   33. exit $RETVAL

3. Next to stop Apache from starting up run:
   PLAIN TEXT
   CODE:

   1. sudo update-rc.d -f apache2 remove

4. On the rewrite front, I needed to add the following to my virtual host configuration to have those seo friendly urls up and running again:
   PLAIN TEXT
   CODE:

   1. try_files $uri $uri/ /index.php;

And locate the lines below to start fine tuning Jetty's memory usage:

When trying to access a controller from the default start page. I traced this to a missing dependency in grails (I use SpringSource Tool Suite for development so that maybe the root cause). By opening and editing your /project/grails-app/conf/(default package)/BuildConfig.groovy, add the following under grails.project.dependency.resolution.

Build your war and re-deploy. Still getting an error?? I was. For jetty there was still an issue with calling the controller. After spending some time exploring, it looks like Jetty support was removed from Grails 1.2. I stumbled across a post mentioning installing the grails Jetty plugin with:

After running this, and re-building my war file and re-deploying it one final time, bingo it all worked.

1. grails war (your app), in this case epic.war
2. Copy to server
   PLAIN TEXT
   CODE:

   1. scp epic.war user@server:/location

3. On Debian the location for jetty webapps is: /var/lib/jetty/webapps
4. Copy from upload location to the above folder (I used sudo)
5. Change permissions:
   PLAIN TEXT
   CODE:

   1. sudo chown jetty:adm epic-0-0.1.war

6. created a *.xml context file in /etc/jetty/contexts, with something like this [note case is important!!]:
   PLAIN TEXT
   CODE:

   1. <?xml version="1.0"  encoding="ISO-8859-1"?>
   2. <!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
   3. <Configure class="org.mortbay.jetty.webapp.WebAppContext">
   4.   <Set name="contextPath">/epic</Set>
   5.   <Set name="war"><SystemProperty name="jetty.home" default="."/>/webapps/epic-0-0.1.war</Set>
   6. </Configure>

7. restart jetty :
   PLAIN TEXT
   CODE:

   1. sudo /etc/init.d/jetty restart

   (try stop/start as well)

8. test with :
   PLAIN TEXT
   CODE:

   1. lynx http://localhost:8080/epic/

9. Nice but I'd like http://localhost/epic/ so enable mod_proxy in apache if you haven't already :
   PLAIN TEXT
   CODE:

   1. a2enmod proxy

10. edit /etc/apache2/mods-enabled/proxy.load and if not present add at end:
    PLAIN TEXT
    CODE:

    1. LoadModule proxy_http_module /usr/lib/apache2/modules/mod_proxy_http.so

11. edit your virtualhost conf file I am using 000-default and add:
    PLAIN TEXT
    CODE:

    1. ProxyRequests Off
    2. <Proxy *>
    3.     Order deny,allow
    4.      Allow from all
    5. </Proxy>
    6. ProxyPass        /epic http://localhost:8080/epic
    7. ProxyPassReverse /epic http://localhost:8080/epic
    8. ProxyPreserveHost On

12. restart apache : 
    PLAIN TEXT
    CODE:

    1. sudo /etc/init.d/apache2 restart

13. now you can
    PLAIN TEXT
    CODE:

    1. lynx http://localhost/epic/

Update: I had omitted the ProxyPreserveHost On from the Apache configuration, which resulted in css, images and external javascripts not loading. It also caused an issue with accessing controllers.

Sources:

• Configuring mod_proxy
• Deploying a web application to Jetty

When you google for the solution I found a number of dead ends, but in the comments for one of them there was a helpful pointer.

When you do an 'ls -la' on sites-enabled (inside /etc/apache2), you will see a symbolic link to the sites-available folder and typically just for the default site (000-default -> default). However in sites-available there's also a default-ssl config file. Creating a symbolic link to this file and reloading apache fixed my problem and now I have apache serving up http over SSL .

1. MySQL : failed to start, complaining about:
   PLAIN TEXT
   CODE:

   1. /etc/init.d/mysql: ERROR: Using expire_logs_days without log_bin crashes
   2. the server. See README.Debian.gz

   Commenting out the expire_logs_days in the my.cnf file allowed me to restart MySQL.

2. After the upgrade of Apache, my virtual hosts weren't working. A quick search via Google pointed me to this post - a quick edit of all of my host files and it was all working again.
3. the php-mysql connector somehow hadn't been upgraded/installed so a quick
   PLAIN TEXT
   CODE:

   1. apt-get install php5-mysql

   fixed that problem.

4. OpenBD : the only thing that remains broken was my tomcat5.5 Open BD install. Tomcat was working fine but Open BD refused to start up complaining about :
   PLAIN TEXT
   CODE:

   1. javax.servlet.ServletException: Open BlueDragon Engine Failed to initialise tags: java.awt.Color

   Since I am not really using it, it's not that important, but at some stage I'd like to get it working again. If you have any suggestions, please leave a comment.

The config looked fine, but after restarting the service, I still wasn't getting prompted for a log in. After re-jigging the order to what you see below and restarting the apache service (we are using 2.0.59), it all worked. Maybe this will help someone else along the way.

He dug a little further and found the solution to the problem (look for the post by yakhunter). For posterity here is the resolution.

This document is briefly going explain out how to configure your Apache web server to execute Cold Fusion pages. First off install the Cold Fusion application server (available from Allaire) normally. When the moment arrives to specify the location of your CF documentation and example files, select a directory of your preference (or if you have IIS running alongside Apache, simply accept the default path <drive letter>:INETPUB\wwwroot). After continue with the normal installation procedure.

Once this is done, shutdown your Apache web server (available from http://www.apache.org/). Next you will need to copy the following file ApacheModuleColdFusion.dll from the <drive letter>:CFUSION\bin directory to the modules sub-directory in your Apache installation (usually <drive letter>:Program Files\Apache Group\Apache\modules).

The next step requires you to edit your httpd.conf. Locate the section displayed below:

Once you have done so enter the following lines at the end of the above section so that the section should now look like this:

You are now nearly ready to test your Cold Fusion installation. All that remains to be done is to tell your Apache web server the location of your cfdocs/ directory. To do this edit your srm.conf file so that your file looks something like this:

At this point you should also be aware of the fact that the Apache web server is case sensitive. So there is a distinct difference between entering cfdocs and CFDOCS when specifying your alias name. You are now ready to restart your Apache web server (please note that if you are using the single user version for development purposes your Apache server has to work on port 8080, else Cold Fusion won't allow the execution of .cfm pages). Once the server is restarted you are ready to test your installation. Simply point your browser to http://<your domain or ip address>/cfdocs/index.htm. If the CF welcome page is served you have properly configured the cfdocs/ directory. Now just go to the Test installation page and test CF. For problems with CF please refer to your CF documentation. For the CF documentation on configuring Apache to serve CF pages check out the documentation that comes with the CF installation (if installed usually located at http://<server name>/cfdocs/ Administering_ColdFusion_Server/01_Installing_and_Configuring_ColdFusion/admin012.htm#1023844)